5 ms·

> systemd has long since outstripped what’s required of an init system I think this is the fundamental disconnect. systemd isn't an init system. It's a colle

by efaref 6y ago

> systemd has long since outstripped what’s required of an init system I think this is the fundamental disconnect. systemd isn't an init system. It's a collection of useful programs for general running of a system, including but not limited to an init program.

horsawlarway 6y ago
I also think folks tend to underestimate just how many things you end up needing to support various init schemes. Every single item listed under his "Some of the daemons provided by systemd are:" example is something that could have a meaningful impact to startup depending on configuration. They happen to be useful later too, but that doesn't mean the system doesn't need them during init.
ssivark 6y ago
I also feel that it’s useful to take a pragmatic perspective on what an init system must cover. As someone who uses linux on the laptop, everything from boot to getting to a usable desktop is part of the “init” as far as I’m concerned. And I love the fact that there is a unified orchestration of all the necessary details (hardware devices, network connections, etc/whatever) to get me to a nice working environment fast. I don’t see what is there to complain about that! Also, I find it strange how folks randomly get hung up on “Unix philosophy” without consistency, or regard for relevance (Per the Unix philosophy, you should not be checking email on a browser meant for webpages). It’s not like Unix is some pinnacle of system design. It was a good thing for 50 years ago, but our computers and our needs have evolved significantly since then.
- danudey 6y ago
  Here's my hot take: systemd actually embodies the so-called "UNIX philosophy" better than any of the other alternatives. The UNIX philosophy is theoretically "do one thing and do it well", but in practice means "create small, composable pieces which can be used together or separately to accomplish what you need." "systemd" the project is certainly huge and all-encompassing, but you could say the same thing about GNOME, the GNU project, or even GCC itself. The systemd project, however, is divided up into a ton of smaller components, all of which are relatively easy to understand in isolation and which almost universally have clear interoperations with each other. Case in point: systemd ships two components, systemd-networkd and systemd-resolved. I typically reconfigure my systems to use these, as I find the documentation simple to understand and the config file easy to write by hand, even from memory. Compare this to, say, netplan, which I've never actually googled a full list of options for. That said, both of them are optional, and Ubuntu 16.04 for example used systemd in what was apparently as few places as possible, notably not using systemd-networkd or systemd-resolved. They were easy to enable and use, but they were by no means necessary. LIkewise, systemd ships systemd-machined, a framework for creating "machines", which are containerized systems which operate like virtualized systems, with their own copy of (probably) systemd running inside. The systemd tools, like systemctl and journalctl, can interact directly with these machines, meaning that you can use the same tools on the same command-lines to access what is effectively a "containerized" system's logs in the same way that you would locally. Likewise, systemd-networkd has configuration to automatically bring up their network configs as soon as they're created, without having to do anything manually. Again, it's not shipped by default and definitely not enabled by default. In this way, I would say that systemd actually embodies the so-called "UNIX philosophy", by creating a bunch of separate daemons and systems, all of which can work well together but few of which are inherently required by each other. It also adds a ton of functionality which is effectively impossible to add to existing init.d systems in any maintainable way (like spawning processes in their own cgroups and namespaces, creating ephemeral users with arbitrary UIDs for those processes, creating private /tmp directories for individual services, adding bind mounts, restricting syscalls, mounting the root filesystem read only, and so on. In essence, systemd gives you all the tools you need to build up whatever system management you want, but if you just want "execute this binary, which will not fork, and keep it running" then you can do that too, without any of those extra features getting in the way.
  - bcrl 6y ago
    If systemd was written by someone with just a bit more taste in structure and APIs, I might believe you, but that just isn't the case. Why do I have to wait for several minutes to boot or reboot my machine when something goes odd with one of the services (like dns not working due to a transient network issue)? Why was ntsysv and chkconfig support (the baby) thrown out with the bathwater until almost a decade after systemd was introduced? The author has consistently demonstrated that he does not have the ability to make decisions that take into account the sysadmin / end user experience when things go awry. That's what frustrates me about systemd. At least I was able to debug the shell scripts that shipped with sysvinit. These days I have no control over that part of my machine. Fwiw, the same disease infected gnome a long time ago as well. One day my key bindings surprisingly changed from unix to windows style in an update. Then I lost the ability to customize the widgets surrounding windows by the window manager. Control over focus follows mouse was lost... It drove me away as a user because my preferences were no longer worth supporting. I guess I'm just turning into a grey beard at this point. Sigh.
    - SahAssar 6y ago
      > Why do I have to wait for several minutes to boot or reboot my machine when something goes odd with one of the services (like dns not working due to a transient network issue)? Because one of your other services has said it depends on network.target/network-online.target and is in the critical path of your boot. Check which one with "systemd-analyze plot > plot.svg" and "systemd-analyze dot 'network.*' | dot -Tsvg >network.svg". You can also see the critical chain and which parts block faster boot with "systemd-analyze critical-chain". I think if you stopped expecting systemd to act like something else and instead treated it like the toolkit that it is you'd see that it does what it says it does quite well. Those issues with boot you mentioned are often that the distro ships a bad systemd config for a certain program.
      - bcrl 6y ago
        Why do you think systemd is defendable for this? The prior init system had a means by which individual init scripts could be disabled during boot. I can't run systemd-analyze when the system off in lala-land for 5+ minutes. Moreover, if I know what is wrong, why can't I just cancel the job it's waiting for like I could previously from the console? It is a unacceptably bad user interface experience. There is no excuse for it. Again, this worked previously - why was this functionality lost / hidden? It's this "punch the user in the face" style of user interface design that I object to that is so prevalent in the corner cases of modern UIs.
dTal 6y ago
The term is "middleware". It's OS middleware. It's an attempt to create a third level between "kernel" and "userspace".

by efaref 6y ago

horsawlarway 6y ago

I also think folks tend to underestimate just how many things you end up needing to support various init schemes. Every single item listed under his "Some of the daemons provided by systemd are:" example is something that could have a meaningful impact to startup depending on configuration. They happen to be useful later too, but that doesn't mean the system doesn't need them during init.

ssivark 6y ago

I also feel that it’s useful to take a pragmatic perspective on what an init system must cover. As someone who uses linux on the laptop, everything from boot to getting to a usable desktop is part of the “init” as far as I’m concerned. And I love the fact that there is a unified orchestration of all the necessary details (hardware devices, network connections, etc/whatever) to get me to a nice working environment fast. I don’t see what is there to complain about that! Also, I find it strange how folks randomly get hung up on “Unix philosophy” without consistency, or regard for relevance (Per the Unix philosophy, you should not be checking email on a browser meant for webpages). It’s not like Unix is some pinnacle of system design. It was a good thing for 50 years ago, but our computers and our needs have evolved significantly since then.

danudey 6y ago
Here's my hot take: systemd actually embodies the so-called "UNIX philosophy" better than any of the other alternatives. The UNIX philosophy is theoretically "do one thing and do it well", but in practice means "create small, composable pieces which can be used together or separately to accomplish what you need." "systemd" the project is certainly huge and all-encompassing, but you could say the same thing about GNOME, the GNU project, or even GCC itself. The systemd project, however, is divided up into a ton of smaller components, all of which are relatively easy to understand in isolation and which almost universally have clear interoperations with each other. Case in point: systemd ships two components, systemd-networkd and systemd-resolved. I typically reconfigure my systems to use these, as I find the documentation simple to understand and the config file easy to write by hand, even from memory. Compare this to, say, netplan, which I've never actually googled a full list of options for. That said, both of them are optional, and Ubuntu 16.04 for example used systemd in what was apparently as few places as possible, notably not using systemd-networkd or systemd-resolved. They were easy to enable and use, but they were by no means necessary. LIkewise, systemd ships systemd-machined, a framework for creating "machines", which are containerized systems which operate like virtualized systems, with their own copy of (probably) systemd running inside. The systemd tools, like systemctl and journalctl, can interact directly with these machines, meaning that you can use the same tools on the same command-lines to access what is effectively a "containerized" system's logs in the same way that you would locally. Likewise, systemd-networkd has configuration to automatically bring up their network configs as soon as they're created, without having to do anything manually. Again, it's not shipped by default and definitely not enabled by default. In this way, I would say that systemd actually embodies the so-called "UNIX philosophy", by creating a bunch of separate daemons and systems, all of which can work well together but few of which are inherently required by each other. It also adds a ton of functionality which is effectively impossible to add to existing init.d systems in any maintainable way (like spawning processes in their own cgroups and namespaces, creating ephemeral users with arbitrary UIDs for those processes, creating private /tmp directories for individual services, adding bind mounts, restricting syscalls, mounting the root filesystem read only, and so on. In essence, systemd gives you all the tools you need to build up whatever system management you want, but if you just want "execute this binary, which will not fork, and keep it running" then you can do that too, without any of those extra features getting in the way.
- bcrl 6y ago
  If systemd was written by someone with just a bit more taste in structure and APIs, I might believe you, but that just isn't the case. Why do I have to wait for several minutes to boot or reboot my machine when something goes odd with one of the services (like dns not working due to a transient network issue)? Why was ntsysv and chkconfig support (the baby) thrown out with the bathwater until almost a decade after systemd was introduced? The author has consistently demonstrated that he does not have the ability to make decisions that take into account the sysadmin / end user experience when things go awry. That's what frustrates me about systemd. At least I was able to debug the shell scripts that shipped with sysvinit. These days I have no control over that part of my machine. Fwiw, the same disease infected gnome a long time ago as well. One day my key bindings surprisingly changed from unix to windows style in an update. Then I lost the ability to customize the widgets surrounding windows by the window manager. Control over focus follows mouse was lost... It drove me away as a user because my preferences were no longer worth supporting. I guess I'm just turning into a grey beard at this point. Sigh.
  - SahAssar 6y ago
    > Why do I have to wait for several minutes to boot or reboot my machine when something goes odd with one of the services (like dns not working due to a transient network issue)? Because one of your other services has said it depends on network.target/network-online.target and is in the critical path of your boot. Check which one with "systemd-analyze plot > plot.svg" and "systemd-analyze dot 'network.*' | dot -Tsvg >network.svg". You can also see the critical chain and which parts block faster boot with "systemd-analyze critical-chain". I think if you stopped expecting systemd to act like something else and instead treated it like the toolkit that it is you'd see that it does what it says it does quite well. Those issues with boot you mentioned are often that the distro ships a bad systemd config for a certain program.
    - bcrl 6y ago
      Why do you think systemd is defendable for this? The prior init system had a means by which individual init scripts could be disabled during boot. I can't run systemd-analyze when the system off in lala-land for 5+ minutes. Moreover, if I know what is wrong, why can't I just cancel the job it's waiting for like I could previously from the console? It is a unacceptably bad user interface experience. There is no excuse for it. Again, this worked previously - why was this functionality lost / hidden? It's this "punch the user in the face" style of user interface design that I object to that is so prevalent in the corner cases of modern UIs.

dTal 6y ago

The term is "middleware". It's OS middleware. It's an attempt to create a third level between "kernel" and "userspace".