SoylentNews is people
SoylentNews
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, Informative) by liquibyte on Saturday September 17 2022, @12:51PM (2 children)
They are not accomodating systemd per se, the developers upstream have however. In order for some software to run systemd must be seen. Devuan is a fork of Debian and those that decide things there insisted this software was a must have feature to the great consternation of the rest of us that don't have enough time to roll our own distros. I remember when this fiasco started and jumped ship early over to Gentoo. Alas, those devs started consistently breaking stuff over the years so I had to, once again, find something else. Devuan it is. I'm glad I did even though I didn't anticipate how much I"d need it later. I just built a CNC machine and run it with LinuxCNC which uses Debian as its OS, which by default ships with systemd. Turns out that while Chimaera doesn't have the package linuxcnc-uspace but Daedalus does. So, a repository change later I have a systemd free machine. By the way, I hate the naming conventions that all distros use, it's assinine. Name your program, use a consistent numbering version system that doesn't jump from v14 to v102 overnight and stop with the silly nicknames already.
(Score: 2) by Unixnut on Saturday September 17 2022, @01:35PM (1 child)
Meh, IMO Linux went from a toy OS in the 90s, to approaching a very reliable, useful, successfully Unix like system, to regressing back towards a toy OS in the last 10 or so years, systemd being one of the more egregious examples of what seems to be a general downtrend in the quality of Linux.
FWIW, the only Linux I still use is Devuan, pretty much only on desktops (due to the better support for graphics HW), and moved my servers and processing machines over to FreeBSD.
At work, there are still many Linux servers I handle, but new project designs and deployments for servers are pretty much FreeBSD nowadays in my world.
(Score: 2) by aafcac on Saturday September 17 2022, @05:32PM
As a FreeBSD user, it does kind of sadden me to see what's becoming of Linux. It's not really surprising with so much development spread over so many different projects though.