It' actually great that systemd isn't portable.
No systemd, no udev.
No systemd, no Linux.
The main innovations of OpenRC are the creation of named runlevels and full dependency handling. The numbered runlevels of sysvinit were an attempt at handling dependencies, but they sequentialize the boot process and are unable to handle complex dependency chains. OpenRC's calculation of the dependency graph eliminates such limitations. It is also written in C, so there is not much overhead in the calculation.
Anyway, systemd is full of severe reliability regressions that I do not want on my system. I am currently fixing a regression that can cause udevd to enter d-state permanently. It will cripple the system boot process in certain situations. eudev inherited it from systemd. Anyone who asks me for details will be told to ask again after our first tag. I have adopted the Sun Microsystems approach to collaboration (i.e. code drops) for reliability bugs introduced by systemd in response to abuse from Lennart Poettering and Kay Sievers. You can thank them for that.
In the case of Upstart, that'sQuote:
hostnamectl journalctl localectl loginctl systemctl systemd systemd-ac-power systemd-analyze systemd-ask-password
systemd-binfmt systemd-cat systemd-cgls systemd-cgroups-agent systemd-cgtop systemd-coredump systemd-coredumpctl
systemd-delta systemd-detect-virt systemd-fsck systemd-hostnamed systemd-inhibit systemd-initctl systemd-journald
systemd-journal-gatewayd systemd-localed systemd-logind systemd-machine-id-setup systemd-modules-load systemd-multi-seat-x
systemd-notify systemd-nspawn systemd-quotacheck systemd-random-seed systemd-readahead systemd-remount-fs
systemd-reply-password systemd-shutdown systemd-shutdownd systemd-sleep systemd-stdio-bridge systemd-sysctl
systemd-timedated systemd-timestamp systemd-tmpfiles systemd-tty-ask-password-agent systemd-udevd systemd-update-utmp
systemd-user-sessions systemd-vconsole-setup timedatectl udevadm
many of which are symbolic links or have traditional system V semantics. To be honest, to the Upstart set one has to add udevd and udevadm, which need to be found and ripped out of systemd's installation image (because that's the best practice that systemd maintainers envision for people who do not want to use systemd).Quote:
halt init init-checkconf initctl initctl2dot poweroff reboot reload restart runlevel shutdown start status stop telinit
And we're talking only about the binaries, not all stuff such as support libraries and configuration files. In total, the systemd installation image touches 621 files and 93 directories. Upstart touches 44 files and 18 directories.
Now in all honesty, looking at the complexity of the two packages, and supposing that I don't need systemd's additional features, because I'm fine with syslog and inetd, when managing my system, am I more likely to need external help when I'm using systemd, or when I'm using upstart?
Oh, and since people keep making silly comparisons such as counting the number of PIDs used,
$ size init
text data bss dec hex filename
221392 1948 136 223476 368f4 init
$ size systemd
text data bss dec hex filename
884496 54692 2424 941612 e5e2c systemd
As I understand it systemd is a system and process manager not a init. A part of systemd, the systemd binary is the init. Upstart and systemd doesn't do the same thing so a comparison of the total code size of the project is not relevant.
As I understands it the last version of the old init in Arch linux is supposed to use some of the stuff in systemd without using the init systemd?
As I understood the news not, it was not only udev they used. At least both init system is partly configuration files compatible. But I didn't care much then, as I had switched my installation to systemd some month before.Quote:
Yes, udev. It was separate package before, but systemd devs "stole" it.