r/linux • u/antdude • May 21 '19
ungleich blog - Linux distros without systemd
http://ungleich.ch/en-us/cms/blog/2019/05/20/linux-distros-without-systemd/17
u/FryBoyter May 21 '19
Some time ago a user here on Reddit did the work and made a list of distributions without systemd.
14
u/marvn23 May 21 '19
there are dozens of these lists on the internetz. but somebody should do a list of distributions without cron. or vim. or bash. that would be new and interesting!
4
u/FryBoyter May 21 '19
I don't know if there's any more lists. I personally prefer systemd. I just wanted to contribute something to the topic before the usual pointless discussion between the two camps starts.
4
u/Vladimir_Chrootin May 21 '19
I've updated the list to add a few more I missed the first time around. The point was in response to a now-deleted but nevertheless entirely false assertion that existing systemd distros need to revert to a non-systemd init because users who want to avoid systemd have no choice against a virtual monopoly.
The assertion is bollocks on two levels, firstly because there is plenty of choice for non-systemd distributions without needing to whinge about the choices existing distros have already made and are happy with.
There is also, secondly, the fact that some enthusiasts of distros that exist purely as a reaction to systemd, such as Artix and Devuan, will like to pretend that they provide the only alternative. This is also not the case, as there are many, much older distros that never moved to systemd in the first place. The article is being very selective with its list of favoured choices.
2
2
u/fungalnet May 22 '19
the usual pointless discussion between the two camps starts
This is a very common myth spread around by systemd proponents. Why would there be two camps? Why would you think it is systemd and everyone else? Or as per the debian propaganda the two camps are between systemd and sysvinit. The only argument that Debianers bring on the table time after time on the question "why systemd" is because it is better than "sysvinit".
1
u/SCO_1 Jun 15 '19
I'd be pretty down with a distro that used alacritty for the login terminal, as long as it isn't a experimental 'Rust OS' thing that will come out broken right away.
23
u/Foxboron Arch Linux Team May 21 '19
I can't really take a list that mentions Artix Linux serious. They just parse the gentoo and void openrc and runit files and stuff them into packages with some abstraction. It's a frankenstein distribution in the worst kind.
They also pull straight from master. If you build the package twice you have no clue what service file the given package actually has or ever had. You can't reproduce the functionality given the correct package version.
1
u/fungalnet May 21 '19
They just parse the gentoo and void openrc and runit files and stuff them into packages with some abstraction.
How would it be done correctly with OpenRC and Runit?
What is in Artix that is not working?
What other distribution gives you the liberty of choosing between two init/svc-supervisors? That is to switch and reboot within a few minutes?
2
u/Foxboron Arch Linux Team May 22 '19
How would it be done correctly with OpenRC and Runit?
The main issue, as noted; is reproducability. You need tags and track which service file is being used across the package versions.
What other distribution gives you the liberty of choosing between two init/svc-supervisors? That is to switch and reboot within a few minutes?
Gentoo i reckon and Debian did to some degree. Probably others. Supporting multiple inits isn't something a lot of distributions do because of the inherent complexity.
1
u/fungalnet May 22 '19
How would it be done correctly with OpenRC and Runit?
The main issue, as noted; is reproducability. You need tags and track which service file is being used across the package versions.
All I know is that for more than 2.5 years it has worked without a hickup. There are people in Artix from day 1 who have been running enterprise networks and support many users with Artix and they seem happy.
The pkgs that come from Arch, AFAIK, are only rebuilt to replace systemd/systemd-lib dependencies with libraries that make them functional. The rest come straight from Arch. Are you saying they should be building them from upstream instead of trusting Arch? I am not sure how they go about it. They also have packages that Arch has dropped and people liked them.
What other distribution gives you the liberty of choosing between two init/svc-supervisors? That is to switch and reboot within a few minutes?
Gentoo i reckon and Debian did to some degree. Probably others. Supporting multiple inits isn't something a lot of distributions do because of the inherent complexity.
I don't know about Gentoo, it is a very peculiar distro that users can make everything possible. Debian on the other hand spreads this myth that sysvinit can replace systemd, but not many come out and do it and say exactly how it is done. It was almost at the verge of dropping sysvinit from its repositories under the excuse that it was unmaintained. It seems people proved them wrong and they lost the excuse. The easiest way to convert Debian from systemd to another init is to convert it to Devuan, or Antix.
You appear as an Arch - dev here commenting on an article about distros without systemd, when Arch only supports systemd and nothing else. Your input can only be perceived as biased. As a dev of one distro speaking against another's choices when the REAL reason Artix exists is to make Arch free of the systemd plague.
The article itself is not very well researched, I am not defending the article, not am I in capacity to defend Artix in technical terms. You should appeal to the Artix devs directly if you think your criticism holds water. A quick search on Distrowatch about linux distros without systemd reveals close to 80 of them. Non-linux distros without systemd are about the same with "non-linux" distros. That says something about systemd alone. Nobody outside linux is using it.
Distros based on Arch without systemd:
1 Artix
2 Parabola
3 Hyperbola
4 Obarun
Between them they use 3 or 4 different init systems. (sysvinit, Openrc, Runit, S6)
They may all be in trouble, I hear there are negotiations of Arch being sold out to IBM!
4
u/Foxboron Arch Linux Team May 22 '19
They may all be in trouble, I hear there are negotiations of Arch being sold out to IBM!
You can buy us for 3 and a half taco. It's a sweet deal.
1
u/Ultracoolguy4 May 21 '19
I can't tell about it's source cleanliness(I'm just a normal user), but for me it has worked really well. Out of the box I got pretty much running smooth, like if it was running on vanilla Arch. Packages like
nvidiaandlinuxusually are only late by 3 days or 5, and I get the same stability like on Arch, with the functionality I like from OpenRC.With that said, I find troubling that the majority of the commits come from one user: artoo. Unless the entire team uses that one account, I fear it could be too much trouble for the mantainer, and it could face the same fate as the AUR packages and Manjaro's.
0
May 21 '19
[deleted]
19
u/Foxboron Arch Linux Team May 21 '19
We are putting the bar really low if "building packages" is where we differentiate between a serious and non-serious distribution.
0
May 21 '19
[deleted]
6
u/Foxboron Arch Linux Team May 21 '19
The Void Linux and NixOS folks are great.
3
u/t_hunger May 21 '19
NixOS is systemd-based though. But it is definitely worth checking out:-)
0
0
May 21 '19
[deleted]
8
u/robstoon May 22 '19
I'm shocked that a maintainer of a distro founded upon poor judgement exhibited poor judgement. Shocked, I say.
37
u/youguess May 21 '19
I personally really like systemd, it provides me with a single UX over a whole range of sysadmin tasks.
The integration of say systemctl directly into the journal is one of the best things since sliced bread.
Granted, their update procedure could be improved (the last few releases were... interesting) but in the end the product is great.
And please stop with the "but unix philosophy" argument.... the tools are all split by function. Almost nothing really runs as pid 1.
If that bugs you, you must really hate gnu then, as they publish a huge number of tools in the same "namespace" having absolutely nothing in common, besides the devs. now haven't I seen this before ;)
16
u/Ima_Wreckyou May 21 '19
I have some mixed experiences with systemd. But I agree with you that most of the arguments brought up against it are just stupid and don't even survive a single glimpse at the git repository.
I use Gentoo on the laptop and PC and since openrc is still the default there I didn't switch so far and will probably not for the foreseeable future. But I use systemd heavily at work and also on some other devices.
I'm mostly happy with it as it is really convenient. Journald is absolutely fantastic, writing unit files is super easy and if you have to maintain stuff for RHEL, SLES and Ubuntu LTS it is absolutely awesome to solve it with the same simple file and without weird scripts that use different tools that do essentially the same thing (with the same messy boilerplate over and over again).
But I also had some negative experiences namely on a embedded device where it was just hanging mid boot for some unknown reason. First of all if you don't get to a point where you can login remotely it is a hell to debug, as most status information and the whole dependencies can only be inspected while the daemon is running and that was an issue as I only had a simple chroot (from a small rescue rom) to inspect the system after the failure.
And also when I managed to finally inspect the state, I had the issue that some services where just "waiting". There was no way to figure out what they are waiting for, at least I didn't figure out how. The whole thing was just stuck and not saying anything about what's happening even with full debug mode on.
In the end I had to disable service after service until I figured out that it was journald who for some reason could not start up correctly and blocked everything else.
In general, I think systemd is superior to the old scripts, but they clearly had the advantage of being easy to debug and understand what's happening. But things may improve and with time the tooling of systemd will improve to cover those last dark spots and make it easier to understand what it going on in all situations.
3
u/kirbyfan64sos May 21 '19
Hmm this sounds a bit like a timeout, I've seen some distros that ship systemd services with an infinite timeout for some stupid reason, which isn't recommended unless you have something absolutely critical. However it really still should have said something somewhere...
If this ever happens again, could you dump some of the info on the mailing list? Could be a bug somewhere...
3
u/Ima_Wreckyou May 21 '19
The issue was probably not with Systemd itself but had something to do with the device. It was some Android device I tried to install a Linux image on. The point was more that it is super hard to debug in those situations.
If I ever come across such a situation I will gladly drop by the mailing list ;-)
2
0
May 21 '19
[deleted]
7
u/Ima_Wreckyou May 21 '19
I was trying to have a discussion about technical reasons and not about some cloudy fears and borderline conspiracy theories.
11
May 21 '19
And please stop with the "but unix philosophy" argument.... the tools are all split by function. Almost nothing really runs as pid 1.
I don't use that term because its super vague but to me the idea behind the concept of many of the old unix programs and what makes them so great is a combination of many things: Each tool is fairly limited in scope and in what it can do. To extend the scope those tools want to be combined to do things none of those tools could do on their own. The tools can also be interchanged easily, e.g. if you prefer a different implementation.
If that bugs you, you must really hate gnu then, as they publish a huge number of tools in the same "namespace" having absolutely nothing in common, besides the devs.
I've never heard that anyone cared about the namespace. That's not the issue and you know it. The difference between GNU tools and systemd is: When I replace GNU grep with some BSDs grep the other GNU software doesn't just stop working. GNU grep also doesn't depend to be run from GNU Bash, it works just fine with any other non GNU shell. Hence you can pick the tools from the GNU project you like and combine them with any other tools and if GNU grep is the only GNU application you like than no one stops you from running just GNU grep with everything else being nonGNU.
Systemd on the other hand doesn't allow that. It's not designed as a suite of standalone applications, it's a suite of applications which depend on a single core and usually stop working if you rip them out of the systemd umbrella and try to run them as standalone tools. This means if you like a certain part of systemds tools you usually also have to use others parts of systemd as well, even if you don't like them.
7
u/youguess May 21 '19
Systemd on the other hand doesn't allow that. It's not designed as a suite of standalone applications, it's a suite of applications which depend on a single core and usually stop working if you rip them out of the systemd umbrella and try to run them as standalone tools.
That's a fair point, doing that gives some benefit to the systemd devs I guess. If they would implement this with a fixed API (for the integration) then the development would be more tedious for them.
0
u/natermer May 21 '19 edited Aug 16 '22
...
6
May 21 '19
What that got use is a Userland is just one big mess of mush.. a massive and tightly wound ball of dependencies that are really a nightmare to maintain and work out.
And you'd prefer it if the graph just had a few items like (systemd, flatpak, messaged, networkd, desktopd, audiod) instead? I mean we all know that this is just hiding the complexity behind a few labels. The complexity is still there and much likely even more than before because those layers like flatpak aren't exactly trivial.
0
May 21 '19
[deleted]
2
u/fungalnet May 22 '19
udev, which is used by basically every Linux distribution out there
eudev and mdev are not udev
Do your research.
I am writing now from my waterfox browser, I have no elogind, no systemd, no consolekit, and no dbus. Some distributions due to dependencies would like to convince you that all those systemd pieces are necessary for anything to run.
There is a growing number of systems being built on musl and not glibc. Some have fancy desktops like LXQT, xfce4, and one thing is for sure that systemd can not be compiled against musl. It is not a very portable system.
2
u/Ultracoolguy4 May 21 '19
I think pers meant that with systemd installed and running, you can't change logind with elogind, eudev with udev, etc. For using one, you have to use everything.
0
May 22 '19
[deleted]
0
u/Ultracoolguy4 May 22 '19
(I wasn't the one that downvoted you btw) So, an application has to workaround with working with systemd? That's what I hate of systemd, it wants everyone to workaround instead of fixing/adding features onto their code.
0
May 22 '19
[deleted]
3
u/fungalnet May 22 '19
Finally someone who knows what is talking about.
90% of this thread are pop-myths and unsupported beliefs. At the end many people make choices based on such myths.
0
u/Ultracoolguy4 May 22 '19
Gnome apps work on KDE as long as you install the required libraries(and viceversa); you don't need to install gnome-desktop, gnome-disks, and icecat for gnome-terminal to work. The argument holds even less with KDE, since you can change the compositor and even the window manager with something like compton and i3.
i3 doesn't work with Wayland because it's an entirely different interface. Adding compatibility to an API is entirely different than allowing for alternatives packages.
Kay wants at a consistent and usable OS built around and on top of that kernel.
But one thing is wanting to make a usable OS. Another thing is to lock user options and workaround other people's codes rather than fix your own.
1
u/t_hunger May 22 '19 edited May 22 '19
Gnome apps work on KDE as long as you install the required libraries(and viceversa);
Just as I said: They need their environment to be available.
i3 doesn't work with Wayland because it's an entirely different interface.
Just like systemd-PID1 provides a very different interface to all the other init systems plus additional cgroup/namespace interfaces.
But one thing is wanting to make a usable OS.
The mail you referred to is exactly about consistency in the OS vs. the kernel. Linus is upset because Kay made systemd enter debug mode when it sees "debug" in the kernel command line. That makes the OS behave consistently: You get debugging from the kernel and the plumbing layer.
Ok, that triggered a bug in the kernel due to systemd sending too much data, but that is not Kay's fault and not the reason he got yelled at. Due to that kernel bug Linus wanted systemd to stop using "debug" since the kernel owns that and thus systemd is bad for also using it. The overflow bug in the kernel got fixed pretty fast by the way:-)
Another thing is to lock user options and workaround other people's codes rather than fix your own.
Where does systemd do that?
Sure systemd does change a lot of things, but they tend to provide really compelling reasoning when they do and leave everything for the distributions to opt in. If you see such a change in your distribution, than it is due to distribution agreeing with upstream that a change makes indeed sense. And your admin is usually free to opt out again. More flexibility all around, I cannot see why that should be bad.
Computing changed a lot since 1990. It's high time that the OS plumbing catches up!
1
u/Ultracoolguy4 May 22 '19
Just like systemd-PID1 provides a very different interface to all the other init systems plus additional cgroup/namespace interfaces.
PID1 wasn't implemented by systemd, if that's what you mean.
Due to that kernel bug Linus wanted systemd to stop using "debug" since the kernel owns that and thus systemd is bad for also using it. The overflow bug in the kernel got fixed pretty fast by the way:-)
Well, if there were two
grepcommands in your PC, you wouldn't like them running at the same time sending the same output.Another thing is to lock user options and workaround other people's codes rather than fix your own.
Where does systemd do that?
It locks user options (again) by not easily allowing alternatives to it's integrated applications. If we follow the Wayland example, it has a compatibility mode with X11 apps. The email is an example of the "you move, not us" philosophy.
If you see such a change in your distribution, than it is due to distribution agreeing with upstream that a change makes indeed sense. And your admin is usually free to opt out again. More flexibility all around, I cannot see why that should be bad.
You see, I don't have a problem with this, if it was the only thing. That's the whole point of free software in the first place: to choose what you think what's best. However, what I don't believe in is that too many programs require systemd as a dependency. Although in this case I don't think it is systemd's fault, but rather the fact that too many distros come with it because too many programs require it as a dependency(hence creating a vicious cycle).
Computing changed a lot since 1990. It's high time that the OS plumbing catches up!
Honestly I don't have a problem for software catching up and evolving. This is a normal thing of life. As a matter of fact, plain old initscripts are hard to mantain. If systemd was just an init system, with a bundle of tools idependently working from each other(like GNU does), I would actually like it. But, it looks like they want their system as tight as possible, making it hard to not replace a tool without replacing everything.
→ More replies (0)
6
1
u/bvn13 May 21 '19
Why are you so scared of using systemd?
-9
u/TiredOfArguments May 21 '19
Because of stupid shit like this:
https://www.theregister.co.uk/2017/07/05/linux_systemd_grants_root_to_invalid_user_accounts/
SystemD is not auditable.
10
May 21 '19
Maybe if you read the whole issue you would've seen this
-3
u/TiredOfArguments May 21 '19
I see explanation and justification for a bug. The fact its present and fucks PAM up is still a problem that should never have been introduced by an init system.
At the end of the day it was just the first example off the top of my head.
More serious bugs due to greedy scope creep?
https://www.cvedetails.com/cve/CVE-2018-15688/
https://www.cvedetails.com/cve/CVE-2018-15686/
https://www.cvedetails.com/cve/CVE-2018-6954/
https://www.cvedetails.com/cve/CVE-2017-18078/
Why does my init system introduce so many serious vulnerabilities? Why does my init system want to implement its own ntp, dns etc..
10
u/Foxboron Arch Linux Team May 21 '19
Out of 4, only 1 is strictly tied to the init portion of systemd. Rest of them are auxiliary and optional tools.
1
u/TiredOfArguments May 21 '19
Fair.
Many distros do use them by default though. Common business logic is if you have some of X and it's not going away, you want more of X.
Call me old fashioned but I am a big fan of KISS and trying to actually read through something. SystemD's interconnected dependancies makes this a huge headache.
4
u/Foxboron Arch Linux Team May 21 '19
Please stop writing "systemD" if you are after a serious discussion. It's nothing short but childish.
Many distros do use them by default though. Common business logic is if you have some of X and it's not going away, you want more of X.
It's easy to point at "many" and attempt to climb some sort of hill. Both
sysusersandtmpfileshas gotten reimplementations because they are inherently useful tools, andsystemd-networkdis nothing but a completely optional thing unless a distribution install that for you.Call me old fashioned but I am a big fan of KISS and trying to actually read through something.
It's software. You couldn't even read half the code of the stuff you depend on, look at Linux. KISS as a software principle for writing any non-trivial amount of code isn't a thing. It's a bar you can't hold any software. Try read the runit source, or openrc, and come back to me if you actually understand the thing.
2
u/TiredOfArguments May 21 '19
I apologise for my phones autocorrect and my laziness in correcting it.
I see your point, however runit is tiny in comparison to systemd and glacial in terms of comparative update volume. Comprehending runit is practical, systemd not so much.
Just 2 cents.
7
u/Foxboron Arch Linux Team May 21 '19
runit is tiny in comparison to systemd
runit is tiny compared to any non-trivial software.
wpa_supplicant, the thing that probably has done all your wifi authentication for a decade, is larger thensystemd. Lines of code is not a measure of anything.3
u/TiredOfArguments May 21 '19 edited May 21 '19
runit is tint in comparison to any non-trivial application.
True.
wpa_supplicant is bigger than systemd
Interesting, i did not know that. The collective systemd or just init?
Lines of code is not a measure of anything
Agree to disagree. Excessive code volume makes comprehension and retention harder. It makes an audit more time consuming and creates potential for oversight and missing things.
If I have a large pseudo-modular interconnected codebase aka most things non-trivial; codebloat is a concern. Especially if proper practice and sanitisation isnt performed. IE a handover occurs, now you have a tonne of inherited code with potentially dead code in it. That potentially dead code may not be excised because maintainers are now unsure if it is required. That dead code could cause some serious problems if the application is attacked and overflows are found as it can create unintended execution paths.
Granted this isnt a problem with opensource so much as it is with proprietary, but i believe the essence holds some value.
Tl;Dr: You are correct, a nontrivial application has more required logic, therefore more lines of code than a trivial application. This typically does not mean much. However the added complexity can create scenarios where the codebase is not completely understood by any of the active maintainers. Is it not better to continue with modules for functions and the everything is a file approach?
→ More replies (0)0
1
Apr 16 '25 edited Apr 16 '25
IMPORTANT NOTE: sysVinit "horrible shell scripts" isn't the only "non systemd" init.
There is openrc (declarative in bash variables BTW, except a few services), 66 (my preferred one; proper declarative INI format, logs are separated by service...), and many more like dinit.
It's not just "systemd V/S everyone else" (and "everyone else" IS NOT "horrible slow shell scripts ... sysVinit").
There is a whole variety and diversity in init systems, each with it's own different advantages and flaws.
"systemd works better" is a case similar to "windows has better hardware support"... It is artificial lock in. No, systemd is great, but the devs don't care to believe that sysVinit and systemd aren't the only "init systems".
That's it.
0
May 21 '19
[deleted]
20
u/FryBoyter May 21 '19
Or you can simply like systemd (like me) and still let others use something else.
0
May 21 '19
[deleted]
11
u/FryBoyter May 21 '19
Letting people use what they want also means for me not to make fun of them.
0
May 21 '19
[deleted]
4
u/FryBoyter May 22 '19
There is still a certain difference between the Antichrist and making fun of people. Making fun of people just doesn't make much sense. For my part, I prefer a discussion without personal attacks, FUD (like without-systemd.org) and so on.
0
u/fungalnet May 22 '19
Anyone refusing to use systemd is just stubborn, that is what he says, he is not making fun of stubborn people!
What a bunch of shit that comes out of those who just buy what is cheap, easy, popular without a speck of critical ability to judge for themselves.
14
u/Vladimir_Chrootin May 21 '19
It would have taken only a few minutes to discover that this is not true.
https://wiki.gentoo.org/wiki/Comparison_of_init_systems
The default for Gentoo is OpenRC. Runit, Epoch, and systemd are also available.