51–60 of 65 posts
/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin I never know where to put my own binaries so I just add my own at ~/bin. Some programs also add their own like ~/.cargo/bin what a mess
I think the current standard for your own binaries is ~/.local/bin instead of ~/bin https://specifications.freedesktop.org/basedir-spec/basedir-...
I still think it’s funny how what used to be the location of user home directories, namely /usr, has been retconned to be where the majority of binaries are stored.
The story went something like, the guys building UNIX got a second hard drive, so they moved the home directories (/usr) to it. As the system grew, they started dropping more binaries into /usr/bin (while trying to keep /bin for things needed to boot/rescue the system, in case the disk with /usr failed). The rest is history.
http://lists.busybox.net/pipermail/busybox/2010-December/074...
Earlier quoted context omitted.
Right, without back-compat, any system trying to gain marketshare is domed. ...but Linux has chroot, symlinks, hardlinks, and everything in-between - it's entirely possible to design a Linux environment where the clutter and warts of back-compat are only visible to the users and programs that need to see them.
GoboLinux attempts to reinvent the filesystem organisation for Linux while maintaining full compatibility.
Earlier quoted context omitted.
About 2009 or 2010 I recall nearly every major distro saying they were going to ignore it, yes. It primarily existed so that Linux could mimic System V and/or POSIX, and that stopped being relevant as soon as software written for Unix migrated into software written for Linux.
It primarily existed to standardise paths between different Linux distributions. This, along with the LSB, was intended to make it possible to ship software that would work on all distributions.
Earlier quoted context omitted.
/usr/local is for all users of the multi-user server you're on, which you have installed locally. ~/... is for your personal user account /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice) and /opt is for third party packages from third party providers we tend to forget the "Unix" precursor of Linux comes from the data centre server world. so "a mess" is relative
> /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice) Don't most/popular distros symlink many of those together?
(Not sure if popularity matters.)
Earlier quoted context omitted.
/usr/local is for all users of the multi-user server you're on, which you have installed locally. ~/... is for your personal user account /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice) and /opt is for third party packages from third party providers we tend to forget the "Unix" precursor of Linux comes from the data centre server world. so "a mess" is relative
> /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice) Don't most/popular distros symlink many of those together?
"back in the days" before there was an initrd you needed a small disk. that was /bin and /sbin. into that disk some /etc/rc.d/ file would mount a separate /use partition (and /home and /opt), often from network.
however with pivot_root and initrd we don't need that dance any more and do another one...
likewise the distinction between sbin and bin is gone.
that's why they today just symlink together.
Earlier quoted context omitted.
evolution. /mnt came first. and distros started mounting stuff into it. but actually it was never meant to be used for that. it was supposed to be an always empty directory where a sysadmin could mount something temporarily if they needed it. so distros moved away from /mnt and started using /media then /run was invented as a place for all that semi-automatic temporary stuff that needs a place while the system is run…
/mnt historically was used as a single mount point. This became problematic when it became common to have multiple temporary mounts, for example a CD-ROM and a USB stick. /media solved that by stating mountpoints are folders inside it, eg /media/cdrom.
personally i wish /media would have stuck. i find the current paths /run/media/username/device rather unpractical. whenever i connect a data device i have to go searching for the mountpoint.
Earlier quoted context omitted.
The story went something like, the guys building UNIX got a second hard drive, so they moved the home directories (/usr) to it. As the system grew, they started dropping more binaries into /usr/bin (while trying to keep /bin for things needed to boot/rescue the system, in case the disk with /usr failed). The rest is history.
Here is more detail: http://lists.busybox.net/pipermail/busybox/2010-December/074...
This is how I set my $PATH, note this code is portable between several Linux distros (including NixOS), macOS, OpenBSD, FreeBSD, and amd64/arm64...
https://github.com/rollcat/dotfiles/blob/52a634f/.profile#L1...>
Whenever I touch it, I just wish I could put PATH=/bin in there instead, but then I'd be stuck juggling 17 different ways to make bind mounts.
The fundamental errors of this are: * It is hierarchical. * It sorts by file type, not by namespace.
Earlier quoted context omitted.
/mnt historically was used as a single mount point. This became problematic when it became common to have multiple temporary mounts, for example a CD-ROM and a USB stick. /media solved that by stating mountpoints are folders inside it, eg /media/cdrom.
right. what early distributions were doing was creating subdirectories within /mnt, but that got in the way when users wanted to mount something manually. at least it did bother me. personally i wish /media would have stuck. i find the current paths /run/media/username/device rather unpractical. whenever i connect a data device i have to go searching for the mountpoint.