systemd's Growth Over 2022

[Berniyh]

Don't forget the standardization that happened, also due to the change to systemd, which is really important, when it comes to supporting Linux from a developer perspective.
e.g. if you got something working on Ubuntu, there was no guarantee that you could get it working in the same way (of course with using, dnf, pacman or whatever instead of apt, if necessary) on Fedora, SUSE or others, because some files were in different places, bin and lib were treated different in some distributions etc.
Now, they are mostly structured the same way and tutorials are usually transferable (again, minus package management tools, although even that was kind of standardized by packagekit).

[sinepgib]

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.

You seem to believe modularity is a binary condition and not a spectrum. You also seem to assume when people talk about something being more modular it's either an insult to the project (hint: I support systemd, and while nowadays I shill s6 more I shill the hell out of systemd) or about packaging stuff together. The modularity I'm talking about is simply loading in runtime just the things your particular system uses. Much of the software we use can benefit from that, and certainly coreutils does that.

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?

Lots of people criticize glibc, and its hard requirement of it is what makes it harder to use in embedded, where paradoxically it would add tons of value.
Regarding splitting in packages, please don't. That's some Debian nonsense we don't need, systemd is a whole package that works much better integrated.

cron via systemd is a pain.

Please tell me you mean timers.

providing only dbus as an rpc is insane.

Luckily that's not the case? You can use any kind of socket in your services. Or you mean for systemd services to interact with each other? In that case, eh, I don't know why they went that way. I would also not have that much functionality depending on D-Bus, tho it has its advantages.

networkmanager is still not using networkd as a backend

AFAIR there's a backend for systemd-networkd. Not sure tho, I avoid it like the plague.

nor do they have parity

This is true and I'm personally glad they don't. If you want the heavyweight because your usecase demands it just use it, but I find it covers far too many cases compared to what most people actually uses.

desktop environments just has the bare integration, and still doing things their own way

That's not systemd's problem really. That's more a relic of how they had to work in pre-systemd days really. They typically aim for compatibility with systems not using systemd too, so it's unlikely to change.

systemd is very modular (i know because I disabled a few of the modules), so I have no issues with it there.

It is very modular, but some components could be more modular. I specifically think of networkd and its management of multiple tunneling/VPN protocols. IMO those don't need to be a part of the base DHCP/interface config daemon. Note I love networkd as it is tho. I used to disable NetworkManager and move to networkd first thing after installing Ubuntu. Now I moved to Arch just because it made more sense for me: what's the point of installing an easy to install distro just to waste hours and hours disassembling it for it to stop being nonsense. Obviously I use networkd there as well, just not with the NM dance.

I'm not even complaining about their roadmap, I just don't believe that systemd will forever be the final word on service managers.

Oh, but I think most of us agree there, supporters (mostly?) think it's just a huge improvement over what came before. I believe for every big jump in functionality there comes a refinement later tho. Kind of like "systemd, the good parts". But you always need the somewhat dramatic change first to battle test ideas and pick which ones need to be in the next iteration.
I'm not sure what their roadmap is tho, other than the vague-ish claim of wanting to be the base userspace.

[sinepgib]

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.

I mean, I don't disagree. But the other problem simply breaks your systems on its own. I can tolerate some confusion, but random broken boots is intolerable.

[Berniyh]

You seem to believe modularity is a binary condition and not a spectrum. You also seem to assume when people talk about something being more modular it's either an insult to the project (hint: I support systemd, and while nowadays I shill s6 more I shill the hell out of systemd) or about packaging stuff together. The modularity I'm talking about is simply loading in runtime just the things your particular system uses. Much of the software we use can benefit from that, and certainly coreutils does that.

Ok, so you're basically talking about splitting up libsystemd, libsystemd-core and libsystemd-shared?
hm, I don't know if the benefit would be that huge, tbh.

[sinepgib]

Ok, so you're basically talking about splitting up libsystemd, libsystemd-core and libsystemd-shared?
hm, I don't know if the benefit would be that huge, tbh.

No, maybe, I'm not sure, I'm spitballing here. I think probably splitting some of the services into tinier (but equally well integrated and sharing a single configuration format) daemons. I think the libraries are modular enough already, not 100% sure.
The benefit would mostly be reduced memory usage (granted, it may not be that important for desktops, but it would enable embedded use) and reduced attack surface. Code that is not running is not a liability, code that is running is.

[Berniyh]

Ok, I see.

[fitzie]

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.

so instead of setting up one line to start a cronjob, now I have to create two files with tons of mandatory options, place these in the right directory, run the correct commands, worry about if loginctl linger settings are correct, and for all that, I don't even get an email with the stdout.

just tell me if your systemd system still has cron/crony/at still installed. i'm guessing the answer is "of course it does".

[sinepgib]

so instead of setting up one line to start a cronjob, now I have to create two files with tons of mandatory options, place these in the right directory, run the correct commands, worry about if loginctl linger settings are correct, and for all that, I don't even get an email with the stdout.

just tell me if your systemd system still has cron/crony/at still installed. i'm guessing the answer is "of course it does".

Mine doesn't. It's not necessary. Besides, I'd much rather go through that dance than not know whether the environment I tested things on is the same cron will run them with, not having a straightforward way to test the command other than play with its obtuse language (there's a reason you have websites explaining you what a given cron expression represents) and try to make it run often to see its effects and all that nonsense. Not even talking about what you mention yourself: rather than having a single language that I can just template and call it a day I have to deal with at least two different programs just so my damn logs get rotated often enough. That's a hard pass.
I can understand not wanting to be tied to a given init for that, but that doesn't make the cron model correct, it just means systemd could be more modular or a different, separate solution that actually makes sense is needed.

[ll1025]

so instead of setting up one line to start a cronjob, now I have to create two files with tons of mandatory options, place these in the right directory, run the correct commands, worry about if loginctl linger settings are correct, and for all that, I don't even get an email with the stdout.

just tell me if your systemd system still has cron/crony/at still installed. i'm guessing the answer is "of course it does".

Getting some serious "old man yelling" vibes.

Systemd timers are different than cron. Yes, you need to create a new file, like you do with many tasks: adding system certs, customizing sshd, creating login scripts... there's an entire concept of dump (".d") directories specifically around this.

And "place these in the right place and run the right commands" describes the entire process of using Linux, nay of operating computers. I suppose my entire resume could be summed up "created the right files in the right places and ran the right commands". Surely you can see how ridiculous these complaints-- which boil down to inexperience-- look?

It's not terribly difficult: you have a .timer file which simply describes when it goes active and what service it is linked to, and a standard .service unit file.

Cron is a total mess by comparison, nigh unreadable to the uninitiated without referencing the manual, easy to get wrong, and terribly limited in its execution. It cannot deal, for instance, with missed execution times, or execution linked to post-boot time, or even validate that the system is in the correct state (services started) prior to execution.

Frankly if you can't figure out .timer files you're going to have a rough time with modern linux administration.

[fitzie]

Getting some serious "old man yelling" vibes.

Systemd timers are different than cron. Yes, you need to create a new file, like you do with many tasks: adding system certs, customizing sshd, creating login scripts... there's an entire concept of dump (".d") directories specifically around this.

And "place these in the right place and run the right commands" describes the entire process of using Linux, nay of operating computers. I suppose my entire resume could be summed up "created the right files in the right places and ran the right commands". Surely you can see how ridiculous these complaints-- which boil down to inexperience-- look?

It's not terribly difficult: you have a .timer file which simply describes when it goes active and what service it is linked to, and a standard .service unit file.

Cron is a total mess by comparison, nigh unreadable to the uninitiated without referencing the manual, easy to get wrong, and terribly limited in its execution. It cannot deal, for instance, with missed execution times, or execution linked to post-boot time, or even validate that the system is in the correct state (services started) prior to execution.

Frankly if you can't figure out .timer files you're going to have a rough time with modern linux administration.

i understand that you really want to insult me, but it's really lame and only degrades your (weak) arguments. See how that works? Your defense of the twenty extra steps that systemd timer launched services have over crontab is that it's necessary. Well that's not really true, cron worked for a long time, and most users were okay with the edge cases. Also you argue that it's a 'standard .service unit'. Well for people who manage systems that's true, but some users hire other people to manage systems, and they just use the machines. Now they are forced to wrap their heads around systemd, search forever trying to look up what the right service type is, or even the name of the man page that will explain the information. just because systemd is more capable, that doesn't mean that dumping complexity on the end user is somehow necessary or a good thing. and I really don't mind the timer scheme, I'm just saying the experience is overly cumbersome, and because it is, I expect that it will get replaced with something more convenient over time.