I’m old enough to remember the culture wars and even older to remember a well thought out approach to overall configuration in Debian given the available tools of the time.

Note I said “good” documentation - many Linux systems have lousy documentation and they lack an obvious, sanctioned way to do it. Again, that’s the problem.

Defining a straightforward configuration structure for that complexity is going to be insane. NetworkManager + Debian's /etc/network/interfaces (IMHO) seems to be a good fit: auto config w/ a GUI in NM in the simple case, and if the interface is listed in /etc/network/interfaces, you can do it anyway you want with Debian's system, with pre-up, up, post-up, post-down, etc scripts to your heart's content to setup whatever complexity you need.

NetworkManager is god awful in this regard. Even for simple desktop uses, if I want something more advanced than simply connecting to the Wi-Fi (even this requires finagling), then I'm fucked.

For example, I've been trying to find what it is that keeps overwriting /etc/resolv.conf.

After reading through various man pages and online forums, I still don't know. Instead, I just stick to one access point, and manually write to /etc/resolv.conf everytime I boot.

Compare this to OpenBSD: nothing fucking touches my /etc/resolv.conf. That file is mine. I write to it and other daemons read from it.

  chattr +i /etc/resolv.conf

What specifically is a pain? Have you used it recently?

Maybe my end-user desktop network requirements aren't complex enough but it's been pretty damn smooth in my experience for the last few years. I used to avoid network-manager with wicd, but now it seems pretty stable. I use the network-manager and network-manager-gnome packages to get the toolbar thingy in i3wm, it's very simple to use. I also combine it with wiregaurd using the wg commands.

Are you doing something more sophisticated like routing traffic? or something else in a server context? I literally can't recall having a single networking issue that was Debian's fault over the last few years, throughout using lots of different APs.

[1] I'm a developer who can admin a Unix system if forced to, but how to administrate Unix has changed at least three times since I first learned in the mid 90s, and I'm tired of the constant changes (shakes my old-man fists at the sky).

Wonder if it solved it. If not, what's the fuss.

It's like somebody decided that the problem with Linux was it wasn't complicated enough. And then everbody just went with it.

I find it much easier to reliably accomplish non-standard things with systemd unit definitions, than it used to be with the ill-defined complex set of shell scripts we had before.

systemd management of mounts can be similarly narrow about the types of configurations it supports, and systemd-firewalld just sort of openly only claims it can support simple use-cases.

systemd-journald is also a net loss of flexibility compared to rsyslog but, on the other hand, rsyslog could quickly turn into an inscrutable mess if you used any of the advanced features (rainerscript...), so this may not be an entirely bad thing.

And in general systemd is, well, opinionated. I hate to bang on resolved too much but I just happen to have spent quite a few hours last week figuring out resolved problems. Resolved does not handle "dotless" domains correctly in a lot of existing environments (it's very particular about exactly how the search domain is set up). Poettering has basically responded that it's because dotless domains are stupid and no one should use them, so it won't be changed. I don't necessarily disagree that dotless domains are not a good idea today but it does mean that resolved breaks a lot of older corporate and institutional environments that have been using them successfully for decades. This manifests as "I updated my distro and the intranet stopped working." That kind of breaking change is not very common with core Linux services and isn't going to make many friends in the IT crowd.

But, I am 100% agreement on the whole resolvd thing. It is a complete fiasco for anything but someone's idea of a standard network.

Even the most basic things, like waiting for DNS to be up before mounting a network filesystem has to be done by writing your own units if you don't want to just try and mount and hope for the best.

Consider a situation, where your sh-backed SysV init was missing some function you required. Something between start-stop-daemon() or ifup(). You could throw a bunch of shell commands (note: most shell "programmers" are not capable of doing it properly; they do some '==' comparisons in /bin/sh shebang, don't handle errors, ignore fact that variables might contain "funny" characters etc. - but in general most of the scripts I've seen during my 24 years in Linux was simply badly written, meaning at least using bashizms). And then ...you watch out for every single package update that would overwrite your changes. Or you could polish them and try to push upstream.

Now the situation seems to be worse - you can't just edit some random file to add missing function, you need to write it in source C files and recompile. Not a way for quick and dirty solution.

But instead, you can simply write the same (s)hell commands in a script and call it from appropriate unit. No messing with thousand-lines scripts, no risk of overwrites, no need for upstreaming.

I’m sure there are many other examples.

Honestly, even after 10 years, I still have’t had a single positive interaction with it vs. traditional init. From what I’ve seen, old-school init handled (and continues to handle) the problems systemd “solved” more robustly and elegantly. I don’t get it.

[citation needed]

I remember spending days reading the arguments on the Debian mailing list. There was no push from systemd devs. (Endless threads about upstart, how tweaking upstart would solve everything and it's already in Ubuntu, and a lots of questions about guarantees. Are openrc/upstart/systemd maintainers willing to guarantee this or that? And as far as I remember, there were no guarantees, obviously.)

Before that when the hwdb and udev merged into systemd, people got the pitchforks out, it was the decision by Kay, but obviously "systemd devs" were somehow behind it.

When Greg KH supported kdbus, somehow it was again those meddling systemd devs.

Somehow OSS veterans just lost their agency overnight and became puppets? Nah.

We are talking 10 years ago, not 1975 here. Unless everybody is 25 years old on HN...

Random system breakages for stupid reasons.

And everything hardcoded the ugliest way possible so that it is impossible to have alternate systems like some embedded ones.

Do you have any links for these statements? My memory is not great but I think I would remember anything similar to this.