4 ms·

> Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities. Ahh, there's the talking point I mentioned in my e

by pdkl95 12y ago

> Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities. Ahh, there's the talking point I mentioned in my earlier post[1]. What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity). As an example in the opposite direction, consider busybox. While it compiles into a single binary, the features provided by busybox are very modular. You could remove any of the utilities it can emulate without that change cascading into lots of other unrelated features (with build system support), and I could replace any of the utilities with something else (i.e. the standard non-busybox version) by simply removing a symlink. Systemd is designed in the opposite manner, on purpose. They put every but of code the project absorbs into the same repository, claiming it makes development easier. Of course it does... initially; you get to skip the all those clearly and rigorously defined interfaces. They can seem like unnecessary work in the beginning, but it is going to be hell maintaining that mess of code in the long run. [1] https://news.ycombinator.com/item?id=9515413 https://news.ycombinator.com/item?id=9515413 [2] See the "Rule of Modularity": http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877537 http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...

Ao7bei3s 12y ago
> What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. What you're not understanding is that these other binaries do not run as PID 1, which is what nextos wrongly claimed. > This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity). Which is the exact opposite of what has happened during the sysvinit times.
- pdkl95 12y ago
  > other binaries do not run as PID 1, which is what nextos wrongly claimed. I never claimed they did. Obviously, I was replying to this claim: "Systemd is not a monolith, it is a bunch of various utilities." > Which is the exact opposite of what has happened during the sysvinit times. I never mentioned anything about sysvinit, which has nothing to do with the bad design in systemd. Regarding those times, I would agree that the older sysv-rc/initscripts were not that great either, which is why many of us moved to OpenRC a long time ago.
chris_wot 12y ago
This honestly seems like FUD. Currently the Sys-V like serialisation of services at startup hasn't been efficient, and sysvinit doesn't handle event based kernel features at all well. And it's definitely not modular. As for this argument that it's monolithic in its code organisation - lolwut? You don't need to have a seperate repository for each binary, hardly anyone does that. When you talk about clearly and vigorously defined interfaces, it seems to already have them - and I hardly consider sysvinit to be a great example of such a thing - a bunch of cobbled together shell scripts serialised into a particular order isn't particularly clean or elegant. Heck, it's not even necessarily easy to troubleshoot if things go wrong. The systemd source is in one git repo, sure, but I can't see why maintenance will be a burden. What in particular concerns you? You do realize that there are only a few binaries? Let's look at them: networkd: handles network events - when a network device is created it handles setup. No, it does not supplant udev. Read here an overview: https://coreos.com/blog/intro-to-systemd-networkd/ https://coreos.com/blog/intro-to-systemd-networkd/ Not a bad idea here: and very sensible aspect of systemd. journald - collects log data from a variety of sources and puts it into a binary indexed data file. The most controversial aspect of systemd, but of course as is overlooked all the log data can be forwarded to syslog, kmsg, the console or wall via a simple configuration change. Or, you can swap out the component: https://fitzcarraldoblog.wordpress.com/2014/09/20/change-systemds-binary-logging-to-text-logging-in-sabayon-linux/ https://fitzcarraldoblog.wordpress.com/2014/09/20/change-sys... logind handles logins systemd-user-sessions.service allows restricting user logins via PAM Then there are the systemd units - it handles sockets for socket activation, which is a key reason Debian chose systemd over Upstart. It handles devices via udev, mount points (a key aspect to initialising systems), automount, swap, path-based activation and timers. I can't see how any of the above should NOT be part of an init system. Init systems should be capable of handling dynamic events. All the technical arguments I've seen so far, with the exception of binary log files, don't hold any water. There are apparently security concerns over PID 1 - but they seem rather specious. Have a look at the dependency list here at https://people.debian.org/~stapelberg/docs/systemd-dependencies.html https://people.debian.org/~stapelberg/docs/systemd-dependenc... if you don't believe me. There's a lot of bashing of systemd, but most of it (if not all of it!) is unwarranted and can be verified with even a modicum of research.
- 12y ago
the_why_of_y 12y ago
Many of the binaries provided by systemd indeed have a non-public interface between them, but they are all compile-time optional, with the exception of journald. Would you say that the people who claim they are migrating to FreeBSD because of systemd are all misguided because FreeBSD, having all of its kernel and userland plumbing in a single repository and tightly coupled, is a monolithic system by design? Here's a bug on Debian/kFreeBSD about a FreeBSD 10 kernel ABI change breaking ifconfig: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740509#51 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740509#51 Would you call postfix monolithic too, given that you cannot replace any of its binaries with one from e.g. qmail because the interfaces are different? Is postfix any better than sendmail in this regard? > They can seem like unnecessary work in the beginning, but it is going to be hell maintaining that mess of code in the long run. Public interfaces aren't without cost - putting public interfaces where they don't belong is one of the best ways to add accidental complexity to your project and make it much harder to maintain. If you find some minor design flaw in a non-public interface, you think about what the ideal interface would do, and then you just change the existing interface because you have control of both client and provider of the interface. If it's a public interface it has to be versioned and you never can remove the implementation of older versions because you have no idea who is using it and what would break, and introducing a new version adds enough extra work that some minor design flaws in the interface will never be fixed because the effort-to-benefit trade-off is different if you have to keep compatibility in mind. See this article from another successful monolithic project for some good reasons to have internal-only interfaces. https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt https://www.kernel.org/doc/Documentation/stable_api_nonsense... If monolithic systems are so obviously inferior, why are micro-kernel implementations of UNIX mostly a historic curiosity?
mercurial 12y ago
> What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity). Designs don't run under PID 1, or any other PIDs. Binaries do. You can't both complain about how insecure systemd is because it has a lot of code under PID 1, and then claim that the size of the code actually running under PID 1 is irrelevant.

by pdkl95 12y ago

Ao7bei3s 12y ago

> What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. What you're not understanding is that these other binaries do not run as PID 1, which is what nextos wrongly claimed. > This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity). Which is the exact opposite of what has happened during the sysvinit times.

pdkl95 12y ago
> other binaries do not run as PID 1, which is what nextos wrongly claimed. I never claimed they did. Obviously, I was replying to this claim: "Systemd is not a monolith, it is a bunch of various utilities." > Which is the exact opposite of what has happened during the sysvinit times. I never mentioned anything about sysvinit, which has nothing to do with the bad design in systemd. Regarding those times, I would agree that the older sysv-rc/initscripts were not that great either, which is why many of us moved to OpenRC a long time ago.

chris_wot 12y ago

This honestly seems like FUD. Currently the Sys-V like serialisation of services at startup hasn't been efficient, and sysvinit doesn't handle event based kernel features at all well. And it's definitely not modular. As for this argument that it's monolithic in its code organisation - lolwut? You don't need to have a seperate repository for each binary, hardly anyone does that. When you talk about clearly and vigorously defined interfaces, it seems to already have them - and I hardly consider sysvinit to be a great example of such a thing - a bunch of cobbled together shell scripts serialised into a particular order isn't particularly clean or elegant. Heck, it's not even necessarily easy to troubleshoot if things go wrong. The systemd source is in one git repo, sure, but I can't see why maintenance will be a burden. What in particular concerns you? You do realize that there are only a few binaries? Let's look at them: networkd: handles network events - when a network device is created it handles setup. No, it does not supplant udev. Read here an overview: https://coreos.com/blog/intro-to-systemd-networkd/ https://coreos.com/blog/intro-to-systemd-networkd/ Not a bad idea here: and very sensible aspect of systemd. journald - collects log data from a variety of sources and puts it into a binary indexed data file. The most controversial aspect of systemd, but of course as is overlooked all the log data can be forwarded to syslog, kmsg, the console or wall via a simple configuration change. Or, you can swap out the component: https://fitzcarraldoblog.wordpress.com/2014/09/20/change-systemds-binary-logging-to-text-logging-in-sabayon-linux/ https://fitzcarraldoblog.wordpress.com/2014/09/20/change-sys... logind handles logins systemd-user-sessions.service allows restricting user logins via PAM Then there are the systemd units - it handles sockets for socket activation, which is a key reason Debian chose systemd over Upstart. It handles devices via udev, mount points (a key aspect to initialising systems), automount, swap, path-based activation and timers. I can't see how any of the above should NOT be part of an init system. Init systems should be capable of handling dynamic events. All the technical arguments I've seen so far, with the exception of binary log files, don't hold any water. There are apparently security concerns over PID 1 - but they seem rather specious. Have a look at the dependency list here at https://people.debian.org/~stapelberg/docs/systemd-dependencies.html https://people.debian.org/~stapelberg/docs/systemd-dependenc... if you don't believe me. There's a lot of bashing of systemd, but most of it (if not all of it!) is unwarranted and can be verified with even a modicum of research.

12y ago

the_why_of_y 12y ago

Many of the binaries provided by systemd indeed have a non-public interface between them, but they are all compile-time optional, with the exception of journald. Would you say that the people who claim they are migrating to FreeBSD because of systemd are all misguided because FreeBSD, having all of its kernel and userland plumbing in a single repository and tightly coupled, is a monolithic system by design? Here's a bug on Debian/kFreeBSD about a FreeBSD 10 kernel ABI change breaking ifconfig: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740509#51 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740509#51 Would you call postfix monolithic too, given that you cannot replace any of its binaries with one from e.g. qmail because the interfaces are different? Is postfix any better than sendmail in this regard? > They can seem like unnecessary work in the beginning, but it is going to be hell maintaining that mess of code in the long run. Public interfaces aren't without cost - putting public interfaces where they don't belong is one of the best ways to add accidental complexity to your project and make it much harder to maintain. If you find some minor design flaw in a non-public interface, you think about what the ideal interface would do, and then you just change the existing interface because you have control of both client and provider of the interface. If it's a public interface it has to be versioned and you never can remove the implementation of older versions because you have no idea who is using it and what would break, and introducing a new version adds enough extra work that some minor design flaws in the interface will never be fixed because the effort-to-benefit trade-off is different if you have to keep compatibility in mind. See this article from another successful monolithic project for some good reasons to have internal-only interfaces. https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt https://www.kernel.org/doc/Documentation/stable_api_nonsense... If monolithic systems are so obviously inferior, why are micro-kernel implementations of UNIX mostly a historic curiosity?

mercurial 12y ago

> What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity). Designs don't run under PID 1, or any other PIDs. Binaries do. You can't both complain about how insecure systemd is because it has a lot of code under PID 1, and then claim that the size of the code actually running under PID 1 is irrelevant.