What you are missing is that it is possible for two things to be true at once. It is possible for sysvinit to suck and for systemd to suck in entirely different and potentially much worse ways.
It's as though someone is complaining about having to live under the USSR and how bad things are, and then someone responds that the German rocket program has been dismantled and the British never really had much of one and the Americans are doing okay but the fact is that the USSR was the first to put a man into space. As if that justifies everything else they did.
Setuping services has been a pain for 15 years for me. Then with systemd it was suddenly easy.
Detractors keep repeating systemd sucks, but that this point, Debian and Fedora apparently decided it was good enough. And I never heard an end user complain.
I don't know if I qualify as an "end user" to you, but I definitely have complaints. I started with an open mind about systemd, because I'm not so attached to any init system in general. So my issue is not that systemd is a monolith or breaks with tradition (sysv init scripts were also a hot mess). My problem is that systemd looks and acts like a freshly written proof of concept that needs to be polished up, but when you dig in to debug a problem you're having, you inevitably end up at bug reports that condescendingly defend the current state of affairs as desired behavior.
"Your issue is user error, because systemd doesn't provide the logical guarantee you want, and adding a hook is outside the scope of systemd." I've run into several instances of this, the worse one being around unit ordering and network interfaces. I eventually solved it with a hack service that put 'sleep 90' between network.target and network-online.target. So much for that startup parallelism.
Another issue is that a dependency loop will cause it to just randomly drop units. There's no insight into this until you notice it happening and go digging. In the abstract, yes there is nothing else systemd could do apart from refuse to boot. Except the problem has only been dragged into the abstract by using a configuration model that punts on real world concerns.
Both of these are exacerbated by magic processes that half-parse crypttab/fstab/interfaces to create runtime units. I don't know if these are from Debian or the upstream. But if the systemd way is better, why haven't those been fully moved to native systemd?
That's not how I remember it. Fedora was pushed to adoption (thread starter characterises it as an internal "power play"), and Debian was presented a fait accompli (article summarises Russ Allbery with "[not] systemd-vs-the-alternatives, but how-much-of-systemd").
> And I never heard an end user complain.
This is ridiculous! I can also claim the world is always dark when I shut my eyes.
Linux mailing lists are full with complaints. A recurring one was an error message that suggests running a command as remedy, only for that command to also error out. (The remedy was formulated wrong.) By then, systemd already had a version number in the hundreds.
The article did a good job articulating that the "end users" of an init system aren't sysadmins, they're distro maintainers. If most distros have switched then it must make things better for them.
The problem, of course, being that for most init systems the "end users" are the distro maintainers but for systemd, because it spreads itself into so many other things, it also impacts the sysadmins and the upstream third party package developers. Who then complain about it and are met with "it was good enough for Debian and Fedora" even though they aren't the ones complaining.
Exactly, my biggest problem with the systemd complainers is that it's all kind of abstract things, like it's not the Unix philosophy, which in practice doesn't mean much and certainly doesn't automatically mean it's a bad thing.
SysVinit was a horrible, inconsistent mess of bash scripts of per-individual-developer variations in quality and not insignificant variations between distros, or even individual services within the same disto, I wouldn't hold that as the cornerstone of the Unix philosophy, that is if one's intention is to paint it in a positive light.
> What you are missing is that it is possible for two things to be true at once.
Actually, it's possible for more than two things to be true at once. It could be:
1. It could be true sysv init sucked. (Actually, it wasn't that bad as a modular version of local.rc, but parallel and delayed startup was always just a kludge).
2. It could be true that systemd is a good init system. (For me it's a step change improvement sysv init for parallel and delayed start up. About my only complaint is you don't see failures on "systemctl start xxx"; you have to run journalctl.)
3. It could be that adding another 1M lines of code into the systemd source unrelated to starting stuff was an unsound engineering decision - almost inexplicable coming as it does from a senior engineer. Keeping things in separate source databases with explicit interfaces is a well understood way of reducing the chances of ending up with a ball of mud.
4. It could be that moving sending state changes via an RPC interface (dbus) so you have a million places you have to inspect to understand the state of the system and how it got there rather than writing the desired state of the system to disk with a journal where everyone can inspect it was a bad idea.
> Keeping things in separate source databases with explicit interfaces is a well understood way of reducing the chances of ending up with a ball of mud.
I don't think this invalidates the thrust of your point, and I don't necessarily subscribe to the concept of monorepos, but Google is a monorepo, so senior engineers are definitely signing off on this sort of thing. Is it a ball of mud though? Actually does seem true more and more as time goes on.
Probably the biggest difference is that well-disciplined engineers utilizing monorepo do sustain those well-defined interfaces. The example of systemd-logind having no interface guarantees (cited in the linked article) is a sign of trouble.
This is the kind of false argument being thrown around often in OSS discourse that ignores the structural power differential.
Don't like it? Write your own/Leave.
The fact is you can't go back to it as an individual, because the system has changed and as an individual you're powerless to change the situation at all, especially against an army of developers paid full-time. The latest news from Debian is sysvinit support is no longer guaranteed.
If you can't pull your own weight and don't want to try anymore then yes, you should leave and come back when you can. Sorry if that sounds rude but this is the way it is. OSS (and software in general) has always been driven by people who are fortunate enough to have access to expensive computers and who have the free time and motivation to spend programming. You can't let what they do bother you, and there's nothing wrong with taking a break and coming back later when you're ready. I'm sure the companies who employ these armies of developers are hiring so you could probably work there too if you really wanted.
If anything the power differential has gotten much smaller in recent years with things like github, and last time I checked systemd was accepting pull requests. And even though they won't guarantee it, it sounds like Debian also will continue to accept contributions from those who want to spend time trying to support sysvinit. What exactly is the barrier you're having?
Before I comment here: I am a fan of systemd in many ways, and I happily use it on my systems. That being said, you do really have to think about the systemic factors at play here. As noted in the original article, Debian found itself in a position where the amount of work to sustain a non-systemd path in a systemd-dominated ecosystem would be too much work _for them_. If you personally have more development time then the entirety of the Debian project, then by all means. Let's just not assume that this is a feasible thing for a single person to handle, and really for all intents and purposes, trying to maintain a Linux distribution (or even just a personal Linux system) without using systemd at this point is folly, no matter how much you dislike it.
That being said, SysV init is (in fact) terrible. I'd say put the effort into something that can supercede systemd some day. That part of the problem is tractable, though success is quite a long-shot given its entrenchment.
The person who wrote the headlined article also wrote commentary back in 2014 on discussions of systemd, which highlighted the false dichotomy that people propound that the decision is between van Smoorenburg init+rc and systemd. You are doing that very thing, years later.
That was never the case, especially so for Debian that you mention. In the Debian Hoo-Hah, the choices were van Smoorenburg init+rc, OpenRC, Upstart and systemd; the latter three being the main contenders, as was acknowledged partway through the affair. In Fedora and Ubuntu, the choice was between Upstart and systemd, Upstart having been what they used for some years before systemd.
I do want to say that despite my comment here, seems like projects like Devuan, Void, and Arch are doing OK with this, in concert with projects like elogind and eudev etc that forego systemd while providing compatible replacements.
> Debian found itself in a position where the amount of work to sustain a non-systemd path in a systemd-dominated ecosystem would be too much work _for them_
Just as a side note for the interested, there is a project named Devuan that launched to keep alive a Debian sans systemd.
> Lennart and the systemd team did exactly that 10 years ago. Why can't you?
It would be impressive if Lennart managed that by himself. Red Hat wanted it done, Ret Hat also has its hands in various open source projects that suddenly started to sprout hard dependencies to systemd. Projects like Gnome were Red Hat is by far the biggest contributor.
Not much an individual programmer can do compared to a corporation throwing its weight around to break things.
Red Hat had zero interest into a new init system when Lennart started systemd. They had just moved to upstart and Red Hat customers don't really care about init systems. Red Hat customers pay for their systems to be stable and to have someone to call when something goes wrong.
Systemd gives Red Hat no competitive advantage whatsoever.
I'm probably not going to make myself a lot of friends by saying this but I don't really understand the systemd opponents.
The components systemd is slowly replacing or sitting on top, most of the low level userspace of linux, is mostly garbage and poorly documented garbage at that. PAM is aweful. I don't even want to talk about ConsoleKit. Cron has one of the worst configuration format ever and I'm certainly not going to miss fstab. I would find journald a step in the right direction even if the only thing it brought to the table was the ability to configure logging from the service file and not have to fiddle with logrotate.
Networkd gives you a nice, uniform and well documented way to configure both interfaces, rules, custom routing tables and vpn tunnels from declarative files. Who in their right mind can miss the hodgepodge of scripts that was there before ?
> I'm probably not going to make myself a lot of friends by saying this but I don't really understand the systemd opponents.
I think sections 3.5 and 3.6 (all of them, including subsections outlines current problems pretty clearly. Summarized, systemd is complex to reason about, ambiguous in how it functions, and poorly documented in many cases. All the very similar directives with slight nuances paint a picture of people that didn't really understand the problem space as well as they thought they did (and to be fair, nobody did, and they probably had the best understanding, as woefully inadequate as it was). For a sysadmin, who rarely (but not never!) has to dive into the intricacies of unit files and the myriad directives and their nuanced behavior for creating a server but less rarely is affected by odd behavior introduced by systemd, it's a liability.
What we have now is a chance to learn from those missteps and build something even better. Systemd as a catalyst for rapid chance was wildly successful. As an init system that capitalizes on those changes in a way that users (that is, system/distro packagers) can take advantage of, not so much, since it's so wildly complex. The article posits that BPF will be used to create programs to take over some of these tasks, which may be right. Alternatively, we could start pulling out the components that systemd subsumed, and formalizing them into new standards that others could develop for. Whether that means actually pulling out the component (e.g. logind) to a new repo, or just formalizing API is up for debate.
> Cron has one of the worst configuration format ever and I'm certainly not going to miss fstab. I would find journald a step in the right direction even if the only thing it brought to the table was the ability to configure logging from the service file and not have to fiddle with logrotate.
What you don't like about cron format? It is nice, consistent.
Same for fstab, the only issue I have with it that e.g. Debian doesn't handle mounting network filesystems after the network is up (there are a couple of those and it shouldn't be hard to just grep the file for those).
As for journald, as long as they keep my log files in /var/log in pure text format it can stay.
The issue I have with systemd is that it tries to fiddle with my files, last year I noticed that /etc/resolv.conf contains some strange line with local resolver, WTF? I didn't install one for sure so why (and it was breaking my network).
> It would be impressive if Lennart managed that by himself. Red Hat wanted it done
RedHat wanted it done once Lennart convinced them it is the right thing to do and Lennart put in the effort to be at RedHat at the right time to have the ability to convince them.
In fact Lennart is one of the few people willing to put in the effort to touch the fundamental building blocks that otherwise rot, but nobody is willing to touch.
> Projects like Gnome were Red Hat is by far the biggest contributor
Yeah, I guess it's not that bad that in FLOSS, the people willing to ultimately sit down and put in the time and effort to actually write the code, even the non-sexy bits, get to steer the project over Hacker News commenters.
That's not the worst outcome out there if you ask me.
> The fact is you can't go back to it as an individual, because the system has changed and as an individual you're powerless to change the situation at all...
Use Void Linux, help Devuan etc. You're not alone, but you're clearly in small minority.
Exactly, and to prevent this from happening is what Devuan is all about (as I'm sure you know): to keep all the maintenance work going into Debian, while remaining mostly bullshit-free.
It's what I'm about to be installing after a decade on the Ubuntu desktop. The recent snap fiasco is just the final nail in the coffin. The trifecta of SystemD, Gnome3, and SnapD means that I can just use Windows with WSL if I wanted a distro that is maximally intransparent and pushing things onto me (saying this without satire). Actually, gnome3 is really the worst regression here, and it being so strongly tied in to SystemD makes it an easy target to get rid of.
Other contenders I've been looking into: Void Linux, Slackware, and the BSDs (I used to run FreeBSD in the late 1990s/early 2000s). At one point there was even a variant of Debian (userspace) running on FreeBSD, which however was abandonded due to SystemD and cgroups/namespaces invading too much of Debian.
Good luck with Devuan (I have no experience with it).
If it doesn't work out I can recommend Void Linux. I've been using it for years as my daily driver since Debian switched to SystemD, both at work and at home.
I don't see how that is the problem. It's exactly what you asked for. If you're replacing a low-level component with something else that hasn't been updated in years and doesn't implement features that other packages do then yeah, you have to be prepared to accept that some newer things will break, and you'll have to revert a lot of other packages to older versions too. What else can we do? This isn't even a systemd-specific thing.
Systemd deliberately refused to conform to standardised interfaces and got other packages to be changed to explicitly depend on it instead (e.g. RedHat made changes to Gnome to make it break under non-systemd). This was not necessary to achieve the technical things that systemd wanted to achieve - competing alternatives (e.g. runit) didn't need that. (Though it probably was necessary to force adoption).
This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd. So this is not a matter of some developers going around and raiding projects and "forcing adoption", it's all stuff that happened under the same umbrella anyway.
If the "competing alternatives" don't need it then I would advise those projects to put their money where their mouth is and either start making improvements to elogind, or develop a new login manager that better fulfills the needs of gnome. In particular the solution used by elogind to deal with cgroups is to just disable them entirely, or at least it was last time I checked. I don't know what runit does for cgroups but a good step would be to make elogind compatible with that.
> This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind.
elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility. It's like saying that windows programs work on Linux, you just have to use wine - it's sort of true for now, but it's not something you can rely on.
> And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd.
I remember multi-seat working fine long before either systemd or ConsoleKit, so that seems pretty questionable.
> I would advise those projects to put their money where their mouth is and either start making improvements to elogind, or develop a new login manager that better fulfills the needs of gnome.
"The needs of gnome" are a constantly moving set of goalposts under the control of RedHat. Gnome worked fine long before systemd and systemd has not noticeably improved it (if anything the opposite); there was no technical consensus that the current hard-dependency was necessary, it was forced through because RedHat wanted it that way. So they're not going to accept patches to offer compatibility with non-systemd, and if they do then they'll just find a different way to hard-depend on a different part of systemd.
>elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility
Isn't that the whole reason for using another init? Because you see full compatibility with systemd as being undesirable and you have the means yourself to maintain things yourself using other solutions? I don't get it, it sounds to me like you're now saying the opposite of what you did before.
>I remember multi-seat working fine long before either systemd or ConsoleKit, so that seems pretty questionable.
Multi-seat might have worked but it did not do so securely. The issue is that you need a daemon to multiplex the display and input devices, and programs that want to request logins must be able to speak a specialized IPC protocol to that daemon. Otherwise all you have is a bunch of setuid root programs that do not communicate and can easily clobber each other at any time. Remember that the kernel does not have any built-in support for this, these are just device nodes in /dev like anything else, and in the old days the X server just used to run as setuid root at all times and sessions running in the background could read the keyboard whenever they wanted or take control of the display. The issue doesn't just affect multi-seat either. Even on your laptop you basically need a login manager to do secure screen-locking. There are an absurd number of ways that pure X- or Wayland-based screenlockers can be escaped. In an ideal world the kernel would probably prevent this stuff, but it doesn't right now, so login managers remain necessary.
>"The needs of gnome" are a constantly moving set of goalposts under the control of RedHat.
1. GNOME is an open source project not in control of any one company or organization, and anyone can contribute or fork the project if they so desire.
2. Nothing was "forced through" as the decision was agreed upon by the current and previous maintainers. If you disagree, you can revert to an old version as previously stated. This may be unpalatable to you but it is not realistically possible for anyone besides you to write code that you will agree with 100% of the time. It's up to you to make the tradeoffs you want on your system.
3. Also as previously stated, there is no hard-dependency on systemd. You can get it working with elogind. If you refuse to because you fear it will break in the future, that's on you. The fact is that it works now.
> Isn't that the whole reason for using another init? Because you see full compatibility with systemd as being undesirable and you have the means yourself to maintain things yourself using other solutions?
Compatibility is the only way it becomes possible to make those changes. E.g. in the pre-systemd days there were at least four different syslog systems and at least three different cron systems. But because they conformed to standard interfaces and were loosely coupled to the rest of the system, users were free to choose any of them, or to make their own. Same with desktop environments: you can run KDE or Gnome or Xmonad or whatever, but since they all follow common standards, any program works with any environment.
If the systemd people want to make a shiny new init with cool features, great. It's when they break compatibility with alternatives that I have a problem with it.
> 1. GNOME is an open source project not in control of any one company or organization, and anyone can contribute or fork the project if they so desire.
> 2. Nothing was "forced through" as the decision was agreed upon by the current and previous maintainers. If you disagree, you can revert to an old version as previously stated. This may be unpalatable to you but it is not realistically possible for anyone besides you to write code that you will agree with 100% of the time. It's up to you to make the tradeoffs you want on your system.
The fact is that most contributions are made by RedHat employees on RedHat time, so anything that can be decided by 51% of maintainers is under RedHat's control (and I can't do anything to change that since I can't outspend RedHat). There was a decision to adopt systemd but it was very much not a consensus; there was bitter disagreement at the time (and still is).
Forking by a minority is only practical if the system is made up of small components with standardised interfaces between them. Good open-source citizens follow those standards for the sake of allowing their users to do that (e.g. KDE migrated from DCOP to the technically inferior DBUS for the sake of being able to have common standards and compatibility with GNOME). If the whole system is a big ball of mud with no way to replace or decouple individual pieces, then you can't ever change or fix one part of it without forking the whole thing, and you don't have the Four Freedoms in any practical sense.
>Since they all follow common standards, any program works with any environment.... If the systemd people want to make a shiny new init with cool features, great. It's when they break compatibility with alternatives that I have a problem with it.
That is not relevant because the "common standard" in this case is the logind D-Bus API. There are no other active and viable alternatives to login management. It has two implementations, systemd-logind and elogind. You can choose either one, and only the first one requires systemd. Or if you really want you can choose to write another implementation. Or you can choose to hack GNOME and remove the logind bits and just run your display manager and shell insecurely as setuid root. Or you can revert it to some old version when consolekit was still supported. Or you can just do nothing and wait for someone else to guess what it is you want. You have options. If none of these will please you then I think you need to adjust your expectations because you can't have it all.
>The fact is that most contributions are made by RedHat employees on RedHat time, so anything that can be decided by 51% of maintainers is under RedHat's control (and I can't do anything to change that since I can't outspend RedHat).
I don't see what this has to do with anything. It's open source. If you want to collaborate, you can submit a pull request, work with the maintainers and get them to spend their paid time reviewing and merging your code. You don't need to outspend them, the code is already written and every bit of it lands on github ready for you to use it. Them getting paid more only benefits you.
>There was a decision to adopt systemd but it was very much not a consensus; there was bitter disagreement at the time (and still is).
I can't speak for other distros but looking at the actual Debian votes on systemd (not flamewars on mailing lists), your statement does not seem to reflect reality. Systemd, as well as support for alternatives like elogind, was voted in with strong consensus. https://www.debian.org/vote/2019/vote_002
>Forking by a minority is only practical if the system is made up of small components with standardised interfaces between them.
Systemd is composed of several small components, and its interfaces have become standard across many Linux distros, so this shouldn't be a problem.
>you don't have the Four Freedoms in any practical sense.
It is not reasonable to expect that every single person will have the time and expertise to contribute to any given project, or that every project will be structured in a way that lets them accept maximum contributions. I don't mean to dismiss your frustration with being unable to contribute. I get that. But you continue to have the opportunity to do so and you will for as long as these projects remain alive. The code is not going to magically disappear one day and it's up to you to find the time to actually dive in. Good luck.
> That is not relevant because the "common standard" in this case is the logind D-Bus API. There are no other active and viable alternatives to login management. It has two implementations, systemd-logind and elogind. You can choose either one, and only the first one requires systemd.
Is there any commitment to treating those as stable interfaces, with a decent deprecation cycle around any incompatible changes? If so then that's a big improvement; there certainly didn't used to be.
> I don't see what this has to do with anything. It's open source. If you want to collaborate, you can submit a pull request, work with the maintainers and get them to spend their paid time reviewing and merging your code.
I saw patches submitted and rejected on the grounds that the project leadership had no interest in supporting non-systemd (and/or non-Linux). Even if the leadership does want to accept a patch, that can take months; in my experience it's not worth making a change if you can't run it on your own systems without upstream getting involved. So if a project is large and not cleanly factored into smaller pieces with stable interfaces between them (or at least open to being factored that way in principle), then it's just not worth trying to contribute unless you can work on it full-time.
> It is not reasonable to expect that every single person will have the time and expertise to contribute to any given project, or that every project will be structured in a way that lets them accept maximum contributions. I don't mean to dismiss your frustration with being unable to contribute. I get that. But you continue to have the opportunity to do so and you will for as long as these projects remain alive. The code is not going to magically disappear one day and it's up to you to find the time to actually dive in. Good luck.
I believe in open source not because it gives me a chance to write code but because it lets me fix bugs or change behaviour that's bothering me. It's the "RMS printer driver" situation; if something goes wrong in Linux these days I feel like I'm no better off than I would be on windows. For the moment I'm using FreeBSD (and KDE) and I can still patch stuff without my patches getting broken every other month, but as things integrate more deeply with systemd it seems like a matter of time before the programs I use go Linux-only.
> I saw patches submitted and rejected on the grounds that the project leadership had no interest in supporting non-systemd
What do you mean with project leadership. If someone submits a patch, the maintainer(s) of the git module can obviously reject it if they don't want to maintain it. Unless they're persuaded because it's better for the project as a whole.
However, you talk about "project leadership". That doesn't really exist. There's loads of maintainers. There's a GNOME foundation, which mostly handles admin stuff, sysadmin stuff, etc. There's a release team. They ensure the various maintainers make releases, plus verify stuff actually builds.
If you help out in GNOME you're just a person in a big group of people. There's not really any "leadership", just loads of people who often agree, sometimes disagree, etc.
It appears they have marked the Logind API as being stable because it is intended to be used by the display server and by the DEs. I don't have any secret information here, I just saw this chart on their website. https://systemd.io/PORTABILITY_AND_STABILITY/
About BSD and non-systemd systems: I actually think it is possible for there to be better compatibility here eventually if someone builds more shims. BSD using Mesa for example is a really good thing for everyone. However FreeBSD and Linux have both refused to budge for quite a long time on various things and cgroups seems to have been the final nail in the coffin for any kind of expectation of modern cross-platform tooling. Everything now is container this, container that. The only non-systemd init that hasn't dragged their feet on this has been OpenRC, and even they still would not make any effort to be systemd-compatible because of objections over other things. So what is the solution here? Do you see how hard it even is to get people to run something like elogind on top of another init with another cgroup implementation? I don't blame the systemd developers for not bothering with that. It is not feasible to expect them to maintain everyone else's init as well as their own.
I checked the systemd contribution graph and it seems they have a large number of smaller contributions from outside developers, so the data does not really support your assertion about it not being worth it. https://github.com/systemd/systemd/graphs/contributors
Also, just going by the data, the repos for KDE (collectively) and FreeBSD (a monorepo, like systemd) are much, much bigger, just as tightly-coupled if not moreso, and get a lot more activity than the repo for systemd. It seems strange that you would pick those projects to contribute to.
> The only non-systemd init that hasn't dragged their feet on this has been OpenRC, and even they still would not make any effort to be systemd-compatible because of objections over other things. So what is the solution here?
You either hammer out a common interface with compromises from both sides, or you implement the parts you want as progressive enhancement from a lowest-common-denominator baseline. It's not easy, it's not glamourous, but it's the right way to do it. Look at how e.g. web standards stuff happens when there's disagreement between different browser makers.
> Also, just going by the data, the repos for KDE (collectively) and FreeBSD (a monorepo, like systemd) are much, much bigger, just as tightly-coupled if not moreso, and get a lot more activity than the repo for systemd. It seems strange that you would pick those projects to contribute to.
I'd disagree with the idea that KDE is more tightly coupled; in my (limited) experience it's very cleanly factored and it's clear where the interface boundaries lie. It's a big project but if you want to fork and patch one part of it you can do that.
FreeBSD is theoretically more tightly coupled than GNU/Linux, but in practice I've found a lot less of the kind of interface churn that you see in Linux. Linux went through two or three rounds of different audio APIs where on FreeBSD you still just use OSS. I've lost count of how many times the way you do network config on Linux changed - I genuinely can't set up a network on Linux any more - whereas in FreeBSD it's all just ifconfig. Linux forced a quick migration to HAL followed by an equally quick deprecation in favour of udev; FreeBSD is still using HAL. There's just so much more commitment to stable interfaces, both in theory - a deprecation cycle for even the kernel ABI - and in practical experience. Or maybe it's just that the project doesn't have enough manpower to churn as much as Linux does, but either way the end result is that I can patch my system and expect my patch to keep working.
> elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility.
That's because elogind is architecturally all wrong - instead of sticking to the defined stable public DBus interfaces of systemd, and implementing those independently from scratch, what they did was rip the implementation of systemd-logind out of the systemd package and hoping that the intentionally unstable internal interfaces in libsystemd that it relies on will continue to be provided.
> Gnome worked fine long before systemd and systemd has not noticeably improved it (if anything the opposite); there was no technical consensus that the current hard-dependency was necessary
There was a very, very simple reason for why Gnome depends on systemd-logind: nobody volunteered to maintain the ConsoleKit backend, or ConsoleKit itself for that matter, so it bitrotted and was eventually removed.
> elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility.
You do realize even the Linux kernel doesn't make any commitments regarding API stability, right?
That's kind of an explicit choice to allow the maintainers to move forward with the limited resources they have without too much red tape.
There's always *BSD, if you want compatibility back to the Sun days in some cases, (Win32 is another option). Linux is about being as modern as possible without having to worry much about backwards-compatibility and all the cruft that comes with having to maintain that.
> You do realize even the Linux kernel doesn't make any commitments regarding API stability, right?
You say "even" the Linux kernel; actually most projects don't and Linux is a rare exception, and I do think it's a bad idea for both technical and nontechnical reasons. (Compare with GCC's refusal to offer a stable API between frontend and backend, which I'd argue is a big reason why LLVM is overtaking it).
> There's always BSD, if you want compatibility back to the Sun days in some cases, (Win32 is another option).
I actually do run FreeBSD these days; one of the reasons this issue still bothers me is that compatibility with BSD is likely to be collateral damage from the systemd push (it's getting harder and harder to run Gnome on BSD, for example). It was particularly frustrating that systemd basically killed off Debian GNU/kFreeBSD just as it was becoming a first-class architecture; that could have been the best of all worlds.
I noticed the ConsoleKit->logind change at the time being largely justified by support for multiseat but had forgotten about it. It seems like a rather extreme case of the tail wagging the dog but perhaps I'm missing something. How many people use multi-seat in large deployments? Where and why?
Virtually nobody is using multi-seat and none should.
For most cases you would get better results by networking n cheap boxes rather than trying to buy a single beefy box to support n users on every dimension including perhaps even power usage if you used low power devices.
Contention for io is a problem. Everyone wanting to say decode video simultaneously is a problem. Browsers high ram usage is a problem.
> rather than trying to buy a single beefy box to support n users
This sentiment has always felt weird to me, as I have always seen UNIX as an OS that has been designed - from the ground up (in late 1960s) to support multiple concurrent users - whether it is via a serial terminal, and now multi-seat, VNC or an X terminal. By today's standards it's not even such a "beefy box" that can easily do that.
Blame browsers as soon as 3 users wanted to use facebook youtube on your 1200 box each user will probably have a worse experience than 3 users running 400 boxes plus hardware failure would reduce capacity to 0% instead of 1 box failing at a time.
Except you seem to have forgotten the other big reason was that basically nobody was actually maintaining ConsoleKit at the time at it was a horrible, insecure mess when logind replaced it.
They didn't used to break if you wanted to switch from one init system to another.
What you could do is to reduce unnecessary interdependencies. And where there is inherently interaction between separate packages, use a stable interface and publish the standard so that alternative implementations can replace a single package in a standard way without breaking several others.
Yes, they did. It they didn't break it was because those inits were compatible with sysvinit scripts. You lose that once you start porting your init scripts over to rc or whatever it is you replaced your init with, and now your system will break if you try to switch to something else.
Your init scripts would have to be replaced, that's to be expected, and when multiple ordinary init systems are popular, packages could easily support more than one since an init script is generally only a few lines.
I'm talking about all the things that now break not related to the normal function of init at all.
If those inits supported newer features, the init scripts would easily grow longer than a few lines and become incompatible once they use those features. I don't see how that's any different from what's going on here.
If your complaint is that the scope of init systems has been expanded, I don't know what to tell you other than that it was inevitable. Systemd is not the first project to try and do this.
It's because systemd offers convenient functionality that those dependent packages want to hook into, because previously they were either maintaining all that themselves and seriosly lacking the manpower to do so or it wasn't being maintained at all and just rotting, (i.e. consolekit)
We had a chance to replace sysvinit with something better. Instead we managed to replace it with something that's horrible in an entirely different set of ways.
The most devastating thing I can say about it is that it feels "enterprise." It's unnecessarily obtuse, complex, and clunky. It feels like a port from some other operating system that's been shoehorned into Linux, or like something designed to sell consulting services and training courses by wrapping very simple things in needless complexity.
We could have ended up with something more straightforward, clean, and simple. It's a tragedy.
It's as though someone is complaining about having to live under the USSR and how bad things are, and then someone responds that the German rocket program has been dismantled and the British never really had much of one and the Americans are doing okay but the fact is that the USSR was the first to put a man into space. As if that justifies everything else they did.