nixCraft š§Origin of unix /bin, /sbin, and /usr/bin , /usr/sbin split
https://lists.busybox.net/pipermail/busybox/2010-December/074114.html
tanavit
Resuna
sch00b
ARGVMI~1.PIF#NeXT / #Apple had the right idea.
* User homes are in /Users
* Each app is in /Applications and looks like a regular file but is actually a folder (i.e. you can cd into it and examine the contents)
* The operating system is in /System
* Files shared among apps (except files that come with the OS), including configuration files, are in /Library
* Static libraries, debug info, C headers, OS API reference docs, etc go in /Developer
GoboLinux does something similar on Linux, but it doesn't seem to have gotten much traction.
GnosticStreetSweeper@argv_minus_one @nixCraft what about file representation of physical devices and processes a lĆ” /proc /sys and /dev?
David Chisnall (*Now with 50% more sarcasm!*)@argv_minus_one @GnosticStreetSweeper @nixCraft
They also have /proc, but not /sys. Linuxās sysfs serves largely the same purpose as sysctl on BSDs, but sysctl has a few benefits:
- Itās structured and the types are introspectable (nodes also expose human-readable descriptions). The command-line tool that exposes them for scripting can provide the structure to scripts.
- Reading or writing one is a single system call, not an open, read/write, close sequence.
- They donāt look like files, so donāt fail in weird ways (e.g. requiring reads of specific sizes).
- They donāt consume a file descriptor.
Their one disadvantage is that they donāt automatically benefit from file-namespace sandboxing tools. On FreeBSD, for example, thereās an allow list for sysctls that can be used in Capsicum capability mode but thereās no way of adding a sysctl to that list.
Norman Wilson@david_chisnall @argv_minus_one @GnosticStreetSweeper @nixCraft /sys does stuff similar to BSD sysctl, but in a much finer-grained way.
Interestingly, Linux sysctl maps directly onto /proc/sys: sysctl kernel.broken.stuff == /proc/sys/kernel/broken/stuff. The sysctl command is still a cleaner higher-level interface.
Nazo@nixCraft I'm starting to really understand lately how much there really is a bureaucracy in Linux of all things lately, especially with stuff like how everyone just accepted integrating systemd deep in their systems solely because the bureaucracy did (and it really kind of decided against the votes saying to at least review it more before actually doing it.)
There are so many examples of this sort of thing really. It truly would help if a lot of these people would take a better look back at the origins and reasons of these things and actually be willing to question if they should continue things that ultimately aren't helping at all (or even worsening everything.)
@nazokiyoubinbou @nixCraft Large groups of people act like that, unfortunately. Consensus becomes impossible.
The Computing Science Research Center at Bell Labs, whence came Unix, was relatively small. I was there in the late 1980s and it was only about 60 people, not all interested in system design and organization. Consensus was easier and worked well. Granted that by the late 1980s that group's influence over Unix had waned considerably.
Douglas Floyd@nixCraft /usr/usb and /usr/X11 or /usr/bin/X11 are good historical stories as well. /usr/ucb should never exist on any Linux distro, regardless of time, unless it is a symlink for old school compatibility purposes.
JdeBPYou haven't gone down the rabbit hole far enough if you haven't yet reached /usr/amdahl/ . (-:
http://jdebp.info/FGA/unix-path-and-personalities.html
It is amusing that you state that /usr/ucb should never exist, given that Arch Linux has had to invent in place of it /opt/bsdutils in order to accommodate David Cantrell's import of actual BSD tools (from FreeBSD) that conflict with the GNU coreutils tools placed in /usr/bin , /opt/BSDuserland for @diegomagdaleno's fork of Cantrell's work, and /usr/lib/vlang-coreutils for yet another conflicting set of tools.
Cantrell's own spec file for RPM actually specifies /usr/ucb as the install directory.
I submit that /usr/ucb is alive and well in Linux distributions, just hiding under several pseudonyms, or actually out in the open in the case of RedHat. (-:
https://aur.archlinux.org/packages/bsdutils
https://aur.archlinux.org/packages/bsdcoreutils-git
https://aur.archlinux.org/packages/vlang-coreutils-git
https://archlinux.org/packages/core/x86_64/coreutils/
https://codeberg.org/dcantrell/bsdutils/src/branch/main/bsdutils.spec.in
Vassil Nikolov | ŠŠ°ŃŠøŠ» ŠŠøŠŗŠ¾Š»Š¾Š²Once upon a time a man page said:
Ā«to keep /bin smallĀ»
(I forget which page...).
@nixCraft Basically correct but mistaken in one or two minor details.
The origin of /usr/bin and /usr/lib is as described, but original ken/dmr Unix had no sbin. sbin these days is taken to mean programs meant only for sysadmins; in the early such programs were in /etc or just /bin.
As I vaguely remember--and I may be mistaken myself here--the s in /sbin originally meant statically-linked, programs like mount that were need to make /usr and hence shared libraries available. (What about /bin/sh? I don't remember.) In that meaning there was no /usr/sbin; it made no sense.
As an old-timer who is always looking to make things smaller and simpler, were it up to me (and it surely is not), I'd abolish /usr except as a place for users' home directories. And I'd abolish /etc as well: executables have a good home now in /sbin, config/data files should move to /lib, which was originally a general library of files need by programs in /bin, not just subroutine libraries.