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.
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").
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.
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 :)
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.
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.
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).
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.
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).
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)
/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
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 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.
> 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.
/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.
/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.
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.
64 comments
[ 3.0 ms ] story [ 170 ms ] thread... 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).
These days seems Red Hat is deciding what the Hierarchy is instead of the community.
I wonder if another UNIX at some point added such a user in order to reserve '/usr/bin'...
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 :)
Makes upgrades easier when leaving SysV init alone (in /bin).
http://lists.busybox.net/pipermail/busybox/2010-December/074...
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.
:D
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.
What relationship is there between home folders and the boot process?
...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.
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/.
So there’s no equivalent to EFISTUB (the kernel as a UEFI executable, most easily accomplished by mounting the ESP at /boot)?
[0] https://wiki.gobolinux.org/Overview/GoboLinux-Filesystem-Hie...
~/... 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
Don't most/popular distros symlink many of those together?
(Not sure if popularity matters.)
"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.
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.
https://specifications.freedesktop.org/basedir-spec/basedir-...
/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.
"For example, StarOffice, Kylix, Netscape Communicator and WordPerfect packages are normally found here"
/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.
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.
giving sensible defaults to automatic mounts is the issue here.
* It is hierarchical.
* It sorts by file type, not by namespace.
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.