7 ms·

> 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,

> 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).
    - sanderjd 7y ago
      Ha yeah, I didn't mean "they really should have used Go", I just meant, "Go as it exists today may be a good thing to use for this".
  - masklinn 7y ago
    Given the timeframe, something like OCaml would likely have been a better option.
    - szemet 7y ago
      Ocaml parallelism/concurrency story was not that good - but Haskell has just got its fancy new epoll based I/O manager (100000+ lightweight threads) around that time, with the 7.0.1 release (16 November 2010) They could have even take inspiration, imagine: typed, functional, monadic init files - "systemd: avoid success at all costs" :)
      - astrobe_ 7y ago
        The topic is memory safety, not concurrency support, FWIW. Lua would have been a good candidate: memory safe, coroutine to structure the code in a concurrent-ish way if needed, and you have a configuration file parser for free (just use Lua as the configuration language, it was its very first purpose after all).
      - masklinn 7y ago
        > Ocaml parallelism/concurrency story was not that good I wouldn't expect CPU-bound multithreading to be much of a concern in an init/rc system. And resource thriftiness and predictability would likely be a bigger concern.
      - the_why_of_y 7y ago
        While that would be amusing for sure, systemd's pid 1 is actually single threaded.
      - ernst_klim 7y ago
        >Ocaml parallelism/concurrency story was not that good OCaml concurrency is great, and Lwt [1] would be exactly what systemd need: run daemon and poll the answer concurrently. Ada, C++ and D would have been another great choices. [1] https://github.com/ocsigen/lwt https://github.com/ocsigen/lwt
      - m4rtink 7y ago
- tracker1 7y ago
  Rust would have been more appropriate. Something like SystemD at such a low level in terms of hardware and service management should not be done in a language with a garbage collector imho.
  - jamesgeck0 7y ago
    systemd predates Rust by a bit over a year.
    - tracker1 7y ago
      The point stands, Go isn't a good option for this type of process.
      - jerf 7y ago
        The only thing that I can think of for that 2019 Go that would be a problem for this use case is binary size. None of the rest of the usual complaints would be stoppers or even that big a deal, and most of them, I'd pay to have a memory-safe language being used at that level. Init systems are a type of code that we don't have a good word for, but that I tend to end up in a lot, the code that isn't CPU intensive, or disk intensive, or RAM intensive, etc., but is all just logic and correctness rather than any of that. So "but Go is GC'ed!" isn't particularly relevant, for instance, because an init system pretty much ought to settle into a steady state and not be executing at all, on average, so who cares about a handful of microsecond GC pauses that may or may not occur at startup time? Rust might be better now; my primary concern would be community size and whether I was limiting my contributor base, which Go also has as a concern. In both cases though I'd take it over C/C++ being used on such a critical project at this juncture. In 2010, though... yeah, choices are a lot worse.
        tracker1 7y ago
        I understand there's a much more limited subset of developers for Rust or even Go vs. C/C++. Also, I recall hearing about Rust before systemd, but am not sure. Today, it would probably be my first choice. Not that go is a bad choice, I just don't think it's a good spot for it. I also agree that either are probably quite a bit better than C/C++ options. I'm not against go, other than gc and some size considerations. Given that a lot of k8s infrastructure for the likes of CoreOS and similar are written in it, it's definitely not a bad option. I think that today, and more so in late summer as async/await syntax settles, that Rust should be a first consideration for any low-level system code.
- grumdan 7y ago
  Sure, there are other concerns and bash is not an ideal language, but memory safety is responsible for quite a large number of security flaws, since its lack turns bugs into code execution vulnerabilities on a regular basis. I don't really have an opinion on what language should have been picked instead, though OCaml may be a good candidate.
  - dscpls 7y ago
    To be fair, erlang would have been the better choice here. Memory safety, concurrency and solid error handling all in one.
    - yellowapple 7y ago
      I think I know what my next Erlang project's gonna be. Erlang-as-PID-1, here we come! EDIT: or maybe as PID 2, per https://github.com/omisego/ewallet/issues/108 https://github.com/omisego/ewallet/issues/108 , though I'd be interested in the idea of writing an OTP application that can reap zombies and forward signals.
- AaronFriel 7y ago
  > People do not write million lines of code applications in bash, for a reason, trade-offs are to be made. Isn't that basically what SysVinit and a good-sized chunk of the management tooling in Linux is? To their credit, Bash is a _weird_ language, but it's not going to corrupt memory when it crashes, and its failure modes are pretty well understood by the distro maintainers writing those scripts.
  - boomlinde 7y ago
    Those are all not million lines of code applications, but that only speaks in favor of a more traditional Unix userspace design. With modularity on the process level you don't need a million lines of code to herd services. Why an init system should a million lines of code is a mystery to me.
- yellowapple 7y ago
  > People do not write million lines of code applications in bash, for a reason And that reason is that one rarely needs to write a million lines of Bash: http://catb.org/esr/writings/unix-koans/ten-thousand.html http://catb.org/esr/writings/unix-koans/ten-thousand.html
  - Intermernet 7y ago
    If they'd picked Perl, they could have written an init system in one line... (hopefully, obviously /s)
    - yellowapple 7y ago
      > (hopefully, obviously /s) You underestimate my masochism and/or overestimate my sense of restraint ;)
dullgiulio 7y ago
Bash is memory safe until you run 'rm -rf $DIR/' when DIR is unset. Let's just say the language choice went from bad to equally bad.
- effie 7y ago
  If you run or write that command into script without checking what DIR variable contains, the problem is in your lack of experience with shell, not the language choice. Also nowadays, rm itself has --preserve-root as default, so this won't delete your root fs.
  - eropple 7y ago
    This is true if you are running the GNU userland. It's not necessarily true with other userlands that are often run on top of Linux. In a discussion touching on systemd, it strikes me as a little surprising that somebody would rely on a quirk of another replaceable component. ;)
    - dijit 7y ago
      I’m sure the irony is not lost on you regarding the fact that systemd can not possibly run on an alternative platform, thus the situation you just ascribed is not “better” with systemd.
      - eropple 7y ago
        Sure. That wasn't in favor of systemd, though? I comfortably write code against the GNU userland and I use systemd where it crops up. Just not a big deal to me; if somebody wanted to use my stuff elsewhere I'd just say "pull requests welcome!". I found the inconsistency striking, that's all.
    - effie 7y ago
      Checking for content of a variable before passing it to rm is a basic instinct that should be done in all shell scripts. The comment about --preserve-root is just a reminder that the problem of deleting / is very rare.
AsyncAwait 7y ago
> they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++) While Bash is memory safe, it is also very error prone to write and the potential of shooting yourself in the foot with it is rather big, especially with bigger scripts and considering these are executed mostly with root privileges, bash is not an ideal choice either. I'd prefer if systemd was a Rust project for sure, but they went with C, presumably to remain consistent with the kernel, GNOME and most lower-level Linux system software, (also, Rust was pre-1.0 at the time).

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).
  - sanderjd 7y ago
    Ha yeah, I didn't mean "they really should have used Go", I just meant, "Go as it exists today may be a good thing to use for this".
- masklinn 7y ago
  Given the timeframe, something like OCaml would likely have been a better option.
  - szemet 7y ago
    Ocaml parallelism/concurrency story was not that good - but Haskell has just got its fancy new epoll based I/O manager (100000+ lightweight threads) around that time, with the 7.0.1 release (16 November 2010) They could have even take inspiration, imagine: typed, functional, monadic init files - "systemd: avoid success at all costs" :)
    - astrobe_ 7y ago
      The topic is memory safety, not concurrency support, FWIW. Lua would have been a good candidate: memory safe, coroutine to structure the code in a concurrent-ish way if needed, and you have a configuration file parser for free (just use Lua as the configuration language, it was its very first purpose after all).
    - masklinn 7y ago
      > Ocaml parallelism/concurrency story was not that good I wouldn't expect CPU-bound multithreading to be much of a concern in an init/rc system. And resource thriftiness and predictability would likely be a bigger concern.
    - the_why_of_y 7y ago
      While that would be amusing for sure, systemd's pid 1 is actually single threaded.
    - ernst_klim 7y ago
      >Ocaml parallelism/concurrency story was not that good OCaml concurrency is great, and Lwt [1] would be exactly what systemd need: run daemon and poll the answer concurrently. Ada, C++ and D would have been another great choices. [1] https://github.com/ocsigen/lwt https://github.com/ocsigen/lwt
    - m4rtink 7y ago
tracker1 7y ago
Rust would have been more appropriate. Something like SystemD at such a low level in terms of hardware and service management should not be done in a language with a garbage collector imho.
- jamesgeck0 7y ago
  systemd predates Rust by a bit over a year.
  - tracker1 7y ago
    The point stands, Go isn't a good option for this type of process.
    - jerf 7y ago
      The only thing that I can think of for that 2019 Go that would be a problem for this use case is binary size. None of the rest of the usual complaints would be stoppers or even that big a deal, and most of them, I'd pay to have a memory-safe language being used at that level. Init systems are a type of code that we don't have a good word for, but that I tend to end up in a lot, the code that isn't CPU intensive, or disk intensive, or RAM intensive, etc., but is all just logic and correctness rather than any of that. So "but Go is GC'ed!" isn't particularly relevant, for instance, because an init system pretty much ought to settle into a steady state and not be executing at all, on average, so who cares about a handful of microsecond GC pauses that may or may not occur at startup time? Rust might be better now; my primary concern would be community size and whether I was limiting my contributor base, which Go also has as a concern. In both cases though I'd take it over C/C++ being used on such a critical project at this juncture. In 2010, though... yeah, choices are a lot worse.
      - tracker1 7y ago
        I understand there's a much more limited subset of developers for Rust or even Go vs. C/C++. Also, I recall hearing about Rust before systemd, but am not sure. Today, it would probably be my first choice. Not that go is a bad choice, I just don't think it's a good spot for it. I also agree that either are probably quite a bit better than C/C++ options. I'm not against go, other than gc and some size considerations. Given that a lot of k8s infrastructure for the likes of CoreOS and similar are written in it, it's definitely not a bad option. I think that today, and more so in late summer as async/await syntax settles, that Rust should be a first consideration for any low-level system code.
grumdan 7y ago
Sure, there are other concerns and bash is not an ideal language, but memory safety is responsible for quite a large number of security flaws, since its lack turns bugs into code execution vulnerabilities on a regular basis. I don't really have an opinion on what language should have been picked instead, though OCaml may be a good candidate.
- dscpls 7y ago
  To be fair, erlang would have been the better choice here. Memory safety, concurrency and solid error handling all in one.
  - yellowapple 7y ago
    I think I know what my next Erlang project's gonna be. Erlang-as-PID-1, here we come! EDIT: or maybe as PID 2, per https://github.com/omisego/ewallet/issues/108 https://github.com/omisego/ewallet/issues/108 , though I'd be interested in the idea of writing an OTP application that can reap zombies and forward signals.
AaronFriel 7y ago
> People do not write million lines of code applications in bash, for a reason, trade-offs are to be made. Isn't that basically what SysVinit and a good-sized chunk of the management tooling in Linux is? To their credit, Bash is a _weird_ language, but it's not going to corrupt memory when it crashes, and its failure modes are pretty well understood by the distro maintainers writing those scripts.
- boomlinde 7y ago
  Those are all not million lines of code applications, but that only speaks in favor of a more traditional Unix userspace design. With modularity on the process level you don't need a million lines of code to herd services. Why an init system should a million lines of code is a mystery to me.
yellowapple 7y ago
> People do not write million lines of code applications in bash, for a reason And that reason is that one rarely needs to write a million lines of Bash: http://catb.org/esr/writings/unix-koans/ten-thousand.html http://catb.org/esr/writings/unix-koans/ten-thousand.html
- Intermernet 7y ago
  If they'd picked Perl, they could have written an init system in one line... (hopefully, obviously /s)
  - yellowapple 7y ago
    > (hopefully, obviously /s) You underestimate my masochism and/or overestimate my sense of restraint ;)

dullgiulio 7y ago

Bash is memory safe until you run 'rm -rf $DIR/' when DIR is unset. Let's just say the language choice went from bad to equally bad.

effie 7y ago
If you run or write that command into script without checking what DIR variable contains, the problem is in your lack of experience with shell, not the language choice. Also nowadays, rm itself has --preserve-root as default, so this won't delete your root fs.
- eropple 7y ago
  This is true if you are running the GNU userland. It's not necessarily true with other userlands that are often run on top of Linux. In a discussion touching on systemd, it strikes me as a little surprising that somebody would rely on a quirk of another replaceable component. ;)
  - dijit 7y ago
    I’m sure the irony is not lost on you regarding the fact that systemd can not possibly run on an alternative platform, thus the situation you just ascribed is not “better” with systemd.
    - eropple 7y ago
      Sure. That wasn't in favor of systemd, though? I comfortably write code against the GNU userland and I use systemd where it crops up. Just not a big deal to me; if somebody wanted to use my stuff elsewhere I'd just say "pull requests welcome!". I found the inconsistency striking, that's all.
  - effie 7y ago
    Checking for content of a variable before passing it to rm is a basic instinct that should be done in all shell scripts. The comment about --preserve-root is just a reminder that the problem of deleting / is very rare.

AsyncAwait 7y ago

> they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++) While Bash is memory safe, it is also very error prone to write and the potential of shooting yourself in the foot with it is rather big, especially with bigger scripts and considering these are executed mostly with root privileges, bash is not an ideal choice either. I'd prefer if systemd was a Rust project for sure, but they went with C, presumably to remain consistent with the kernel, GNOME and most lower-level Linux system software, (also, Rust was pre-1.0 at the time).