[Discuss] SysVinit vs. systemd

[blu at nedharvey.com (Edward Ned Harvey (blu))]

> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> bounces+blu=nedharvey.com at blu.org] On Behalf Of Tom Metro
> 
>   Mike Gancarz sums up the Unix philosophy: 1. Small is beautiful. 2.
>   Make each program do one thing well. ... 

Ok, I'm just going to start by naming a few situations where that was a bad idea.

1- For example, you can do something like "find somedir -type f -exec grep -l somestring {} \;" and this adheres to the above principles where each tool does one job and does it well, but you're missing the potential to benefit by integrating the peanut butter & chocolate combination which is frequently seen together.  So then the makers of grep realized they're getting thousands of new processes spawned and wasting a lot of time, so now you can equivalently do "grep -lr somestring somedir" which is simpler, more compact, easier to read/write, and also much faster, because it's integrated.

2- There are lots of other situations, where some extremely specific switch was added to an otherwise basic simple tool, despite the fact that the same thing could have been accomplished by stringing together multiple basic tools.  It was *useful* to integrate it and thus make the tool bigger and more complex.  "ls" built-in sort instead of using /bin/sort.  "cat" has an option to number lines, instead of using awk or whatever.  Also has a "squeeze" option to be used instead of " | grep -v '^$'".  "pgrep" and "pkill" instead of their obvious counterparts based on grep & kill.  "less" is more than "more".  etc etc etc.  This is a huge, huge list.


>   We have built the Internet
>   and all modern Internet services on those principles. 

I have to say:  I couldn't disagree more.  I would never call apache, nginx, php, mysql, postgres, selinux, apparmor, iptables, or about a hundred other common standard languages, applications, and internet service tools "simple" or "small" or even "beautiful."


>   Systemd's design
>   and implementation violates nearly all of them.

Now that we've completely debunked the entire premise, let's finally address some of this:

The first and most obvious response I have to this is startup time.  The traditional /etc/init.d structure is designed to be serial, where the person who configured it is required to be aware of the dependencies in order to set the serial ordering.  And while the system would be perfectly fine starting half a dozen processes at the same time, it can't.  

Sometimes the entire startup process hangs because one service failed to exit its startup script.

Support for service dependencies, parallelization, and the ability to make it trivially easy to daemonize any random process you'd like to daemonize...  Are all benefits.

*More* importantly, I find it's not more complex, but *less* complex.  Instead of needing to know "Well, you could /etc/init.d/fooservice, or 'service fooservice' or /etc/rc3.d/S55fooservice or ..."  now you just have one command.  "initctl" which could not get any easier.