systemd's Growth Over 2022

[fitzie]

Which features are unnecessary is subjective. Just because someone in particular doesn't need them or use them doesn't make them unnecessary.

all things come with a tradeoff. i am very happy with the design approach systemd took to try to replace all the old ways of doing things and to leverage linux kernel features to the max, but at the same time the larger ecosystem around core system services is not entirely well integrated, and systemd implementation is overly complicated.

said another way, if something gains enough popularity to replace systemd it will not be because it has more features, but that it fits the problem space better, and it is overall a simpler approach. I will look forward to that.

[sinepgib]

all things come with a tradeoff. i am very happy with the design approach systemd took to try to replace all the old ways of doing things and to leverage linux kernel features to the max, but at the same time the larger ecosystem around core system services is not entirely well integrated, and systemd implementation is overly complicated.

What exactly is not well integrated or overly complicated? The statement seems rather vague.
I'm all for better modularity, but there's a distinction between modularity (isolating complexity and making the features' cost appear only when you use them), simplicity (reducing complexity, often at the cost of reducing functionality) and fragmentation (modularization by lack of integration, non-justified competing products). For the latter, there are a few valid reasons to make competing products that I wouldn't strictly call fragmentation, which is when the problem space is actually different, say a different, less featureful but lighter DHCP daemon (or even non-daemon, just a one shot that runs periodically) for more severely resource-constrained systems.

said another way, if something gains enough popularity to replace systemd it will not be because it has more features, but that it fits the problem space better, and it is overall a simpler approach. I will look forward to that.

I'll keep shilling s6 with regard to this

[ll1025]

I'm going to wade into this systemd hatefest (always a good life decision) and say-- the criticisms that its growth seems endless may have merit, but that's largely because there's a ton of cruft to fix in Linuxworld:

• Journald is legitimately better than trawling through /var/log looking for that one culprit
• resolv.conf is a relic with no support of modern protocols or complex scenarios and NM is a terribly janky way of working around its limitations
• ntpd is a mess of black magic and chrony is fairly new
• cron is a painful relic with severe limitations

Should those things have been bundled in with an init replacement? Maybe not. Maybe that's not unixy. But you know what? These are problems that I'm sure most people have at least once said "good grief that's awful" about, and never bothered to fix. Resolvd isn't being pulled into RHEL because of a conspiracy but because there's a problem and this provides a fix.

I wonder what could be accomplished if, instead of complaining, all of the detractors simply banded together and made a Unix-philosophy solution to these problems. Or maybe those detractors don't think they're problems, which is great because they can use the distros that haven't adopted systemd-- and the rest of us can get on with briefly configuring them and moving on with our lives.

TL;DR if systemd components are really so horrible, the haters should group up and make a proper alternative.

[sinepgib]

Journald is legitimately better than trawling through /var/log looking for that one culprit

Trawling through /var/log isn't that much of a problem. Decoupling log rotation from log generation is the dumbest take on "The Unix Way". I don't care how you log, but don't fill my disk because the computer was off when logrotate was supposed to run. Which also plays with cron being a breathing disaster.

[fitzie]

What exactly is not well integrated or overly complicated? The statement seems rather vague.
I'm all for better modularity, but there's a distinction between modularity (isolating complexity and making the features' cost appear only when you use them), simplicity (reducing complexity, often at the cost of reducing functionality) and fragmentation (modularization by lack of integration, non-justified competing products). For the latter, there are a few valid reasons to make competing products that I wouldn't strictly call fragmentation, which is when the problem space is actually different, say a different, less featureful but lighter DHCP daemon (or even non-daemon, just a one shot that runs periodically) for more severely resource-constrained systems.



I'll keep shilling s6 with regard to this

cron via systemd is a pain. providing only dbus as an rpc is insane. networkmanager is still not using networkd as a backend, nor do they have parity, desktop environments just has the bare integration, and still doing things their own way. systemd is very modular (i know because I disabled a few of the modules), so I have no issues with it there. I'm not even complaining about their roadmap, I just don't believe that systemd will forever be the final word on service managers.

[ll1025]

Trawling through /var/log isn't that much of a problem.

Go troubleshoot *anything* involving authentication against Active Directory with SSSD debugging turned on and then lets talk. Is it in /var/log/secure? /var/log/sshd? or in the absolute trashdump that is /var/log/sssd? Heaven forbid you're dealing with GPO-based HBAC, because it will literally be all 3, at the same time, in text-based logs with no consistent format.

Decoupling log rotation from log generation is the dumbest take on "The Unix Way". I don't care how you log, but don't fill my disk because the computer was off when logrotate was supposed to run. Which also plays with cron being a breathing disaster.

You're absolutely not wrong but I think people give a pass to how bad text logs are and it smells of Stockholm syndrome.

[Berniyh]

I'm all for better modularity, but there's a distinction between modularity (isolating complexity and making the features' cost appear only when you use them), simplicity (reducing complexity, often at the cost of reducing functionality) and fragmentation (modularization by lack of integration, non-justified competing products). For the latter, there are a few valid reasons to make competing products that I wouldn't strictly call fragmentation, which is when the problem space is actually different, say a different, less featureful but lighter DHCP daemon (or even non-daemon, just a one shot that runs periodically) for more severely resource-constrained systems.

How is systemd not modular? Because multiple tools are distributed in one package?
That would be like criticizing coreutils for shipping more than 100 tools in one package.

Sure, you could split systemd into 20 packages or so, but what would be the gain? A complete systemd installation is something in the range of 60-70MB. That's in the same range as glibc and I don't see people complaining about glibc here?

[Berniyh]

I just don't believe that systemd will forever be the final word on service managers.

I don't think anyone claims that. Only, that it is a major step forward from the last service manager.
The latter one really being a huge embarrassment for the Linux world back then.
Actually the embarrassment doesn't only include pure Sys-V-Init, but also all the hacks that were invented to try to workaround problems of dynamic events. Talking about coldplug, hal, devicekit and the rest of the misery. If you used Linux in the 2000s, I'm pretty sure you know what I'm talking about.
I think some people really should go back to a distribution from 2000, 2005, 2010 etc., just to see whether things were really that great …

[ll1025]

cron via systemd is a pain.

Systemd doesnt do cron, it does its own thing which has more capabilities such as having a unit run based on event.

If you're findinding it painful to work with, Cockpit makes it drop-dead simple.

[ll1025]

I think some people really should go back to a distribution from 2000, 2005, 2010 etc., just to see whether things were really that great …

My favorites were X breakage on the regular and IP addresses attaching to the wrong adapter at boot because the boot up adapter naming process seemingly involved a pair of dice.

The last 10 years have been a huge leap forward, between systemd de-janking a ton of systems, firewalld substantially improving the iptables experience, and Network Manager eliminating a ton of footguns.

10 years ago I would not recommend an average user use linux because it felt entirely too much like it was built on baling wire and chewing gum. These days-- in large part because of projects like systemd-- it actually feels like a cohesive system. I honestly think that systemctl and journalctl are the best qol improvements to everyday systems administration in that time.