ungleich blog - Linux distros without systemd
ungleich.ch
external-link
Affordable VM hosting in Glarus, Switzerland, operated by 100% hydropower. Devuan, debian, freebsd, ubuntu, centos. Our tech stack is fully open source.

Sharing this blog post because I liked reading it. Nice photos and images and shows lots of options. The section about Gentoo Linux suggests it is unclear whether Gentoo uses Systemd. From what I’ve seen after tinkering with a Gentoo container last week is that Systemd is an option for “make world” but not the default.

@AgreeableLandscape
mod
admin
link
118M

ELI5: Why do people hate systemd? I don’t know much about it or init systems in general, but it seems to work fine for me.

@ndarwincorn
link
88M

My favorite reason is the conspiracy theory that systemd is a CIA op.

@AgreeableLandscape
mod
admin
link
18M

Wait what? Got any links to further info?

dandelion
creator
link
2
edit-2
5M

deleted by creator

musicmatze
link
48M

basically because it does things different than other init systems before. It has another philosophy and people don’t like change.

That’s basically it. There have been some issues with bugs not being fixed or even acknowledged, but nothing that concerns the casual user at all (IMHO).

@PeterLinuxer
link
58M

Systemd breaks a Unix principle, namely “Do only one thing and do it well”. It sort of envades into areas of the system where the init system previously did not. (Some say systemd isn’t an init system.)

But systemd seems to boot faster than previous init systems because it uses compiled tools instead of scripts.

And yes, the casual end user (in contrast to a sysadmin or system programmer) probably shouldn’t notice any difference with or without systemd.

@kevincox
link
58M

Systemd breaks a Unix principle, namely “Do only one thing and do it well”

I’m not so sure about this when just talking about systemd core. For the most part it starts and manages services. It has grown a “bit” to help that dependency graph be complete and reliable (for example mounts and devices so that services that use them can be started after the devices are online) but I think for the large part it is still doing “one thing”. Sure, it would be nice if those were split into separate processes and systemd had some sort of interface for external things but that would arguably be more complex as now you need to worry about multiple interacting processes.

I do agree that systemd brought a lot of things under it’s umbrella, and the systemd repo is quite bloated. For example journald, systemd-resolved and much more. But that is kinda like saying that GNU doesn’t follow the unix philosophy because they have a lot of projects.

But systemd seems to boot faster than previous init systems because it uses compiled tools instead of scripts.

This is such a tiny part of the reason that systemd boots faster that IMHO it isn’t even worth mentioning.

The primary reason that systemd boots faster is that it has proper dependency management. From the simple tracking dependencies to the much power powerful socket activation that allows dependent services to start up in parallel (at least to some degree). Socket activation can also help lazy-start services that aren’t needed right away freeing up resources for starting critical services faster.

@spytfyre
link
38M

https://blog.darknedgy.net/technology/2020/05/02/0/ this blogpost is a nice technological and historical overview. Systemd is sometimes good sometimes bad and sometimes ugly (for the love of God I cant make resolved work and the documentation just isnt there). At the end of the day if it works for you don’t fix it but just for the sake of it I would recommend trying out another init system and seeing for yourself

Arijit
link
08M

According to the UNIX philosophy, one program should do one thing and do it nicely. People hate it because systemd just does a lot of things; especially when you add things like systemd-resolvd, systemd-boot and all other systemd-* things

I am one of those neutrals who goes what his distro’s manuals say. I use Arch btw

dandelion
creator
link
5
edit-2
5M

deleted by creator

@kevincox
link
78M

Confronted with a virtual console with a blinking systemd line : “Waiting for stop job … 1m29”.

That is a weird complaint. Letting things shut down properly is a feature. If you don’t like it you can disable it:

# /etc/systemd/system.conf
DefaultTimeoutStopSec=0
@ozoned
link
78M

Never understood how systemd, telling an application to stop, and then waiting on it to stop and it doesn’t, is a systemd problem. This is an application that isn’t shutting down properly or they unit done was configured incorrectly.

If I tell my car to turn off and when I turn the key of, the car keeps on rubbing, is that my fault or the car’s?

Also as for the container issues, a lot of these container platforms are built on top of systemd and leverage systemd, because it makes their jobs easier. The containers devs could decide to handle cgroups themselves, but instead they’ll push systemd to do things it wasn’t intended to do and then blame systemd.

I will say, I am biased. I work for Red Hat, primarily in systemd support and I with closely with the systemd devs. Is it perfect? Not at all. A lot of stuff is completely broken, but the devs are always willing to listen and try to make it better.

dandelion
creator
link
3
edit-2
5M

deleted by creator

@ozoned
link
48M

“I guess in all those years with sysv,openrc,runit it simply didn’t show its shutdown slowness clearly, if it did not shutdown that fast. On FreeBSD stopping a desktop computer is always fast, never a delay and never a problem because of that. I guess it also had to do with the fact that I was playing with Ubuntu on a pi4, which comes with snap daemon and what not.”

I know nothing about runit or openrc, but I do know about sysv and upstart(which masquerades as sysv so most folks probably think they’re running sysv and really it’s upstart). sysv and upstart don’t manage the process the way that systemd does. It just runs a start script and walks away. So there’s no true tracking of if an application is misbehaving or not. 99/100 the script runs a command and puts it in the background, and then moves on so that other scripts can do their thing. If all init scripts would wait for every process to come down, then I would imagine we’d see a lot more of what systemd does, which is waiting on something to stop properly.

I feel like there’s a huge misconception about systemd, regardless of what folks think, it is NOT just an init system. upstart, sysv, are just init systems. systemd is a full management layer. As well as contrary belief, a LOT of what systemd does is all modular.

You don’t NEED systemd-logind or systemd-homed or systemd-networkd, again I work for Red Hat, we often don’t allow things in because they don’t pertain to us (looking at you systemd-homed). So the fact that your distro of choice DOES have this, means the devs made the decision that this systemd piece solves a problem for them. You do NOT need it.

Now, if you do not have systemd-logind, then yes, you’re going to be limited in what you can use. Gnome has decided to make a hard dependency on systemd-logind. Again though, is that systemd’s fault or Gnome’s?

It’s just code, if you don’t like it, don’t use it. If you have a problem with it, please report a bug so it can be fixed or so folks can understand how to use systemd or help the systemd devs understand use cases.

I will state that systemd source is a MASSIVE labyrinth and pisses me off endlessly, but it’s moving more towards like what the kernel is. But as you have kernel space and userspace, now there’s kind of a system management space.

@jazzfes
link
28M

Yes, maybe, but every single time? Things shutdown without systemd and nothing seems to explode.

@kevincox
link
28M

Just about every service manager has a similar concept. systemd makes it very visible (and maybe has a longer default timeout? I haven’t checked) but this is a generic problem.

Programs should be fine if you just send SIGKILL but it is often better if you let them shut down gracefully. For example maybe it wants to tell it’s clients that they should fail over to another host so that they won’t experience interruption, and maybe the database wants to flush it’s updates to disk so that it doesn’t need to waste time recovering from the WAL on next boot. But at the end of the day it isn’t systemd’s fault. It is just enacting the configuration. If you think that 90s is too long you can change it.

@jazzfes
link
18M

That’s good to know.

I’m just saying that for a hobby admin like me, other init systems don’t seem to have this behaviour or configuration requirement. And I find it strange that it always goes “isn’t systemds fault”… it’s clearly doing something different here than other inits by default. And that is what is criticised.

Helix
link
1
edit-2
8M

Only because something is the default, it does not have to be a good idea.

@kevincox
link
18M

I seem to remember this problem on Arch before systemd. But maybe I am misremembering. I also fail to imagine a way to avoid this issue, but maybe other systems are doing something clever that I didn’t think of.

@jazzfes
link
28M

I’m saying this as a casual hobby admin:

Systemd saying “it’s not my fault” and “so you think you’re better than me?” pretty much sums up my user experience with it.

To me, this just isn’t very inspiring. Each to their own I guess.

dandelion
creator
link
2
edit-2
5M

deleted by creator

@rep
link
98M

Gentoo uses it’s own init OpenRC but one can switch to systemd

dandelion
creator
link
38M

I posted this link because I liked what the page showed, but meanwhile I learned from the comments a few things about Systemd and its modular state and decisions that Linux distribution maintainers make. That was very good to hear. Thank you all !

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word “Linux” in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

  • 0 users online
  • 17 users / day
  • 56 users / week
  • 166 users / month
  • 446 users / 6 months
  • 4.83K subscribers
  • 1.77K Posts
  • 5.43K Comments
  • Modlog