Devuan is the outlet of a bunch of people that don’t want Linux to evolve, become better and have more flexibility because it violates the UNIX philosophy and/or it is backed by big corp. Systemd was made to tackle a bunch of issues with poorly integrated tools and old architectures that aren’t as good as they used to be. If you look at other operating systems, even Apple has a better service manager (launchd).
Systemd is incredibly versatile and most people are unaware of its full potential. Apart from the obvious - start services - it can also run most of a base system with features such as networking (IPv4+IPV6, PBR), NTP, Timers (cron replacement), secure DNS resolutions, isolate processes, setup basic firewalls, port forwarding, centralize logging (in an easy way to query and read), monitor and restart services, detect hardware changes and react to them, mount filesystems, listen for connections in sockets and launch programs to handle incoming data, become your bootloader and… even run full fledged containers both privileged and non-privileged containers. Read this for more details: https://tadeubento.com/2023/systemd-hidden-gems-for-a-better-linux/
The question isn’t “what is the benefit of removing this init system”, it is “what I’ll be missing if I remove it”. Although it is possible to do all the above without Systemd, you’ll end up with a lot of small integration pains and dozens of processes and different tools all wasting resources.
What worries me about the “systemd does everything as a tightly integrated package” is the too-big-to-fail aspect. I’d be worried that we’re seeing a lot of configurations that can’t be pulled apart piecemeal-- for example, if you need a feature not available in systemd, or you need to deactivate a systemd component due to an unfixed vulnerability. It feels like there’s value in supporting a non-systemd init in the same way there’s value for individual packages to support an architecture beyond x86-64-- you get some extra checks that you aren’t making assumptions that only work for a specific happy path.
The problem of not having systemd is the mess what’ve seen before. It doesn’t make sense to have 200 different services to be able to have usable dual-stack networking. Furthermore Init and Cron are aging, having everything based on bash scripts doesn’t cut it anymore - they don’t scale, you can’t monitor and audit things properly and worse it creates a dependency on some very specific shell.
What worries me about the “systemd does everything as a tightly integrated package” is the too-big-to-fail aspect.
It’s been the default for ~10 years and it hasn’t been an issue yet… Even if it did “fail” the solution would never be to roll an entirely different init system. That would be absurd. If there is a bug, it gets patched.
I’d be worried that we’re seeing a lot of configurations that can’t be pulled apart piecemeal-- for example, if you need a feature not available in systemd
You can run services independently of systemd. There is no reason you couldn’t have whatever feature you want and systemd at the same time.
you need to deactivate a systemd component due to an unfixed vulnerability.
When vulnerabilities are discovered there is disclosure to maintainers, a patch is released, and then an announcement is made publicly with the instructions on how to fix the problem. I’ve never seen an instance where the industry collectively says “There’s a vulnerability here but we aren’t going to fix it. Good luck!” Especially for such an important layer of the stack… There’s no way that is going to happen.
Yeah, I just have a question about that community. Debian maintainers told them they were open to a multi init architecture (as in have Debian support both systemd and init) as long as they maintained it, they just rumbled around and decided to fork Debian instead. This is the kind of people we’re dealing with.
The philosophical arguments are pretty garbage. I generally want to know if the “it violates the UNIX philosophy” people use browser extensions… That violates the UNIX philosophy too. Systemd “is backed by big corp” but who do you think is actually contributing time/effort/code to the Linux kernel? It’s the device manufacturers who are trying to get you to buy their products… So that fails too.
No offense to anyone reading this but if you’re really passionately anti-systemd, I would not hire you. This is a dumb hill to die on and a red flag.
Devuan is the outlet of a bunch of people that don’t want Linux to evolve, become better and have more flexibility because it violates the UNIX philosophy and/or it is backed by big corp. Systemd was made to tackle a bunch of issues with poorly integrated tools and old architectures that aren’t as good as they used to be. If you look at other operating systems, even Apple has a better service manager (launchd).
Systemd is incredibly versatile and most people are unaware of its full potential. Apart from the obvious - start services - it can also run most of a base system with features such as networking (IPv4+IPV6, PBR), NTP, Timers (cron replacement), secure DNS resolutions, isolate processes, setup basic firewalls, port forwarding, centralize logging (in an easy way to query and read), monitor and restart services, detect hardware changes and react to them, mount filesystems, listen for connections in sockets and launch programs to handle incoming data, become your bootloader and… even run full fledged containers both privileged and non-privileged containers. Read this for more details: https://tadeubento.com/2023/systemd-hidden-gems-for-a-better-linux/
The question isn’t “what is the benefit of removing this init system”, it is “what I’ll be missing if I remove it”. Although it is possible to do all the above without Systemd, you’ll end up with a lot of small integration pains and dozens of processes and different tools all wasting resources.
What worries me about the “systemd does everything as a tightly integrated package” is the too-big-to-fail aspect. I’d be worried that we’re seeing a lot of configurations that can’t be pulled apart piecemeal-- for example, if you need a feature not available in systemd, or you need to deactivate a systemd component due to an unfixed vulnerability. It feels like there’s value in supporting a non-systemd init in the same way there’s value for individual packages to support an architecture beyond x86-64-- you get some extra checks that you aren’t making assumptions that only work for a specific happy path.
The problem of not having systemd is the mess what’ve seen before. It doesn’t make sense to have 200 different services to be able to have usable dual-stack networking. Furthermore Init and Cron are aging, having everything based on bash scripts doesn’t cut it anymore - they don’t scale, you can’t monitor and audit things properly and worse it creates a dependency on some very specific shell.
It’s been the default for ~10 years and it hasn’t been an issue yet… Even if it did “fail” the solution would never be to roll an entirely different init system. That would be absurd. If there is a bug, it gets patched.
You can run services independently of systemd. There is no reason you couldn’t have whatever feature you want and systemd at the same time.
When vulnerabilities are discovered there is disclosure to maintainers, a patch is released, and then an announcement is made publicly with the instructions on how to fix the problem. I’ve never seen an instance where the industry collectively says “There’s a vulnerability here but we aren’t going to fix it. Good luck!” Especially for such an important layer of the stack… There’s no way that is going to happen.
Devuan community is a cesspool indeed. However, I cannot deny the validity on some of their argument, namely about having alternatives.
Yeah, I just have a question about that community. Debian maintainers told them they were open to a multi init architecture (as in have Debian support both systemd and init) as long as they maintained it, they just rumbled around and decided to fork Debian instead. This is the kind of people we’re dealing with.
Indeed wasted potential. Debian could’ve welcomed them with open arms had they participated in the Init divesity discussion.
That’s the problem, Debian did welcome them with open arms… they decided to left and fork.
Exactly this.
The philosophical arguments are pretty garbage. I generally want to know if the “it violates the UNIX philosophy” people use browser extensions… That violates the UNIX philosophy too. Systemd “is backed by big corp” but who do you think is actually contributing time/effort/code to the Linux kernel? It’s the device manufacturers who are trying to get you to buy their products… So that fails too.
No offense to anyone reading this but if you’re really passionately anti-systemd, I would not hire you. This is a dumb hill to die on and a red flag.
Exactly bigncorp is doing the majority of the Linux kernel development. Wonder why nobody complains about that.
Maybe you should hire me then?