10 Oct
2018
10 Oct
'18
11:08 p.m.
On 10/10/2018 08:43 AM, Norman Wilson wrote:
The first UNIX system I ever used, ca. 1980, had
users' home directories
in /u. I suspect it was that way (as suggested in some earlier messages)
just for storage management: separate file system from /usr.
I sort of like /u because I'm lazy and it's shorter than /usr or /home.
}:-)
I've carried /u around with me ever since to
other systems I've set up
from scratch, except in my home environment where I've made a radical
departure: everything that isn't part of the base OS is in a tree
rooted at /con, so home directories are /con/u. /con was `constant,'
inspired by /var, meaning stuff that should be preserved when the OS
is reinstalled--everything else should come from installation media or
configuration management.
Save for /etc, I like the spirit of /con.
But in any case there's nothing especially novel
about moving users' home
directories out of /usr, and since it's UNIX, nothing that says there has
to be any standard at all.
The wonderful thing about standards is that we have so many to choose from.
On the systems I am currently paid to help run, most
users have
home-directory names like /h/u12/c4/00/c4ntest. There is no attempt to
glue together a single name hierarchy; we have in excess of 17000 users
so that would be something of a mess. (I guess enormous directories
aren't the resource pigs they used to be,
I don't know if it's still the performance penalty that it used to be,
or if the systems are just faster and / or better and overcoming said
performance penalty of big directories.
though symlinks are just as bad as they have ever
been.)
Would you please elaborate on what you mean by that?
There's the ~user shell syntax for those who like
that; I don't, but
I have a little shell script in my personal bin directory so I can do
things like ls `home c4ntest`; it all just works.
I use tilde somewhat frequently, particularly when I want to manipulate
contents from someone else's home directory. (Usually copy something
from my directory elsewhere when running as root. I.e. scp a file to my
home, then move said file to where it belongs, which my normal user
can't write to.)
I've done some other things like your "home" script (or variables). But
I found them lacking when wanting to do file manipulations like above.
I once thought of writing a paper entitled `/usr and
/etc considered
harmful,' in which I would have proposed:
I would be interested in reading such a paper.
a. It no longer matters a whit whether the (real)
root file system can
fit into a 5MB slice of the disk or the like, so just merge everything
that spilled into /usr in the tiny-disk days back into the root where
it belongs.
Are you talking about just things like /usr ~> /home or all other
mounted file systems too?
I still see a reason to have other files systems, particularly if they
come from block devices with different storage criteria. I.e. RAID 1
for root, RAID 5 for user data, RAID 0 for news spool & HTTP cache, etc.
b. /etc is largely junk. Executables have long since
moved into /sbin.
Pretty much everything else that's there belongs (according to the
original scheme, not the latter-day complications inflicted by those
who didn't understand) in /lib.
I never liked executable (think binaries vs scripts) in /etc or /lib.
Maybe it's just my ignorance.
I've never had a really good grasp on the difference between bin and
sbin. Different people have different explanations. Then there's
Solaris sym-linking /bin to /usr/bin.
(I think) I get the /{bin,lib,…} vs /usr/{bin,lib,…} vs
/usr/local/{bin,lib,…}. At least / being what's required to boot strap
and bring the system up to run level 1 (or comparable). Then /usr being
the rest of the things installed by the OS vendor. With /usr/local
being where the site would install all of their customizations.
To me, this is more about scoping of who's responsible for what and what
it's primary purpose is.
Given Norman's comments, I could see how / and /usr could be merged back
together. Then I suppose that they could be restructured to remove /usr.
Question: Where do the following things belong, if not in /etc?
· passwd / shadow
· group / gshadow
· inittab
In other words, where do system configuration files live? — IMHO they
should be separate from the location of the files the programs consist
of. Much like /con above allowing most everything else to be replaced
wholesale.
Unfortunately all the quick hacks and
poorly-considered tweaks of the
past have long since been cast in stone by widespread convention, so
it's fruitless to try to clean any of this up.
That doesn't make it any less of a thought experiment or enlightening
discussion.
--
Grant. . . .
unix || die