Systemd 243 Is Getting Buttoned Up For Release With New Features & Fixes

[F.Ultra]

The take away from the whole AMD RdRand / systemd problem is that it is good to have alternatives when things go wrong.

Like Intel?

[Templar82]

I think you're trying to end the wrong discussion because this one is about RDRAND being AMD's fault, not systemd's.

I think you are in the wrong thread, this one is about systemd releasing a patch to fix their software not booting on the latest AMD processors.

[jacob]

It is still good to have an alternative...

It would be good but at the moment there is no alternative. The likes of openrc, runit etc. are in no circumstances alternatives to systemd. These are "init" systems for *NIX operating systems, that is OSes driven primarily through command line, configuration files and scripts. Whereas systemd is designed to move Linux to a post-Unix era and become a modern OS driven primarily through APIs. As such, these "init" systems are not an alternative to systemd any more than MS-DOS is an alternative to Windows 10. So yes, it would be useful if there was an alternative to systemd that fulfilled the same objectives and exposed the same interfaces, but I'm not aware of any project like that, not even in development.

[andyprough]

Whereas systemd is designed to move Linux to a post-Unix era and become a modern OS

One ring to rule them all? And in the darkness bind them? Steve Ballmer, is that you?

[jacob]

One ring to rule them all? And in the darkness bind them? Steve Ballmer, is that you?

You can't provide a robust, predictable, fully featured platform for third-party end-user applications until you have One Ring To Rule Them All. The only alternative is fragmentation and incompatibility not just between distros, but between individual users, where upstream developers basically can't assume anything and therefore can't implement and test anything. Linux has, rightly, one true system call interface, one true memory manager, one true threading library, one true executable format and for the same reasons it absolutely needs one true service and event manager. We don't need Steve Ballmer to realise that, Captain Obvious will suffice.

[polarathene]

What made it break is actually besides the point. The fact is that it is much more prone to breakage than less complex init systems.
The "insane" part is that its doing the things listed below (and probably losts of undocmented things) which "sane" init systems do not do.

So...why are you using an x86 CPU? Why not switch to a less complex ARM MCU? Or go with Atmel 8-bit controller? You'll miss out on some advanced functionality, but the hardware is simpler, so there is less breakage right.

If a company sells you a product, like I dunno, say a Raspberry Pi 4. And you naturally expect that you can use any of your USB-C cables to power it since that's one of the exciting improvements touted by that release. And then you find out, that 5/6 of the USB-C type cables don't actually work with the product because of a hardware design flaw... who's fault is it? Is the Pi4 exempt somehow? Do we throw the blame at USB-C instead for having the different variants which meet the needs of users based on cost/features, not unlike the variety of CPUs and RAM or Disk products out there with their ample variety and nuances?

If hardware is the cause of the breakage, you don't blame the software that is actually doing the correct thing? The batteries ran out on my wireless mouse, therefore Linux sucks, it's too complex, shipping all those drivers in the kernel, I'm going to a sane OS where it keeps it simple and I download ONLY the drivers I need! *cough*

[polarathene]

And yet, systemd hasn't addresses any of the problems in that article.

> Unfortunately, it also gets the other properties, including bringing down the whole system when it crashes.

How often is that occurring? Have any statistics? Along with ones where systemd usage is replaced by alternatives with how often they crash and the impact that has, in addition to any other issues that were run into by not using systemd.

> On a hardened system without systemd, you have at most one root-privileged process with any exposed surface: sshd. Everything else is either running as unprivileged users or does not have any channel for providing it input except local input from root. Using systemd then more than doubles the attack surface.

Actual examples? And what, doubles as in from 1 to 2? Gee... that's massive. Are there reports of security focused systems that happen to use systemd proving to have been vulnerable where using alternatives would have avoided the vulnerability and what would the impact have been in using those alternatives instead? Would they not have had their own vulnerabilities that didn't also impact systemd equivalents, was there larger room for error in maintaining a variety of alternatives that are developed/managed separately?

> Unfortunately, by moving large amounts of functionality that's likely to need to be upgraded into PID 1, systemd makes it impossible to upgrade without rebooting. This leads to "Linux" becoming the laughing stock of Windows fans, as happened with Ubuntu a long time ago.

Odd... I've updated plenty of times just fine without rebooting. The only time that I've needed to reboot tends to be because of kernel updates just like the article mentioned as an acceptable reason. Again, please provide more information on when this turns out to be a real problem to systemd users vs using alternatives and the drawbacks that brings.

systemd wasn't mass adopted for no good reason, it solved problems, provided value. You can write articles to point out some bad things for pretty much anything, the article is biased in not pointing out the benefits of systemd over alternatives which are equally unlikely to fix their own issues that systemd resolves(if it didn't, distros would not all continue to use systemd).

The windows update article is ridiculous, the author doesn't seem to be aware of what they're talking about or are intentionally conveying misinformation. How does using an alternative to systemd improve that? The package updates and distro upgrades are still going to be there for numbers, reboots or at least restarting certain processes(such as ones that may impact your DE session) is still going to be required to use the updated version of.

Seriously.. you're not making a good case here.

[polarathene]

I think you are in the wrong thread, this one is about systemd releasing a patch to fix their software not booting on the latest AMD processors.

Because of a hardware flaw.. Look at this https://www.phoronix.com/scan.php?pa...-Systemd-Maybe

And note how it specifically points out that systemd is just calling a hardware instruction, it's the CPU hardware not doing it's job correctly(which is being patched via a BIOS update).

systemd PR that caused it on newer releases was from working around a related bug in AMD hardware:

https://github.com/systemd/systemd/pull/12536/commits/1c53d4a070edbec8ad2d384ba0014d0eb6bae077

Which wouldn't have made it into Ubuntu 19.04. Why it didn't happen in 18.04 or 18.10 is because the usage of that hardware instruction arrived afterwards in systemd:

https://github.com/systemd/systemd/issues/11810#issuecomment-489727505

So again.. this is not systemd bug, it's the result of using a hardware instruction when available(not unlike if you were to improve crypto performance by using hardware AES-NI support, or SIMD for optimizing your code), but that hardware not performing the instruction correctly.

[andyprough]

You can't provide a robust, predictable, fully featured platform for third-party end-user applications until you have One Ring To Rule Them All. The only alternative is fragmentation

What you desire already exists. Walk into your nearest retail store and any salesman will be happy to sell you a Windows or Apple system. You are never going to get unification within libre software, however. By its very nature there will always be tremendous diversity.

[jacob]

What you desire already exists. Walk into your nearest retail store and any salesman will be happy to sell you a Windows or Apple system. You are never going to get unification within libre software, however. By its very nature there will always be tremendous diversity.

The day that Windows or Apple is open source I will happily do that. But unless that happens, we need Linux to offer the same level of integration as they do. I use Linux because it's libre, not for the privilege to have to write duct tape scripts and rely on unixy kludges to do what should Just Work(tm) on every modern OS. There is no reason why libre software should be an intractable mess. There is no reason why there should not be an expectable, consistent API for applications to set up timers and jobs (/etc/crontab is not an API). There is no reason why there should not be an expectable consistent API to set up and monitor network interfaces (ifconfig is not an API). Etc etc etc etc.

Bottom line: unless you insist that you must have "choice" in defining your own system calls or your own VFS interfaces, then there is no fundamental reason why there should be "choice" between various broken and dysfunctional service managers either. The fact that the former is part of the kernel and the latter isn't is a mere historical accident that doesn't imply anything by itself. I see systemd as part of "The" operating system in the same way as the kernel's core parts, drivers, network stack or indeed the historical userland (shell, grep etc.). The fact that Unix didn't have systemd doesn't worry me. What worries me is that Linux is still lacking One True APIs (not command line utilities or config files or "choice" between dozens of me-too implementations that no-one can rely on being present) to do things like managing user accounts, setting up authentication policies, configuring VPN etc.