5 ms·

One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of c

by b112 3y ago

One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity. Yes, there are things delivered with that complexity. However, as an example, sysvinit is maybe, oh, 20k lines of code including binaries, heck including all core init scripts. What's systemd? 2M lines? It was >1M lines 4+ years ago. For an init system, a thing that is to be the core of stability, security, and most importantly glacial, stable change -- that is absurdly complex. It's exceedingly over engineered. And so you get cases like this. And cases like that, and that over there, and that case over there too. All which could not exist, if systemd didn't try to overengineer, over complicate everything. Ah well. I'm still waiting for someone to basically fork systemd, remove all the fluff (udev, ntp, dns, timers, restart code, specialized logging, on and on and on), and just end up with systemd compatible service files. But not yet. So... well, oh well.

gavinhoward 3y ago
I have a design in the works to do just this. The problem? It's on the backburner because I don't think I could find a business model to make money from it. I don't think offering support for a price would work, for example.
- adr1an 3y ago
  What about sponsors? Actually, now I have the idea of a platform similar to Kickstarter but for software development, and with just sponsors. It wouldn't work, sure... Except in some cases. Like when things like this happen...
  - gavinhoward 3y ago
    Sponsors are fickle, unfortunately, and they tend to remove "donations" when money gets tight. If I am considered a full vendor, though, and a vendor for a critical piece of software, they might keep me around.
- iforgotpassword 3y ago
  What's the point of your implementation? systemd is totally modular, you can use just the init system without networkd, timesyncd, resolved, nspawn, whatever else I forgot about. If you want you can just use systemd as PID1 for service management and enjoy a sane way to define and manage services – and do everything in archaic ways like 20 years ago.
  - gavinhoward 3y ago
    There are two points to the implementation: * Choice. If I have a separate implementation, my users do not have to be subject to systemd's choices. And I do not either. * The same implementation will have the same bugs, so in the same way that redundant software has multiple independent implementations, having an independent implementation will avoid the same bugs. It may have different bugs, sure, but my goal would be to test like SQLite and achieve DO-178C certification. Or as close as I could, anyway.
    - iforgotpassword 3y ago
      I'd assume chances of monetizing this are incredibly low. There already is an init system that understands systemd unit files, the name escapes my mind unfortunately. DO-178C might be a selling point literally, but whether there's enough potential customers for ROI is questionable.
      - gavinhoward 3y ago
        I unfortunately agree with you. Hence why it's on the backburner.
      - JdeBP 3y ago
        Ahem! * https://jdebp.uk/Softwares/nosh/guide/converting-systemd-units.html https://jdebp.uk/Softwares/nosh/guide/converting-systemd-uni...
  - Repulsion9513 3y ago
    No, you can't. Systemd might be somewhat modular; the things distros ship which depend on it are not.
jorvi 3y ago
> Ah well. I'm still waiting for someone to basically fork systemd, remove all the fluff (udev, ntp, dns, timers, restart code, specialized logging, on and on and on) Most of the things you named there are modular and can be easily disabled. Furthermore, udev precedes systemd and systemd has in fact its own replacement for it (though the name escapes me). Kind of a classic, people loving harping on systemd without properly understanding it.
- johnny22 3y ago
  systemd subsumed udev. Eudev is what folks who don't have systemd use.
- nottorp 3y ago
  > are modular and can be easily disabled. That's a common defense for any bloatware. If they're modular and easily disabled then why are they all enabled by default?
matheusmoreira 3y ago
Systemd is actually pretty damn good and it's GPL licensed free software. I understand that people don't like the way it seems to work itself into the rest of Linux user space as a dependency but that's actually our own fault for not investing the man power that Red Hat invests. We have better things to do than make our own Linux user space and so they have occupied that niche. It's free software though, we always have the freedom to do whatever we want. By the way, all the stuff you mentioned is not really part of the actual init system, namely PID 1. There's an actual service manager for example and it's entirely separate from init. It manages services really well too, it's measurably better than all that "portable" nonsense just by virtue of using cgroups to manage processes which means it can actually supervise poorly written double forking daemons.
- pessimizer 3y ago
  People are complaining that it's too big, labyrinthine, and arcane to audit, not that it doesn't work. They would prefer other things that work, but don't share those characteristics. Also, the more extensive the remit (of this init), the more complexly interconnected the interactions between the components; the fewer people understand the architecture, the fewer people understand the code, the fewer people read the code. This creates a situation where the codebase is getting larger and larger at a rate faster than the growth of the number of man-hours being put into reading it. This has to make it easier for people who are systemd specialists to put in (intentionally or unintentionally) backdoors and exploitable bugs that will last for years. People keep defending systemd by talking about its UI and its features, but that completely misses the point. If systemd were replaced by something comprehensible and less internally codependent, even if the systemd UI and features were preserved, most systemd complainers would be over the moon with happiness. Red Hat invests too much into completely replacing linux subsystems, they should take a break. Maybe fix the bugs in MATE.
  - dralley 3y ago
    >the more complexly interconnected the interactions between the components This is a bit of a rich criticism of systemd, given the init scripts it replaced. > Red Hat invests too much into completely replacing linux subsystems, they should take a break. Maybe fix the bugs in MATE. MATE isn't a Red Hat project. And nobody complains about Pipewire.
dralley 3y ago
This is a bit like complaining that the Linux kernel has 30 million lines of code, while ignoring that 3/4 of that is in hardware support (drivers) or filesystems that nobody is actually required to use at any given time. systemd is a collection of tools, one of which is an init system. Nobody accused GNU yes of being bloated just because it's in a repository alongside 50 other tools.
- msm_ 3y ago
  Gnu yes is actually pretty bloated. It's 130 lines of code for something so trivial [1]! ;) [1] https://github.com/coreutils/coreutils/blob/master/src/yes.c https://github.com/coreutils/coreutils/blob/master/src/yes.c
  - pixelbeat 3y ago
    yes(1) is the standard unix way of generating repeated data. It's good to do this as quickly as possible. I really don't understand why so many get annoyed with this code. 130 lines isn't that complicated in the scheme of things.
- Repulsion9513 3y ago
  > that nobody is actually required to use at any given time But that's the very problem with systemd! As time goes on you're required, whether by systemd itself or by the ecosystem around it, to use more and more of it, until it's doing not only service management but also timezones, RTC, DNS resolution, providing getpwent/getgrent, inetd, VMs and containers, bootloader, udev (without adding literally any benefit over the existing implementations), ... oh and you also have to add significant complexity in other things (like the kernel!) to use it, like namespaces (which have been a frequent source of vulnerabilities)...
  - SahAssar 3y ago
    > timezones, RTC, DNS resolution, providing getpwent/getgrent, inetd, VMs and containers, bootloader How many of those are you actually required to use systemd for? At least for DNS, inetd, containers and bootloader I'm pretty sure I run a few different alternatives across my systems. I think major distros (running systemd) still ship with different dns and inetd, for containers its a lot more common to use a docker-like (probably docker or podman) than it is to use systemd-nspawn. > oh and you also have to add significant complexity in other things (like the kernel!) to use it, like namespaces (which have been a frequent source of vulnerabilities) Namespaces were implemented before systemd, have been used before systemd in widely used systems (for example LXC and many others). Namespaces and similar kernel features are not tied to systemd.
bananapub 3y ago
> One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity. this is and always has been such a dumb take. if you'd like to implement an init (and friends) system that doesn't have "unnecessary complexity" and still provides all the functionality that people currently want, then go and do so and show us? otherwise it's just whinging about things not being like the terrible old days of init being a mass of buggy and racey shell scripts.
- simoncion 3y ago
  > about things not being like the terrible old days of init being a mass of buggy and racey shell scripts. Zero of the major distros used System V init by default. Probably only distros like Slackware or Linux From Scratch even suggested it. It's unfortunate that so many folks uncritically swallowed the Systemd Cabal's claims about how they were the first to do this, that, or the other. (It's also darkly amusing to note that every service that has nontrivial pre-start or post-start configuration and/or verification requirements ends up using systemd to run at least one shell script... which is what would have often been inlined into their init script in other init systems.)
  - bananapub 3y ago
    > Zero of the major distros used System V init by default. Probably only distros like Slackware or Linux From Scratch even suggested it. I have absolutely no idea what you're trying to claim. Are you suggesting that Debian's "sysvinit" package wasn't a System V init system? That the years I spent editing shell scripts in /etc/init.d/ wasn't System V init? or are you making some pointless distinction about it not actually being pre-lawsuit AT&T files so it doesn't count or something? or did you not use Linux before 2010? if you have some important point to make, please make it more clearly. > It's unfortunate that so many folks uncritically swallowed the Systemd Cabal's claims about how they were the first to do this, that, or the other. I feel like you have very strong emotions about init systems that have nothing to do with the comment you're replying to.
    - 3y ago
marcosdumay 3y ago
As long as Gnome requires bug-compatibility with systemd, nobody will rewrite it.
quotemstr 3y ago
> One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity. Complexity that would otherwise be distributed to a sea of ad-hoc shell scripts? systemd is a win
- Repulsion9513 3y ago
  The init-scripts that predated systemd were actually pretty damn simple. So was init itself.
  - adql 3y ago
    We removed tens of thousands of lines of code for fixes for those "simple" init scripts when migrating to systemd. They are never "simple", there is always some fucking edge case, like for example we had Java apps writing its own PID few seconds after start. So any app that did start and immediately after status (like Pacemaker) threw errors. Or how once in blue moon MySQL didn't start after reboot because it so happened that: * the PID file from previous boot wasn't cleared * some other app ran with same PID as it was in file * Script did not care, script saw pid file existing and didn't start MySQL. Both examples from pre-systemd CentOS

by b112 3y ago

gavinhoward 3y ago

I have a design in the works to do just this. The problem? It's on the backburner because I don't think I could find a business model to make money from it. I don't think offering support for a price would work, for example.

adr1an 3y ago
What about sponsors? Actually, now I have the idea of a platform similar to Kickstarter but for software development, and with just sponsors. It wouldn't work, sure... Except in some cases. Like when things like this happen...
- gavinhoward 3y ago
  Sponsors are fickle, unfortunately, and they tend to remove "donations" when money gets tight. If I am considered a full vendor, though, and a vendor for a critical piece of software, they might keep me around.
iforgotpassword 3y ago
What's the point of your implementation? systemd is totally modular, you can use just the init system without networkd, timesyncd, resolved, nspawn, whatever else I forgot about. If you want you can just use systemd as PID1 for service management and enjoy a sane way to define and manage services – and do everything in archaic ways like 20 years ago.
- gavinhoward 3y ago
  There are two points to the implementation: * Choice. If I have a separate implementation, my users do not have to be subject to systemd's choices. And I do not either. * The same implementation will have the same bugs, so in the same way that redundant software has multiple independent implementations, having an independent implementation will avoid the same bugs. It may have different bugs, sure, but my goal would be to test like SQLite and achieve DO-178C certification. Or as close as I could, anyway.
  - iforgotpassword 3y ago
    I'd assume chances of monetizing this are incredibly low. There already is an init system that understands systemd unit files, the name escapes my mind unfortunately. DO-178C might be a selling point literally, but whether there's enough potential customers for ROI is questionable.
    - gavinhoward 3y ago
      I unfortunately agree with you. Hence why it's on the backburner.
    - JdeBP 3y ago
      Ahem! * https://jdebp.uk/Softwares/nosh/guide/converting-systemd-units.html https://jdebp.uk/Softwares/nosh/guide/converting-systemd-uni...
- Repulsion9513 3y ago
  No, you can't. Systemd might be somewhat modular; the things distros ship which depend on it are not.

jorvi 3y ago

> Ah well. I'm still waiting for someone to basically fork systemd, remove all the fluff (udev, ntp, dns, timers, restart code, specialized logging, on and on and on) Most of the things you named there are modular and can be easily disabled. Furthermore, udev precedes systemd and systemd has in fact its own replacement for it (though the name escapes me). Kind of a classic, people loving harping on systemd without properly understanding it.

johnny22 3y ago
systemd subsumed udev. Eudev is what folks who don't have systemd use.
nottorp 3y ago
> are modular and can be easily disabled. That's a common defense for any bloatware. If they're modular and easily disabled then why are they all enabled by default?

matheusmoreira 3y ago

Systemd is actually pretty damn good and it's GPL licensed free software. I understand that people don't like the way it seems to work itself into the rest of Linux user space as a dependency but that's actually our own fault for not investing the man power that Red Hat invests. We have better things to do than make our own Linux user space and so they have occupied that niche. It's free software though, we always have the freedom to do whatever we want. By the way, all the stuff you mentioned is not really part of the actual init system, namely PID 1. There's an actual service manager for example and it's entirely separate from init. It manages services really well too, it's measurably better than all that "portable" nonsense just by virtue of using cgroups to manage processes which means it can actually supervise poorly written double forking daemons.

pessimizer 3y ago
People are complaining that it's too big, labyrinthine, and arcane to audit, not that it doesn't work. They would prefer other things that work, but don't share those characteristics. Also, the more extensive the remit (of this init), the more complexly interconnected the interactions between the components; the fewer people understand the architecture, the fewer people understand the code, the fewer people read the code. This creates a situation where the codebase is getting larger and larger at a rate faster than the growth of the number of man-hours being put into reading it. This has to make it easier for people who are systemd specialists to put in (intentionally or unintentionally) backdoors and exploitable bugs that will last for years. People keep defending systemd by talking about its UI and its features, but that completely misses the point. If systemd were replaced by something comprehensible and less internally codependent, even if the systemd UI and features were preserved, most systemd complainers would be over the moon with happiness. Red Hat invests too much into completely replacing linux subsystems, they should take a break. Maybe fix the bugs in MATE.
- dralley 3y ago
  >the more complexly interconnected the interactions between the components This is a bit of a rich criticism of systemd, given the init scripts it replaced. > Red Hat invests too much into completely replacing linux subsystems, they should take a break. Maybe fix the bugs in MATE. MATE isn't a Red Hat project. And nobody complains about Pipewire.

dralley 3y ago

This is a bit like complaining that the Linux kernel has 30 million lines of code, while ignoring that 3/4 of that is in hardware support (drivers) or filesystems that nobody is actually required to use at any given time. systemd is a collection of tools, one of which is an init system. Nobody accused GNU yes of being bloated just because it's in a repository alongside 50 other tools.

msm_ 3y ago
Gnu yes is actually pretty bloated. It's 130 lines of code for something so trivial [1]! ;) [1] https://github.com/coreutils/coreutils/blob/master/src/yes.c https://github.com/coreutils/coreutils/blob/master/src/yes.c
- pixelbeat 3y ago
  yes(1) is the standard unix way of generating repeated data. It's good to do this as quickly as possible. I really don't understand why so many get annoyed with this code. 130 lines isn't that complicated in the scheme of things.
Repulsion9513 3y ago
> that nobody is actually required to use at any given time But that's the very problem with systemd! As time goes on you're required, whether by systemd itself or by the ecosystem around it, to use more and more of it, until it's doing not only service management but also timezones, RTC, DNS resolution, providing getpwent/getgrent, inetd, VMs and containers, bootloader, udev (without adding literally any benefit over the existing implementations), ... oh and you also have to add significant complexity in other things (like the kernel!) to use it, like namespaces (which have been a frequent source of vulnerabilities)...
- SahAssar 3y ago
  > timezones, RTC, DNS resolution, providing getpwent/getgrent, inetd, VMs and containers, bootloader How many of those are you actually required to use systemd for? At least for DNS, inetd, containers and bootloader I'm pretty sure I run a few different alternatives across my systems. I think major distros (running systemd) still ship with different dns and inetd, for containers its a lot more common to use a docker-like (probably docker or podman) than it is to use systemd-nspawn. > oh and you also have to add significant complexity in other things (like the kernel!) to use it, like namespaces (which have been a frequent source of vulnerabilities) Namespaces were implemented before systemd, have been used before systemd in widely used systems (for example LXC and many others). Namespaces and similar kernel features are not tied to systemd.

bananapub 3y ago

> One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity. this is and always has been such a dumb take. if you'd like to implement an init (and friends) system that doesn't have "unnecessary complexity" and still provides all the functionality that people currently want, then go and do so and show us? otherwise it's just whinging about things not being like the terrible old days of init being a mass of buggy and racey shell scripts.

simoncion 3y ago
> about things not being like the terrible old days of init being a mass of buggy and racey shell scripts. Zero of the major distros used System V init by default. Probably only distros like Slackware or Linux From Scratch even suggested it. It's unfortunate that so many folks uncritically swallowed the Systemd Cabal's claims about how they were the first to do this, that, or the other. (It's also darkly amusing to note that every service that has nontrivial pre-start or post-start configuration and/or verification requirements ends up using systemd to run at least one shell script... which is what would have often been inlined into their init script in other init systems.)
- bananapub 3y ago
  > Zero of the major distros used System V init by default. Probably only distros like Slackware or Linux From Scratch even suggested it. I have absolutely no idea what you're trying to claim. Are you suggesting that Debian's "sysvinit" package wasn't a System V init system? That the years I spent editing shell scripts in /etc/init.d/ wasn't System V init? or are you making some pointless distinction about it not actually being pre-lawsuit AT&T files so it doesn't count or something? or did you not use Linux before 2010? if you have some important point to make, please make it more clearly. > It's unfortunate that so many folks uncritically swallowed the Systemd Cabal's claims about how they were the first to do this, that, or the other. I feel like you have very strong emotions about init systems that have nothing to do with the comment you're replying to.
  - 3y ago

marcosdumay 3y ago

As long as Gnome requires bug-compatibility with systemd, nobody will rewrite it.

quotemstr 3y ago

> One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity. Complexity that would otherwise be distributed to a sea of ad-hoc shell scripts? systemd is a win

Repulsion9513 3y ago
The init-scripts that predated systemd were actually pretty damn simple. So was init itself.
- adql 3y ago
  We removed tens of thousands of lines of code for fixes for those "simple" init scripts when migrating to systemd. They are never "simple", there is always some fucking edge case, like for example we had Java apps writing its own PID few seconds after start. So any app that did start and immediately after status (like Pacemaker) threw errors. Or how once in blue moon MySQL didn't start after reboot because it so happened that: * the PID file from previous boot wasn't cleared * some other app ran with same PID as it was in file * Script did not care, script saw pid file existing and didn't start MySQL. Both examples from pre-systemd CentOS