13 ms·

The argument is not about the init system. systemd’s is probably fine. It’s about an ever expanding take-over of userspace by a single module, which is not the

The argument is not about the init system. systemd’s is probably fine. It’s about an ever expanding take-over of userspace by a single module, which is not the Unix way. And about a high-handed project leader who is paid by Redhat to do it full time.

tssva 6y ago
If the issue is a single module take over of userspace then I have good news for you. The systemd project is made up of multiple modules handling differing tasks not all of which you have to use.
- dogecoinbase 6y ago
  Modules which only work with their own other modules and fail to work with other people's modules aren't modules, they're a monolith.
  - hinkley 6y ago
    with accessories.
  - the_why_of_y 6y ago
    Would you say Postfix is a monolith? Or qmail?
    - f1refly 6y ago
      yes and yes. Fairly small ones, but monoliths nonetheless.
- JdeBP 6y ago
  Every time that this argument comes up, people don't get their computer science right. The problem is not whether something has modules. It is the degree of coupling amongst and cohesion within said modules that is the metric. * https://news.ycombinator.com/item?id=19132437 https://news.ycombinator.com/item?id=19132437 * https://news.ycombinator.com/item?id=19028053 https://news.ycombinator.com/item?id=19028053
  - tssva 6y ago
    There is significant variety between distributions regarding which systemd project modules are used by default. Many distributions also allow systemd modules used by default to be easily replaced with non-systemd alternatives. This speaks to the level of coupling and cohesion between systemd modules being low enough that they don't form a monolith.
    - JdeBP 6y ago
      Waving around the terms without understanding them, as you are doing, demonstrates exactly what I mentioned. Someone who actually knew the computer science would not be talking of low cohesion here, or of modules forming a monolith.
xellisx 6y ago
Well isn't the Unix way still plaguing us with legacy craziness? How many bin directories do we need?
- edoceo 6y ago
  4: /bin, /usr/bin, /usr/local/bin and then ~/bin - for per-user commands, first in path if you allow it.
- ori_b 6y ago
  That's cargo culting -- a computer at bell labs once ran out of disk space on the system disk (/), people put binaries in a directory on the user disk (/usr), and everyone started to copy it for all eternity.
  - wmf 6y ago
    Right, and systemd is pretty much the only successful attempt to de-cargo-cult Unix.
    - ori_b 6y ago
      Wut. What has it de-cargo-culted? Most of the stuff that could use de-cargo-culting is still there under it.
      - mappu 6y ago
        Runlevels, for one.
        ori_b 6y ago
        Oh. That's a linuxism. BSD has never had them, iirc. I don't think any of the other simpler init systems (eg, runit) did either.
        catblast 6y ago
nrclark 6y ago
Agreed 100%. Systemd is a pretty good init system IMO. Service files are good, timers are good, dependency-based init is good. Easy sandboxing is nice. I absolutely _don't_ think that my init system should also be my bootloader. It also shouldn't manage my network configuration, or be responsible for controlling the system clock. And it shouldn't assert control of my home folders. And it shouldn't be spidering its way into the Gnome login manager, which grew a systemd dependency a couple of years ago. My problem with systemd isn't pid 1. It's all the rest of the shovelware that comes along for the ride. And it's the "you'll use what we tell you to use" attitude of the project.
- 256 6y ago
  > My problem with systemd isn't pid 1. It's all the rest of the shovelware that comes along for the ride. And it's the "you'll use what we tell you to use" attitude of the project. This could not be further from the truth.
  - marios 6y ago
    At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly. Of course, since this hack solved the gnome bug, it was enabled by default by many, thus breaking applications like screen and tmux. What should have been done is fix the issue in whatever offending application. Certainly not at systemd level. Because in that case, you need to do some insane things (IMO), like link tmux with libsystemd [1]. [1] https://github.com/tmux/tmux/issues/428nk https://github.com/tmux/tmux/issues/428nk
    - majewsky 6y ago
      > At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly. The backstory is actually enlightening to me. To me, RemainAfterExit just seemed like the obvious sane decision and I actually wondered why it ever was different. When a user logs out, I absolutely want everything cleaned up after them unless they explicitly want something like screen or tmux to linger. > you need to do some insane things (IMO), like link tmux with libsystemd That would probably be the easiest choice for the tmux devs. If they don't want to link libsystemd, they could have accessed logind's DBus interface directly (either by calling dbus-send(1) or via libdbus). Contrary to wide-spread belief, systemd does, in fact, present well-defined and documented interfaces that other daemons can implement as well (and they do, see elogind). libsystemd is not magical.
catblast 6y ago
> by a single module, which is not the Unix way. Kind of ironic when one of the oft touted complaints I recall about Linux vs the BSDs or virtually any historical Unix is how the userspace and kernel are not one integrated distribution.
- wmf 6y ago
  We have now reached the "Unix, is that a flavor of Linux?" state that people joked about in the 1990s. If the only Unix you know is Linux, then your "Unix way" is really the Linux way (which is just a different set of historical accidents).
jonny383 6y ago
I see a bunch of people in these threads complaining about change in Linux, but this is exactly all they do - _complain_. I don't see any of these people making better contributions. It's easier to sit there and insult the project leader for being paid by RedHat - but let's face it. Without commercial sponsorship, Linux would be dead. So quit your whining. If you all ready don't like systemd that much - why don't you implement a better alternative - as you all seem to have the answers.
dralley 6y ago
>It’s about an ever expanding take-over of userspace by a single module, which is not the Unix way. You confuse Systemd the init system with Systemd the project. The Systemd project can be described as "GNU coreutils but for low-level system components". People hear about all the tools that the Systemd project maintains and think that all that functionality is built into the init system, when the reality it's >50 separate binaries, the majority of which (like systemd-boot or systemd-resolved) are completely optional and aren't even installed by most distributions. And while I understand that some parts, like journald, are not so independent - it's still not "a single module" in a way that prevents it from being unix-y. The Unix philosophy is about separation of concerns, not having a bunch of interchangable options for low-level system components.
- stouset 6y ago
  You know, I had to integrate with `journald` a bit ago and I was prepared for a nightmare after all the ruckus raised about systemd. And you know what? It’s fantastic. The API is generally well-designed (if not without a few sharp corners) and the whole thing is incredibly well thought out. Sure, plain text logs let you use standard UNIX tools. But doing so sucks. God help you if there’s a newline in your logs or if you have to ensure that you iterate over all the logs even across restarts or if you need to parse logs back out from text into the underlying attributes.
  - pnako 6y ago
    Next, have all the settings in some sort of central database. And in 20 years, Red Hat will have finally finished re-inventing Windows NT on top of the Linux kernel.
    - zenlot 6y ago
      Have you ever worked with IBMs AIX? It has ODM and it’s amazing. Systemd is going to the right direction.
      - pnako 6y ago
ac29 6y ago
> the Unix way This gets pulled out far too often. Systemd is a family of projects thast are largely modular and independent, not a single binary that takes over everything. Each part's goal is to do one thing, and you're free to take or leave each piece. By this logic, Bell Labs should have never worked on UNIX or C - they were a telephone company!

tssva 6y ago

If the issue is a single module take over of userspace then I have good news for you. The systemd project is made up of multiple modules handling differing tasks not all of which you have to use.

dogecoinbase 6y ago
Modules which only work with their own other modules and fail to work with other people's modules aren't modules, they're a monolith.
- hinkley 6y ago
  with accessories.
- the_why_of_y 6y ago
  Would you say Postfix is a monolith? Or qmail?
  - f1refly 6y ago
    yes and yes. Fairly small ones, but monoliths nonetheless.
JdeBP 6y ago
Every time that this argument comes up, people don't get their computer science right. The problem is not whether something has modules. It is the degree of coupling amongst and cohesion within said modules that is the metric. * https://news.ycombinator.com/item?id=19132437 https://news.ycombinator.com/item?id=19132437 * https://news.ycombinator.com/item?id=19028053 https://news.ycombinator.com/item?id=19028053
- tssva 6y ago
  There is significant variety between distributions regarding which systemd project modules are used by default. Many distributions also allow systemd modules used by default to be easily replaced with non-systemd alternatives. This speaks to the level of coupling and cohesion between systemd modules being low enough that they don't form a monolith.
  - JdeBP 6y ago
    Waving around the terms without understanding them, as you are doing, demonstrates exactly what I mentioned. Someone who actually knew the computer science would not be talking of low cohesion here, or of modules forming a monolith.

xellisx 6y ago

Well isn't the Unix way still plaguing us with legacy craziness? How many bin directories do we need?

edoceo 6y ago
4: /bin, /usr/bin, /usr/local/bin and then ~/bin - for per-user commands, first in path if you allow it.
ori_b 6y ago
That's cargo culting -- a computer at bell labs once ran out of disk space on the system disk (/), people put binaries in a directory on the user disk (/usr), and everyone started to copy it for all eternity.
- wmf 6y ago
  Right, and systemd is pretty much the only successful attempt to de-cargo-cult Unix.
  - ori_b 6y ago
    Wut. What has it de-cargo-culted? Most of the stuff that could use de-cargo-culting is still there under it.
    - mappu 6y ago
      Runlevels, for one.
      - ori_b 6y ago
        Oh. That's a linuxism. BSD has never had them, iirc. I don't think any of the other simpler init systems (eg, runit) did either.
        catblast 6y ago

nrclark 6y ago

Agreed 100%. Systemd is a pretty good init system IMO. Service files are good, timers are good, dependency-based init is good. Easy sandboxing is nice. I absolutely _don't_ think that my init system should also be my bootloader. It also shouldn't manage my network configuration, or be responsible for controlling the system clock. And it shouldn't assert control of my home folders. And it shouldn't be spidering its way into the Gnome login manager, which grew a systemd dependency a couple of years ago. My problem with systemd isn't pid 1. It's all the rest of the shovelware that comes along for the ride. And it's the "you'll use what we tell you to use" attitude of the project.

256 6y ago
> My problem with systemd isn't pid 1. It's all the rest of the shovelware that comes along for the ride. And it's the "you'll use what we tell you to use" attitude of the project. This could not be further from the truth.
- marios 6y ago
  At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly. Of course, since this hack solved the gnome bug, it was enabled by default by many, thus breaking applications like screen and tmux. What should have been done is fix the issue in whatever offending application. Certainly not at systemd level. Because in that case, you need to do some insane things (IMO), like link tmux with libsystemd [1]. [1] https://github.com/tmux/tmux/issues/428nk https://github.com/tmux/tmux/issues/428nk
  - majewsky 6y ago
    > At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly. The backstory is actually enlightening to me. To me, RemainAfterExit just seemed like the obvious sane decision and I actually wondered why it ever was different. When a user logs out, I absolutely want everything cleaned up after them unless they explicitly want something like screen or tmux to linger. > you need to do some insane things (IMO), like link tmux with libsystemd That would probably be the easiest choice for the tmux devs. If they don't want to link libsystemd, they could have accessed logind's DBus interface directly (either by calling dbus-send(1) or via libdbus). Contrary to wide-spread belief, systemd does, in fact, present well-defined and documented interfaces that other daemons can implement as well (and they do, see elogind). libsystemd is not magical.

catblast 6y ago

> by a single module, which is not the Unix way. Kind of ironic when one of the oft touted complaints I recall about Linux vs the BSDs or virtually any historical Unix is how the userspace and kernel are not one integrated distribution.

wmf 6y ago
We have now reached the "Unix, is that a flavor of Linux?" state that people joked about in the 1990s. If the only Unix you know is Linux, then your "Unix way" is really the Linux way (which is just a different set of historical accidents).

jonny383 6y ago

I see a bunch of people in these threads complaining about change in Linux, but this is exactly all they do - _complain_. I don't see any of these people making better contributions. It's easier to sit there and insult the project leader for being paid by RedHat - but let's face it. Without commercial sponsorship, Linux would be dead. So quit your whining. If you all ready don't like systemd that much - why don't you implement a better alternative - as you all seem to have the answers.

dralley 6y ago

>It’s about an ever expanding take-over of userspace by a single module, which is not the Unix way. You confuse Systemd the init system with Systemd the project. The Systemd project can be described as "GNU coreutils but for low-level system components". People hear about all the tools that the Systemd project maintains and think that all that functionality is built into the init system, when the reality it's >50 separate binaries, the majority of which (like systemd-boot or systemd-resolved) are completely optional and aren't even installed by most distributions. And while I understand that some parts, like journald, are not so independent - it's still not "a single module" in a way that prevents it from being unix-y. The Unix philosophy is about separation of concerns, not having a bunch of interchangable options for low-level system components.

stouset 6y ago
You know, I had to integrate with `journald` a bit ago and I was prepared for a nightmare after all the ruckus raised about systemd. And you know what? It’s fantastic. The API is generally well-designed (if not without a few sharp corners) and the whole thing is incredibly well thought out. Sure, plain text logs let you use standard UNIX tools. But doing so sucks. God help you if there’s a newline in your logs or if you have to ensure that you iterate over all the logs even across restarts or if you need to parse logs back out from text into the underlying attributes.
- pnako 6y ago
  Next, have all the settings in some sort of central database. And in 20 years, Red Hat will have finally finished re-inventing Windows NT on top of the Linux kernel.
  - zenlot 6y ago
    Have you ever worked with IBMs AIX? It has ODM and it’s amazing. Systemd is going to the right direction.
    - pnako 6y ago

ac29 6y ago

> the Unix way This gets pulled out far too often. Systemd is a family of projects thast are largely modular and independent, not a single binary that takes over everything. Each part's goal is to do one thing, and you're free to take or leave each piece. By this logic, Bell Labs should have never worked on UNIX or C - they were a telephone company!