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

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

[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

[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

[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

[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

[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

[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

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

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

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

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

[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

[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

[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

[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

[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

[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

[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

[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] ASR 37 teletype desired by LCM / Vulcan.com

[John Foust]

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