7 ms·

This was an amazing review, and love systemd or hate it, this article gives a fantastic history and exposition of what systemd actually is. My favorite quote (

This was an amazing review, and love systemd or hate it, this article gives a fantastic history and exposition of what systemd actually is. My favorite quote (and when taken in context is much less tongue-in-cheek thank you might think): systemd is an event-driven object manager with dependency-like side effects which ‘boxes’ primitive kernel resources and userspace subsystems into a generic object type called Unit. These Unit objects are scheduled through the state propagation mechanism of ‘jobs’ and dynamically dispatched via a singleton object called Manager, responsible for launching jobs in ‘transactions’ which do merging, cyclic ordering and consistency checks and serve as the main point at which unit dependencies are pulled in. Unit startup is executed as a non-indempotent parallel dataflow with weak ordering guarantees on the job level, mostly independent of the active state of dependent units. Any night you have insomnia, just read that a few times and you'll be out like a light! :-)

throwawayboise 5y ago
It reads like an over-eager developer read Design Patterns and then was tasked with writing a new init system for Linux.
- throwaway984393 5y ago
  His name is Lennart Poettering, and apparently he was tasked with reinventing the entire operating system
  - b112 5y ago
    Quite true, and he was coerced! http://systemd-the-porno.com http://systemd-the-porno.com
    - kinghajj 5y ago
      ... I don't get it? Who is "Madeline" supposed to represent?
      - deleted 5y ago
        [deleted]
- arendtio 5y ago
  I think the whole problem with systemd wasn't just about technology. The results were spectacular. Before systemd normal Linux boot times were well over a minute. After switching you could get below 10 seconds on the same hardware. And that is just one aspect. I think the core of the problem was somewhere between the style of introducing changes and the way how people communicated. After all, it speaks for itself that pulseaudio and systemd shared a lot of common criticism. Both are technically sound systems today, but in a way, systemd was just the escalation of the pulseaudio debacle.
  - guenthert 5y ago
    SystemV init allows for init scripts to run in parallel, but that was rarely used. Most time spent was anyhow waiting for network (e.g. the MTA trying to resolve the hostname) and hardware initialization. Bourne shell isn't particularly fast, but ten years ago hardware used for typical Linux desktop/server systems was fast enough that it hardly mattered (it's used here for sequentially starting system processes, not number crunching). Not that it matters -- how often do you boot a desktop/server in a day? Performance mattered for VMs deployed in the cloud on request, but whether a full OS is the best choice for such services is a different topic ...
  - int_19h 5y ago
    Here's a good example. https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935
ratorx 5y ago
I’m a fan of this description. It might not be the easiest to understand or the first one you should read, but I wish more things had this kind of description somewhere (but not necessarily on the introductory materials or front page).
- rlonn 5y ago
  It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.
  - Spooky23 5y ago
    Exactly. “Idempotent” is one of the key words used as a cudgel in this way. It’s great for the bullshit artist, as to a layman the dictionary definition is completely inscrutable.
    - bollu 5y ago
      Idempotence is a desirable property of systems whereby repeating an action has no effect. Mathematically, an operator is idempotent if f(f(x)) = f(x). Idempotence is handy because it implies that one can retry safely if one isn't sure whether something succeeded or failed. Not sure if your file was saved? Save again! If it was indeed saved, the file continues to be saved. If the file was not saved, it is now. Yay. I would kill for such descriptions of every system I work with.
    - lifeisstillgood 5y ago
      Idempotent is surely a valuable piece of software jargon. I know exactly what the user intends, and have good ideas of how hard it is and what likely trade offs they will be making behind the scenes surely it is the very opposite of bullshit.
      - bjourne 5y ago
        But the phrase in the paragraph is non-idempotent which is completely redundant. Every piece of software in the world is non-idempotent.
zozbot234 5y ago
...so, how does a systemd unit definition differ from a Makefile (other than using a different syntax, obviously)? What features would you need to add to UNIX make (and PID 1, for that matter) in order to be able to separate out this whole dependency management business from the other stuff PID 1 has to deal with already?
- eternityforest 5y ago
  For one thing make is imperative and doesn't actually know what it's doing. Systemd is declarative. You'd need to replace all the options service files give you. Make doesn't do dependencies between unrelated projects. A makefile can't say "I want to run if X runs, but I should run before them". Make doesn't have supervision, you'd need some kind of declaratively configured poller. Systemd is also parallel, there's probably some complexity there that make might or might not handle well. I think the most important problems would only be obvious once you started using a replacement system though. Systemd almost totally replaces the need for any imperative code whatsoever for process autostart, configuration, and supervision, and that might be hard to do in a more modular setup. You don't need extra stuff besides the service file. Everything is extremely consistent and done the same way for every service.
  - hedora 5y ago
    Everything statement that comment makes about make is incorrect, except the bit about polling. Polling is better-addressed by having each service implement its own error handling. Restart loops are the wrong policy for most services. In the rare cases where they are actually the correct behavior, they’re trivial for the service author to implement. Those that don’t understand make are doomed to reimplement it poorly.
    - eternityforest 5y ago
      How are restart loops the wrong policy? If it should be running, and it's not, how else would I fix it except by restarting it? They're not exactly trivial. There's restart delay, number of times to restart, passing stdout through so the journal can get it, and there's failure reporting. How is PID 1 supposed to know if my service failed when the restart daemon is still up and running, but my actual app keeps crashing? How can it tell the difference between my app and a supervisor, or a fully failed app or just one failed subprocess that my app can handle? Now you need some scheme for that. If PID1 doesn't know what's failed, how would I get a list of all failed systems programmatically? Systemd could provide a standard supervisor component, but then it couldn't ever do anything but restart failed apps, or you're back to people complaining about monoliths. You'd have to have your service file explicitly call it with some command line args making your syntax uglier. And more importantly, it might be harder for the systemd dev team because now they have a communication protocol between this restart daemon and everything else. Or they could leave restart daemons up to the user... and everyone would probably choose 3 different ones, that might or might not keep up with compatibility. That would break the "One and only one obvious way" principle. When you start splitting stuff up in tiny bits, you get more overhead, all the extra nice features seem to evaporate.
deleted 5y ago
[deleted]

throwawayboise 5y ago

It reads like an over-eager developer read Design Patterns and then was tasked with writing a new init system for Linux.

throwaway984393 5y ago
His name is Lennart Poettering, and apparently he was tasked with reinventing the entire operating system
- b112 5y ago
  Quite true, and he was coerced! http://systemd-the-porno.com http://systemd-the-porno.com
  - kinghajj 5y ago
    ... I don't get it? Who is "Madeline" supposed to represent?
    - deleted 5y ago
      [deleted]
arendtio 5y ago
I think the whole problem with systemd wasn't just about technology. The results were spectacular. Before systemd normal Linux boot times were well over a minute. After switching you could get below 10 seconds on the same hardware. And that is just one aspect. I think the core of the problem was somewhere between the style of introducing changes and the way how people communicated. After all, it speaks for itself that pulseaudio and systemd shared a lot of common criticism. Both are technically sound systems today, but in a way, systemd was just the escalation of the pulseaudio debacle.
- guenthert 5y ago
  SystemV init allows for init scripts to run in parallel, but that was rarely used. Most time spent was anyhow waiting for network (e.g. the MTA trying to resolve the hostname) and hardware initialization. Bourne shell isn't particularly fast, but ten years ago hardware used for typical Linux desktop/server systems was fast enough that it hardly mattered (it's used here for sequentially starting system processes, not number crunching). Not that it matters -- how often do you boot a desktop/server in a day? Performance mattered for VMs deployed in the cloud on request, but whether a full OS is the best choice for such services is a different topic ...
- int_19h 5y ago
  Here's a good example. https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935

ratorx 5y ago

I’m a fan of this description. It might not be the easiest to understand or the first one you should read, but I wish more things had this kind of description somewhere (but not necessarily on the introductory materials or front page).

rlonn 5y ago
It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.
- Spooky23 5y ago
  Exactly. “Idempotent” is one of the key words used as a cudgel in this way. It’s great for the bullshit artist, as to a layman the dictionary definition is completely inscrutable.
  - bollu 5y ago
    Idempotence is a desirable property of systems whereby repeating an action has no effect. Mathematically, an operator is idempotent if f(f(x)) = f(x). Idempotence is handy because it implies that one can retry safely if one isn't sure whether something succeeded or failed. Not sure if your file was saved? Save again! If it was indeed saved, the file continues to be saved. If the file was not saved, it is now. Yay. I would kill for such descriptions of every system I work with.
  - lifeisstillgood 5y ago
    Idempotent is surely a valuable piece of software jargon. I know exactly what the user intends, and have good ideas of how hard it is and what likely trade offs they will be making behind the scenes surely it is the very opposite of bullshit.
    - bjourne 5y ago
      But the phrase in the paragraph is non-idempotent which is completely redundant. Every piece of software in the world is non-idempotent.

zozbot234 5y ago

...so, how does a systemd unit definition differ from a Makefile (other than using a different syntax, obviously)? What features would you need to add to UNIX make (and PID 1, for that matter) in order to be able to separate out this whole dependency management business from the other stuff PID 1 has to deal with already?

eternityforest 5y ago
For one thing make is imperative and doesn't actually know what it's doing. Systemd is declarative. You'd need to replace all the options service files give you. Make doesn't do dependencies between unrelated projects. A makefile can't say "I want to run if X runs, but I should run before them". Make doesn't have supervision, you'd need some kind of declaratively configured poller. Systemd is also parallel, there's probably some complexity there that make might or might not handle well. I think the most important problems would only be obvious once you started using a replacement system though. Systemd almost totally replaces the need for any imperative code whatsoever for process autostart, configuration, and supervision, and that might be hard to do in a more modular setup. You don't need extra stuff besides the service file. Everything is extremely consistent and done the same way for every service.
- hedora 5y ago
  Everything statement that comment makes about make is incorrect, except the bit about polling. Polling is better-addressed by having each service implement its own error handling. Restart loops are the wrong policy for most services. In the rare cases where they are actually the correct behavior, they’re trivial for the service author to implement. Those that don’t understand make are doomed to reimplement it poorly.
  - eternityforest 5y ago
    How are restart loops the wrong policy? If it should be running, and it's not, how else would I fix it except by restarting it? They're not exactly trivial. There's restart delay, number of times to restart, passing stdout through so the journal can get it, and there's failure reporting. How is PID 1 supposed to know if my service failed when the restart daemon is still up and running, but my actual app keeps crashing? How can it tell the difference between my app and a supervisor, or a fully failed app or just one failed subprocess that my app can handle? Now you need some scheme for that. If PID1 doesn't know what's failed, how would I get a list of all failed systems programmatically? Systemd could provide a standard supervisor component, but then it couldn't ever do anything but restart failed apps, or you're back to people complaining about monoliths. You'd have to have your service file explicitly call it with some command line args making your syntax uglier. And more importantly, it might be harder for the systemd dev team because now they have a communication protocol between this restart daemon and everything else. Or they could leave restart daemons up to the user... and everyone would probably choose 3 different ones, that might or might not keep up with compatibility. That would break the "One and only one obvious way" principle. When you start splitting stuff up in tiny bits, you get more overhead, all the extra nice features seem to evaporate.

deleted 5y ago

[deleted]