Journal phantomfive's Journal: Systemd 11 - Open Source Makes Things Better 9
In some ways, I think of Lennart Poettering as a product manager. He figures out what people want, then builds it. The architecture is not always the best, but 'customers' don't tend to care. The point here is that some people do want some of the features of systemd, and Lennart figured that out.
Lennart's system is sometimes laughably bad (for example, he'd prefer to get rid of BSD because he doesn't know how to write portable software), but he has done the community a service by bringing up the topic of system init. More and more, we are seeing thought provoking commentary, ideas on what a good init should be like. This wouldn't have happened if Lennart hadn't built systemd.
This is how the community should be. One person sees the problem, and tries to solve it. Other people come and say, "I can think of a way to improve that." Eventually we arrive at a solution that is elegant, and effective. Init systems have been controversial for decades, which is why BSD and SysVinit are different. Every major Unix vendor has tried to come up with a solution to that problem, and in each case come up with something rather mediocre. Until recently, the Linux and BSD communities have kept what they had, preferring not to change until something comes that is clearly better. When the better answer comes along, it will be obvious.
Systemd won't be here for the long term, but it's effects will be felt through spurring the community to solve this problem that has plagued the community for decades, again, analyzing the problem with things like this (I'd also like to think my own analysis is worth something).
I think a good start would be to add functions to POSIX like "daemonize()" and "start_dameonize()" "complete_daemonize()" but maybe I'm wrong.
Hmm... (Score:2)
In my internet travels, I came across "uselessd" which attempts to make a light-weight version of systemd. If you've not bumped into it then, by all means, click this [darknedgy.net] and have a gander.
Re: (Score:1)
:-) You missed out [slashdot.org]
The real problem with systemd (Score:2)
To me, the real problem with systemd is the massive web of interdependence tied together with bad interfaces. That makes it really hard to remove even a part of it in an attempt to do something better. It doesn't really provide any demarcations.
It doesn't seem too intractable today only because the various popular daemons like sshd and httpd haven't been 'integrated' the way the systemd project wants them to be.
Various people in the systemd camp have even gone as far as advocating that only init (systemd) b
Re: (Score:2)
People are saying (and indeed, this is how it's going to be implemented once the current cgroups API has been replaced) that applications should go through systemd's interfaces, asking for permission to change cgroups.
That is exactly the thing I am complaining about. What if I want MY experimental system to be in charge rather than systemd? That's right, I would have to rip out systemd and everything that depends on it rather than carving out a small niche to test in.
How about "If you're root, you can use the cgroups API"? Let systemd have control over the groups it creates and puts processes into and my test daemon will do the same. It seems to me that the only "problem" the change seeks to address is "it's too easy to
Re: (Score:2)
OMG WTF!!!
Just who do you think you are? My system, my rules! Perhaps on your system, everyone and his dog has root access, but on my system, *I* have root and cgroups should be usable by anything *I* designate.
The system's job is to provide mechanism. My job is to provide policy.
And you double down on the fascist theory of systems by demanding that nobody but the systemd team should even write software that uses the kernel cgroups API? Amazing, you have actually created a godwin situation in a technical