HN Reader

This part seems fairly editorial:

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

>The specification was not so much finished as abandoned after FHS 3.0 was released...

OK.

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

>Meanwhile, in the absence of a current standard, systemd has spun off its file-hierarchy documentation to the Linux Userspace API (UAPI) Group as a specification. LWN covered that development in August, related to Fedora's search for an FHS successor.

Ah. Systemd/Fedora want a standard that they can directly control without interference from others.

Can anyone tell why systemd developers run fast and loose with what they believe and bully everyone with a stick made out of their ideas?

Debian systemd maintainer Luca Boccassi has recently pushed through and dismissed several problematic and undesired breakages as "niche cases" in a way I personally find antithetical to what I expect from Debian.

I hope they have a change of mind in their approach.

I still cannot understand how it came about that everyone adopted systemd, despite it being a showcase of the most selfish, reckless and irresponsible maintainership ever. And it's not like it's something new, it's been like that for what, 10, 15 years now?

> The FHS 3.0 is clearly reaching the end of its useful life, if not actually expired.

Interesting take.

I think that the FHS is still extremely helpful for packagers, sysadmins and others so they won't stomp on each other's feet constantly. It helps set expectations and prevents unnecessary surprises.

Just the fact that one particular FHS rule might be outdated or even harmful doesn't mean that the FHS as a whole has outlived its usefulness.

Another conflict: in Debian Trixie (current stable release), when you run `systemctl status …` you’re given the rather scary warnings:

    State: degraded
    …
    Tainted: unmerged-bin

This is because Debian has a separate /usr/bin and /usr/sbin. There are no plans to either back off this warning by the systemd maintainers, or to patch it out by the Debian maintainers, and also no plans to merge /usr/sbin and /usr/bin.

So we’re left with the absurd situation that Debian users are being told the default clean install is ‘degraded’ and ‘tainted’ by its main init system!

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370

https://github.com/systemd/systemd/issues/35438

The last paragraph in the article states how Fedora uses lockdev(3) to somehow address the issue. It's not clear to me how a library that exposes a standardized management interface to these locks enables non-root users to create them without a world writable lock directory. Is it that lockdev(3) allows the system to use a different directory?

Secondly, it's suggested that the /run/lock directory and/or the solution of acquiring a lock for a shared resources is dated -- but, no mention of the "modern" way to address this? Is it implied that systemd offers a solution to this? What is it?

PS lockdev has such a poorly written manpage.

It's been a very long time since I heard about uucico (Unix-to-Unix Copy-In Copy-Out program, part of the UUCP suite). Glad to see it's still being shipped! I wonder if any network uses it.

Non-clickbait title -- Debian Technical Committee overrides /run/lock permission change

They should've never accepted systemd into Debian, or other submarines to monopolize knowledge around RH/IBM and steal attention away from original software packages (gnome, wayland, podman, hell even rpm, etc.)

The "somebody might mailicuously exhaust memory via /run” argument seems silly IMHO... you can trivially put a hard limit on its size via the tmpfs mount option. I guess if you bend over backwards that's still a DOS in that new files can't be created in /run once it is full, but come on...

There is support for quotas in tmpfs! /me runs and hides under desk to avoid fruit being thrown at me

> Any process could write as much as it wanted to /run, which

> could effectively DoS the system by exhausting space or inodes

Does ulimit and quotas sufficiently address this concern?

Wow, talk about making a mountain of a mole hill.

Letting upstream systemd single-handedly define what directories exist with what modes in your distro has never been the intended Modus Operandi.

Debian has a huge selection of packages available for it and clearly is going to have more headaches when it comes to preserving compatibility with all that software.

This is a trivial matter for Debian to handle appropriately, while systemd stays focused on its current priorities. I'm surprised this is being talked about at all outside the appropriate mailing lists... slow week for linux news?

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

Somehow I feel that if all the time that has been invested in debating and discussing this had been spent on patching the affected apps, the problem would be properly solved.

I mean, yeah, I get it, systemd bad, democracy good, but these world-writable lock folders are actually a huge pain, and adding some shim code to upgrade to a more secure solution seems achievable?

As always, it will just take another decade until debian has figured it out.

Debian discussions make political discussions seem quick and fast acting by comparison

> He said that he uses cu ""almost constantly for interacting with embedded serial consoles on devices a USB connection away from my laptop""

Whyyyyyyyyyyyyyyy

There are a million better ways of doing this.