8 ms·

> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these pro

> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sharing between different components, but it's not a monolith. On my Debian system it ships 50+ different binaries split across 8 different packages. You can use the network management without using the NTP service, the journal without using the device manager, the tmpfiles manager without using the user manager, etc. Most, if not all, of these components only depend on the service manager (i.e. PID 1). That's more or less unavoidable for an event-driven system, there'll always be a dependency on the event bus. The components itself can be freely swapped out for different, even incompatible, implementations. If you don't even want to run the service manager, all external interfaces are stable, pretty well-documented and relatively straightforward, so it's even possible to write a completely independent implementation without breaking external dependencies. By the way, if we're talking about loose coupling and POSIX, this OpenBSD implementation isn't it either. resolvd has an hardcoded reference to the unwind socket, and they use a special BSD-only socket type to communicate between the different processes.

throw0101a 5y ago
> Yes, there's some code sharing between different components, but it's not a monolith. So I can take the code for just systemd-resolved and port it to FreeBSD or Solaris?
- deleted 5y ago
  [deleted]
- op00to 5y ago
  What part of “not a monolith” requires portability to other operating systems?
  - pwdisswordfish8 5y ago
    The use of stable, documented, orthogonal interfaces. That part.
rkangel 5y ago
systemd fundamentally made a branding mistake, not a technical one. Putting all of these components under one 'systemd' umbrella name meant that people simplistically think of them as one thing and then start making the 'Unix philosophy' argument.
- op00to 5y ago
  Moving the goalposts yet again. Not only must it be technically superior for everyone, not only must it adhere to decades old computing dogma, but now it must be branded in such a way that it’s individual components must be unidentifiable?
- dralley 5y ago
  We're in a thread about OpenBSD, a Unix that keeps literally the entire OS (except for ports) in one repo, and ships them together. So this is a strange criticism to make.
  - csande17 5y ago
    You're right that Linux is pretty much the only operating system where users can mix and match core system components. That's precisely why people get so mad about systemd! If I wanted to use an operating system where all the components were tightly coupled and made by a single vendor, I'd use Windows, or macOS, or a BSD. (In fact I do use those operating systems when that's what I want.) But I would also like for other kinds of systems to exist in the world. I downloaded Linux because I wanted to use an operating system that _wasn't_ macOS!
    - dralley 5y ago
      They are free to make that criticism but they should do it without invoking "the Unix philosophy" which Linux has never adhered to. Unix never had interchangable components like that.
      - pjmlp 5y ago
        Specially because "the Unix philosophy" as preached by Linux afficionados never happened in real UNIX, it keeps being preached as some kind of cargo cult by people that weren't even around during the UNIX wars heyday.
IgorPartola 5y ago
What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working. systemd has a good init system and a decent set of other services. Could things be improved? Sure. But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switching which DHCP client or which NTP daemon I’m using?
- throw0101a 5y ago
  > What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. Because some implementations have time jump while others have it slew it slowly. On boot-up a jump may be fine to get with ± some number of milliseconds, but once the system is running, there are situations where jumps could be a problem (especially in the negative direction, where a moment is "repeated"). > But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switching which DHCP client or which NTP daemon I’m using? Because as a sysadmin it is your job to understand how a system works. There should be very little "magic" happening. Sure there are many times where things Just Working™ is fine (it's why I run a Mac at home), but many others where you should understand why things are working the way they are.
  - Denvercoder9 5y ago
    > Because as a sysadmin it is your job to understand how a system works. No, as a sysadmin your job is to deliver a working system. To do that it usually helps to understand how the system works, but it's not a necessity. As long as something keeps working, and you're equipped to go digging if and when it's necessary, it's fine to not understand or know how something works.
    - totony 5y ago
      >As long as something keeps working, and you're equipped to go digging if and when it's necessary, it's fine to not understand or know how something works How do you know it's working if you don't understand it? What's preventing some admin socket to be activated, is the firewall good, etc
richardfey 5y ago
> Most, if not all, of these components only depend on the service manager (i.e. PID 1). And dbus. The components being discussed here don't depend on either.
pwdisswordfish8 5y ago
> On my Debian system it ships 50+ different binaries split across 8 different packages. Nobody cares. The number of binaries is irrelevant. What is relevant are stable, documented interfaces between them that someone else could implement if they so choose and remain compatible. And systemd people have repeatedly said they do not intend to maintain stable interfaces between the various components of systemd. As long as that's true, it's completely fair to call systemd a monolith, 50+ binaries or not. In other words, this is a ‘only Microsoft employees may use the secret 7 on the dice’ situation.
- dfhsfgsdfhh 5y ago
  What's really relevant is market share. Guess what? Systemd is winning because it massively sucks less than what existed before it.
  - AstralStorm 5y ago
    No, it's winning because RedHat is forcing everyone's hand by hiring most of Linux desktop developers, and the rest are insufficient to maintain other solutions to keep feature parity. It's Embrace Extend Extinguish in action, except by using the force of running two biggest distributions in addition to GNOME project. (And a bunch of others depending directly on them.) Even Debian was unable to weather all the dependencies using the new interfaces. Gentoo tries still with OpenRC, more or less successfully.
    - circularfoyers 5y ago
      I don't think Red Hat are forcing anyone's hand. I think the fact that Red Hat are hiring passionate developers to work on something they love full time is something they should be lauded for. Of course Red Hat have to pick a project they're going to focus on, they can't focus on every implementation, and it only makes sense that community projects aren't going to have feature parity with software that's being built for enterprise use cases, worked on people whose it's their full time job. It's because of the wider support that the majority of distros decided to go with them.

throw0101a 5y ago

> Yes, there's some code sharing between different components, but it's not a monolith. So I can take the code for just systemd-resolved and port it to FreeBSD or Solaris?

deleted 5y ago
[deleted]
op00to 5y ago
What part of “not a monolith” requires portability to other operating systems?
- pwdisswordfish8 5y ago
  The use of stable, documented, orthogonal interfaces. That part.

rkangel 5y ago

systemd fundamentally made a branding mistake, not a technical one. Putting all of these components under one 'systemd' umbrella name meant that people simplistically think of them as one thing and then start making the 'Unix philosophy' argument.

op00to 5y ago
Moving the goalposts yet again. Not only must it be technically superior for everyone, not only must it adhere to decades old computing dogma, but now it must be branded in such a way that it’s individual components must be unidentifiable?
dralley 5y ago
We're in a thread about OpenBSD, a Unix that keeps literally the entire OS (except for ports) in one repo, and ships them together. So this is a strange criticism to make.
- csande17 5y ago
  You're right that Linux is pretty much the only operating system where users can mix and match core system components. That's precisely why people get so mad about systemd! If I wanted to use an operating system where all the components were tightly coupled and made by a single vendor, I'd use Windows, or macOS, or a BSD. (In fact I do use those operating systems when that's what I want.) But I would also like for other kinds of systems to exist in the world. I downloaded Linux because I wanted to use an operating system that _wasn't_ macOS!
  - dralley 5y ago
    They are free to make that criticism but they should do it without invoking "the Unix philosophy" which Linux has never adhered to. Unix never had interchangable components like that.
    - pjmlp 5y ago
      Specially because "the Unix philosophy" as preached by Linux afficionados never happened in real UNIX, it keeps being preached as some kind of cargo cult by people that weren't even around during the UNIX wars heyday.

IgorPartola 5y ago

What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working. systemd has a good init system and a decent set of other services. Could things be improved? Sure. But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switching which DHCP client or which NTP daemon I’m using?

throw0101a 5y ago
> What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. Because some implementations have time jump while others have it slew it slowly. On boot-up a jump may be fine to get with ± some number of milliseconds, but once the system is running, there are situations where jumps could be a problem (especially in the negative direction, where a moment is "repeated"). > But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switching which DHCP client or which NTP daemon I’m using? Because as a sysadmin it is your job to understand how a system works. There should be very little "magic" happening. Sure there are many times where things Just Working™ is fine (it's why I run a Mac at home), but many others where you should understand why things are working the way they are.
- Denvercoder9 5y ago
  > Because as a sysadmin it is your job to understand how a system works. No, as a sysadmin your job is to deliver a working system. To do that it usually helps to understand how the system works, but it's not a necessity. As long as something keeps working, and you're equipped to go digging if and when it's necessary, it's fine to not understand or know how something works.
  - totony 5y ago
    >As long as something keeps working, and you're equipped to go digging if and when it's necessary, it's fine to not understand or know how something works How do you know it's working if you don't understand it? What's preventing some admin socket to be activated, is the firewall good, etc

richardfey 5y ago

> Most, if not all, of these components only depend on the service manager (i.e. PID 1). And dbus. The components being discussed here don't depend on either.

pwdisswordfish8 5y ago

> On my Debian system it ships 50+ different binaries split across 8 different packages. Nobody cares. The number of binaries is irrelevant. What is relevant are stable, documented interfaces between them that someone else could implement if they so choose and remain compatible. And systemd people have repeatedly said they do not intend to maintain stable interfaces between the various components of systemd. As long as that's true, it's completely fair to call systemd a monolith, 50+ binaries or not. In other words, this is a ‘only Microsoft employees may use the secret 7 on the dice’ situation.

dfhsfgsdfhh 5y ago
What's really relevant is market share. Guess what? Systemd is winning because it massively sucks less than what existed before it.
- AstralStorm 5y ago
  No, it's winning because RedHat is forcing everyone's hand by hiring most of Linux desktop developers, and the rest are insufficient to maintain other solutions to keep feature parity. It's Embrace Extend Extinguish in action, except by using the force of running two biggest distributions in addition to GNOME project. (And a bunch of others depending directly on them.) Even Debian was unable to weather all the dependencies using the new interfaces. Gentoo tries still with OpenRC, more or less successfully.
  - circularfoyers 5y ago
    I don't think Red Hat are forcing anyone's hand. I think the fact that Red Hat are hiring passionate developers to work on something they love full time is something they should be lauded for. Of course Red Hat have to pick a project they're going to focus on, they can't focus on every implementation, and it only makes sense that community projects aren't going to have feature parity with software that's being built for enterprise use cases, worked on people whose it's their full time job. It's because of the wider support that the majority of distros decided to go with them.