Honest question, is your opinion that we should have been stuck with something like SysVinit just so it's more convenient for the BSDs, while the likes of RedHat contribute the majority of the work?
And if yes, can you point to an example of *BSD doing something similar while pushing their platform forward?
This is a loaded way to frame the question, some of us were just fine being "stuck" with SysVinit. I try not to get dragged into systemd flamewars because life is too short but it's disingenuous to claim that before systemd init systems were some kind of inescapable hellscape.
I administrate multiple systemd-based linux distros, FreeBSD servers and buildroot-based embedded systems and I can tell you that systemd still gets in my way regularly while the sh-based init systems tend to Just Work and are very simple to understand and maintain.
Of course I know that a big reason is that I'm very familiar with un*x system administration and the gotchas of shell scripting while systemd is probably more approachable for somebody who doesn't want to learn arcane knowledge about chmod and file locking and setuid and symbolic links but I think that explains why there's still so much pushback against systemd all these years later: people who care about init systems know enough about them that systemd feels over-engineered and unnecessarily complex while not bringing a lot to the table.
Never once in the past years of running systemd have I thought "oh man, I sure am glad I'm using systemd and not an old SysV/BSD init system!". Not a single time. I did have multiple occurrences of systemd breaking stuff after an update though.
> systemd still gets in my way regularly while the sh-based init systems tend to Just Work
For me systemd based systems allow me to have declarative, portable unit files where init scripts don't. They allow me to reliably monitor and restart services, they shut things down properly instead of just force killing as many init scripts end up doing.
I instantly know how to manage most major distros now that systemd's common among all of them, have no hesitation of writing a proper service file even for minor tasks and I get a ton of functionality 'for free' too.
Init scripts were always a poor-quality mess, non-portable among systems, non-consistent, non-deterministic. If your experience differs there's still plenty of non-systemd choices out there. They're not as prevalent as systemd ones, but that's because the people who sit down and actually write the code we all use find the services systemd provides valuable.
Arguing that the advantage of systemd is portability is rather bold!
And even if portability was the point I'm not sure I see the big deal. Writing an RC script from scratch if the software you use doesn't provide it is generally trivial. The vast majority of the time you wouldn't have to do that anyway as it ships with your OS's packages anyway. Sure, systemd might be "tidier" with its standard APIs and whatnot but it's also a lot more complicated and opaque than a bunch of shell scripts running one after an other. And if you're serious about sysadmin you'll have to learn shell scripting one day or the other anyway.
>Init scripts were always a poor-quality mess, non-portable among systems, non-consistent, non-deterministic.
They're non-portable, that much is true but so is systemd, that's a weak argument. If everybody had adopted FreeBSD-style init it would be equally as portable, it's a self-fulfilling prophecy. With that logic we should just all ditch un*x and start running Windows since most people already use that anyway.
The rest is nonsense. It's poor quality, non-consistent and non-deterministic if you write them that way. Sure, shell scripts being turing-complete opens the door to a lot of nonsense if people go wild and gives more latitude for very sloppy code but it doesn't have to be that way.
>the people who sit down and actually write the code we all use find the services systemd provides valuable
Systemd has been pushed down everybody's throat for a while now, saying retroactively that people use it because they find it valuable is a bit of a stretch. I'm sure many of them use it because that's what's available. I wrote a bunch of systemd unit files myself, I assure you that it wasn't meant as an endorsement.
Besides it's only one side of the equation. Maybe it's nicer for the people writing the unit files, doesn't mean that it's a good thing for people actually having to use them. I'm sure many software maintainers would prefer if everybody ran the same OS on the same hardware with the same use cases but that's not how the real world works.
> Arguing that the advantage of systemd is portability is rather bold!
It's merely a statement of fact, systemd services accept the same set of commands across distros, which is rather unlike SysV.
> It's poor quality, non-consistent and non-deterministic if you write them that way.
That's a bullshit statement, because everything fits it. Of course everything is great if you make it great. And?
The point is that systemd's declarative nature makes it hard to screw up services and even badly written ones will get enough common functionality for free that they'd be usable.
> Systemd has been pushed down everybody's throat for a while now, saying retroactively that people use it because they find it valuable is a bit of a stretch.
Systemd got adopted because people generally found it valuable enough to adopt over what they had before.
> Maybe it's nicer for the people writing the unit files, doesn't mean that it's a good thing for people actually having to use them
Matter of opinion, but I happen to think that having a uniform set of commands working at work and at home is nicer for users too, over the patchwork of scripts that SysV was across the various distros.
I don't think we should have stuck with something like SysVinit, there's definitely room for improvement, but saying "it's either SysVinit or systemd" is a false dichotomy.
If I was approaching building an init system I'd make a better language for writing init scripts than bash, some kind of interpreter that processes mostly declarative init files, sets things up, and then exits. An incremental improvement that works with existing systems instead of putting a whole bunch of new (generally un-audited) code into PID 1, with all the security implications that implies.
Redhat may contribute the majority of the work but they're also very good at positioning themselves so that outsiders can't really contribute any work, or get any independently developed standards implemented.
How can people replace SysVinit without "doing their own take on EEE"? Your alternative approach is still not going to be compatible with SysVinit either, not to mention it being strikingly similar to systemd.
Archlinux had their own non-sysvinit system (which went away in favor of systemd) as does voidlinux (runit based) and alpine (OpenRC) today.
The problem is less the init system itself, but applications that depend on a specific init system [1] (gnome used to be a major source of contention in that regard).
That's sort of the complaint, why I accused them of "doing their own weird version of EEE". When faced with a choice of "make everybody else do a whole bunch of work so that they're not forced to use your entire project-umbrella" or "make some minor changes to our architecture so things aren't as tightly coupled" they almost always choose the one that forces you to use systemd.
To the extent that you believe that free software development should work such that random people on internet forums dictate the architecture to the people who are doing the work, and instead of writing their software to solve problems that actual users have, they should comply with these whims, you better prepare to be disappointed.
Is applications depending on systemd particularly a bad thing? If we don't want applications to use non-SysVinit features, we might as well keep using SysVinit.
>How can people replace SysVinit without "doing their own take on EEE"?
By not tightly bundling their init with other OS components, by not having GNOME desktop somehow depend on what init system you're using (as opposed to services running under that init system).
Also you know how shell scripts have `#!/usr/bin/env bash` at the top of them? Well the reason why my hypothetical init system would be compatible with SysVinit is because instead of `#!/usr/bin/env bash` it would have `#!/usr/bin/env new_init_language` at the top of it. 'new_init_language" could implement almost all the same features that systemd unit files do.
> If I was approaching building an init system I'd make a better language for writing init scripts than bash, some kind of interpreter that processes mostly declarative init file
Guess what systemd does?
> sets things up, and then exits
And that's the crux of the issue isn't it? Because on modern systems, things need setting up and tearing down all the time.
> things need setting up and tearing down all the time.
Well not really, that's an artifact of systemd's over-engineered design. There's nothing stopping you from tearing something down from an init script or doing more complicated dependency management using the CLI as your RPC mechanism (but red hat needed a reason to use their in-house RPC mechanism).
Honestly something like systemd could be pretty reasonable if it wasn't created with the express intent of "combating fragmentation". Not that there aren't a whole bunch of technical and architectural issues with it, but still.
> There's nothing stopping you from tearing something down from an init script
Except most init scripts I've seen are rather brittle and only "work" if the PID dance is exactly as the author predicted, are not declarative and hard to debug.
I don't want to go back to init scripts, for all systemd's faults, the past was worse.
Using the CLI as my RPC mechanism etc. just sounds like I should spend a bunch of time doing work that systemd can do a better job of managing for me.
