From mboxrd@z Thu Jan 1 00:00:00 1970 From: lyricalnanoha@usotsuki.hoshinet.org (Steve Nickolas) Date: Fri, 3 Feb 2012 17:09:08 +0100 (CET) Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <20120203162216.504c4bb7@cnb.csic.es> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> <0D449762-FD45-4528-B46E-AEA962E6B7CA@tfeb.org> <20120203162216.504c4bb7@cnb.csic.es> Message-ID: On Fri, 3 Feb 2012, Jose R. Valverde wrote: (snipping) > There was a reason to separate user data from system data to avoid > the system disk from becoming unusable by a misbehaving user. There was one > to separate /tmp for the same reason (a buggy program might generate a huge > temporary file and render the system unusable for all other users). Same for > /var and out of control log files. When vendors started adding their software > in /usr (and maintaining it) there ceased to be a standard, well known set > of "reserved system program names" and it made sense to separate /usr/local > for non-vendor maintained files which might have an unknown naming conflict > (and I witnessed many at the time, not the less GNU) with "non-standard-UNIX" > vendor additions. When LANs started to be common it made sense to share as > many files as possible, and since executables would not be shareable on an > heterogeneous network (something most newcomers have never experienced -or > fancied) it became sensible to have /home and /usr/share separate and served > over the network. When UNIX systems became more complex and started to take > over mainframes and get many users, it made sense to separate system programs > from user programs, and it didn't make sense to duplicate all of them: hence > a /bin for programs common to users and admins, and a /sbin for just admins > (for standard system commands) and a /usr/bin and /usr/sbin (for vendor > maintained commands and system daemons) and a /usr/local/bin and a > /usr/local/sbin (for locally added commands and system tools and daemons). > /lib, /lib64, /usr/lib and /usr/lib64? Heck! that's not even enough to > ensure user programs keep on running after a system upgrade and cleanup. > I often try to keep relevant packages in their own directory and run an > automated ldd to save in their own .../lib their shared libraries before > doing an upgrade. There are binaries that haven't been updated since the > '90s and require very old libraries (or even worst, complex sources that > require various versions of the GCC toolchain). It doesn't make sense to > port them, it's easier to ensure they keep on running keeping their libraries. > And so on. > > And many of these arguments might hold today. One might argue that > since people is now tied to a vendor (Ubuntu, or RedHat, or Oracle, or HP, > or whomever) one no longer needs separate / and /usr spaces. The problem > is that would only work for newbies and occasional users, but would fail > for most other cases (large computing servers and multiuser shops as well > as tiny embedded devices, as pointed out). So, as long as systems are shipped > to run on any machine, the layout should be versatile enough to accommodate > all uses. Hence the need for maintaining these conventions, not legacy or > bureaucracy. What is shortsighted is to expect all use-cases to be like a > home user who only runs one game or, at most, his/her word-processor, > e-mail and navigator simultaneously. > > Beyond that, the original articles and comments complained also about > directory naming (/bin /etc /lib) as "unintuitive". I fail to understand in > what way is it easier for someone new to a computer to learn a "/bin /etc /var > /lib" alien terminology and what it means, than to learn "System Config Libraries > etc..." or "Windows Windows32 Windows64 Temp Users and Settings, etc..." The > point is one needs to learn them and if you are familiar with one terminology > then to map terms, and if we are to use a standard, at least POSIX is one. > > That said, I often place everything (but /boot) in a single partition > for single-user machines (except for power users who usually demand at least > separate /tmp and /home) and there is nothing to prevent one from making symlinks > (er, aliases for Windowers) to system directories with whatever names you like. > And I still see a need to separate the system from vendor files and from user > files (like, e.g. when you later want to switch from say RedHat to Debian). Only > a moron would ignore the risk of system files left around by vendor-specific > naming conventions. > > I said originally I could rant on and on. And I can. And add lots of > anecdotes, but I'll leave it here. > > Sorry. Couldn't resist. > > j > > Actually, I tend to think the bare minimum to get the system running goes in /bin, /sbin and /lib, the rest of the base in /usr/bin, /usr/lib, /usr/include and /usr/sbin ... and all installed apps really ought to be in trees off /opt (although that would break stuff that expects X in /usr/X11R6/bin if I put it in /opt/X11 instead). But that's just my own opinion. -uso.