No, it's terrible. I think what they mean by "success" here is that it functions, and is easier to use and more sturdy than init scripts. But any number of things would have been better than those. Instead of writing and adopting one or more, Linux allowed Redhat to take over the last piece of itself, its spine, after which Redhat sold itself to IBM. Linux is an IBM product.
They basically mediate all Linux access to the hardware, and can add arbitrary dependencies to the system at will. They could decide that we're all going to use leftpad now.
Cutting off my hand to get rid of that cancerous mole might have saved my life, but I wish you had just cut off the mole.
> Instead of writing and adopting one or more, Linux allowed Redhat to take over the last piece of itself, its spine, after which Redhat sold itself to IBM. Linux is an IBM product.
Who exactly was going to write the systemd alternative? If by "Linux" you mean the kernel devs, that was never going to happen-- systemd is a middleware stack living in userspace, the kernel guys were never going to get involved. If you mean some distro, other distros did propose some alternatives to systemd back in the day (e.g. upstart), and they all eventually abandoned them and switched to systemd instead, because systemd was better.
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 consuming them.
The problem with systemd is that, because of all the new userspace APIs it adds, we can't just agree to disagree. You either target a Systemd OS and the users get to suffer non-trivial, often broken, configs or you target a normal GNU/Linux OS and the systemd users suffer all kinds of surprises when systemd rug pulls them.
# 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-complete shell scripts as configuration. Hard pass.
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?
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
>Who exactly was going to write the systemd alternative?
And that quote proves 100% what is wrong with Linux these days.
In the 90s, if someone posted in USENET they want init to do X, at least 2 different solutions would appear with in a week, probably many more.
That happened to me when I went from Coherent OS to Slackware in the early 90s. I asked if there was a way to have virtual consoles on my VGA monitor and my B&W Hercules monitor (386sx), or to have at least 1 VC on the Hercules. Coherent 486 supported that, Linux did not. A post appeared in a couple of days with a patch.
Now, between the Linux Foundation and the Companies that owns it, that would never happen. People who have gotten into Linux in the last 20 years cannot imagine how responsive the developers were to user requests back then.
Seems these days we are dealing with some corporate behemoth drowning in red tape.
They basically mediate all Linux access to the hardware, and can add arbitrary dependencies to the system at will. They could decide that we're all going to use leftpad now.
Cutting off my hand to get rid of that cancerous mole might have saved my life, but I wish you had just cut off the mole.