Like what if you don't mind me asking, and what did people used to use as an alternative?
Also upstart, which was actually pretty good, but systemd was more ambitious.
Additionally Upstart was not good. It has some good ideas but its approach to dependencies was generally regarded as unintuitive. Writing services in systemd is much more obvious than writing for Upstart.
There is strange false history that systemd replaced sysvinit, which occurred only on Debian, because Debian was the last major system to discard sysvinit.
Gentoo had replaced sysvinit with OpenRC in 2006; Fedora and Ubuntu were using Upstart in 2005. systemd primarily replaced Upstart and systems that used Runit or OpenRC tended to have stayed with them.
Frankness be, this false history seems to be crafted in order to compare it with very outdated technology to make it look good. Obviously systemd is better than sysvinit, technology that almost all systems but Debian had discarded long before systemd was even started. The issue is whether it compares favorably to Upstart, runit, and OpenRC, and to the first I would say yes, because Upstart was full of very ugly hacks and didn't deliver it's ambition. In the second two cases, their mode of operation is so different that it's hard to compare. runit was inspired by daemontools and is very simple and effective and works in a very different way from most models of service management; OpenRC is backwards compatible with sysvinit and is essentially a large library so that init scripts typically need nothing more than something such as:
#!/sbin/openrc-run
command=sshd
args="-D"
daemon=no
provides=ssh
after=net
But on the desktop I use FreeBSD which has a different system again.
By the way alpine is also working on a full service manager init system (like systemd) but more minimalistic, based on s6 service manager. Looking forward to seeing how that pans out.
https://skarnet.com/projects/service-manager.html
When something comes from the alpine team I have a much higher confidence that I'll like it than from RedHat :) I don't care for Gnome either as it has become so opinionated.
This is partially incorrect and partially misleading.
Incorrect in that openSUSE and Arch are major distros and migrated from sysvinit to systemd.
https://news.opensuse.org/2011/12/22/systemd-e2-80-93-boot-f...
https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...
Misleading in that Ubuntu and Fedora did use Upstart but not in its native mode, they used it in its sysvinit compatibility mode. This is almost identical to sysvinit, so from the point of view of a user or a package maintainer it was functionally barely distinguishable from sysvinit.
OpenRC was considered by Debian, but 7 out of 8 members of the technical committee preferred both systemd and Upstart to OpenRC (Ian Jackson preferred sysvinit over OpenRC and "further discussion" over every other option).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708;msg...
At 82k loc it's huge for what it does, but nonetheless is order(s?) of magnitude smaller than systemd. If it was active I'd trust it more that systemd on that basis alone.
I can't say I'm a fan of systemd's event driven approach. A system whose state depends on it's configuration plus past state is usually a nightmare to debug and control compared to a system who state is dependent on it's configuration alone - and that's how it has worked out for me and systemd.
The simple cases work fine of course but systemd's power over what came before it is it's dependency relationships it allows you setup. But they are the very things that break in weird and wonderful ways when the events it's reacting to fire in an unexpected order. If you could set them up reliably without much thinking it would be a big win - but as it is, not so much.
OpenSUSE also had upstart in the meanwhile but continued to support sysvinit as an alternative.
Arch Linux had sysvinit as it's pid1, but it's big sell initially was that, similar to Crux, it had a custom BSD-style init script setup and did not use sysvinit's booting and rc mechanism.
OpenRC systems typically also continue to use sysvinit's pid1 to this day, which is not the complaint people have with it but the impossible to understand script sand lack of dependency management of it's service management because it was never meant to do service management which was a bit of a hack.
> Misleading in that Ubuntu and Fedora did use Upstart but not in its native mode, they used it in its sysvinit compatibility mode. This is almost identical to sysvinit, so from the point of view of a user or a package maintainer it was functionally barely distinguishable from sysvinit.
There is no such compatibility mode as far as I know. A big sell of Upstart and OpenRC was always that it was backwards compatible with old-style sysvinit-style scripts even though new ones were written in the new style. There is no global mode as far as I know but no doubt many of the olds scripts remained.
> OpenRC was considered by Debian, but 7 out of 8 members of the technical committee preferred both systemd and Upstart to OpenRC (Ian Jackson preferred sysvinit over OpenRC and "further discussion" over every other option).
That would not surprise me. It's not what Debian is looking for.
I wasn't aware of that ... it turns out that it was the other way around: openSUSE 11.3 has this item, implying it's not the default:
"Upstart is included as optional init system"
https://en.opensuse.org/Archive:Product_highlights_11.3
openSUSE 11.4 then mentions systemd, although "experimental".
https://en.opensuse.org/Archive:Product_highlights_11.4
openSUSE 12.1 defaults to systemd (see previous comment), with sysvinit as non-default option.
So Upstart was a short-lived non-default option.
> A big sell of Upstart and OpenRC was always that it was backwards compatible with old-style sysvinit-style scripts even though new ones were written in the new style.
You are right that there are no distinct modes as such, my memory is quite fuzzy as it's been some years, and I wouldn't rely on anything I say. And it looks like Ubuntu (unlike Fedora) did replace a lot of init.d scripts with native Upstart jobs.
https://launchpad.net/ubuntu/+spec/replacement-initscripts
I can't remember what the problem was with mixing init.d scripts and native Upstart jobs, or what impact it had, maybe it was not important in practice.
The Debian wiki has this item, but, well, it's a Wiki, so perhaps it's not the most reliable source.
Can't set proper dependencies until everything has converted from SysV init files to Upstart jobs.
I would add S6 to the list, as this would be the better challenger to systemd. That said, I use OpenRC daily on Alpine servers with little to complain about.
The previous gentoo init system was already better than sysvinit and initscripts.
I still prefer and use systemd though.
And why wouldn't you compare it with the systems it actually competes against and replaces rather than against something that was barely used any more before systemd even stated development? The comparison with sysvinit, suggesting that those that do not use systemd advocate sysvinit instead, is simply a flagrant straw-man designed to make systemd look good.
So the year you're looking for isn't when OpenRC was introduced, but rather when Gentoo started using the OpenRC style of init script, which happened much earlier - it's definitely been like that since I started using Gentoo, at least since 2003 or so.
It's actually a misconception that sysvinit is the whole init system; sysvinit is PID 1. Gentoo still uses sysvinit for PID 1 by default. What matters is what your service manager is - that's OpenRC here.
I would say that's a meaningless comparison and those other systems were never considered as real replacements. At that time I don't remember OpenRC getting any traction outside of Gentoo, and the distros using Upstart were already unhappy with it. Adding to that, systemd explicitly was targeting distros that used a lot of sysvinit scripts and was intended to be used as an upgrade for them. It's largely succeeded at that.
The vast, and I mean vast majority of distros used SysV before transitioning to SystemD
If you spend an afternoon installing it and configuring a few network services, you’ll already know most of what there is to know about how init used to work.
It used to be extremely elegant and robust.
The main flaw in the design was that the “service” files were written in a Turing complete language, which meant that distribution maintainers could ship things that were arbitrarily terrible, and many chose to do so.
(Edit: Also, the organizations that somehow couldn’t figure out how to use and maintain traditional init systems were the ones that produced the current generation replacements and pushed them so hard.)
This is revisionist. The organizations that built the current generation were those who had to support those who couldn't figure out how to use and maintain "traditional" init systems. Distro init scripts were (usually, and at great effort) decent, whether from Red Hat, SuSE, Debian, etc. (just don't ask too hard about why they were different). But the third-party (often, but not exclusively, proprietary) software vendors looking to support even a single distro were godawful. Eventually the support burden for e.g. Red Hat got large enough it made more sense to replace it wholesale than keep mentoring the latest batch of e.g. Oracle interns in how to write half-decent shell scripts.