systemd 251 is already among us to continue with the evolution of this “suite of basic building blocks for a Linux system”, which is also defined as a system manager or system framework depending on where you look at it. On this occasion we find some important news that in the future may lead to important changes, so let’s go with them.
First of all we have to the default version of C has been changed from C89 to C11 with the GNU extensions (GNU11), although the API headers are still limited to the oldest version (which is 89). This change could be motivated by following in the footsteps of the Linux kernel, a project that has also considered migrating to C11 due to the limitations that C89 is presenting. Some will say that the true future is Rust, but here we would be getting too prescient.
Experimentally, the component ‘systemd-sysupdate‘, which is work started last summer by Red Hat and the core systemd developers. It is a mechanism capable (or at least intended to be capable) of automatically discover, download, and install updates for host installations, container images, portable service images, and other components.
All supported kernels starting with systemd 251 will scramble the output of the RdRand instruction (or other processor randomization ISA extensions) on early startup, which has had two consequences. The first is that, even if `/dev/urandom’ is not initialized, it would still be able to return bytes of at least the same quality as using RdRand directly. Second, systemd no longer needs to invoke RdRand directly, seeing as systemd’s use of RdRand has been a source of bugs.
The generators called by PID 1 have built-in several environment variables: $SYSTEMD_SCOPE, $SYSTEMD_IN_INITRD, $SYSTEMD_ARCHITECTURE, $SYSTEMD_FIRST_BOOT Y $SYSTEMD_VIRTUALIZATION. On the other hand, the same PID 1 will automatically fetch system credentials from QEMU’s ‘fw_cfg’ interface as a means of passing arbitrary data to virtualized systems, similar to what can be done with ‘systemd-‘ containers. nspawn’.
Continuing with more systemd 251 stuff, the ‘systemd-creds’ tool has included ‘has-tpm2’ to indicate if a working TPM 2.0 module is available. It is worth remembering that TPM 2.0 is being one of the main obstacles for the expansion of Windows 11, although that does not mean that Linux systems that rely on systemd will also require it, especially considering that most of the components of the framework they are optional.
One of the star components of systemd is ‘systemd-oomd’, which is responsible for improving RAM management when it starts to run low. In this release, in addition to other additions, it allows units you have killed to have an ‘oom-kill’ service result. The number of times a service has been killed is counted in the ‘user.oomd_ooms’ extended attribute.
At the udev level, two files have been incorporated. One lists handheld devices like calculators and PDAs, while the other lists audio and video production devices like DJ tables. Both should be accessible by default by the owning user.
Other minor components of systemd 251 are more service configurations that can now also function as non-privileged user services, the fact that ‘.netdev’ files can now be used in virtual WLAN devices, and improvements to the specification of the boot manager.
systemd 251 can be installed through the tortuous process of compiling its source code. As an alternative way, you can resort to some distribution rolling release Y bleeding edge like Arch Linux, which should arrive in a matter of time if it hasn’t already. However, updating this component is rarely critical, especially on desktop systems where the user rarely interacts directly with it. Those who want to know all the details can consult the list of changes published in GitHub releases.
