7 ms·

Wow, this model addresses a lot of the issues I have with different Linux distributions. Mainly, finding where the heck it installed that program in the maze of

by foxyv 6y ago

Wow, this model addresses a lot of the issues I have with different Linux distributions. Mainly, finding where the heck it installed that program in the maze of file/folder locations. Sometimes it's etc, opt, var/lib, bin, usr/bin, apps... Gwahhhhh! Then, you go to modify the configuration, and it turns out that the configuration file is being copied and generated from a different location. It's endless misdirection which changes in each distribution based on the package manager. I think I may try out Gobo the next chance I get. This is pretty cool.

freedomben 6y ago
FHS and distros that follow it aren't perfect, but it does make a big difference. I prefer Fedora-based and Arch-based flavors for that reason. It's usually pretty easy to find stuff. Backtrack used to do something like this and while it was easier compared to a lot of other debian/ubuntu based things, I still ran into some pain points. A great command to keep handy is ls -la `which <program>` That will usually find you the binary right away, and if it's a symlink or something you'll see it in the ls output. It's especially useful to me because (generally speaking) I put stuff I build myself in ~/bin rather than `/usr/local/bin` so I can quickly tell if I'm using my own build or the package manager's. Edit: FHS == Filesystem Hierarchy Standard - https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
- LMYahooTFY 6y ago
  Thank you, that's informative and you and GP have made me feel better about this particular aspect of learning Linux.
  - freedomben 6y ago
    My pleasure! It can feel brutal at first to learn Linux, especially with so much choice out there (aka fragmentation?), but honestly it's the best thing I ever did for myself both personal and career-wise. Can't recommend at least basic Linux proficiency enough if you are in a technology sector especially.
- forgotpwd16 6y ago
  Interestingly Arch address multiple bin directories mess by symlinking /bin, /sbin, and /usr/sbin to /usr/bin. Stali, an experimental distro (originally a suckless.org project), goes that a bit further by symlinking /sbin to /bin and /usr to /.
  - pkaye 6y ago
    Its the same in Ubuntu and Centos with symlinks of the bin directories.
    - stonesweep 6y ago
      Big picture, this is known as "the usr merge" which has been happening for probably a decade, each distro is approaching it at their own speed as they're not all exactly identical in their FHS layout (some distros add a bit of this and that on top). You can read about it at a meta level over here, each distro has it's own wiki/working page if you Google around: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
- voidfunc 6y ago
  The FHS really only makes sense when you use Linux as traditionally intended as a multi-user system. Most uses of Linux are single-user, running as a server, or even more just a container.
  - freedomben 6y ago
    I'm not sure I agree that most uses of Linux are single-user. I know this (likely) isn't what you meant, but at a minimum most every system, even containers, will have at least two users: root and the non-privileged user account. It may not be two humans but it is two users. On my current desktop (where I'm the only human user) I have 53 entries in /etc/passwd. Each have different permissions and access to resources. But even if you consider the above to be a single-user setup (which is reasonable) I still think there's value in consistency. I personally get a ton of value from having CentOS and RHEL systems being laid out the same as my Fedora Laptop and Desktop system, and having all that knowledge transfer both ways. Being able to add a user to a "single user" setup too is very useful. It would suck if adding a second user required completely changing everything about the filesystem.
  - sergeykish 6y ago
    FHS makes sense from a system developer standpoint — entire system is a project /lib for libraries /usr/include for C includes /etc for configs
- stonesweep 6y ago
  trivia: `which` is not the same which on all distros - on Ubuntu for example it's a super simple shell script named `which` which supports one single param (-a), not the compiled binary that you have on say Arch - and the features are different between them - I can't for example run `which --skip-tilde which` on Ubuntu, invalid usage. Many scripters who need wide compatibility of "which" fall back to the builtins `type` and `command` as they resolve any bash aliases set and give you a more truthful (sic) output than relying on `which` and bash is bash on all platforms: # command -v which /usr/bin/which # type which which is hashed (/usr/bin/which) $0.02 for your next adventure down the `which` rabbit hole. :)
  - akira2501 6y ago
    It can also be a shell builtin: akira@akira:~ which which which: shell built-in command
    - stonesweep 6y ago
      Very true, I missed that thanks - to illustrate how that could be important (to the scripter): kaneda@tetsuo:~ which type kaneda@tetsuo:~ type type type is a shell builtin kaneda@tetsuo:~ command -v type type This was on Ubuntu, the which script doesn't resolve type or command silently, while on say Arch it's verbose ("can't find type in (paths ... ...)" so even a failure-to-find emits differently for the `which` crowd.
  - turminal 6y ago
    > Many scripters who need wide compatibility of "which" fall back to the builtins `type` and `command` as they resolve any bash aliases set When wide compatibility is needed it is best to avoid bash specific solutions.
    - account42 6y ago
      `command -v` is standard POSIX sh [0] [0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...
- Fnoord 6y ago
  > I prefer Fedora-based and Arch-based flavors for that reason. It's usually pretty easy to find stuff. > Backtrack used to do something like this and while it was easier compared to a lot of other debian/ubuntu based things, I still ran into some pain points. FTA you linked: > Most Linux distributions follow the Filesystem Hierarchy Standard and declare it their own policy to maintain FHS compliance. GoboLinux and NixOS provide examples of intentionally non-compliant filesystem implementations. Debian and Ubuntu adhere to FHS; they're not more difficult in this regard than Arch or Fedora (or distributions based on these). GoboLinux and NixOS don't because they serve a higher goal. GoboLinux for user-friendliness/explorability and has backwards compatibility (which is hidden via optional kernel extension), NixOS aims to solve dependency hell (among various other goals). Learning curves are an obvious drawback. > ls -la `which <program>` Backticks should be avoided; use ls -la $(which <program>) instead (avoid the $ in Fish).
johnisgood 6y ago
I ran across it ages ago. I think you could use something like GNU Stow to achieve the same thing unless I am missing something. You install programs to ~/.local/pkg, then you link it to ~/.local/{bin,etc,include,lib,man,share,var}. Unless of course it is an Electron app. I use zpkg to handle this, it has been made specifically for this use case.
fiddlerwoaroof 6y ago
/bin and /usr/bin make less sense these days since the root partition is usually big enough to boot and to hold all the programs the system needs. But it’s important to have somewhere outside the package-manager’s control for manually installed binaries. Most installers default to directories like /opt/foo/bin and I tend to put user-built programs into /usr/local/bin.
- mindslight 6y ago
  /bin and /usr/bin would actually make plenty of sense these days - the new root partition is called initrd and gets hidden by pivot_root.
ploxiln 6y ago
GoboLinux install layout is a cool concept. However, it's not hard to figure out where files were installed, and what files are from. The package manager keeps track of all of that, and you can ask it. Example for debian or ubuntu: # list all files from package dpkq-query -L <package> dpkg-query -L <package> | grep bin/ # see just commands # find what package a file is from dpkg-query -S /path/to/some/thing I use equivalent commands in Archlinux (pacman ...) and they certainly exist for redhat/fedora but I'm not familiar with those. For stuff not installed as packages, hopefully it's either in a single directory in /opt, or among a small collection of stuff spread in /usr/local, or in a self-contained directory in your home folder.
- colechristensen 6y ago
  RPM-based distros (redhat, etc.) # List all files from q package rpm -ql <package> # Where did file come from rpm -qf <path>
  - antx 6y ago
    And just because I have to be THAT guy, with Arch linux you use pacman -Ql and pacman -Qo to do the same. Also, man! Do I love the Arch wiki: https://wiki.archlinux.org/index.php/Pacman/Rosetta https://wiki.archlinux.org/index.php/Pacman/Rosetta
    - Teknoman117 6y ago
      I'll be THAT guy as well! On Gentoo, "equery f <package>" displays a list of files installed by that package, "equery b <path>" says which package owns that file or directory, if any. (f and b are the short versions of "files" and "belongs", respectively)
      - account42 6y ago
        I prefer `qlist` and `qfile` from app-portage/portage-utils [0] as the q versions tend to be faster. [0] https://wiki.gentoo.org/wiki/Q_applets https://wiki.gentoo.org/wiki/Q_applets
Blikkentrekker 6y ago
In almost any system, finding out where what files belong to a package is a trivial operation for the package manager to list. The idea that a package is “installed somewhere” rather than “installed” and has files that “belong to it” seems to be a Windows-ism in mentality, where it is common to start applications by navigating to the folder they are installed in, and starting an execution there from an absolute path. Many packages' files consist of nothing more than adding more fonts to the system, it seems a bad idea to me, to have all that in a per-package folder, rather than simply in `/usr/share/fonts`, and have the package manager track what file therein belongs to what package.
- noisem4ker 6y ago
  This runs somewhat counter to my practical experience. On Windows, most programs come with an installer and end up launchable with a shortcut from the start menu. On Linux, on the other hand, unless you're pulling from the package manager, then you've probably got a .tar.gz archive to manually extract somewhere. I see things have been changing only recently with the advent of Snap/Flatpak/AppImage.
  - Blikkentrekker 6y ago
    I find that most Unix software installs via a `make install` directive, which keeps track of what files are installed where, and are then uninstalled with a `make uninstall`, if one not rely on a package manager that installs does the same internally.
nextos 6y ago
Sadly Gobo has few users, so it doesn't enjoy as much support as other mainstream distributions. You may want to consider NixOS, which is equivalent to Gobo except for the fact that linking across packages is static instead of dynamic. This has very deep consequences. Nix has tons of developers, it's one of the most active projects on Github. Past the initial difficulties, most common usecases are really easy.
- riffic 6y ago
  > Sadly Gobo has few users Honestly, there's nothing sad about this.
Jasper_ 6y ago
The typical convention these days is: - /usr/ is read-only data. /usr/bin/ contains OS-supplied binaries, /usr/lib/ contains OS-supplied libraries. - /var/ is read-write state data and will persist between boots. /var/log/ is for log files. - /run/ is read-write scratch on a tmpfs, and will be cleaned up between boots. So, UNIX sockets and other temporary files go here. - /etc/ is per-system configuration overrides. There is a goal to move to "empty /etc/", meaning you should be able to remove all files in /etc/ and still have a functioning system. - /opt/ is "vendor space". The OS should never touch /opt/. The names are weird, but that's the intention behind the new scheme. If you want to change configuration, the default config might be shipped read-only in /usr/, but it should be overridable in /etc/. This is why systemd ships read-only unit files in /usr/, which are symlinked into /etc/ to be "enabled".
- asveikau 6y ago
  /usr/local/etc is a common pattern, though. So maybe I would add that /usr/local is a special case of /usr for locally built* stuff, with sub-nodes imitating the corresponding nodes in /. * Not always locally built, though. *BSDs put binary packages there too.
- Blikkentrekker 6y ago
  > /etc/ is per-system configuration overrides. There is a goal to move to "empty /etc/", meaning you should be able to remove all files in /etc/ and still have a functioning system. I find this goal to be rather frustrating. It means that software will hardcode it's default configuration when it cannot find a file in `/etc`, and it makes it very hard to deduce what exactly can be configured. I strongly dislike software that will simply apply a default state when it cannot encounter a certain configuration in it's configuration file for this reason. I favor that software simply refuse to start with a clear warning as to why, when it cannot find a configuration option in it's configuration file. Applying a default on a missing key is another case of weak typing; I would hope that lessons were learned by now that guessing what the user wants in case of error is a bad idea. What is even worse is software that simply ignores malformed keys, and applies a default value anyway, giving rise to not only innocent mistakes by typoes, but some malicious exploits that were found by putting zero-width spaces into keys to trick administrators viā social engineering.
turminal 6y ago
`man hier` is usually a helpful reference for things like this.
birksherty 6y ago
Exactly. It's always annoying to use, sometimes I just give up. This is why I never feel comfortable using Linux.
hansvm 6y ago
As another solution in that space, equery and other tools are excellent when administering a Gentoo box. https://wiki.gentoo.org/wiki/Equery#Listing_files_installed_by_a_package_with_files_.28f.29 https://wiki.gentoo.org/wiki/Equery#Listing_files_installed_...
nix23 6y ago
> Mainly, finding where the heck it installed that program in the maze of file/folder locations whereis ?

by foxyv 6y ago

freedomben 6y ago

FHS and distros that follow it aren't perfect, but it does make a big difference. I prefer Fedora-based and Arch-based flavors for that reason. It's usually pretty easy to find stuff. Backtrack used to do something like this and while it was easier compared to a lot of other debian/ubuntu based things, I still ran into some pain points. A great command to keep handy is ls -la `which <program>` That will usually find you the binary right away, and if it's a symlink or something you'll see it in the ls output. It's especially useful to me because (generally speaking) I put stuff I build myself in ~/bin rather than `/usr/local/bin` so I can quickly tell if I'm using my own build or the package manager's. Edit: FHS == Filesystem Hierarchy Standard - https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

LMYahooTFY 6y ago
Thank you, that's informative and you and GP have made me feel better about this particular aspect of learning Linux.
- freedomben 6y ago
  My pleasure! It can feel brutal at first to learn Linux, especially with so much choice out there (aka fragmentation?), but honestly it's the best thing I ever did for myself both personal and career-wise. Can't recommend at least basic Linux proficiency enough if you are in a technology sector especially.
forgotpwd16 6y ago
Interestingly Arch address multiple bin directories mess by symlinking /bin, /sbin, and /usr/sbin to /usr/bin. Stali, an experimental distro (originally a suckless.org project), goes that a bit further by symlinking /sbin to /bin and /usr to /.
- pkaye 6y ago
  Its the same in Ubuntu and Centos with symlinks of the bin directories.
  - stonesweep 6y ago
    Big picture, this is known as "the usr merge" which has been happening for probably a decade, each distro is approaching it at their own speed as they're not all exactly identical in their FHS layout (some distros add a bit of this and that on top). You can read about it at a meta level over here, each distro has it's own wiki/working page if you Google around: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
voidfunc 6y ago
The FHS really only makes sense when you use Linux as traditionally intended as a multi-user system. Most uses of Linux are single-user, running as a server, or even more just a container.
- freedomben 6y ago
  I'm not sure I agree that most uses of Linux are single-user. I know this (likely) isn't what you meant, but at a minimum most every system, even containers, will have at least two users: root and the non-privileged user account. It may not be two humans but it is two users. On my current desktop (where I'm the only human user) I have 53 entries in /etc/passwd. Each have different permissions and access to resources. But even if you consider the above to be a single-user setup (which is reasonable) I still think there's value in consistency. I personally get a ton of value from having CentOS and RHEL systems being laid out the same as my Fedora Laptop and Desktop system, and having all that knowledge transfer both ways. Being able to add a user to a "single user" setup too is very useful. It would suck if adding a second user required completely changing everything about the filesystem.
- sergeykish 6y ago
  FHS makes sense from a system developer standpoint — entire system is a project /lib for libraries /usr/include for C includes /etc for configs
stonesweep 6y ago
trivia: `which` is not the same which on all distros - on Ubuntu for example it's a super simple shell script named `which` which supports one single param (-a), not the compiled binary that you have on say Arch - and the features are different between them - I can't for example run `which --skip-tilde which` on Ubuntu, invalid usage. Many scripters who need wide compatibility of "which" fall back to the builtins `type` and `command` as they resolve any bash aliases set and give you a more truthful (sic) output than relying on `which` and bash is bash on all platforms: # command -v which /usr/bin/which # type which which is hashed (/usr/bin/which) $0.02 for your next adventure down the `which` rabbit hole. :)
- akira2501 6y ago
  It can also be a shell builtin: akira@akira:~ which which which: shell built-in command
  - stonesweep 6y ago
    Very true, I missed that thanks - to illustrate how that could be important (to the scripter): kaneda@tetsuo:~ which type kaneda@tetsuo:~ type type type is a shell builtin kaneda@tetsuo:~ command -v type type This was on Ubuntu, the which script doesn't resolve type or command silently, while on say Arch it's verbose ("can't find type in (paths ... ...)" so even a failure-to-find emits differently for the `which` crowd.
- turminal 6y ago
  > Many scripters who need wide compatibility of "which" fall back to the builtins `type` and `command` as they resolve any bash aliases set When wide compatibility is needed it is best to avoid bash specific solutions.
  - account42 6y ago
    `command -v` is standard POSIX sh [0] [0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...
Fnoord 6y ago
> I prefer Fedora-based and Arch-based flavors for that reason. It's usually pretty easy to find stuff. > Backtrack used to do something like this and while it was easier compared to a lot of other debian/ubuntu based things, I still ran into some pain points. FTA you linked: > Most Linux distributions follow the Filesystem Hierarchy Standard and declare it their own policy to maintain FHS compliance. GoboLinux and NixOS provide examples of intentionally non-compliant filesystem implementations. Debian and Ubuntu adhere to FHS; they're not more difficult in this regard than Arch or Fedora (or distributions based on these). GoboLinux and NixOS don't because they serve a higher goal. GoboLinux for user-friendliness/explorability and has backwards compatibility (which is hidden via optional kernel extension), NixOS aims to solve dependency hell (among various other goals). Learning curves are an obvious drawback. > ls -la `which <program>` Backticks should be avoided; use ls -la $(which <program>) instead (avoid the $ in Fish).

johnisgood 6y ago

I ran across it ages ago. I think you could use something like GNU Stow to achieve the same thing unless I am missing something. You install programs to ~/.local/pkg, then you link it to ~/.local/{bin,etc,include,lib,man,share,var}. Unless of course it is an Electron app. I use zpkg to handle this, it has been made specifically for this use case.

fiddlerwoaroof 6y ago

/bin and /usr/bin make less sense these days since the root partition is usually big enough to boot and to hold all the programs the system needs. But it’s important to have somewhere outside the package-manager’s control for manually installed binaries. Most installers default to directories like /opt/foo/bin and I tend to put user-built programs into /usr/local/bin.

mindslight 6y ago
/bin and /usr/bin would actually make plenty of sense these days - the new root partition is called initrd and gets hidden by pivot_root.

ploxiln 6y ago

GoboLinux install layout is a cool concept. However, it's not hard to figure out where files were installed, and what files are from. The package manager keeps track of all of that, and you can ask it. Example for debian or ubuntu: # list all files from package dpkq-query -L <package> dpkg-query -L <package> | grep bin/ # see just commands # find what package a file is from dpkg-query -S /path/to/some/thing I use equivalent commands in Archlinux (pacman ...) and they certainly exist for redhat/fedora but I'm not familiar with those. For stuff not installed as packages, hopefully it's either in a single directory in /opt, or among a small collection of stuff spread in /usr/local, or in a self-contained directory in your home folder.

colechristensen 6y ago
RPM-based distros (redhat, etc.) # List all files from q package rpm -ql <package> # Where did file come from rpm -qf <path>
- antx 6y ago
  And just because I have to be THAT guy, with Arch linux you use pacman -Ql and pacman -Qo to do the same. Also, man! Do I love the Arch wiki: https://wiki.archlinux.org/index.php/Pacman/Rosetta https://wiki.archlinux.org/index.php/Pacman/Rosetta
  - Teknoman117 6y ago
    I'll be THAT guy as well! On Gentoo, "equery f <package>" displays a list of files installed by that package, "equery b <path>" says which package owns that file or directory, if any. (f and b are the short versions of "files" and "belongs", respectively)
    - account42 6y ago
      I prefer `qlist` and `qfile` from app-portage/portage-utils [0] as the q versions tend to be faster. [0] https://wiki.gentoo.org/wiki/Q_applets https://wiki.gentoo.org/wiki/Q_applets

Blikkentrekker 6y ago

In almost any system, finding out where what files belong to a package is a trivial operation for the package manager to list. The idea that a package is “installed somewhere” rather than “installed” and has files that “belong to it” seems to be a Windows-ism in mentality, where it is common to start applications by navigating to the folder they are installed in, and starting an execution there from an absolute path. Many packages' files consist of nothing more than adding more fonts to the system, it seems a bad idea to me, to have all that in a per-package folder, rather than simply in `/usr/share/fonts`, and have the package manager track what file therein belongs to what package.

noisem4ker 6y ago
This runs somewhat counter to my practical experience. On Windows, most programs come with an installer and end up launchable with a shortcut from the start menu. On Linux, on the other hand, unless you're pulling from the package manager, then you've probably got a .tar.gz archive to manually extract somewhere. I see things have been changing only recently with the advent of Snap/Flatpak/AppImage.
- Blikkentrekker 6y ago
  I find that most Unix software installs via a `make install` directive, which keeps track of what files are installed where, and are then uninstalled with a `make uninstall`, if one not rely on a package manager that installs does the same internally.

nextos 6y ago

Sadly Gobo has few users, so it doesn't enjoy as much support as other mainstream distributions. You may want to consider NixOS, which is equivalent to Gobo except for the fact that linking across packages is static instead of dynamic. This has very deep consequences. Nix has tons of developers, it's one of the most active projects on Github. Past the initial difficulties, most common usecases are really easy.

riffic 6y ago
> Sadly Gobo has few users Honestly, there's nothing sad about this.

Jasper_ 6y ago

The typical convention these days is: - /usr/ is read-only data. /usr/bin/ contains OS-supplied binaries, /usr/lib/ contains OS-supplied libraries. - /var/ is read-write state data and will persist between boots. /var/log/ is for log files. - /run/ is read-write scratch on a tmpfs, and will be cleaned up between boots. So, UNIX sockets and other temporary files go here. - /etc/ is per-system configuration overrides. There is a goal to move to "empty /etc/", meaning you should be able to remove all files in /etc/ and still have a functioning system. - /opt/ is "vendor space". The OS should never touch /opt/. The names are weird, but that's the intention behind the new scheme. If you want to change configuration, the default config might be shipped read-only in /usr/, but it should be overridable in /etc/. This is why systemd ships read-only unit files in /usr/, which are symlinked into /etc/ to be "enabled".

asveikau 6y ago
/usr/local/etc is a common pattern, though. So maybe I would add that /usr/local is a special case of /usr for locally built* stuff, with sub-nodes imitating the corresponding nodes in /. * Not always locally built, though. *BSDs put binary packages there too.
Blikkentrekker 6y ago
> /etc/ is per-system configuration overrides. There is a goal to move to "empty /etc/", meaning you should be able to remove all files in /etc/ and still have a functioning system. I find this goal to be rather frustrating. It means that software will hardcode it's default configuration when it cannot find a file in `/etc`, and it makes it very hard to deduce what exactly can be configured. I strongly dislike software that will simply apply a default state when it cannot encounter a certain configuration in it's configuration file for this reason. I favor that software simply refuse to start with a clear warning as to why, when it cannot find a configuration option in it's configuration file. Applying a default on a missing key is another case of weak typing; I would hope that lessons were learned by now that guessing what the user wants in case of error is a bad idea. What is even worse is software that simply ignores malformed keys, and applies a default value anyway, giving rise to not only innocent mistakes by typoes, but some malicious exploits that were found by putting zero-width spaces into keys to trick administrators viā social engineering.

turminal 6y ago

`man hier` is usually a helpful reference for things like this.

birksherty 6y ago

Exactly. It's always annoying to use, sometimes I just give up. This is why I never feel comfortable using Linux.

hansvm 6y ago

As another solution in that space, equery and other tools are excellent when administering a Gentoo box. https://wiki.gentoo.org/wiki/Equery#Listing_files_installed_by_a_package_with_files_.28f.29 https://wiki.gentoo.org/wiki/Equery#Listing_files_installed_...

nix23 6y ago

> Mainly, finding where the heck it installed that program in the maze of file/folder locations whereis ?