SysVinit 3.11 Released With An "Important Feature" At Long Last

[TheMightyBuzzard]

All these things he mentioned as "bloat" are normal parts od desktop linux today.

Yeah, I'm pretty sure that's why he mentioned them. I very much doubt he'd care if they were only part of your desktop or even just one distro.

[Nempk]

Got it wrong, though.

I prefer speed and simplicity of systemd over UNIX neckbeards' bloated, slow monstrosity of impotent tools and unsound shell scripts, thank you very much

"speed and simplicity of systemd"

simple != easy.

"I prefer speed and simplicity of Windows over *nix neckbeards slow monstrosity of impotent tools and unsound shell scripts" ahhh argument

[intelfx]

"speed and simplicity of systemd"

simple != easy.

I never claimed that simple == easy, don't put words in my mouth. I said what I said.

[intelfx]

In theory, yes. In practice, "lol fu".

Way too many cultist userspace programmers have made their code dependent on one specific init system when it has absolutely no reason to be. That should never have happened with anything except system utilities that deal directly with the systemd init system and no other. That's not systemd's fault but it absolutely is the fault of its cultists.

Name one such dependency that has no technical or organizational reason to be there. Otherwise I call bullshit on your "systemd cultists" whining.

[oiaohm]

Also memory/storage limited environments sometimes uses an alternate libc like musl-libc.
You can not make systemd work with the alternate libc's short of rewriting parts of systemd to not use glibc specific features.

There is more to the story.

https://catfox.life/2024/09/05/porting-systemd-to-musl-libc-powered-linux/

https://code.atwilcox.tech/sphen/scaly/systemd/-/commits/adelie-v256

Yes people have done musl-libc ports its less than 40 patches to make systemd work.

Not only do you have remove glibc specific features you have to support specific features of the alternative libc you are using. C and Posix standards don't define everything you need.

Yes the patches show that over 99% of systemd is in fact libc neutral. Yes that less than 1% means the complete thing refuses to work.

Of course the above musl patch set has the problem that it takes out glibc stuff and put in musl stuff so effectiving breaking building this patched version of systemd for musl on glibc due to now it using musl specific features.

libc items like it or not are not neutral items.

[mobadboy]

In theory, yes. In practice, "lol fu".

Way too many cultist userspace programmers have made their code dependent on one specific init system when it has absolutely no reason to be. That should never have happened with anything except system utilities that deal directly with the systemd init system and no other. That's not systemd's fault but it absolutely is the fault of its cultists.

sucks to suck, man

systemd, the umbrella project, provides tons of individual components and features. why not take advantage of whats available, when it reliably works? systemd and its many projects revolutionized and continue to revolutionize linux for a reason.

[moonwalker]

Sorry but I don't need neckbeardctl to control my neckbeardd

As much as I personally enjoy systemd, I had to upvote this pearl

[ahrs]

Sure. But is that design decision still relevant today?



So we have a few useless lines of C code and run those as PID1 and run the interesting stuff (e.g. service management) as PID2. How does that make the overall system simpler?

I care that my system as a whole runs fine. If the service management crashes I will need to reboot. Which PID service management has is not important.

But let's assume we have a simple PID1 that starts service management and the service management crashes. What now?

1. PID1 reboots the system when PID2 stops. So PID2 crashing effectively reboots the system. That is not much different from PID1 crashing itself
2. PID1 does nothing. The system is dead now and I need to turn it off.
3. PID1 restarts service management... that means PID1 is not minimal anymore though. We are on a slippery slope towards moving the service management into PID1 :-)

PID2 in this scenario would be your process supervisor like supervise-daemon, or Runit, etc. PID3 is the thing that will crash. All of the same "must never segfault" things apply to your process supervisor and if you're not using one then "PID1 reboots the system when PID2 stops. So PID2 crashing effectively reboots the system. That is not much different from PID1 crashing itself" is probably the correct thing to do.

[ahrs]

Of course the above musl patch set has the problem that it takes out glibc stuff and put in musl stuff so effectiving breaking building this patched version of systemd for musl on glibc due to now it using musl specific features.

Lennart has already said he doesn't want this anyway. He thinks Musl should do what Glibc does.

It's easy to support both with an #ifdef mess or #include <musl-compat.h>, etc but when upstream doesn't want it, from the perspective of the patch maintainer it's easier to maintain by ripping out all of the Glibc stuff.

[Akiko]

Sure. But is that design decision still relevant today?

For the common user? Nope, definitely not. But Linux is one of the rare software pieces that basically runs everywhere, and promotes this, too. So for niche systems it is relevant. And it is not helpful if a lot of software you need to build a working distributions migrates away from "runs everywhere" because of a single software that tries to be everything. You end up with a kernel that runs everywhere, but can not get a working userspace anymore. I really try to take all scenarios into account. And the "runs everywhere" approach of Linux is still pushed forward. Just look at the RT extension which is becoming mainstream now. Now you can do funny realtime stuff on "bloated*" micro-controllers. (*ARMv7/ARMv8 based micro-controllers able to run "normal" kernels)

With a million daemons running in the background?

systemd needs to be exorcised. Waste of CPU power and memory.

Oh come on, this is just not true. Depending on your configuration you run 3 to 10 systemd daemons. This is absolutely nothing for a desktop system, but something you feel on an embedded system. In my workstation journald, udevd, logind and the user specific part already eats about 33 MiB of RAM. For an embedded system this is absolute overkill. If you login into a build of a yocto-tiny system you can see that your whole running system eats about 10-20 MiB RAM (depending on the Yocto release, there is quite a difference between sumo, kirkstone and the upcoming styhead).

Comments like the above is why it is so hard to take anti-systemd people seriously.

Wow, that got "interesting" quite fast... I am NOT anti-systemd. I just do not jump into hypes and take everything without a critical look into it. Let me get you some examples:
I am a C++ developer for decades now, even teaching c++20 and C++23. I love it. But man, do I hate some aspects of C++, like default constructors and operators or even implicit conversions. I do Rust programming and yes, I see the benefits, and some are really good, but man do I hate the over-complex syntax (async Rust) and the runtime bloat (from the perspective of embedded) and the over-reliance of online hosted crates. Now after the .io top level domain may be going away I hope some more people see why this is not a good idea. I mean after cpan, npm, pypi are now good malware/adware providers I thought people understand this, nope. After left-pad fucked the whole world, nope... Okay, back to topic. I love coding using Zig. You know, having no runtime (just attach to kernel APIs) is great, the buildsystem being part of the language itself is great, but man do I hate it having no constructor/destructor mechanism to do RAII. defer is nice, but still is not enough. See? I try to use my brain and try to understand the pros/cons.

I have no experience with embedded, but for servers/hpc, systemd is a godsend.

Okay, so let me tell some of my experience as a developer who worked at one of the biggest Linux distributors building professional distributions for (at that time) unique systems. In my office back then I was surrounded by a AlphaSever DS20 and DS20E, HP C3750 and about 2 years ago I killed my HP C8000. I was surrounded by AMD Sledgehammer engineering samples and UltraSparce systems. I had remote access to SGI Altix systems with 512 and 1024 CPUs (Itanium) to investigate and fix bugs. We had a bug where the customer reported this: SGI Altix 1024 CPUs, 1024 GiB RAM, runs HPC application over weeks, highly tuned to run with exactly 1024 threads, but sometimes a CPU runs two threads and another runs nothing, the HPC runtime increased about 25% because of this ... please fix this scheduling issue, because CPU time is expensive.

To make it short: On HPC system doing serious work, running for weeks or months, you really want a predictable runtime behavior. Having daemons running on the system, which start to do some work like deleting or swapping out journals and eating into your IO or CPU time can become a nightmare. This is the reason why running systemd on a HPC system may be a bad idea. And yes, I know this is an extreme example. But I want to demonstrate you, that I do not throw bullshit around. I tell this, because I encountered these issues. I really try to see the good and the bad.