6 ms·

One giant program to rule them all was never the Unix way. System's monolithic architecture will be its downfall. Rather than stabilize I predict that systemd

One giant program to rule them all was never the Unix way. System's monolithic architecture will be its downfall. Rather than stabilize I predict that systemd will get more and more complicated and eventualy fall due to unwieldy maintenance problems at which point someone will come up with a better more modular system.

userbinator 11y ago
It's ironic that one of the design goals (or was that just the marketing blurb) of systemd was "modularity".
- mhurron 11y ago
  Systemds molecularity is 'we'll write a systemd module to handle that.'
  - chris_wot 11y ago
    What's wrong with that? I think I quite like this "molecularity", I'd like to see more of it!
    - mhurron 11y ago
      Ok that's it, enough internet for me today.
geofft 11y ago
Wasn't it? Multics was the modular system, Unix was the one where they said "That's silly, let's stick everything in a single kernel and not bother with all the flexibility because we don't need it." People seem to ignore the kernel for some reason, but it is literally one giant program to rule them all, and it works very well. There have been many efforts to modularize it and move most of the complexity into independent units, and none have particularly worked out.
- cfallin 11y ago
  The thing is that the kernel, while large, has one defined purpose -- to provide abstractions of hardware resources and arbitrate those resources between programs -- and thus conceptual simplicity, even if the source tree is huge. The POSIX syscall API is simple and the rest is just implementation. In contrast, systemd is conceptually complex -- its scope continues to expand to manage every little nook and cranny and configurable tidbit in the system. (I'm not arguing one way or another, just pointing out that the type of complexity is different.)
  - chris_wot 11y ago
    Really? How is it complex conceptually? The main concepts you really need to understand is that of units, and for that I found a very well written piece by Digital Ocean on the topic: https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files https://www.digitalocean.com/community/tutorials/understandi... Aside from that, there are a number of services and utilities, but I'm not sure how they are conceptually harder to understand that any other similar program or utility on Linux...
    - cfallin 11y ago
      The core of systemd revolves around units, but the "systemd ecosystem" has expanded to logging (journalctl), bus management, a new way to set the hostname (hostnamectl), a login manager, fstab parsing and disk management, a new session/login management framework, networking (systemd-netword, or is it netctl now, or do people use NetworkManager? I'm on Arch and ended up choosing netctl but I still don't understand all the tradeoffs), and I'm probably missing something. Don't get me wrong -- I actually like some of the new thinking, appreciate parallelized bootups, and think service units are cleaner than the old /etc/rc.d mudball. I'd rather have things Just Work(tm) than play with wpa_supplicant and hibernate configurations on my laptop. But it's been a lot of new stuff to learn for someone used to the Old Ways, and it's kind of astonishing how fast systemd pieces have taken over different domains.
      - 11y ago
rubiquity 11y ago
The Linux kernel itself is a a monolithic kernel and it beat out Hurd which was a micro kernel. I would say Linux has a history of certain programs being monolithic being a good thing.
- jcoffland 11y ago
  Hurd has failed after many years to produce a kernel even nearly as complete as Linux.
  - ferrari8608 11y ago
    That's because there are only a couple of guys working on it. Linux has had hundreds of contributors over the years, many of which work for large tech companies like Intel and get paid by their company for their contributions. I would be fascinated if Hurd could get the same sort of developer momentum to be comparable to Linux. A completely new (as in 1.0 released) and usable FOSS Unix-alike would be quite welcome amongst Linux and the BSD's I think.
    - schmichael 11y ago
      GNU's kernel efforts had an entire team debating, discussing, prototyping, and eventually working on Hurd before Linux even existed. Linux was initially written and released by one guy. Linux obviously gained a wider team while Hurd languished, but it's still interesting that GNU's kernel efforts started with far more initial human resources and were still quickly overshadowed by Linux.
- cyphar 11y ago
  Linux is a kernel. Monolithic and micro kernel architectures are a different problem to the Unix philosophy which specifically concerns design of userspace programs. I don't see how having pipes between kernel components would be a useful feature for a user. Also, the userspace of GNU/Linux isn't called Linux. Linux isn't an operating system.
  - 11y ago
chris_wot 11y ago
systemd has neither a monolithic architecture, nor does the systemd process itself do anything other than the following: "[systemd] provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic." [1] It comes with a set of utilities that do a lot of things. But that doesn't make it monolithic. In fact, systemd is actually extremely modular. Ironically, systemd has not gotten any harder to use since it was introduced, at least IMHO, but I guess as with anything YMMV. But this myth about systemd being monolithic, it really needs to stop because it's not correct. 1. https://freedesktop.org/wiki/Software/systemd/ https://freedesktop.org/wiki/Software/systemd/
- pdkl95 11y ago
  Systemd is the very definition of monolithic. > It comes with a set of utilities that do a lot of things "monolithic" vs "modular" has isn't about the number of binaries you build. This is about coupling. Replacing systemd itself is the modularity we're talking about, which becomes harder to replace (less modular) every time systemd annexes another set of features. Do those utilities use only well-defined, simple interfaces both to the system and between utilities? Can I replace one or more of those utilities with something else that implements those simple, stable, and well-defined interfaces? This what we mean by modularity; each piece of the complex system can be considered in isolation, with only minimal dependencies. When I can remove systemd-PID-1, OR keep using systemd-PID-1 but replace those utilities with other tools, only then will systemd be a "modular" set of tools. If I have to recompile daemons to remove systemd dependencies (libsystemd-journal0, libsystemd-login0), those daemons are now part of the systemd monolith. > needs to stop The only things that should stop are these attempts at changing word definitions.
  - pavanky 11y ago
    That's like claiming binutils collections is monolithic..

userbinator 11y ago

It's ironic that one of the design goals (or was that just the marketing blurb) of systemd was "modularity".

mhurron 11y ago
Systemds molecularity is 'we'll write a systemd module to handle that.'
- chris_wot 11y ago
  What's wrong with that? I think I quite like this "molecularity", I'd like to see more of it!
  - mhurron 11y ago
    Ok that's it, enough internet for me today.

geofft 11y ago

Wasn't it? Multics was the modular system, Unix was the one where they said "That's silly, let's stick everything in a single kernel and not bother with all the flexibility because we don't need it." People seem to ignore the kernel for some reason, but it is literally one giant program to rule them all, and it works very well. There have been many efforts to modularize it and move most of the complexity into independent units, and none have particularly worked out.

cfallin 11y ago
The thing is that the kernel, while large, has one defined purpose -- to provide abstractions of hardware resources and arbitrate those resources between programs -- and thus conceptual simplicity, even if the source tree is huge. The POSIX syscall API is simple and the rest is just implementation. In contrast, systemd is conceptually complex -- its scope continues to expand to manage every little nook and cranny and configurable tidbit in the system. (I'm not arguing one way or another, just pointing out that the type of complexity is different.)
- chris_wot 11y ago
  Really? How is it complex conceptually? The main concepts you really need to understand is that of units, and for that I found a very well written piece by Digital Ocean on the topic: https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files https://www.digitalocean.com/community/tutorials/understandi... Aside from that, there are a number of services and utilities, but I'm not sure how they are conceptually harder to understand that any other similar program or utility on Linux...
  - cfallin 11y ago
    The core of systemd revolves around units, but the "systemd ecosystem" has expanded to logging (journalctl), bus management, a new way to set the hostname (hostnamectl), a login manager, fstab parsing and disk management, a new session/login management framework, networking (systemd-netword, or is it netctl now, or do people use NetworkManager? I'm on Arch and ended up choosing netctl but I still don't understand all the tradeoffs), and I'm probably missing something. Don't get me wrong -- I actually like some of the new thinking, appreciate parallelized bootups, and think service units are cleaner than the old /etc/rc.d mudball. I'd rather have things Just Work(tm) than play with wpa_supplicant and hibernate configurations on my laptop. But it's been a lot of new stuff to learn for someone used to the Old Ways, and it's kind of astonishing how fast systemd pieces have taken over different domains.
    - 11y ago

rubiquity 11y ago

The Linux kernel itself is a a monolithic kernel and it beat out Hurd which was a micro kernel. I would say Linux has a history of certain programs being monolithic being a good thing.

jcoffland 11y ago
Hurd has failed after many years to produce a kernel even nearly as complete as Linux.
- ferrari8608 11y ago
  That's because there are only a couple of guys working on it. Linux has had hundreds of contributors over the years, many of which work for large tech companies like Intel and get paid by their company for their contributions. I would be fascinated if Hurd could get the same sort of developer momentum to be comparable to Linux. A completely new (as in 1.0 released) and usable FOSS Unix-alike would be quite welcome amongst Linux and the BSD's I think.
  - schmichael 11y ago
    GNU's kernel efforts had an entire team debating, discussing, prototyping, and eventually working on Hurd before Linux even existed. Linux was initially written and released by one guy. Linux obviously gained a wider team while Hurd languished, but it's still interesting that GNU's kernel efforts started with far more initial human resources and were still quickly overshadowed by Linux.
cyphar 11y ago
Linux is a kernel. Monolithic and micro kernel architectures are a different problem to the Unix philosophy which specifically concerns design of userspace programs. I don't see how having pipes between kernel components would be a useful feature for a user. Also, the userspace of GNU/Linux isn't called Linux. Linux isn't an operating system.
- 11y ago

chris_wot 11y ago

systemd has neither a monolithic architecture, nor does the systemd process itself do anything other than the following: "[systemd] provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic." [1] It comes with a set of utilities that do a lot of things. But that doesn't make it monolithic. In fact, systemd is actually extremely modular. Ironically, systemd has not gotten any harder to use since it was introduced, at least IMHO, but I guess as with anything YMMV. But this myth about systemd being monolithic, it really needs to stop because it's not correct. 1. https://freedesktop.org/wiki/Software/systemd/ https://freedesktop.org/wiki/Software/systemd/

pdkl95 11y ago
Systemd is the very definition of monolithic. > It comes with a set of utilities that do a lot of things "monolithic" vs "modular" has isn't about the number of binaries you build. This is about coupling. Replacing systemd itself is the modularity we're talking about, which becomes harder to replace (less modular) every time systemd annexes another set of features. Do those utilities use only well-defined, simple interfaces both to the system and between utilities? Can I replace one or more of those utilities with something else that implements those simple, stable, and well-defined interfaces? This what we mean by modularity; each piece of the complex system can be considered in isolation, with only minimal dependencies. When I can remove systemd-PID-1, OR keep using systemd-PID-1 but replace those utilities with other tools, only then will systemd be a "modular" set of tools. If I have to recompile daemons to remove systemd dependencies (libsystemd-journal0, libsystemd-login0), those daemons are now part of the systemd monolith. > needs to stop The only things that should stop are these attempts at changing word definitions.
- pavanky 11y ago
  That's like claiming binutils collections is monolithic..