[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

I'm not a huge fan of systemd

First things first: I'm Steve Litt, using the same email address I've
used since 1996. You may or may not believe me a troll, but you have to
admit I'm not some guy coming around yet again with new email address,
trying to fool everybody.

Anyway, I don't think a dislike of systemd is, by necessity, offtopic.
Systemd is a substantial change, not only in the operating system, but
in philosophy. Unix was built as a sort of Erector Set emphasizing a
bunch of small parts that could be bolted together, with each part
doing one thing and doing it well. Where else can you write an entire
data processing application with a pipeline of repeated grep, sed, awk,
sort, and cut?.

With the advent of GUI, some compromises were made to the Unix
Philosophy, but command line Linux in all distros has always adhered
pretty well to the Unix Philosophy. In the case of Debian, even the GUI
adheres to the Unix Philosophy pretty well, a point that separates
Debian from Ubuntu, Mint, and OS/x.

In the beginning, booting up was just a bunch of shellscripts. Crude,
but effective, and everything reachable with Vim or vi. Then there was
that upstart thing: a little more convoluted, but still somewhat
conformant to the Unix Philosophy. Now comes systemd, which, from what
I've heard, is a further step away from the Unix Philosophy, in that it
is more monolithic and exerts more control and more continuous control
over all programs, from what I understand. And most un-Unix of all,
from what I understand it has binary log files.

The DOS (and Windows) Philosophy was one of monolith, with hooks into
the monolith via autoexec.bat, config.sys, and (later) the registry.
Programs were big and binary, with binary inputs and output files
readable only by the specific program, or a converter or program with
an importer or exporter. The Unix philosophy is a bunch of parts
configured together, mainly communicating with readable text, and if
you want to change things, you reconfigure.

In other words, from what I hear about systemd, it would be more
acceptable in Windows. And all this begs the question: Why fix
something that's already working just fine? And why fix it with
something that's more monolithic and black boxy, with binary log files
that are going to a problem if you must go in with a rescue disc.

It looks to me like the main goals are to boot faster, and to tie
everything together better. As far as tying everything together, that's
what I want to avoid. And as far as booting quickly, Linux people don't
boot often, so the only time this is relevant is those maintaining a
very strict level of service, for whom theoretically systemd could be a
(welcome) option.

My plan is to switch to systemd, see how I like it, and if I don't,
install the old boot system, or if that can no longer be done, switch
distros. I don't see systemd as the end of the world. *But*, I think a
discussion of a plan B is very ontopic, because if the conversion to
systemd turns out to be even 1/10 the fiasco that the kmail to kmail2
change was, we all need a systemd alternative, and a plan to make that


Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

Reply to: