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

[jacob]

Maybe one day they gonna add speed and simplicity to their codebase. But that's somewhere at the end of their big list of bullshit features.

That's why it was created in the first place. So that we don't need to control services through dozens of broken, slow and inefficient shell scripts, all running as root.

[Old Grouch]

That's why it was created in the first place. So that we don't need to control services through dozens of broken, slow and inefficient shell scripts, all running as root.

Many people agree that "control[ing] services through dozens of broken, slow and inefficient shell scripts, all running as root" is non-optimal.

What some do not agree with is that systemd and its associated 'ecosystem' is necessarily the optimal replacement. They are not idiots for disagreeing, as systemd might not be suitable for their use-cases. The developers and maintainers of systemd are quite clear that it is not intended to cover all use-cases covered by previous methods, which means that other ways are required for the use cases not covered. Systems using the linux kernel, but not systemd, are not rare. Systemd is suitable for many things, but not everything.

[ahrs]

rc.d > sysvinit
openrc > rc.d
upstart > openrc
systemd > upstart

The init system that hasn't even had a release in years is better than the actively maintained OpenRC. That's hard to believe. The last commit to their repository was in 2016:

https://code.launchpad.net/upstart

The only distro that's still left using Upstart is ChromeOS as far as I know.

[tobias]

What some do not agree with is that systemd and its associated 'ecosystem' is necessarily the optimal replacement.

Oh, it is absolutely not optimal, it is just the best we have right now.

They are not idiots for disagreeing, as systemd might not be suitable for their use-cases.

People are stupid for claiming that there is no way under the sun that systemd could be better at any metric than whatever they use right now. There are lots of those.

The developers and maintainers of systemd are quite clear that it is not intended to cover all use-cases covered by previous methods, which means that other ways are required for the use cases not covered.

They did indeed drop a couple outdated use cases to enable tons of new use cases non of the others support. Just look at all those immutable distributions, logind improving the security story, homed enabling key eviction on suspend, pervasive logging in a tamper-resistant way, systemd-repart, tmpfiles, sysusers and all the workmto finally get TPMs supported. Many of these had a huge impact on even more distributions than those that use systemd as PID1.

Systems using the linux kernel, but not systemd, are not rare. Systemd is suitable for many things, but not everything.

Nobody claims that as far as I am aware, but neither is any of the other systems out there. And systemd does have significant advantages over many of those IMHO. Plus it is one place where a interested developer can go to improve the plumbing layer of linux across a huge spectrum of distributions. So systemd is where all the developer mindshare is right now. That is going to be hard to change -- till something better comes along.

But nowadays you can not write an init system that is better, it has to either integrate into the systemd plumbing layer or provide a better one on its own.

[jacob]

Many people agree that "control[ing] services through dozens of broken, slow and inefficient shell scripts, all running as root" is non-optimal.

What some do not agree with is that systemd and its associated 'ecosystem' is necessarily the optimal replacement. They are not idiots for disagreeing, as systemd might not be suitable for their use-cases. The developers and maintainers of systemd are quite clear that it is not intended to cover all use-cases covered by previous methods, which means that other ways are required for the use cases not covered. Systems using the linux kernel, but not systemd, are not rare. Systemd is suitable for many things, but not everything.

I don't think that anyone (reasonable) claims that systemd is optimal for everything. It's meant to replace the old script-based ecosystem and its associated environment of non-integrated tools. It does that rather well. It's not the only way it could have been done, but it's the only one someone actually developed, made usable and marketed. But yes, systems that use the Linux kernel and not systemd do exist and are not rare. One of them even happens to be the most widely used OS in the world, they call it Android

[ahrs]

But nowadays you can not write an init system that is better, it has to either integrate into the systemd plumbing layer or provide a better one on its own.

You can, you just have to change all of the applications again. Apps didn't have Systemd support overnight, this was added overtime. Of course you may find yourself facing some resistance from maintainers that are less interested in whether or not it works better than Systemd and more interested in "I have to maintain this".

[DrYak]

SysVinit 3.11 is out today with a new "important feature" addition...

Oh boy, I can't wait for when they release SysVinit for Workgroups 3.11 upgrade later!...

[wertigon]

What some do not agree with is that systemd and its associated 'ecosystem' is necessarily the optimal replacement. They are not idiots for disagreeing, as systemd might not be suitable for their use-cases.

I am having a hard time thinking of any specific SYSV use case that is not already covered by systemd, these days. We even use it in embedded programming to achieve a much more reliable soft realtime scheduling via systemd timers where I work. systemd is about as slow as a Lamborghini, while SYSV is more like a VW Beetle.

I am, however, not having a hard time thinking of a specific use case that systemd can do, and SYSV simply cannot. Those are a dime a dozen.

[Akiko]

*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.

[tobias]

... 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.

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

At least I can add an override myself and that is not constantly getting undone whenever distributions updating the package containing the unit file. And the security features I want are easy to add and implemented by systemd devs and not included into the init scripts themselves. 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..