-jonny-
Years ago I was wondering what this init freedom thing was all about. Today in the wakes of regreSSHion and xzUtils it dawns on me.

This article has been written in 2022 but could not be more up to date today.

#gnu #linux #foss #init #freedom #devuan #debian #backdoor #systemd

The fight for Init Freedom


Distro Walk – Devuan

Devuan, with its promise of Init Freedom, provides users an alternative to systemd as an init process.

Long-time Linux users may remember a time when Debian was viewed as a collection of anarchists, with radical ideas about voting and decision-making. At times, Debian was even the lone dissenter among distributions about decisions made by the Free Software Foundation. However, over the years, Debian has developed its own hierarchy along the way to becoming the source for some two-thirds of active distributions. Today, the Debian derivative most reminiscent of early Debian is Devuan [1], which forked from Debian in 2014 over how decisions were made and the technical connotations of using systemd. Recently, two Devuan developers – fsmithred, who builds the live images and helps with support, and golinux, the community manager – took the time to recall Devuan's past and why their issues are still relevant today. Because Devuan lacks a formal hierarchy, they emphasize that their remarks are "unofficially official."

In 2014, major Linux distributions were transitioning from SysVinit to systemd as an init process – init being the first process to start on a system and the one that manages other processes. Ubuntu had started using Upstart a decade earlier with little controversy. By contrast, systemd was controversial from its earliest days. To start with, systemd is much more than an init system. Rather, as contributor dasein described on the Debian User Forums, "calling systemd an init system is like calling an automobile a cup holder" [2]. That is, while systemd includes the functions of an init system, dasein said systemd is also "an effort to recreate large portions of existing userspace (including login, job scheduling, and networking, just to name a few) inside a single process traditionally reserved for the sole purpose of starting *nix userspace. (Just in case it isn't clear, there is a huge difference between starting userspace (init) and being userspace (systemd).)"

From this perspective, not only is systemd overkill, but it is a violation of the basic tenet of Unix development that an application does only one thing and does it very well. As Christopher Barry stated in the Linux Kernel Archive, this philosophy is what makes Linux "a collection of simple modular components that could be plugged together at will to do real work" [3] – an operating system that is both flexible and accessible. Just as importantly, a modular structure allows the pieces to be assembled in different ways, so that each distribution can be unique. By contrast, systemd imposes a structure on all Linux systems that reduces variety – which is convenient in some ways, but needlessly limiting in time-honored ways.

As expected, the Debian mail forums debated these perspectives extensively. Unsurprisingly, the discussion culminated in a General Resolution among Debian users, with many Debian officials favoring systemd. The winning option was to use systemd, but at the same time, a more general resolution to favor systemd placed last – a decided ambiguity. Although rarely stated in so many words, much of the dissatisfaction implied that the decision to use systemd was imposed by the Debian hierarchy upon the general membership.

Whether this implication was valid is besides the point. Many believed it was. On November 24, 2014, the Devuan fork was announced. The intention was "to produce a reliable and minimalist base distribution that stays away from the homogenization and lock-in promoted by systemd" [4].
Introducing Init Freedom

Rather than being seen as simply an anti-systemd project, Devuan calls its position Init Freedom (Figure 1). The name invokes Richard Stallman's four essential freedoms, although the idea itself might seem less basic. Devuan's Init Freedom page [5] simply defines the idea as being "about restoring a sane approach to PID1 [init] that respects portability, diversity, and freedom of choice," assuming that the value of these goals is self-evident.
Figure 1: Devuan supports a choice of init alternatives.

In practice, Init Freedom means supporting a choice of init freedoms. Although systemd advocates often maintain that supporting multiple init systems would make packaging more difficult, from its first release, Devuan has continually added init alternatives without any apparent difficulties. Today, in addition to the default SysVinit, Devuan lists six alternatives: OpenRC, runit, sinit, s6, 66-devuan, and Shepherd, and it is open to considering others. Fsmithred suggests that most people simply use sysVinit, although OpenRC and runit, which use SysVinit scripts, are also available. Scripts are also being developed for runit and to extend usability of other shipped alternatives. For those interested in learning more, discussion can be found on the Dev1 Galaxy Forum [6] and on Devuan's IRC channel [7].

In addition, the Init Freedom page lists other Linux distributions that offer systemd-free alternatives, as well as other Unices such as the BSD Family. DistroWatch also offers a search filter for distros without systemd – currently, 97, a total far higher than many might suspect, although it includes only a handful of major distributions, such as MX Linux, Alpine Linux, and KNOPPIX [8]. Devuan keeps in close touch with these distributions, especially on the Dev1 Galaxy Forum.

Fsmithred adds that, "We rely heavily on Debian. Most of the packages in Devuan are unchanged from Debian. We only fork packages that require systemd. There is collaboration between Devuan and Debian on a few packages, and we occasionally send bug fixes or patches upstream to Debian for packages we do not fork."
Beyond Init Freedom

Devuan is usually referred to in terms of Init Freedom – often with the obviously mistaken assumption that it is a lost cause. However, Devuan also features Docker images and community-developed ARM packages. Chimaera, the latest Devuan release, also includes an option to not install PulseAudio to enable simultaneous speech synthesis in both a graphical and console session. In addition, at least one Devuan-derivative exists, Maemo Leste, whose goal is "to provide a free and open source Maemo experience on mobile phones and tablets like the Nokia N900, Motorola Droid 4, Motorola Bionic, PinePhone, PineTab, Allwinner tablets, and more" [9]. Although Devuan might be a niche distribution, clearly it is a thriving one.

But can Devuan's cause become mainstream? It's not impossible. Linux is in an era in which large parts of it are being written. If PulseAudio can be replaced with PipeWire – which is currently happening – then systemd's obsolescence is not impossible, either. Meanwhile, for those who disagree with the majority, Devuan provides a workable alternative, while keeping the early spirit of Debian alive.

Source: https://www.linux-magazine.com/Issues/2022/260/Devuan
Diggers hat dies geteilt
Avap Xia
This wrong focus on init alone made a new category of distros that on paper were free of systemd, but on false grounds.

The most pervasive and invasive part of systemd is not its init process (stage 1 for other init systems) but its enforcement of the logind/dbus processes after stage 1. Upstream, primarily desktop software, begun to make calls on this subsystem and to make life easier distros adopted elogind, which is the largest part of systemd, and it is pretty much systemd. This way they had to make no effort in building any software that was oriented in running in a systemd system.

Then came out the propaganda that the alternative, consolekit, was abandoned, when it is still to this day active and fully functional, for those that need it.

Then came another propaganda reproduced by even distro leaders who promoted their no-systemd status, that wayland compositors wouldn't work without systemd/elogind, because consolekit2 doesn't prpvide a seat daemon. False again, seatd in addition to consolekit2 have been 100% an alternative to elogind.

Actually, you don't even need elogind/ck2 for wayland, seatd which is tiny (space and running resources) is fully able to satisfy current wayland compositors. labwc which is a neae 95% equivalent to openbox on wayland runs great, no dbus, no ck, no elogind, just seatd and xdg-runtime environment.

The same propagandists on false premises were using logind logic to deem gksu/gksudo unsafe, on the sole ground it bypassed logind and provided rights escalation to a desktop user entering a root password when asked. Many puppet fashion freak distros abandoned gksu/gksudo on those false claims. Now the same gang are aiming in abandoning sudo, and its even lighter alternative (thanks BSD) doas, in favor of yet another systemd gadget on some false claims of security!

The #1 security risk a linux distro has is running parts of systemd in it, including the treacherous systemd-boot. So systemd has extended beyond the installed system and begind before even the kernel is mounted.

80% of linux specific rags (media) are either subsidiaries or on the payroll of RH/IBM, the least you can question is how objective their propaganda is. To get an idea of it search their articles for mentioning of OpenRC, runit, daemontools, s6, anope, dinit, .... On a distrowatch poll a few years back systemd came 2nd place, and openrc/runit/s6 summed about 60% of the vote. The picture phoronix paints is contradictory to say the least.
Question: Why do you think Unique Random IDs on your system are generated by systemd/dbus parts and nearly unchanged for the lifetime of the system? For your benefit?

They should rename the project to boobietrapD it has become nearly as bad as MS/Mac-OS or googledroid. ... and they are not even done yet.
Packaged, runit, s6, openrc, dinit, sinit, consolekit2, seatd, all together are a "fraction" of the size of systemd alone. What so modern and efficient about so much code?
Why can't you have systemd with musl instead of glibc?
Why can't you have systemd with BSDs ?
Why can you build configure and run runit, s6 on pretty much any open free system, init and service management?
The better you answer such questions the more likely you are to rethink this "choice" thing.
#1

This website uses cookies to recognize revisiting and logged in users. You accept the usage of these cookies by continue browsing this website.