6 ms·

I think he is being downvoted because he is factual wrong. Could someone please elaborate with details?

by darfs 10y ago

DyslexicAtheist 10y ago
one of the arguments against systemd is that it consolidates several scriptable and bug-prone isolated scripts into a binary. This is introducing it's own risks that require upstream interaction to fix a small issue normally a sysadmin without knowledge of C can hot-fix locally. Considering the non existence of a systemd developer community, it's pretty risky. There are similar arguments (pro/against) docker where 2 camps, one saying it's poison & bloat the other the best thing since tabbed browsing. People get so riled up because they're unwilling to acknowledge that they're just tools that make lot sense for solving specific issues. Everyone keeps looking for silver bullets. Problems start when one camp tries to become the de-facto standard (not just the tool but also the processes that come with it). Also people are way to scared of code-forks IMHO. The "fail quick, fail fast" mentality should apply here too. Some healthy competition and a willingness to let certain projects just wither and die should be a good thing ...
- deleted 10y ago
  [deleted]
- wtbob 10y ago
  > Considering the non existence of a systemd developer community, it's pretty risky. There's also the fact that it's written in C. Writing security-sensitive software in C in 2016 is, in general, a grievous mistake. No, other languages are not perfect; yes, other languages have their own issues; regardless, C is worse than most. Buffer overflows, memory management, lack of type safety — Just Say No™.
  - qwertyuiop924 10y ago
    It's an acceptable language for writing the piece of software that init is supposed to be. However, systemd is for more complicated and integrated and unsafe than that piece of software.
    - zeveb 10y ago
      > It's an acceptable language for writing the piece of software that init is supposed to be. Is it though? Although I can't think of a lot of vulnerabilities to be concerned of in PID 1, I can think of a few (perhaps something to do with reaping zombies?). Why even allow for that possibility? I see no reason why init(1) couldn't be written in Lisp, or Python (although the speed might not be great), or Go, or Rust, or Haskell, or ML.
      - bandrami 10y ago
        PID 1 shouldn't have anything complicated about it. A comp sci student should be able to write it in 10 minutes. This is a solved problem[1]. A run control system, which should be a completely separate project, could easily be written in a higher-level language than C. For instance, the traditional Linux RC system is written in sh, and the official GNU RC system[2] is written in scheme. Daemon run control isn't a domain where performance is crucial; transparency is much more important there, so the argument for using a higher level language to control daemons is pretty strong. [1] http://git.suckless.org/sinit/ http://git.suckless.org/sinit/ [2] https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/
        qwertyuiop924 10y ago
        Yep. Pretty much. The setup is that you have your init, which handles startup, shutdown, reaping, and runs your RC. From there, you'll run process montoring for daemons (this is sometimes integrated into rc, sometimes spun out, resulting in runit, s6, and the rest of the daemontools family). This is sometimes mashed together into one program. Sometimes RC and init are the same, and process monitoring is spun out. But that's the pattern. Most RCs and process managers also have the ability to run as PID 1 if you want them to, and many do. But it's not necessary, and it is a security liability (although not as much of one as systemd, which does so much more than all of this, and which people are trying to expose to the internet directly).
        justinsaccount 10y ago
  - jcranmer 10y ago
    Systemd was started in 2010, not 2016. That would be before Go or Rust were viable options, and probably before C++ would have been a palatable alternative.

I think he is being downvoted because he is factual wrong. Could someone please elaborate with details?

by darfs 10y ago

I think he is being downvoted because he is factual wrong. Could someone please elaborate with details?

one of the arguments against systemd is that it consolidates several scriptable and bug-prone isolated scripts into a binary. This is introducing it's own risks that require upstream interaction to fix a small issue normally a sysadmin without knowledge of C can hot-fix locally. Considering the non existence of a systemd developer community, it's pretty risky. There are similar arguments (pro/against) docker where 2 camps, one saying it's poison & bloat the other the best thing since tabbed browsing. People get so riled up because they're unwilling to acknowledge that they're just tools that make lot sense for solving specific issues. Everyone keeps looking for silver bullets. Problems start when one camp tries to become the de-facto standard (not just the tool but also the processes that come with it). Also people are way to scared of code-forks IMHO. The "fail quick, fail fast" mentality should apply here too. Some healthy competition and a willingness to let certain projects just wither and die should be a good thing ...

deleted 10y ago
[deleted]
wtbob 10y ago
> Considering the non existence of a systemd developer community, it's pretty risky. There's also the fact that it's written in C. Writing security-sensitive software in C in 2016 is, in general, a grievous mistake. No, other languages are not perfect; yes, other languages have their own issues; regardless, C is worse than most. Buffer overflows, memory management, lack of type safety — Just Say No™.
- qwertyuiop924 10y ago
  It's an acceptable language for writing the piece of software that init is supposed to be. However, systemd is for more complicated and integrated and unsafe than that piece of software.
  - zeveb 10y ago
    > It's an acceptable language for writing the piece of software that init is supposed to be. Is it though? Although I can't think of a lot of vulnerabilities to be concerned of in PID 1, I can think of a few (perhaps something to do with reaping zombies?). Why even allow for that possibility? I see no reason why init(1) couldn't be written in Lisp, or Python (although the speed might not be great), or Go, or Rust, or Haskell, or ML.
    - bandrami 10y ago
      PID 1 shouldn't have anything complicated about it. A comp sci student should be able to write it in 10 minutes. This is a solved problem[1]. A run control system, which should be a completely separate project, could easily be written in a higher-level language than C. For instance, the traditional Linux RC system is written in sh, and the official GNU RC system[2] is written in scheme. Daemon run control isn't a domain where performance is crucial; transparency is much more important there, so the argument for using a higher level language to control daemons is pretty strong. [1] http://git.suckless.org/sinit/ http://git.suckless.org/sinit/ [2] https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/
      - qwertyuiop924 10y ago
        Yep. Pretty much. The setup is that you have your init, which handles startup, shutdown, reaping, and runs your RC. From there, you'll run process montoring for daemons (this is sometimes integrated into rc, sometimes spun out, resulting in runit, s6, and the rest of the daemontools family). This is sometimes mashed together into one program. Sometimes RC and init are the same, and process monitoring is spun out. But that's the pattern. Most RCs and process managers also have the ability to run as PID 1 if you want them to, and many do. But it's not necessary, and it is a security liability (although not as much of one as systemd, which does so much more than all of this, and which people are trying to expose to the internet directly).
        justinsaccount 10y ago
- jcranmer 10y ago
  Systemd was started in 2010, not 2016. That would be before Go or Rust were viable options, and probably before C++ would have been a palatable alternative.