Understanding the bin, sbin, usr/bin, usr/sbin split (2010)

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Scout APM - Less time debugging, more time building
  • SonarLint - Clean code begins in your IDE with SonarLint
  • SaaSHub - Software Alternatives and Reviews
  • Cargo

    The Rust package manager

    There is no specific reason for a program that uses the XDG dirs on other unices to not use them on macOS, other than some idea that it's "alien".

    You can have ~/.config/. Nothing in macOS prevents you from having it. And so, some programs do. The worst thing that happens is that, instead of having one directoy ~/.foo you now have one directory ~/.config/foo and nothing else in ~/.config. But as soon as you add the second thing that uses ~/.config, you now have two directories in there instead of a second dotdirectory in ~.

    It's just that for a bunch of them the XDG path is only used if it exists - e.g. emacs predates the spec, so it uses ~/.emacs.d (and a few others) first.

    Cargo doesn't use the XDG paths at all, apparently - https://github.com/rust-lang/cargo/issues/1734. However it also needs a directory for binaries (~/.cargo/bin) and ~/.local/bin isn't actually in the spec at the moment (https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/14).

  • kubernetes

    Production-Grade Container Scheduling and Management

    I can understand devs not using the right circumstances if their platform of choice doesn't come with an easy way to determine the right directory to put stuff in, let alone create it if necessary.

    What I really want is an API that does "create/open/delete a file/directory for the relevant configuration/cache/resources store", be it user configured or platform default. What I get is an external package that gives me a list of potential storage locations (of which I'll probably just pick the first) that may or may not be actual directories on the system which I may or may not have access to touch files in.

    Some devs are kindly reminded that there's a spec for these things but often it's too late as data is already in specific paths that users may have come to know. That way you end up with paths that get set by environment variables where you have to tell each and every program where to put their crap.

    Other programs don't care enough to implement the standards (like Firefox; the bug report about XDG is old enough to vote [1] and it's still not implemented fully). Kubernetes has an open issue for its client that only ever gets bumped.

    Even worse are devs that are reminded of standards like XDG and then decide to give everyone the middle finger. Snap is one of them, not only is the data directory hard-coded, it's hard-coded lowercase unlike every other standard directory on Canonical's distribution itself! Snap's biggest competitor, Flatpak, decided not following the standard is not a problem [3]. At least it's special snowflake folder starts with a period so that it's hidden by default, I suppose. Even Bash doesn't support XDG [4] because not everyone uses Linux (and apparently no effort should be made to support OS specific standards?) with the suggestion closed as won't fix.

    Many tools that do support XDG only care about their own standards, of course; Windows has had SHGetKnowlFolderPath since Vista, replacing SHGetFolderLocation which dates back to Windows 2000. Still, developers like to push POSIX standards into Windows, creating .dotfiles and not even bothering to at least mark them as hidden.

    There's a big list on the Arch wiki[7] listing programs and their compatibilities with XDG.

    [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=259356

    [2]: https://github.com/kubernetes/kubernetes/issues/56402

    [3]: https://github.com/flatpak/flatpak/issues/1651

    [4]: https://savannah.gnu.org/support/?108134

    [5]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co...

    [6]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co...

    [7]: https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcode...

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • flatpak

    Linux application sandboxing and distribution framework

    I can understand devs not using the right circumstances if their platform of choice doesn't come with an easy way to determine the right directory to put stuff in, let alone create it if necessary.

    What I really want is an API that does "create/open/delete a file/directory for the relevant configuration/cache/resources store", be it user configured or platform default. What I get is an external package that gives me a list of potential storage locations (of which I'll probably just pick the first) that may or may not be actual directories on the system which I may or may not have access to touch files in.

    Some devs are kindly reminded that there's a spec for these things but often it's too late as data is already in specific paths that users may have come to know. That way you end up with paths that get set by environment variables where you have to tell each and every program where to put their crap.

    Other programs don't care enough to implement the standards (like Firefox; the bug report about XDG is old enough to vote [1] and it's still not implemented fully). Kubernetes has an open issue for its client that only ever gets bumped.

    Even worse are devs that are reminded of standards like XDG and then decide to give everyone the middle finger. Snap is one of them, not only is the data directory hard-coded, it's hard-coded lowercase unlike every other standard directory on Canonical's distribution itself! Snap's biggest competitor, Flatpak, decided not following the standard is not a problem [3]. At least it's special snowflake folder starts with a period so that it's hidden by default, I suppose. Even Bash doesn't support XDG [4] because not everyone uses Linux (and apparently no effort should be made to support OS specific standards?) with the suggestion closed as won't fix.

    Many tools that do support XDG only care about their own standards, of course; Windows has had SHGetKnowlFolderPath since Vista, replacing SHGetFolderLocation which dates back to Windows 2000. Still, developers like to push POSIX standards into Windows, creating .dotfiles and not even bothering to at least mark them as hidden.

    There's a big list on the Arch wiki[7] listing programs and their compatibilities with XDG.

    [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=259356

    [2]: https://github.com/kubernetes/kubernetes/issues/56402

    [3]: https://github.com/flatpak/flatpak/issues/1651

    [4]: https://savannah.gnu.org/support/?108134

    [5]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co...

    [6]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co...

    [7]: https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcode...

  • BSDGames

    Text based games from Debian - bsdgames package.

    I'll also note /usr/games/dm ( https://github.com/vattam/BSDGames/tree/master/dm ) which allowed sysadmins to restrict when programs in /usr/games could be run. Setting up that structure in /usr/bin would be more work to maintain.

  • toybox

    toybox

    For those who liked this text and want to read more from the author, have a look at his busybox replacement toybox:

    http://landley.net/toybox/

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts