6 ms·

What I always wondered is: Why is a lot of the discussion about systemd vs initd when systemd is so many things. And the follow-up question would be: Why hasn't

What I always wondered is: Why is a lot of the discussion about systemd vs initd when systemd is so many things. And the follow-up question would be: Why hasn't anyone taken apart systemd and reused only the parts they found useful, like the system manager for example. "Systemd: The Good Parts", so to speak.

kick 7y ago
The article literally gives an example of people doing that with elogind (though dbus isn't good, it's just necessary for certain software to work).
blihp 7y ago
That is pretty much the issue: to some, systemd is too many things. Realistically, one tends to take or leave an upstream package since picking and choosing pieces of it is far more work than a typical package maintainer takes on. Also, upstream design decision changes can make doing so problematic down the road.
- bonzini 7y ago
  > picking and choosing pieces of it is far more work than a typical package maintainer takes on. Not necessarily. RHEL does not ship gummiboot, timesyncd or networkd for example; it uses grub, chrony, NetworkManager. On my raspberry pis running Debian I have systemd as pid 1, one runs ConnMan (it connects to wireless) and the other runs networkd (it connects to Ethernet).
  - aerique 7y ago
    The article mentions that Debian does not have these "embrace, extend" problems yet because they've been using a fairly old version of SystemD, but they are going to run into those issues when they upgrade.
    - bkor 7y ago
      The distribution I use uses a much newer version of systemd. There still isn't any issue not using things mentioned like e.g. networkd and so on.
michaelmrose 7y ago
Presumably because there being multiple binaries doesn't mean they are actually easily seperable.
- hnarn 7y ago
  Or maybe because complaining is so much easier than putting in the work.
  - michaelmrose 7y ago
    This is a low effort post inconsistent with reality. You are simply incorrect.
- geofft 7y ago
  Doesn't necessarily imply that in general, sure, but for the specific cases of systemd and timesyncd/gummiboot/nspawn, they are in fact trivially separable. I'm pretty sure that's even the out-of-the-box config of Debian.
tsukurimashou 7y ago
I'd say that is one of the complain I hear often "systemd is so many things", Unix philosophy tells you to do one thing and to do it well, a lot of people against systemd were against it for that reason.
- bonzini 7y ago
  But then systemd is multiple binaries, each doing one thing. The only two that are really intertwined are systemd and journald.
- nguoi 7y ago
  Unix-esque OSes run in my computer, my car, and my phone. That's not the Unix philosophy either. It's a nice design rule for CLI utilities, it doesn't work for systems.
  - kevingadd 7y ago
    "do one thing and do it well" does not mean "intentionally only support one piece of hardware". If your do one thing is "offer a bootloader that works on your hardware" or "offer device detection and driver loading for all your devices" that is not somehow scope creep. It's the only sensible way to architect those things. Similarly, curl supporting both HTTP and HTTPS is not a violation of "do one thing and do it well" - if you fail to support at least those two protocols, you've built a shitty tool. It's best to consider "do one thing" in the context of "what does the user want the software to do". A web browser having lots of functionality baked in is not necessarily a violation of this principle if all of that functionality is used to solve one user problem (I want to view YouTube, or I want to use GMail). At that point, the factoring issue lies somewhere else - the definition of the web platform, etc. Systemd attempts to solve very many user problems all at once, with varying levels of success, and other software packages have solved one or two of them at once instead. In that case there is a clear way to separate the ones that probably apply the "unix philosophy" and the ones that obviously do not. The Linux kernel and related components themselves sort of violate this, but that's mostly a matter of necessity - super-modular microkernel designs have not worked out great in practice. However, it still is built around relatively narrowly-scoped drivers for individual devices or services, instead of massive Megadrivers that handle every component in your system. Your PC may have an Intel GPU integrated on the CPU die, but it's still using a separate video driver, and the video driver is probably separate from things like the compositor and the actual PnP layer beneath that detects what hardware you have. If you look at the average USB device in Windows' device manager (this is probably true in Linux as well but I don't know how to dump the data), you can see a given device like a mouse or a phone is actually split up into a bunch of sub-capabilities exposed by the device, and those can each have their own driver. Same thought process there.
bipson 7y ago
You can use systemd without almost all of the sideparts. No need to use networkd for example, networkmanager works great along systemd. Actually most my systems use only systemd and journalctl to my knowledge. I prefer my established tools for all other jobs.
- ohazi 7y ago
  But you can't use many of the sideparts without systemd. I think systemd actually won when they absorbed udev.
  - bipson 7y ago
    That was not the argument though
    - dredmorbius 7y ago
      If the answers are more insightful than the question, perhaps the question was incorrect.
  - jakeogh 7y ago
    https://wiki.gentoo.org/wiki/Eudev https://wiki.gentoo.org/wiki/Eudev works perfect
- yc12340 7y ago
  > You can use systemd without almost all of the sideparts. Can you? The whole premise of systemd revolves around ability to use existing init files, written by upstream developers. Upstream init files are going to use arbitrary parts of systemd functionality, which may include network and container management, timers and God knows what else. So in effect you HAVE to use those parts of systemd — unless you are insisting on writing all your init files from scratch (at which point you may as well use any of systemd alternatives).
  - bipson 7y ago
    For one, have you ever written an unit file? It literally takes 3 minutes. And unless you are working with e.g containerized services (which you create yourself), why would a service need anything from networkd? I have never encountered a unit file like that on my system, and I don't run anything apart from systemd and journalctl. No networkd (I prefer NetworkManager), no systemd containers, no systemd ntp. I wonder if I even have those installed, why should I? And all my services run just fine.
diffeomorphism 7y ago
Mostly because the many projects under the systemd umbrella are somewhat coupled and not that easy to use outside of it. For example many of the larger DEs use logind because it is good at what it does and consolekit at that time was not really active anymore. That meant that for example freebsd had to either make the DEs work with consolekit (and maintain it) or make a logind implementation work with their implementation. This is one of the confusing things about the discussion. The systemd project very much follows the "unix way" in that there are lots of subprojects that do one thing well, but is developed in a cathedral style (just like the *BSDs are) and not easily reusable, which kinda loses the benefit.
- bkor 7y ago
  > many of the larger DEs use logind because it is good at what it does and consolekit at that time was not really active anymore. More that ConsoleKit developers and logind/systemd overlapped. For GNOME, logind seemed better and used to be separate. A warning that it would not always stay decoupled was underestimated/ignored. Once logind was tied to systemd all hell broke loose :-P Having something like systemd is great; e.g. GNOME has various user services running. Nowadays systemd manages those user services. But as great as that is, it makes non-Linux more difficult. IMO systemd on Linux makes things very easy and it's better to standardize on it.
eleitl 7y ago
> when systemd is so many things Because it was originally advertized as an optional init replacement. The acrimonious debates were because a number of people did not believe that's all is going to be, given the history of its designers. Of course, nowadays many people would flat-out deny that systemd was sold as an init replacement, and claim that what you see was the original intention all along.
- deleted 7y ago
  [deleted]
- bkor 7y ago
  At the time of the Debian debate around systemd it was already very clear that systemd was not just an init system. The systemd website at that time already mentioned it to be "basic building block for Linux". People just pretending it is or only should be an init system was one of the annoying things about the discussion; people only compared the init system part of things and ignored that systemd offered more to developers. Any additional functionality was "not to be used" or "developers should offer alternatives". That wasn't very realistic then and now.
nickik 7y ago
> Why hasn't anyone taken apart systemd and reused only the parts they found useful Everybody does that. Are you using networkd? Every distro makes different choices and user can then further configure what they want to use. You can already configure systemd as you like, there is no need to 'take it apart'.

kick 7y ago

The article literally gives an example of people doing that with elogind (though dbus isn't good, it's just necessary for certain software to work).

blihp 7y ago

That is pretty much the issue: to some, systemd is too many things. Realistically, one tends to take or leave an upstream package since picking and choosing pieces of it is far more work than a typical package maintainer takes on. Also, upstream design decision changes can make doing so problematic down the road.

bonzini 7y ago
> picking and choosing pieces of it is far more work than a typical package maintainer takes on. Not necessarily. RHEL does not ship gummiboot, timesyncd or networkd for example; it uses grub, chrony, NetworkManager. On my raspberry pis running Debian I have systemd as pid 1, one runs ConnMan (it connects to wireless) and the other runs networkd (it connects to Ethernet).
- aerique 7y ago
  The article mentions that Debian does not have these "embrace, extend" problems yet because they've been using a fairly old version of SystemD, but they are going to run into those issues when they upgrade.
  - bkor 7y ago
    The distribution I use uses a much newer version of systemd. There still isn't any issue not using things mentioned like e.g. networkd and so on.

michaelmrose 7y ago

Presumably because there being multiple binaries doesn't mean they are actually easily seperable.

hnarn 7y ago
Or maybe because complaining is so much easier than putting in the work.
- michaelmrose 7y ago
  This is a low effort post inconsistent with reality. You are simply incorrect.
geofft 7y ago
Doesn't necessarily imply that in general, sure, but for the specific cases of systemd and timesyncd/gummiboot/nspawn, they are in fact trivially separable. I'm pretty sure that's even the out-of-the-box config of Debian.

tsukurimashou 7y ago

I'd say that is one of the complain I hear often "systemd is so many things", Unix philosophy tells you to do one thing and to do it well, a lot of people against systemd were against it for that reason.

bonzini 7y ago
But then systemd is multiple binaries, each doing one thing. The only two that are really intertwined are systemd and journald.
nguoi 7y ago
Unix-esque OSes run in my computer, my car, and my phone. That's not the Unix philosophy either. It's a nice design rule for CLI utilities, it doesn't work for systems.
- kevingadd 7y ago
  "do one thing and do it well" does not mean "intentionally only support one piece of hardware". If your do one thing is "offer a bootloader that works on your hardware" or "offer device detection and driver loading for all your devices" that is not somehow scope creep. It's the only sensible way to architect those things. Similarly, curl supporting both HTTP and HTTPS is not a violation of "do one thing and do it well" - if you fail to support at least those two protocols, you've built a shitty tool. It's best to consider "do one thing" in the context of "what does the user want the software to do". A web browser having lots of functionality baked in is not necessarily a violation of this principle if all of that functionality is used to solve one user problem (I want to view YouTube, or I want to use GMail). At that point, the factoring issue lies somewhere else - the definition of the web platform, etc. Systemd attempts to solve very many user problems all at once, with varying levels of success, and other software packages have solved one or two of them at once instead. In that case there is a clear way to separate the ones that probably apply the "unix philosophy" and the ones that obviously do not. The Linux kernel and related components themselves sort of violate this, but that's mostly a matter of necessity - super-modular microkernel designs have not worked out great in practice. However, it still is built around relatively narrowly-scoped drivers for individual devices or services, instead of massive Megadrivers that handle every component in your system. Your PC may have an Intel GPU integrated on the CPU die, but it's still using a separate video driver, and the video driver is probably separate from things like the compositor and the actual PnP layer beneath that detects what hardware you have. If you look at the average USB device in Windows' device manager (this is probably true in Linux as well but I don't know how to dump the data), you can see a given device like a mouse or a phone is actually split up into a bunch of sub-capabilities exposed by the device, and those can each have their own driver. Same thought process there.

bipson 7y ago

You can use systemd without almost all of the sideparts. No need to use networkd for example, networkmanager works great along systemd. Actually most my systems use only systemd and journalctl to my knowledge. I prefer my established tools for all other jobs.

ohazi 7y ago
But you can't use many of the sideparts without systemd. I think systemd actually won when they absorbed udev.
- bipson 7y ago
  That was not the argument though
  - dredmorbius 7y ago
    If the answers are more insightful than the question, perhaps the question was incorrect.
- jakeogh 7y ago
  https://wiki.gentoo.org/wiki/Eudev https://wiki.gentoo.org/wiki/Eudev works perfect
yc12340 7y ago
> You can use systemd without almost all of the sideparts. Can you? The whole premise of systemd revolves around ability to use existing init files, written by upstream developers. Upstream init files are going to use arbitrary parts of systemd functionality, which may include network and container management, timers and God knows what else. So in effect you HAVE to use those parts of systemd — unless you are insisting on writing all your init files from scratch (at which point you may as well use any of systemd alternatives).
- bipson 7y ago
  For one, have you ever written an unit file? It literally takes 3 minutes. And unless you are working with e.g containerized services (which you create yourself), why would a service need anything from networkd? I have never encountered a unit file like that on my system, and I don't run anything apart from systemd and journalctl. No networkd (I prefer NetworkManager), no systemd containers, no systemd ntp. I wonder if I even have those installed, why should I? And all my services run just fine.

diffeomorphism 7y ago

Mostly because the many projects under the systemd umbrella are somewhat coupled and not that easy to use outside of it. For example many of the larger DEs use logind because it is good at what it does and consolekit at that time was not really active anymore. That meant that for example freebsd had to either make the DEs work with consolekit (and maintain it) or make a logind implementation work with their implementation. This is one of the confusing things about the discussion. The systemd project very much follows the "unix way" in that there are lots of subprojects that do one thing well, but is developed in a cathedral style (just like the *BSDs are) and not easily reusable, which kinda loses the benefit.

bkor 7y ago
> many of the larger DEs use logind because it is good at what it does and consolekit at that time was not really active anymore. More that ConsoleKit developers and logind/systemd overlapped. For GNOME, logind seemed better and used to be separate. A warning that it would not always stay decoupled was underestimated/ignored. Once logind was tied to systemd all hell broke loose :-P Having something like systemd is great; e.g. GNOME has various user services running. Nowadays systemd manages those user services. But as great as that is, it makes non-Linux more difficult. IMO systemd on Linux makes things very easy and it's better to standardize on it.

eleitl 7y ago

> when systemd is so many things Because it was originally advertized as an optional init replacement. The acrimonious debates were because a number of people did not believe that's all is going to be, given the history of its designers. Of course, nowadays many people would flat-out deny that systemd was sold as an init replacement, and claim that what you see was the original intention all along.

deleted 7y ago
[deleted]
bkor 7y ago
At the time of the Debian debate around systemd it was already very clear that systemd was not just an init system. The systemd website at that time already mentioned it to be "basic building block for Linux". People just pretending it is or only should be an init system was one of the annoying things about the discussion; people only compared the init system part of things and ignored that systemd offered more to developers. Any additional functionality was "not to be used" or "developers should offer alternatives". That wasn't very realistic then and now.

nickik 7y ago

> Why hasn't anyone taken apart systemd and reused only the parts they found useful Everybody does that. Are you using networkd? Every distro makes different choices and user can then further configure what they want to use. You can already configure systemd as you like, there is no need to 'take it apart'.