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
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
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.
And coding best-practice. And a philosophy borne of bad luck and bad software that aims to resist monoculture.
But that lennart kid is cool for a Microsoft employee.
@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
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…
That sounds like a design decision (not saying it’s good or bad here), not something broken.