Systemd is a suite of basic building blocks

You're taking a slant on the rally, to turn a possible downside into something greviously fatal. That's not intrinsic in what I was talking about. We can have clear identifying gathering points, touchstones, blog posts, etc that call the cause without having to hide and conceal. This argument you are making is extremely uncharitable, and assumes bad motives from the start.

This is just a descent into more fervor, saying nothing. Let's skip the stupid lawyerly word picking of zero value contestation. Please.

I think the macro subject stands. In neither the old world where everyone was doing their own thing nor the new one where >50% use systemd to run a significant amount of their systems: in neither case was or is there a strong practice of sharing and doing the work of exchange (certainly not without counterexample, yada yada, and I've already provided some in other threads, namely AOSA, but I stand by my assertion here). We can ignore which path is better, and simply say: both paths should do more to create broad discussion, ideally that is constructive, that covers what is working, the big picture outlook, and the negative sides of the world they're living in.

I think of that as rallying not to zealotry, but as rallying to understanding, trying to draw people in, so we can see and perceive what are in fact stable, alluring points of the world. So that we can let people know what an option might be. I think the Din and Darkness is winning against those who want to gather and protect the light. The anti forces are everywhere and persistent, the doers are quiet and busy. Civilization would be healthier with more deliberate work to share the light, to show and exchange specifics (as most systemd touching blog posts do) but also broader pictures, wider stances.

That you don't know what I'm talking about when I say least least privileges isn't stunning. Because almost no one took any precautions with how processes ran and only some people realize you should! Even though systemd makes it so so easy, and integrates many many different mechanisms and systems for locking down what procesess can do and what they have access to. SuSe has an ok page, but this is barely the tip of the iceberg they are covering. There are temporary users, sandboxed filesystems, all sorts of stuff more! https://documentation.suse.com/smart/security/html/systemd-s...

"cgroups are a kernel feature that is quite straightforward to use without systemd". Oh, you've used cgconfigparser? You run your services via cgexec? You found cgrulesengd to be pleasant and productionally operizationable? Or did you have a bash /etc/init.d/set-my-cgroups with 30 hardcoded lines of things twiddling /sys/fs/cgroups files? C'mon my man. No one did either of these! Or at least very very few! Today Cgroups work incredibly well, out of the box, with no thought, and have a very sensible coherent pattern of use, that benefit all Linux users. And which is incredibly tweakable. Since systemd. Because of systemd. You're not being remotely intellectually honest & your suggestion that this was "straightforward" maybe comes from you being a master sysop with decades of experience for who this came second nature, and if that's so I think you have no idea how most code ran. But I think you are just blowing smoke, making up nonsense.

I too ran years of libnss-mdns and avahi-daemon (another Lennart project btw). It worked for a decade, was fine. I'm glad systemd-networkd (advertising) and systemd-resolved (finding) just integrate these concerns for me, alongside everything else they just integrate amazingly, a drop-in file like everything else if I want. It's easier to scope & keep on top of which networks I do what mdns on. This is the weakest win of these three but it's still to me a sigificant win.

To reframe: I realize that this was an off the cuff take-down, not a blog post in aggression of systemd, but you must know that every time a systemd hater tries to throw salt like this, full of "do we really win" that no one ever did before, the impression is only further reinforced that what the haters really got is nothing.

Systemd composes incredibly well, with the way etc drop in files work. With the consistency of how it has different unit types that work together. With how units can BindsTo= and have After= and other patterns. There's a pretty amazing toolkit here that relates multiple parts together to form a very cohesive explorable and regular system, that many people know and understand. It helps you make really good use of all sorts of kernel capabilities like cgroups, like their namespaces, to help you juggle/constrain annoying system-hogs, to maintain better responsiveness, to lock down access to daemons. This is still just the tip, of a mono-repo of many projects all of which have common operational patterns and nice tooling, almost all (except to much hew & cry & perhaps rightfully so: journald) of which be disabled. "Just marketing" is a statement professing profound disconnect & ignorance.

Bash doesn’t just stop working because the x86 CPU is inside a different form factor. And actually Linux (and BSD too) did used to run on commodity desktop for local ISPs, newsgroups and so on and so forth. That was part of the reason for their success story: Linux and FreeBSD meant smaller Internet-facing business in the late 90s didn’t have to buy expensive mainframe hardware to run Unix software.

The issue with Linux on the desktop, and especially the laptop, in the pre-systemd days wasn’t the init system. It was the lack of quality drivers.

Now I’m not saying that systemd hasn’t brought improvements over sysv. But to say bash worked badly on laptops but fine on servers is just silly. That’s simply not how the technology works at all.

And I don’t need to read some promotional piece from Redhat to know this. I’ve been running Linux on desktops and laptops longer than many adults have been alive. So I’ve lived through these massive ecosystem changes and have a first hand account of life before systemd.

Fair point.

Analogies only go so far. Driving an actual tank with a cannon to the grocery store 10 minutes away is ludicrous, but my smartphone has gigabytes of both ram and storage and a CPU that runs at gigahertz frequency, but weighs about the same as a dumb phone that does far less. It's not the 1970's anymore. We can be inefficient and stop counting every single little bit where it doesn't count. Yes, where it counts, we still want to be efficient and mean and lean, like in transcoding, but for starting up services on a laptop with gobs of ram and CPU cycles to spare, the added expense of the tracked vehicle to the grocery store is what, an extra 100 milliseconds of loading data from nvme storage to RAM? Yeah, don't port kubernetes to a microcontroller. Focus on the interface you have with it and let the complexity just sit there, being harmless.

This. I can see the utility of systemd and probably would have liked to have it when my team was riding herd on a DC full of Sun E15Ks and HP Superdomes. But for basically everything else that I use Linux for, every time someone says "systemd does this", at least 50% of the time I don't need that, and most of the rest I could do with with other tools with vastly less complexity.

Those jenga towers were terrible, many didn't work very well. Very few had good monitoring, ops, reliability, least-privleges.

It's unbelievable to me to hear people advocating for not having good broadly usable systems, to advocate that sysadmins really should spent their time and energy building bespoke custom cut weird poorly invested in little things to suit their own fancies. It's not helping the company to do this. And to me it's such a weird antisocial vibe, that is radically vocal, that shows up all the time to proclaim everyone everyone else is doing the wrong thing by working together and making tools that fit together, have cohesion. Theres never any suggestions for how or what that looks like either, just the image of not working with others is the only thing presented to sell itself. This is din. This is havoc. This is hell. Don't do it people. And alas, we have to endure this attitude every single time. The forces against cooperation are doggedly persistent and vocal. The forces for just build your own thing, this unreasonableness, is radically overrepresented.

This is why I was so hopeful this submission was going to be a nice new post kind of re-selling where we are today with systemd. Because the pro-social forces are weirdly not bothering to get the social / cultural victory. And those driving us apart telling us to each do our own thing, figure it all out yourself: they are endemic, dime a dozen on social media.

> What use cases of "proper server management" does fucking with my resolv.conf(5) solve?

For one, it avoids telling all processes and their mothers the IP of the DNS resolvers they should query, but hands them 127.53 instead. If you then update your resolvers using systemd-resolved, for example because the network changes to a failover line, or because puppet pushes an updated catalog, or you want split DNS for a VPN (like, send *.corp.local to the internal DNS server or something), that is all pretty easy. There are more use cases on servers, but of course you most obviously benefit from this on laptops that roam between WIFIs with different upstream DNS server config.