SysVinit 2.90 Released With Fixes & Better Support For Newer Compilers

[rtfazeberdee]

Systemd in contrast is indeed very monotithic and aggregates many features that would benefit from being independent.

No matter how many times people make these "claims", it won't make it true

[sjukfan]

No matter how many times people make these "claims", it won't make it true

So how does someone use logind without systemd?

[starshipeleven]

Funny. Someone before you mentioned how straightforward sysvinit is, but it can't be straightforward is so many things are undocumented...

It's as straightforward as calling a script. The issue isn't the init, but the script (and what a script can actually do).

[starshipeleven]

So how does someone use logind without systemd?

Sorry, "how does someone use <random program> without <its dependencies>" is a bullshit argument, as it can be used on anything that isn't... wait for it... monolithic.

logind relies on features provided by its dependencies, you can remove them or clone them from systemd init to logind (making it more monolithic),

Yes ladies and gents, elogind is more monolithic.

[starshipeleven]

There are good alternatives to sysvinit and systemd out there. OpenRC is often mentioned, runit is another, minit, daemontools... The nice thing about all of those except systemd is that they play fairly well together on a single system.

Why you even have more than one init installed again? What's the point? Why is that "a nice thing"?

[moltonel]

Why you even have more than one init installed again? What's the point? Why is that "a nice thing"?

Because not every software package comes with the scripts for your favorite init system. The software may have complicated internal startup/monitoring and not wish to support multiple init systems. So it's nice when they can bring their init system, and you can plug that as one unit into your OS's native init.

Systemd can use sysvinit scripts, but it's not bugfree. I've experienced that first-hand professionally trying to get a well-tested sysvinit script to run under systemd, the error cases were not handled well under systemd, we had to write native systemd files and patch the underlying software to get back to sysvinit-era dependability. I've had less problems mixing openrc, sysvinit, and runit scripts, probably because those don't try as hard to be the sole source of truth as systemd does.

Don't get me wrong, systemd is really nice. It offers elegant solutions to many problems. But it has a "do things my way or get lost" mentality which can get troublesome. Custom solutions for logging, managing control groups, monitoring health, etc are possible under systemd but you have to fight for it. Subsystems like udev and logind that could (or used to) be independent projects get lumped into systemd, seemingly just to strong-arm people into using systemd (thankfully, systemd-less forks are maintained for both of those). It is these reasons, not some internal architechture, that make systemd monolithic. For better and worse.

[discordian]

Why you even have more than one init installed again? What's the point? Why is that "a nice thing"?

Everyone trying to hack him will do a facepalm, look again in disbelief... and force himself to get out of his system before they are challenged fixing his unbelievable mess?

On-topic: there really aint much ground between busybox for dead-simple systems and something more maintainable than sysvinit. good luck to those still depending on it.

[Bigon]

So how does someone use logind without systemd?

You don't. You use an other implementation of the login1 D-Bus API, like elogind

[Bigon]

* Horribly written probably. Did you check ? Sysvinit is actually very small, so only its age will make it horrible. Maybe you're thinking about the individual service scripts ?
[...]

The individuals initscript need to be taken in account when using sysvinit for sure.

And so is inserv that is/was used in most distribution to calculate the dependency graph of the LSB compliant initscript: https://sources.debian.org/src/insse...5.4/insserv.c/

[moltonel]

Why you even have more than one init installed again? What's the point? Why is that "a nice thing"?

Because not every software package comes with the scripts for your favorite init system. The software may have complicated internal startup/monitoring and not wish to support multiple init systems. So it's nice when they can bring their init system, and you can plug that as one unit into your OS's native init.

Systemd can use sysvinit scripts, but it's not bugfree. I've experienced that first-hand professionally trying to get a well-tested sysvinit script to run under systemd, the error cases were not handled well under systemd, we had to write native systemd files and patch the underlying software to get back to sysvinit-era dependability. I've had less problems mixing openrc, sysvinit, and runit scripts, probably because those don't try as hard to be the sole source of truth as systemd does.

Don't get me wrong, systemd is really nice. It offers elegant solutions to many problems. But it has a "do things my way or get lost" mentality which can get troublesome. Custom solutions for logging, managing control groups, monitoring health, etc are possible under systemd but you have to fight for it. Subsystems like udev and logind that could (or used to) be independent projects get lumped into systemd, seemingly just to strong-arm people into using systemd (thankfully, systemd-less forks are maintained for both of those). It is these reasons, not some internal architechture, that make systemd monolithic.