Re: administration of initscripts
On 04/16/2013 04:33 AM, Kevin Chadwick wrote:
The Unix Philosophy is overapplied and used way too much like gospel. Is
it a bad approach to system software? No, of course not! Is it the One
True Way and Every Other Other Way the worst/evil? No, of course not!
+ dropping human readable textfiles in favour of c binary code, which makes it
needless more complex to debug the whole show.
That's non-sense. systemd unit files are text-files in ini-like format
and much more readable then shell scripts with all their boiler plate.
I think you miss the point which is those unit files depend on C code
that is not as easy to follow or as well documented as tools which
follow the unix philosophy such as grep and you also don't seem
to have read between the lines about the detail of "more complex to
In any case systemd has had more attention than it deserves so look
inthis archive or likely any other archive (Gentoos a good one for
a balanced view) and lwn.net for the arguments and make your own
decision. Just don't believe the hype and understand that many pages on
freedesktop.org aren't official or balanced but abused as if they are.
The problem with the Unix Philosophy is it was created in a day where
its design principles actually were essential. Today it really is less
important and in some ways detrimental in software engineering.
Am I saying the "do everything" approach is best? Absolutely not. But
that's not systemd's goal either. It's just expanded from being merely a
drop-in init replacement with a nice feature set to being something that
is probably better for Linux, being a full-scale system manager with
The problem with those "objective" views of systemd you speak of is that
they're entirely based on incorrect assertions of precisely how systemd
works. A lot of people, for example, automatically assume that systemd
is "against" shell scripts. This is simply not true. It can run shell
scripts, even init scripts, just fine. It's just that it identifies that
shell scripts needn't be a *requirement* in bringing up or breaking down
a system. It really is better for the init system to use a minimal
approach to invoking daemons as systemd does and no initscript does. And
of course, if you need to do more than just "run a binary" in the unit
file, systemd doesn't stop you from using an initscript approach either.
As far as "C code that is easy to follow and is well documented" I
should point out a couple things.
I don't see why it's important to know how systemd works at the SOURCE
level to write a unit. Unit files are very simple and systemd has very
well-written documentation on how to make/interpret unit files for
yourself. I should also point out that those "Unix Philosophy" tools you
cite, as well are "C code that is not easy to follow and is not well
documented." Ever try to grok grep's source code? Have you ever needed
to to understant how you use it?
Systemd is just as open source as any other compiled program you use on
Linux, and I find this argument lacking in merit. I'm a programmer. I'd
like to think I'm a skilled programmer. Do I REALLY need to know how
GCC, the Linux kernel, Xorg, vi, ZSH, or any other of my tools are
programmed to use them? Nope. All I need is good documentation on how to
use them (And whatever APIs I program with.).
Further, I also don't see it essential to delve into systemd's source
code to debug unit files. In fact, I do believe systemd provides more
than a suffificient framework to debug unit files. It just won't provide
one to debug whatever it launches. Code quality of someone else's
programming is not and should not be a goal of systemd. If you're using
a buggy initscript in systemd, then look at the initscript, which
systemd merely launched.
I concede there's plenty of hype about systemd. But SysV really does
need to be laid to rest, and Upstart does things in a very backwards
way. OpenRC is good, but not as fast/flexible/well supported as systemd,
and was primarily designed for Gentoo.