[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Hendrik Jan Thomassen]

If I recall well the /sbin directory first appeared in HP/UX,
and the name stood for 'Static binaries'. Its reason for existence
was that with the introduction of shared libraries the file with
the C-library had become a single point of failure. Therefore this
sbin was introduced to hold Statically linked executables for the
most important commands needed to fix a broken system (sh, ls, mv,
cp, find, tar, fsck etcetera). With this directory earlier than
/bin in his PATH the administrator could at least restore a working
libc.so file. And, while we are at it, the name 'executable' was
not commonly used: they were called 'binaries' (except in IBM
mainframe terminology were they were called 'load modules').
Only much later the habit of /sbin = System binaries emerged.

An important reason to split /bin vs. /usr/bin and /lib vs. /usr/lib
etc. was that the root file system had to be kept small. The fsck
program, while at work, builds tables. If possible, they stay in
memory, but if memory runs out fsck writes them to disk. However,
you don't want them to be written to an untrusted/unchecked file
system, and certainly not to the file system currently under repair.
Since the root file system has to be checked before the others, it
had to be small enough so ensure that fsck could run memory-based
only. Therefore: the /bin, /lib and other root-fs based directories
held the minimal stuff needed for booting and for repairs/restores,
while all the rest had to go into the "overflow" directories /usr/bin,
/usr/lib etc (and, obviously, /usr was a separately mounted partition).
Remember: those were the days that every reboot included a full
fsck on all your partitions. 
-- 
Hendrik-Jan Thomassen     <hjt at ATComputing.nl>
AT Computing
6546 BE  Nijmegen NL      Fax +31 24 352 72 92
info at atcomputing.nl       www.atcomputing.nl
'If you think education is expensive, then try ignorance.'

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Jaap Akkerhuis]

On Feb 5, 2012, at 9:38, Hendrik Jan Thomassen wrote:

> Remember: those were the days that every reboot included a full
> fsck on all your partitions. 

And before such a modern tool as fsck came one used icheck/ncheck/clri to
fix broken file systems.  Ah, those were the days ...

	jaap

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Warner Losh]

On Feb 5, 2012, at 1:38 AM, Hendrik Jan Thomassen wrote:
> If I recall well the /sbin directory first appeared in HP/UX,
> and the name stood for 'Static binaries'.

Do you recall when this was?

4.3-RENO has the bin/sbin split, and that was 1990, but the split isn't yet in 4.3-Tahoe, which was in 1988.  In 4.3-RENO it was already system binaries since 4.3 didn't have shared libraries, at least according to the TUHS 4.3-RENO archive

	http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/share/man/man7/hier.7

I don't have a copy of the BSD SCCS trees to narrow the split down further...

Perhaps this indicates multiple invention?

Warner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120205/84dadaff/attachment.html>

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Lyndon Nerenberg]

On 2012-02-04, at 11:34 AM, Pepe wrote:

> In SCO Xenix/UNIX, the home directory is usually mounted on /u.
> 
> I was amused the first time I saw it.

The /u convention was a common site convention in at least the early 1980s. I don't recall a vendor using it as a default in any shipping system, though.  Mind you, I have blissfully forgotten most of my follies with Xenix.

--lyndon

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Pepe]

"Jose R. Valverde" <jrvalverde at cnb.csic.es> said:

> 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..."

In SCO Xenix/UNIX, the home directory is usually mounted on /u.

I was amused the first time I saw it.

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Steve Nickolas]

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.

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Ronald Natalie]

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).

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Jose R. Valverde]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Tim Bradshaw]

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.

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[John Cowan]

Norman Wilson scripsit:

> Once upon a time, I made an RK05 disk (5MB) with a stripped-down
> post-V7 for an 11/45.  It had just enough programs to allow basic file
> manipulation and text-processing.

In my first job, around 1976, I hand-carried an RK05 from New Jersey
to Kansas City.  It was full of my employer's proprietary software,
which I was to install.  The laternative was to bring a huge pile of
floppies, which didn't seem sensible.

I was able to convince the airline security of those days that they
could neither open the RK nor X-ray it, but when it got there, it was
unreadable anyway.  My colleague took the next flight, with the huge
pile.

> Due to contractor screwups (when the chilled water was turned on, it
> rained up and down the hall--many poorly-soldered joints in the copper
> pipes), [...]

During PM, always mount a scratch machine room!

-- 
First known example of political correctness:   John Cowan
After Nurhachi had united all the other         http://www.ccil.org/~cowan
Jurchen tribes under the leadership of the      cowan at ccil.org
Manchus, his successor Abahai (1592-1643)
issued an order that the name Jurchen should       --S. Robert Ramsey,
be banned, and from then on, they were all           The Languages of China
to be called Manchus.

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Carl Lowenstein]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

On Thu, Feb 2, 2012 at 3:16 PM, Norman Wilson <norman at oclsc.org> wrote:
> Lyndon Nerenberg:
>
>  A well designed system without library bloat can pump out some
>  pretty skinny static binaries.
>
> =======
>
> V6, for example.  Or even V7 if carefully pruned.
>
> Once upon a time, I made an RK05 disk (5MB) with a stripped-down
> post-V7 for an 11/45.  It had just enough programs to allow
> basic file manipulation and text-processing.
>
> We used this compact system to allow our secretaries (in a
> small university department in the early 1980s) to continue
> typing up papers and letters on the day the machine-room
> air conditioning was being replaced.  With the doors standing
> open and a big fan, we were willing to leave the 11/45 running,
> but not the VAX-11/780.
>
> Due to contractor screwups (when the chilled water was turned
> on, it rained up and down the hall--many poorly-soldered
> joints in the copper pipes), we actually needed this for a
> couple of days, so for safety I shut the system down every
> evening, removed the RK05 cartridge, and took it downstairs
> to the 11/34 that had a tape drive, where I booted RT11 and
> took an image backup with ROLLOUT.

You may have been lucky not to need the backup images.  My experience
with ROLLIN/ROLLOUT early on was that DEC software used only 200 of
the 203 tracks available on a RK05.   Unix on the other hand also used
the 3 spare tracks.  4872 whole blocks.  So ROLLIN backups of a Unix
RK05 did not always have everything on them.

    carl
-- 
    carl lowenstein         marine physical lab     u.c. san diego
                                                 clowenstein at ucsd.edu

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Warner Losh]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Warner Losh]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Norman Wilson]

Lyndon Nerenberg:

  A well designed system without library bloat can pump out some
  pretty skinny static binaries.

=======

V6, for example.  Or even V7 if carefully pruned.

Once upon a time, I made an RK05 disk (5MB) with a stripped-down
post-V7 for an 11/45.  It had just enough programs to allow
basic file manipulation and text-processing.

We used this compact system to allow our secretaries (in a
small university department in the early 1980s) to continue
typing up papers and letters on the day the machine-room
air conditioning was being replaced.  With the doors standing
open and a big fan, we were willing to leave the 11/45 running,
but not the VAX-11/780.

Due to contractor screwups (when the chilled water was turned
on, it rained up and down the hall--many poorly-soldered
joints in the copper pipes), we actually needed this for a
couple of days, so for safety I shut the system down every
evening, removed the RK05 cartridge, and took it downstairs
to the 11/34 that had a tape drive, where I booted RT11 and
took an image backup with ROLLOUT.

Norman Wilson
Toronto ON

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Lyndon Nerenberg]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Lyndon Nerenberg]

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?

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Warner Losh]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Tim Newsham]

[-- 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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Warner Losh]

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
> 
> 

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Dave Horsfall]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Warner Losh]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Tim Newsham]

> 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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Warner Losh]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[John Cowan]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Warner Losh]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Larry McVoy]

On Thu, Feb 02, 2012 at 01:35:58PM +0000, Tim Bradshaw wrote:
> On 1 Feb 2012, at 09:26, arnold at skeeve.com wrote:
> 
> > The Berkeley guys did NOT invent shared libraries.  Shared libraries as
> > we know them came originally from Sun, on SunOS 4.x for sure, possibly
> > on SunOS 3.x. (Larry?)  Many commercial vendors adopted the design (Ultrix,
> > I think, and maybe others) and finally around 4.4 they found their way into
> > "pure" BSD.
> 
> 4.  3 may have had them but not in any version we had, so I'd guess not in a major release, anyway.

I got there when SunOS 4.1 was being worked on and they were definitely in
4.0.  4.0 gave you shared libs, vnodes, mmap, there was a lot of good stuff
in there.  It actually worked by 4.1.1 which was probably my favorite SunOS
release.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Tim Bradshaw]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Tim Bradshaw]

On 1 Feb 2012, at 09:26, arnold at skeeve.com wrote:

> The Berkeley guys did NOT invent shared libraries.  Shared libraries as
> we know them came originally from Sun, on SunOS 4.x for sure, possibly
> on SunOS 3.x. (Larry?)  Many commercial vendors adopted the design (Ultrix,
> I think, and maybe others) and finally around 4.4 they found their way into
> "pure" BSD.

4.  3 may have had them but not in any version we had, so I'd guess not in a major release, anyway.

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Random832]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Warner Losh]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Jose R. Valverde]

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

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[arnold]

> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

Cute, but most of the history is wrong.

The distinction between /bin and /usr/bin is true - / held the things
need to boot the system. Other things were on /usr.

The Berkeley guys did NOT invent shared libraries.  Shared libraries as
we know them came originally from Sun, on SunOS 4.x for sure, possibly
on SunOS 3.x. (Larry?)  Many commercial vendors adopted the design (Ultrix,
I think, and maybe others) and finally around 4.4 they found their way into
"pure" BSD.

/home and /opt came into the picture circa 1989 with SVR4 when Berkeley,
AT&T and Sun (and maybe a few others?) got together to standardize the
layout and make diskless booting possbile and reasonable with NFS sharing
of home directories. /sbin & /usr/sbin came into the picture at this
point also, to hold executables that until then had lived in /etc. The
idea was that /etc should only have per-machine configuration files.

The general point of the article and of some of the postings, that the
proliferation doesn't make a lot of sense today, is well taken. The
Bell Labs guys themselves recognized this when they did Plan 9.

The problem is even worse on 64 bit Linux systems, which can handle
two different architectures. /lib and /lib64 confuse a lot of the
older 'configure' programs.

Personally, I hate reading articles by "experts" where 85% of the facts
are wrong.  I lived through all of it, and I know better... :-)

Arnold

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Warner Losh]

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>

[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[A. P. Garcia]

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>