26 ms·

sbin split (2010)

378 points by kylerpalmer 10y ago

josephscott 10y ago
I like that FreeBSD dedicates a man page, HIER(7), on this topic - https://www.freebsd.org/cgi/man.cgi?query=hier https://www.freebsd.org/cgi/man.cgi?query=hier - "layout of file systems"
- protomyth 10y ago
  The other major BSDs: http://man.openbsd.org/OpenBSD-current/man7/hier.7 http://man.openbsd.org/OpenBSD-current/man7/hier.7 http://netbsd.gw.com/cgi-bin/man-cgi?hier++NetBSD-current http://netbsd.gw.com/cgi-bin/man-cgi?hier++NetBSD-current https://www.dragonflybsd.org/cgi/web-man?command=hier&section=7 https://www.dragonflybsd.org/cgi/web-man?command=hier&sectio...
- catern 10y ago
  systemd has a man page on this as well, file-hierarchy(7): https://www.freedesktop.org/software/systemd/man/file-hierarchy.html https://www.freedesktop.org/software/systemd/man/file-hierar...
shirro 10y ago
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. 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.
- tremon 10y ago
  Funny. I always thought the /bin vs /sbin split made more sense than / vs /usr. I very much prefer that my shell's autocomplete does not stop on binaries that I have no business running as a normal user, so I like that root-only tools are in /sbin.
IshKebab 10y ago
I wonder what is more likely in our lifetimes - a sane Linux filesystem layout, or viable fusion power. Honestly I'm not sure.
- ploxiln 10y ago
  gobolinux - http://gobolinux.org/ http://gobolinux.org/ - has had a completely different filesystem layout, for many years. It's languished in the past few. archlinux has for a couple of years symlinked /bin, /sbin, and /usr/sbin to /usr/bin, and /lib, /lib64 to /usr/lib https://wiki.archlinux.org/index.php/arch_filesystem_hierarchy https://wiki.archlinux.org/index.php/arch_filesystem_hierarc... If you make your own linux distro from scratch, you can get many of the open source pieces of a linux distro to use whatever layout you want, while some pieces do require patching and fixing ... but you do have the source :)
  - zanny 10y ago
    The problem with Gobo is that this progression never works: New FS Layout -> User Adoption -> Profit Because at the end of the day the layout of the filesystem is never the selling point on any given distro. It always comes down to the software - either the amount of it, or the newness of it, and that is why people flock to Ubuntu and Arch respectively. It is much more prudent to argue for filesystem improvements in those distros, and get them implemented there, than to fork it out. Gobo demonstrated both the validity and the utility of the approach, but it is up to distro makers to actually use the evidence given that the traditional Unix layout is garbage.
  - digi_owl 10y ago
    Gobolinux still house the old layout for compatibility. Heck, i think it could adopt any any FS layout it wanted as long as some defined place to house the "Programs" tree was provided.
  - rekado 10y ago
    Much like Gobolinux, Guix also has a completely different filesystem layout. Packages are installed into their own namespace under /gnu/store but then linked to expected locations under a profile root (such as ~/.guix-profile).
nickpsecurity 10y ago
NixOS is one of the few distros that recognizes and solves this problem: https://nixos.org/nixos/about.html https://nixos.org/nixos/about.html 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.
- orik 10y ago
  I was about to ask if any BSD's handle this better, great to see that NixOS does.
  - gkya 10y ago
    In FreeBSD the base system stuff goes into /bin /lib and /etc, and all the ports target /usr/local as the prefix. Even the config files of the ports go to /usr/local/etc.
    - soupbowl 10y ago
      I really like how freebsd does it, nixos has me interested too.
      - gkya 10y ago
        Though NixOS and Guix form a different approach than the FreeBSD's, that is they treat packages as isolated immutable objects and use an unconventional directory layout (wanted to note this, because someone who doesn't know the OSs named may have thought that FreeBSD and NixOS/Guix approaches are similar).
- aidenn0 10y ago
  It's a lot more work to retroactively impose a new FS layout on an existing distribution than to come up with a new distribution. If e.g. Ubuntu did this then 1) They'd have to fix all of the packages in the main repository, and then PPAs? 2) Lots of third party software targeted on Ubuntu would break; this would cause a lot of users to want to stay on pre-change versions of Ubuntu, which probably means it would get forked.
chris_wot 10y ago
Well this partially answers my question at https://news.ycombinator.com/item?id=11647487 https://news.ycombinator.com/item?id=11647487
SquareWheel 10y ago
How badly would things break if we tried to "fix" this split today?
- davb 10y ago
  Probably not too badly if we took a phased approach. 1 - Establish a new, consistent filesystem hierarchy. New code should use the new hierarchy. Move the legacy stuff to the new hierarchy and symlink the old locations to avoid breakage. 2 - After some time, make the legacy locations read-only. This will highlight any non-conforming code. 3 - After even longer, delete the legacy paths. It would maybe be even easier if we could redirect writes (I'm not too versed in filesystem capabilities) from the legacy paths to the new ones.
  - arthur2e5 10y ago
    > Establish a new, consistent filesystem hierarchy. systemd is kind of enforcing this already, preferring /usr (where most of the packages go) over naked paths. This is the trend on relatively modern desktop systems, which thankfully preserves standard fs hierarchy while mostly keeping everything in one place. (Unfortunately there are bunches of non-desktop uses for Linux out there.) See also https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ https://freedesktop.org/wiki/Software/systemd/separate-usr-i.... > It would maybe be even easier if we could redirect writes (I'm not too versed in filesystem capabilities) from the legacy paths to the new ones. Quite a few distros (and users like Rob Landley) use symlinks from /bin to /usr/bin and the same goes for /lib. sbin is sometimes linked to bin. This does some of the redirection. (I am not aware of the /usr/tmp and /var/etc stuff mentioned in the message.) > After even longer, delete the legacy paths. Nah. Millions of scripts are writing she-bangs like #!/bin/sh and I don't really expect to see this being changed... Workarounds using `env` is kind of crippled since a.) it introduces an extra level of dependency and indirection and b.) it stops the user from reliability passing options to the interpreter (Linux only cut at the first space, with all sorts of other *nixen doing different things with multiple spaces.)
    - Pxtl 10y ago
paxcoder 10y ago
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.
- eridius 10y ago
  It's not FUD, and GPLv3 is not clearly a superior license. It may surprise you to learn that different people value different things and have different opinions, and so want different licenses. GPLv3 is really a pretty extreme license that imposes a lot of restrictions that a lot of people simply don't want. If GPLv3 does what you want, by all means use it, but don't denigrate the choices other people make.
  - jordigh 10y ago
    I wonder if people even know what those restrictions are and how exactly the anti-tivoisation clause works. It does not forbid anyone from running software on tivoised devices, which is what some people seem to think it does. All that it requires is that if you distribute the software primarily to be used on a User Product (as GPLv3 calls it), then as part of the installation information (which in GPLv2 used to just mean install and build scripts), you must also provide the signing keys for the hardware. This also does not mean that GPLv3 makes software signing impossible and that you must forbid users from rejecting unsigned software if they so wish. It doesn't mean that you have to distribute every secret key that you use for signing software. It merely means that you have to give your users a way to install software on the User Product as they see fit, if they see fit. It's up to the user to decide to override any signing feature or not. It's very much in spirit with GPLv2 that required installation scripts. As far as GPLv3, hardware signing keys are just another part of installation scripts (the actual term used in GPLv3 is "Installation Information"). http://radar.oreilly.com/2007/03/gplv3-user-products-clause.html http://radar.oreilly.com/2007/03/gplv3-user-products-clause.... https://copyleft.org/guide/comprehensive-gpl-guidech10.html#x13-820009.9.2 https://copyleft.org/guide/comprehensive-gpl-guidech10.html#...
    - eridius 10y ago
bbanyc 10y ago
Nitpicking: 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. (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.) 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.
- digi_owl 10y ago
  I can't help think that initramfs is a pox on Linux. It seems to lead to all kinds of "solutions" that are bothersome at best to maintain unless you have big dollars at your back.
  - kakwa_ 10y ago
    I've never quite understood it myself. It's far from mandatory (I've run Gentoo for years without it) and when you have to fix stuff in the mkinitrd script, you just cry...
- kps 10y ago
  > And /home never existed before Linux SunOS used /home before Linux existed.
m45t3r 10y ago
For all people that think this is still a issue: it is not: * Arch Linux: https://wiki.archlinux.org/index.php/Arch_filesystem_hierarchy https://wiki.archlinux.org/index.php/Arch_filesystem_hierarc... * Fedora: https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove * Debian: https://wiki.debian.org/UsrMerge https://wiki.debian.org/UsrMerge * Ubuntu: https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMerge https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMer... 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. The only thing that remains is the difference between bin and sbin that Fedora/Ubuntu/Debian still maintain (Arch Linux simply merged everything). 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.
- Esau 10y ago
  "Note that Arch follows the systemd FHS convention of symlinking" The Systemd convention? What the fuck? Does Systemd have to touch everything??
  - dsfyu404ed 10y ago
    Systemd walks into a bar, shoots the owner, proclaims it is the new owner, turns the bar into a casino, adds a hotel, a grocery store and an init system.
    - Hello71 10y ago
      systemd opens a new bar right next to the most popular bar in town, becomes far more popular (possibly due to better advertising), people complain that their beer tastes worse, and when other people tell them to just go to the original bar, they complain that all their friends are at the new bar.
      - cyphar 10y ago
        systemd stopped selling just beer a long time ago. It now sells books, used cars, cement mix and cheap Chinese take away.
rhabarba 10y ago
Today I learned that /usr actually means user, not Unified System Resources. Damn, one less thing I can nitpick about.
takeda 10y ago
MacPorts use /opt/local :)
- therein 10y ago
  I was about to say, I've seen /opt/local somewhere. :)
- drauh 10y ago
  And Fink uses /sw. Which left me looking for some other place to dump stuff I compiled myself.
- fit2rule 10y ago
  And, interestingly, HomeBrew uses /usr/local "because Apple left it for us when they abandoned this whole mess" ..
  - justincormack 10y ago
    /use/local/bin has the big advantage that it is in the default PATH.
dredmorbius 10y ago
Reasons why you still might want to keep / and /usr isolated: 1. NFS mounts. Your local or initial BOOTP image has a minimal root, your (non-root-writeable, BTW) NFS /usr has Other Stuff. 2. Mount options. Root is often (and perhaps still must 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 don't 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. 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.
- majewsky 10y ago
  mtab is not a problem anymore. On Arch, /etc/mtab is just a symlink to /proc/self/mounts. As for the recovery partition, you don't need the split for that, either. Just have a live system on the recovery partition that mounts the normal root FS. Then you can chroot into there for recovery tasks.
  - dredmorbius 10y ago
    Right, that seemed to be the mtab solution Debian were angling toward. I think there were some odd edge cases where it didn't behave well, though I don't recall what those were. Perhaps the ability to specifically edit the contents to allow fixing of fubared mounts -- almost certainly loopback or NFS, both of which get quite twitchy at times. I don't recall my precise thinking on a clean root vs. /usr split on the recovery partition, though it may have avoided some confusion over binaries. Or perhaps that you could mount the /usr partition itself independently if you wanted, assuming primary root was hosed. Not being able to mount a separate /usr would negate that option.
    - majewsky 10y ago
      > Not being able to mount a separate /usr would negate that option. You can mount the root to e.g. /mnt and symlink (or bind-mount) /mnt/usr to /usr, if that's what you need.
chrisamanse 10y ago
I thought 'usr' stands for "Unix System Resources"?
- dgemm 10y ago
  I think someone made that up retroactively.
RijilV 10y ago
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.
ChuckMcM 10y ago
Interesting. 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. 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. 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. 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?) 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. 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.
- JdeBP 10y ago
  > good enough for Windows right? Only in the minds of people who don't know much about Windows. The Windows model is, after all, for globally installed individual packages to be largely rooted at "/Program Files/%COMPANY_OR_PERSON%/%PACKAGE%/" with "%USERPROFILE%/AppData/Local/%COMPANY_OR_PERSON%/%PACKAGE%/" as a root for per-user data. The former dates all of the way back to Windows NT 3.5, the latter "merely" dating back to Windows NT 4 (where it was "Application Data" rather than "AppData"). * https://blogs.msdn.microsoft.com/cjacks/2008/02/05/where-should-i-write-program-data-instead-of-program-files/ https://blogs.msdn.microsoft.com/cjacks/2008/02/05/where-sho... Unix and Linux people will recognize this as akin to NeXTSTEP's ~/Apps, /LocalLibrary, /LocalApps, and so forth from the early 1990s; and to Daniel J. Bernstein's /package hierarchy (for package management without the need for conflict resolution) from the turn of the century. * http://cr.yp.to/slashpackage.html http://cr.yp.to/slashpackage.html * http://cr.yp.to/slashcommand.html http://cr.yp.to/slashcommand.html And a few years after NeXTSTEP introduced its directory hierarchy, SunOS 5 (a.k.a. Solaris 2) introduced the System 5 Release 4 /usr merge.
Annatar 10y ago
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). /opt: application payload /etc/opt: application's configuration files /var/opt: application's data. For applications with more than two configuration or data files, it is a good idea to create /etc/opt/application and /var/opt/application. 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.
- majewsky 10y ago
  > 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 What? Why should it be impossible for a third-party package to just create /opt? They will probably need to extend the PATH and LD_LIBRARY_PATH, but /etc/profile.d is very much standardized AFAIK.
  - dingaling 10y ago
    Indeed Adobe Reader for Linux used to land itself in /opt on Ubuntu. The power of run-as-su installers...
    - Annatar 10y ago
      The FHS thing in Debian and Ubuntu must be relatively new, I certainly have no recollection of it back then when we looked into delivering unbundled software for it. And we did look for it, and we even combed through the Debian packaging specification back then. Whatever it might be, or has been, if Debian and Ubuntu did get /opt, /etc/opt, and /var/opt and are now one small step closer to being System V compliant (from which FHS stems), I for one am very glad for that.
SFJulie 10y ago
I love the quote in the signature : GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke.
teamhappy 10y ago
/{bin,sbin} is for stuff you cannot live without (e.g., sh, mkdir, chmod, rm, ln, etc.) /usr/{bin,sbin} is for stuff you can live without but expect to be there (e.g., make, grep, less). /usr/local/{bin,sbin} is for stuff you/your local admin installed (e.g., mosh, cmake). 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). 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 has to work).
- mattmanser 10y ago
  Did you read the link?
  - teamhappy 10y ago
    Yup. I'm not sure what you're hinting at though. Are you saying that's not really why they exist? True, but that's how people use them.
- nilved 10y ago
  Regarding your last sentence, why does having grep in /bin reduce the chance of mkdir working?
  - teamhappy 10y ago
    I doesn't reduce the chance of mkdir working but it does increase the chance of you missing a bug in the part of your source tree that needs to be rock solid.

378 points by kylerpalmer 10y ago

I like that FreeBSD dedicates a man page, HIER(7), on this topic - https://www.freebsd.org/cgi/man.cgi?query=hier https://www.freebsd.org/cgi/man.cgi?query=hier - "layout of file systems"

protomyth 10y ago
The other major BSDs: http://man.openbsd.org/OpenBSD-current/man7/hier.7 http://man.openbsd.org/OpenBSD-current/man7/hier.7 http://netbsd.gw.com/cgi-bin/man-cgi?hier++NetBSD-current http://netbsd.gw.com/cgi-bin/man-cgi?hier++NetBSD-current https://www.dragonflybsd.org/cgi/web-man?command=hier&section=7 https://www.dragonflybsd.org/cgi/web-man?command=hier&sectio...
catern 10y ago
systemd has a man page on this as well, file-hierarchy(7): https://www.freedesktop.org/software/systemd/man/file-hierarchy.html https://www.freedesktop.org/software/systemd/man/file-hierar...

shirro 10y ago

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. 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.

tremon 10y ago
Funny. I always thought the /bin vs /sbin split made more sense than / vs /usr. I very much prefer that my shell's autocomplete does not stop on binaries that I have no business running as a normal user, so I like that root-only tools are in /sbin.

IshKebab 10y ago

I wonder what is more likely in our lifetimes - a sane Linux filesystem layout, or viable fusion power. Honestly I'm not sure.

ploxiln 10y ago
gobolinux - http://gobolinux.org/ http://gobolinux.org/ - has had a completely different filesystem layout, for many years. It's languished in the past few. archlinux has for a couple of years symlinked /bin, /sbin, and /usr/sbin to /usr/bin, and /lib, /lib64 to /usr/lib https://wiki.archlinux.org/index.php/arch_filesystem_hierarchy https://wiki.archlinux.org/index.php/arch_filesystem_hierarc... If you make your own linux distro from scratch, you can get many of the open source pieces of a linux distro to use whatever layout you want, while some pieces do require patching and fixing ... but you do have the source :)
- zanny 10y ago
  The problem with Gobo is that this progression never works: New FS Layout -> User Adoption -> Profit Because at the end of the day the layout of the filesystem is never the selling point on any given distro. It always comes down to the software - either the amount of it, or the newness of it, and that is why people flock to Ubuntu and Arch respectively. It is much more prudent to argue for filesystem improvements in those distros, and get them implemented there, than to fork it out. Gobo demonstrated both the validity and the utility of the approach, but it is up to distro makers to actually use the evidence given that the traditional Unix layout is garbage.
- digi_owl 10y ago
  Gobolinux still house the old layout for compatibility. Heck, i think it could adopt any any FS layout it wanted as long as some defined place to house the "Programs" tree was provided.
- rekado 10y ago
  Much like Gobolinux, Guix also has a completely different filesystem layout. Packages are installed into their own namespace under /gnu/store but then linked to expected locations under a profile root (such as ~/.guix-profile).

nickpsecurity 10y ago

NixOS is one of the few distros that recognizes and solves this problem: https://nixos.org/nixos/about.html https://nixos.org/nixos/about.html 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.

orik 10y ago
I was about to ask if any BSD's handle this better, great to see that NixOS does.
- gkya 10y ago
  In FreeBSD the base system stuff goes into /bin /lib and /etc, and all the ports target /usr/local as the prefix. Even the config files of the ports go to /usr/local/etc.
  - soupbowl 10y ago
    I really like how freebsd does it, nixos has me interested too.
    - gkya 10y ago
      Though NixOS and Guix form a different approach than the FreeBSD's, that is they treat packages as isolated immutable objects and use an unconventional directory layout (wanted to note this, because someone who doesn't know the OSs named may have thought that FreeBSD and NixOS/Guix approaches are similar).
aidenn0 10y ago
It's a lot more work to retroactively impose a new FS layout on an existing distribution than to come up with a new distribution. If e.g. Ubuntu did this then 1) They'd have to fix all of the packages in the main repository, and then PPAs? 2) Lots of third party software targeted on Ubuntu would break; this would cause a lot of users to want to stay on pre-change versions of Ubuntu, which probably means it would get forked.

chris_wot 10y ago

Well this partially answers my question at https://news.ycombinator.com/item?id=11647487 https://news.ycombinator.com/item?id=11647487

SquareWheel 10y ago

How badly would things break if we tried to "fix" this split today?

davb 10y ago
Probably not too badly if we took a phased approach. 1 - Establish a new, consistent filesystem hierarchy. New code should use the new hierarchy. Move the legacy stuff to the new hierarchy and symlink the old locations to avoid breakage. 2 - After some time, make the legacy locations read-only. This will highlight any non-conforming code. 3 - After even longer, delete the legacy paths. It would maybe be even easier if we could redirect writes (I'm not too versed in filesystem capabilities) from the legacy paths to the new ones.
- arthur2e5 10y ago
  > Establish a new, consistent filesystem hierarchy. systemd is kind of enforcing this already, preferring /usr (where most of the packages go) over naked paths. This is the trend on relatively modern desktop systems, which thankfully preserves standard fs hierarchy while mostly keeping everything in one place. (Unfortunately there are bunches of non-desktop uses for Linux out there.) See also https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ https://freedesktop.org/wiki/Software/systemd/separate-usr-i.... > It would maybe be even easier if we could redirect writes (I'm not too versed in filesystem capabilities) from the legacy paths to the new ones. Quite a few distros (and users like Rob Landley) use symlinks from /bin to /usr/bin and the same goes for /lib. sbin is sometimes linked to bin. This does some of the redirection. (I am not aware of the /usr/tmp and /var/etc stuff mentioned in the message.) > After even longer, delete the legacy paths. Nah. Millions of scripts are writing she-bangs like #!/bin/sh and I don't really expect to see this being changed... Workarounds using `env` is kind of crippled since a.) it introduces an extra level of dependency and indirection and b.) it stops the user from reliability passing options to the interpreter (Linux only cut at the first space, with all sorts of other *nixen doing different things with multiple spaces.)
  - Pxtl 10y ago

paxcoder 10y ago

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.

eridius 10y ago
It's not FUD, and GPLv3 is not clearly a superior license. It may surprise you to learn that different people value different things and have different opinions, and so want different licenses. GPLv3 is really a pretty extreme license that imposes a lot of restrictions that a lot of people simply don't want. If GPLv3 does what you want, by all means use it, but don't denigrate the choices other people make.
- jordigh 10y ago
  I wonder if people even know what those restrictions are and how exactly the anti-tivoisation clause works. It does not forbid anyone from running software on tivoised devices, which is what some people seem to think it does. All that it requires is that if you distribute the software primarily to be used on a User Product (as GPLv3 calls it), then as part of the installation information (which in GPLv2 used to just mean install and build scripts), you must also provide the signing keys for the hardware. This also does not mean that GPLv3 makes software signing impossible and that you must forbid users from rejecting unsigned software if they so wish. It doesn't mean that you have to distribute every secret key that you use for signing software. It merely means that you have to give your users a way to install software on the User Product as they see fit, if they see fit. It's up to the user to decide to override any signing feature or not. It's very much in spirit with GPLv2 that required installation scripts. As far as GPLv3, hardware signing keys are just another part of installation scripts (the actual term used in GPLv3 is "Installation Information"). http://radar.oreilly.com/2007/03/gplv3-user-products-clause.html http://radar.oreilly.com/2007/03/gplv3-user-products-clause.... https://copyleft.org/guide/comprehensive-gpl-guidech10.html#x13-820009.9.2 https://copyleft.org/guide/comprehensive-gpl-guidech10.html#...
  - eridius 10y ago

bbanyc 10y ago

Nitpicking: 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. (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.) 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.

digi_owl 10y ago
I can't help think that initramfs is a pox on Linux. It seems to lead to all kinds of "solutions" that are bothersome at best to maintain unless you have big dollars at your back.
- kakwa_ 10y ago
  I've never quite understood it myself. It's far from mandatory (I've run Gentoo for years without it) and when you have to fix stuff in the mkinitrd script, you just cry...
kps 10y ago
> And /home never existed before Linux SunOS used /home before Linux existed.

m45t3r 10y ago

For all people that think this is still a issue: it is not: * Arch Linux: https://wiki.archlinux.org/index.php/Arch_filesystem_hierarchy https://wiki.archlinux.org/index.php/Arch_filesystem_hierarc... * Fedora: https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove * Debian: https://wiki.debian.org/UsrMerge https://wiki.debian.org/UsrMerge * Ubuntu: https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMerge https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMer... 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. The only thing that remains is the difference between bin and sbin that Fedora/Ubuntu/Debian still maintain (Arch Linux simply merged everything). 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.

Esau 10y ago
"Note that Arch follows the systemd FHS convention of symlinking" The Systemd convention? What the fuck? Does Systemd have to touch everything??
- dsfyu404ed 10y ago
  Systemd walks into a bar, shoots the owner, proclaims it is the new owner, turns the bar into a casino, adds a hotel, a grocery store and an init system.
  - Hello71 10y ago
    systemd opens a new bar right next to the most popular bar in town, becomes far more popular (possibly due to better advertising), people complain that their beer tastes worse, and when other people tell them to just go to the original bar, they complain that all their friends are at the new bar.
    - cyphar 10y ago
      systemd stopped selling just beer a long time ago. It now sells books, used cars, cement mix and cheap Chinese take away.

rhabarba 10y ago

Today I learned that /usr actually means user, not Unified System Resources. Damn, one less thing I can nitpick about.

takeda 10y ago

MacPorts use /opt/local :)

therein 10y ago
I was about to say, I've seen /opt/local somewhere. :)
drauh 10y ago
And Fink uses /sw. Which left me looking for some other place to dump stuff I compiled myself.
fit2rule 10y ago
And, interestingly, HomeBrew uses /usr/local "because Apple left it for us when they abandoned this whole mess" ..
- justincormack 10y ago
  /use/local/bin has the big advantage that it is in the default PATH.

dredmorbius 10y ago

Reasons why you still might want to keep / and /usr isolated: 1. NFS mounts. Your local or initial BOOTP image has a minimal root, your (non-root-writeable, BTW) NFS /usr has Other Stuff. 2. Mount options. Root is often (and perhaps still must 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 don't 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. 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.

majewsky 10y ago
mtab is not a problem anymore. On Arch, /etc/mtab is just a symlink to /proc/self/mounts. As for the recovery partition, you don't need the split for that, either. Just have a live system on the recovery partition that mounts the normal root FS. Then you can chroot into there for recovery tasks.
- dredmorbius 10y ago
  Right, that seemed to be the mtab solution Debian were angling toward. I think there were some odd edge cases where it didn't behave well, though I don't recall what those were. Perhaps the ability to specifically edit the contents to allow fixing of fubared mounts -- almost certainly loopback or NFS, both of which get quite twitchy at times. I don't recall my precise thinking on a clean root vs. /usr split on the recovery partition, though it may have avoided some confusion over binaries. Or perhaps that you could mount the /usr partition itself independently if you wanted, assuming primary root was hosed. Not being able to mount a separate /usr would negate that option.
  - majewsky 10y ago
    > Not being able to mount a separate /usr would negate that option. You can mount the root to e.g. /mnt and symlink (or bind-mount) /mnt/usr to /usr, if that's what you need.

chrisamanse 10y ago

I thought 'usr' stands for "Unix System Resources"?

dgemm 10y ago
I think someone made that up retroactively.

RijilV 10y ago

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.

ChuckMcM 10y ago

Interesting. 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. 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. 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. 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?) 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. 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.

JdeBP 10y ago
> good enough for Windows right? Only in the minds of people who don't know much about Windows. The Windows model is, after all, for globally installed individual packages to be largely rooted at "/Program Files/%COMPANY_OR_PERSON%/%PACKAGE%/" with "%USERPROFILE%/AppData/Local/%COMPANY_OR_PERSON%/%PACKAGE%/" as a root for per-user data. The former dates all of the way back to Windows NT 3.5, the latter "merely" dating back to Windows NT 4 (where it was "Application Data" rather than "AppData"). * https://blogs.msdn.microsoft.com/cjacks/2008/02/05/where-should-i-write-program-data-instead-of-program-files/ https://blogs.msdn.microsoft.com/cjacks/2008/02/05/where-sho... Unix and Linux people will recognize this as akin to NeXTSTEP's ~/Apps, /LocalLibrary, /LocalApps, and so forth from the early 1990s; and to Daniel J. Bernstein's /package hierarchy (for package management without the need for conflict resolution) from the turn of the century. * http://cr.yp.to/slashpackage.html http://cr.yp.to/slashpackage.html * http://cr.yp.to/slashcommand.html http://cr.yp.to/slashcommand.html And a few years after NeXTSTEP introduced its directory hierarchy, SunOS 5 (a.k.a. Solaris 2) introduced the System 5 Release 4 /usr merge.

Annatar 10y ago

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). /opt: application payload /etc/opt: application's configuration files /var/opt: application's data. For applications with more than two configuration or data files, it is a good idea to create /etc/opt/application and /var/opt/application. 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.

majewsky 10y ago
> 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 What? Why should it be impossible for a third-party package to just create /opt? They will probably need to extend the PATH and LD_LIBRARY_PATH, but /etc/profile.d is very much standardized AFAIK.
- dingaling 10y ago
  Indeed Adobe Reader for Linux used to land itself in /opt on Ubuntu. The power of run-as-su installers...
  - Annatar 10y ago
    The FHS thing in Debian and Ubuntu must be relatively new, I certainly have no recollection of it back then when we looked into delivering unbundled software for it. And we did look for it, and we even combed through the Debian packaging specification back then. Whatever it might be, or has been, if Debian and Ubuntu did get /opt, /etc/opt, and /var/opt and are now one small step closer to being System V compliant (from which FHS stems), I for one am very glad for that.

SFJulie 10y ago

I love the quote in the signature : GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke.

teamhappy 10y ago

/{bin,sbin} is for stuff you cannot live without (e.g., sh, mkdir, chmod, rm, ln, etc.) /usr/{bin,sbin} is for stuff you can live without but expect to be there (e.g., make, grep, less). /usr/local/{bin,sbin} is for stuff you/your local admin installed (e.g., mosh, cmake). 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). 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 has to work).

mattmanser 10y ago
Did you read the link?
- teamhappy 10y ago
  Yup. I'm not sure what you're hinting at though. Are you saying that's not really why they exist? True, but that's how people use them.
nilved 10y ago
Regarding your last sentence, why does having grep in /bin reduce the chance of mkdir working?
- teamhappy 10y ago
  I doesn't reduce the chance of mkdir working but it does increase the chance of you missing a bug in the part of your source tree that needs to be rock solid.