Heck, the author of this article couldn’t even find a design doc or adequate manual for the init part of the train wreck, and it’s been in development for ten years.

I ask not rhetorically, just out of curiosity. It's not a typical type of suggestion for other packages I've encountered with open source, and it feels far more difficult to discover than typical decisions at compile time.

Define “usual people who compile this package”. In my books those are distro maintainers who indeed should be familiar with options provided by the init system they choose. If you decide to include oddballs who compile everything themselves (Linux from scratch?) then again, yes, they are expected to know a thing or two or dig into options or even code from time to time.

In this case it should be assumed we’re talking about someone who’s compiling systemd and familiar with the source. And yes, these are flags that anyone who builds systemd from source would be familiar with and know how to set.

It’s the same as when you run a configure script and pass —-disable-feature.

Furthermore, even if you compile it, you don't have to use it. Even if you install it, you don't have to use it. (After all it has 2-3 APIs, one of them is the /etc/resolve.conf symlink, if you instead just put 1.1.1.1 in that file, libc will not go through resolved. And similarly for the other entry points.)

It's possible to accidentally compile, install and have systemd-resolved set up on your computer, but it still seems rare that someone can compile and install systemd, yet not know what they're doing.

From HHGTTG:

"But the plans were on display …"

"On display? I eventually had to go down to the cellar to find them."

"That's the display department."

"With a flashlight."

"Ah, well, the lights had probably gone."

"So had the stairs."

"But look, you found the notice, didn't you?"

"Yes," said Arthur, "yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.'"

And that's exactly the problem.

For all the complaining I do about systemd, I'd be much less annoyed with it if all it did was PID 1. It's all the other stuff that gets tightly coupled for no discernibly-good reason that poisons the well for me.

Unfortunately, currently systemd-resolved is the only OS level DNS-Over-TLS solution that works for my use cases: roaming laptops and desktops running Linux. At home it's fine because the core router runs AsusWRT-Merlin which does DNS over TLS for all clients using it as resolver.

I don't have a strong opinion against systemd (initially I disliked it moving from Arch's BSD style rc.d). Trend is that systemd is taking over more and more *ctl, seem like its goal is the entire user-space?. Most distros choose to accept and adopt it, and overall (at some point) it eliminated distro differences and lowered the barrier for new Linux users (desktop) and sysadmins.

Personally I started systemd when it rolled into Arch Linux, after which point, rolling upgrade has never gone broke (workstation use case - Desktop Environment / WM), could be skill levelled up after gaining experience though lol...

BTW: I watched `reinventing home directories` by Lennart Poettering (recording @ All System Go! 2019), interesting one. Personally I like to see reinventing wheels to solve legacy problems (people get used to them, sometimes confused, question but don't know how to solve) others don't even consider problems. These helped open my mind and look at things from a different PoV.

[1]: notes on systemd-homed https://sites.google.com/site/imterry/aboutme/profiles/skill...