On Tue, 31 Jan 2012 13:16:17 -0600 "A. P. Garcia" <a.phillip.garcia(a)gmail.com> wrote: I think this is typical misunderstanding of modern-day newcomers. The main problem to me seems to be that they think of UNIX (and Linux) as a Windows PC, which it isn't (and they even do not understand the Windows PC itself). The fact that at some point people was strained by disk space (and it has nothing to do with Ken or Dennis or disk availability) only means they had a pressure to split contents, and unless anyone was a moron, everyone would do it in a similar rational way. A rational way in the times meant adapting for the times' needs, and by then UNIX was a multi-user OS. So, beyond the point of filling up a disk (and that's the point for the partition system) there was a need to ensure you could separate user data from system data: adding user programs or data to a separate space (disk, partition, whatever) ensured the system space was not filled and the system would not become unusable. That was the real reason for /, /usr, /tmp and /var as standard partitions for most of us, not the availability of new disks. And the same is valid for separating system-specific binaries from general users. When disks came it would be handy to move a partition to a separate disk, but the need itself has nothing to do with the availability of extra disks. This is something obvious to anyone maintaining a multi-user server, only presumptuous single-user windows toyers think they know better. Even now when I get a user asking to set up a new computing server, their first query is how to separate system from users and scratch space. Any power user has filled his own system once and knows the risk. They also know they can cope with their own system and files. And they all know they cannot in a shared environment where they cannot control other users' files. Point is, the very first idea that occurs to any sensible being when facing a multiuser system is how to separate contents safely. That Ken and Denis did the obvious thing (as many of us did at the time --I remember having a /usr/local on my machines years before it was commonplace use) only speaks of their common sense (and the ignorance or lack of common sense in complainers). This is still valid in the times of petabyte disk arrays, ACLs, quotas, queuing systems and all what nots. Even more so in these large installations (I have witnessed multi-TB scratch files in jobs, filling a supercomputing installation and requiring operator intervention to avoid stopping the work of all other users). And so on, I could rant all day arguing why this was the obvious approach to many problems then, and often now too. So, to me, this looks more like a case of "reintrepreting and twisting the facts to justify untenable beliefs" instead of trying to understand what actually happened and why. Like saying the wheel was invented only to make carriages and that we keep using carriages (instead of say helicopters) just because of tradition and "bureaucrats" instead of accepting that there were many needs and when the wheel came it was -and still is- the obvious solution to most of those problems (among them carrying loads in carriages). j -- EMBnet/CNB Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es http://www.es.embnet.org

On 2/1/2012 6:12 AM, Jose R. Valverde wrote: The thing is, /usr isn't "user data". That's /home. /usr is just "more system space". And this article never actually explains sbin. Or /usr/share, which is interesting because as I understand it it's designed to be shareable between multiple computers of possibly different architectures

On Feb 2, 2012, at 6:32 AM, Random832 wrote: /usr was user data, back in the day. /home came about much later. sbin was created in SYS Vr4 to move all the binaries that were in /etc. /usr/share was created to move all the non-binary, non-text files that were in /etc like termcap and timezone info. Warner

On Feb 2, 2012, at 10:24 AM, Warner Losh wrote: That should read 'all non-binary executables and non-config files' Warner

On Feb 2, 2012, at 10:36 AM, John Cowan wrote: I'd been told a long time ago that is stands for 'system' for people that need to administer the system, not necessarily super users. The FreeBSD hier man page seems to bear this out: /sbin/ system programs and administration utilities fundamental to both single-user and multi-user environments That's true, but /usr/dict was a bit of an odd-ball at the top /usr level. /usr/share contained all the stuff from /etc and also other things that didn't seem to belong. That's why it is documented as having the architecture independent files in it... Warner

On Feb 2, 2012, at 2:14 PM, Dave Horsfall wrote: /bin is also statically linked, at least on those distributions that support split / and /usr. SunOS 4.x and 4.4BSD did this. Except for the ones that have gone to a dynamic root moving the shared libraries from /usr/lib to /lib. Prior to the /etc -> /sbin moves, all binaries were statically linked. Even after the move /bin and /sbin remained static, while /usr/bin and /usr/sbin were dynamic. The needs of reliability vs space savings pushed all the binaries in /sbin and /bin to be static. Even after the split in more modern systems, init and sh tend to be the only binaries that are statically linked anymore. Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used). Warner

On Feb 2, 2012, at 3:29 PM, Tim Newsham wrote: No. I'm not kidding. Remember that these systems exist in more places than on monster-sized hard-disks. Embedded systems had limits of 4MB, 8MB or 16MB when these patches were done. While NAND has grown so that 64MB or 256MB parts are more common on boards, the savings is still rather substantial and allow for additional functionality. The space savings rivals 'crunchgened' binaries (think busybox). Savings between 32MB and 64MB is only a few $$$, but if you ship a million of something, the savings can be substantial. In addition, having everything link in shared libraries makes doing security updates much easier. Warner

On 2012-02-02, at 2:47 PM, Warner Losh wrote: Those systems also tend to ship with a very carefully culled set of binaries. Perhaps someone reading this with access to that type of system could do some measurements of a static vs. shared build of one of those embedded systems. A well designed system without library bloat can pump out some pretty skinny static binaries. --lyndon

On Feb 2, 2012, at 3:53 PM, Lyndon Nerenberg wrote: No. Read what I wrote: as a percentage of the whole. Yes. Thankfully, I've never had a similar loss on my FreeBSD boxes. :) Warner

Whoa! I wasn't expecting this flood of comments! :-) Anyway, I think that I was clear: the choices about separating files into directories, partitions, disks, network shares, etc... have always been pretty obvious to anybody with a minimum of common sense. The only way around them is foolishness or ignorance (or both). I can understand a newcomer, using a computer for his/her petty games one task at a time and not doing much, to believe the world would be simpler if it (or the filesystem) were flat and suited to his unvoiced personal expectations. This is nothing new, the machine language opcode RPM (read programmer's mind) is as old a joke as I can remember. 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 -- EMBnet/CNB Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es http://www.es.embnet.org

On Fri, 3 Feb 2012, Jose R. Valverde wrote: (snipping) 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.