4 ms·

The basic summary is basically: Developers love systemd, it's much more "developer friendly" and the way it's laid out makes sense to them (e.g. your love of jo

by phil21 9y ago

The basic summary is basically: Developers love systemd, it's much more "developer friendly" and the way it's laid out makes sense to them (e.g. your love of journalctl, which is bizzaro-world for me). No more thinking about ugly operating systems and those silly details! Old school sysadmins and those who actually get their hands dirty with Linux systems under the hood despise it for what it is. It's the windowsfication of Linux, in my - and many others - opinions. A giant PID 1 that controls everything, re-implementing such basics as ntp and rm, is imo entirely anti-unix-like. Systemd is great until it breaks. Once it breaks though, good luck. They've re-invented the wheel multiple times over, and as time goes on more and more things become part of monolithic systemd. If you do happen to find a weird bug, prepare to get yelled at and be forced to vigorously defend your bug report. The joke in the office is when Pulseaudio support gets added.

mateuszf 9y ago
> A giant PID 1 that controls everything Kernel is also a giant code that controls everything. Is this such a bad thing?
- VLM 9y ago
  Yes. There's been a lot of theoretical and practical work around the last couple decades about putting as little as possible in your single point of technical and legal/patent failure. Small tools that do as little as possible, but do it very well, composed into bigger systems. Philosophically identical to RISC vs CISC.
- Twirrim 9y ago
  The kernel is a component that has a straightforward purpose on a system, and interferes as little as possible with the actual usage of the system. You could describe it as "It gets the job done, and stays the hell out of the way" Even with the kernel there is an element of choice about what parts of it you do / don't use, e.g. you can use ext4, XFS etc. etc. and even have the choice of providing kernel modules so you can bolt on ZFS. The kernel doesn't start to dictate who or what software does DNS resolution, for example. systemd keeps taking over more and more control of various aspects of your system and effectively removing choice by making it hard to use alternatives because it starts to make assumptions based on the inbuilt versions. systemd is presenting you with a "one-size-fits-all" scenario. The problem is one size never fits all. One of the biggest strengths within the *nix ecosystem has been the fundamental understanding no two use cases are entirely the same, what works well for one purpose doesn't work well for others, and choosing the right software to meet those various purposes is invaluable. It's impossible to make software that is efficient for every single use case. The freedom and possibility to choose the right tool for the right task is essential to designing and building new, innovative, or even just plain old efficient systems.
  - fireflash38 9y ago
    I hear all this, but I never really see examples of it, which would really help your argument. People hear the 'theoretical', but theoretical doesn't matter if it never makes it to the practical.
    - Twirrim 9y ago
      Okay, so an example: dnsmas
  - VLM 9y ago
    "The problem is one size never fits all." Well written and agreed with but I'd add management of legal risk and labor productivity. You could compile a http server into the kernel, which would benefit microscopically in ways almost all people don't care about, then product tie it into other projects to successfully kill nginx and apache off. Or you could simply run Apache in a non-monolithic way. What happens if a submarine patent surfaces? Or a critical "must fix this instant" security bug hits? Well, if you're running Apache and not doing anything too weird, you'll be back up and running on nginx in a couple minutes and the world yawns. Or you can upgrade/downgrade/patch apache without messing up your DNS service or NTP service or whatever else. But what happens on a monolith? Well, you could ... I guess you decide if you're better off infringing the patent or replacing the ENTIRE monolith. Those things happen. Eventually its inevitable that something in the monolith will become unacceptable to run, legally or from a security perspective, and then the entire monolith has to go, simultaneously. Life with separate tools is incredibly easier. Embrace, extend, submarine patent, extinguish. There are also labor productivity issues with monoliths. Best expressed via a standard HN automobile analogy, where technically I could completely restore a vintage jeep automobile using one tool, a swiss army knife. Simplistically, all automobile restorations should be done with swiss army knives to minimize the paradox of choice and minimize the massive expense of tool training. In practice it seems obvious I would infinitely prefer not restore an automobile using a single swiss army knife as my only tool. Even a really bad toolbox would be better than using one swiss army knife. Given the choice between using an old, slight imperfect yet historically proven highly successful toolbox vs only being able to use one brand new untested swiss army knife... thats the kind of thing that makes me glad I use *bsd instead of linux.
- epistasis 9y ago
  Of course it is! Which is why it's preferable to put things in user space whenever possible. There were even microkernels for a while to try to mitigate the design difficulty of kernels; however at least with Linux what won out was lots of testing and very very picky maintainers. Even if systemd is at the very high standard of kernel reliability, it would be better design to break out the monolithic parts where possible. The kernel is the way it is because it needs to be, not because it's a preferable way of writing code.
  - Etzos 9y ago
    I see this kind of thing mentioned a lot which really disappoints me because systemd is not as monolithic as people seem to think it is. systemd (the init system) is a relatively small component with a modest set of dependencies. systemd (the umbrella project) includes a number of other projects which are separate and many of them aren't even required and are easy to replace with something else if it's needed. If you're a programmer I highly recommend taking a quick browser through the systemd source code, it doesn't take long to see that it isn't really monolithic at all and is in fact a combination of individual tools which are combined to accomplish things. Just because they're all under the systemd umbrella and all in the same repository does not mean it's all one binary and that parts can't be swapped out.
- digi_owl 9y ago
  That one can liken pid1 to the kernel should give one pause for thought, and not in systemd's favor...
jbergstroem 9y ago
I think this is very well put. The ever-going philosophical debate is about interface complexity (developer vs sysop), not how it actually works.
- digi_owl 9y ago
  And also between small and large deployments. Systemd has over the sprouted a whole bunch of parts that fit large (cloud) scale deployments. Where things get messy is when all you want to do is to spin up a gray box on the shelf to handle some internal data, and at that point systemd, and a whole bunch of other "plumbing" that has sprouted within the Linux ecosystem in recent years (often under the Freedesktop umbrella, even though it seems to have a ill fit on desktops), becomes a beast to wrangle into submission rather than an assistant.
hiciu 9y ago
I, for one, am a old school sysop that is very happy with systemd as a modern service manager. I bet there are literally dozens of us :). > A giant PID 1 that controls everything > monolithic systemd Technically speaking only small portion of systemd is running as pid 1. This has been explained many times: https://news.ycombinator.com/item?id=9515789 https://news.ycombinator.com/item?id=9515789 and I'm not going to explain this again. > re-implementing such basics as ntp Systemd-timesyncd is a minimal ntp client. This is not a replacement for ntp. You are free to use full blown ntpd if you want. Think of it as a dns resolver inside your libc vs running proper caching dns server. It's the same situation. > more and more things become part of monolithic systemd https://www.youtube.com/watch?v=bdmv2FQRHWg https://www.youtube.com/watch?v=bdmv2FQRHWg :)
petre 9y ago
Well, not all developers. The first thing I do on systemd Linux systems is install rsyslogd and runit. We run our own services under runit which is started by systemd (because that's what the distro ships with). Runit works flawlessly.

by phil21 9y ago

mateuszf 9y ago

> A giant PID 1 that controls everything Kernel is also a giant code that controls everything. Is this such a bad thing?

VLM 9y ago
Yes. There's been a lot of theoretical and practical work around the last couple decades about putting as little as possible in your single point of technical and legal/patent failure. Small tools that do as little as possible, but do it very well, composed into bigger systems. Philosophically identical to RISC vs CISC.
Twirrim 9y ago
The kernel is a component that has a straightforward purpose on a system, and interferes as little as possible with the actual usage of the system. You could describe it as "It gets the job done, and stays the hell out of the way" Even with the kernel there is an element of choice about what parts of it you do / don't use, e.g. you can use ext4, XFS etc. etc. and even have the choice of providing kernel modules so you can bolt on ZFS. The kernel doesn't start to dictate who or what software does DNS resolution, for example. systemd keeps taking over more and more control of various aspects of your system and effectively removing choice by making it hard to use alternatives because it starts to make assumptions based on the inbuilt versions. systemd is presenting you with a "one-size-fits-all" scenario. The problem is one size never fits all. One of the biggest strengths within the *nix ecosystem has been the fundamental understanding no two use cases are entirely the same, what works well for one purpose doesn't work well for others, and choosing the right software to meet those various purposes is invaluable. It's impossible to make software that is efficient for every single use case. The freedom and possibility to choose the right tool for the right task is essential to designing and building new, innovative, or even just plain old efficient systems.
- fireflash38 9y ago
  I hear all this, but I never really see examples of it, which would really help your argument. People hear the 'theoretical', but theoretical doesn't matter if it never makes it to the practical.
  - Twirrim 9y ago
    Okay, so an example: dnsmas
- VLM 9y ago
  "The problem is one size never fits all." Well written and agreed with but I'd add management of legal risk and labor productivity. You could compile a http server into the kernel, which would benefit microscopically in ways almost all people don't care about, then product tie it into other projects to successfully kill nginx and apache off. Or you could simply run Apache in a non-monolithic way. What happens if a submarine patent surfaces? Or a critical "must fix this instant" security bug hits? Well, if you're running Apache and not doing anything too weird, you'll be back up and running on nginx in a couple minutes and the world yawns. Or you can upgrade/downgrade/patch apache without messing up your DNS service or NTP service or whatever else. But what happens on a monolith? Well, you could ... I guess you decide if you're better off infringing the patent or replacing the ENTIRE monolith. Those things happen. Eventually its inevitable that something in the monolith will become unacceptable to run, legally or from a security perspective, and then the entire monolith has to go, simultaneously. Life with separate tools is incredibly easier. Embrace, extend, submarine patent, extinguish. There are also labor productivity issues with monoliths. Best expressed via a standard HN automobile analogy, where technically I could completely restore a vintage jeep automobile using one tool, a swiss army knife. Simplistically, all automobile restorations should be done with swiss army knives to minimize the paradox of choice and minimize the massive expense of tool training. In practice it seems obvious I would infinitely prefer not restore an automobile using a single swiss army knife as my only tool. Even a really bad toolbox would be better than using one swiss army knife. Given the choice between using an old, slight imperfect yet historically proven highly successful toolbox vs only being able to use one brand new untested swiss army knife... thats the kind of thing that makes me glad I use *bsd instead of linux.
epistasis 9y ago
Of course it is! Which is why it's preferable to put things in user space whenever possible. There were even microkernels for a while to try to mitigate the design difficulty of kernels; however at least with Linux what won out was lots of testing and very very picky maintainers. Even if systemd is at the very high standard of kernel reliability, it would be better design to break out the monolithic parts where possible. The kernel is the way it is because it needs to be, not because it's a preferable way of writing code.
- Etzos 9y ago
  I see this kind of thing mentioned a lot which really disappoints me because systemd is not as monolithic as people seem to think it is. systemd (the init system) is a relatively small component with a modest set of dependencies. systemd (the umbrella project) includes a number of other projects which are separate and many of them aren't even required and are easy to replace with something else if it's needed. If you're a programmer I highly recommend taking a quick browser through the systemd source code, it doesn't take long to see that it isn't really monolithic at all and is in fact a combination of individual tools which are combined to accomplish things. Just because they're all under the systemd umbrella and all in the same repository does not mean it's all one binary and that parts can't be swapped out.
digi_owl 9y ago
That one can liken pid1 to the kernel should give one pause for thought, and not in systemd's favor...

jbergstroem 9y ago

I think this is very well put. The ever-going philosophical debate is about interface complexity (developer vs sysop), not how it actually works.

digi_owl 9y ago
And also between small and large deployments. Systemd has over the sprouted a whole bunch of parts that fit large (cloud) scale deployments. Where things get messy is when all you want to do is to spin up a gray box on the shelf to handle some internal data, and at that point systemd, and a whole bunch of other "plumbing" that has sprouted within the Linux ecosystem in recent years (often under the Freedesktop umbrella, even though it seems to have a ill fit on desktops), becomes a beast to wrangle into submission rather than an assistant.

hiciu 9y ago

I, for one, am a old school sysop that is very happy with systemd as a modern service manager. I bet there are literally dozens of us :). > A giant PID 1 that controls everything > monolithic systemd Technically speaking only small portion of systemd is running as pid 1. This has been explained many times: https://news.ycombinator.com/item?id=9515789 https://news.ycombinator.com/item?id=9515789 and I'm not going to explain this again. > re-implementing such basics as ntp Systemd-timesyncd is a minimal ntp client. This is not a replacement for ntp. You are free to use full blown ntpd if you want. Think of it as a dns resolver inside your libc vs running proper caching dns server. It's the same situation. > more and more things become part of monolithic systemd https://www.youtube.com/watch?v=bdmv2FQRHWg https://www.youtube.com/watch?v=bdmv2FQRHWg :)

petre 9y ago

Well, not all developers. The first thing I do on systemd Linux systems is install rsyslogd and runit. We run our own services under runit which is started by systemd (because that's what the distro ships with). Runit works flawlessly.