Finding a successor to the FHS

The purpose of the Filesystem Hierarchy Standard (FHS) is to provide a specification for filesystem layout; it specifies the location for files and directories on a Linux system to simplify application development for multiple distributions. In its heyday it had some success at this, but the standard has been frozen in time since 2015, and much has changed since then. There is a slow-moving effort to revive the FHS and create a FHS 4.0, but a recent discussion among Fedora developers also raised the possibility of standardizing on the suggestions in systemd's file-hierarchy documentation, which has now been added to the Linux Userspace API (UAPI) Group's specifications.

FSSTND to FHS 3.0

Efforts to standardize directory structure and file placement for Linux systems go back to the earliest days of distributions. The Filesystem Standard (FSSTND) 1.0 was released in 1994; it was developed as "a consensus effort of many Linux activists", and coordinated by Daniel Quinlan. In the preface to the document, which can be found in this directory, it noted that the "open and distributed process" of Linux created a need for a standardized structure of the filesystem:

This will allow users, developers, and distributors to assemble parts of the system from various sources that will work together as smoothly as if they had been developed under a monolithic development process. It will also make general documentation less difficult, system administration more consistent, and development of second and third party packages easier.

It was supplanted by the FHS 2.0 in 1997. Version 2.3, the last in the 2.x series, was announced in 2004. Eventually the work moved under the auspices of the Linux Foundation (LF), as part of the Linux Standard Base (LSB) effort, which was a project that attempted to promote open standards to improve compatibility between Linux distributions. In addition to filesystem layout, the LSB specified standard libraries, run levels, and so forth. The LF released FHS 3.0 in 2015.

The FSSTND and FHS specifications described the layout of the filesystem as well as the files and commands that should exist on a conformant system. It describes the expected structure of everything under root ("/"), which directories should be present on a local system or those that can be shared via NFS or similar, and more. For example, the FHS describes the /bin directory as well as all of the commands—such as cp, ls, and mv— that are expected to exist there.

One might question whether any of the various standards succeeded in making open-source projects work together as envisioned; but we can also imagine how chaotic things would be if there had been no FHS at all. Now, however, the standard has been frozen in time for a decade while Linux development has continued apace.

The FHS is not just old at this point: everyone involved seems to have packed up and gone home. The fhs-discuss mailing list that was hosted by the LF appears to have been retired and LSB maintainer Mats Wichmann wrote in 2023 that "the LSB project is essentially abandoned".

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. There has been some sporadic activity and discussion; the project has a handful of issues open, but little real progress has been made so far. In fact, the discussions under the project had been stalled for months until the topic was raised on a Fedora list.

FHS or UAPI?

On August 5, Pavol Sloboda asked on the fedora-devel mailing list whether Fedora's packaging guidelines were referring to FHS 2.3 or 3.0. The filesystem layout section of the guidelines only links to the landing page of the FHS specification archive, where both 2.3 and 3.0 are linked. Sloboda was trying to figure out whether it was acceptable to create directories inside /usr/bin. He said that the 3.0 version prohibits directories inside /usr/bin, but 2.3 does not.

Michal Schorm said that the project should officially adopt FHS 3.0 and create a list of exceptions where Fedora intentionally deviates from the standard. Zbigniew Jędrzejewski-Szmek, though, said that even FHS 3.0 had missed much of the evolution of Linux systems:

In particular, it completely missed the usr-merge, and obviously the merge of bin and sbin… Just looking at the contents table, it is full of outdated stuff, it talks about /mnt and /media, without the understanding that *temporary* paths need to go under /run instead of polluting the root file system.

Some of the FHS is useful, he conceded, but it is now "mostly of historical interest". He said that Fedora should just use the systemd file-hierarchy. He later suggested that the document should be moved out of systemd's repository and made part of the UAPI Group's specifications; that was done on August 8. Michael Catanzaro said that the UAPI group was "clearly the right place for the successor to FHS".

It is worth noting that the systemd/UAPI file-hierarchy is based in part on the FHS, XDG Base Directory Specification, and XDG User Directories. It does not attempt to be as comprehensive as the FHS; it "only documents a skeleton of a directory tree, that downstreams can extend". It does not, for example, provide any guidance about what binaries are to be expected on a compliant system.

Neal Gompa, who is participating in the FHS 4.0 effort, disagreed, saying that the UAPI "isn't a neutral space: it's a systemd-driven project". He added that he has no "particular beef" with systemd, but it is not used by everyone. Luca Boccassi argued that the file-hierarchy documentation was not systemd-only:

For example, one of the specs (config files) is driven mainly by libeconf which is completely unrelated to systemd and which is used by many projects (and not by systemd) [...]

None of the specifications mentioned on this website require systemd for anything.

Both Boccassi and Jędrzejewski-Szmek expressed skepticism about the FHS 4.0 effort's progress thus far.

Change coming?

Jędrzejewski-Szmek has opened a ticket with Fedora's packaging committee to update Fedora's guidelines to point to that document instead. He added that the UAPI guidelines describe what Fedora is doing anyway, so "this doesn't introduce any new rules, only drops some baggage that we were ignoring anyway". If the packaging committee agrees, Fedora could be the first distribution to officially adopt the file-hierarchy specification. In his most recent comment on the ticket, Jędrzejewski-Szmek said that by linking to UAPI guidelines "we make it more likely that other distributions will follow the same rules", and Fedora does not need to duplicate the work.

It remains to be seen, of course, whether other distributions will want to follow Fedora's lead. Currently, Debian uses the FHS 3.0, with a number of exceptions or additions in its policy manual. Gentoo, rather emphatically, does not adhere to the FHS; its developer guide spells out where files should be placed on Gentoo systems. According to openSUSE's guidelines for RPM packaging, it also follows the FHS; but, like Fedora, openSUSE does not link to a specific version, leaving it open to question whether it refers to 3.0. (In fact, openSUSE links to a wiki page that still mentions the 3.0 as being developed, rather than completed.) Ubuntu's packaging guidelines also refer to the FHS, without specifying the version.

It may be that the need for a universal Linux filesystem standard has waned; while it is important for distribution packages to have an agreed-on standard, 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.

Perhaps, at some point, the FHS revival will bear fruit as a meaningful update to the standard. Until then, the UAPI documentation is the only current game in town.