this post was submitted on 23 Oct 2025
44 points (100.0% liked)

Linux

9902 readers
808 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago
MODERATORS
Ategon@programming.dev
anzo@programming.dev
dwraf_of_ignorance@programming.dev
44
Debian Technical Committee overrides systemd change (lwn.net)
submitted 4 days ago by cm0002@lemmings.world to c/linux@programming.dev
9 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] woelkchen@lemmy.world 7 points 4 days ago (2 children)

Why on earth would the permissions on /var/lock be something for systemd to decide?

Because – as LWN explains – there no longer is an overarching standards body who makes the decision, so anybody can make up their own.

Debian's continued use of UUCP-style locking does seem to be more than a little bit dated. The FHS 3.0 is clearly reaching the end of its useful life, if not actually expired.

Seems like Debian is more the outlier here.

[–] who@feddit.org 3 points 3 days ago

there no longer is an overarching standards body who makes the decision

The creators of the FHS were never an overarching standards body. Despite its name, the FHS is more a set of conventions than a standard.

The closest standard that comes to mind is POSIX.

https://pubs.opengroup.org/onlinepubs/9799919799/

[–] kbal@fedia.io 2 points 4 days ago (1 children)

Reading more carefully I see that the real reason is "the /run directory is created as a tmpfs filesystem specifically for run-time files by systemd-tmpfiles.

I forgot that systemd had been allowed to take over /tmp and /run.

[–] woelkchen@lemmy.world 2 points 4 days ago

I forgot that systemd had been allowed to take over /tmp and /run.

According to Debian everyone is allowed to take over /run