5 ms·

Then.. why does it exist? More importantly, why is it enabled by default? Does systemd want to be an init system? A logging system? a dnsmasq replacement?

nine_k 6y ago
Systemd is a replacement for Unix. Folks at Red Hat noticed that the Linux userland architecture is not convenient for what they would like to build. So they are building systems which replace the traditional mechanisms: first DBus, then systemd, which is an umbrella of many services: init + service monitoring + containers, logging, interactive login, some networking, etc. I suppose that in 10 years a linux kernel + systemd could be a complete system, with little need for other userland.
- jamiesonbecker 6y ago
  > Systemd is a replacement for Unix... I suppose that in 10 years a linux kernel + systemd could be a complete system, with little need for other userland. 'Doing many things, none of them well' is actually the opposite of UNIX. https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy
  - nine_k 6y ago
    Sometimes you want a different balance — say, in embedded systems. If you think about busybox, it does something similar, only doing a better job at looking like the traditional userland. There is nothing bad about it. What I find bad is forcing everyone to jump on the same bandwagon, no matter which bandwagon. If I wanted choices made for me, I'd buy a Mac.
    - deleted 6y ago
      [deleted]
    - tal8d 6y ago
      ugh, I was so excited when my POWER9 arrived... and then I started looking at the OpenBMC stack.
  - dralley 6y ago
    This needs to be stated yet again apparently - systemd is not one monolothic binary, it's a collection of tools in one repository. Centrally developing many disparate pieces of software from one repository is what every BSD does so you can hardly argue that it's not "UNIX". This is setting aside that systemd actually does all of those things better than the tools that came before. journalctl and systemd timers are fantastic. And good luck using the alternatives to manage cgroups.
    - jamiesonbecker 6y ago
      A monolith does not necessarily mean a single binary.
dralley 6y ago
There is a "project" named systemd and an "init system" named systemd, in much the same way that there's the GNU project and GNU-$everything. Nobody says things like "what is GNU? Is it a kernel, a compiler, a libc, a build system, a set of userspace tools?". Likewise, the systemd project has many utilities under its umbrella, and most of them are completely optional.
- dTal 6y ago
  Hm. GNU exists to unify software under a single philosophical umbrella - the thing that all GNU software has in common is a fanatical attitude to software freedom. What does all systemd software have in common? What's the unifying principle there?
  - LukeShu 6y ago
    I think the best answer is that systemd-the-project tries to be the things that all of the different distros historically had to do themselves, the things that didn't have an upstream, but maybe deserved to have an upstream so that they could be reused by other distros, and maybe benefit from more eyes and more engineering effort. Each distro used to have to roll their own initscript system (with varying degrees of compatibility), so they made `systemd`. Each distro had their own init script to save/load the backlight state, so they made `systemd-backlight` (if you're going to replace the initscript system, you'll also have to replace the things that the initscripts for that system did). Each distro used to have to roll their own network configuration scripts (Debian's /etc/network, Arch Linux's netcfg and later netctl, ...), so they made `systemd-networkd`. Some of this class of thing got picked up by other projects; each distro used to have to roll its own initramfs system; today Dracut exists, so systemd won't be doing that (unless the Dracut folks decide to team up with the systemd folks--remember gummiboot? gummiboot renamed to systemd-boot). In one of your other comments you wrote "in my opinion that implies more modularity than it posesses." While there are some nasty couplings (it'll take some patching to get systemd-nspawn to work on a non-systemd system), you can successfully use many of the systemd modules on an OpenRC system; it is a lot more modular than people give it credit for.
  - deleted 6y ago

nine_k 6y ago

Systemd is a replacement for Unix. Folks at Red Hat noticed that the Linux userland architecture is not convenient for what they would like to build. So they are building systems which replace the traditional mechanisms: first DBus, then systemd, which is an umbrella of many services: init + service monitoring + containers, logging, interactive login, some networking, etc. I suppose that in 10 years a linux kernel + systemd could be a complete system, with little need for other userland.

jamiesonbecker 6y ago
> Systemd is a replacement for Unix... I suppose that in 10 years a linux kernel + systemd could be a complete system, with little need for other userland. 'Doing many things, none of them well' is actually the opposite of UNIX. https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy
- nine_k 6y ago
  Sometimes you want a different balance — say, in embedded systems. If you think about busybox, it does something similar, only doing a better job at looking like the traditional userland. There is nothing bad about it. What I find bad is forcing everyone to jump on the same bandwagon, no matter which bandwagon. If I wanted choices made for me, I'd buy a Mac.
  - deleted 6y ago
    [deleted]
  - tal8d 6y ago
    ugh, I was so excited when my POWER9 arrived... and then I started looking at the OpenBMC stack.
- dralley 6y ago
  This needs to be stated yet again apparently - systemd is not one monolothic binary, it's a collection of tools in one repository. Centrally developing many disparate pieces of software from one repository is what every BSD does so you can hardly argue that it's not "UNIX". This is setting aside that systemd actually does all of those things better than the tools that came before. journalctl and systemd timers are fantastic. And good luck using the alternatives to manage cgroups.
  - jamiesonbecker 6y ago
    A monolith does not necessarily mean a single binary.

dralley 6y ago

There is a "project" named systemd and an "init system" named systemd, in much the same way that there's the GNU project and GNU-$everything. Nobody says things like "what is GNU? Is it a kernel, a compiler, a libc, a build system, a set of userspace tools?". Likewise, the systemd project has many utilities under its umbrella, and most of them are completely optional.

dTal 6y ago
Hm. GNU exists to unify software under a single philosophical umbrella - the thing that all GNU software has in common is a fanatical attitude to software freedom. What does all systemd software have in common? What's the unifying principle there?
- LukeShu 6y ago
  I think the best answer is that systemd-the-project tries to be the things that all of the different distros historically had to do themselves, the things that didn't have an upstream, but maybe deserved to have an upstream so that they could be reused by other distros, and maybe benefit from more eyes and more engineering effort. Each distro used to have to roll their own initscript system (with varying degrees of compatibility), so they made `systemd`. Each distro had their own init script to save/load the backlight state, so they made `systemd-backlight` (if you're going to replace the initscript system, you'll also have to replace the things that the initscripts for that system did). Each distro used to have to roll their own network configuration scripts (Debian's /etc/network, Arch Linux's netcfg and later netctl, ...), so they made `systemd-networkd`. Some of this class of thing got picked up by other projects; each distro used to have to roll its own initramfs system; today Dracut exists, so systemd won't be doing that (unless the Dracut folks decide to team up with the systemd folks--remember gummiboot? gummiboot renamed to systemd-boot). In one of your other comments you wrote "in my opinion that implies more modularity than it posesses." While there are some nasty couplings (it'll take some patching to get systemd-nspawn to work on a non-systemd system), you can successfully use many of the systemd modules on an OpenRC system; it is a lot more modular than people give it credit for.
- deleted 6y ago