> cgroups
Works fine on my Gentoo (OpenRC) desktop. This meme that systemd is necessary for cgroups is simply incorrect.
> sockets
We stopped using xinetd a loooooong time ago. If you want to use a central point of failure, that's your business.
> dbus
Isn't necessary in the init process, though you're free to use it if you wish.
> didn't used to exist
Such as?
> replacement for these features
The replacement in some cases should be "nothing". You're trying to frame the conversation in a way that presumes features like cgroups or "socket activation" are desired features.
The entire point of this "debate" is that you shouldn't be tying extra features to the init process. There are a wide variety of systems in the Linux ecosystem, and there is no one-size-fits-all solution.
If you want to run a heavyweight, opinionated, monolithic init like systemd, that's fine. If it makes your life easier, that's great. Just remember that other people have different requirements.
> > replacement for these features
Did GP edit their comment? The quotes and arguments you're arguing with aren't present in it.
> We stopped using xinetd a loooooong time ago. If you want to use a central point of failure, that's your business.
An init system that groks socket activation yields more benefits than just lazy service startup. Services which communicate over a socket can be more loosely coupled, and a service need not be a traditional "forking daemon" for dependent services to start up at the correct time (since , say, the dependency's UNIX domain socket is already created, they can all start in parallel).
edit: I edited the last paragraph in 20 minutes after posting.
That's not what it's about. The point of cgroups integration in systemd is that it allows systemd to precisely track the processes started under it, which means that e.g. applications where things like double-forking or similar happens can still be completely stopped by systemd even if the parent process des.
> You're trying to frame the conversation in a way that presumes features like cgroups or "socket activation" are desired features.
They are to me. They massively improves things vs. sysvinit.
> The entire point of this "debate" is that you shouldn't be tying extra features to the init process.
The entire starting point for systemd is that traditional sysvinit is woefully lacking in the functionality required to build reliable systems. And when you start trying to cobble together something on top of it, it quickly becomes clear that it is not easy.
E.g. try to build a reliable process manager outside of pid 1. You still need process restarting functionality in pid 1 for when your process manager dies. What if it fails to restart? How are you going to log those failures reliably? You end up duplicating a lot of functionality of a process manager in pid 1 if you want a reliable system even if you run a separate process manager outside of pid 1.
There are parts of the systemd design I don't agree with, and I think they'd benefit from splitting out various components from the project, not least for "political" reasons. But the design for the core parts of systemd-the-init-system largely follow on from a very limited set of core requirements of being able to reliably start, stop and keep services running and reliably log data from them.
These are requirements that sysvinit basically throws it hands up at and says "not my table", while by owning pid 1 they make it basically impossible to meet them.
I know why systemd uses cgroups. I was addressing the myth that systemd is required to use cgroups.
> They are to me.
That's nice. You should use systemd if its features satisfy your requirements better than the other options.
Other people have different requirements. Is this concept difficult to understand? We don't want the same features, for a variety of reasons. Disagreement is fine, but systemd advocates often seem to want a monoculture.
> the functionality required to build reliable systems
That's your opinion, which you're entitled to. I disagree, as I've never had problems like you're describing. I value stability a very strongly, so I consider the methods that worked fine over the past 20+ years.
> requirements
That's the framing I was talking about. There is more than one way to design a stable system, and your requirement list is only one of those methods. Some of those requirements I consider misfeatures that cause problems, but it's fine if you disagree.
> impossible to meet them
Then use systemd or some other solution that solves your needs. Is it so hard to understand that we can choose different software?
What I see, however, in most of the opposition to systemd is that most who criticise it don't understand these design considerations and often aren't even aware of the problems involved.
This is why they keep coming up. If most people designed systems that took care of these things in other ways, it wouldn't be so much of an issue. But most people don't. E.g. the fact that most Linux distros for the longest time kept running critical system services straight from init scripts with no process manager or other restart logic is a good example.
But now everything seems to be a case of web monkey balls of yarn that is no better than Windows in staying upright.
Its like i can reuse old UF comics, only replace Murky's love for Windows with Ubuntu or some such.
There are numerous long-term expert users and developers of Linux who've spoken against systemd, its design, its behavior, and its developers. Including Linus Torvalds, Alan Cox, Ted T'so, and Patrick Volkerding
(That's the original developer of Linux, the long-time second in command, the lead filesystem developer, and the Slackware distro's maintainer -- the oldest extant linux distro.)
Mark Shuttleworth, Eric Raymond, and Ian Jackson are notable other critics.
For actual arguments against systemd:
http://without-systemd.org/wiki/index.php/Arguments_against_...
https://igurublog.wordpress.com/2014/04/03/tso-and-linus-and...
The laptop vs server divide:
http://www.infoworld.com/article/2837182/linux/back-into-lin...
Bad design and bad attitude. One or the other might be survivable. Both are likely not.
http://www.infoworld.com/article/2608798/data-center/systemd...
Uselessd's observations on misrepresentations by systemd advocates:
http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
Five troubles:
http://www.draketo.de/light/english/top-5-systemd-troubles
LWN on Debian's debates: https://lwn.net/Articles/452865/
Wikipedia on Systemd's controversy: https://en.m.wikipedia.org/wiki/Systemd#History_and_controve...
or
> I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.
> Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.
> Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys. [2]
Both a quick Google away. To sum it up: Linus is okay with systemd. He just doesn't like its maintainers because they're straight up primadonnas. [3]
1: http://www.zdnet.com/article/linus-torvalds-and-others-on-li...
2: https://linux.slashdot.org/story/15/06/30/0058243/interviews...
3: http://www.theregister.co.uk/2014/04/05/torvalds_sievers_dus...
In what way is that a "big argument"? BSD has their own rc-thing (not sysv init), OS X has launchd (not sysv init, shares many similarities with systemd actually, such as socket activation), Solaris has SMF (again, not sysv init), etc.
Apart from a bunch of non-mainstream Linux distros sticking with sysv init, who else is actually using it?
* https://news.ycombinator.com/item?id=11415985
But yes.