> From: [email protected] [mailto:discuss-
> [email protected]] 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.
_______________________________________________
Discuss mailing list
[email protected]
http://lists.blu.org/mailman/listinfo/discuss
