Solving problems in multiple different ways is the only reason we have multiple distros serving different needs. Unification is not always a positive thing.
Also, just look at the before-systemd landscape, there was much more difference in the repositories, and nowadays even more niche distros can trivially package almost everything since .service files are unified. Also, they are quite flexible, so I don’t feel that anything would be lost.
True, but desktop usage is only one of many things linux is used for. All the "unification" efforts ala systemd try to handle all of those use cases. I don't see why the init system on my server has to be the same as the one on my ultrabook, because only a fraction of what they should do is shared. Having one tool that covers all the use cases just sounds like a very good way to increase the attack surface.
> I believe there are only a handful of people who knows enough to create a proper init system (similarly, sound and graphics) and do it for the community.
I don't think Linux graphics or sound situations have much in common with the init system situation, except perhaps the fact that Poettering tried to fix sound as well.
Well, not even the kernel should be shared —- but most of us is okay with having the same kernel, but at most configured differently. I see it the same way in the case of systemd, of course your ultra book doesn’t need I don’t know how many services, but the basics are very much the same. And to be honest, I’m happy to use the same knowledge/tools on a server machine and a laptop.
> Having one tool that covers all the use cases just sounds like a very good way to increase the attack surface.
That’s just security by obscurity...
The real problem is that almost no one has been able to create alternatives to SystemD’s solutions to the vast majority of problems it chooses to tackle that are as well developed or effective as the SystemD solution.
You might then ask why no one created these better solutions 6 years ago before systemD gained its stranglehold on distributions, but that's like asking why systemD itself didn't add all these features 6 years ago.
Either open source and software freedom affords us endless amounts of choice and capability to create, inspect, modify and use whatever software we like, or we're all forced to use systemd against our will. Which is it?
Systemd doesn't have a stranglehold over anything - that misinterprets the power dynamic. It's got large adoption, because it's actually useful.
I don't think that's the case. Systemd was introduced with a SysV init backwards compatibility mode, so it was trivial to port services over to using it. Porting a systemd-only service over to SysV init is much harder, though. I'll be charitable and say that this one-way "interoperability" wasn't deliberate, but it does seem reminiscent of the way some proprietary software supports open standards for importing files but not exporting them.
> Either open source and software freedom affords us endless amounts of choice and capability
Software freedom is not a binary matter (excuse the pun), and different licences have given people different amounts of freedom in the past. For example, the FSF considered the pre-1999 BSD licence to be non-free simply because it required a sentence to be included in any advertisement of the product[0]. Another example would be "the Dissident test"[1] that Debian applies to licenses, considering them non-free if they require that modifications to the source code be reported back to the original author.
I think that when trying to determine the freeness of a piece of software, we have to consider the second-order effects it has on the free software ecosystem generally. If the adoption of a (hypothetical) piece of nominally free software caused other unrelated pieces of software to run artificially slower, or become insecure, or to no longer be developed, then that could be a net loss to the free software community, even if the new software has some shiny new features.
> It's got large adoption, because it's actually useful.
That's a rather self-serving interpretation of events. As another comment in this thread[2] explains, systemd at every stage of its adoption was made hard to avoid, and adopting it was made a one-way process. I also gave a more thorough analysis in a comment on another thread a couple of years ago[3], but it seems that the myths about systemd's path to world domination are becoming more and more accepted as people forget the actual history.
[0] https://www.gnu.org/licenses/bsd.html
[1] https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline...
(I meant before systemd/upstart existed).
Is it harder because systemd supports more features than sysv? What's stopping someone writing a new init / service manager that's systemd-compatible? Or improving sysv so that it supports those features?
> Software freedom is not a binary matter (excuse the pun)...
Of course there's nuance, and you're right to point out that different corners of the open source world have different values and disagree on things (BSD/GNU etc). But the point is that the users are in control and that the power lies with the users. If systemd was bad, or actively useless, people would stop using redhat, Debian, etc. As proof that the overall model works, there are distributions out there that shun or provide non-systemd options. People can use and contribute to those!
I also don't agree that anything is a "one way process". Everything is temporary. We'll use systemd until something better comes along, just like we did with perl, apache, Hadoop, or any technology that was the de facto canonical way of doing things right up until the point that there were better options.
I remember the history too - systemd would have gotten zero traction anywhere if it wasn't actually solving real problems. Sure, there were some pretty major bugs, and I wish Debian had done it right, but that doesn't take away from the recognition that there was a problem to solve and this was our best stab at solving it.
I guess I just don't understand the energy poured into hyperbole like "world domination" and "stranglehold". If you want to convince me that something I find useful every single day is bad, then build something better.
I still don't think we were "locked into shell scripts" though. Even if shell scripts were the only thing that existed, it was still possible for someone to make a service manager which supported something else, with a backwards compatibility mode for shell scripts.
> What's stopping someone writing a new init / service manager that's systemd-compatible?
My understanding is that systemd deliberately makes it hard to independently reimplement certain critical components like logind and journald. In practice, no distro is going to go to the trouble of packaging and supporting a mixture of components from the "official" systemd set and other competing implementations, even if those competing implementations were easier to use, or faster, or more secure, or more portable.
Compare this to the situation where system services were not so tightly coupled and it was possible for distros to change their default ntpd, for example. Just as monopolies in industries prevent new innovative start-ups from emerging, a monoculture in Linux system services prevents people from even trying new approaches.
> As proof that the overall model works, there are distributions out there that shun or provide non-systemd options.
I can't help being reminded of the (in)famous scene of a Microsoft lawyer holding up a boxed copy of Red Hat as a defence against the claim that they were abusing their monopoly[0]. Alternatively, it's like an authoritarian dictatorship pointing to the existence of nominal opposition parties to show that its citizens are free.
My point is, I think you're missing some of the power dynamics here, in particular the fact that people don't want to completely reinstall their operating system just to avoid the problems of systemd. Indeed, most users wouldn't even know that systemd is the cause of their problems, especially when the problem is something nebulous like a lack of innovation and competition in the system services space.
To put it more simply: Just because lots of people don't switch away from Windows (or Facebook for example) doesn't mean that they are happy with it.
> systemd would have gotten zero traction anywhere if it wasn't actually solving real problems.
It might have solved a few people's real problems, but I think that GNOME suddenly making it a hard requirement probably mattered to more people.
> If you want to convince me that something I find useful every single day is bad, then build something better.
If you find it useful every day then I'm happy for you. However, I don't think I have to convince you of anything. I'm not trying to make it harder for you to use systemd, whereas systemd is making it harder for people to use other inits, including SysV init which has been working fine for them for decades. The onus should be on the ones doing the coercion, to convince the people whose choices they are reducing, not the other way around.
[0] https://archive.is/eMmMB / https://www.washingtonpost.com/wp-srv/business/longterm/micr...
I switched from Windows to Linux 20 years ago to have more choice.
E.g. in Gentoo you can choose to use SystemD or OpenRC, but I think that most other distros don't provide such a choice.
And of course after a certain size it has to do with network effects, but it was chosen based on merits — for example debian voted multiple times on the issue and I would say their voting system puts most countries’ to shame.
I believe up until recently the vote on debian was basically use systemd but if the maintainer wants to, they can also support alternative init systems, but there was not much interest. But of course anyone can help the fringe distros on another init systems to make them less fringe.
Yes, I absolutely agree regarding the effort. (not sure about that vote - I honestly didn't follow that discussion)
In parallel, some software (cannot recall - maybe the Gnome window mgr) does rely (in its original form) on SystemD being there => I don't think that's fair, kind of forcing the distros that want to offer it to adopt it => I don't like it - I do see the advantage of having that kind of integration, but I still don't like it :P
The dependency no longer exists because some people took logind from systemd, made it a standalone package and called it elogind lol, and now you can use that instead of logind.
I think it has more to do with the linux kernel being much more advanced than the others, and some of the userspace depending more and more on these advanced features. But I’m not sure about this. Aren’t you referring instead to debian itself providing packages for all of them and the package manager running on each distro? Because I can’t really believe you could just swap out the kernel and be on your way in most cases. If it is the latter, than it was more due to the fact that debian maintainers voted against supporting other systems, because it is a great amount of additional work.
It's a bit more direct than that - previous init systems were kernel-agnostic whereas systemd is explicitly tightly coupled to Linux and udev, and encourages the rest of userland to be tightly coupled to it.
> I think it has more to do with the linux kernel being much more advanced than the others, and some of the userspace depending more and more on these advanced features.
I wouldn't say "more advanced" - in many ways FreeBSD jails are a better technical solution than Linux's various container systems.
1) eudev works
2) elogind works
3) you can still use sysvinit or literally the multitude of others
The fact that this is so rare it has to be pointed out like this kind of speaks for itself.
> 1) eudev works 2) elogind works 3) you can still use sysvinit or literally the multitude of others.
I am aware of these and use them on nearly all my machines.
Note that both elogind and eudev required a significant amount of work by the Gentoo community when they were pulled out of the systemd codebase.
You may not mind the decisions others make on your behalf, or care about the options that are no longer possible, but that doesn't mean that Linux hasn't lost some of its identity.
Yes, in the sense, that if you want, you can eventually make it the way you want.
No in the sense, that others won't do it for you; they will make linux distribution the way they consider it best, not how you consider it the best.
So if you want to pick and choose the components the way you want and not the way the distributions consider the best, be ready to put in the manhours.
Just like you can mostly expect filesystem behavior to be consistent no matter which distro, so should be the OOM behavior if a "good" solution is found.
The same thing goes for out of memory handling: no size fits all. The kind of handling strategy you need depends on the kind of system you build.
Exactly this kind of flexibility and lack of unification is what made Linux so ubiquitous.
Except with the monoculture of systemd how can experiments be done with other approaches? Nowadays it seems like "use systemd or GTFO".
> Just like you can mostly expect filesystem behavior to be consistent […]
And how many file systems does the Linux support? One can try an approach and see how it works and others can perhaps copy it.
How does another approach towards OOM (or anything else in the kitchen sink that systemd handles) get traction when the 800lb/400kg of RH/IBM is bankrolling The One True Way™.
Is that much different from let's say databases, where "One True Way" was SQL and despite that NoSQL became a thing and is appropriate for some use-cases?
> And how many file systems does the Linux support?
And yet ext4 appears to be the most widespread though. It's true that there are other options such as XFS, ZFS and BTRFS but in general, ext4 is a safe default that works well enough for most use cases unless you have specific reasons to choose otherwise.
Is it that far-fetched to believe that systemd might be the same, and it works "well enough" to be the default and even be bankrolled by some big names?
> How does another approach towards OOM [...] get traction
Presumably the systemd OOM killer can be disabled and something else put in its place if you so desire, just like you can still build or use a distro without systemd or selectively disabling its "bad" parts such as the journal, etc?
(not sure how any of this is relevant to this discussion)