FilterHN

Finding a Successor to the FHS

27 points

by firexcy

14 hours ago

| past

| 4 comments

| lwn.net

| HN

▲

JdeBP

1 hour ago

[-]

There's an awful lot of back and forth in the comments there over whether it should be a specification that defines its requirements in terms of whatever systemd programs happen to do, or whether it should be a specification with its own concrete basis that systemd is held to like everything else.

▲

kelnos

31 minutes ago

[-]

It should be neither. It should be a set of rules that most people can agree on. If some of that is what systemd does, that's fine. If there are things that systemd does that most people don't agree on, something else should end up in the standard, and systemd should conform to it.

The problem is that systemd evokes some pretty visceral negative reactions in people. I still have mixed feelings about it, but, by and large, I encounter minimal real-world issues with it. Just because systemd has decided to do something that violates the older FHS3/4 standards, doesn't automatically make it a bad thing. Maybe what they're doing is a better way. Maybe not.

▲

WhyNotHugo

31 minutes ago

[-]

The irony is that systemd doesn't really follow what it prescribes in file-hierarchy(7), and expects some files in the "wrong" place. Other software has (obviously) followed suit, so now we're in a world where software follows the conventions that systemd _implements_ to maintain compatibility, rather than what it _documents_.

The most obvious example that comes to mind is /usr/lib/os-release, which file-hierarchy(7) indicates should actually be in /usr/share/os-release.

▲

curt15

2 hours ago

[-]

>there's far less emphasis on creating native distribution packages for third-party software in 2025. Flatpaks, Snaps, and AppImage packages seem more popular with desktop-application developers these days. A lot of server-side software is now expected to be deployed as a container—or a group of containers run in Kubernetes—rather than installed as a package.

Are CLI tools or low-level, privileged software (e.g. anything that requires root) also distributed using flatpak or snap these days?

▲

creatonez

2 hours ago

[-]

Ubuntu distributes some system daemons and even the kernel image as Snaps. The Ubuntu Server interactive installer nags you to look at a list of server software (such as nginx) to install using Snap.

Flatpak hasn't really taken the same path, it doesn't have much utility for anything other than desktop apps.

▲

bonzini

1 hour ago

[-]

There is toolbox, see https://github.com/containers/toolbox.

▲

creatonez

1 hour ago

[-]

Toolbox and Distrobox are not based on Flatpak, though. They're more just nicely packaged docker-like container tools, targeted for development use cases.

▲

i80and

2 hours ago

[-]

A little surprised that the linked systemd file-hierarchy(7) manpage makes no mention of /opt

▲

JdeBP

1 hour ago

[-]

You won't find it in the hier(7) manual pages on BSDs, either.

* https://man.openbsd.org/hier

* https://man.netbsd.org/hier.7

* https://man.freebsd.org/cgi/man.cgi?query=hier&sektion=7

* https://man.dragonflybsd.org/?command=hier&section=7

There was a long time when the Linux world held /opt in disfavour, because officially it required either a stock market ticker name or some other corporate identity to make a subdirectory legitimate. You can still see traces of this in the Solaris descendant operating systems, where pkginfo(5) talks about package names using corporate stock ticker names.

* https://illumos.org/man/5/pkginfo

/opt/SUNW* used to be a very familiar thing to a lot of people.

Maybe enough time has passed for anti-corporate memory to fade. Maybe there's enough corporate backing in the Linux world now to resurrect the idea regardless.

Maybe /opt/RHT* is the shape of things to come. (-:

I've never over the years seen the systemd people advocate for /opt, though.

▲

WhyNotHugo

29 minutes ago

[-]

/opt is used for manually-installed software. Packages should never place files there, so it falls out-of-scope for file-hierarchy(7) or hier(7).

▲

creatonez

2 hours ago

[-]

/opt/ is just a dumping ground for crap nobody can find a better location for

▲

curt15

1 hour ago

[-]

Where else would ./install-3rdparty-software.sh write to? Should it spray files all over /usr?

▲

creatonez

1 hour ago

[-]

It shouldn't do anything until the user has told it where the files should end up. It's an unpackaged program, there is no sane place to put it that doesn't have a high chance of conflicting with something else.

▲

kelnos

29 minutes ago

[-]

That's only due to a lack of standardization. I think a default install to a vendor-specific directory under /opt is a sane place to put it, and there's a very low chance that would conflict with something else.

But sure, absolutely, an installer should prompt the user for an install location, and I think a default under /opt is probably among the best defaults possible, if we consider installing outside $HOME to be reasonable.

▲

MisterTea

1 hour ago

[-]

Honestly there should be no install-bs.sh and you just bind everything into the file tree as needed. At least that is how it works on Plan 9 which simplifies a lot of things like path which is just '/bin.'

▲

hulitu

4 hours ago

[-]

> Last year, postmarketOS core developer Pablo Correa Gomez and a few others started an effort to move the FHS work under the freedesktop.org banner and create 4.0 of the standard

No. freedesktop.org is the place where standards go to die and CADT development takes place.