8 ms·

Yeah, basically I've found that the people the more vocal against systemd are either not really knowing how it works behind the scenes, and just criticizing for

by Faaak 2y ago

Yeah, basically I've found that the people the more vocal against systemd are either not really knowing how it works behind the scenes, and just criticizing for the sake of it (or because other people do so), or criticizing from an ideological point of view (do one thing and do it well). They see systemd as an octopus, not following the unix ideology. Which I don't really agree tbh

hanselot 2y ago
[flagged]
- throwaway598 2y ago
  The root of the problem is sudo, and su more generally. This derives from *nix, or mainstream versions today, requiring a super user, a manifestation of the problem with monolithic kernals. A microkernal may be a stepping stone to improving this but even this is not a solution. The only solution is no kernal space, no privileged user(s), all processes negotiate independently with each other.
  - metalforever 2y ago
    No the root of the problem is the large attack surface systemd is creating by tightly coupling a ton of tools together, I agree about the microkernel idea completely though.
- dale_glass 2y ago
  systemd isn't a single piece of software. It's a collection of software with an unified theme, like KDE or Gnome. Attack surface-wise, I don't think there's much difference between "sudo" being a part of the systemd package and not. Either way there's "sudo" code to be targeted, which package it's part of is just a technicality.
  - SAI_Peregrinus 2y ago
    I like to compare Systemd to GNU. Pretty similar scale, similar "take over the world" levels of adoption in Linux (GNU's libc is in nearly everything, all the other GNU tools are ridiculously common), adds lots of attack surface to what used to be single-purpose simple tools, etc. Just about every criticism of Systemd applies just as well to GNU.
    - deleted 2y ago
      [deleted]
    - fsflover 2y ago
      https://news.ycombinator.com/item?id=40215413 https://news.ycombinator.com/item?id=40215413
StimDeck 2y ago
[flagged]
- growse 2y ago
  I think dynamic linking pre-dates systemd by quite a number of years.
  - StimDeck 2y ago
    SSH being linked to XZ doesn’t.
    - growse 2y ago
      So aim your ire at the distributions who (I agree) cocked this one up. "Take a library dependency to implement basic functionality" is not a systemd mentality, it's pernicious throughout software development - see leftPad as another example.
      - deleted 2y ago
        [deleted]
      - immibis 2y ago
        "Put everything in one big ball" is systemd mentality AND something that enabled the xz exploit to work.
        growse 2y ago
        Lots of things enabled the xz exploit to work. If the lesson you take from xz is "systemd bad" then you've really missed the wood for the trees.
        immibis 2y ago
        It's one of many things to consider. Think of it as sandboxing, or attack surface reduction. Should we expose everything to everything else, or should it be on a need-to-know basis?
CuriousCosmic 2y ago
The issue is that it's not just ideological. "Do one thing and do it well" is important because if you want to port software to another platform, it's a lot easier to port a single dependency component over to make it work than it is to port over the entire framework. This is a serious problem and it makes it way harder to make things cross platform.
- Xylakant 2y ago
  Systemd was written specifically for Linux, hard depends on a list of features provided by the Linux kernel and leverages them to do its work. Porting it to another kernel is a rewrite. Lack of portability is in this case a design tradeoff.
  - CuriousCosmic 2y ago
    Sure that is the case for systemd itself but it's not the case for most projects that happen to use things systemd provides. There is very little benefit for most userspace software to tie itself to systemd and by extension linux when otherwise it could be portable to any unix or unix like platform. Especially when an alternative, portable solution already exists and is well established.
  - fhars 2y ago
    The argument was that this design of systemd makes it hard to write applications that are portable, so that systemd is effectively a very big net negative to the open source ecosystem, because it causes massive fragmentation.
dijit 2y ago
I think this is a really old statement. I’ve used systemd since it was made default in Fedora back in 2011 (Lovelock, anyone?) - at what point am I qualified to have an opinion, after having used it personally for 13 years and professionally for 8. systemd is scary for 3 reasons. 1. it is inscrutable. Debugging it is nearly impossible, so you had better hope you don’t get a buggy release, especially with how hostile the devs can be. 2. it is large, and growing. Lots of things it claims are optional are in reality: not really. This is fine until uou get something that really doesnt work well (systemd-resolved is consistently the largest reason I have connectivity issues, wether it be because it interferes with docker inter-container networking or because it needs to time-out when trying DNSSec to continue- or if it fights with my vpn provider for power over my resolvers etc). Due to my distro being very tied to it: I gotta keep using it and working around it. 3. The interface is irreplaceable. Why are their 13 init systems? Because init is a closed scope. To be a sucessful init you need to spawn processes and do it cheaply. Supervising processes after start? Noble, and there were implementations that could do that (CDDL licensed SMF from Solaris for example). However we have already reached the state where it will be literal man-decades of work to replace systemd as we will need to make any replacement bug compatible with systemd itself. Its the ultimate show stopper. The implementation is the reference. Which is a large departure now from what came before.

by Faaak 2y ago

hanselot 2y ago

[flagged]

throwaway598 2y ago
The root of the problem is sudo, and su more generally. This derives from *nix, or mainstream versions today, requiring a super user, a manifestation of the problem with monolithic kernals. A microkernal may be a stepping stone to improving this but even this is not a solution. The only solution is no kernal space, no privileged user(s), all processes negotiate independently with each other.
- metalforever 2y ago
  No the root of the problem is the large attack surface systemd is creating by tightly coupling a ton of tools together, I agree about the microkernel idea completely though.
dale_glass 2y ago
systemd isn't a single piece of software. It's a collection of software with an unified theme, like KDE or Gnome. Attack surface-wise, I don't think there's much difference between "sudo" being a part of the systemd package and not. Either way there's "sudo" code to be targeted, which package it's part of is just a technicality.
- SAI_Peregrinus 2y ago
  I like to compare Systemd to GNU. Pretty similar scale, similar "take over the world" levels of adoption in Linux (GNU's libc is in nearly everything, all the other GNU tools are ridiculously common), adds lots of attack surface to what used to be single-purpose simple tools, etc. Just about every criticism of Systemd applies just as well to GNU.
  - deleted 2y ago
    [deleted]
  - fsflover 2y ago
    https://news.ycombinator.com/item?id=40215413 https://news.ycombinator.com/item?id=40215413

StimDeck 2y ago

[flagged]

growse 2y ago
I think dynamic linking pre-dates systemd by quite a number of years.
- StimDeck 2y ago
  SSH being linked to XZ doesn’t.
  - growse 2y ago
    So aim your ire at the distributions who (I agree) cocked this one up. "Take a library dependency to implement basic functionality" is not a systemd mentality, it's pernicious throughout software development - see leftPad as another example.
    - deleted 2y ago
      [deleted]
    - immibis 2y ago
      "Put everything in one big ball" is systemd mentality AND something that enabled the xz exploit to work.
      - growse 2y ago
        Lots of things enabled the xz exploit to work. If the lesson you take from xz is "systemd bad" then you've really missed the wood for the trees.
        immibis 2y ago
        It's one of many things to consider. Think of it as sandboxing, or attack surface reduction. Should we expose everything to everything else, or should it be on a need-to-know basis?

CuriousCosmic 2y ago

The issue is that it's not just ideological. "Do one thing and do it well" is important because if you want to port software to another platform, it's a lot easier to port a single dependency component over to make it work than it is to port over the entire framework. This is a serious problem and it makes it way harder to make things cross platform.

Xylakant 2y ago
Systemd was written specifically for Linux, hard depends on a list of features provided by the Linux kernel and leverages them to do its work. Porting it to another kernel is a rewrite. Lack of portability is in this case a design tradeoff.
- CuriousCosmic 2y ago
  Sure that is the case for systemd itself but it's not the case for most projects that happen to use things systemd provides. There is very little benefit for most userspace software to tie itself to systemd and by extension linux when otherwise it could be portable to any unix or unix like platform. Especially when an alternative, portable solution already exists and is well established.
- fhars 2y ago
  The argument was that this design of systemd makes it hard to write applications that are portable, so that systemd is effectively a very big net negative to the open source ecosystem, because it causes massive fragmentation.

dijit 2y ago

I think this is a really old statement. I’ve used systemd since it was made default in Fedora back in 2011 (Lovelock, anyone?) - at what point am I qualified to have an opinion, after having used it personally for 13 years and professionally for 8. systemd is scary for 3 reasons. 1. it is inscrutable. Debugging it is nearly impossible, so you had better hope you don’t get a buggy release, especially with how hostile the devs can be. 2. it is large, and growing. Lots of things it claims are optional are in reality: not really. This is fine until uou get something that really doesnt work well (systemd-resolved is consistently the largest reason I have connectivity issues, wether it be because it interferes with docker inter-container networking or because it needs to time-out when trying DNSSec to continue- or if it fights with my vpn provider for power over my resolvers etc). Due to my distro being very tied to it: I gotta keep using it and working around it. 3. The interface is irreplaceable. Why are their 13 init systems? Because init is a closed scope. To be a sucessful init you need to spawn processes and do it cheaply. Supervising processes after start? Noble, and there were implementations that could do that (CDDL licensed SMF from Solaris for example). However we have already reached the state where it will be literal man-decades of work to replace systemd as we will need to make any replacement bug compatible with systemd itself. Its the ultimate show stopper. The implementation is the reference. Which is a large departure now from what came before.