systemd's mkosi-initrd Talked Up As Better Alternative To Current Initrd Handling--Phoronix:
Red Hat engineer and systemd developer Zbigniew Jędrzejewski-Szmek presented on Monday at the Linux Plumbers Conference on a new design for inital RAM disks (initrd) making use of the new systemd mkosi-initrd project.
The mkosi-initrd approach paired with systemd system extensions is a fundamental shift from expecting initrd images to be built locally on user systems to something that can be done by distribution vendors with their build system. This can allow for better QA, embracing various modern security features, and more manageable initrd assets. Zbigniew summed up his LPC 2022 talk as:
Distributions ship signed kernels, but initrds are generally built locally. Each machine gets a "unique" initrd, which means they cannot be signed by the distro, the QA process is hard, and development of features for the initrd duplicates work done elsewhere.
Systemd has gained "system extensions" (sysexts, runtime additions to the root file system), and "credentials" (secure storage of secrets bound to a TPM). Together, those features can be used to provide signed initrds built by the distro, like the kernel. Sysexts and credentials provide a mechanism for local extensibility: kernel-commandline configuration, secrets for authentication during emergency logins, additional functionality to be included in the initrd, e.g. an sshd server, other tweaks and customizations.
Mkosi-initrd is a project to build such initrds directly from distribution rpms (with support for dm-verity, signatures, sysexts). We think that such an approach will be more maintainable than the current approaches using dracut/mkinitcpio/mkinitramfs. (It also assumes we use systemd to the full extent in the initrd.)
See the talk or go look at the PDF slides.
(Score: 2, Interesting) by Anonymous Coward on Friday September 16 2022, @10:34PM (1 child)
It is the unicode version of init, full of vulnerabilities...
BSD looks better every day
(Score: 2) by aafcac on Saturday September 17 2022, @05:35PM
Apart from hardware and commercial software support, FreeBSD in particular has been good for decades. I remember when I first installed it, the main things to worry about were drivers and being unable to use flash and shockwave. Most of the rest of things were pretty solid.
And now with some of the other options that are basically just BSD+GUI as an initial install, it's just that much easier. I just bought a new computer and I didn't even bother to think about whether the drivers were there or not as I haven't had driver issues in years at this point.
That being said, I don't think that sticking with the old for the sake of it is a good idea, but I do think that this business of conglomerating more and more into a single system shouldn't be done without a whole lot more care than's being done. The init system can be a bit complicated at the deep end, but it is flexible and it seems to work out rather well in most cases.