9 ms·

> Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either. No. Only a small part of systemd runs as PID 1. Syst

> Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either. No. Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities. > However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. I agree. This sounds scary. However, it does not mean that distros will hurry to adopt this kind of system. I also get the impression that it is targeted more toward special use cases than intended to replace traditional package managers. > Pulseaudio is slow and unreliable. While anecdote is not data, I never had any issue with it. > Dbus is quite inefficient. They did not invent Dbus, and using the foremost userland IPC mechanism to communicate is not unreasonable (since, as mentioned above, systemd is a bunch of utilities, they do need some form of IPC). I don't think it has an impact in practice.

pdkl95 11y 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 11y 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 11y 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 11y 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.

pdkl95 11y 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 11y 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 11y 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 11y 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.