Debian Technical Committee overrides systemd change

Author here: It was abandoned. I linked to one of the former maintainers who said as much. The current effort is by a few people who asked the LF to take out over, and have (so far) done little after an initial flurry of activity. That, too, is covered in the other article I wrote about the FHS recently.

Prior to the group who started an update effort, it had not been touched in about a decade. That’s not slow-moving: that’s abandoned.

Counterpoint: Modern distro’s needs have evolved past the FHS in some cases, and everybody deviates from it slightly but incompatibly.

A standard does no good if it does not reflect reality. I think it is a worthwhile effort to try to bring it back in line with actual real world usage.

> What ongoing maintenance would a file system standard require?

adaption to _a lot_ of subtle changes to requirements

- very different security related requirements today

- very different performance related requirements/characteristics

- very different need for various edge cases

and lastly adapt based on what turned out to work well and what didn't

so some examples not already mentioned in the article

- /boot -- dead or at least differently used if you use efistub booting

- /etc/X11 -- half dead on wayland

- /etc/xml, /etc/sgml -- dead, should IMHO never have existed

- also why was /etc/{X11,xml,sgml} every explicit part of the standard when the spec for `/etc` already implies them as long as e.g X11 is used ??

- `/media` -- dead/half dead depending on distro, replaced by `/run/media/{username}/{mount}`

- `/sbin` -- "controversial"; frequent reoccurring discussions that it isn't needed anymore, didn't work out as intended etc. It was useful for very old style thin clients as `/sbin` was in storage but `/bin` was mounted. And there are still some edge cases where it can makes sense today but most fall under "workaround for a different kind of problem which is better fixed properly".

- `/tmp` -- "controversial", long history of security issues, `/tmp` dir per program fixes the security issues (e.g. systemd service PrivateTmp option) but requires having a concept of "programs" instead of just "running processes" (e.g. by systemd services or flatpack programs). Also `tmpfiles.d` can help here.

- `/usr/libexec` -- dead, nice idea but introduces unneeded complexity and can be very misleading in combination swith suid and similar

- `/usr/sbin` see `/sbin`

- `/usr/share/{color,dict,man,misc,ppd,sgml,xml}` -- should never have been in the standard they are implied by the definition of `/usr/share`; at least sqml,xml are dead. dict was for spell check/auto completion, except that neither works anymore like dict expects

- `/var/account` -- to specific to some subset of partially dead programs, shouldn't be in the standard

- `/var/crash` -- distro specific mess

- `/var/games` -- basically dead/security mess, I mean 99% of games today are user per-user installed (e.g. Steam) and even for such which are packed any variable download data is per user, making it shared creates a permission/security mess

- `/var/lock` -- as mentioned there are better technical solutions by now, e.g. using `flock` instead of "presence of file" and some other techniques. Tend to also avoid issues of crashed programs not cleaning up "lock files" leading to dead locks and needing manual intervention.

- `/var/mail` assumes a quite outdated form of managing mail which is quite specific to the mailing program, as it's very program specific it IMHO shouldn't be in the standard

- various legacy program specific, non "generic" file system requirements e.g. that `/usr/lib/sendmail` must exist and be a link to a sendmail compatible program and similar.

also missing parts:

- `/run/user/{uid}`

- `/var/run/user/{uid}`

- `/proc`

- `/sys`

- user side versions (e.g. from the XDG spec which is also somewhat in a zombie state from my personal experience with it , e.g. .config, .local/{bin,share})

- references to light weight sandboxing, e.g. per-program /temp etc.

- factory reset stuff (`/usr/share/factory`) needed for having a uniform way for devices sold with Linux and device specific distro customization(e.g. steam deck)

so yes, it's quite outdated

The /usr merge is an example of something that a modern FHS might reflect.

I'm very happy that the "independent standard" facade of the UAPI group fell, and its actions are now directly attributed to systemd's interests.

Well, it probably depends on which software's concern will be implementing a policy to prevent users from having permission to fill critical directories and prevent the system from operating normally, which is discussed in the article. Which is also a coordination problem because the most common user of disk is software itself, I think.

FHS seems to specifically imbue the user with the responsibility and consequences of filling up the disk.

A more neutral phrasing would be.

> Debian Policy still cites the FHS, and FHS has remained static for over a decade.

>> Debian Policy still cites the FHS, even though the FHS has gone unmaintained for more than a decade.

> What ongoing maintenance would a file system standard require? A successful standard of that type would have to remain static unless there was a serious issue to address. Regular changes are what the standard was intended to combat in the first place.

It's 2025, anything that wants to be considered modern (and everything should want that), needs to be undergoing constant change and delivering regular "improvements."

>>...though there is a slow-moving effort to revive and revise the standard as FHS 4.0, it has not yet produced any results.

> So it is not abandoned then. A slow moving process is exactly what you would want for the maintenance of a file system standard.

The FHS people to get off their butts. There's no excuse for that pace now that we have such well-developed AI assistants. They should be pushing quarterly updates at a minimum, and a breaking change at least every year or two. It's been obvious for decades that "etc" is in urgent need of renaming to "config", "home" to "user", and "usr" to "Program Files" to keep up with modern UX trends.

yes but also no

every distro has defined their own new file system layout standard

sure they all started out with the common ancestor of FHS 3.0, but diverged since then in various degrees

and some modern competing standards try to fix it (mainly UAPI Group)

(And yes some people will go one and one about how UAPI is just a way for systemd to force their ideas on others, but if you don't update a standard for 10+[1] years and aren't okay with others taking over this work either, idk. how you can complain for them making their own standard).

[1]: It's more like 20 years, but 10 years ago the Linux Fundation took over it's ownership.

Standards are a double edged sword though. They are great for getting everyone to agree to the "most correct" answer. But they also freeze evolution in place. What happens when your standard doesn't support contemporary use cases? What if it's at direct odds with, say, modern security practices?

FHS hasn't changed in years. Since then, sandboxing, containers, novel package schemes, and more are the zeitgeist. What does the FHS say about them?

This is usual systemd maintainer behavior. Poetterings "I don't consider it much of a problem" is legend: https://github.com/systemd/systemd/issues/5644

There is Devuan, if you want to Debian but without systemd. I suspect though that "natively" non-systemd distros will be more consistent, personally I've found happiness with Guix.

Link to such an dismissal: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112535#64

[flagged]

In this case, I think the upstream maintainer's response -- "Upstream systemd will do X, distros who want to are free to do Y" -- is legitimate. Consider the reverse: If systemd requires a writable /run/lock, then distros who want to be more safe won't really be able to (or will have to implement a much more intrusive patch).

Looking from the outside, it looks more that this is a failure of the Debian systemd package maintainer to follow Debian's rules. (Though since I'm not a part of that community, I recognize that there may be cultural expectations I'm not aware of.)

Linux is 34 years old, and some of the Unix-ism borrowed are even older. There is genuine cruft that has downsides. Different relative priorities of backwards comparability, maintainability and the various issues the legacy issues cause are reasonable.

Systemd basically arose out of a frustration at the legacy issues so the whole project exists as a modernizing effort. No wonder they consider backwards compatibility low priority.

That has been their method since the beginning; why would they change from a tactic which works for them?

The central problem with systemd is that they don't want to let you go about your business, they want you to conform to their rule.

Because that's what they've always done, and it continues to work for them?

Systemd doesn't work for me, but it has taken over most Linux distributions, so clearly it's got something people want that I don't understand. That was the case for PulseAudio too.

Did you read the same article?

   * Their is an option for the old behavior.
   * It is a security issue and better solutions to replace exist.
   * FHS isn't maintained.

In this case I assume their "fear" is that unprivileged users can exhaust resources (inodes, filesystem space) in an important tmpfs breaking the system. The proper solution for backward compatibility would probably be something like make /run/lock its own mountpoint, but they fixed it in their system (Fedora) so now it's no longer their problem. Just be thankful their software is portable to such strange niche operating systems like Debian. /s

[dead]

[flagged]

More-clickbaity title -- Debian Technical Committee tells its doofus maintainers to stop worshipping Poettering so much

Why is that non-clickbait? Honestly "Debian Technical Committee overrides systemd /run/lock permission change" might be a better title than either, I don't know whether the thing or the actors are more interesting here. But you can only say so much in a title.

Yeah. I expected better from LWN.

> Is anyone surprised that the systemd folks basically said "fuck you, we'll do what we want to" to everyone else?

I don't think that's an accurate paraphrase of "Consider this more a passing of the baton from upstream systemd to downstreams: if your distro wants this kind of legacy interface, then just add this via a distro-specific tmpfiles drop-in. But there's no point really in forcing anyone who has a more forward-looking view of the world to still carry that dir."

That kind of drop-in is pretty routine, so I don't know why this became a big thing we're all discussing now.

"everyone else" in this case is pretty much only the debian ecosystem because they insist on enforcing a serial lock policy from the 1980s. It's fine if Debian wants to move at the speed of a Soviet committee but I don't think it should be expected (or would be healthy) for systemd to move at the same pace.

A software developer's primary job is to develop software for their users, not to comply with a third party distributor that repackages their software.

Genuinely curious - why would world-writeable directory be bad for security? Assuming of course, it's on a separate filesystem mounted with sensible options. Here's what I see from "grep /run/lock /proc/mounts" in sid:

  rw,nosuid,nodev,noexec,size=5120k

Hmm - I see there's now "lockdev" for managing access to things like serial lines, but what's the preferred method of expressing "only one instance of this program should run at any one time"?

I use GNU screen for that. Looking at cu, it looks to be just as tiny and has ssh-like tilda-escapes, including "~." to disconnect. Nice, gotta try it out, thanks!

What would you suggest? Personally I find cu the closest to ssh in ergonomics to any of the tui serial terminal programs, and it’s easily available across unixes like FreeBSD or Mac OS, which is a bonus.

cu is the regular way of doing it

I don't see the problem. Minicom and even picocom are bloated compared to cu

One comment [0] highlights a point in favor of the current implementation:

> create a lock file for every dial-in line to prevent its use by programs looking for a dial-out line.

[0]: https://lwn.net/Articles/1042594/

Considering I never had to reinstall a Debian system because it got bloated or broke one day, I can accept this slow-cooking approach. Even support them on this regard.

once it's ready they'll push it, that's how it should be

I am in no rush. I like something being stable.