I just never get why people always flame on systemd. Sure, it's kinda bloated in the sense that it is "battery included" just like Python, but the intention to have a stable init with great system and service management is very good from both a DevOps and Sysadmin perspective. It is at least much better than writing your adhoc init.d script that may not guarantee to run on other Linux distros.
Systemd 252
71–80 of 317 posts
Re: Systemd 252
#72Earlier quoted context omitted.
I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?
systemd-logind(1) manages user sessions. If you want to replicate the functionality of what “nohup” used to give you, I am reliably informed that “systemd-run --scope --user $command” does the right thing. Or, you can enable it permanently for your user with “loginctl enable-linger”.
When I see “manages user sessions,” I don’t know what that phrase means. What is a “session” (again assuming not a POSIX session leader) and what are we concretely doing to “manage” it?
Is there a guide that explains the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years? I would never expect a non-sysadmin to have read the “systemd-run” or “loginctl” manpages or know how to find them. I’m a nerd and even I don’t know how to get to the point of understanding what https://man7.org/linux/man-pages/man1/systemd-run.1.html is trying to tell me.
Re: Systemd 252
#73Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.
Alpine linux seems to be doing fine without systemd.
But I almost never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora. Without systemd, bootstrapping a complicated desktop environment would be a hot mess.
Well, maybe you would say Alpine is not intented to run heavyweight stuff like that and is mostly focused on security and containers.
That's exactly what Alpine is, the OpenBSD of Linux distros. OpenBSD likewise cannot be used as your production powerhouse as well.
Re: Systemd 252
#74Earlier quoted context omitted.
Alpine linux seems to be doing fine without systemd.
But I almost never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora. Without systemd, bootstrapping a complicated desktop environment would be a hot mess. Well, maybe you would say Alpine is not intented to run heavyweight stuff like that and is mostly focused on security and containers. That's exactly what Alpine is, the OpenBSD of Linux distros…
>never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora
Alpine runs musl libc. This makes it buggy with all sorts of software that rely on glibc-isms, that makes it incompatible with proprietary drivers like NVIDIA and make it harder to run proprietary/binary software on the userland.
musl is developed by people with that sort of break-everything attitude : https://twitter.com/RichFelker/status/994629795551031296
There is a world of pain that awaits anyone with the expectation that this sort of distro could be used on a workstation.
Musl is really meant to be run.. with software vetted by communities like https://suckless.org/
Meaning things like dwm, dmenu, st.
Which may or may not be one's cup of tea. It certainly ain't mine.
Re: Systemd 252
#75Earlier quoted context omitted.
Quoted post unavailable.
That isn't so true anymore, given their focus on home directory management and killing all user processes on logout (desktop-focused and doesn't work well with tmux or ssh)
> killing all user processes on logout
This is a good default for the server use-case, to prevent developers and sysadmins launching stealth long-running jobs. (Especially if they steal resources.)
The idea is you'd run batch jobs and services explicitly via systemd-run.
Re: Systemd 252
#76systemd is fine for single user systems and perhaps verts, but I would never deploy it on a server. The deprecation of cgroup v1 is a welcome change. It's come a long way, but it still has a very long way to go.
Facebook runs lots of Systemd but I'm sure on your infrastructure you couldn't run it.
Re: Systemd 252
#77Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.
I had to chattr +i /etc/resolv.conf because my resolv.conf would keep getting truncated (as in empty) every time I restarted an lxd container. Rock solid my ass.
Why is lxd touching that file?
Re: Systemd 252
#78Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.
+1 for systemd-networkd too: it let me declaratively describe some netns/ipvlan interfacing the other day that netplan et al simply couldn't. It could use with some more netns awareness but its pretty great at the current stage
You can still let netplan use systemd-networkd as the renderer, though in some cases some overrides are necessary.
Re: Systemd 252
#79Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.
I had to chattr +i /etc/resolv.conf because my resolv.conf would keep getting truncated (as in empty) every time I restarted an lxd container. Rock solid my ass.
How is that a systemd issue?