From ParabolaWiki
Jump to: navigation, search

1 Init Freedom

From Devuan:

"Init Freedom is about restoring a sane approach to PID1 that respects portability, diversity and freedom of choice."

There are many well-founded and well-articulated arguments against SystemD to be found on the web, mostly from organizations using terms such as "no-systemd", "systemd-free", "without-systemd" (generally: the "anti-systemd" perspective). The most compelling arguments are the danger of "monoculture" (ie: the tendency to discourage diversity and compatibility/portability), and "monolithic" system designs (in contrast to the well-established "UNIX philosophy"). Rather than being a suite of interoperable, interchangeable system components, SystemD fancies itself as the core system, essential for any OS with Linux as its kernel. Some even refer to it as "The System Daemon" or "The SystemD", as if that were a standard OS design concept, rather than a brand name.

Although we agree with most of the premises of these arguments, we must reject the conclusion to exclude SystemD, on the principle of freedom. People should have options, in addition to information and/or warnings. Education and tolerance are more responsible than mandates and prohibitions.

So, Parabola is neither anti-systemd nor pro-systemd. Parabola is pro-freedom. The essential concept related to software freedom is init-freedom. Any distro which offers only one init-system, regardless of which one that is, lacks init-freedom; which hinders the do-it-yourself "admin freedom" - a hallmark of *nix systems - arch-like systems especially. Parabola offers init-freedom by allowing each user to choose and switch between multiple init-systems, including, but (most importantly) not limited to SystemD or any other.

SystemD's tendency toward monoculture (much like its cousin: Pulseaudio, and its successor: Pipewire, all originating from the same consortium, coincidentally) is the most formidable obstacle to overcome for distros which support init-systems other than SystemD, without also sacrificing a large sub-set of GUI software; because application developers are likely to accept such things as de-facto standards (even if a true de-facto standard exists, such as ALSA). The perhaps uncomfortable and perhaps regrettable fact to accept (especially for those who wish to eradicate SystemD entirely), is that it would be difficult to find any *nix distro, which uses any variant of the linux kernel, and offers a wide selection of GUI software, but does not also have some parts of SystemD as essential components, consequently. Some programs will simply refuse to run, without or logind. Parabola. like most well-known non-systemd distros such as Gentoo, Devuan, and Artix, includes parts of SystemD (eg:, logind) rather than to exclude software which requires them. The essential difference is that non-systemd distros offer those parts of SystemD as optional components, de-coupled from the SystemD and Linux monoliths.

2 Quick! What's the file-system look like?

Services are installed as… Services are enabled in runlevels by… Switch runlevels by running…
sysvinit lines in /etc/inittab editing /etc/inittab telinit ${number}
sysvinit + Arch initscripts files in /etc/init.d/ editing /etc/rc.conf telinit ${number}
sysvinit + OpenRC files in /etc/init.d/ creating symlinks in /etc/runlevels/${runlevel_name}/ telinit ${number} or openrc ${name}
openrc-init + OpenRC files in /etc/init.d/ creating symlinks in /etc/runlevels/${runlevel_name}/ openrc ${name}
runit subdirectories in /etc/sv/ creating symlinks in /etc/runit/runsvdir/${runlevel_name}/ runsvchdir ${name}
systemd files in /usr/lib/systemd/system/ creating symlinks in /etc/systemd/system/${runlevel_name}.target.wants/ systemctl start ${name}.target
  • We don't recommend using sysvinit by itself, it is only included in the above table for completeness.
  • We haven't supported Arch initscripts in several years, it is only included in the above table for completeness.
  • The systemd folks thought that people thought of "runlevels" as exclusively numeric, so they actually call their thing "targets" instead of "runlevels".

3 What do the various virtual package names mean, exactly?

  • init is provided by a package that contains /usr/bin/init
  • initscripts is provided by a package that contains /etc/inittab
  • udev is provided by a package that contains /usr/bin/udevadm and a udevd
  • libudev is provided by a package that contains /usr/lib/
  • openrc-pid1 is provided by a package that contains or configures a program as PID1 to launch OpenRC.