Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd has been a complete, utter, unmitigated success

blog.tjll.net

Post reply on HN
Print view View original

111–114 of 114 posts

Re: Systemd has been a complete, utter, unmitigated success

#111

Post by navi-desu »

akdev1l wrote: post #61
msgodel wrote: post #59

Earlier quoted context omitted.

OpenRC is great, there's just no flashy marketing behind it or team of consultants pushing it. EDIT: Heh. At least I can debug a shell script, I can't debug a config file. I think this is a fundamental disagreement many people have in what's ultimately desirable when designing software. I personally can't stand non-trivial config files and both at work and at home have wasted way too much time pulling apart software…

#!/sbin/openrc-run depend() { need net } # Export some ENVs for it export SERVER_ADDRESS="0.0.0.0:8088" name="my-program" description="My program" command="/usr/local/bin/my-program" # If it does not know how to background iself command_background=true pidfile="/run/${RC_SVCNAME}.pid" # To have logs output_log="/var/log/${RC_SVCNAME}.log" error_log="/var/log/${RC_SVCNAME}.err" It seems that it still uses Turing-compl…

what is... actually wrong with that?

it works, it's extensible, and a simple service is just as declarative as systemd, but when you need to do something more complex (e.g. checking conditions before starting), you don't need to create a separate script to do so or pile up 10 ExecStartPre lines, just `start_pre() { ... }` away

i've seen people again and again complain of "but shell scripts", while the default functions provide an interface with declarative variables right there, what is the actual issue with it?

Re: Systemd has been a complete, utter, unmitigated success

#112

Post by navi-desu »

plqbfbv wrote: post #98
vinceguidry wrote: post #96

Earlier quoted context omitted.

I don't fucking hate systemd. I'm marginally glad it exists. I just don't want to live under it's despotic regime. You might like it because you think trains running on time is more important than freedom. You're the one coming at me with fucking attitude, like a 16 year old who just discovered IntelliJ. I have done the exploration, then looked online for why everything is so damn complicated now. It's because system…

> It's not just an init system, it's everything below the userland. And a lot of those components are very poorly designed. And it's this big ball of mush where if you use one component, thy must use them all. It's so bad Arch does not support replacing systemd, like at all. You're totally on your own. It's true, it's not only an init system anymore, it's also a service manager, a network manager, a DNS cache and res…

> OpenRC still requires you to manually enable support for service auto-restart ( https://wiki.gentoo.org/wiki/OpenRC/supervise-daemon#General... ), a feature that comes built-in in systemd and without extra complexity or components, and with predictable outcomes given the unit file

fwiw it's being worked on to have supervision as the default in openrc as well

Re: Systemd has been a complete, utter, unmitigated success

#113

Post by akdev1l »

navi-desu wrote: post #111
akdev1l wrote: post #61

Earlier quoted context omitted.

#!/sbin/openrc-run depend() { need net } # Export some ENVs for it export SERVER_ADDRESS="0.0.0.0:8088" name="my-program" description="My program" command="/usr/local/bin/my-program" # If it does not know how to background iself command_background=true pidfile="/run/${RC_SVCNAME}.pid" # To have logs output_log="/var/log/${RC_SVCNAME}.log" error_log="/var/log/${RC_SVCNAME}.err" It seems that it still uses Turing-compl…

what is... actually wrong with that? it works, it's extensible, and a simple service is just as declarative as systemd, but when you need to do something more complex (e.g. checking conditions before starting), you don't need to create a separate script to do so or pile up 10 ExecStartPre lines, just `start_pre() { ... }` away i've seen people again and again complain of "but shell scripts", while the default functio…

That it is a Turing complete language and now people can add all sorts of crazy logic

I don’t want to have to evaluate a shell script to figure out how a system service is supposed to start

Re: Systemd has been a complete, utter, unmitigated success

#114

Post by navi-desu »

akdev1l wrote: post #113
navi-desu wrote: post #111

Earlier quoted context omitted.

what is... actually wrong with that? it works, it's extensible, and a simple service is just as declarative as systemd, but when you need to do something more complex (e.g. checking conditions before starting), you don't need to create a separate script to do so or pile up 10 ExecStartPre lines, just `start_pre() { ... }` away i've seen people again and again complain of "but shell scripts", while the default functio…

That it is a Turing complete language and now people can add all sorts of crazy logic I don’t want to have to evaluate a shell script to figure out how a system service is supposed to start

and how is that any different from system services doing `ExecStartPre=/usr/libexec/my_setup_script.sh`? or worse, 20 different `ExecStartPre` lines that basically build a shell script in the ini file, one line at a time

services are not simply a set of knobs to start a single process, often they don't even have processes (e.g. wg-quick)

and even when they do, it often involves setup, and sometimes cleanup.

systemd has to provide the exact same functionality, even if they put a .ini-paint of coat in it -- the difference is that openrc doesn't make services install N helpers scripts for that. Really, "Not being turing complete" is a useless metric for "stopping complexity in init setups"

the way you stop complexity is by giving pre-configured functionality that is easy to use. systemd did that very well, openrc does do that for a lot of things already, and we're adding more as we see the common need of init scripts for said features

Post reply on HN