I think this may be where I step off the train. I grumbled, but can live with it as init, and it is easy enough to disable the ntp and name resolution nonsense to use decent tools.
Buy systemd has no business sticking its nose in authentication or storage, or more generally telling me how to manage users. This is a no.
If you want to rage at systemd, you can do that equally well with or without this optional feature: nothing changes unless you specifically tell systemd-homed to manage your home directory.
Why does any criticism of systemd have to be due to "rage"? There is this ongoing behavior whereby anything other than fawning praise is treated as irrational and emotion-driven.
You may as well ask why Lennart rages so hard against ZFS.
So, explain this. I mean, it is a positive step that you've backed off your strange "rage" accusation, but why do you consider my stance on the technical merits of this step irrational?
Systemd is just an upstream project. It's up to your distro to ship it to you and then it's up to you if you want to use some feature or you want to do it a different way. This feature doesn't even do anything unless you create the user with "homectl".
If another open source program depends on it by default, then you can patch it to remove the dependency. If you disagree with the concept of JSON, feel free to write your own data format.
I have zero interest in using this feature, but still I find it really embarrassing that I have to regularly explain this basic concept of open source here. And I don't mean that as a dig at you, I mean it in the sense that there is a lot more work we have to do.
I decided to not act on it, take it easy and roll with defaults.
After all alternatives remained, it is an upstream project indeed, etc
But I took quite a bit of interest in the discussion as it raged on over the years those arguments you've used I've seen time and time again.
Especially this: "If another open source program depends on it by default, then you can patch it to remove the dependency."
and "then it's up to you if you want to use some feature or you want to do it a different way."
Now recently also Debian has decided to drop support for other init systems. It just wasn't practical anymore.
Now you get to be on the lookout when you "want to use some feature or you want to do it a different way." because if you don't you end up with shit like this: https://news.ycombinator.com/item?id=19291067
Now we get to see hilarious stuff like a systemd developer asking tmux to add systemd specific code to work around systemd's own default behaviour.
Now we get BSD's putting in work to deal with the prevalence of Systemd.
Now we get those working with embedded linux putting in work to deal with the prevalence and dependency on SystemD.
Because at the end of the day the systemd devs don't care about ulibc, non linux and what have you whilst at the same time seeming to really want to set the standard for as much as possible.
Or until e.g. GNOME requires use of this, and Firefox requires use of GNOME (thank God it doesn't yet). A computer without a browser is not terribly useful in 2020.
My problem with systemd really isn't what it does, though: it's how it does it. It's as though someone looked at late-90s Microsoft and admired the taste.
On the contrary, having a single blessed, supported, and secure home directory utility will simplify a lot of tasks around generating home directories and encrypting them. You no longer have to figure out/solve automounting, decryption/rotation, or realms using a litany of bash scripts or stack overflow snippets.
You are assuming that homed fits all use cases, which it certainly does not. It is opinionated and has a limited scope. This will add to the chaos, not subtract from it. I just hope the extra penetration of encrypted home directories is worth the added complexity.
$ man systemd
NAME
systemd, init — systemd **system** and service manager
managing your whole Linux system in an unified way, with a single configuration language to learn, a single syntax for commands, and a shared framework allowing to refer to systemd domain objects (units) from everywhere where they can be relevant (journal, network, fstab, etc) is the raison d'être of systemd. It's why it has been created.
Just saying the word system does not mean anything. Maybe my system encompasses more than a single machine, maybe it encompasses more than just silicon. Same with units. It is a word that means as little as possible. You did not answer my question, you just regurgitated vague and useless documentation.
Buy systemd has no business sticking its nose in authentication or storage, or more generally telling me how to manage users. This is a no.