On Wed, Oct 15, 2014 at 09:34:45PM +1100, Russell Coker wrote:
On Wed, 15 Oct 2014, "Trent W. Buck" <trentbuck@gmail.com> wrote:
Jeremy Visser <jeremy@visser.name> writes:
From a sysadmin perspective [systemd] makes my life easier by bringing service control up to (and beyond) the standard of Windows, which has been able to supervise processes since, gosh, I only started counting in Windows 2000.
So sort of like djb daemontools or (as you mentioned) upstart? It's not like systemd is the first thing to do this in Linux.
The big problem with DJB daemontools is that they are written by DJB and he doesn't like doing things in the same way as everyone else.
that accurately describes Lennart Pottering too. i know i'm not the only person who has described LP as "like DJB but without the talent to justify the arrogance". (i can't stand djb's software but it's undeniable that - even as misguided as he usually is - he know what he's doing when it comes to writing code. it might be doing the wrong thing, but it'll be doing it nearly perfectly)
Anyone who's going to argue against change to old interfaces and software is going to hate anything from DJB.
yep. and from LP too. daemontools sucked partly because it automagically did stuff just because files had been created in certain directories - this made it impossible to control when and how stuff got started or stopped because it would just do it whenever it felt like noticing changes had been made. qmail had similar problems - djb really like his programs to automagically do stuff without any ability to manually control it. djb's software also suffered from his brain-damaged ideas about copyright and licensing.
The syntax is not as friendly as upstart, but this is a minor detail. [...] and doesn't interfere with muscle memory by still being able to do "service foo restart".
upstart supports "service foo restart".
Upstart was the second choice of the Debian technical committee...
the TC was stacked with 2 upstart supporters, 2 systemd supporters, and the chairman also supported systemd. none of the other options (openrc, sysvinit) had a chance. the result was inevitable.
I find a good analogy for the way cgroups improves management is thinking about the ways in which virtualisation also improves management.
cgroups were also available long before systemd :-)
Was there any other init before systemd that used cgroups?
according to http://qnikst.github.io/posts/2013-02-20-openrc-cgroup.html openrc had "extended cgroups support" since at least feb 2013. i don't know if/when it had basic cgroups support before that. systemd proponents often tout "but systemd does cgroups" as if that's somehow remarkable or spectacularly difficult. it's not. they make the same "it's a miracle" claim for "socket activation" too as if that isn't something that inetd has been doing for decades (wow! listen on a port and then exec a program if something connects. so difficult!) a blogger by the name of Felipe Contreras wrote a good article (with sample code) called "Demystifying the init system" about a year ago in which he shows that these allegedly super-amazing and systemd-only features aren't particularly amazing or unique or special. https://felipec.wordpress.com/tag/sysvinit/ the things that systemd does that are useful aren't special or unique, and certainly aren't worth all the extra non-init baggage that systemd brings in. as an init system, there's nothing wrong with systemd. it's all the other stuff that it tries to do that's the problem...and it's getting kind of boring to hear systemd proponents respond to that particular point with tedious claims about systemd doing cgroups or having a wonderful scripting language (because sh is so scary) or some other irrelevant missing-the-point pseudo-rebuttal. the problem is not about systemd's init capabilities. the problem is all the other shit it tries to do. craig -- craig sanders <cas@taz.net.au>