6 ms·

It certainly sounds crazy, compared to the maybe 10KB of init.d scripts on a typical older Unix system. Yeah, I realize that isn't quite apples-to-apples, but

It certainly sounds crazy, compared to the maybe 10KB of init.d scripts on a typical older Unix system. Yeah, I realize that isn't quite apples-to-apples, but still, systemd is a ridiculous beast. We used to mock Windows for this sort of thing, and now we've become them.

m463 6y ago
I think at this point, the systemd mess is an opportunity. Write a better one. "Be the change that you wish to see in the world."- Gandhi (maybe)
- dTal 6y ago
  There are already better ones. The problem is more social than technical. I'm using Void Linux with runit and it's simple and functional; I've never once missed systemd. And the BSDs all manage fine without it as well.
  - vlovich123 6y ago
    > runit employs a concept of a service directory, responsible for an individual service, which is a process to monitor and an optional log service Hey look at that. The critique that systemd has a log daemon (why does init need a log daemon?) doesn't really fly. Also runit doesn't have the ability as I understand it to properly specify dependencies between components falling back to the crap of runlevels. You won't see it as a user. You see it consistently & repeatedly as an OS developer/maintainer & through slow boot times. Then you have upstart which has some dependency & parallelization effort. The fundamental architectural flip that systemd takes is, as I understand it, that each service/process starts as needed & just blocks on I/O letting the kernel manage parallelism implicitly through synchronization mechanisms that are robust & easy to maintain rather than manual config files. There's a lot of complexity here. There's name discovery & registration so that when you have a dependency on you, you automatically start whenever a dependency tries to access you. The logging mechanism is because you want to make sure that logging is robust & functional. The binary mechanism is great because it drastically shrinks the size of the log files, reduces the overhead (printf format strings are expensive), & makes it easier to write tools to process them. I'm not sure about the DNS & other binaries but I'm sure there are similar intrinsic architectural problems those tools are solving. Again, none of these are necessarily ones you see as an end user directly. You see it indirectly because a lot of diffuse time is spent finding/fixing bugs due that architecture (yes there are still bugs but they're of a different flavor, and, hopefully, bugs you'd have in either system. BTW when I last looked at systemd, superficially it looked very very similar to launchctl in terms of design with many of the same benefits.
- zozbot234 6y ago
  It's not that trivial to "write a better one" while broadly keeping the behavior and desirable features that systemd proponents have come to want. It will have to happen at some point, because the sheer amount of incidental complexity in systemd is quite unsustainable - but a lot of hard, fundamental work will be necessary.
SahAssar 6y ago
Considering the functionality systemd provides shouldn't we include the line counts for dnsmasq, syslog-ng, netctl, dhcpcd, podman, cronie, dbus-broker, supervisor and a few others too? I get that not all people want to use the whole systemd family of tools, but comparing line counts like this is ridiculous and unproductive.
vlovich123 6y ago
So wait. You're saying a 5x increase in the amount of code that solves in a broader range of problems than just those init scripts, that doesn't seem ridiculous to me. What's the size of just the initd piece? Systemd is also significantly faster than the old init.d scripts to boot. Not sure how well it outperforms upstart & haven't been able to find those details.
- downerending 6y ago
  My math says 60x increase, which is a lot considering that the liability of each added source line is superlinear. And it's also a lot considering that most (?) of those lines of source are compiled into a single inscrutable binary. One of the great boons of init.d shell scripts is that you can just look at them when something is going wrong, and quickly realize that they have a bug. If something's wrong with a unit file (and/or systemd itself) it can be extremely difficult to debug. The unit file for a reasonably common piece of software (ganglia) is broken, and apparently still is after years. I've no real idea of how to debug this, and certainly don't have time to fuck with it. At least in this regard, systemd sucks.
  - vlovich123 6y ago
    Whoops. My bad with the math. systemd is a bunch of purpose-built libraries though so I don't follow your reasoning. In fact, by comparison you should have more of a problem with the Linux kernel - 28 million lines of code in largely a single executable. The init binary of systemd itself is ~70k if my math is correct & still has a much richer feature set. I don't know what init.d shell scripts you've been looking at but my experience has not been as pleasant. Also, if you as an end user are looking at init scripts there's something massively wrong with the init system. Never heard of Ganglia but they seem to be on github. Have you filed a ticket with them? Have you messaged them on whatever forum/IRC the devs hang out on with your issue?
    - downerending 6y ago
      There's a good reason why the kernel is a single "binary". It's far less clear why the init system needs to be, especially since it wasn't for decades. Yeah, I'm not crazy about the various init scripts that have been produced over the years. But at least when they're broken, I can usually just glance at them and see that. With systemd, mostly one just gives up.

m463 6y ago

I think at this point, the systemd mess is an opportunity. Write a better one. "Be the change that you wish to see in the world."- Gandhi (maybe)

dTal 6y ago
There are already better ones. The problem is more social than technical. I'm using Void Linux with runit and it's simple and functional; I've never once missed systemd. And the BSDs all manage fine without it as well.
- vlovich123 6y ago
  > runit employs a concept of a service directory, responsible for an individual service, which is a process to monitor and an optional log service Hey look at that. The critique that systemd has a log daemon (why does init need a log daemon?) doesn't really fly. Also runit doesn't have the ability as I understand it to properly specify dependencies between components falling back to the crap of runlevels. You won't see it as a user. You see it consistently & repeatedly as an OS developer/maintainer & through slow boot times. Then you have upstart which has some dependency & parallelization effort. The fundamental architectural flip that systemd takes is, as I understand it, that each service/process starts as needed & just blocks on I/O letting the kernel manage parallelism implicitly through synchronization mechanisms that are robust & easy to maintain rather than manual config files. There's a lot of complexity here. There's name discovery & registration so that when you have a dependency on you, you automatically start whenever a dependency tries to access you. The logging mechanism is because you want to make sure that logging is robust & functional. The binary mechanism is great because it drastically shrinks the size of the log files, reduces the overhead (printf format strings are expensive), & makes it easier to write tools to process them. I'm not sure about the DNS & other binaries but I'm sure there are similar intrinsic architectural problems those tools are solving. Again, none of these are necessarily ones you see as an end user directly. You see it indirectly because a lot of diffuse time is spent finding/fixing bugs due that architecture (yes there are still bugs but they're of a different flavor, and, hopefully, bugs you'd have in either system. BTW when I last looked at systemd, superficially it looked very very similar to launchctl in terms of design with many of the same benefits.
zozbot234 6y ago
It's not that trivial to "write a better one" while broadly keeping the behavior and desirable features that systemd proponents have come to want. It will have to happen at some point, because the sheer amount of incidental complexity in systemd is quite unsustainable - but a lot of hard, fundamental work will be necessary.

SahAssar 6y ago

Considering the functionality systemd provides shouldn't we include the line counts for dnsmasq, syslog-ng, netctl, dhcpcd, podman, cronie, dbus-broker, supervisor and a few others too? I get that not all people want to use the whole systemd family of tools, but comparing line counts like this is ridiculous and unproductive.

vlovich123 6y ago

So wait. You're saying a 5x increase in the amount of code that solves in a broader range of problems than just those init scripts, that doesn't seem ridiculous to me. What's the size of just the initd piece? Systemd is also significantly faster than the old init.d scripts to boot. Not sure how well it outperforms upstart & haven't been able to find those details.

downerending 6y ago
My math says 60x increase, which is a lot considering that the liability of each added source line is superlinear. And it's also a lot considering that most (?) of those lines of source are compiled into a single inscrutable binary. One of the great boons of init.d shell scripts is that you can just look at them when something is going wrong, and quickly realize that they have a bug. If something's wrong with a unit file (and/or systemd itself) it can be extremely difficult to debug. The unit file for a reasonably common piece of software (ganglia) is broken, and apparently still is after years. I've no real idea of how to debug this, and certainly don't have time to fuck with it. At least in this regard, systemd sucks.
- vlovich123 6y ago
  Whoops. My bad with the math. systemd is a bunch of purpose-built libraries though so I don't follow your reasoning. In fact, by comparison you should have more of a problem with the Linux kernel - 28 million lines of code in largely a single executable. The init binary of systemd itself is ~70k if my math is correct & still has a much richer feature set. I don't know what init.d shell scripts you've been looking at but my experience has not been as pleasant. Also, if you as an end user are looking at init scripts there's something massively wrong with the init system. Never heard of Ganglia but they seem to be on github. Have you filed a ticket with them? Have you messaged them on whatever forum/IRC the devs hang out on with your issue?
  - downerending 6y ago
    There's a good reason why the kernel is a single "binary". It's far less clear why the init system needs to be, especially since it wasn't for decades. Yeah, I'm not crazy about the various init scripts that have been produced over the years. But at least when they're broken, I can usually just glance at them and see that. With systemd, mostly one just gives up.