13 ms·

Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It

Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It is easier to configure and is convenient to have one holistic system in a lot of ways, but... They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. I don't think the code is high-quality, but even more than that I have a problem with the people being controlling, dismissive, and deceptive.

boxfire 7y ago
If systemd were a gstreamer plugin it would be in gstreamer-plugins-bad
Piezoid 7y ago
> They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. We should standardize on the interfaces, avoiding hard dependencies. There is dbus for that.
- Crinus 7y ago
  dbus is also a dependency though. If you are on the bus (heh) that says systemd is a hard dependency that should be avoided then dbus is also the same thing.
  - eropple 7y ago
    I agree with your logical consistency, but I'm curious: is D-Bus sufficiently specified that one could write an alternative to it? That is, is it a hard dependency or is it itself an interface? I'm not nearly sufficiently experienced with desktop Linux application development to know. ;)
    - vetinari 7y ago
      Yes, DBUS is specified [1]. There are multiple implementations shipping (dbus reference implementation and dbus-broker), as well as several different client libraries. As dbus user, or application, you just need some client library. As an operating system, you also need a daemon running, which is routing the messages among all the clients. [1] - https://dbus.freedesktop.org/doc/dbus-specification.html https://dbus.freedesktop.org/doc/dbus-specification.html
      - eropple 7y ago
        So it is--and, in reading, it looks like systemd actually ships their own sd-bus client. Huh. TIL. Thanks.
        m4rtink 7y ago
        IIRC at least part of the reason for sd-bus is the need for using D-Bus between parts of systemd during early boot when "normal" D-Bus is not yet up and running.
    - asveikau 7y ago
      I'm not a huge fan, but dbus at least runs on FreeBSD and others.
      - AsyncAwait 7y ago
        FreeBSD developers are actually looking at something like systemd themselves. The fact that systemd itself doesn't run on it is just the consequence of POSIX being inadequate for its implementation, since it relies on a bunch of Linux specific features, like cgroups etc. I am personally in the camp that doesn't mind that, Linux users should get the best possible software given their system capabilities, not the lowest common denominator one just for the sake of it. (Free)BSD developers are also not looking to make sure their stuff works with Linux, which I think it's a valid approach. GNOME itself does exist on the BSDs, by the way knocking down the argument of systemd being a hard dependency of GNOME along the way.
haolez 7y ago
But I think that the author of systemd himself wrote a patch for Gnome to keep it working without systemd. Am I correct?
- rocqua 7y ago
  That would invalidate a lot of the criticism I saw.
- _emacsomancer_ 7y ago
  My understanding is that it the patching of Gnome to work without systemd was done by others (Guix, Void developers), not Poettering: https://www.reddit.com/r/linux/comments/66ass2/update_void_linux_offers_a_fully_functional/dgjep53/ https://www.reddit.com/r/linux/comments/66ass2/update_void_l...
ajross 7y ago
> They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. This seems like it needs some citation. There certainly have been bugs. I think it's legitimate to talk (with specifics!) about cultural issues with systemd's development and its impact on security. But I don't see that this statement is particularly well supported. In particular I genuinely don't know what you're referring to with respect to ignored/suppressed bugs and CVEs. I mean, systemd is a lot of code and makes up a big chunk of the system plumbing these days. Obviously it's going to make up a big chunk of the bug budget. People don't get upset about flaws in someone's random cgroup launcher or encrypted block device manager or daemon wrapper not because those projects don't have bugs, but because basically no one uses them. Because basically everyone is using systemd!
- viraptor 7y ago
  For the CVEs, it's the comments like this: https://github.com/systemd/systemd/pull/5998#issuecomment-303651608 https://github.com/systemd/systemd/pull/5998#issuecomment-30... (Just in case, this is an security issue because it enables constant dosing, as well as clears the resolver cache making spoofing easier)
  - ajross 7y ago
    I think that's valid enough. Not sure it rises to the level of "OMG they ignore bugs" implied by the original comment though. I mean... they took the patch and fixed the bug, right? Poettering was just being a jerk about whether it deserved a CVE. (Also... gotta be honest that's sort of a vanity CVE. Note the complete lack of details in the report itself, it never saw an eyeball after it was filed. It's valid enough, but frankly I'm with Poettering on the specifics here: if we filed a CVE for every theoretically-exploitable-but-unexploited-until-fix-released crash bug the system would be beyond useless.)
    - inferiorhuman 7y ago
      I think that's valid enough. Not sure it rises to the level of "OMG they ignore bugs" implied by the original comment though. I mean... they took the patch and fixed the bug, right? Poettering was just being a jerk about whether it deserved a CVE. Poettering is dismissive of nearly every bug. Remember when systemd would default to starting units as root when it couldn't parse the username? We're not talking about some minor piece of software like a sound multiplexing daemon, we're talking about the core userland piece of every Linux install. Bug reports on something that central should be taken seriously and with a minimum of snark. I'm with Poettering on the specifics here: if we filed a CVE for every theoretically-exploitable-but-unexploited-until-fix-released crash bug the system would be beyond useless. All the more reason to reduce the attack vectors and ensure that your code is well thought out, and coded defensively. That you have too many security issues to generate CVEs for each and every one is a problem in and of itself. Ten years ago how many people thought that all of these speculative execution side channel attacks were possible or practical?
jdefr89 7y ago
This is always the case with any new software. Things may get a bit worse before they get better. Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key. It is in the same spirit as launchd on macOS. It works well overall and end up being more portable and consistent in the long run. Hatred for it seems to come mostly out of dogma, something to be avoided in this age.
- falcolas 7y ago
  > addresses the complexities of a modern system in the simplest fashion but no simpler I have a serious contention with the statement that systemd is the simplest possible solution for this problem. Especially since it involves not only service management, but user logins, a data bus, logging management, file system mounting, initd, and a host of other things. Are all of those pieces necessary? Arguably yes. But not all in one system(d).
  - Phrodo_00 7y ago
    Thing is, though, most of those things are different systems. systemd-logind systemd, systemd-udevd, and journald (and others) are different systems in the same project. They're a bit tied together (through dbus and I'm not sure what else), but that doesn't mean they're the same system.
    - _emacsomancer_ 7y ago
      The problem is that they're not really swappable. So, effectively it is all one system(d).
- erik_seaberg 7y ago
  launchd doesn't break nohup. It doesn't have any opinions about processes started from shells. systemd does, which is completely inappropriate scope creep.
  - Spivak 7y ago
grumdan 7y ago
> They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. Additionally, this is not likely to stop, since they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++), thus enabling a whole class of systemic security issues that will keep popping up in the future over and over again as well. This is one of the design decisions behind systemd that irks me the most.
- pmezard 7y ago
  Memory safety is not the alpha and omega of programming languages. People do not write million lines of code applications in bash, for a reason, trade-offs are to be made. That said I agree they should have picked Go instead /s.
  - sanderjd 7y ago
    I'm not such a lover of Go, but: non-sarcastically, Go may well have been a good choice.
    - amalcon 7y ago
      > Lennart Poettering and Kay Sievers started the project to develop systemd in 2010. https://en.wikipedia.org/wiki/Systemd#History https://en.wikipedia.org/wiki/Systemd#History > Go was publicly announced in November 2009,[29] and version 1.0 was released in March 2012. https://en.wikipedia.org/wiki/Go_(programming_language)#History https://en.wikipedia.org/wiki/Go_(programming_language)#Hist... The brand-new language that Google just announced last year was probably not considered a serious option here.
      - loeg 7y ago
        It's 2019 and Go still has a much weaker toolchain and infrastructure story than C (which has a 30 year head start).
      - 7y ago
natermer 7y ago
> Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. The 'Imperialistic Culture' you speak of is one of those made-up things that systemd haters keep repeating, but has no basis in reality. > They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. Again, another fairy tail. > They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. A) This is par for the course in Linux software. See also: Linux kernel. One side you have is a bunch of security bros running around trying to fluff up their resumes and trying to turn themselves into heros. And on the other side you have devs working hard on various features and bugs and being resentful that most of their work goes unnoticed while stuff they already fixed is thrown back in their face. B) Many of the bugs that make it onto Reddit/Hacker news are going to be ones that are largely changes in configuration defaults or behaviors that break things and are meant to be configured by the operating system designers that use it, not end users. C) This level of scrutiny never existed before for low-level Linux features. The multitude of redundent and terrible shell scripts that made up the majority of functionality that systemd project seeks to replace was always a swampy mess of broken functionality and bad code. Having each and every major linux distribution rewriting 90% of it from scratch in a completely un-portable and estoric way didn't help matters. Linux advocates actually went so far as to praising the fact that even though half of the scripts in their OS were completely broken and the OS still worked fine was a testament to it's robustness. The fact that now, finally, after decades of this crap people can now track bugs related to low-level Linux userland 'plumbing' is actually a good thing. > It is easier to configure and is convenient to have one holistic system in a lot of ways, but... On the sysvinit side you had thousands and thousands of lines bunch of procedural code of dubious quality that is endlessly rewritten by hundreds of different teams with vastly differing levels of competency and success using a general purpose language for configuration. It was so unportable that you couldn't even use anything but the most basic and trivial (also broken) init scripts from one distribution to another without herculean levels of effort. On the other side you have a even driven OS configuration and management engine that allows people to describe the state they want the OS to be in via a domain specific configuration language. It has managed to standardize the low level plumbing for Linux operating systems and allows distributions to share improvements with one another in a way that was previously impossible. If people want a alternative to gain in popularity they need learn what systemd does and understand why Linux distribution makers switched to it. Then produce something of their own that takes those positive features and improves on it further. All the hand waiving about 'Imperialism via releasing open source software to the public' is infantile. The upside of all of this is that it's going to be a hell of a lot easier to make systemd unit files portable then it is to make Linux init shell scripts. There isn't any reason why a more capable init system wouldn't be able to parse existing unit files and know then how to start and manage the services and applications that use them... So the effort to move away from systemd should be significantly less then the effort to move to systemd.
lamontcg 7y ago
> I have a problem with the people being controlling, dismissive, and deceptive. They're probably just busy. And calling the "imperialistic" is annoying them, so you've destroyed your political capital with them.
commandersaki 7y ago
> Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. The most recent gripe I have is that systemd people can't even do randomness properly and even use non-cryptographic randomness for DNS transaction IDs (ok probably benign). But just boggles the mind. https://twitter.com/FiloSottile/status/1125840911299223554 https://twitter.com/FiloSottile/status/1125840911299223554

boxfire 7y ago

If systemd were a gstreamer plugin it would be in gstreamer-plugins-bad

Piezoid 7y ago

> They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. We should standardize on the interfaces, avoiding hard dependencies. There is dbus for that.

Crinus 7y ago
dbus is also a dependency though. If you are on the bus (heh) that says systemd is a hard dependency that should be avoided then dbus is also the same thing.
- eropple 7y ago
  I agree with your logical consistency, but I'm curious: is D-Bus sufficiently specified that one could write an alternative to it? That is, is it a hard dependency or is it itself an interface? I'm not nearly sufficiently experienced with desktop Linux application development to know. ;)
  - vetinari 7y ago
    Yes, DBUS is specified [1]. There are multiple implementations shipping (dbus reference implementation and dbus-broker), as well as several different client libraries. As dbus user, or application, you just need some client library. As an operating system, you also need a daemon running, which is routing the messages among all the clients. [1] - https://dbus.freedesktop.org/doc/dbus-specification.html https://dbus.freedesktop.org/doc/dbus-specification.html
    - eropple 7y ago
      So it is--and, in reading, it looks like systemd actually ships their own sd-bus client. Huh. TIL. Thanks.
      - m4rtink 7y ago
        IIRC at least part of the reason for sd-bus is the need for using D-Bus between parts of systemd during early boot when "normal" D-Bus is not yet up and running.
  - asveikau 7y ago
    I'm not a huge fan, but dbus at least runs on FreeBSD and others.
    - AsyncAwait 7y ago
      FreeBSD developers are actually looking at something like systemd themselves. The fact that systemd itself doesn't run on it is just the consequence of POSIX being inadequate for its implementation, since it relies on a bunch of Linux specific features, like cgroups etc. I am personally in the camp that doesn't mind that, Linux users should get the best possible software given their system capabilities, not the lowest common denominator one just for the sake of it. (Free)BSD developers are also not looking to make sure their stuff works with Linux, which I think it's a valid approach. GNOME itself does exist on the BSDs, by the way knocking down the argument of systemd being a hard dependency of GNOME along the way.

haolez 7y ago

But I think that the author of systemd himself wrote a patch for Gnome to keep it working without systemd. Am I correct?

rocqua 7y ago
That would invalidate a lot of the criticism I saw.
_emacsomancer_ 7y ago
My understanding is that it the patching of Gnome to work without systemd was done by others (Guix, Void developers), not Poettering: https://www.reddit.com/r/linux/comments/66ass2/update_void_linux_offers_a_fully_functional/dgjep53/ https://www.reddit.com/r/linux/comments/66ass2/update_void_l...

ajross 7y ago

> They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. This seems like it needs some citation. There certainly have been bugs. I think it's legitimate to talk (with specifics!) about cultural issues with systemd's development and its impact on security. But I don't see that this statement is particularly well supported. In particular I genuinely don't know what you're referring to with respect to ignored/suppressed bugs and CVEs. I mean, systemd is a lot of code and makes up a big chunk of the system plumbing these days. Obviously it's going to make up a big chunk of the bug budget. People don't get upset about flaws in someone's random cgroup launcher or encrypted block device manager or daemon wrapper not because those projects don't have bugs, but because basically no one uses them. Because basically everyone is using systemd!

viraptor 7y ago
For the CVEs, it's the comments like this: https://github.com/systemd/systemd/pull/5998#issuecomment-303651608 https://github.com/systemd/systemd/pull/5998#issuecomment-30... (Just in case, this is an security issue because it enables constant dosing, as well as clears the resolver cache making spoofing easier)
- ajross 7y ago
  I think that's valid enough. Not sure it rises to the level of "OMG they ignore bugs" implied by the original comment though. I mean... they took the patch and fixed the bug, right? Poettering was just being a jerk about whether it deserved a CVE. (Also... gotta be honest that's sort of a vanity CVE. Note the complete lack of details in the report itself, it never saw an eyeball after it was filed. It's valid enough, but frankly I'm with Poettering on the specifics here: if we filed a CVE for every theoretically-exploitable-but-unexploited-until-fix-released crash bug the system would be beyond useless.)
  - inferiorhuman 7y ago
    I think that's valid enough. Not sure it rises to the level of "OMG they ignore bugs" implied by the original comment though. I mean... they took the patch and fixed the bug, right? Poettering was just being a jerk about whether it deserved a CVE. Poettering is dismissive of nearly every bug. Remember when systemd would default to starting units as root when it couldn't parse the username? We're not talking about some minor piece of software like a sound multiplexing daemon, we're talking about the core userland piece of every Linux install. Bug reports on something that central should be taken seriously and with a minimum of snark. I'm with Poettering on the specifics here: if we filed a CVE for every theoretically-exploitable-but-unexploited-until-fix-released crash bug the system would be beyond useless. All the more reason to reduce the attack vectors and ensure that your code is well thought out, and coded defensively. That you have too many security issues to generate CVEs for each and every one is a problem in and of itself. Ten years ago how many people thought that all of these speculative execution side channel attacks were possible or practical?

jdefr89 7y ago

This is always the case with any new software. Things may get a bit worse before they get better. Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key. It is in the same spirit as launchd on macOS. It works well overall and end up being more portable and consistent in the long run. Hatred for it seems to come mostly out of dogma, something to be avoided in this age.

falcolas 7y ago
> addresses the complexities of a modern system in the simplest fashion but no simpler I have a serious contention with the statement that systemd is the simplest possible solution for this problem. Especially since it involves not only service management, but user logins, a data bus, logging management, file system mounting, initd, and a host of other things. Are all of those pieces necessary? Arguably yes. But not all in one system(d).
- Phrodo_00 7y ago
  Thing is, though, most of those things are different systems. systemd-logind systemd, systemd-udevd, and journald (and others) are different systems in the same project. They're a bit tied together (through dbus and I'm not sure what else), but that doesn't mean they're the same system.
  - _emacsomancer_ 7y ago
    The problem is that they're not really swappable. So, effectively it is all one system(d).
erik_seaberg 7y ago
launchd doesn't break nohup. It doesn't have any opinions about processes started from shells. systemd does, which is completely inappropriate scope creep.
- Spivak 7y ago

grumdan 7y ago

> They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. Additionally, this is not likely to stop, since they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++), thus enabling a whole class of systemic security issues that will keep popping up in the future over and over again as well. This is one of the design decisions behind systemd that irks me the most.

pmezard 7y ago
Memory safety is not the alpha and omega of programming languages. People do not write million lines of code applications in bash, for a reason, trade-offs are to be made. That said I agree they should have picked Go instead /s.
- sanderjd 7y ago
  I'm not such a lover of Go, but: non-sarcastically, Go may well have been a good choice.
  - amalcon 7y ago
    > Lennart Poettering and Kay Sievers started the project to develop systemd in 2010. https://en.wikipedia.org/wiki/Systemd#History https://en.wikipedia.org/wiki/Systemd#History > Go was publicly announced in November 2009,[29] and version 1.0 was released in March 2012. https://en.wikipedia.org/wiki/Go_(programming_language)#History https://en.wikipedia.org/wiki/Go_(programming_language)#Hist... The brand-new language that Google just announced last year was probably not considered a serious option here.
    - loeg 7y ago
      It's 2019 and Go still has a much weaker toolchain and infrastructure story than C (which has a 30 year head start).
    - 7y ago

natermer 7y ago

> Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. The 'Imperialistic Culture' you speak of is one of those made-up things that systemd haters keep repeating, but has no basis in reality. > They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. Again, another fairy tail. > They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. A) This is par for the course in Linux software. See also: Linux kernel. One side you have is a bunch of security bros running around trying to fluff up their resumes and trying to turn themselves into heros. And on the other side you have devs working hard on various features and bugs and being resentful that most of their work goes unnoticed while stuff they already fixed is thrown back in their face. B) Many of the bugs that make it onto Reddit/Hacker news are going to be ones that are largely changes in configuration defaults or behaviors that break things and are meant to be configured by the operating system designers that use it, not end users. C) This level of scrutiny never existed before for low-level Linux features. The multitude of redundent and terrible shell scripts that made up the majority of functionality that systemd project seeks to replace was always a swampy mess of broken functionality and bad code. Having each and every major linux distribution rewriting 90% of it from scratch in a completely un-portable and estoric way didn't help matters. Linux advocates actually went so far as to praising the fact that even though half of the scripts in their OS were completely broken and the OS still worked fine was a testament to it's robustness. The fact that now, finally, after decades of this crap people can now track bugs related to low-level Linux userland 'plumbing' is actually a good thing. > It is easier to configure and is convenient to have one holistic system in a lot of ways, but... On the sysvinit side you had thousands and thousands of lines bunch of procedural code of dubious quality that is endlessly rewritten by hundreds of different teams with vastly differing levels of competency and success using a general purpose language for configuration. It was so unportable that you couldn't even use anything but the most basic and trivial (also broken) init scripts from one distribution to another without herculean levels of effort. On the other side you have a even driven OS configuration and management engine that allows people to describe the state they want the OS to be in via a domain specific configuration language. It has managed to standardize the low level plumbing for Linux operating systems and allows distributions to share improvements with one another in a way that was previously impossible. If people want a alternative to gain in popularity they need learn what systemd does and understand why Linux distribution makers switched to it. Then produce something of their own that takes those positive features and improves on it further. All the hand waiving about 'Imperialism via releasing open source software to the public' is infantile. The upside of all of this is that it's going to be a hell of a lot easier to make systemd unit files portable then it is to make Linux init shell scripts. There isn't any reason why a more capable init system wouldn't be able to parse existing unit files and know then how to start and manage the services and applications that use them... So the effort to move away from systemd should be significantly less then the effort to move to systemd.

lamontcg 7y ago

> I have a problem with the people being controlling, dismissive, and deceptive. They're probably just busy. And calling the "imperialistic" is annoying them, so you've destroyed your political capital with them.

commandersaki 7y ago

> Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. The most recent gripe I have is that systemd people can't even do randomness properly and even use non-cryptographic randomness for DNS transaction IDs (ok probably benign). But just boggles the mind. https://twitter.com/FiloSottile/status/1125840911299223554 https://twitter.com/FiloSottile/status/1125840911299223554