As a FreeBSD user I find this kind of comment hilarious given I see Linux specific code littering upstream open source projects with no thought for other platforms on a regular basis. I occasionally see resistance to fixing these issues as well.
I don't presume to know if EEE is Microsoft's strategy here, but if it is, do you think a fleeting moment of amusement at Linux's comeuppance is worth the damage done to the larger open source ecosystem in its wake? Linux and FreeBSD are on the same team here.
And if yes, can you point to an example of *BSD doing something similar while pushing their platform forward?
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.
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.
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.
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.
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).
[1] https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd
And like I already mentioned in my previous post.. there are other alternatives around than just SysV-init..
Gnome does not depend on systemd, but rather logind.
KDE used to be the same, until someone started maintaining ConsoleKit2 again, proper, at which point they were happy to support it.
ConsoleKit was dropped because it just wasn't being maintained, and had various limitations.
Maybe it's simply easier to maintain this way?
elogind exists, if you care. It exposes the DBus interfaces that logind supports for applications to call.
Thus, environments like Gnome can be supported on non-systemd systems if they emulate and/or expose and implement the required DBus interfaces.
See also https://lwn.net/Articles/586141
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.
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.
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.
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.
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.
Portable to what?
sysv init scripts simply weren't portable between distros, leading to tons of non-standard, incompatible fragmentation.
Users simply couldn't simply take their own scripts over to another distro and expect them to just work, given said differences.
With systemd, unit files will simply just work between all systemd distros, given the standardized format.
You're ignoring what the parent said and talking past.
It's not the 'sets' that are standardized, it's the set of commands that are applicable to a systemd service and to any systemd Linux distro that is.
BSD init is far better than Sysv. Adopting it would have been a step forward.
There are also other init systems that are better designed, like openrc or runit.
OpenRC is practically speaking a thin wrapper around SysVinit, not much of an upgrade if you ask me.
Why for example are Jails not compatible with Linux? Is that not considered upstream because FreeBSD's "integrated"? How convenient.
I think what you see is happening because these "upstream" projects are actually primarily for Linux and by Linux devs. They just happen to work on BSD as well, but weren't you guys saying this whole time how the BSD approach of having everything integrated into one system is better and the whole GNU/Linux ecosystem of several upstream components is strictly worse?
So what exactly are you complaining about? Us trying to use Linux-specific features to make the Linux ecosystem the best, rather than target the lowest common denominator while you guys take full advantage of FreeBSD's specifics?
Seems less than fair to me.
Any examples?
> Why for example are Jails not compatible with Linux?
What? Jails originated in FreeBSD over 20 years ago? This question doesn't make sense.
The OP was referring to systemd affecting upstream by requiring systemd for things (ie Gnome). Are you saying there are pieces of software you have always used, but no longer can because they directly rely on jails?
I don't even use FreeBSD, but this was a weird argument.
Just because GNOME wasn't using systemd in the 90s when systemd didn't even exist does not mean it should not use it ever, even if it makes sense for GNOME devs to do so now.