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) by sjames on Saturday September 17 2022, @10:17PM (6 children)
I don't see systemd booting any faster in practice than a well done SysV. It also doesn't seem to have a way to deal with things that should ideally happen but if it can't I'd rather have the rest of the system come up so I can log in and debug it. For example an auxiliary data disk. The ability to quickly hide what may be the only useful debugging information to show a pretty picture doesn't sound like much of a feature.
But as far as initrd goes, the machine really doesn't spend long in that environment anyway unless something has gone horribly wrong. Not to mention a few cases where the only reason systemd was even feasible was that the initrd using a more standard init was able to do the things systemd simply refused to do correctly before letting systemd have at it.
The whole thing smells like change for change's sake likely to introduce system breaking bugs for years to come in what was once a well debugged subsystem. If you really need a one vision fleet, nobody is stopping anyone from rolling up an initrd they like and deploying it everywhere. If you have a big enough fleet to need that, it's not a big deal to do and you quite likely have a vision that differs from the "one true systemd way".
Linux came to be everywhere because it is flexible and versatile, not because it offers a one size fits none "solution". Notably it's a big part of why the WinPhone is dead and Android is everywhere. The world just doesn't need yet another IBM/RedHat solution looking for a problem.
Note, my comments on boot time are based on my personal best (using LinuxBIOS and a DiskOnChip in an old AMD board) of 10 seconds from power on to a command prompt. Systemd didn't even exist then. If it had, I would have needed to do a lot more work to throw it out in order to get that boot time.
(Score: 2) by JoeMerchant on Sunday September 18 2022, @02:46AM (4 children)
>I don't see systemd booting any faster in practice than a well done SysV
That may be the most damning observation of all: in practice most systemd implementations are done better than most SysV implementations, for whatever reasons.
The Pi 2 with its limited resources magnified the difference, but the difference is there on all systems.
>The whole thing smells like change for change's sake likely to introduce system breaking bugs for years to come
I read a good bit of security theater in the presentation, and that will definitely make life harder with questionable benefits.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by sjames on Sunday September 18 2022, @03:50PM (3 children)
Probably because most Linux systems are booted infrequently enough that nobody cares that much about boot time (within reason) in most applications.
Kind of like way back in the old days, Tandy's PC clone booted to DOS nearly instantly (by keeping the boot image in ROM). That feature didn't generate much excitement even though DOS needed much more frequent reboots.
(Score: 2) by JoeMerchant on Sunday September 18 2022, @04:50PM (2 children)
>most Linux systems are booted infrequently enough
Depends entirely on application. I boot my TV system once a month and I don't care much about how long that takes, my desktop once or twice daily and that already matters, laptops even more often and I put up with the vagaries of sleep mode to accelerate the restart times there.
Excitement varies by audience a lot. I will note that even after I have had Linux on my desktop for 20+ years, and on the TV for 15, my wife and children still use Windows or iOS or Android for their "daily driver" computer OSs. My wife is ready to make the jump to Ubuntu but her 5 year old Windows laptop just won't die. One son could use Linux instead of iOS for everything he does, but similar situation with the familiar old iMac, and the other actually has an Ubuntu desktop but he spends 90%+ of his time on Android.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by sjames on Sunday September 18 2022, @06:43PM (1 child)
(Score: 2) by JoeMerchant on Sunday September 18 2022, @08:56PM
Well, two dozen colleagues at various sites around the country have settled on "vanilla Ubuntu" as the flavor of choice for our products, so I end up with systemd drain bramage at work anyway regardless of what I choose to struggle with at home.
Actually, at home I rarely interact with systemd as anything but a user. It's my work stuff that has me fighting with services, dependencies, X can't run as root, Y has to run as root headaches.
For home I'm presently messing around with Raspberry Pi Pico Ws which are cool for their low power requirements... I have one running on a solar cell in the yard running a 24-7 available webserver that can activate an ultrasonic dog whistle on demand... Unfortunately micropython, while easy to get going, isn't terribly stable when running threads on both cores.... And the C SDK stack is.... Formidable.
By comparison the home Ubuntu and Raspberry Pi OS boxes are pretty much just appliances.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 3, Insightful) by maxwell demon on Sunday September 18 2022, @11:25AM
Idon't think so. There's surely a plan behind this. I just doubt the plan is to the benefit of the users.
The Tao of math: The numbers you can count are not the real numbers.