Thanks to all great Debian developers!
It's like saying gnu is bloated because it is 395 different packages [0].
You might want to read this blog post: http://0pointer.de/blog/projects/the-biggest-myths.html
[0]: https://www.gnu.org/software/software.en.html#allgnupkgs
Speeding up booting is a nice side benefit but not at all what systemd is about.
That's a claim I've seen before. Maybe it's true, but it's not what I get from reading the initial introduction "Rethinking PID 1" [0] is that systemd is very much about fast booting. That blog story says:
"As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast.
For a fast and efficient boot-up two things are crucial:
- To start less.
- And to start more in parallel.The remainder of the post talks mainly about those things. In my mind, that clearly means that fast booting was the major design goal of the project.
(Off topic to your comment, but what the post does not talk about is taking over lots of unrelated services. Even the name of Poettering's blog, "Pid Eins", seemed to indicate that systemd was meant only as an init-implementation. That would have been a lot better).
> This doesn't mean being fast was irrelevant for us, but reducing systemd to its speed is certainly quite a misconception, since that is certainly not anywhere near the top of our list of goals.
> That would have been a lot better
Yeah, I noticed that all the complaints about systemd almost never are about the init implementation. Instead people complain about journald (e.g. binary=plain text+time stamp instead of just plain text) or networkd or about Poettering or how there is some shadowy conspiracy. Honestly, I think if all the non-init parts had another name like "linux plumbing project" and were developed separately by non-Poettering, much fewer people would complain (even though the software is the exact same).
It would also make discussions much clearer if people said in the beginning what exactly they are complaining about, e.g. "logind is buggy" instead of "systemd is evil".
Indeed it does.
As said before, Poettering opens his introductory blog post "Rethinking PID 1" with a bit of history, and then immediately writes "As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast." That's the very first thing he writes about systemd. And the speed of booting comes up again and again in the blog post. Then how can it not have been one if his major considerations?
So he's contradicting himself, or he changed his mind in the three years between those blog posts.
> It would also make discussions much clearer if people said in the beginning what exactly they are complaining about, e.g. "logind is buggy" instead of "systemd is evil".
That's what one gets if one puts everything under the same name, throw everything in one tarball.
systemd at it's core is very much adhering to UNIX principles.
Speaking only for myself and every Unix developer and system administrator I have ever met:
No, systemd in no way, shape, or form adheres to well known Unix prinicples.
Perl, the do-all tool, was the final nail in the Unix philosophy, way back in the 80's.
Principles != dogma.
> The Unix philosophy died when ls learned to sort its output and find learned to execute commands.
As for "find", I leave the explanation of it to this[0] recounting. Suffice to say that one command doth not a philosophy make.
Regarding "ls learned to sort", let's put this trope to rest, shall we?
The 'ls' command, as I am sure you and all whom read this posting are aware, is described[1] as:
NAME
ls -- list directory contents
The implication of that assessment, in this context, I assume to be a reference to "do one thing and do it well."[2]
Which begs the question; what is the one thing which 'ls' must do? Given the summary description quoted above, that "one thing" is:
list directory contents
Since the operation of 'ls' includes both filtering and production due to the functional requirement of having to "list directory contents", there exists two disjoint concerns which must be addressed in order to satisfy the goal of "do it well." For example, an invocation can involve identifying C source files ("*.[ch]"), yet want the production of the files which match based on when each file was last modified ("-c").
To achieve sorting on the modification time using another program, such as sort[3], would require 'ls' produce both the desired output as well as out-of-band information needed to sort[3]. This also implies that the desired sorting (such as numeric or lexiographic) must be provided out-of-band as well. And this, too, would imply that sort[3] is made aware of what/where the out-of-band data can be found. All of this leads to a "Leaky Abstraction."[4]
Instead, if one identifies the functional requirement of 'ls' to treat both filtering and production as coequal concerns when listing directory contents, the need for 'ls' to "learn to sort" becomes self-evident.
0 - http://doc.cat-v.org/unix/find-history
1 - https://www.freebsd.org/cgi/man.cgi?query=ls&apropos=0&sekti...
2 - https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_a...
3 - https://www.freebsd.org/cgi/man.cgi?query=sort&apropos=0&sek...
4 - https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
Of course, these choices don’t matter at all in the grand scheme of things, but it’s also these little design differences that seem to nudge systemd into the contrarian oddball bucket, for me.
Kind of like the summer intern that wants to refactor lots of code and changes the coding style while doing so.
No. All the enterprise Unix OSs had advanced system management facilities that a mesh of RC scripts well before Linux (the OSS Unix OSs still mostly don't). Whatever the core design philosophy of Unix was or is, mostly people who do work on it as a hobby seem to care.