6 ms·

I read everything I could find on systemd to form my own opinion. I used FreeBSD for a decade and have many years of Ubuntu/upstart experience after that. Base

I read everything I could find on systemd to form my own opinion. I used FreeBSD for a decade and have many years of Ubuntu/upstart experience after that. Based on my experience and all the anti-systemd posts online, I expected to dislike it. But on it's merits I really like the consistency it brings to the "system layer" of the OS. I find it's shame when developers skip over systemd for consideration, adding extra layers of complexity when systemd alone would have been sufficient: For example, using Docker when the basic isolation features of systemd would do, or using "forever.js" to manage Node.js processes, when systemd could could be saving 15% memory overhead per process, using software already installed in the base system. On the other hand, I do support diversity of software and am glad to see some other options still being promoted and used. The dangers and weaknesses of monoculture in the physical world apply to software systems as well.

boramalper 7y ago
> For example, using Docker when the basic isolation features of systemd would do This is an interesting claim, mind throwing some pointers?
- progval 7y ago
  https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Sandboxing https://www.freedesktop.org/software/systemd/man/systemd.exe... and some other directives documented on the same page.
  - Operyl 7y ago
    I had completely forgotten about these directives! It's things like this that make me glad systemd is a choice, honestly.
    - dijit 7y ago
      SystemD did not invent cgroups. Not only is it possible to use cgroups without systemd it is often easier for small cases and binaries can call cgroups themselves for any child processes they create. The timing of these systems releasing does not equate to causation here. Google themselves (creators of cgroups) do not even use systemd on their own hypervisors which leverage cgroups heavily.
      - Operyl 7y ago
        Nobody said they did. You’re putting words in my mouth. The ease of use with 2-3 directives in a way that just works is what they brought to the table.
        dijit 7y ago
        boramalper 8 hours ago | parent | flag | favorite | on: Linux distros without systemd > For example, using Docker when the basic isolation features of systemd would do
fabiomaia 7y ago
Interesting. So what use cases is Docker good for? Why is it so popular if systemd suffices?
- tarruda 7y ago
  I'm not sure systemd had every container feature available when docker was released. If I'm not mistaken, systemd-nspawn (systemd alternative to docker) is much more recent.
- eropple 7y ago
  Docker provides some more approachable tooling on top and (IMO, at least) its networking is more straightforward for "developer-y" use cases. I quite like systemd-nspawn too, though.
- addicted 7y ago
  Cross platform stuff? Docker allows you to do many things on Windows and Linux. I’m not arguing that this is worth the overhead, or even a useful feature in practice (most companies and products tend to pick one environment and stick to it), but one that comes to mind that systemd would likely never have.
  - tracker1 7y ago
    The cross-platform stuff is interesting... however, in practice almost everything outside Linux containers is only weakly supported. You have to jump through some hoops to use alpha/nightly builds of Docker hand installed in Windows 2019 or later Win10 builds in order to support both Linux and Windows containers on a single system. I think the work with WSL2 may make things better better as a result. The naming in Windows and Mac, along with the limitations of the Desktop implementation are also frustrating. Don't get me wrong, I really like Docker as an orchestration base, I just don't think the cross-platform support is a value add in practice and in fact detracts as a whole imho.
- ajross 7y ago
  Docker is about deployment. The isolation model is built on the same tooling that systemd uses, but the usage model is all about how to come up with an easily isolated runtime environment that can be published and extended in a big development community. Basically systemd has nothing like a dockerfile, that's not what it's for. I think there's a good argument though that Docker should be retargetting its encapsulation work to a lower level OS primitive where possible (which would be systemd on linux) instead of rolling its own.
jimktrains2 7y ago
One of my biggest issues with systemd is that I don't like the idea of not being able to replace pieces of it. If I don't like their logging, dns, or ntp daemons, I can't easily replace them without feeling like a second-class citizen and/or having the overhead you've mentioned. From my understanding, alternatives _could_ be written, but haven't yet and that means we currently having to ignore more battle-hardened software in favour of whatever is in systemd by default.
- PlutoIsAPlanet 7y ago
  The ntp and dns are easy to replace, they're not part of the actual systemd binary. Fedora from what I remember, doesn't even enable systemds ntp service on Workstation. Logging is a bit different, but you can tell journald to use syslog.
  - jimktrains2 7y ago
    I don't mean in terms of the binary, but in terms of the whole system.
    - vetinari 7y ago
      You would have to write quite a bit of code... The success of systemd is in that it solves problems for distros that none other was solving (or even looking other way). If you want to successfully replace it, you have to solve the same problems, and do it better, so it would be worth replacing systemd. And because none other was doing it, you would have to write solution that does that. Slapping some bash scripts together won't do it.
      - michaelmrose 7y ago
        It's a very strange argument that I have seen previously that someone could write an alternative to systemd but haven't ergo systemd must be the best alternative. This is wholly and totally imaginary. Every part of system has an alternative because it is all solving existing problems that people have been solving for decades with a variety of tools. The only actual challenge is replacing just part of systemd while retailing compatibility with the rest of it.
JohnFen 7y ago
> On the other hand, I do support diversity of software and am glad to see some other options still being promoted and used. Then you should not be wanting to see applications including a hard dependency to systemD.
- eropple 7y ago
  Why is it another open source developer's obligation to satisfy your design desires? Are you paying them? If not, put your time where you aren't putting your money, become the purveyor of diversity, and submit a patch. Fork, if necessary and it matters to you that much--it's your right to do so.
  - JohnFen 7y ago
    > Why is it another open source developer's obligation to satisfy your design desires? I never said it is. What I said is that if someone values diversity of software, then they should object to applications including a hard dependency on systemD. That's just logical, as including hard dependencies on systemD reduces software diversity by requiring that the system it runs on uses systemD rather than allowing them the choice.
  - silversconfused 7y ago
    We did fork debian, and here are a TON of people who say they do not care, but still insist that we are doing it wrong for some reason.
  - camgunz 7y ago
    Full disclosure: I'm a systemd skeptic. The problem is basically that Linux used to be about choice (choose your distro! choose your DE! choose your shell! choose your browser!) but now that it's become big business, large corporations like Red Hat (developer of systemd) have transformed the evolution of Linux from a bottom-up consensus system to a top-down "we develop all the stuff you use and now it all uses our stuff so now you do too" approach. It's _very_ hard for me to build a system without systemd; I can use a niche Linux distro, I can use a BSD, or I can hack another init system (etc.) in myself. None of those are satisfying, I think for obvious reasons. systemd is not well written, and it is not well designed. Its style and architecture are inconsistent. Parsing is mixed with validation and business logic. The types of CVEs its generated show that there was no coherent thought put into input validation, fuzzing, taint analysis, and so on. The effects of those flaws (your whole system crashes, etc.) show that failure strategies were never considered. And if all that sounds like overkill to you, maybe it is! But I can tell you that these techniques and design strategies are employed by experts to build software that must be robust, like software that controls medical equipment or transportation control systems. We know how to build software that works and that mitigates failures. Looking at systemd's code, it's clear they used none of that knowledge. And that, combined with its sprawling control over my system, makes me not want it on my machines.

boramalper 7y ago

> For example, using Docker when the basic isolation features of systemd would do This is an interesting claim, mind throwing some pointers?

progval 7y ago
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Sandboxing https://www.freedesktop.org/software/systemd/man/systemd.exe... and some other directives documented on the same page.
- Operyl 7y ago
  I had completely forgotten about these directives! It's things like this that make me glad systemd is a choice, honestly.
  - dijit 7y ago
    SystemD did not invent cgroups. Not only is it possible to use cgroups without systemd it is often easier for small cases and binaries can call cgroups themselves for any child processes they create. The timing of these systems releasing does not equate to causation here. Google themselves (creators of cgroups) do not even use systemd on their own hypervisors which leverage cgroups heavily.
    - Operyl 7y ago
      Nobody said they did. You’re putting words in my mouth. The ease of use with 2-3 directives in a way that just works is what they brought to the table.
      - dijit 7y ago
        boramalper 8 hours ago | parent | flag | favorite | on: Linux distros without systemd > For example, using Docker when the basic isolation features of systemd would do

fabiomaia 7y ago

Interesting. So what use cases is Docker good for? Why is it so popular if systemd suffices?

tarruda 7y ago
I'm not sure systemd had every container feature available when docker was released. If I'm not mistaken, systemd-nspawn (systemd alternative to docker) is much more recent.
eropple 7y ago
Docker provides some more approachable tooling on top and (IMO, at least) its networking is more straightforward for "developer-y" use cases. I quite like systemd-nspawn too, though.
addicted 7y ago
Cross platform stuff? Docker allows you to do many things on Windows and Linux. I’m not arguing that this is worth the overhead, or even a useful feature in practice (most companies and products tend to pick one environment and stick to it), but one that comes to mind that systemd would likely never have.
- tracker1 7y ago
  The cross-platform stuff is interesting... however, in practice almost everything outside Linux containers is only weakly supported. You have to jump through some hoops to use alpha/nightly builds of Docker hand installed in Windows 2019 or later Win10 builds in order to support both Linux and Windows containers on a single system. I think the work with WSL2 may make things better better as a result. The naming in Windows and Mac, along with the limitations of the Desktop implementation are also frustrating. Don't get me wrong, I really like Docker as an orchestration base, I just don't think the cross-platform support is a value add in practice and in fact detracts as a whole imho.
ajross 7y ago
Docker is about deployment. The isolation model is built on the same tooling that systemd uses, but the usage model is all about how to come up with an easily isolated runtime environment that can be published and extended in a big development community. Basically systemd has nothing like a dockerfile, that's not what it's for. I think there's a good argument though that Docker should be retargetting its encapsulation work to a lower level OS primitive where possible (which would be systemd on linux) instead of rolling its own.

jimktrains2 7y ago

One of my biggest issues with systemd is that I don't like the idea of not being able to replace pieces of it. If I don't like their logging, dns, or ntp daemons, I can't easily replace them without feeling like a second-class citizen and/or having the overhead you've mentioned. From my understanding, alternatives _could_ be written, but haven't yet and that means we currently having to ignore more battle-hardened software in favour of whatever is in systemd by default.

PlutoIsAPlanet 7y ago
The ntp and dns are easy to replace, they're not part of the actual systemd binary. Fedora from what I remember, doesn't even enable systemds ntp service on Workstation. Logging is a bit different, but you can tell journald to use syslog.
- jimktrains2 7y ago
  I don't mean in terms of the binary, but in terms of the whole system.
  - vetinari 7y ago
    You would have to write quite a bit of code... The success of systemd is in that it solves problems for distros that none other was solving (or even looking other way). If you want to successfully replace it, you have to solve the same problems, and do it better, so it would be worth replacing systemd. And because none other was doing it, you would have to write solution that does that. Slapping some bash scripts together won't do it.
    - michaelmrose 7y ago
      It's a very strange argument that I have seen previously that someone could write an alternative to systemd but haven't ergo systemd must be the best alternative. This is wholly and totally imaginary. Every part of system has an alternative because it is all solving existing problems that people have been solving for decades with a variety of tools. The only actual challenge is replacing just part of systemd while retailing compatibility with the rest of it.

JohnFen 7y ago

> On the other hand, I do support diversity of software and am glad to see some other options still being promoted and used. Then you should not be wanting to see applications including a hard dependency to systemD.

eropple 7y ago
Why is it another open source developer's obligation to satisfy your design desires? Are you paying them? If not, put your time where you aren't putting your money, become the purveyor of diversity, and submit a patch. Fork, if necessary and it matters to you that much--it's your right to do so.
- JohnFen 7y ago
  > Why is it another open source developer's obligation to satisfy your design desires? I never said it is. What I said is that if someone values diversity of software, then they should object to applications including a hard dependency on systemD. That's just logical, as including hard dependencies on systemD reduces software diversity by requiring that the system it runs on uses systemD rather than allowing them the choice.
- silversconfused 7y ago
  We did fork debian, and here are a TON of people who say they do not care, but still insist that we are doing it wrong for some reason.
- camgunz 7y ago
  Full disclosure: I'm a systemd skeptic. The problem is basically that Linux used to be about choice (choose your distro! choose your DE! choose your shell! choose your browser!) but now that it's become big business, large corporations like Red Hat (developer of systemd) have transformed the evolution of Linux from a bottom-up consensus system to a top-down "we develop all the stuff you use and now it all uses our stuff so now you do too" approach. It's _very_ hard for me to build a system without systemd; I can use a niche Linux distro, I can use a BSD, or I can hack another init system (etc.) in myself. None of those are satisfying, I think for obvious reasons. systemd is not well written, and it is not well designed. Its style and architecture are inconsistent. Parsing is mixed with validation and business logic. The types of CVEs its generated show that there was no coherent thought put into input validation, fuzzing, taint analysis, and so on. The effects of those flaws (your whole system crashes, etc.) show that failure strategies were never considered. And if all that sounds like overkill to you, maybe it is! But I can tell you that these techniques and design strategies are employed by experts to build software that must be robust, like software that controls medical equipment or transportation control systems. We know how to build software that works and that mitigates failures. Looking at systemd's code, it's clear they used none of that knowledge. And that, combined with its sprawling control over my system, makes me not want it on my machines.