4 ms·

I personally love the init/service/unit-file portion of systemd and have few complaints. It has a lot of powerful features for security, cron, etc that are very

by pram 1y ago

I personally love the init/service/unit-file portion of systemd and have few complaints. It has a lot of powerful features for security, cron, etc that are very simple to use. I also really like journald. The parts I don’t really like are the half baked “ancillary” managers like resolvd, which are frankly baffling to use and tend to make simple things needlessly difficult.

thyristan 1y ago
And those ancillary managers are usually half-baked or outright broken and dangerous, in that they only implement half of the stuff they are trying to replace. E.g. https://github.com/systemd/systemd/issues/25676 https://github.com/systemd/systemd/issues/25676
bryanlarsen 1y ago
Hard disagree. Name resolution feels like a solved problem, so why fix it if it isn't broken? But that's just like the old init & logging systems. They mostly worked, and yes it was annoying to relearn a new way of doing things. But the new way is better. I've got software that works with resolvconf, NetworkManager and resolved. I definitely prefer resolved. Yes, the cost of switching likely exceeds the benefits for you, and likely for many greybeards. But for those in complicated situations, and for the next generation of sysadmins who never have to learn the old way, resolved is nice.
- msgodel 1y ago
  I think even for new people the systemd configs are much more complex (and the APIs are certainly much more complex) than the libc ones which worked well (often better.) The problem is that almost nothing in Systemd shares theory with the rest of the OS. It's entirely its own island of new ideas, commands, and configuration language that you have to learn and memorize.
- const_cast 1y ago
  The older init systems were incredibly frail and often did not work. The reason is because Bash, as much as we all love it, is actually super mega ass. It's very bug-prone and actually one of the least portable languages ever invented, in practice. Because you can't, or shouldn't, call to any other binary from within Bash, otherwise you risk your portability. Now your script won't work the same on other platforms, or even the same platform with slightly different configuration. But um... yeah... calling to other binaries is the entire ethos of Bash. It's a shell, that's supposed to be all it does. Even getting a "true" value should be a call to another binary. Unit files, despite being a bespoke format for one singular program, are actually more portable. Like, WAY more portable.

by pram 1y ago

thyristan 1y ago

And those ancillary managers are usually half-baked or outright broken and dangerous, in that they only implement half of the stuff they are trying to replace. E.g. https://github.com/systemd/systemd/issues/25676 https://github.com/systemd/systemd/issues/25676

bryanlarsen 1y ago

Hard disagree. Name resolution feels like a solved problem, so why fix it if it isn't broken? But that's just like the old init & logging systems. They mostly worked, and yes it was annoying to relearn a new way of doing things. But the new way is better. I've got software that works with resolvconf, NetworkManager and resolved. I definitely prefer resolved. Yes, the cost of switching likely exceeds the benefits for you, and likely for many greybeards. But for those in complicated situations, and for the next generation of sysadmins who never have to learn the old way, resolved is nice.

msgodel 1y ago
I think even for new people the systemd configs are much more complex (and the APIs are certainly much more complex) than the libc ones which worked well (often better.) The problem is that almost nothing in Systemd shares theory with the rest of the OS. It's entirely its own island of new ideas, commands, and configuration language that you have to learn and memorize.
const_cast 1y ago
The older init systems were incredibly frail and often did not work. The reason is because Bash, as much as we all love it, is actually super mega ass. It's very bug-prone and actually one of the least portable languages ever invented, in practice. Because you can't, or shouldn't, call to any other binary from within Bash, otherwise you risk your portability. Now your script won't work the same on other platforms, or even the same platform with slightly different configuration. But um... yeah... calling to other binaries is the entire ethos of Bash. It's a shell, that's supposed to be all it does. Even getting a "true" value should be a call to another binary. Unit files, despite being a bespoke format for one singular program, are actually more portable. Like, WAY more portable.