21–30 of 132 posts
> What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. As a distro and philosophy, Archlinux was bound to adopt systemd eventually. e.g. Maintaining you're own init system/scripts is not KISS. Creating a custom init file to adapt 90% of software from systemd to another init system is not KISS.
Earlier quoted context omitted.
I think ultimately a lot of the systemd hate is just fear of change and not wanting to give up an init system they are famiiliar with.
For me it was the scope creep. Systemd is turning "init" into a framework of all the vulnerable and bad ideas that Microsoft moved away from after Win95/XP. binfmt mount, intercepting and changing the behavior of DNS, polkit implementation, changing user authentication, so much more than I could put here. There are many desktop concepts being shimmed into servers that are simply not appropriate for a lean mean web ma…
This is conflating the systemd project and they systemd init system. Most of the things you mention are seperate systems (systemd-resolved,logind, polkit, etc.) that are part of the systemd project and interoperate with the systemd init system, but are not part of the init system itself.
Earlier quoted context omitted.
For me it was the scope creep. Systemd is turning "init" into a framework of all the vulnerable and bad ideas that Microsoft moved away from after Win95/XP. binfmt mount, intercepting and changing the behavior of DNS, polkit implementation, changing user authentication, so much more than I could put here. There are many desktop concepts being shimmed into servers that are simply not appropriate for a lean mean web ma…
Is it correct to even say that systemd "brought" cgroups and lxc? They seem like fairly independent projects.
You can still use cgroups independently with systemd, but it's recommended that you use a service and the delegate option to have systemd create a cgroup hierarchy and also know that it shouldn't mess with it after creating it. This lets you have your cake and eat it too if you have a case that systemd doesn't handle (I'm working on a setup with this myself for a coding sandbox setup).
Looking back, I still don't get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I'm looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only…
I think part of it actually stems from people that had problems early on with PulseAudio, and have developed a vendetta against Poettering. Whether that vendetta is justified or not, I don't know.
Personally systemd hasn't been a pain point. It's been far less of a headache than everyone at the office thought it would be.
Looking back, I still don't get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I'm looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only…
> What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. As a distro and philosophy, Archlinux was bound to adopt systemd eventually. e.g. Maintaining you're own init system/scripts is not KISS. Creating a custom init file to adapt 90% of software from systemd to another init system is not KISS.
If you look for most decisions Arch took in the last years, most of them were focused in simplifying the distro and reducing the maintainer burden. So things like removing the TUI installer (does someone remember it?) and migrating to systemd. Even the fact that Arch ships with most packages with few or no changes compared to upstream is focused on it: reduce the burder on maintainer.
I really like logrotate and syslog and not needing journalctl for stdout/err logs from services. It's one of the things that makes working with Docker containers so much nicer too, because you have sane commands to get logs for services; way easier than remember all the weird switches for journalctl.
I like NetworkManager (this still hasn't been replaced in systemd, right?)
I still use OpenRC and Runit on Gentoo/Void respectively. OpenRC does dependency management but runit not so much. When it comes to building out VMs and stuff, I see the use of systemd for mount targets, but like I said earlier, I really hate the implementation in target files. It's so hard to make drop-in replacements for systemd that can run the same target files because of just how far it goes into the system.
For VMs at this point, I honestly prefer minimal startup and running everything in Docker. Alpine or RancherOS seem to fit this bill nicely. If FreeBSD had a current Docker API implementation, it would be perfect.
For my desktop, I prefer OpenRC or runit. It's just easier to do things and I'm not fighting with the system layer like I am in Windows. Then again I use i3 and prefer to have more control over my hardware, so that's just my use case I suppose.
Looking back, I still don't get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I'm looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only…
> just like PulseAudio does. I think part of it actually stems from people that had problems early on with PulseAudio, and have developed a vendetta against Poettering. Whether that vendetta is justified or not, I don't know. Personally systemd hasn't been a pain point. It's been far less of a headache than everyone at the office thought it would be.
Earlier quoted context omitted.
Is it correct to even say that systemd "brought" cgroups and lxc? They seem like fairly independent projects.
systemd did bring them mainstream, but yea cgroups were around for years before systemd was a thing. But they were mostly independently managed by some small daemons that did things based off rules and other things like that mostly. Systemd changed how they got used, primarily because multiple management systems working with them tends to cause issues, but using them for low impact isolation and tracking of daemons a…
Looking back, I still don't get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I'm looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only…
The problem is when "It just works" doesnt, it's an undebuggable, un-understandable, documentationless kluge with binary logs. I had it silently take over my DNS . I even have the 'official' way check-boxed to not override DNS settings in Network Manager. Does so anyway. I even removed the symlink from /etc/resolv.conf and made it root:root . SystemD changed it next reboot.