I’ve seen a lot of self-hosted software wanting to store their data in /opt, is there any reason why?
"Traditionally, the /opt directory is used for installing/storing the files of third-party applications that are not available from the distribution’s repository.
The normal practice is to keep the software code in opt and then link the binary file in the /bin directory so that all the users can run it."
Let’s say you want to compile and install a program for yourself from its source code form. There’s generally a lot of choice here:
You could (theoretically) use / as its installation prefix, meaning its binaries would then probably go underneath /bin, its libraries underneath /lib, its asset files underneath /share, and so on. But that would be terrible because it would go against all conventions. Conventions (FHS etc.) state that the more “important” a program is, the closer it should be to the root of the filesystem (“/”). Meaning, /bin would be reserved for core system utilities, not any graphical end user applications.
You could also use /usr as installation prefix, in which case it would go into /usr/bin, /usr/lib, /usr/share, etc… but that’s also a terrible idea, because your package manager respectively the package maintainers of the packages you install from your distribution use that as their installation prefix. Everything underneath /usr (except /usr/local) is under the “administration” of your distro’s packages and package manager and so you should never put other stuff there.
/usr/local is the exception. It’s where it’s safe to put any other stuff. Then there’s also /opt. Both are similar. Underneath /usr/local, a program would be traditionally split up based on file type - binaries would go into /usr/local/bin, etc. - everything’s split up. But as long as you made a package out of the installation, your package manager knows what files belong to this program, so not a big deal. It would be a big deal if you installed it without a package manager though - then you’d probably be unable to find any of the installed files when you want to remove them. /opt is different in that regard - here, everything is underneath /opt/<programname>/, so all files belonging to a program can easily be found. As a downside, you’d always have to add /opt/<programname>/ to your $PATH if you want to run the program’s executable directly from the commandline. So /opt behaves similar to C:\Program Files\ on Windows. The other locations are meant to be more Unix-style and split up each program’s files. But everything in the filesystem is a convention, not a hard and fast rule, you could always change everything. But it’s not recommended.
Another option altogether is to just install it on a per-user basis into your $HOME somewhere, probably underneath ~/.local/ as an installation prefix. Then you’d have binaries in ~/.local/bin/ (which is also where I place any self-writtten scripts and small single scripts/executables), etc. Using a hidden directory like .local also means you won’t clutter your home directory visually so much. Also, ~/.local/share, ~/.local/state and so on are already defined by the XDG FreeDesktop standards anyway, so using ~/.local is a great idea for installing stuff for your user only.
Hope that helps clear up some confusion. But it’s still confusing overall because the FHS is a historically grown standard and the Unix filesystem tree isn’t really 100% rational or well-thought out. It’s a historically grown thing. Modern Linux applications and packaging strategies do mitigate some of its problems and try to make things more consistent (e.g. by symlinking /bin to /usr/bin and so on), but there are still several issues left over. And then you have 3rd party applications installed via standalone scripts doing what they want anyway. It’s a bit messy but if you follow some basic conventions and sane advice then it’s only slightly messy. Always try to find and prefer packages built for your distribution for installing new software, or distro-independent packages like Flatpaks. Only as a last resort you should run “installer scripts” which do random things without your package manager knowing about anything they install. Such installer scripts are the usual reason why things become messy or even break. And if you build software yourself, always try to create a package out of it for your distribution, and then install that package using your package manager, so that your package manager knows about it and you can easily remove or update it later.
This would’ve saved me so much pain if I knew this when starting Linux. Sooo much pain
Great detailed explanation, thank you.
I see very weird or even inaccurate descriptions here, so let me say it much simplier how it is most commonly used today:
Programs are expected to be unpacked/installed to proper locations. Like /usr/bin for binaries or /var/lib for their data. But not all programs, especially games and those ported from Windows, are made in recpect to this schema and expect everything in one directory.
So TLDR: For badly ported programs or quick installs that want every of program files in a single folder.
/home is deprecated?
That’s what I was wondering as well?
If so, what’s the “correct” location to store stuff like documents, downloads, configurations, etc.?
In the user’s home directory, which may or may not be in /home/username.
grep username /etc/passwdwill show you the home directory for a user. Also~usernamefrom the CLI will resolve to that user’s home directory. e.g.cp file.txt ~username/Documents/So i checked the fhs. Doesn’t say it is deprecated. V3 just mentions XDG and glib (the probable sources of such claims).
I was wondering about that too… According to the spec:
/home is a fairly standard concept, but it is clearly a site-specific filesystem. The setup will differ from host to host. Therefore, no program should assume any specific location for a home directory, rather it should query for it.
Sometimes home directories are in other locations. My University used to have different mount points for different graduating classes on our Unix servers. And I use “/home2” for one of my servers for… reasons.
Though I’m not sure that qualifies as “deprecated”? I get the “non-standard” bit though.
How about $HOME, is it standardized?
You also have to consider that roots homedir is in /root and not home, so if you’d just assume it’s /home/$USER you’d get in trouble when your programm is run or compiled as root.
My best guess is that having programs treat a user’s home directly as a location for things like config files is deprecated. Programs should be following the XDG standard instead.
You could contact the author (their email address is in the image), but I’m too lazy to do that.
The legend seems confusing to me. I think it’s trying to say that
/homeis non-standard. Notice that the description for/var/runexplicitly states it’s deprecated, and has a solid border.
Holy crap this is amazing!! Thank you
You’re welcome!
I like running mesa git for a few specific games but I have zero desire to install it for my system so I install it to /opt and invoke the right environment variable to use it from there instead
Add-on application software packages
How are applications that go into /opt different than any other packages? Even after reading that spec, it seems arbitrary.
If you didn’t get it through your distro’s package manager, it probably should go into
/opt.I think it refers to applications that do not respect the standard directories like
/usr/bin,/usr/share/man,/etcIt is very arbitrary. Some/most non-free applications usually drop stuff into /opt, so it does not spread all over the filesystem. It makes sense if the application was not developed with Linux in mind, like Discord, Teamviewer etc.
Woah, there’s even /etc/opt and /var/opt in the FHS.
I agree, " Add-on application software packages" is quite ambiguous.
General use, when you can install software through your system’s package manager then that’s the preferred way to get software on your system. For the most part, those applications live under /usr
If for some reason you prefer to install the package manually, best practice is to install it outside /usr to avoid potential conflicts with existing system libraries. The /opt (“optional”) system is a common place to install these apps. Many modern install scripts already default to using /opt
It’s also convenient for backing up those apps.
A trash hierarchy designed to replace /usr/local, which I think is not much used on Linux, and cause compatibility problem with BSDs.
