3 ms·

Almost all software bugs come from managing state. Which is why hoarding state management in PID 0 is a dumb idea. I said this when systemd was gaining traction

Almost all software bugs come from managing state. Which is why hoarding state management in PID 0 is a dumb idea. I said this when systemd was gaining traction and I'm still saying it now. When Debian switched to systemd in the default was when I began to seriously use OpenBSD and I've never regretted the decision.

bitwize 4y ago
> Which is why hoarding state management in PID 0 is a dumb idea. Because the Unix process API is unreliable and unsafe ( http://catern.com/process.html http://catern.com/process.html ), managing processes is difficult to impossible in a general way under Unix systems including Linux. Linux gained some features to help with this, but for the longest time, PID 1 was the only process that could manage its child processes in a way that wasn't fraught with race conditions -- meaning systemd or something like it was the only way to have safe, effective process management because it tracked all that state in PID 1. Blame Unix being broken, not systemd, for the problems systemd solves.
kaba0 4y ago
Because the litany of shittily written bash scripts don’t hoard state, or what exactly are you saying? The only thing I dislike about systemd is that it is written in C, but otherwise it is a single purpose solution to the surprisingly complex problem of managing services during boot and running. I fail to see how state is relevant here — if it were written in Haskell it would also have state, almost by definition it has to handle external state. No Monad would help you there, there is just correct and not correct software.
- kasabali 4y ago
  > single purpose solution You can't be saying this with a straight face. systemd project subsumes functionality of - device hotplug - user session manager - cron - logging - network management - time zone management - time sync - cgroup manager - deleting /tmp files - DNS resolver - UEFI boot manager and also dozen other things I've forgotten.
  - kaba0 4y ago
    You do realize that there is a systemd project and a systemd program. Is the plasma5 shell bloated because under the KDE umbrella there are hundreds of other projects?

bitwize 4y ago

> Which is why hoarding state management in PID 0 is a dumb idea. Because the Unix process API is unreliable and unsafe ( http://catern.com/process.html http://catern.com/process.html ), managing processes is difficult to impossible in a general way under Unix systems including Linux. Linux gained some features to help with this, but for the longest time, PID 1 was the only process that could manage its child processes in a way that wasn't fraught with race conditions -- meaning systemd or something like it was the only way to have safe, effective process management because it tracked all that state in PID 1. Blame Unix being broken, not systemd, for the problems systemd solves.

kaba0 4y ago

Because the litany of shittily written bash scripts don’t hoard state, or what exactly are you saying? The only thing I dislike about systemd is that it is written in C, but otherwise it is a single purpose solution to the surprisingly complex problem of managing services during boot and running. I fail to see how state is relevant here — if it were written in Haskell it would also have state, almost by definition it has to handle external state. No Monad would help you there, there is just correct and not correct software.

kasabali 4y ago
> single purpose solution You can't be saying this with a straight face. systemd project subsumes functionality of - device hotplug - user session manager - cron - logging - network management - time zone management - time sync - cgroup manager - deleting /tmp files - DNS resolver - UEFI boot manager and also dozen other things I've forgotten.
- kaba0 4y ago
  You do realize that there is a systemd project and a systemd program. Is the plasma5 shell bloated because under the KDE umbrella there are hundreds of other projects?