Since systemd-260 and later have been tainted by the slopmongers, and Linus won’t ban LLM-laundered contributions to the Linux kernel, I guess it’s time to resume hacking on the “initd” that I started putting together for NetBSD…

#ai #llm #slop #opensource #systemd #systemd260 #linux

1️⃣3️⃣ Here's the 13th post highlighting key new features of the just published v260 release of systemd. #systemd260 #systemd

systemd-vmspawn is systemd's wrapper around qemu, that integrates it nicely with various of systemd's interfaces and subsystems, while providing an interface closely resembling systemd-nspawn's.

There's one really useful switch systemd-nspawn has that systemd-vmspawn so far didn't:

1️⃣2️⃣ Here's the 12th post highlighting key new features of the just published v260 release of systemd. #systemd260 #systemd

D-Bus has been tremendously successful as an IPC system, but as you probably are aware within the systemd project we have been pursuing adding more and more Varlink IPC interfaces to our services instead – for a variety of reasons.

In v260 we added minimal Varlink support to one key component, that needs to be available during early boot, and where D-Bus is hence…

1️⃣1️⃣ Here's the 11th post highlighting key new features of the just published v260 release of systemd. #systemd260 #systemd

ARM laptops have recently started moving from the fringes of the Linux world more towards the middle. In the ARM world the nice ACPI-based auto-discovery of devices that PCs have is not really that common, and Devicetree reigns instead. While ACPI is somewhat OS independent, and hence can easily be provided…

1️⃣0️⃣ Here's the 10th post highlighting key new features of the just published v260 release of systemd. #systemd260 #systemd

As systemd gains more and more TPM support we increasingly run into problems with actual real-life TPM implementations. TPMs run non-trivial firmware after all, and … let's just say …, not all of it is of the highest quality.

When TPM operations fail, and we get a "clean" error back, then we can relatively nicely handle this, implement fallback code paths, and move on.

9️⃣ Here's the 9th post highlighting key new features of the upcoming v260 release of systemd. #systemd260 #systemd

If you deploy systems and services, then beyond the general lifecycle management that systemd always did you typically also want some form of metrics monitoring/observability. There are various approach to this, but the most popular ones all operate with local agents that pull metrics out of local services, and make them available for centralized collection (prometheus, …).

8️⃣ Here's the 8th post highlighting key new features of the upcoming v260 release of systemd. #systemd260 #systemd

In the 4th posting of this current series, we introduced the new .mstack/ directory type, for putting together service and container trees from stacks of overlayed directory trees and bind mounts, all in a self-descriptive directory.

In v260 there's also one major user of this new concept: the importctl tool gained a new "pull-oci" verb for downloading OCI containers. What it…

7️⃣ Here's the 7th post highlighting key new features of the upcoming v260 release of systemd. #systemd260 #systemd

Sometimes it's useful to bind a specific service to a certain network interface – all of it, at once. With v260 there's a new knob for that: BindNetworkInterface= can be configured in service units, and will cause all sockets of the service to be bound to the specified network interface, without a chance to use any other.

This is particularly useful in VRF contexts, …

6️⃣ Here's the 6th post highlighting key new features of the upcoming v260 release of systemd. #systemd260 #systemd

One of the now-standard files that systemd introduces is the /usr/lib/os-release file. It contains various fields with meta information on the OS and the OS image your system is running.

One of the fields in there is PRETTY_NAME= which contains the primary name of the OS for human consumption. It's a bit limited in some ways however. Given this is written…