4 ms·

> 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.
- m45t3r 9y ago
  > 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. You can also do the same with systemd. Don't want to use journalctl? Fine, forward logs to syslog. You can argue that you can't disable journalctl, however depending of the feature you want in kernel you can't disable some modules thanks to inter-dependency. > The kernel doesn't start to dictate who or what software does DNS resolution, for example. Neither does systemd. I don't use systemd-networkd at all in my machine and it still works fine. > 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. I kinda concur with you, however I also try to understand why they're adding support for all those things. In general, there is a sound resolution to include something in systemd, even if I or you does not agree. And remember, except for journalctl, systemd does not force anything at you if you just want its init system. > systemd is presenting you with a "one-size-fits-all" scenario. The problem is one size never fits all. It is not. All systemd implements are foundations to build bigger and more advanced functionality. systemd-nspawn is basically chmod on steroids, you can't call it a container system. However, you can use systemd-nspawn to build a container system like rkt. systemd-networkd is also too bare bones to be called a "network manager", etc etc. > 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. See above response. > 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. Yeah, that is why systemd does not force you to use anything (except journalctl).
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...

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.
m45t3r 9y ago
> 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. You can also do the same with systemd. Don't want to use journalctl? Fine, forward logs to syslog. You can argue that you can't disable journalctl, however depending of the feature you want in kernel you can't disable some modules thanks to inter-dependency. > The kernel doesn't start to dictate who or what software does DNS resolution, for example. Neither does systemd. I don't use systemd-networkd at all in my machine and it still works fine. > 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. I kinda concur with you, however I also try to understand why they're adding support for all those things. In general, there is a sound resolution to include something in systemd, even if I or you does not agree. And remember, except for journalctl, systemd does not force anything at you if you just want its init system. > systemd is presenting you with a "one-size-fits-all" scenario. The problem is one size never fits all. It is not. All systemd implements are foundations to build bigger and more advanced functionality. systemd-nspawn is basically chmod on steroids, you can't call it a container system. However, you can use systemd-nspawn to build a container system like rkt. systemd-networkd is also too bare bones to be called a "network manager", etc etc. > 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. See above response. > 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. Yeah, that is why systemd does not force you to use anything (except journalctl).

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...