4 ms·

The main problem with systemd IMO is that it’s written in a critically insecure language. If they could rewrite it in something safe but keep the same design, t

The main problem with systemd IMO is that it’s written in a critically insecure language. If they could rewrite it in something safe but keep the same design, that would be ideal.

atoav 6y ago
I would rather say, the main problem with systemd is, that it tries to solve to many things in a way that: 1. makes very common usecases needlessly hard for beginners (e.g. run something on boot) 2. is sometimes the opposite of self explainatory I use systemd and am OK with it and I aggree with the problems it is trying to solve. It is just a bit convoluted and intransparent even after years of using it.
- genghizkhan 6y ago
  I'd say running something on boot tends to be similar for beginners with or without systemd. The support for drop-in configs, however, makes it easy to revert screw-ups without much effort. In addition, the fact that one does not have to write any bash to change the way a service is started is a godsend. Ini-files aren't perfect, I get that, but from the point of view of a beginner they're both easier to grok and modify as compared to bash scripts.
- foobar33333 6y ago
  I had to find a way to start something on boot recently and I found it trivial. I just did a google search for starting thing on boot systemd, copied a 5 line service file, enabled it and it worked. And if you just want to start a gui, Gnome Tweaks has a page which is super simple.
- deadbunny 6y ago
  > makes very common usecases needlessly hard for beginners (e.g. run something on boot) Ah yes, systemd unit files are well regarded as far more complex than shell scripts that are 99% boilerplate. /s
  - GordonS 6y ago
    systemd unit files are a massive step up from the old way - they properly handle dependant services, running as a user, can handle restarts for you etc. And as you say, no more annoying boilerplate! Actually, unit files are possibly the only part of SystemD that I've knowingly interacted with - I know it does about a thousand things, but whatever those other things are, they are transparent to me as a user.
    - deadbunny 6y ago
      I agree completely. I was being a sarcastic arse because GP said that systemd apparently makes it hard to get something to start on boot.
      - GordonS 6y ago
        I got the sarcasm - the "/s" would have given it, as if it was needed :)
- zlynx 6y ago
  I have had to help a few Unix newbies, and systemd is way easier to explain than RedHat init scripts with comment blocks for chkconfig and no useful errors if things are wrong. The biggest problem I remember now is that when testing your init script it picks up environment variables from your root shell. So, because of that it works when it shouldn't, and realizing what's missing is a big debugging nightmare. The systemd init starts every unit in the same environment. Another one that resulted in hours of fun fixing it is init scripts happily starting services even when various filesystems failed to mount. Like /var. Getting those particular database files back in sync after the / filesystem filled up was a nightmare. Systemd has pretty good documentation and I think it is a feature that its users are pushed to read it, rather than hacking out a shell script that doesn't use half the already existing functions because the author never bothered to read RedHat or Debian docs.
junon 6y ago
Wait until you hear what the Darwin, Linux and Windows kernels are written in...
- robertlagrant 6y ago
  Ooh ooh I know I know! They were all written in.. ...the 90s. So it's too late to change them. We should definitely be considering safer languages in 2021.
  - junon 6y ago
    None of the safe languages I know of that are capable of writing an OS in are "safe" in the verification sense. They require extra, external processes for doing such. See the SEL4 kernel.
kaba0 6y ago
I’m not sure why are you downvoted — yeah the “rewrite everything in rust” hype is bad/annoying (and no, I don’t have any problem with rust), but systemd simply should not have been started in C. It replaced goddamn shell scripts so performance can’t really be a good argument pro, but a not too scripty managed language would have more than enough performance.
- nn3 6y ago
  If it had been written in rust or go, we already would have hundreds of MB worth of systemd binaries on our disks, like some other popular packages. People all the time complain about systemd bloat, but it's very likely that in those languages it would be far worse.
  - kaba0 6y ago
    I don’t believe people complain about systemd binaries’ sizes at all. They complain about bloat (in my opinion wrongly) in terms of systemd incorporating more and more features that often seems orthogonal to an init system. But often these are not part of systemd itself, but created only under the same project.
- CameronNemo 6y ago
  What language would have been appropriate in 2013?
  - kaba0 6y ago
    Well, C++ had been around, but there were plenty of managed languages also. I will be hated for this, but perhaps even Java would have been appropriate if one sets the heap size appropriately, I believe the GCs were already quite good then; and it wouldn’t have to create too much garbage so I think it could get away with only a bit of memory. The only problem is the not too comfortable way to do C calls.
    - fl0wenol 6y ago
      Unix sockets aren't in the standard java libraries either, which probably meant it was a non-starter.

The main problem with systemd IMO is that it’s written in a critically insecure language. If they could rewrite it in something safe but keep the same design, that would be ideal.

atoav 6y ago

I would rather say, the main problem with systemd is, that it tries to solve to many things in a way that: 1. makes very common usecases needlessly hard for beginners (e.g. run something on boot) 2. is sometimes the opposite of self explainatory I use systemd and am OK with it and I aggree with the problems it is trying to solve. It is just a bit convoluted and intransparent even after years of using it.

genghizkhan 6y ago
I'd say running something on boot tends to be similar for beginners with or without systemd. The support for drop-in configs, however, makes it easy to revert screw-ups without much effort. In addition, the fact that one does not have to write any bash to change the way a service is started is a godsend. Ini-files aren't perfect, I get that, but from the point of view of a beginner they're both easier to grok and modify as compared to bash scripts.
foobar33333 6y ago
I had to find a way to start something on boot recently and I found it trivial. I just did a google search for starting thing on boot systemd, copied a 5 line service file, enabled it and it worked. And if you just want to start a gui, Gnome Tweaks has a page which is super simple.
deadbunny 6y ago
> makes very common usecases needlessly hard for beginners (e.g. run something on boot) Ah yes, systemd unit files are well regarded as far more complex than shell scripts that are 99% boilerplate. /s
- GordonS 6y ago
  systemd unit files are a massive step up from the old way - they properly handle dependant services, running as a user, can handle restarts for you etc. And as you say, no more annoying boilerplate! Actually, unit files are possibly the only part of SystemD that I've knowingly interacted with - I know it does about a thousand things, but whatever those other things are, they are transparent to me as a user.
  - deadbunny 6y ago
    I agree completely. I was being a sarcastic arse because GP said that systemd apparently makes it hard to get something to start on boot.
    - GordonS 6y ago
      I got the sarcasm - the "/s" would have given it, as if it was needed :)
zlynx 6y ago
I have had to help a few Unix newbies, and systemd is way easier to explain than RedHat init scripts with comment blocks for chkconfig and no useful errors if things are wrong. The biggest problem I remember now is that when testing your init script it picks up environment variables from your root shell. So, because of that it works when it shouldn't, and realizing what's missing is a big debugging nightmare. The systemd init starts every unit in the same environment. Another one that resulted in hours of fun fixing it is init scripts happily starting services even when various filesystems failed to mount. Like /var. Getting those particular database files back in sync after the / filesystem filled up was a nightmare. Systemd has pretty good documentation and I think it is a feature that its users are pushed to read it, rather than hacking out a shell script that doesn't use half the already existing functions because the author never bothered to read RedHat or Debian docs.

junon 6y ago

Wait until you hear what the Darwin, Linux and Windows kernels are written in...

robertlagrant 6y ago
Ooh ooh I know I know! They were all written in.. ...the 90s. So it's too late to change them. We should definitely be considering safer languages in 2021.
- junon 6y ago
  None of the safe languages I know of that are capable of writing an OS in are "safe" in the verification sense. They require extra, external processes for doing such. See the SEL4 kernel.

kaba0 6y ago

I’m not sure why are you downvoted — yeah the “rewrite everything in rust” hype is bad/annoying (and no, I don’t have any problem with rust), but systemd simply should not have been started in C. It replaced goddamn shell scripts so performance can’t really be a good argument pro, but a not too scripty managed language would have more than enough performance.

nn3 6y ago
If it had been written in rust or go, we already would have hundreds of MB worth of systemd binaries on our disks, like some other popular packages. People all the time complain about systemd bloat, but it's very likely that in those languages it would be far worse.
- kaba0 6y ago
  I don’t believe people complain about systemd binaries’ sizes at all. They complain about bloat (in my opinion wrongly) in terms of systemd incorporating more and more features that often seems orthogonal to an init system. But often these are not part of systemd itself, but created only under the same project.
CameronNemo 6y ago
What language would have been appropriate in 2013?
- kaba0 6y ago
  Well, C++ had been around, but there were plenty of managed languages also. I will be hated for this, but perhaps even Java would have been appropriate if one sets the heap size appropriately, I believe the GCs were already quite good then; and it wouldn’t have to create too much garbage so I think it could get away with only a bit of memory. The only problem is the not too comfortable way to do C calls.
  - fl0wenol 6y ago
    Unix sockets aren't in the standard java libraries either, which probably meant it was a non-starter.