Talk:Linux distributions without systemd
GNU/Linux Distros in which systemd can be replaced
Exherbo Linux "systemd is the default init system, but you can disable systemd usage globally and use alternatives easily." See Without systemd. The fact that systemd can be disabled/replaced is also true for most other GNU/Linux distros which ship systemd as default init (except those derived from Red Hat, eg Fedora, RHEL, CentOS).
Sabayon Linux (Gentoo based) The default init system is systemd. Switch to runit(?) + OpenRC via "eselect init".
- As of Debian8 (jessie) release, systemd is the default init system. A "sysvinit-core" package can be installed to alternatively provide sysV /sbin/init
- Note: alternative software repositories, e.g. from Devuan or antiX or angband.pl, can be added to improve System V init compatibility.
ALT Linux is derived from Mandrake. Prior releases did use PID1 systemd, but does the "Jan2017 Sisyphus" release have systemd as default init?
Reply -- CrayXMP -- ALT Linux
Their wiki has some English. Sisyphus can be seen as a testing/unstable repo : "Sisyphus is quite dynamic project which makes it hard to schedule and perform releases based on it." They release nightly images and branches every few months however.
We can notice that the following sources suggest that systemd is actively used : ChangeLog; BUGS or the russian wiki page on systemd.
To be fair, experimental downloads using GNUstep, IceWM and WindowMaker flavours use sysvinit. But these are obviously not mainstream Desktop Environments.
I tried the latest branch alt-workstation-8-x86_64.iso (which happens to be a MATE desktop) and then installed sysvinit related packages to remove the systemd process as PID1. Except from the systemd package itself I was not able to remove the systemd related packages because of their deep dependencies. I even shifted the repos to sisyphus under apt (p8/branch --> Sisyphus) to confirm it. Based on this little experiment I thus recommend to definitely exclude ALT Linux from the list of systemd-free distros.
To sum it up: ALT defaults to systemd as PID1 and as such is actively developed. Even if it was easy to install sysvinit and remove the systemd process only, fully removing the systemd packages leads to unwanted consequences on the desktop. This could explain that sysvinit has been limited to some very light DE (with no forced dependencies to systemd).
Should we list old (prior) non-infected operating system releases?
Trisquel is one of the libre distributions recommended by the FSF. Trisquel 6.0 (still supported) doesn't have any trace of systemd on it. It's successor Trisquel 7.0 has a systemd-services and systemd-shim package installed along with a virtual systemd package. It is based on ubuntu though so the next LTS release might have to use systemd. Should either Trisquel 6 or 7 be added to the list of distributions without systemd ?
PS: The kernels in both versions of Trisquel live CDs are dated but you can upgrade them up 3.5.x ( with backports for Trisquel 6.0 ) and 4.2.x for Trisquel 7.0 at the time of this writing.)
reply: -- kriv
How old is OLD?
IMO, no (neither Trisquel 6 nor 7) should be listed. Although a fan of Trisquel, I count that project among those "now infected". Mentioning Trisquel here, off mainpage, is fine. Linking/mentioning "but but older version XYZ is systemd-free" seems pointless (track/list old version how far back?) ref: trisquel T6=2013, T7=2014 w/systemd
Linux From Scratch (LFS and BLFS)
LFS status has been (questioned and) fact-checked repeatedly. As of March 2018: Distribution Release: Linux From Scratch 8.2
the project does not have "a (one) default init" ~~ LFS still provides its users a choice
Hey guys, firstly I hope you are alright with my changes (splitting up the pages, rearranging sections, changing lists to tables and introducing some templates).
At the top of Linux distributions without systemd, I spelled out the criteria which you seem to have followed.
Should we unlist distributions that do not provide / document the recipes to their boot images / their packages? Examples are 4MLinux, Quirky, LinuxConsole and Slontoo.
Should we unlist Lombix because it is pre-Alpha?
Should we unlist distributions whose latest version contains a kernel that has reached EOL? An example is Legacy OS with kernel v2.6.18.
Due to its target architecture, LegacyOS will always ship v2.x kernel.
EOL (vs maintined, rolling) is often difficult to research and assess.
Presenting O/Ses which rely on upstream, no-longer-maintained, repositories seems like a disservice to the readers.
re: 4MLinux, Quirky, LinuxConsole and Slontoo...
I'm not inclined to de-list any of those. If you move 'em to the unlisted page under a header "source code availability uncertain", that might spur future editors to find links to source code or spur the project developers to into providing links.
Lombix? Now that the wiki mainPage looooong list is split up, and supplementary links for each item have been culled... I can't guess.
Rechecking just now, I see the dev has stated (ref) "At this moment Lombix is not meant to be installed on any system, it is a very much work in progress and I cannot see why anybody would want to install it when you can try it safely using qemu."... so yeah, I've now moved it to the unlisted page.
criteria: I've further modded the verbiage in the page preface, toward clarifying the rationale.
Still... I'm not inclined to remove, er "disqualify", any of the currently listed O/Ses. Technically, several are so niche (EasyOS, Quirky, PicarOS, KaNaPi, etc.) that they may not "qualify", yet per my research each did seem well-maintained and viable. Similarly, nanolinux (arguably EOL), TAZ, et al... still seem suitable for their intended niche task/audience.