I like systemd and it has helped Linux advance. init was a mess and no one still has come with a golden response that shows the world how anything would be better then systemd.
systemd answered a difficult question and hopefully we willsee more similar advancements shortly for Linux.
I just didn't want to be forced to use it in case history repeated itself. Opting out of systemd is ridiculously difficult due to that GNOME tie-in. It's one of the most important parts of my system.
I still would prefer not to have systemd, but I will admit that it works reasonably well for my purposes. I'm pretty upset about how it all went down, but that's life in the fast lane I guess. Where are the days when everybody ignored Linux? I should move to BSD ;-)
So they took plan B and used logind, which is part of systemd. People are still free to develop shims that would work with other init systems - but so far nobody is willing to do that.
The main problem is that, as the responder to my comment said, there are not enough outside developers getting in there and fixing the problem. I am included in the list of people who could fix it, but won't because I have other things to do.
It doesn't stop me complaining about it, though. I don't think the complaints are counter productive either, if they are aimed in the right place: Red Hat. Blaming Lennart is useless, whether or not it is fair. It's Red Hat's behaviour that needs to change, because if they replaced Lennart tomorrow the new person would have a mandate to do exactly the same thing.
Opting out of systemd is hard because systemd is the only package which actually solves these problems reliably, and is enthusiastically maintained. Logind is the only maintained implementation of ConsoleKit. xinetd works fine, but it operates outside the loop of the system manager, which makes socket activated services harder to monitor and configure and prevents them from being started before xinetd itself.
Say what you will, but systemd is relied upon because if they didn't rely on it, the functionality they need would not be found elsewhere.
I think these are all growing pains. As the system gets more complex, we are starting to realize that we can't afford to maintain two or three wrappers and sets of configs for the device manager process; we can't afford to maintain a handful of different metadata-enhanced logging systems in each daemon; we can't afford to maintain adapters and configs for a bunch of login managers. This is exactly the same kind of pain which made portable UNIX an overnight commercial success. People yearned not to have to maintain a port for every computer they run on. Today they yearn not to have to have to ask five daemons different questions for the same answer.
* https://www.mail-archive.com/supervision@list.skarnet.org/ms...
* http://jdebp.eu./Softwares/nosh/openbsd-binary-packages.html...
Just boot the system and hand it off to a service manager that handles unit files. That was a nice idea. Everything else that came after with tight coupling to systemd was not.
"There will be better alternatives in the future that are more secure than what we have now. But adopting them will only be possible if systemd has not destroyed the modularity and standards-compliance that make innovation possible" [1]
[1] https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_...
The article was an interesting example of how upstreaming unit file for systemd means more collaboration between distributions, less wasted work.
Agreed, but I hope that systemd starts focusing on stability and fixing the regressions they've introduced compared to sysvinit. systemd machines are the only instances of Linux since 1995 where I've had intermittent random hangups during startup and sometimes shutdown. I never thought about startup and shutdown before systemd. It just worked, and if there was a problem, it was reproduceable and a real error (usually configuration), not systemd random fault. I don't use CentOS, maybe their systemd integration is actually reliable.
This kind of defensive response seeks to shift everything from the technical to the political and leaves no room for genuine criticism, improvement and diversity.
Linux was a success way before systemd, you just can't disrespect all the talented people who have got Linux where it as greybeards or motivated.
You say systemd has advanced Linux but don't say how, you say init scripts were a mess but so are systemd symlinks littered all over the place. This is not reasonable.
SMF or Nosh
They could have easily written this same article when nfs first came out and they were working through their default sysvinit scripts.
If anything, the article is a good example of adapting new tech to work around the many odd behaviours of old tech.
Statement without substance that sounds more like a "feel good" phrase
> that shows the world how anything would be better then systemd.
Not breaking and being very unstable is a start
> systemd answered a difficult question
No, it caused more problems than solved
> more similar advancements
It's not an advancement except in the mind of some
I'm not against an init tool like Systemd. I'm against 2 things: LP and his contributors don't seem to know what stable software means or even care (I went through something like 4 distro versions before Pulseaudio was minimally stable) and the scope creep of systemd
Talk about a statement without substance.
But setting that aside, I think init is guilty of "breaking" and "being unstable". Having existed long enough for others to work around your flaws is damning with faint praise. The hours I have spent combing documentation upon an upgrade of one thing or another (I'm looking at you, Apache) because init broke would be difficult to count. If you manage all your components from within the distribution then it's usually fine, but if you are managing something not included in the repositories... buckle up, it's going to be a bumpy ride.
But the greatest vote for systemd is that every major linux distribution, even ones that value stability very highly (RHEL and Debian) adopted it, sometimes at great cost to the community. That says a great deal about systemd's advantages in a system often fractured by choice.
The substance is in several bug reports and general trouble that are available in google for all to search
But I'm curious at what problems you did have with init
It doesn't help that we are increasingly dependent on packages that most would argue are as opaque as systemd. For example, if my organization wants to adopt single sign on (and why not), I've got to install shibboleth: a massive, hulking beast of a system that I don't really understand but can tell you for sure does not obey Unix's "one tool, one function" philosophy and with an init script that I pieced together from parts. (Tangent: There are days when I miss Microsoft and it's suite of integrated tools, notable active directory).
So I would say that while systemd has plenty of bug reports, init simply substitutes endless form posts on fixing init for bugs. And frankly, after a rocky start on the switch over, I haven't seen many issues with systemd.
So perhaps it's just acknowledging that best practices don't always get followed and that others have a different set of problems. I expect systemd resolved a lot of issues for distribution maintainers that had to walk gingerly around init when planning their upgrades. Perhaps that's the wrong reason to switch, but at least it's a reason I understand.
So you're saying Linux didn't advance in the last few years?
> Not breaking and being very unstable is a start
Statement without substance that sounds more like a "feel bad" phrase
> No, it caused more problems than solved
Statement without substance that sounds more like a "feel bad" phrase
More seriously, show us data that refutes OP's statement instead of simply claiming that it's without value. You do the same thing in your assertions, and it really doesn't drive the discourse forward.
I worked with a number of large enterprise customers running Linux at scale, and when the architects opened up to the value of systemd, they universally sang its praises. Out of all these large customers, I've never run into an issue where systemd was the culprit of a significant, P1 style issue. There's a large, silent majority of systemd users who run into no issues at all.
Linux advanced significantly more under sysvinit than systemd, so does this mean sysvinit is superior to systemd?
> Not breaking and being very unstable is a start
When it works, it works fine. When it breaks, it's very hard to debug. There's plenty of articles out there about this. Even the original article which spawns this talks about the same types of problems - "we have to mask it, not disable it, because <xyz>", or "end users will have to be responsible for masking this service", or "when it was just bash scripts, we didn't have to worry about order".
> There's a large, silent majority of systemd users who run into no issues at all.
Can be equally said about sysvinit and upstart. Does that mean they are just as good as systemd?
My two cents: Developers love systemd; its one more thing they can abstract away and mostly not deal with. People who have to troubleshoot problems with systemd don't feel nearly as charitable towards it.