For all people that think this is still a issue: it is not:<p>* Arch Linux: <a href="https://wiki.archlinux.org/index.php/Arch_filesystem_hierarchy" rel="nofollow">https://wiki.archlinux.org/index.php/Arch_filesystem_hierarc...</a><p>* Fedora: <a href="https://fedoraproject.org/wiki/Features/UsrMove" rel="nofollow">https://fedoraproject.org/wiki/Features/UsrMove</a><p>* Debian: <a href="https://wiki.debian.org/UsrMerge" rel="nofollow">https://wiki.debian.org/UsrMerge</a><p>* Ubuntu: <a href="https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMerge" rel="nofollow">https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMer...</a><p>And this is true for quite a long time. I think the last distro that did /usr merge is Debian and this is already 3 years ago. So I find surprising that people still thinks that this is a issue.<p>The only thing that remains is the difference between bin and sbin that Fedora/Ubuntu/Debian still maintain (Arch Linux simply merged everything).<p>P.S.: of course, there should be still distros that use a split /bin /usr/bin, /lib and /usr/lib, etc. OpenWRT is one of them. However I think the major distros already migrated.
Nitpicking:<p>If you look at the very early versions of the Unix manuals, before even /lib was invented, there was a notion that /bin was the "system" (section 1) and /usr/bin was "user software" (section 6). This fell by the wayside when they ran out of disk space on / and started putting section 1 commands in /usr/bin. At some point the system/user distinction was abandoned and everything but the games got moved to section 1 of the manual.<p>(Back in those early days /lib files used to be in /etc. So did /sbin. There's still a meaningful semantic difference between programs any user could run vs programs only useful to root.)<p>On *BSD there is no initramfs equivalent and the / partition still serves its traditional role of the minimal startup environment. And /home never existed before Linux - it was always something like /usr/home as far as I can tell.
NixOS is one of the few distros that recognizes and solves this problem:<p><a href="https://nixos.org/nixos/about.html" rel="nofollow">https://nixos.org/nixos/about.html</a><p>A solution like theirs should become the default. Their transactional, package management too given the number of times my Linux packages got broken by some ridiculous crap. That even a smaller outfit could knock out two problems, one major, shows these bigger distros could be gradually knocking out such issues themselves.
Interesting.<p>First there was /bin for the things that UNIX provided and /usr/bin for the things that users provided. Part of the system, it lived in /bin, optional? it lives in /usr/bin.<p>In SunOS 4 (and BSD 4.2 as I recall) the introduction of shared libraries meant you needed a "core" set of binaries for bootstrap and recovery which were not dynamically linked, and so "static" bin or /sbin (and its user equivalent /usr/sbin) came into existence. Same rules for lib. /lib for the system tools, /usr/lib for the optional user supplied stuff.<p>Then networking joined the mix and often you wanted to mount a common set of things from a network file server (saved on precious disk space) but there were things you wanted locally, that gave use /usr/local/bin and /usr/local/lib. Then in the great BSD <==> SVR3.2 merge AT&T insisted on everything optional being in /opt which had a kind of logic to it. Mostly about making packages that could be installed without risking system permission escapes.<p>When Linux started getting traction it was kind of silly that they copied the /bin, /sbin, /usr/bin, /usr/sbin stuff since your computer and you are the only "user" (usually) so why not put everything in the same place, (good enough for Windows right?)<p>File system naming was made more important by the limited permission controls on files, user, group, and other is pretty simplistic. ACLs "fixed" that limitation but the naming conventions were baked into people fingers.<p>The proliferation of places to keep your binaries lead to amazingly convoluted search paths. And with shared libraries and shared library search paths even more security vulnerabilities.
Reasons why you <i>still</i> might want to keep / and /usr isolated:<p>1. NFS mounts. Your local or initial BOOTP image has a minimal root, your (non-root-writeable, BTW) NFS /usr has Other Stuff.<p>2. Mount options. Root is often (and perhaps still <i>must</i> be -- /etc/mtab for example -- I've stopped closely tracking discussion to make root fully read-only) writeable. It may also require other mount permissions, including device files and suid. Other partitions <i>don't</i> require these permissions, and there is some Principle of Least Privilege benefit to mounting such partitions without them. /usr requires suid, but not dev, and may be nonwriteable except for OS updates.<p>3. Recovery partition. I'll frequently stash a second root partition, not typically mounted. It has minimal tools, but enough to bootstrap the system if the primary is hosed for whatever reason (more often myself than any other). Without a clean / /usr split, this becomes more complicated.
The elephant in the room is /opt, /etc/opt, and /var/opt. The System V and filesystem hierarchy specifications say that those locations are, and I quote, "for third party and unbundled applications". Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems (no, an unbundled application can never be delivered into /usr, because that is vendor's namespace, and an updated version from the vendor might very well bring a production application down).<p>/opt: application payload<p>/etc/opt: application's configuration files<p>/var/opt: application's data.<p>For applications with more than two configuration or data files, it is a good idea to create /etc/opt/application and /var/opt/application.<p>If your company is mature enough to understand what system engineering is, and employs dedicated OS and database system engineering departments, /opt/company, /etc/opt/company[/application], and /var/opt/company[/application] become very practical. If this approach is combined with delivering the application payload and configuration management as operating system packages, one only need worry about backing up the data in /var/opt, and that's it.
I like that FreeBSD dedicates a man page, HIER(7), on this topic - <a href="https://www.freebsd.org/cgi/man.cgi?query=hier" rel="nofollow">https://www.freebsd.org/cgi/man.cgi?query=hier</a> - "layout of file systems"
/{bin,sbin} is for stuff you cannot live without (e.g., sh, mkdir, chmod, rm, ln, etc.)<p>/usr/{bin,sbin} is for stuff you can live without but expect to be there (e.g., make, grep, less).<p>/usr/local/{bin,sbin} is for stuff you/your local admin installed (e.g., mosh, cmake).<p>Also, I use $HOME/{bin,sbin} for wrapper scripts, binaries that I need but don't want to install system-wide (single-file C utils that come without man pages, stuff like that).<p>I'm not sure where the confusion comes from and I don't really see any advantage in merging / and /usr. On the flip side, I do think there's value in keeping /{bin,sbin} as small as possible (because that stuff <i>has to</i> work).
The /bin vs /usr/bin split makes perfect sense but I always thought /sbin was superflous to happy to see it being deprecated by many distros.<p>I expect with the increasing moves towards app stores and sandboxing on all platforms that the days of installing packages contents all over the filesystem are limited and things like xdg-app are probably going to take over with an app being mounted into the filesystem in a sandbox as it is run.
One outcome of this that drove me nuts back in the day on Debian system was libpcre was installed in /usr and grep was in /bin. This meant perl regex were not supported because the maintainers of Debian didn't want the dependency on /usr from things in /bin, and didn't want to "bloat" / with something as distasteful as libpcre.
I want to react to the signature FUD: GPLv3 is clearly a superior copyleft license to GPLv2 despite Linus' latently permissive opinion on the anti-TiVoization clause.
Well this partially answers my question at <a href="https://news.ycombinator.com/item?id=11647487" rel="nofollow">https://news.ycombinator.com/item?id=11647487</a>