> So, for the simple act of logging in, three mechanisms are required (systemd, /etc/shadow, /etc/passwd). This is inefficient, and Poettering has decided to make a drastic change. That change is homed. With homed, all information will be placed in a cryptographically signed JSON record for each user.

10 years ago this would have been considered satire

homed is a purely optional, independent tool, for use in situations where you’d use roaming home directories on windows, or similar technology.

No one is forcing you to change your broken buggy 30-year old shell scripts, you can always continue using them.

> No one is forcing you to change your broken buggy 30-year old shell scripts, you can always continue using them.

How about usernames that start with a digit? Am I still allowed to use those?

* https://ma.ttias.be/giving-perspective-systemds-usernames-st...

POSIX says that any tool should always translate usernames into userids at the earliest possible point, and pass UIDs to children it spawns.

Now assuming I have a user called 1000 with UID 2000, and a user called 2000 with UID 1000.

Now what do you think is gonna happen if multiple POSIX-compliant tools call each other?

This is clearly broken, and the reason why BSDs don’t actually implement POSIX cleanly, instead allowing all their tools to take unambiguous identifiers on the CLI, with the # prefix to mark a UID, and have all their tools call all their children with this format.

The POSIX standard is clearly suboptimal here, and the set of valid usernames, and the set of valid UIDs should never have been allowed to overlap.

The weblog post has an user called '0day', i.e., "zero day". This breaks systemd as outlined in the post. This is a WONTFIX per the systemd folks.

That’s one of the possible options, the other would be replacing chown, chmod, ls, etc (as the BSDs do)

This must be satire, not? Because soon my .forward won't work, my .procmailrc won't work, my crontab scripts won't (etc pp) unless my encrypted home directory (planned to be decrypted on login) is decrypted. Or all these are moved to other locations.

Or you opt to not encrypt your home separately.

But how large a proportion of machines do you think have mail delivery rely on .forward or .procmailrc in $HOME these days?

In any case, procmail can be executed directly rather than from .forward in most cases, and can be configured to take the rc file to be a file in /etc/procmail-rcs/ as an alternative to $HOME/.procmailrc (at least the version of procmail in Ubuntu; unlike /etc/procmailrc, the files in /etc/procmail-rcs/ will take on the user id of the user the file is named for, like $HOME/.procmailrc).

User crontabs on my system at least (Ubuntu) are in /var/spool/cron/crontabs/[username], not in $HOME anyway. I can't remember the last system I had with user crontabs in $HOME.

People have had systems where relying on accessing the home directory of a logged out user has been undesirable or impossible for a very long time.

> But how large a proportion of machines do you think have mail delivery rely on .forward or .procmailrc in $HOME these days?

I help run a 500 node HPC cluster that leverages procmail. Do I count?

> User crontabs on my system at least (Ubuntu) are in /var/spool/cron/crontabs/[username], not in $HOME anyway.

The crontab(5) may be there, but where is the script that is actually executed? Probably in $HOME/scripts/ or some such.

> People have had systems where relying on accessing the home directory of a logged out user has been undesirable or impossible for a very long time.

I have daily experiences indicating otherwise. I would hazard to guess that many other syadins in academia & research would agree. Even assuming $HOME is in /home breaks a bunch of stuff:

* https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu2004Sna...

> I help run a 500 node HPC cluster that leverages procmail. Do I count?

You do, but you're a tiny minority, and as noted /etc/procmail-rcs/ provides an alternative to putting them in /home. If that doesn't work for you, all you need is to not configure encrypted home directions and nothing changes.

> The crontab(5) may be there, but where is the script that is actually executed? Probably in $HOME/scripts/ or some such.

So don't configure encrypted home directories, then. Nobody is forcing you to enable it. Or you can provide an alternative location, and let your users protect their data better and still be able to use cron jobs. It does not take any flexibility away from you, but it adds capabilities for those who want them.

> I have daily experiences indicating otherwise. I would hazard to guess that many other syadins in academia & research would agree. Even assuming $HOME is in /home breaks a bunch of stuff:

Your experiences with systems that are fine with accessing $HOME does not mean that there aren't plenty of systems where it has been an issue, hence why plenty of software supports alternatives.

Your point of not assuming $HOME is in /home is irrelevant to this issue. The point is that software have had to deal with a subset of users with setups where a users home directory is not necessarily accessible when the user is not logged in for many years. As such most software has options to avoid relying on a users home directory being present already, which reduces this to a relatively simple choice of whether or not you consider the ability to encrypt home directories to be worth making those changes for.

Maybe my point wasn't stated clear enough: the crontab itself is in spool, obviously, but the scripts started from crontab entries reside in my home directory. And while a procmailrc can live in some spool too, the files to be delivered into are in my home directory too.

So then you have two choices: Move them elsewhere, and be able to encrypt the rest of $HOME, or don't encrypt $HOME. This gives you additional options for protecting your home directory if you want it. Noone is forcing you.

Yeah, don't get me started on the fragile glass test tube called systemd-resolved that fails in mysterious ways when I use wicd on Ubuntu and the WiFi gets momentarily disconnected. I don't see the sense behind treating name resolution as something so special that it has to be part of an init system.

I like the overall theoretical concept of systemd but it has ugly implementation details like this.

But systemd-resolved is such an odd complaint since it’s only connection to systemd is the name and that it’s in the same repo. It’s not connected to the init system at all.

The entire repo is a big ball of mud. No one knows which parts can be removed without breaking things.

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.

Just set ENABLE_RESOLVE=0 when compiling and resolved is gone?

You use the word "just" as if this were a simple thing to understand and know. Is this magic incantation communicates in a way that the usual people who compile this package can understand to use it without being intimately familiar with the code?

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.

> this magic incantation communicates in a way that the usual people who compile this package can understand to use it without being intimately familiar with the code?

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.

I mean the parent was talking about the source code being a ball of mud and it being difficult to determine what components can be removed without breaking things.

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.

So common with open source - flags that once worked are now tangled up with subsequent code/flags and won't even compile if not part of some common configuration. Because its not fun to exhaustively test all combinations, it doesn't get done.

It seems exactly as difficult as with any other stuff written in C. Let's say uWSGI. systemd uses meson, and there's a file listing all the options, and the first match for "resolve" seems to be that flat: https://github.com/systemd/systemd/blob/master/meson_options...

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.

Yes it is.

> Just set ENABLE_RESOLVE=0 when compiling and resolved is gone?

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.'"

This is a config option that you pass when compiling systemd in the same was as --enable-feature in a ./configure script. If you are familiar with the systemd source you would be aware of these options. They’re not hidden.

> [...] and that it’s in the same repo. It’s not connected to the init system at all.

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.

Funny you mentioned systemd-resolved, it generated so many coredumps across the machines I use at home (Arch, Manjaro, Fedora), its stability / reliability improved over time but still not up to standard.

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...

systemd isn't just an init system. It's a suite of tools that provides a system and service manager. It's not handling everything in one monolithic process. This has been said thousands of times before. I don't know why people don't get this.

systemd is not an init system. That it has one, it out of necessity. To manage a system you have to manage what runs on it, to manage that you have to manage what gets started and stopped, and so you have to manage boot and shutdown. And now, here's your nametag, there's the counter, don't forget to smile, you're the new init system!

udev doesn't have to be there, but when a handful of people maintain critical parts of the Linux ecosystem and they saw ways to make their maintenance work more effective, they went ahead and made their work more efficient.

I mean, criticizing systemd/udev/Debian/Ubuntu/Arch on how they did stuff, and the technical merits of how things are is completely fair, but criticizing "why" is strange. They did because they saw that it will help them, their projects, their users. (And they probably understood very well that it won't please all of their users.)