5 ms·

Sure, it might be because System D integrates so tightly with the whole ecosystem that it is hard to replace it. Or: Those folks who write rants about system d

Sure, it might be because System D integrates so tightly with the whole ecosystem that it is hard to replace it. Or: Those folks who write rants about system d are not very active in contributing to a distribution that runs without it. With some discussions, you have that feeling that there are "those who talk, and those who do".

gorkonsine 9y ago
It's the latter. It didn't take anywhere near 2 full years to integrate systemd into Debian, so obviously there's a far smaller number of people in Devuan working to undo that. The whole systemd shouting match has been dominated by anti-systemd people who are the extremely vocal majority, happy to blog incessantly about how "evil" systemd is, but apparently not that happy to contribute their time to an alternative that's more to their liking. I'm not a systemd proponent (or detractor), as I'm not a professional sysadmin and just use Mint personally, but throughout that debacle it was fairly obvious which side was the more religious and less rational, and also less willing to put their money (or time) where their mouths were. Consequently, without doing any deep research on it myself, I tend to believe the systemd proponents far more.
aleksei 9y ago
Well, people are allowed to have opinions even if they dont' have the time, resources, or know-how to contribute to a solution, so yes, there may very well be "those who talk, and those who do". I don't see what your point is.
- wirrbel 9y ago
  people are allowed to have their opinions, and after a while, I reserve my right to not listen to certain opinions anymore if they are not backed up.
  - benchaney 9y ago
    If that is the attitude you take don't be surprised when people don't listen to your opinions.
  - falcolas 9y ago
    That same paintbrush also applies to those who denigrate people who have problems with systemd without putting forth the effort to see their point of view. The top comment on this post is a great example. People have been giving well reasoned arguments against systemd for years, yet the first and most upvoted salvo in this article is "I have yet to see a well reasoned argument against systemd". The hate for systemd gained steam when people stopped listening to well reasoned arguments because it also provided parallel startup and unit files, and really hit its stride when the developers ignore legitimate bug reports as "working as intended" (the latest numeric user issue is but the latest in an established history of such issues).
dijit 9y ago
Unfortunately I'm a sysadmin, I deal with systemd/sysvinit every single day often dozens of times a day, but I do not have the means/skills to help remove integrations. So, SystemD affects me daily and yet I can do nothing, I'm helpless. Which is why I'm rather vocal.
slau 9y ago
Or maybe we just gave up on Debian, and decided to spend our efforts somewhere else? I've been fairly vocal against systemd, and not because of Poettering. I'm no fan of the man, and I strongly agree with a lot of the points he made in his initial blog posts when introducing systemd. I think he's probably very talented---I'm not in a position to judge that. I wouldn't be against systemd if it were just an init system. The problem is that it's not. That's the end of my argument. If systemd were just an init system, I'd be very happy to have it on my machines. Poettering even admitted this himself [1]: > Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want. In response, I've decided to not use systemd on my machines. I'm a patreon of xtraeme [2], the creator of Void Linux [3] and xbps (the package manager used in Void). Void Linux uses runit [4], which is exactly as simple and fast as I'd like it to be [5]. Working in startups, I haven't had time to contribute code to either xbps or Void, but at least I'm contributing in the way that I can. I didn't contribute to Devuan (other than seeding a few hundred TB of ISOs) for the same reason that I haven't contributed to Debian in a long time: I don't use it any more. [1]: http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html [2]: https://www.patreon.com/xtraeme https://www.patreon.com/xtraeme [3]: https://www.voidlinux.eu/ https://www.voidlinux.eu/ [4]: http://smarden.org/runit/ http://smarden.org/runit/ [5]: https://www.voidlinux.eu/usage/runit/ https://www.voidlinux.eu/usage/runit/
- jcrites 9y ago
  > I wouldn't be against systemd if it were just an init system. The problem is that it's not. That's the end of my argument. All of systemd's functionality, as far as I'm concerned, is rationally motivated by wanting to orchestrate and instrument system startup in a sensible way. What functionality do you think systemd should not have that it has today? What is a better way of achieving the result provided by that functionality? If your perspective is that you don't care about that functionality or the related user experience, and so all of its complexity is dead weight to you, OK. That makes sense. But as a software engineer and system administrator, I find the features extremely useful, and I think many other people do too. That's why systemd has been adopted by major distributions. I wrote a comment earlier [1] about systemd that reviews Russ Allbery's analysis of systemd [2], from when Debian was evaluating switching to systemd and upstart. Russ's comment reviews a number of different systemd functions, such as its integrated journal, and then explains the pros and cons of each. Russ even said: Integrated daemon status. This one caught me by surprise, since the systemd journal was functionality that I expected to dislike. But I was surprised at how well-implemented it is, and systemctl status blew me away. [lots more details in linked comment] [1] https://news.ycombinator.com/item?id=13387989 https://news.ycombinator.com/item?id=13387989 [2] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html Sure, you could argue an init system "shouldn't" have an integrated journal (for example), but then you'd lose the clear benefits that Russ outlines. You wouldn't achieve the same benefits or user experience. Similarly, systemd's configuration-driven approach to service definition makes it possible to employ a wide variety of standard configuration options across all services. From my previous comment: > I can launch my service at the appropriate time during boot with configuration as simple as: [Unit] Description=Demo service [Service] Type=forking ExecStart=/usr/sbin/my-daemon > Now let's say that I didn't author this daemon, but I'd like to run it with a private network, private temp folder, or a private /dev namespace. Or perhaps the daemon needs to run as root, but I want to drop all capabilities it doesn't need. It's as simple as adding these lines to the service's configuration: PrivateTmp=yes PrivateDevices=yes PrivateNetwork=yes CapabilityBoundingSet=CAP_NET_BIND_SERVICE > The fact that systemd supports these configuration options means that there's a simple and standard way to employ them with any service. The service itself doesn't need to support them, and needn't complicate its own daemonization logic to do so correctly. Indeed, I don't need to trust the service to daemonize or drop capabilities, since I can tell the init system do that before launching the service. > I can drop capabilities with CapabilityBoundingSet=, or limit resource usage with CPUSchedulingPriority=, IOSchedulingPriority=, etc. I could even tell systemd to open the listening socket for me so the service doesn't need CAP_NET_BIND_SERVICE! Moving these options into the init system makes a ton of sense, because it gives administrators the ability to employ these features from outside applications, not just by enabling them within applications that bother to explicitly support them via command line arguments. Systemd better encourages the principle of least privilege: if a system daemon does not need the ability to "ptrace" other processes, or bind to ports <1024, then as the administrator I can take those away with CapabilityBoundingSet= in the unit file. Chrooting the service is as easy as RootDirectory=. This is a huge step forward compared to the world where every service must be relied upon to expose these settings, and must be trusted to implement them correctly.
JdeBP 9y ago
You are implying that Steve Litt is not very active in contributing to Devuan. On what data and metrics are you basing this?
- jhkjhkjhu 9y ago
  Steve Litt uses Void Linux. He says so himself on the "Debian is not GNOME first" mailing list (aka the Devuan mailing list).

gorkonsine 9y ago

It's the latter. It didn't take anywhere near 2 full years to integrate systemd into Debian, so obviously there's a far smaller number of people in Devuan working to undo that. The whole systemd shouting match has been dominated by anti-systemd people who are the extremely vocal majority, happy to blog incessantly about how "evil" systemd is, but apparently not that happy to contribute their time to an alternative that's more to their liking. I'm not a systemd proponent (or detractor), as I'm not a professional sysadmin and just use Mint personally, but throughout that debacle it was fairly obvious which side was the more religious and less rational, and also less willing to put their money (or time) where their mouths were. Consequently, without doing any deep research on it myself, I tend to believe the systemd proponents far more.

aleksei 9y ago

Well, people are allowed to have opinions even if they dont' have the time, resources, or know-how to contribute to a solution, so yes, there may very well be "those who talk, and those who do". I don't see what your point is.

wirrbel 9y ago
people are allowed to have their opinions, and after a while, I reserve my right to not listen to certain opinions anymore if they are not backed up.
- benchaney 9y ago
  If that is the attitude you take don't be surprised when people don't listen to your opinions.
- falcolas 9y ago
  That same paintbrush also applies to those who denigrate people who have problems with systemd without putting forth the effort to see their point of view. The top comment on this post is a great example. People have been giving well reasoned arguments against systemd for years, yet the first and most upvoted salvo in this article is "I have yet to see a well reasoned argument against systemd". The hate for systemd gained steam when people stopped listening to well reasoned arguments because it also provided parallel startup and unit files, and really hit its stride when the developers ignore legitimate bug reports as "working as intended" (the latest numeric user issue is but the latest in an established history of such issues).

dijit 9y ago

Unfortunately I'm a sysadmin, I deal with systemd/sysvinit every single day often dozens of times a day, but I do not have the means/skills to help remove integrations. So, SystemD affects me daily and yet I can do nothing, I'm helpless. Which is why I'm rather vocal.

slau 9y ago

Or maybe we just gave up on Debian, and decided to spend our efforts somewhere else? I've been fairly vocal against systemd, and not because of Poettering. I'm no fan of the man, and I strongly agree with a lot of the points he made in his initial blog posts when introducing systemd. I think he's probably very talented---I'm not in a position to judge that. I wouldn't be against systemd if it were just an init system. The problem is that it's not. That's the end of my argument. If systemd were just an init system, I'd be very happy to have it on my machines. Poettering even admitted this himself [1]: > Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want. In response, I've decided to not use systemd on my machines. I'm a patreon of xtraeme [2], the creator of Void Linux [3] and xbps (the package manager used in Void). Void Linux uses runit [4], which is exactly as simple and fast as I'd like it to be [5]. Working in startups, I haven't had time to contribute code to either xbps or Void, but at least I'm contributing in the way that I can. I didn't contribute to Devuan (other than seeding a few hundred TB of ISOs) for the same reason that I haven't contributed to Debian in a long time: I don't use it any more. [1]: http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html [2]: https://www.patreon.com/xtraeme https://www.patreon.com/xtraeme [3]: https://www.voidlinux.eu/ https://www.voidlinux.eu/ [4]: http://smarden.org/runit/ http://smarden.org/runit/ [5]: https://www.voidlinux.eu/usage/runit/ https://www.voidlinux.eu/usage/runit/

jcrites 9y ago
> I wouldn't be against systemd if it were just an init system. The problem is that it's not. That's the end of my argument. All of systemd's functionality, as far as I'm concerned, is rationally motivated by wanting to orchestrate and instrument system startup in a sensible way. What functionality do you think systemd should not have that it has today? What is a better way of achieving the result provided by that functionality? If your perspective is that you don't care about that functionality or the related user experience, and so all of its complexity is dead weight to you, OK. That makes sense. But as a software engineer and system administrator, I find the features extremely useful, and I think many other people do too. That's why systemd has been adopted by major distributions. I wrote a comment earlier [1] about systemd that reviews Russ Allbery's analysis of systemd [2], from when Debian was evaluating switching to systemd and upstart. Russ's comment reviews a number of different systemd functions, such as its integrated journal, and then explains the pros and cons of each. Russ even said: Integrated daemon status. This one caught me by surprise, since the systemd journal was functionality that I expected to dislike. But I was surprised at how well-implemented it is, and systemctl status blew me away. [lots more details in linked comment] [1] https://news.ycombinator.com/item?id=13387989 https://news.ycombinator.com/item?id=13387989 [2] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html Sure, you could argue an init system "shouldn't" have an integrated journal (for example), but then you'd lose the clear benefits that Russ outlines. You wouldn't achieve the same benefits or user experience. Similarly, systemd's configuration-driven approach to service definition makes it possible to employ a wide variety of standard configuration options across all services. From my previous comment: > I can launch my service at the appropriate time during boot with configuration as simple as: [Unit] Description=Demo service [Service] Type=forking ExecStart=/usr/sbin/my-daemon > Now let's say that I didn't author this daemon, but I'd like to run it with a private network, private temp folder, or a private /dev namespace. Or perhaps the daemon needs to run as root, but I want to drop all capabilities it doesn't need. It's as simple as adding these lines to the service's configuration: PrivateTmp=yes PrivateDevices=yes PrivateNetwork=yes CapabilityBoundingSet=CAP_NET_BIND_SERVICE > The fact that systemd supports these configuration options means that there's a simple and standard way to employ them with any service. The service itself doesn't need to support them, and needn't complicate its own daemonization logic to do so correctly. Indeed, I don't need to trust the service to daemonize or drop capabilities, since I can tell the init system do that before launching the service. > I can drop capabilities with CapabilityBoundingSet=, or limit resource usage with CPUSchedulingPriority=, IOSchedulingPriority=, etc. I could even tell systemd to open the listening socket for me so the service doesn't need CAP_NET_BIND_SERVICE! Moving these options into the init system makes a ton of sense, because it gives administrators the ability to employ these features from outside applications, not just by enabling them within applications that bother to explicitly support them via command line arguments. Systemd better encourages the principle of least privilege: if a system daemon does not need the ability to "ptrace" other processes, or bind to ports <1024, then as the administrator I can take those away with CapabilityBoundingSet= in the unit file. Chrooting the service is as easy as RootDirectory=. This is a huge step forward compared to the world where every service must be relied upon to expose these settings, and must be trusted to implement them correctly.

JdeBP 9y ago

You are implying that Steve Litt is not very active in contributing to Devuan. On what data and metrics are you basing this?

jhkjhkjhu 9y ago
Steve Litt uses Void Linux. He says so himself on the "Debian is not GNOME first" mailing list (aka the Devuan mailing list).