Linux Filesystem Hierarchy (2004) | Hacker News Reader

Linux Filesystem Hierarchy (2004)

tldp.org

58 pointsreqo61 comments

Hm, not to be confused with the Linux Filesystem Hierarchy Standard: https://refspecs.linuxfoundation.org/FHS_3.0/fhs.html

... which is referenced in hier(7) https://man7.org/linux/man-pages/man7/hier.7.html

... which is itself referenced in file-hierarchy(7) https://www.freedesktop.org/software/systemd/man/latest/file... (which is the first place I look things up these days).

Isn't Red Hat/Fedora ignoring these standards ? I noticed /run is not even mentioned. I wish Linux would go back to what I consider a sane Hierarchy :) Similar to what OpenBSD has.

These days seems Red Hat is deciding what the Hierarchy is instead of the community.

Fedora isn't the "community"?

it is run by RedHat, so no, not in this context

About 2009 or 2010 I recall nearly every major distro saying they were going to ignore it, yes. It primarily existed so that Linux could mimic System V and/or POSIX, and that stopped being relevant as soon as software written for Unix migrated into software written for Linux.

It primarily existed to standardise paths between different Linux distributions. This, along with the LSB, was intended to make it possible to ship software that would work on all distributions.

It did a pretty poor job of it though, since it made no attempt to separate distro software from third-party software (unless you count "shove everything 3rd-party in /opt and bundle all dependencies").

Do you mean in the FHS? /run is in there. It's runtime variable data, like /var but for data that doesn't need to persist between boots.

The equivalent for Haiku OS, without decades of legacy, conflicts, changes, history, backwards compatibility:

https://www.haiku-os.org/docs/userguide/en/filesystem-layout...

This shows you what Linux could be if it were redesigned from scratch without layers of patches/fixes. Nice, simple, and due to dynamically mounted read only package system, read-only actually means read only.

> "The home folder - /boot/home/"

What relationship is there between home folders and the boot process?

It says it's the boot volume, not necessarily the equivalent I guess of /boot on Linux where it's exclusively for boot related things.

You may want to email HN (see https://news.ycombinator.com/newsfaq.html) as it seems you're shadow banned.

These are folders on the boot drive, which is always mounted on /boot?

This seems like a bad choice. The home directory need not be on the boot drive. In fact, a lot of people put it on a separate drive, or at least a separate partition.

With a proper redesign from scratch, it could have the same success and market share Haiku has.

Right, without back-compat, any system trying to gain marketshare is domed.

...but Linux has chroot, symlinks, hardlinks, and everything in-between - it's entirely possible to design a Linux environment where the clutter and warts of back-compat are only visible to the users and programs that need to see them.

I’d point in the direction of Nixpkgs’s buildFHSEnv, but unfortunately Nixpkgs has its own layers and layers of cruft (being more than fifteen years old by now).

GoboLinux attempts to reinvent the filesystem organisation for Linux while maintaining full compatibility.

With success?

I actually like how the document dates itself, for example in the /opt description:

"For example, StarOffice, Kylix, Netscape Communicator and WordPerfect packages are normally found here"

/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin I never know where to put my own binaries so I just add my own at ~/bin. Some programs also add their own like ~/.cargo/bin what a mess

/usr/local is for all users of the multi-user server you're on, which you have installed locally.

~/... is for your personal user account

/bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice)

and /opt is for third party packages from third party providers

we tend to forget the "Unix" precursor of Linux comes from the data centre server world.

so "a mess" is relative

> /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice)

Don't most/popular distros symlink many of those together?

Most distros use a mostly hermetic-usr, where a majority of "distro stuff" is shipped in /usr/{bin,sbin,lib,lib<bitness>,share}. The folders in root mostly symlink to these directories (/usr/sbin might also symlink to /usr/bin).

Yes, ex. https://wiki.debian.org/UsrMerge

Yes https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...

(Not sure if popularity matters.)

yes they do, because the original purpose and value of the separation has gone.

"back in the days" before there was an initrd you needed a small disk. that was /bin and /sbin. into that disk some /etc/rc.d/ file would mount a separate /use partition (and /home and /opt), often from network.

however with pivot_root and initrd we don't need that dance any more and do another one...

likewise the distinction between sbin and bin is gone.

that's why they today just symlink together.

> we tend to forget the "Unix" precursor of Linux comes from the data centre server world.

Indeed. When I first encountered Unix back in the Dark Ages, not only was it common to be working on the same machine with a dozen other people simultaneously, we also had an environment where many programs were hosted on NFS filesystems, and we would have paths like /usr/nfs/alpha-dec-osf1 for Alpha binaries, /usr/nfs/decstation-ultrix for MIPS binaries, /usr/nfs/sparc-sun-solaris, etc. You would make sure your profile scripts included the right architecture path.

Even modern UNIXes (like Darwin/MacOS) include write(1), if you want to start a chat with someone else logged into your MacBook, I suppose.

I think the current standard for your own binaries is ~/.local/bin instead of ~/bin

https://specifications.freedesktop.org/basedir-spec/basedir-...

I would probably end up symlinking ~/.local/bin to ~ anyway, at which point I wonder why bother?

The long version is:

/usr/bin belongs to the package manager for your distro. Don't put anything there.

/usr/sbin is the same but house executables that should only be run by root.

/bin and /sbin are analogous but house the minimal set that needs to be present during early boot in case /usr is on a separate partition. In practice, distros have largely moved to making at least /bin and /sbin symlinks to /usr/bin and /usr/sbin, with some making everything else a symlink to /usr/bin.

/usr/libexec holds executables installed by the package manager but meant to be run only by other programs, not by interactive users.

/usr/local/bin and /usr/local/sbin hold executables installed manually rather than by the package manager. By convention, the package manager should never touch this and it will be left alone during system upgrades. In theory, it holds executables meant to be used by every user of a system, but if this is a desktop system with only one user, putting your personal stuff there is harmless.

Not part of the FHS, but according to cross-desktop group standards, ~/.local/bin is where you put executables meant to be used by a single user only. The package manager won't touch this directory, but third-party installers like pip and what not should theoretically be using it (not ~/.cargo/bin like cargo does).

/opt effectively serves a similar purpose to /usr/local, but for software that expects all of its dependencies to be hermetically contained within a single top-level directory rather than shared. This is often because /opt is mounted via NFS and shared across multiple hosts that might not all have the same common system-wide dependencies. I can't think of a whole lot of examples where this is still commonly used, except that Kubernetes puts the CNI plugins here.

Also, technically if you're booting via UEFI, then your bootloader or any other EFI executables should be at the root of your EFI system partition, which in Linux will usually be mounted at either /boot or /boot/efi depending on the distro, but users should rarely be messing with this unless you're doing Linux from Scratch or really know what you're doing. This also includes Linux itself in a Linux distro because the kernel is an EFI executable now thanks to EFISTUB and you don't actually need a separate bootloader if you really know what you're doing.

See also the GoboLinux filesystem hierarchy [0], which may be what would happen if we redesigned the traditional Unix hierarchy.

[0] https://wiki.gobolinux.org/Overview/GoboLinux-Filesystem-Hie...

I still think it’s funny how what used to be the location of user home directories, namely /usr, has been retconned to be where the majority of binaries are stored.

I didn't know this. I had never seen it. I've used Linux for many years, but not an expert by any means. But it peeked my curiosity, and I found the explanation in this answer satisfying: https://askubuntu.com/a/135679

The story went something like, the guys building UNIX got a second hard drive, so they moved the home directories (/usr) to it. As the system grew, they started dropping more binaries into /usr/bin (while trying to keep /bin for things needed to boot/rescue the system, in case the disk with /usr failed). The rest is history.

And to this day there is a mysterious 'bin' user on Linux systems that no one seems to use or know the purpose of.

I wonder if another UNIX at some point added such a user in order to reserve '/usr/bin'...

At least one old UNIX book of French origin described the “bin” user as the owner of the common binary files on the system.

Yes, that was what I remember. I think having bin own the binaries was a kind of security check for suids. Avoids having a suid on a root owned binary. Plus you could use bin to install programs instead of root. Restricting who has root access.

But I suppose it did not work out as people were hoping and only added to admin costs.

Still, I was a bit annoyed when I noticed everything was owned by root as opposed to bin when I first installed Slackware decades ago. But I got over it :)

used to be that a drum drive covered /bin and a platter drive provided /usr/bin.

Makes upgrades easier when leaving SysV init alone (in /bin).

Here is more detail:

http://lists.busybox.net/pipermail/busybox/2010-December/074...

Oh my gosh, that /opt/local rant was prophetic.

This is how I set my $PATH, note this code is portable between several Linux distros (including NixOS), macOS, OpenBSD, FreeBSD, and amd64/arm64...

<https://github.com/rollcat/dotfiles/blob/52a634f/.profile#L1...>

Whenever I touch it, I just wish I could put PATH=/bin in there instead, but then I'd be stuck juggling 17 different ways to make bind mounts.

complementary openbsd resource:

https://man.openbsd.org/hier

some differences:

* openbsd does not use a /boot/ partition. instead it uses the bsd.* files in root.

* no /proc/ in its entirety in openbsd. use sysctl(3) instead.

* current openbsd does not have a separate /var/tmp/; it is a symbolic link to /tmp/.

Note the (2004). Some things were removed/added/changed (/initrd, /sys, several things in /usr). Check <https://linux.die.net/man/7/hier> for an up-to-date resource.

The /proc equivalent in OpenBSD is ptrace(2).

Could you elaborate? To me there seems extremely little overlap there (I'm familiar with both the procfs and linux's ptrace APIs, but not OpenBSD's ptrace).

Ptrace could an equivalent of what /proc was originally supposed to be, before it got repurposed for a bunch of sysctl-like purposes.

Interesting. I didn't know much about /proc's original design intent, and Wikipedia indeed says "the design of procfs aimed to replace the ptrace system call used for process tracing", citing https://lucasvr.gobolinux.org/etc/Killian84-Procfs-USENIX.pd... ("Processes as Files", USENIX 1984)

> openbsd does not use a /boot/ partition. instead it uses the bsd.* files in root.

So there’s no equivalent to EFISTUB (the kernel as a UEFI executable, most easily accomplished by mounting the ESP at /boot)?

Why does every distro mount USB mass storage devices differently? "/run/media" vs "/media/" vs "/mnt/"

evolution.

/mnt came first. and distros started mounting stuff into it. but actually it was never meant to be used for that. it was supposed to be an always empty directory where a sysadmin could mount something temporarily if they needed it.

so distros moved away from /mnt and started using /media

then /run was invented as a place for all that semi-automatic temporary stuff that needs a place while the system is running.

by looking at where a distro mounts stuff, you can see how long they have not bothered to follow changing standards.

/mnt historically was used as a single mount point. This became problematic when it became common to have multiple temporary mounts, for example a CD-ROM and a USB stick. /media solved that by stating mountpoints are folders inside it, eg /media/cdrom.

right. what early distributions were doing was creating subdirectories within /mnt, but that got in the way when users wanted to mount something manually. at least it did bother me.

personally i wish /media would have stuck. i find the current paths /run/media/username/device rather unpractical. whenever i connect a data device i have to go searching for the mountpoint.

Things lile this are why I use Windows daily. I can assign a specific USB mass storage device a letter it will always use and I memorize it.

you can assign a mountpoint to specific devices on linux too. that's not a new feature.

giving sensible defaults to automatic mounts is the issue here.

> your file system got damaged so badly that the files were mutilated beyond recognition

I love that sentence so much.

The fundamental errors of this are:

* It is hierarchical.

* It sorts by file type, not by namespace.

by namespace do you roughly mean package?

I mean spaces where we put things belonging to a name. When I look at the bin folder on my system, I am mostly: "what the heck are these?" If each of these binaries were in a folder, for example "Python" (that's the namespace), together with their sources, configuration, documentation, etc., I could easily explore this small aspect of the system.

some linux distributions, such as GoboLinux (which, i think, was mentioned elsewhere in the comments, too), do this.

from gobolinux.org:

> GoboLinux is a modular Linux distribution: it organizes the programs in your system in a new, logical way. Instead of having parts of a program thrown at /usr/bin, other parts at /etc and yet more parts thrown at /usr/share/something/or/another, each program gets its own directory tree, keeping them all neatly separated and allowing you to see everything that's installed in the system and which files belong to which programs in a simple and obvious way.

Thank you, very interesting!

Reply on news.ycombinator.com