10 Oct
2018
10 Oct
'18
2:43 p.m.
Dave Horsfall:
Before I started using /home (Slowaris had yet to appear), I used /u/*
instead (I didn't want to pollute /usr with home directories).
===
I'm late to the party, but I'll chime in too:
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'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.
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. 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, though symlinks are just as bad as they have
ever been.) 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 once thought of writing a paper entitled `/usr and /etc
considered harmful,' in which I would have proposed:
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.
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.
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.
Norman Wilson
Toronto ON
10 Oct
10 Oct
4:26 p.m.
New subject: The origin of /home
Norman Wilson <norman(a)oclsc.org> wrote:
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.
Plan 9 did exactly that, no?
Arnold
5:08 p.m.
New subject: The origin of /home
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
11 Oct
11 Oct
12:22 a.m.
New subject: The origin of /home
On Wed, 10 Oct 2018, Grant Taylor via TUHS wrote:
On 10/10/2018 08:43 AM, Norman Wilson wrote:
Here is how I understand the current system is intended to work:
1. /sbin for binaries for use by root that must be available before the
system is fully brought up (and for an emergency copy of the Bourne
shell), which should all be linked static.
2. /bin for binaries for use by all users that must be available before
the system is fully brought up. These may be linked dynamic.
3. /lib for libraries which are needed for binaries in /bin to work, and
for kernel plugin modules in /lib/modules.
4. /usr/sbin for other binaries in the base system to be available to
root only.
5. /usr/bin for other binaries in the base system to be available to all
users.
6. /etc for global configuration files used by the kernel and the base OS.
7. /opt/PACKAGE contains a full bin, etc, lib etc. folder tree for every
non-base package (I would put almost everything here, including X Window
in /opt/X11/bin etc.).
8. /home as the base for all user folders.
(Scripts and binaries are not differentiated in this system.)
I think I would be prone to do a cleanup of the system to isolate
everything into some form of the above. Just my opinion.
-uso.
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.
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. 
2:33 a.m.
New subject: The origin of /home
Some (most?) Linux distributions have followed Solaris’ lead, and put all of /bin into
/usr/bin, and /sbin into /usr/sbin, and then symlinked /bin to /usr/bin (and /sbin to
/usr/sbin) to make everything effectively available in both locations.
Some rationale here:
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
<https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/>
Most (all?) Linux distributions never followed the "should be static, needed for boot
to runlevel 1", logic for /bin & /sbin anyway, so the locations were largely
based on a perception of traditional or most common location anyway. sh was thus in /bin,
while env was in /usr/bin, for example.
d
Here is how I understand the current system is
intended to work:
1. /sbin for binaries for use by root that must be available before the system is fully
brought up (and for an emergency copy of the Bourne shell), which should all be linked
static.
2. /bin for binaries for use by all users that must be available before the system is
fully brought up. These may be linked dynamic.
3. /lib for libraries which are needed for binaries in /bin to work, and for kernel
plugin modules in /lib/modules.
4. /usr/sbin for other binaries in the base system to be available to root only.
5. /usr/bin for other binaries in the base system to be available to all users.
6. /etc for global configuration files used by the kernel and the base OS.
7. /opt/PACKAGE contains a full bin, etc, lib etc. folder tree for every non-base package
(I would put almost everything here, including X Window in /opt/X11/bin etc.).
8. /home as the base for all user folders.
(Scripts and binaries are not differentiated in this system.)
I think I would be prone to do a cleanup of the system to isolate everything into some
form of the above. Just my opinion.
-uso.
7:10 p.m.
New subject: The origin of /home
arnold(a)skeeve.com writes:
Norman Wilson <norman(a)oclsc.org> wrote:
> 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.
Plan 9 did exactly that, no?
Yes, but no. With namespaces, There Is No Root. You can pretzel up
the filesystem to your heart's content, and nobody else will ever know.
But on the filserver, there are some required conventions.
* /usr is for home directories
* /bin is an empty mountpoint
* /sys contains "the system" in the form of reference files, configs,
source code, etc.
* /lib is a semi-sparse directory tree that non-system programs can use
to store data/configs/etc.
* every CPU architecture gets its own top level directory (e.g.
/386, /sparc, ...)
But the fileserver conventions are only there because the cpu/terminal
diskless boot scripts need a basically consistent fileserver
environment to do their initial bootstrap from. After that, the
namespace is your to pervert at your pleasure. And such perversion
is actively encouraged :-)
http://doc.cat-v.org/plan_9/4th_edition/papers/9 (e.g. "Implementation of Name
Spaces")
http://doc.cat-v.org/plan_9/4th_edition/papers/names
--lyndon
2029
days inactive
2030
days old
5 comments
6 participants
participants (6)
-
arnold＠skeeve.com -
David Arnold -
Grant Taylor -
Lyndon Nerenberg -
Norman Wilson -
Steve Nickolas