6 ms·

Systemd is at odds with the core design philosophy of UNIX. That is do one thing and do it well. Systemd has been brilliant for speeding up the boot speed, than

by acd 7y ago

Systemd is at odds with the core design philosophy of UNIX. That is do one thing and do it well. Systemd has been brilliant for speeding up the boot speed, thanks for that! But I do understand the controversy of systemd design. Thanks to all great Debian developers!

jasonvorhe 7y ago
It is not, because it's made of modules that do one thing very well which are then woven together, to work in unison, which is opt-in for distribution maintainers to configure. systemd at it's core is very much adhering to UNIX principles.
- AdieuToLogic 7y ago
  > 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.
  - oblio 7y ago
    Unix itself doesn't adhere to Unix principles. The Unix philosophy died when ls learned to sort its output and find learned to execute commands. Perl, the do-all tool, was the final nail in the Unix philosophy, way back in the 80's.
    - AdieuToLogic 7y ago
      > Unix itself doesn't adhere to Unix principles. 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 Now there are many command options which have been added to 'ls' over the decades, no doubt. But you partially identified the death of "The Unix philosophy" as being "when ls learned to sort," so let's focus on that. 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 This leaves the remaining conjunctive clause of "do it well." 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 http://doc.cat-v.org/unix/find-history 1 - https://www.freebsd.org/cgi/man.cgi?query=ls&apropos=0&sektion=0&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=ls&apropos=0&sekti... 2 - https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_a... 3 - https://www.freebsd.org/cgi/man.cgi?query=sort&apropos=0&sektion=0&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=sort&apropos=0&sek... 4 - https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
- gorgoiler 7y ago
  INI files and usingCamelCase always felt like an odd choice for something trying to replace the heart of a Unix system. 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.
NilsIRL 7y ago
Systemd seems so big because of the way it is branded when in fact it is many different parts put together. What people refer to as systemd is many different parts that have been branded as such. 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 http://0pointer.de/blog/projects/the-biggest-myths.html [0]: https://www.gnu.org/software/software.en.html#allgnupkgs https://www.gnu.org/software/software.en.html#allgnupkgs
diffeomorphism 7y ago
Systemd-init does one thing and does it well. Logind does one thing and does it well, etc. . GNU and FreeBSD are then also at odds with the core design philosophy of UNIX. Speeding up booting is a nice side benefit but not at all what systemd is about.
- fanf2 7y ago
  journald is a disaster area and is the main thing that makes me avoid systemd.
- roelschroeven 7y ago
  > 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). [0] http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html
  - diffeomorphism 7y ago
    Same source http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html lists it as most common myth number 2. > 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".
coffeeaddicted 7y ago
Not sure about boot speed. At least on my system booting Debian became noticably slower in Debian 8,9 and again in 10. Maybe simply because software got larger or because I didn't do clean installs but upgraded my existing system, I don't know. But the only boot speed improvement I got in the last years was switching to SSD. Thought I do like that with systemd you can at least find out easier which parts slow down the boot process.
2ion 7y ago
> Systemd is at odds with the core design philosophy of UNIX 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.

by acd 7y ago

jasonvorhe 7y ago

It is not, because it's made of modules that do one thing very well which are then woven together, to work in unison, which is opt-in for distribution maintainers to configure. systemd at it's core is very much adhering to UNIX principles.

AdieuToLogic 7y ago
> 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.
- oblio 7y ago
  Unix itself doesn't adhere to Unix principles. The Unix philosophy died when ls learned to sort its output and find learned to execute commands. Perl, the do-all tool, was the final nail in the Unix philosophy, way back in the 80's.
  - AdieuToLogic 7y ago
    > Unix itself doesn't adhere to Unix principles. 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 Now there are many command options which have been added to 'ls' over the decades, no doubt. But you partially identified the death of "The Unix philosophy" as being "when ls learned to sort," so let's focus on that. 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 This leaves the remaining conjunctive clause of "do it well." 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 http://doc.cat-v.org/unix/find-history 1 - https://www.freebsd.org/cgi/man.cgi?query=ls&apropos=0&sektion=0&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=ls&apropos=0&sekti... 2 - https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_a... 3 - https://www.freebsd.org/cgi/man.cgi?query=sort&apropos=0&sektion=0&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=sort&apropos=0&sek... 4 - https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
gorgoiler 7y ago
INI files and usingCamelCase always felt like an odd choice for something trying to replace the heart of a Unix system. 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.

NilsIRL 7y ago

Systemd seems so big because of the way it is branded when in fact it is many different parts put together. What people refer to as systemd is many different parts that have been branded as such. 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 http://0pointer.de/blog/projects/the-biggest-myths.html [0]: https://www.gnu.org/software/software.en.html#allgnupkgs https://www.gnu.org/software/software.en.html#allgnupkgs

diffeomorphism 7y ago

Systemd-init does one thing and does it well. Logind does one thing and does it well, etc. . GNU and FreeBSD are then also at odds with the core design philosophy of UNIX. Speeding up booting is a nice side benefit but not at all what systemd is about.

fanf2 7y ago
journald is a disaster area and is the main thing that makes me avoid systemd.
roelschroeven 7y ago
> 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). [0] http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html
- diffeomorphism 7y ago
  Same source http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html lists it as most common myth number 2. > 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".

coffeeaddicted 7y ago

Not sure about boot speed. At least on my system booting Debian became noticably slower in Debian 8,9 and again in 10. Maybe simply because software got larger or because I didn't do clean installs but upgraded my existing system, I don't know. But the only boot speed improvement I got in the last years was switching to SSD. Thought I do like that with systemd you can at least find out easier which parts slow down the boot process.

2ion 7y ago

> Systemd is at odds with the core design philosophy of UNIX 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.