* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split @ 2012-01-31 19:16 A. P. Garcia 2012-01-31 19:27 ` Warner Losh 2012-02-01 11:12 ` Jose R. Valverde 0 siblings, 2 replies; 24+ messages in thread From: A. P. Garcia @ 2012-01-31 19:16 UTC (permalink / raw) http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120131/7b847bfb/attachment.html> ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-01-31 19:16 [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split A. P. Garcia @ 2012-01-31 19:27 ` Warner Losh 2012-02-01 11:12 ` Jose R. Valverde 1 sibling, 0 replies; 24+ messages in thread From: Warner Losh @ 2012-01-31 19:27 UTC (permalink / raw) Well, except for the part that it stopped making sense before Linux was invented... the split also allows minimal ram disk images to load the rest of the OS and mount the full system remotely... These were still useful after 1990 when Linux was first released. It wasn't until around 1995 or so that disks were big/cheap enough for it to not matter... Warner On Jan 31, 2012, at 12:16 PM, A. P. Garcia wrote: > http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120131/ecc6c47a/attachment.html> ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-01-31 19:16 [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split A. P. Garcia 2012-01-31 19:27 ` Warner Losh @ 2012-02-01 11:12 ` Jose R. Valverde 2012-02-01 17:35 ` Warner Losh ` (2 more replies) 1 sibling, 3 replies; 24+ messages in thread From: Jose R. Valverde @ 2012-02-01 11:12 UTC (permalink / raw) On Tue, 31 Jan 2012 13:16:17 -0600 "A. P. Garcia" <a.phillip.garcia at gmail.com> wrote: > http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-01 11:12 ` Jose R. Valverde @ 2012-02-01 17:35 ` Warner Losh 2012-02-02 13:32 ` Random832 2012-02-02 13:45 ` Tim Bradshaw 2 siblings, 0 replies; 24+ messages in thread From: Warner Losh @ 2012-02-01 17:35 UTC (permalink / raw) On Feb 1, 2012, at 4:12 AM, Jose R. Valverde wrote: > 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. You had different quotas on different partitions as well... Something most folks don't get these days: you used to get 5MB from the CS department and be grateful they gave you that much... There were bugs in the dim, dark past too where if you filled up /, the system would crash. Having a separate / insulated you from that. Also, fsck and file systems were a little more fragile in the early days than now, so you wanted to make sure that you minimized the amount of data needed to change before / could be mounted rw. This boot-strapping process these days (on linux) happens in a ram disk, but historically (and still in many BSDs) happens on the actual drive, so any corruption or filesystem issue would take a while to repair, and once repaired you had to reboot to ensure that the pages that were swapped in read-only that might have been changed behind the scenes by fsck were properly flushed. None of that was mentioned in the article :) Warner ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-01 11:12 ` Jose R. Valverde 2012-02-01 17:35 ` Warner Losh @ 2012-02-02 13:32 ` Random832 2012-02-02 17:24 ` Warner Losh 2012-02-02 18:02 ` Tim Newsham 2012-02-02 13:45 ` Tim Bradshaw 2 siblings, 2 replies; 24+ messages in thread From: Random832 @ 2012-02-02 13:32 UTC (permalink / raw) On 2/1/2012 6:12 AM, Jose R. Valverde wrote: > 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. 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 13:32 ` Random832 @ 2012-02-02 17:24 ` Warner Losh 2012-02-02 17:36 ` John Cowan 2012-02-02 17:40 ` Warner Losh 2012-02-02 18:02 ` Tim Newsham 1 sibling, 2 replies; 24+ messages in thread From: Warner Losh @ 2012-02-02 17:24 UTC (permalink / raw) On Feb 2, 2012, at 6:32 AM, Random832 wrote: > On 2/1/2012 6:12 AM, Jose R. Valverde wrote: >> 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. > > The thing is, /usr isn't "user data". That's /home. /usr is just "more system space". /usr was user data, back in the day. /home came about much later. > 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 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 17:24 ` Warner Losh @ 2012-02-02 17:36 ` John Cowan 2012-02-02 18:10 ` Warner Losh 2012-02-02 21:14 ` Dave Horsfall 2012-02-02 17:40 ` Warner Losh 1 sibling, 2 replies; 24+ messages in thread From: John Cowan @ 2012-02-02 17:36 UTC (permalink / raw) Warner Losh scripsit: > 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. Does anyone know what the "s" in sbin stands for? "Superuser"? I would have put these files in /root/bin, but perhaps /root did not yet exist. Not everything in /usr/share comes from /etc; in particular, /usr/share/dict was formerly /usr/dict. -- Go, and never darken my towels again! John Cowan --Rufus T. Firefly http://ccil.org/~cowan ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 17:36 ` John Cowan @ 2012-02-02 18:10 ` Warner Losh 2012-02-02 21:14 ` Dave Horsfall 1 sibling, 0 replies; 24+ messages in thread From: Warner Losh @ 2012-02-02 18:10 UTC (permalink / raw) On Feb 2, 2012, at 10:36 AM, John Cowan wrote: > Warner Losh scripsit: > >> 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. > > Does anyone know what the "s" in sbin stands for? "Superuser"? I would > have put these files in /root/bin, but perhaps /root did not yet exist. 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 > Not everything in /usr/share comes from /etc; in particular, /usr/share/dict > was formerly /usr/dict. 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 17:36 ` John Cowan 2012-02-02 18:10 ` Warner Losh @ 2012-02-02 21:14 ` Dave Horsfall 2012-02-02 21:49 ` Warner Losh 1 sibling, 1 reply; 24+ messages in thread From: Dave Horsfall @ 2012-02-02 21:14 UTC (permalink / raw) On Thu, 2 Feb 2012, John Cowan wrote: > Does anyone know what the "s" in sbin stands for? "Superuser"? I would > have put these files in /root/bin, but perhaps /root did not yet exist. I seem to recall that they were statically linked i.e. not using those new-fangled shared library thingies. And if you've ever tried to admin a system with a trashed shared library, you'll understand; it usually involves looking for the installation media. > Not everything in /usr/share comes from /etc; in particular, > /usr/share/dict was formerly /usr/dict. As I dimly recall, /usr/share was exported, hence the name. -- Dave ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 21:14 ` Dave Horsfall @ 2012-02-02 21:49 ` Warner Losh 2012-02-02 22:29 ` Tim Newsham 2012-02-02 22:53 ` [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split Lyndon Nerenberg 0 siblings, 2 replies; 24+ messages in thread From: Warner Losh @ 2012-02-02 21:49 UTC (permalink / raw) On Feb 2, 2012, at 2:14 PM, Dave Horsfall wrote: > On Thu, 2 Feb 2012, John Cowan wrote: > >> Does anyone know what the "s" in sbin stands for? "Superuser"? I would >> have put these files in /root/bin, but perhaps /root did not yet exist. > > I seem to recall that they were statically linked i.e. not using those > new-fangled shared library thingies. And if you've ever tried to admin a > system with a trashed shared library, you'll understand; it usually > involves looking for the installation media. /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 >> Not everything in /usr/share comes from /etc; in particular, >> /usr/share/dict was formerly /usr/dict. > > As I dimly recall, /usr/share was exported, hence the name. > > -- Dave > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 21:49 ` Warner Losh @ 2012-02-02 22:29 ` Tim Newsham 2012-02-02 22:47 ` Warner Losh 2012-02-02 22:53 ` [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split Lyndon Nerenberg 1 sibling, 1 reply; 24+ messages in thread From: Tim Newsham @ 2012-02-02 22:29 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 334 bytes --] > Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used). you're kidding, right? Disk space of binaries? (I still wish "du" had a "-$" flag that pulled info from a recent price database). > Warner -- Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 22:29 ` Tim Newsham @ 2012-02-02 22:47 ` Warner Losh 2012-02-02 22:59 ` Lyndon Nerenberg 2012-03-13 16:09 ` [TUHS] ASR 37 teletype desired by LCM / Vulcan.com John Foust 0 siblings, 2 replies; 24+ messages in thread From: Warner Losh @ 2012-02-02 22:47 UTC (permalink / raw) On Feb 2, 2012, at 3:29 PM, Tim Newsham wrote: >> Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used). > > you're kidding, right? Disk space of binaries? > (I still wish "du" had a "-$" flag that pulled info from a recent price > database). 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 22:47 ` Warner Losh @ 2012-02-02 22:59 ` Lyndon Nerenberg 2012-02-02 23:33 ` Warner Losh 2012-03-13 16:09 ` [TUHS] ASR 37 teletype desired by LCM / Vulcan.com John Foust 1 sibling, 1 reply; 24+ messages in thread From: Lyndon Nerenberg @ 2012-02-02 22:59 UTC (permalink / raw) On 2012-02-02, at 2:47 PM, Warner Losh wrote: > Embedded systems had limits of 4MB, 8MB or 16MB when these patches were done. 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 22:59 ` Lyndon Nerenberg @ 2012-02-02 23:33 ` Warner Losh 0 siblings, 0 replies; 24+ messages in thread From: Warner Losh @ 2012-02-02 23:33 UTC (permalink / raw) On Feb 2, 2012, at 3:59 PM, Lyndon Nerenberg wrote: > On 2012-02-02, at 2:47 PM, Warner Losh wrote: > >> Embedded systems had limits of 4MB, 8MB or 16MB when these patches were done. > > 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. You know that I wrote those patches for FreeBSD when I was producing embedded systems that needed the savings, right? At the time, the size of / was on the order of 60MB without the patches and 8MB with the patches (excluding the kernel and modules). Compression got the size of the kernel + / + /usr down to about 7MB which left enough room on the flash for our monolithic application. At the time, the crunchgen approach to binaries produced similar values (about 6MB for the same list of binaries we selected). However, our build process and monolithic application were ill suited to crunchgenning so we opted for shared libraries which got us most of the benefits and allowed us better flexibility in deploying new versions of our program. After the patches were done, we discovered other benefits, such as easier deploying of security fixes... Warner ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] ASR 37 teletype desired by LCM / Vulcan.com 2012-02-02 22:47 ` Warner Losh 2012-02-02 22:59 ` Lyndon Nerenberg @ 2012-03-13 16:09 ` John Foust 1 sibling, 0 replies; 24+ messages in thread From: John Foust @ 2012-03-13 16:09 UTC (permalink / raw) I forward a request from the Greenkeys (teletype) mailing list. The ASR 37 did upper- and lower-case. - John From: Cynde Moya <CyndeM@vulcan.com> To: greenkeys <GreenKeys at mailman.qth.net> Date: Mon, 12 Mar 2012 22:01:51 +0000 Subject: [GreenKeys] Wanted : ASR 37 The Living Computer Museum is looking to purchase a working or restorable ASR 37 teletype. Do you have any leads? Thanks very much. Cynde Moya Librarian/Archivist, Vintage Computing Vulcan Inc 206 342-2385 http://www.vulcan.com http://www.LivingComputerMuseum.org ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 21:49 ` Warner Losh 2012-02-02 22:29 ` Tim Newsham @ 2012-02-02 22:53 ` Lyndon Nerenberg 2012-02-02 23:35 ` Warner Losh 2012-02-03 11:10 ` Tim Bradshaw 1 sibling, 2 replies; 24+ messages in thread From: Lyndon Nerenberg @ 2012-02-02 22:53 UTC (permalink / raw) On 2012-02-02, at 1:49 PM, Warner Losh wrote: > Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used In the day of sub-hundred dollar terabyte drives, you're kidding me, right? Also, ever lost libc.so on a Solaris box? ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 22:53 ` [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split Lyndon Nerenberg @ 2012-02-02 23:35 ` Warner Losh 2012-02-03 11:10 ` Tim Bradshaw 1 sibling, 0 replies; 24+ messages in thread From: Warner Losh @ 2012-02-02 23:35 UTC (permalink / raw) On Feb 2, 2012, at 3:53 PM, Lyndon Nerenberg wrote: > On 2012-02-02, at 1:49 PM, Warner Losh wrote: >> Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used > > In the day of sub-hundred dollar terabyte drives, you're kidding me, right? No. Read what I wrote: as a percentage of the whole. > Also, ever lost libc.so on a Solaris box? Yes. Thankfully, I've never had a similar loss on my FreeBSD boxes. :) Warner ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 22:53 ` [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split Lyndon Nerenberg 2012-02-02 23:35 ` Warner Losh @ 2012-02-03 11:10 ` Tim Bradshaw 2012-02-03 15:22 ` Jose R. Valverde 1 sibling, 1 reply; 24+ messages in thread From: Tim Bradshaw @ 2012-02-03 11:10 UTC (permalink / raw) On 2 Feb 2012, at 22:53, Lyndon Nerenberg wrote: > > In the day of sub-hundred dollar terabyte drives, you're kidding me, right? > > Also, ever lost libc.so on a Solaris box? This is missing the point. A system with shared libraries can deliver a fix to a bug in a library by a new version of that library, instead of a new version of every program which is statically linked against that library. ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-03 11:10 ` Tim Bradshaw @ 2012-02-03 15:22 ` Jose R. Valverde 2012-02-03 16:06 ` Ronald Natalie 2012-02-03 16:09 ` Steve Nickolas 0 siblings, 2 replies; 24+ messages in thread From: Jose R. Valverde @ 2012-02-03 15:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-03 15:22 ` Jose R. Valverde @ 2012-02-03 16:06 ` Ronald Natalie 2012-02-03 16:09 ` Steve Nickolas 1 sibling, 0 replies; 24+ messages in thread From: Ronald Natalie @ 2012-02-03 16:06 UTC (permalink / raw) On Feb 3, 2012, at 10:22 AM, Jose R. Valverde wrote: > > There was a reason to separate user data from system data to avoid > the system disk from becoming unusable by a misbehaving user. But this wasn't practically done in the early UNIX. Even much that was in /usr was required for normal system operation and there was stuff that got left on the root that was within the user's ability to hose up. I was system administrator of a V6 UNIX that was used in a University setting in the late 70's. People banging on the disks was the least of my issues. There were far more fun ways to crash UNIX (and even PDP-11's in general), break security, etc... that I ran around trying to forestall. In fact our /usr was on the root disk. We had two "user" home directory drives /sys1 and /sys2 on two more RK05's. My first quota as a student was 8 blocks (4K). I supplemented that at first with a dectape (half a megabyte) and then with my own RK05 pack (we reserved two drives for user mounted volumes). We swapped to an RF11 fixed head disk of about a megabyte. The fun one was people trying to ascribe meanings to the "acronyms" on the kernel disk (KEN and DMR). ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-03 15:22 ` Jose R. Valverde 2012-02-03 16:06 ` Ronald Natalie @ 2012-02-03 16:09 ` Steve Nickolas 1 sibling, 0 replies; 24+ messages in thread From: Steve Nickolas @ 2012-02-03 16:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 17:24 ` Warner Losh 2012-02-02 17:36 ` John Cowan @ 2012-02-02 17:40 ` Warner Losh 1 sibling, 0 replies; 24+ messages in thread From: Warner Losh @ 2012-02-02 17:40 UTC (permalink / raw) On Feb 2, 2012, at 10:24 AM, Warner Losh wrote: > > On Feb 2, 2012, at 6:32 AM, Random832 wrote: > >> On 2/1/2012 6:12 AM, Jose R. Valverde wrote: >>> 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. >> >> The thing is, /usr isn't "user data". That's /home. /usr is just "more system space". > > /usr was user data, back in the day. /home came about much later. > >> 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 > > 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. That should read 'all non-binary executables and non-config files' Warner ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-02 13:32 ` Random832 2012-02-02 17:24 ` Warner Losh @ 2012-02-02 18:02 ` Tim Newsham 1 sibling, 0 replies; 24+ messages in thread From: Tim Newsham @ 2012-02-02 18:02 UTC (permalink / raw) > The thing is, /usr isn't "user data". That's /home. /usr is just "more > system space". Thats exactly what /usr is supposed to be. user data. ie. /usr/ken, /usr/dmr. -- Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split 2012-02-01 11:12 ` Jose R. Valverde 2012-02-01 17:35 ` Warner Losh 2012-02-02 13:32 ` Random832 @ 2012-02-02 13:45 ` Tim Bradshaw 2 siblings, 0 replies; 24+ messages in thread From: Tim Bradshaw @ 2012-02-02 13:45 UTC (permalink / raw) On 1 Feb 2012, at 11:12, Jose R. Valverde wrote: > This is something obvious to anyone maintaining a multi-user server, only > presumptuous single-user windows toyers think they know better. If only this were true. Until reasonably recently (may be a couple of years ago was the last time I cared), a major Unix vendor's recommendation was not to have separate /var, because that was "old fashioned" (I assume). Some of their installation / upgrade programs would fail if you did in fact. For additional amusement, the default install would put no limit on the size of the memory-based /tmp filesystem. So basically anything on the system could fill / with all the undesirable consequences that has, and also eat the system's memory in an unpleasantly persistent way. --tim ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2012-03-13 16:09 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-01-31 19:16 [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split A. P. Garcia 2012-01-31 19:27 ` Warner Losh 2012-02-01 11:12 ` Jose R. Valverde 2012-02-01 17:35 ` Warner Losh 2012-02-02 13:32 ` Random832 2012-02-02 17:24 ` Warner Losh 2012-02-02 17:36 ` John Cowan 2012-02-02 18:10 ` Warner Losh 2012-02-02 21:14 ` Dave Horsfall 2012-02-02 21:49 ` Warner Losh 2012-02-02 22:29 ` Tim Newsham 2012-02-02 22:47 ` Warner Losh 2012-02-02 22:59 ` Lyndon Nerenberg 2012-02-02 23:33 ` Warner Losh 2012-03-13 16:09 ` [TUHS] ASR 37 teletype desired by LCM / Vulcan.com John Foust 2012-02-02 22:53 ` [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split Lyndon Nerenberg 2012-02-02 23:35 ` Warner Losh 2012-02-03 11:10 ` Tim Bradshaw 2012-02-03 15:22 ` Jose R. Valverde 2012-02-03 16:06 ` Ronald Natalie 2012-02-03 16:09 ` Steve Nickolas 2012-02-02 17:40 ` Warner Losh 2012-02-02 18:02 ` Tim Newsham 2012-02-02 13:45 ` Tim Bradshaw
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).