A composable container build tool chain.
A low-level build tool for OCI-compliant container images.
A container build tool that runs inside a container, requiring no additional privileges. Suitable for use inside a Kubernetes pod. Supports reproducible (timestamp-less) builds out of the box.
Matthias
#
Well-maintained (or not) OpenJDK Docker images
Here is a list of major OpenJDK vendors and the container images they offer.
| Vendor | Image name | Tag | Release cycle | Base OS | Remarks |
|---|---|---|---|---|---|
| Azul | docker.io/azul/zulu-openjdk |
17 |
LTS | Ubuntu | |
| Azul | docker.io/azul/zulu-openjdk-alpine |
17 |
LTS | Alpine Linux | |
| Azul | docker.io/azul/zulu-openjdk-centos |
17 |
LTS | CentOS | |
| Azul | docker.io/azul/zulu-openjdk-debian |
17 |
LTS | Debian | |
| BellSoft | docker.io/bellsoft/liberica-openjdk-alpine |
17 |
LTS | Alpine (glibc) | |
| BellSoft | docker.io/bellsoft/liberica-openjdk-alpine |
latest |
non-LTS | Alpine (glibc) | |
| BellSoft | docker.io/bellsoft/liberica-openjdk-alpine-musl |
17 |
LTS | Alpine (musl) | |
| BellSoft | docker.io/bellsoft/liberica-openjdk-alpine-musl |
latest |
non-LTS | Alpine (musl) | |
| BellSoft | docker.io/bellsoft/liberica-openjdk-centos |
17 |
LTS | CentOS | |
| BellSoft | docker.io/bellsoft/liberica-openjdk-centos |
latest |
non-LTS | CentOS | |
| BellSoft | docker.io/bellsoft/liberica-openjdk-debian |
17 |
LTS | Debian | |
| BellSoft | docker.io/bellsoft/liberica-openjdk-debian |
latest |
non-LTS | Debian | |
| Eclipse | docker.io/library/eclipse-temurin |
latest |
non-LTS | Ubuntu | recommended non-LTS1 |
| Eclipse | docker.io/library/eclipse-temurin |
17 |
LTS | Ubuntu | recommended LTS1 |
| Eclipse | docker.io/library/eclipse-temurin |
17-alpine |
LTS | Alpine | |
gcr.io/distroless/java17-debian11 |
latest |
LTS | Debian | ||
| Microsoft | mcr.microsoft.com/openjdk/jdk |
17-ubuntu |
LTS | Ubuntu | |
| Microsoft | mcr.microsoft.com/openjdk/jdk |
17-mariner |
LTS | CentOS (derivative) | |
| Microsoft | mcr.microsoft.com/openjdk/jdk |
17-cbld |
LTS | Debian (derivative) | |
| Oracle | container-registry.oracle.com/java/openjdk |
latest |
non-LTS | Oracle Linux | recommended non-LTS2 |
| Red Hat | registry.access.redhat.com/ubi8/openjdk-17 |
latest |
LTS | RHEL (UBI)4 | recommended LTS3 |
| Red Hat | registry.access.redhat.com/ubi8/openjdk-17-runtime |
latest |
LTS | RHEL (UBI)4 |
General remarks:
As is apparent from the list, most vendors do not offer a rolling non-LTS image. Be careful when using a non-LTS image pinned to a specific version as its time under support will be quite limited. Rolling non-LTS images that always update to the latest OpenJDK version are fine (and may in fact be more secure and reliable than any LTS image considering that OpenJDK Updates primarily consists of backports from later versions).
Generally speaking, Docker images, particularly OpenJDK images, tend to drift from the latest update state of the base OS underlying them. It is probably a good idea to build your own runtime image (perhaps based on something like UBI Micro (manual)) and keep it up to date through a nightly CI job.
I cannot recommend any Alpine-based images at present because there are too many dependencies on glibc specifics (see also) in the ecosystem and using glibc on Alpine is not a supported configuration.
Footnotes:
Being a widely deployed image with lots of attention given to it, the Temurin image is probably the one you want if you prefer Ubuntu over RHEL.
Oracle is the main sponsor of OpenJDK. New OpenJDK releases tend to find their way into their image promptly. Oracle Linux is also a generally well-maintained and secure base; do note, however, that the OpenJDK image is typically only updated when a new OpenJDK is released, so you have to install system package updates yourself.
Red Hat is the second largest contributor to OpenJDK (after Oracle) and one of the sponsors of the OpenJDK 17 Updates project and is typically quick to release security patches. UBI8 is also a well-maintained and secure image base.
UBI is a trimmed-down version of RHEL that Red Hat distribute free of charge as part of their container image offerings.
Targeting JDK 19.
Proposed to target JDK 19.
A web application and JMX client that runs in your Kubernetes cluster to pull Java Flight Recorder dumps from pods and store them in a central location for later processing.
While you can always use kubectl exec in conjunction with kubectl cp to pull a dump in a pinch, this sounds nicer.
A JavaScript rich text editor that can only do simple things and enforces a correspondingly simple structure on the document being edited. Takes HTML as input and outputs HTML, but deliberately does not allow direct HTML editing.
A rich-text editor for React with a fairly complex document model.
A JavaScript rich text editor that stores blocks (paragraphs, images, etc.) in a structured way. Each block is an entry in a JSON list. Paragraphs contain HTML inline.It seems a bit strange to me to mix JSON with HTML given that HTML itself is a mark-up language for semi-structured data.
Embedding it in XML as a dialect would have felt more natural to me. Such an arrangement would have been especially useful when the desired output format is not HTML, but, say, TeX or Markdown.
Matthias
#
How do I create smaller initramfs images on Ubuntu?
If you are running Ubuntu, your initramfs images may be quite large. On my system, for instance, each initramfs took up about 100 MiB of space. Because I did not pay enough attention when setting up the computer I ended up with a very small boot partition, which prompted me to look for a way to make the initramfs images generated by update-initramfs smaller.
Caution: Any of the below may make your system unbootable. Please only copy the steps if you understand what they do.
Step 1. Fewer kernel modules.
Create a file called, say, /etc/initramfs-tools/conf.d/zzz-custom (the exact name of the file does not matter much) and fill it with the following:
MODULES=dep
This causes mkinitramfs to guess the set of kernel modules required to boot your system based on what is currently loaded and what hardware is present instead of indiscriminately including whatever could be useful to make a computer boot.
This saved me about 50 MiB, reducing the size of the initramfs from 100 MiB to 50 MiB.
Step 2. No GPU.
Assuming you do not need to interact with the initramfs (to debug boot problems or to type in a disk encryption password, say), you can disable the scripts that deal with setting up a graphics frame buffer. Doing so gets rid of GPU firmware, which at least for the amdgpu driver is a pretty sizable amount of data.
Adding the following to /etc/initramfs-tools/conf.d/zzz-custom may or may not be good enough:
FRAMEBUFFER=n
In my case it was not good enough. Since I boot from ZFS, the /usr/share/initramfs-tools/conf-hooks.d/zfs hook was active, forcing FRAMEBUFFER to y regardless of what /etc/initramfs-tools/conf.d says.
But of course you can add your own configuration hook to /usr/share/initramfs-tools/conf-hooks.d. You just have to ensure it runs after the zfs one by giving it a lexicographically higher name. So create a file called /usr/share/initramfs-tools/conf-hooks.d/zzz-custom and fill it with the same content as above:
FRAMEBUFFER=n
As long as you do not need a disk encryption passphrase prompt in the initramfs, this should not break anything. If you do, it is probably a bad idea.
This saved me another 30 MiB, reducing the size of the initramfs from 50 MiB to 20 MiB.
A docker-like command line tool for containerd.
A PC boot loader with support for ZFS boot environments.
One benefit over GRUB is that being Linux-based, it supports all ZFS pool features. (With GRUB you generally have to maintain a separate boot pool with a restricted feature set or else be very careful about which features you enable on your pool.)
A continuous profiler. Run it next to your production servers and visualize the data later.
Benefits:
- small
- easy to install
- easy to cross-compile with
Neo-reaction is mostly racist and chauvinist, but it is intellectually interesting because it raises a few good questions (not the least of which being how to deal with neo-reactionaries winning elections).
A very strange blog by one Mencius Moldbug, who calls himself a reactionary.
I am not sure whether “reactionary” as used here and “neo-reactionary” as used by Tyler Cowen are the same thing or whether it even is a coherent concept in the first place.
They are still very bad, of course, particularly if you are living in a large population center.
Lets you simulate the detonation of a nuclear war head in a location of your choice and estimate how bad it would be.
Try to make a guess before running the simulation and see how well it lines up with the result.