5 ms·

This post gets some of the details wrong. /usr/local is for site-local software - e.g. things you compile yourself, i.e in the case of the BSDs the ports collec

This post gets some of the details wrong. /usr/local is for site-local software - e.g. things you compile yourself, i.e in the case of the BSDs the ports collection - things outside the base system. (They may be compiled for you). Since Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it - this distinction makes no sense on Linux. /opt is generally for software distros for which you don't have source; only binaries. Like commercial software packages. More common on Real UNIX(R) because most Linux users outside enterprise aren't running commercial software. You're putting your $500k EDA software under /opt.

yjftsjthsd-h 9mo ago
> Since Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it - this distinction makes no sense on Linux. The Linux base system is managed by the package manager, leaving local for the sysadmin to `make install` into
- schmuckonwheels 9mo ago
  > The Linux base system There is no such thing as a Linux base system. Separate components, separate people. Hence the term Ganoo plus Leenox...
  - yjftsjthsd-h 9mo ago
    Well, no, my exact argument is that there is a base system, even if it is composed of assorted components. If you install Debian (or whatever) on a machine, the software installed by the package manager ships as a unified release that has been adapted to work together. I think it's reasonable to call that the base OS. And then, separate from that base system that is managed by the package manager, the local admin my install things into /usr/local.
    - schmuckonwheels 9mo ago
      If you can remove GNU coreutils and replace them with something else (like that Rust garbage) then you don't have a base system. You have a loose collection of packages around a kernel.
      - Krutonium 9mo ago
        Replaces the GNU Coreutils with the Rusty ones on BSD
        hnlmorg 9mo ago
        Which BSD ships GNU Coreutils? Every occasion I’ve seen GNU coreutils installed on BSD, it’s been outside of the base and thus installed outside of /bin. Eg /usr/local or /opt/homebrew
        LoganDark 9mo ago
        BSD has its own coreutils, in fact they even predate GNU.
    - LoganDark 9mo ago
      They're talking about Linux, the kernel. The kernel has no concept of a base system. There is initramfs and init.
      - yjftsjthsd-h 9mo ago
        Okay, that's true but other than the slight semantic point of "Linux" vs a "Linux distro" or "GNU/Linux" I don't think it matters. Whatever words you use to describe it, there is a base OS which is composed of a variety of components from different sources but which ultimately amounts to a single thing.
        LoganDark 9mo ago
        > there is a base OS In most distributions yes, there is Linux and then there is userspace on top of it. What you call "base system" is actually part of userspace, which has nothing to do with Linux itself.
theandrewbailey 9mo ago
> /opt is generally for software distros for which you don't have source; only binaries. Like commercial software packages. More common on Real UNIX(R) because most Linux users outside enterprise aren't running commercial software Steam says hi. On Windows, a common Steam library exists in Program Files directory, therefore not user specific. On Linux, each user has a separate Steam installation and library. I'm not sure why there isn't a common Steam library on Linux, but /opt would be a good place for it.
- schmuckonwheels 9mo ago
  By default, Program Files is not writable by non-Administrators. This is likely done by some background service. Or they loosened the default file permissions (which would be dumb). No reason this can't be done on Linux but since NT's security model is more flexible it's a lot easier to do so on Windows. You'd need to add dedicated users. (Running a Steam daemon as root would probably cause an uproar.)
  - Dylan16807 9mo ago
    They loosen the permissions on the steam folder on windows. I would have expected just the library folder but apparently it's the whole thing.
    - schmuckonwheels 9mo ago
      Oof. The correct location for this is C:\ProgramData Developers who knowingly reduce or disable default Windows security settings should be censured. Because in 99% of cases it is due to ignorance or plain laziness.
      - Dylan16807 9mo ago
        Well ProgramData didn't exist when they designed it, and the crime of putting their folder in the wrong place is a pretty minor one. They don't change the permissions of anything outside Steam. It doesn't "reduce or disable default Windows security settings" in a meaningful way if you say to yourself "that folder effectively is in ProgramData, but spelled wrong".
immibis 9mo ago
I understand /usr/local to be for anything not managed by your distribution but following the standard system layout (e.g. Python that you compiled yourself) while /opt is used for things that are (relatively) self-contained and don't integrate with the system, similar to Program Files on Windows (e.g. a lot of Java software). Regarding "that's a Linux-ism" - well yeah? Linux is the main OS this is about. FreeBSD can do what it wants, too.
- schmuckonwheels 9mo ago
  > anything not managed by your distribution That's a Linux-ism. Other *nix there is a lot more in /usr/local. In reality /usr is similar to Windows' System32 directory on most Unicies. /opt is really the only good place for Java and where I've been putting it for decades (old habits die hard).
loeg 9mo ago
You've entirely missed the point of the article.
shevy-java 9mo ago
> /usr/local is for site-local software - e.g. things you compile yourself See, you assume here that /usr/local/ makes any sense. I use a versioned appdir prefix approach similar to GoboLinux. So for me, /usr/local never ever made any sense at all. Why should I adhere to it? I have ruby under e. g. /Programs/Ruby/4.0.0/. It would not matter in the slightest WHO would compile it, but IF I were to need to store that information, I would put that information under that directory too, perhaps in a file such as environment.md or some other file; and perhaps additionally into a global database if it were important to distinguish (but it is not). The problem here is that you do not challenge the notion whether /usr/local/ would make any sense to begin with. > /opt is generally for software distros for which you don't have source; only binaries. Makes no sense. It seems to be about as logical as the FHS "standard". Why would I need to use /opt/? If I install libreoffice or google chrome there under /opt, I can as well install it under e. g. /Programs/ or whatever hierarchy I use for versioned appdirs. Which I actually do. So why would I need /opt/ again?
- hnlmorg 9mo ago
  > See, you assume here that /usr/local/ makes any sense. You’re presenting your comment as a rebuttal but you’re actually arguing something completely different to the OP. They’re talking about UNIX convention from a historic perspective. Whereas you’re talking about your own opinions about what would make sense if we were to design the file system hierarchy today. I don’t disagree with your general points, but it also doesn’t mean that the OP is incorrect either.
nyrikki 9mo ago
While practically useless in reality /usr/local is `site-local software`, E.G. software that if you nfs mounted /usr, would be local to the `site` not the machine. The BSD ports explanation is a bit revisionist I hate to say, this all predates ports. It was a location in a second stage mount you knew the upstream wouldn’t overwrite with tar or cpio. Later ports used it to avoid the same conflict.
asveikau 9mo ago
I seem to recall Solaris put packages in /opt. Each package got its own prefix under /opt.
Uehreka 9mo ago
I normally wouldn’t be this pedantic, but given that this is a conversation about pedantry it only seems right: you’re using i.e. and e.g. backwards.
- rrauenza 9mo ago
  My mnemonic is “In Essence” and “for EGsample”
  - NewJazz 9mo ago
    I just remember the actual words: * e.g. exempli gratia (or, in Spanish, ejemplo gratis) * i.e. id est (literally means "that is")
    - dataflow 9mo ago
      "example given" is what I've found easiest to remember.
  - RickHull 9mo ago
    I like: "In Ether words" and "Example Given"
aap_ 9mo ago
> This post gets some of the details wrong "some" is an understatement.
sohrob 9mo ago
Now I get what the folks using FreeBSD typically like to point to as a reason why they prefer FreeBSD over Linux because there is a clear distinction between the base system and userland.
- NewJazz 9mo ago
  Linux has more of a clear distinction between kernel and userspace. But the base system in *BSD includes a lot of userspace, so the API boundary is more the libc and some core libraries (TLS) instead of the kernel ABI.
- asveikau 9mo ago
  FreeBSD is moving to a scheme where the base system is managed with pkg. In the release notes for last month's 15.0 release, they suggest that this will be mandatory in 16.0. The ports tree will still be very different from base, but I feel this may erode some of the difference between FreeBSD and a typical Linux distro in terms of user experience, with respect to base vs ports. You'll update both with pkg.
ajross 9mo ago
> Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it Good grief. How does this end up as the top comment on HN of all places? I'll bet anything that this author also thinks that systemd is way too opinionated and unified and that the system needs a less coupled set of init code. Edit to be at least a tiny bit more productive: the Linux Filesystem Hierarchy Standard is about to pop the cork on its thirty second birthday. It's likely older than most of the people upvoting the post I responded to. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard To wit: that's outrageous nonsense, and anyone who know anything about how a Linux distro is put together (which I thought would have included most of the readers here, but alas) would know that.
xattt 9mo ago
So, in Debian, where should I be placing a Firefox tarball I download from Mozilla’s site? It is open-source, and I can get source files, but it’s precompiled…
- SAI_Peregrinus 9mo ago
  Anywhere in your `$PATH` that isn't managed by `apt`/`dpkg`. E.g. add `~/bin` to your `$PATH`, and install it in there. No risk of overwriting files the system package manager manages & having manually-installed software break next time it updates them.
JdeBP 9mo ago
The problems with what you say are that: 1. The history of /usr subdirectories is a lot more complex than that. There was a /usr/lbin once, for example. 1. /usr/local is not where third party softwares from packages/ports go on "the BSDs". On NetBSD, they go in /usr/pkg instead, again exemplifying that this is quite complex through history and across operating systems.

yjftsjthsd-h 9mo ago

> Since Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it - this distinction makes no sense on Linux. The Linux base system is managed by the package manager, leaving local for the sysadmin to `make install` into

schmuckonwheels 9mo ago
> The Linux base system There is no such thing as a Linux base system. Separate components, separate people. Hence the term Ganoo plus Leenox...
- yjftsjthsd-h 9mo ago
  Well, no, my exact argument is that there is a base system, even if it is composed of assorted components. If you install Debian (or whatever) on a machine, the software installed by the package manager ships as a unified release that has been adapted to work together. I think it's reasonable to call that the base OS. And then, separate from that base system that is managed by the package manager, the local admin my install things into /usr/local.
  - schmuckonwheels 9mo ago
    If you can remove GNU coreutils and replace them with something else (like that Rust garbage) then you don't have a base system. You have a loose collection of packages around a kernel.
    - Krutonium 9mo ago
      Replaces the GNU Coreutils with the Rusty ones on BSD
      - hnlmorg 9mo ago
        Which BSD ships GNU Coreutils? Every occasion I’ve seen GNU coreutils installed on BSD, it’s been outside of the base and thus installed outside of /bin. Eg /usr/local or /opt/homebrew
      - LoganDark 9mo ago
        BSD has its own coreutils, in fact they even predate GNU.
  - LoganDark 9mo ago
    They're talking about Linux, the kernel. The kernel has no concept of a base system. There is initramfs and init.
    - yjftsjthsd-h 9mo ago
      Okay, that's true but other than the slight semantic point of "Linux" vs a "Linux distro" or "GNU/Linux" I don't think it matters. Whatever words you use to describe it, there is a base OS which is composed of a variety of components from different sources but which ultimately amounts to a single thing.
      - LoganDark 9mo ago
        > there is a base OS In most distributions yes, there is Linux and then there is userspace on top of it. What you call "base system" is actually part of userspace, which has nothing to do with Linux itself.

theandrewbailey 9mo ago

> /opt is generally for software distros for which you don't have source; only binaries. Like commercial software packages. More common on Real UNIX(R) because most Linux users outside enterprise aren't running commercial software Steam says hi. On Windows, a common Steam library exists in Program Files directory, therefore not user specific. On Linux, each user has a separate Steam installation and library. I'm not sure why there isn't a common Steam library on Linux, but /opt would be a good place for it.

schmuckonwheels 9mo ago
By default, Program Files is not writable by non-Administrators. This is likely done by some background service. Or they loosened the default file permissions (which would be dumb). No reason this can't be done on Linux but since NT's security model is more flexible it's a lot easier to do so on Windows. You'd need to add dedicated users. (Running a Steam daemon as root would probably cause an uproar.)
- Dylan16807 9mo ago
  They loosen the permissions on the steam folder on windows. I would have expected just the library folder but apparently it's the whole thing.
  - schmuckonwheels 9mo ago
    Oof. The correct location for this is C:\ProgramData Developers who knowingly reduce or disable default Windows security settings should be censured. Because in 99% of cases it is due to ignorance or plain laziness.
    - Dylan16807 9mo ago
      Well ProgramData didn't exist when they designed it, and the crime of putting their folder in the wrong place is a pretty minor one. They don't change the permissions of anything outside Steam. It doesn't "reduce or disable default Windows security settings" in a meaningful way if you say to yourself "that folder effectively is in ProgramData, but spelled wrong".

immibis 9mo ago

I understand /usr/local to be for anything not managed by your distribution but following the standard system layout (e.g. Python that you compiled yourself) while /opt is used for things that are (relatively) self-contained and don't integrate with the system, similar to Program Files on Windows (e.g. a lot of Java software). Regarding "that's a Linux-ism" - well yeah? Linux is the main OS this is about. FreeBSD can do what it wants, too.

schmuckonwheels 9mo ago
> anything not managed by your distribution That's a Linux-ism. Other *nix there is a lot more in /usr/local. In reality /usr is similar to Windows' System32 directory on most Unicies. /opt is really the only good place for Java and where I've been putting it for decades (old habits die hard).

loeg 9mo ago

You've entirely missed the point of the article.

shevy-java 9mo ago

> /usr/local is for site-local software - e.g. things you compile yourself See, you assume here that /usr/local/ makes any sense. I use a versioned appdir prefix approach similar to GoboLinux. So for me, /usr/local never ever made any sense at all. Why should I adhere to it? I have ruby under e. g. /Programs/Ruby/4.0.0/. It would not matter in the slightest WHO would compile it, but IF I were to need to store that information, I would put that information under that directory too, perhaps in a file such as environment.md or some other file; and perhaps additionally into a global database if it were important to distinguish (but it is not). The problem here is that you do not challenge the notion whether /usr/local/ would make any sense to begin with. > /opt is generally for software distros for which you don't have source; only binaries. Makes no sense. It seems to be about as logical as the FHS "standard". Why would I need to use /opt/? If I install libreoffice or google chrome there under /opt, I can as well install it under e. g. /Programs/ or whatever hierarchy I use for versioned appdirs. Which I actually do. So why would I need /opt/ again?

hnlmorg 9mo ago
> See, you assume here that /usr/local/ makes any sense. You’re presenting your comment as a rebuttal but you’re actually arguing something completely different to the OP. They’re talking about UNIX convention from a historic perspective. Whereas you’re talking about your own opinions about what would make sense if we were to design the file system hierarchy today. I don’t disagree with your general points, but it also doesn’t mean that the OP is incorrect either.

nyrikki 9mo ago

While practically useless in reality /usr/local is `site-local software`, E.G. software that if you nfs mounted /usr, would be local to the `site` not the machine. The BSD ports explanation is a bit revisionist I hate to say, this all predates ports. It was a location in a second stage mount you knew the upstream wouldn’t overwrite with tar or cpio. Later ports used it to avoid the same conflict.

asveikau 9mo ago

I seem to recall Solaris put packages in /opt. Each package got its own prefix under /opt.

Uehreka 9mo ago

I normally wouldn’t be this pedantic, but given that this is a conversation about pedantry it only seems right: you’re using i.e. and e.g. backwards.

rrauenza 9mo ago
My mnemonic is “In Essence” and “for EGsample”
- NewJazz 9mo ago
  I just remember the actual words: * e.g. exempli gratia (or, in Spanish, ejemplo gratis) * i.e. id est (literally means "that is")
  - dataflow 9mo ago
    "example given" is what I've found easiest to remember.
- RickHull 9mo ago
  I like: "In Ether words" and "Example Given"

aap_ 9mo ago

> This post gets some of the details wrong "some" is an understatement.

sohrob 9mo ago

Now I get what the folks using FreeBSD typically like to point to as a reason why they prefer FreeBSD over Linux because there is a clear distinction between the base system and userland.

NewJazz 9mo ago
Linux has more of a clear distinction between kernel and userspace. But the base system in *BSD includes a lot of userspace, so the API boundary is more the libc and some core libraries (TLS) instead of the kernel ABI.
asveikau 9mo ago
FreeBSD is moving to a scheme where the base system is managed with pkg. In the release notes for last month's 15.0 release, they suggest that this will be mandatory in 16.0. The ports tree will still be very different from base, but I feel this may erode some of the difference between FreeBSD and a typical Linux distro in terms of user experience, with respect to base vs ports. You'll update both with pkg.

ajross 9mo ago

> Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it Good grief. How does this end up as the top comment on HN of all places? I'll bet anything that this author also thinks that systemd is way too opinionated and unified and that the system needs a less coupled set of init code. Edit to be at least a tiny bit more productive: the Linux Filesystem Hierarchy Standard is about to pop the cork on its thirty second birthday. It's likely older than most of the people upvoting the post I responded to. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard To wit: that's outrageous nonsense, and anyone who know anything about how a Linux distro is put together (which I thought would have included most of the readers here, but alas) would know that.

xattt 9mo ago

So, in Debian, where should I be placing a Firefox tarball I download from Mozilla’s site? It is open-source, and I can get source files, but it’s precompiled…

SAI_Peregrinus 9mo ago
Anywhere in your `$PATH` that isn't managed by `apt`/`dpkg`. E.g. add `~/bin` to your `$PATH`, and install it in there. No risk of overwriting files the system package manager manages & having manually-installed software break next time it updates them.

JdeBP 9mo ago

The problems with what you say are that: 1. The history of /usr subdirectories is a lot more complex than that. There was a /usr/lbin once, for example. 1. /usr/local is not where third party softwares from packages/ports go on "the BSDs". On NetBSD, they go in /usr/pkg instead, again exemplifying that this is quite complex through history and across operating systems.