What's your favourite OS that does not use systemd?
What's your favourite OS that does not use systemd?
systemd cat and GNU cat hugging a Linux cat.
You're viewing a single thread.
System service managers like systemd, OpenRC, runit, or SysVinit often come down to user preference. While these systems are crucial for initializing and managing services on servers, where uptime, resource allocation, and specific daemon behaviors are important, their impact on a typical desktop or laptop is generally minimal.
For most personal devices, the primary functions of a service manager occur largely out of sight. As long as the system boots reliably and applications run smoothly, the underlying service manager rarely registers as a significant factor in the daily user experience.
For many, including myself, systemd simply works without much fuss. My choice to stick with it isn't due to strong conviction or deep technical analysis, but rather the simple fact that I've rarely, if ever, had to interact with it directly. For my personal desktop and laptop, it reliably handles booting, service management, and shutdown in the background. If it's not broken and isn't hindering my daily computing, there's no compelling reason to explore alternatives.
@furycd001 @nutbutter Technically, it's broken. If you run screen/tmux built without systemd support, it will be killed on logout. Systemd requires every program that needs daemonize link libsystemd0 only to notify systemd to keep it running. So it's broken, but worked-around in every software which need daemonize
If you run screen/tmux built without systemd support, it will be killed on logout.
Actually, if you run anything and logout, it will be killed after a timeout. The way to prevent this in systemd land is to enable-linger for that user.
IMO this is a pretty sane default and it's easy enough to disable for users
EDIT: For non-root users
@InnerScientist This might be good behaviour (especially on shared multiuser system)
But how often you using shared multiuser systems in 2025? In 2015? In 2010 this might be useful, but now we are using containers instead.
When you have single root user, single unpriveleged user and few service users, such behaviour is just useless. If interactive user left some services running, it's usually intentional. And systemd requires notify about this intention every time. Why? It's just useless complexity.And systemd requires notify about this intention every time.
Systemd requires a one time fee of
loginctl enable-linger myserviceuserto never kill processes with a timeout for that user again. This behavior also doesn't affect system users, only normal users.I think the main purpose nowadays is to stop pipewire and other user services that don't need to consume resources when that user isn't logged in
Systemd requires every program that needs daemonize link libsystemd0
No, that's only if you want the health check feature, so that systemd can distinguish between e.g. "The process is started" and "The HTTP server is bound and listening"
You can run hello world and a
sleep()loop as a systemd daemon. You can run a Bash script as a systemd daemon.I'm pretty sure that notification is also like 5 lines of code. You read an env var and that tells you a pipe to send a single character on.
You are not obligated to use libsystemd. And if you were you could certainly layer another init system inside of it
So, running a program incompatible with a particular system leads to incompatibilities?
Wow, who'd have thought...
@lka1988 why systemd needs some extra compatibility? If it designed to work, it must just work, not requiring changing evertyhing around
Ok, let me spell this out for you:
IF YOU RUN A PROGRAM THAT IS INCOMPATIBLE WITH A CERTAIN PART OF THE CORE SYSTEM, DON'T BE SURPRISED WHEN IT LEADS TO INCOMPATIBILITIES.
That sounds like a design decision (not saying it's good or bad here), not something broken.