3 ms·

I think this discussion thread is basically people looking at this in different contexts. A lot of the replies seem to interpret your post as saying "systemd is

I think this discussion thread is basically people looking at this in different contexts. A lot of the replies seem to interpret your post as saying "systemd is more complicated than sysvinit was" which is most definitely not what you meant regarding your further replies in this thread. You seem to say "even systemd is too complicated for the layperson". I somewhat agree, if we assume someone totally not dealing with tech in any way on a daily basis, except for typical Office work. But the "in-betweeners"? They totally could. Like, not even Linux users, but curious tinkerers that fiddle aound with .ini files and registry settings to tweak their machines; do overclocking? They totally have what it takes to chew through a tutorial that tells you how to set up a Linux VPS with a couple services running. For the layperson that's a bus driver by day, not so much, most definitely, but I think no matter how simple you make setting this up, just having to maintain this and having to do something when the setup eventually has some unexpected bug a few years down the line is just too much.

jethro_tell 5y ago
To be fair, a bus driver probably isn't writing a self-hosted service anyway. So if there is an issue with the service init 3 years later, they will probably file a bug and let the maintainer handle it. And they wouldn't be parsing a bash script for a sysV-init if that broke either? SysV-init was to complex for the layman as well. Because gracefully starting and stopping system services with their dependency chains is generally too complex for the layman as well. There's this strange idea that laymen self-hosters are doing all this stuff and the choice of init system matters in the lease. They were going to run the command to start the service blindly regardless of which init system it was and if it breaks, they aren't going to really troubleshoot either one.
- fps_doug 5y ago
  Sure, the bus driver was supposed to represent the other extreme. In reality, they probably wouldn't care no matter how simple the setup is. But the at-least-somewhat-curious non-tech person has probably better chances finding a problem with a systemd service than a sysvinit script, even if they just open a ticket in the end. The info they can provide is more likely to be useful with systemd, I'd argue.
  - jethro_tell 5y ago
    For the record, I'm a big systemd fan. But to a user, taking a debug log is more or less the same either way. They don't care.

jethro_tell 5y ago

To be fair, a bus driver probably isn't writing a self-hosted service anyway. So if there is an issue with the service init 3 years later, they will probably file a bug and let the maintainer handle it. And they wouldn't be parsing a bash script for a sysV-init if that broke either? SysV-init was to complex for the layman as well. Because gracefully starting and stopping system services with their dependency chains is generally too complex for the layman as well. There's this strange idea that laymen self-hosters are doing all this stuff and the choice of init system matters in the lease. They were going to run the command to start the service blindly regardless of which init system it was and if it breaks, they aren't going to really troubleshoot either one.

fps_doug 5y ago
Sure, the bus driver was supposed to represent the other extreme. In reality, they probably wouldn't care no matter how simple the setup is. But the at-least-somewhat-curious non-tech person has probably better chances finding a problem with a systemd service than a sysvinit script, even if they just open a ticket in the end. The info they can provide is more likely to be useful with systemd, I'd argue.
- jethro_tell 5y ago
  For the record, I'm a big systemd fan. But to a user, taking a debug log is more or less the same either way. They don't care.