3 ms·

And BSD users have been doing this forever. I know I've read about why Linux is divergent, but I forget why.

by barakm 14y ago

morpher 14y ago
Almost all software I've custom built over the last 13 years of using Linux has, by default, set the prefix to /use/local. I don't know if ruby is for some reason different, but installing software outside of /usr/local is not something to snark at Linux about...
- barakm 14y ago
  No snark intended. I mean only to recognize BSD in the discussion as having made another choice. And yes, Linux custom-built software goes into /usr/local without a hitch. But really, the question comes down to layers of abstraction. Is /bin the base system? Is /usr/bin? Is /usr/local/bin? Probably not on the last one, but Linux distros have chosen /usr/bin as where all packages install. And BSD treats packages as user programs and goes to /usr/local/bin. I'm not saying one is right. At best, I'm advocating use of "#!/usr/bin/env foo" instead of some of the assumptions made by some shell scripters.
  - npsimons 14y ago
    But really, the question comes down to layers of abstraction. Is /bin the base system? Is /usr/bin? Is /usr/local/bin? Probably not on the last one, but Linux distros have chosen /usr/bin as where all packages install. And BSD treats packages as user programs and goes to /usr/local/bin. As I've always understood it, since /usr can be on another partition (to keep / small, or keep it from filling up with stuff from /usr, /home, /tmp, and the like), /bin should contain "essential" binaries for booting that weren't necessarily "system" tools (those would go in /sbin). Now that I think of it, I can't really think of binaries essential to booting that aren't "system" tools, but my Linux boxes typically have about a hundred CLI programs that are basic, but not essential (AFAICT) to booting in there. They're all from packages.
    - alexchamberlain 14y ago
      Bash is well qualified for /bin.
    - qznc 14y ago
      Apparently most modern Linux distros cannot boot anymore without /usr. Therefore people suggest to link /bin to /usr/bin etc. /usr/local still has its place, though. http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT...
      - npsimons 14y ago
        I'm pretty sure Debian (my Linux of choice) can boot without /usr. And I love how on that page they bring up BS such as "well Fedora has 450MB (of crap) in /, so that's not minimal". I've got at least one Debian box packed to the gills with programming languages, scientific software and who knows what else, and it clocks in at right around 129MB for /. Maybe Fedora is doing it wrong; wouldn't surprise me, as I switched from RH to Debian over a decade ago because of dependency hell. I'm not sure linking /bin to /usr/bin is a good idea; it may have merits, but many of the reasons they bring up seem dubious ("Solaris is doing it!", yeah like Solaris should be the gold standard; "hard coded paths!" - recompile). I'm not opposed to progress, but some change isn't progress. It's interesting to me that this initiative is being pushed by Lennart Poettering - well known for his work on PulseAudio and systemd, two other controverisal Linux subsystems. While systemd is still unproven (and quite frankly, Poettering's talk at Linux Plumbers about systemd subsuming more control scared me; it's like a hydra!), PulseAudio appears to have finally become stable and usable. I guess time will tell with both systemd and /usr-merging. Another interesting point from Poettering's talk was that he wanted to take more after BSD, especially having the one "correct" way to do it. Me, I like having options, especially in the case of "what if the 'correct' way doesn't work?" (http://news.ycombinator.com/item?id=4409768 http://news.ycombinator.com/item?id=4409768).
    - pferde 14y ago
      The way I understand it, the 's' in "/sbin" does not stand for "system", but for "superuser" - essential system tools which need superuser privileges (insmod, ifconfig, fsck, ...) /bin should contain all the non-privileged essential tools for system to boot up and execute all its initscripts - stuff like echo, cat, grep, awk, sed, chmod and many other everyday tools. In addition, it should contain tools which will allow you to repair a broken system in minimal environment (where only / is available to you). So, stuff like ls, mount, gunzip, dmesg, ...
ajross 14y ago
Linux isn't divergent, except for the common practice (though not quite a standard) of using /opt for non-distro package-installed software. All autotools-based packages drop themselves into a prefix of /usr/local by default, which makes the admonition to pass --prefix=/usr/local to configure a little strange.
lmm 14y ago
It's the BSD approach that's divergent. /usr/local is supposed to belong to programs that have been manually installed by the administrator. BSD's awkward and frankly unhelpful split between packages and ports means they need one more level of hierarchy than linux (rather than package-managed programs and manually installed programs, you have package-managed programs, ports-managed programs and manually installed programs); unfortunately they've taken over /usr/local for the ports-managed programs, leaving you with nowhere for manually installed programs. And while ports purports to support a configuration variable for changing where ports software gets installed to, it must not get tested because a number of programs break if you try and actually use it.

And BSD users have been doing this forever. I know I've read about why Linux is divergent, but I forget why.

by barakm 14y ago

And BSD users have been doing this forever. I know I've read about why Linux is divergent, but I forget why.

Almost all software I've custom built over the last 13 years of using Linux has, by default, set the prefix to /use/local. I don't know if ruby is for some reason different, but installing software outside of /usr/local is not something to snark at Linux about...

barakm 14y ago
No snark intended. I mean only to recognize BSD in the discussion as having made another choice. And yes, Linux custom-built software goes into /usr/local without a hitch. But really, the question comes down to layers of abstraction. Is /bin the base system? Is /usr/bin? Is /usr/local/bin? Probably not on the last one, but Linux distros have chosen /usr/bin as where all packages install. And BSD treats packages as user programs and goes to /usr/local/bin. I'm not saying one is right. At best, I'm advocating use of "#!/usr/bin/env foo" instead of some of the assumptions made by some shell scripters.
- npsimons 14y ago
  But really, the question comes down to layers of abstraction. Is /bin the base system? Is /usr/bin? Is /usr/local/bin? Probably not on the last one, but Linux distros have chosen /usr/bin as where all packages install. And BSD treats packages as user programs and goes to /usr/local/bin. As I've always understood it, since /usr can be on another partition (to keep / small, or keep it from filling up with stuff from /usr, /home, /tmp, and the like), /bin should contain "essential" binaries for booting that weren't necessarily "system" tools (those would go in /sbin). Now that I think of it, I can't really think of binaries essential to booting that aren't "system" tools, but my Linux boxes typically have about a hundred CLI programs that are basic, but not essential (AFAICT) to booting in there. They're all from packages.
  - alexchamberlain 14y ago
    Bash is well qualified for /bin.
  - qznc 14y ago
    Apparently most modern Linux distros cannot boot anymore without /usr. Therefore people suggest to link /bin to /usr/bin etc. /usr/local still has its place, though. http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT...
    - npsimons 14y ago
      I'm pretty sure Debian (my Linux of choice) can boot without /usr. And I love how on that page they bring up BS such as "well Fedora has 450MB (of crap) in /, so that's not minimal". I've got at least one Debian box packed to the gills with programming languages, scientific software and who knows what else, and it clocks in at right around 129MB for /. Maybe Fedora is doing it wrong; wouldn't surprise me, as I switched from RH to Debian over a decade ago because of dependency hell. I'm not sure linking /bin to /usr/bin is a good idea; it may have merits, but many of the reasons they bring up seem dubious ("Solaris is doing it!", yeah like Solaris should be the gold standard; "hard coded paths!" - recompile). I'm not opposed to progress, but some change isn't progress. It's interesting to me that this initiative is being pushed by Lennart Poettering - well known for his work on PulseAudio and systemd, two other controverisal Linux subsystems. While systemd is still unproven (and quite frankly, Poettering's talk at Linux Plumbers about systemd subsuming more control scared me; it's like a hydra!), PulseAudio appears to have finally become stable and usable. I guess time will tell with both systemd and /usr-merging. Another interesting point from Poettering's talk was that he wanted to take more after BSD, especially having the one "correct" way to do it. Me, I like having options, especially in the case of "what if the 'correct' way doesn't work?" (http://news.ycombinator.com/item?id=4409768 http://news.ycombinator.com/item?id=4409768).
  - pferde 14y ago
    The way I understand it, the 's' in "/sbin" does not stand for "system", but for "superuser" - essential system tools which need superuser privileges (insmod, ifconfig, fsck, ...) /bin should contain all the non-privileged essential tools for system to boot up and execute all its initscripts - stuff like echo, cat, grep, awk, sed, chmod and many other everyday tools. In addition, it should contain tools which will allow you to repair a broken system in minimal environment (where only / is available to you). So, stuff like ls, mount, gunzip, dmesg, ...

ajross 14y ago

Linux isn't divergent, except for the common practice (though not quite a standard) of using /opt for non-distro package-installed software. All autotools-based packages drop themselves into a prefix of /usr/local by default, which makes the admonition to pass --prefix=/usr/local to configure a little strange.

lmm 14y ago

It's the BSD approach that's divergent. /usr/local is supposed to belong to programs that have been manually installed by the administrator. BSD's awkward and frankly unhelpful split between packages and ports means they need one more level of hierarchy than linux (rather than package-managed programs and manually installed programs, you have package-managed programs, ports-managed programs and manually installed programs); unfortunately they've taken over /usr/local for the ports-managed programs, leaving you with nowhere for manually installed programs. And while ports purports to support a configuration variable for changing where ports software gets installed to, it must not get tested because a number of programs break if you try and actually use it.