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

[Raka555]

*sigh* Okay, here my thoughts as a mainline kernel dev, gcc dev, distribution builder and embedded dev...

From the perspective of a desktop distribution systemd is absolutely fine (to give it a nuanced note: it perfectly fits in all the desktop bloat ). It is a fire-and-forget thing. So it is easy to use, especially for users not really firm in Linux, well, just like Windows. And - you can twist and turn it however you like - it is widespread and a somewhat well defined standard. Though, from the perspective of a distribution builder it is not so funny anymore. That is the point where "not intended to cover all use-cases" comes into play. As an embedded developer I often end up putting whole Linux distributions into 8, 16 or 32 MiB sized flashes. And here systemd really is to big and may even end up eating cpu time. The old scripts did run just once, you know, the good old start/stop/restart/reload, while systemd has several running daemons. That is something you really see on a 600 MHz single- or dual-core ARMv5/6. But yeah, in that case you can switch to the good old sysvinit or similar. Problem solved. Wait a minute, no, the problem is not solved. Systemd becoming a standard is something that bled into a lot of other software. Some now have a dependency to systemd and if you want to use this software, you have to at least build systemd or worse, include it in you distribution. It also led to a lot of software dropping their init scripts and now you have to write all these. And there is another "issue" I see for a while now. Are there people who actually read these systemd files? A lot of these are mostly shell scripting "assigned" to the systemd recognized keywords. I mean, huh, okay ... so what was the reason to use systemd? To make it short: systemd is fine for desktops, questionable for servers/hpc, abysmal for embedded.

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.

[Akiko]

Yes, we have seamlessly moved from poorly maintained and barely working init scripts to poorly maintained and barely working systemd unit files. No surprise there:-)

Well, these poorly maintained scripts are execute very fast now. I can imagine that systemd even executes some of the shell scripting as JIT. Which means, that they wrote their own shell interpreter, which would be - uhm - insane? I really don't know, never looked into the sources. But knowing that Lennart Poettering is involved concerns me a bit. Though, he actually did nice stuff, kdbus for example.

I do trust the systemd peoples a bit more to get all that stuff right than random distribution developers writing init scripts for something they have hardly any idea how it actually works..

Just use a search engine of your liking and type in "systemd rand crash", maybe you even come across the famous Ryzen 3000 issue. Seriously, the init system was designed to to following simple things: run as pid 1, fork everything as a child process, never segfault. The smallest version of init you can write is just a couple of lines of C code and only includes open/close, read/write, a fork variant (vfork?) and maybe system. The most important point is the third one: never segfault. And there you really have to "keep it simple, stupid". Like I said, from the perspective "not a desktop system", systemd is questionable.

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.

Exactly ... that is also part of my "dependencies" statement.

[Raka555]

Well, these poorly maintained scripts are execute very fast now. I can imagine that systemd even executes some of the shell scripting as JIT. Which means, that they wrote their own shell interpreter, which would be - uhm - insane? I really don't know, never looked into the sources. But knowing that Lennart Poettering is involved concerns me a bit. Though, he actually did nice stuff, kdbus for example.



Just use a search engine of your liking and type in "systemd rand crash", maybe you even come across the famous Ryzen 3000 issue. Seriously, the init system was designed to to following simple things: run as pid 1, fork everything as a child process, never segfault. The smallest version of init you can write is just a couple of lines of C code and only includes open/close, read/write, a fork variant (vfork?) and maybe system. The most important point is the third one: never segfault. And there you really have to "keep it simple, stupid". Like I said, from the perspective "not a desktop system", systemd is questionable.



Exactly ... that is also part of my "dependencies" statement.

It reminds me of this article: http://ewontfix.com/14/

[tobias]

Seriously, the init system was designed to to following simple things: run as pid 1, fork everything as a child process, never segfault.

Sure. But is that design decision still relevant today?

The smallest version of init you can write is just a couple of lines of C code and only includes open/close, read/write, a fork variant (vfork?) and maybe system. The most important point is the third one: never segfault. And there you really have to "keep it simple, stupid". Like I said, from the perspective "not a desktop system", systemd is questionable.

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 :-)

[anda_skoa]

To make it short: systemd is fine for desktops, questionable for servers/hpc, abysmal for embedded.

I don't think one can simplify it to that level.

While "desktop" might work as a category, the other two are too much of a spectrum themselves.

Embedded, for example, covers a really wide range of devices.

On one hand it might be unnecessary overhead for devices with restricted resource, on the other hand, once you are in the area of having GUI and user configurability, it becomes really nice to have access to the systemd ecosystem.

It makes application development much easier of you can access system features through D-Bus, e.g. talking to timedated when the user changes the device time.

[wertigon]

As an embedded developer I often end up putting whole Linux distributions into 8, 16 or 32 MiB sized flashes. And here systemd really is to big and may even end up eating cpu time.

CPU time, doubtful. From a reliability standpoint it is better. From a space conservation standpoint... You have a point, systemd takes up ~16 MB of space, which is not that much for a 64 MB system. At the same time, perhaps here it would be possible to take a page from busybox and reimplement the systemd standard in a new, novel way, perhaps in a restricted setting?

Most Yocto builds take up ~50 MB and up these days, though poky-tiny only takes up 3.2MB + whatever the kernel size is. But yes, if you are that space constrained, FreeRTOS might even be a *better* fit. Otherwise, 16MB of NAND is becoming cheaper than 8 MB and soon the same will be true for 64 MB of NAND, at which point systemd is feasible.

https://wiki.yoctoproject.org/wiki/Poky-Tiny

It is also possible to make use of a busybox strategy to shrink down systemd with a single config file that allows for dependencies, but at 8 or even 16 MB, I think neither SYSV nor systemd is a good fit here as boot scripts can easily eat up 50kb-100kb when they have complex dependencies.

Systemd becoming a standard is something that bled into a lot of other software. Some now have a dependency to systemd and if you want to use this software, you have to at least build systemd or worse, include it in you distribution. It also led to a lot of software dropping their init scripts and now you have to write all these. And there is another "issue" I see for a while now. Are there people who actually read these systemd files? A lot of these are mostly shell scripting "assigned" to the systemd recognized keywords. I mean, huh, okay ... so what was the reason to use systemd?

Some valid points. Yes, systemd is definitely more than an init system. No it still is not perfect. It is better, but not perfect. Linux, however, is now entwined with systemd for better or worse. Which is also why I am saying, the battle is already lost.

It is not impossible to make a systemd clone that use a ton less resources though, but the entire systemd units concept? Here to stay, even in BSD land.

To make it short: systemd is fine for desktops, questionable for servers/hpc, abysmal for embedded.

No, systemd is fine for desktops and much better on both servers and embedded (provided you have the minimum 64 MB required). That's just the objective truth. No one is saying it is perfect though.

[F.Ultra]

Well, these poorly maintained scripts are execute very fast now. I can imagine that systemd even executes some of the shell scripting as JIT. Which means, that they wrote their own shell interpreter, which would be - uhm - insane? I really don't know, never looked into the sources. But knowing that Lennart Poettering is involved concerns me a bit. Though, he actually did nice stuff, kdbus for example.

Comments like the above is why it is so hard to take anti-systemd people seriously. You just imagine the worst thing you can and then assume that this is the case instead of actually looking it up and e.g in this case realize that systemd doesn't execute any script internally, it calls execve() just like any sane person/project would.

To make it short: systemd is fine for desktops, questionable for servers/hpc, abysmal for embedded.

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

[Raka555]

The time is ripe for a revolution against "Linux". Where "Linux" came to mean linux kernel, glibc and systemd and the bloatware technologies like flatpak/snap/appimage ...

[reba]

The time is ripe for a revolution against "Linux". Where "Linux" came to mean linux kernel, glibc and systemd and the bloatware technologies like flatpak/snap/appimage ...

Burn them all! For progress!

[andyprough]

or perhaps an asteroid that will wipe out all "sysv init /compile everything from source / don't use graphical tools only command line" dinosaurs?

No, the asteroid is not necessary. You will die out slowly and in the process you will make a lot of noise but still remain irrelevant.

Why don't you recompile kernel once more with few more flags, it will calm you down

LOL, "Join Date: Oct 2024". Abhors compiling and any disgusting person who would ever compile. It's like a meme has sprung to life.