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

Re: I'm not a huge fan of systemd

On 2014-07-05 20:25 +0200, Steve Litt wrote:

> 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.

I don't think that Debian is that different from Ubuntu or Mint here.

> In the beginning, booting up was just a bunch of shellscripts. Crude,
> but effective, and everything reachable with Vim or vi.

It's crude, but anything than effective.

> 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.

Systemd is anything but monolithic, it includes several dozen programs
many of which are precisely "doing one thing and doing it well".  E.g.
the common task of creating a directory/file/socket etc. under /tmp or
/run is accomplished by systemd-tmpfiles, and packages can just drop a
snippet in /usr/lib/tmpfiles.d do declare what they want.

In the sysvinit world, every package who wants that needs an init script
which contains the necessary mkdir/mkfifo/chown/chmod commands plus a
lot of boilerplate.

> And most un-Unix of all,
> from what I understand it has binary log files.

It is true that systemd's logs are binary which means you need a
separate tool (journalctl) to access them, but text log files don't go
away, you just install a syslog daemon and systemd forwards the logs to

> 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.

That's exactly how systemd units work.  One notable difference to init
scripts is that they are much shorter and easier to understand, plus you
can exactly override the parts you want to change - no need to answer
questions at the dpkg conffile prompt and merge your changes back in
later (I have done that often enough to know how annoying it is).

> 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.

In the standard Debian setup, the journal is not even written to disc
but only exists on a tmpfs, so you are not going to have that problem.

> It looks to me like the main goals are to boot faster, and to tie
> everything together better.

Booting faster is not really a main goal, tighter integration - yes,
systemd aims to reduce the differences between the various Linux
distributions.  However, most parts of it are optional, and in cases
where Debian currently has a superior solution (binfmt-misc and
console-setup come to mind), the corresponding systemd service is

> 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 would recommend not to install systemd-sysv right away, but to stick
to sysvinit-core and boot with init=/lib/systemd/systemd so that it's
easier to switch back to sysvinit if necessary.

Nearly all major GNU/Linux distributions are switching to systemd or
have already done so, I think Gentoo and Slackware are the only
prominent exceptions.  Of course there are other choices like the BSDs
or Android.

> 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
> switch.

So far none of the systemd antagonists has been able to come up with a
plan B, but time will tell.


Reply to: