Re: [TUHS] The origin of /home

Re: [TUHS] The origin of /home

[Noel Chiappa]

    > From: Dan Cross

    > particular in sites with lots of users like universities and
    > production-focused corporate groups

The existence of /usr, /usr/bin, /etc, /lib, etc dates back to the Research
group at Bell, so I don't think we can look to these other environments for an
explanation.

    > "Hmm. Well, we've got space in /usr: create /usr/bin

I seem to recall reading (don't recall where, OTTOMY) an explanation for the
creation of /usr/bin, and I think it was performance related; IIRC the issue
was that they wanted to keep the directory size down (both for disk block
caching, and search time, reasons). Or maybe that was later on, and it was
originally created for 'user-maintained' ancillary programs (another vague
memory)?

    > The more intriguing possibility from the antiquarian point of view is
    > whether someone coined "/home" and then THAT led to the rise of the "home
    > directory" nomenclature.

My memory is that the term "home directory" predates /home - perhaps on other
OS's such as TOPS-20, but I don't have time to research that. (I did look
quickly in the Multics docs, and it has 'working directory', i.e. current dir
- but it refers to the home dir as 'original WD', i.e. the WD at the time of
login.)

       Noel

Re: [TUHS] The origin of /home

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]

On Thu, Sep 27, 2018 at 11:34 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > From: Dan Cross
>
>     > particular in sites with lots of users like universities and
>     > production-focused corporate groups
>
> The existence of /usr, /usr/bin, /etc, /lib, etc dates back to the Research
> group at Bell, so I don't think we can look to these other environments
> for an
> explanation.
>

Sorry, I was (very) unclear in this point. I was referring to two separate
things:

1) Why things were spread out across multiple filesystems (space and/or
performance considerations dating from the Bell Labs days), and
2) The notion that rigid structures built in at a very low level would
naturally give rise to local naming conventions as "large" sites grew
beyond the limitations built into the system. E.g., /udd/u1 etc vs /home vs
/usr/users vs /net/somehostname vs /var/users vs whatever. As a concrete
example is the use of name-dependent hierarchical home directory paths like
"/home/c/r/cross" because one tried to put too many directories into /home
(I have actually seen the UFS directory entry limit hit in /home on a
machine that had >32k users). Anyway, eventually through whatever accident
of history "/home" seems to have won as a de facto standard.

    > "Hmm. Well, we've got space in /usr: create /usr/bin
>
> I seem to recall reading (don't recall where, OTTOMY) an explanation for
> the
> creation of /usr/bin, and I think it was performance related; IIRC the
> issue
> was that they wanted to keep the directory size down (both for disk block
> caching, and search time, reasons). Or maybe that was later on, and it was
> originally created for 'user-maintained' ancillary programs (another vague
> memory)?
>

I think the latter might be a justification-after-the-fact: /usr as the
filesystem containing stuff of interest to the users.

    > The more intriguing possibility from the antiquarian point of view is
>     > whether someone coined "/home" and then THAT led to the rise of the
> "home
>     > directory" nomenclature.
>
> My memory is that the term "home directory" predates /home - perhaps on
> other
> OS's such as TOPS-20, but I don't have time to research that. (I did look
> quickly in the Multics docs, and it has 'working directory', i.e. current
> dir
> - but it refers to the home dir as 'original WD', i.e. the WD at the time
> of
> login.)
>

If I recall correctly, the mappings from "users" on TOPS-20 to directories
is an injection, but I don't think they used the "home directory"
nomenclature.

Certainly the analogy with one's directory as home is clear enough.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 3545 bytes --]

Re: [TUHS] The origin of /home

[Noel Chiappa]

    > From: Norman Wilson

    > Unfortunately all the quick hacks and poorly-considered tweaks of the
    > past have long since been cast in stone by widespread convention

There seem to be two kind of people in the world; i) those who cannot bring
themselves to change anything, and ii) those who change all sort of things,
usually with no good reason (perhaps just to be different).

The world of Unix seems to be thickly stocked with both.

    Noel

Re: [TUHS] The origin of /home

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

On Wed, Oct 10, 2018 at 11:27 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

> There seem to be two kind of people in the world; i) those who cannot bring
> themselves to change anything, and ii) those who change all sort of things,
> usually with no good reason (perhaps just to be different).
>
> The world of Unix seems to be thickly stocked with both.
>
Demonstrating that we are, after all, human. ;-)

Although I suggest that there miight be a third kind, which I think might
be defined as usually those that have had some experience:  *"iii) Those
that have learned when its now wise to break from the past, but have
learned enough from it to change just the amount that needs to be changed
and no more."*

Clem

ᐧ

[-- Attachment #2: Type: text/html, Size: 1954 bytes --]

Re: [TUHS] The origin of /home

[David]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]


> On Oct 10, 2018, at 8:45 AM, Clem Cole <clemc@ccc.com> wrote:
> 
> 
> 
> On Wed, Oct 10, 2018 at 11:27 AM Noel Chiappa <jnc@mercury.lcs.mit.edu <mailto:jnc@mercury.lcs.mit.edu>> wrote:
> There seem to be two kind of people in the world; i) those who cannot bring
> themselves to change anything, and ii) those who change all sort of things,
> usually with no good reason (perhaps just to be different).
> 
> The world of Unix seems to be thickly stocked with both.
> Demonstrating that we are, after all, human. ;-) 
> 
> Although I suggest that there miight be a third kind, which I think might be defined as usually those that have had some experience:  "iii) Those that have learned when its now wise to break from the past, but have learned enough from it to change just the amount that needs to be changed and no more."
> 
> Clem
> 
> ᐧ

That third kind is so rare as to be unheard-of in common software circles.

	David


[-- Attachment #2: Type: text/html, Size: 2941 bytes --]

Re: [TUHS] The origin of /home

[Michael Kjörling]

On 10 Oct 2018 11:45 -0400, from clemc@ccc.com (Clem Cole):
>> There seem to be two kind of people in the world; i) those who cannot bring
>> themselves to change anything, and ii) those who change all sort of things,
>> usually with no good reason (perhaps just to be different).
> 
> Although I suggest that there miight be a third kind, which I think might
> be defined as usually those that have had some experience:  *"iii) Those
> that have learned when its now wise to break from the past, but have
> learned enough from it to change just the amount that needs to be changed
> and no more."*

I know I'm a bit late to the party here too, but from personal
experience, I'd add *"iv) those who change all sort of things, and
thereby end up with something eerily similar to that which was
recently changed away from"*.

Case in point: "the cloud".

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)

Re: [TUHS] The origin of /home

[Dave Horsfall]

On Wed, 10 Oct 2018, Noel Chiappa wrote:

> There seem to be two kind of people in the world; i) those who cannot 
> bring themselves to change anything, and ii) those who change all sort 
> of things, usually with no good reason (perhaps just to be different).

I tend to fall into the former category; I don't change anything unless 
there's a damned good reason e.g. a security update (which doesn't seem to 
happen often, unlike a certain other OS).

-- Dave

Re: [TUHS] The origin of /home

[Norman Wilson]

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

Re: [TUHS] The origin of /home

[arnold]

Norman Wilson <norman@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

Re: [TUHS] The origin of /home

[Lyndon Nerenberg]

arnold@skeeve.com writes:
> Norman Wilson <norman@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

Re: [TUHS] The origin of /home

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 5008 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] The origin of /home

[Steve Nickolas]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3194 bytes --]

On Wed, 10 Oct 2018, Grant Taylor via TUHS wrote:

> On 10/10/2018 08:43 AM, Norman Wilson wrote:
>
>> 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.

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.

Re: [TUHS] The origin of /home

[David Arnold]

[-- Attachment #1.1: Type: text/plain, Size: 1941 bytes --]

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.


[-- Attachment #1.2: Type: text/html, Size: 2696 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [TUHS] The origin of /home

[Doug McIlroy]

> I couldn't find any use of 'home' in the V6 documentation.

$HOME was set by default in v7. It probably dates from the
advent of enviroment variables.

Doug

Re: [TUHS] The origin of /home

[Noel Chiappa]

    > My memory is that the term "home directory" predates /home - perhaps on
    > other OS's such as TOPS-20, but I don't have time to research that.

Well, I looked at the "Introduction to MIT-XX" (a TOPS-20 machine), and it
also used the terms "logged-in directory" (home dir) and "connected directory"
(current dir).

I couldn't find any use of 'home' in the V6 documentation.

I _did_ find "home directory" in the ITS documentation; the oldest doc file I
found it in was dated 5/25/79. If ITS was the source, not sure how it spread -
maybe via EMACS?

       Noel

Re: [TUHS] The origin of /home

[Lars Brinkhoff]

Noel Chiappa writes:
> I _did_ find "home directory" in the ITS documentation; the oldest doc
> file I found it in was dated 5/25/79. If ITS was the source, not sure
> how it spread - maybe via EMACS?

I see "home directory" in an ITS file from 1976 (.TECO.; TECORD 508).

There could be a hint the AI memos, but they are hard to search.

Re: [TUHS] The origin of /home

[Noel Chiappa]

    > From: Jon Forrest

    > Another reason why the home directory part of /usr was made into /home
    > is because after doing so, it was possible to mount /usr read-only, and
    > supply it from a server.

The real issue is that /usr contained stuff which wasn't true 'user data' -
e.g. /usr/bin. The reasons for that must have seemed good at the time it
started, but it was IMO a mistake. (Disgression about partitions, physical
packs, etc elided for now.)

       Noel

[TUHS] The origin of /home

[Cág]

Hi,

The earliest I've found to be in the FHS from '94. Are there any earlier
examples of a home directory being at /home instead of /usr/$(user)? Are
there any current Unix systems that don't use /home by default (except
OSX)? Does anybody here do it intentionally? Also, what was the
rationale of moving the directory to /home?

Thanks!

--
caóc

Re: [TUHS] The origin of /home

[Alec Muffett]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

Opinion, predating that era: I believe that the driver for /home was
automounter, because of the complexity of referencing local and remote
/export/foo/whatever/username paths consistently across a large NFS-enabled
university deployment with many different platforms and individual systems.


On Thu, 27 Sep 2018, 13:11 Cág, <ca6c@bitmessage.ch> wrote:

> Hi,
>
> The earliest I've found to be in the FHS from '94. Are there any earlier
> examples of a home directory being at /home instead of /usr/$(user)? Are
> there any current Unix systems that don't use /home by default (except
> OSX)? Does anybody here do it intentionally? Also, what was the
> rationale of moving the directory to /home?
>
> Thanks!
>
> --
> caóc
>
>

[-- Attachment #2: Type: text/html, Size: 1049 bytes --]

Re: [TUHS] The origin of /home

[Donald ODona]

At 27 Sep 2018 12:11:15 +0000 (+00:00) from "Cág" <ca6c@bitmessage.ch>:
> Hi,
>
Also, what was the
> rationale of moving the directory to /home?
originally /usr, placed on a separate disk, was what became /home much later. Then disk space of / was running out and more an more applications and libs were moved to the /usr device.
Much later in the 80ths much more disk space was available and a separate /home was created. Exacly when I don't know, but there was no /home in Ed. 7 but System V release 3 had it already.

Re: [TUHS] The origin of /home

[John P. Linderman]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

More opinion, unencumbered by facts. /usr contained many sudirectories,
like /usr/bin and /usr/lib, that were essential to an operational OS. Home
directories, on the other hand, persisted unchanged when new releases of an
OS were installed. Some of us had symlinks from /usr into a separate file
system to make the distinction easier to maintain across releases.

On Thu, Sep 27, 2018 at 8:58 AM, Donald ODona <mutiny.mutiny@india.com>
wrote:

> At 27 Sep 2018 12:11:15 +0000 (+00:00) from "Cág" <ca6c@bitmessage.ch>:
> > Hi,
> >
> Also, what was the
> > rationale of moving the directory to /home?
> originally /usr, placed on a separate disk, was what became /home much
> later. Then disk space of / was running out and more an more applications
> and libs were moved to the /usr device.
> Much later in the 80ths much more disk space was available and a separate
> /home was created. Exacly when I don't know, but there was no /home in Ed.
> 7 but System V release 3 had it already.
>

[-- Attachment #2: Type: text/html, Size: 1447 bytes --]

Re: [TUHS] The origin of /home

[Ronald Natalie]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

 Symlinks?   Surely  you jest.   Not in Version 7 or System V.

The idea was to keep root small for convenience in various stages of setup.   /usr was indeed intended to be a separate disk.   If you look at the early distributions like V7, you’ll find the /usr image was a separate tape file.

> On Sep 27, 2018, at 9:54 AM, John P. Linderman <jpl.jpl@gmail.com> wrote:
> 
> More opinion, unencumbered by facts. /usr contained many sudirectories, like /usr/bin and /usr/lib, that were essential to an operational OS. Home directories, on the other hand, persisted unchanged when new releases of an OS were installed. Some of us had symlinks from /usr into a separate file system to make the distinction easier to maintain across releases.
> 
> On Thu, Sep 27, 2018 at 8:58 AM, Donald ODona <mutiny.mutiny@india.com <mailto:mutiny.mutiny@india.com>> wrote:
> At 27 Sep 2018 12:11:15 +0000 (+00:00) from "Cág" <ca6c@bitmessage.ch <mailto:ca6c@bitmessage.ch>>:
> > Hi,
> >
> Also, what was the
> > rationale of moving the directory to /home?
> originally /usr, placed on a separate disk, was what became /home much later. Then disk space of / was running out and more an more applications and libs were moved to the /usr device.
> Much later in the 80ths much more disk space was available and a separate /home was created. Exacly when I don't know, but there was no /home in Ed. 7 but System V release 3 had it already.
> 


[-- Attachment #2: Type: text/html, Size: 2438 bytes --]

Re: [TUHS] The origin of /home

[Jon Forrest]

Another reason why the home directory part of /usr was made into
/home is because after doing so, it was possible to mount /usr
read-only, and supply it from a server. This was the so-called
"dataless" method. I wrote a short email message summarizing
what we were doing with this in UC Berkeley Comp. Sci., and mentioning
a paper I had written describing how to create a "dataless"
environment for DEC's OSF1 operating system (see
http://beowulf.org/pipermail/beowulf/2008-July/022210.html).

Jon Forrest

Re: [TUHS] The origin of /home

[Arrigo Triulzi]

> On 27 Sep 2018, at 16:18, Jon Forrest <nobozo@gmail.com> wrote:
> Another reason why the home directory part of /usr was made into
> /home is because after doing so, it was possible to mount /usr
> read-only, and supply it from a server. This was the so-called
> "dataless" method. I wrote a short email message summarizing
> what we were doing with this in UC Berkeley Comp. Sci., and mentioning
> a paper I had written describing how to create a "dataless"
> environment for DEC's OSF1 operating system (see
> http://beowulf.org/pipermail/beowulf/2008-July/022210.html).

Not to be pedantic but the OSF/1 “dataless” trick is from 1993 in Jon Forrest’s writeup:

https://groups.google.com/d/msg/comp.unix.osf.osf1/-s1xW80zXPE/OGENDhH2Sc0J

As one of the three people figuring out what DEC had told us was impossible I’m pretty sure we were the first - our DEC 3000/400s with OSF/1 T1.0 did not have enough disk space so we struggled to get our network operational serving /usr and /home from the “big” DEC 3000/600 which had two disks (one of which was /home).

Cheers,

Arrigo

Re: [TUHS] The origin of /home

[Jon Forrest]

On 9/27/2018 7:28 AM, Arrigo Triulzi wrote:

> Not to be pedantic but the OSF/1 “dataless” trick is from 1993 in Jon
> Forrest’s writeup:

Right, and I am that Jon Forrest

> https://groups.google.com/d/msg/comp.unix.osf.osf1/-s1xW80zXPE/OGENDhH2Sc0J
>
>  As one of the three people figuring out what DEC had told us was
> impossible I’m pretty sure we were the first - our DEC 3000/400s with
> OSF/1 T1.0 did not have enough disk space so we struggled to get our
> network operational serving /usr and /home from the “big” DEC
> 3000/600 which had two disks (one of which was /home).

It's been a while, but what I remember is that DEC actually published
their own method for doing this but it was surprisingly cumbersome.
What I described was incredibly simple but effective. I ran many
Alphas this way with no problems at all.

Jon

Re: [TUHS] The origin of /home

[Arrigo Triulzi]

On 27 Sep 2018, at 17:36, Jon Forrest <nobozo@gmail.com> wrote:
> Right, and I am that Jon Forrest

Well, made a fool of myself there!

> It's been a while, but what I remember is that DEC actually published
> their own method for doing this but it was surprisingly cumbersome.
> What I described was incredibly simple but effective. I ran many
> Alphas this way with no problems at all.

On OSF/1 T1.0, which is what we got shipped with our first Alphas, we were categorically told by REO that we were on our own. At the time there were four Alphas in the UK: three were ours and one was at REO running OpenVMS in the morning and OSF/1 in the afternoon (or vice-versa) and we spent a long weekend napping on the machine room floor and on caffeine trying to figure out how to get /usr mounted despite the SIA startup script as we had no choice and the cluster needed to be up as it had cost a small fortune.

The later DEC solution I recall requiring more disk space on the clients, which we didn’t have, but I’m sure that later ships with sufficient disk space had less issues.

Another weekend was spent getting TeX and LaTeX running with ghostscript MX’d from the Ultrix MIPS binary as we just couldn’t get it to compile. That it even worked using MX remains one of the most beautiful surprises of that install.

Arrigo 

Re: [TUHS] The origin of /home

[Jon Forrest]

On 9/27/2018 8:54 AM, Arrigo Triulzi wrote:
> On 27 Sep 2018, at 17:36, Jon Forrest <nobozo@gmail.com> wrote:
>> Right, and I am that Jon Forrest
> 
> Well, made a fool of myself there!

That's OK. I do things like that at least once a day.

> On OSF/1 T1.0, which is what we got shipped with our first Alphas, we were
> categorically told by REO that we were on our own.

Those were the days when DEC would tell you all kinds of things.
I remember in the late 80s they told me that TCP/IP wasn't going
to catch on, and that I should stick with DecNet.

> The later DEC solution I recall requiring more disk space on the clients,
> which we didn’t have, but I’m sure that later ships with sufficient disk space had less issues.

I actually started my dataless design back when we were running Ultrix.
It worked fine there too, although back then 10Mbs networking was common
so it wasn't super speedy. Of course, neither were the workstations.

The document I quoted also described how the CS department used
an Auspex file server to serve what we called the "Software Warehouse",
which was a collection of open source software that we built
for all the popular architectures then.

Jon

Re: [TUHS] The origin of /home

[Theodore Y. Ts'o]

On Thu, Sep 27, 2018 at 11:49:02AM -0700, Jon Forrest wrote:
> 
> I actually started my dataless design back when we were running Ultrix.
> It worked fine there too, although back then 10Mbs networking was common
> so it wasn't super speedy. Of course, neither were the workstations.

MIT Project Athena had a dataless design in the late 1980's.  For
read-only remote file systems, Athena developed a Remote Virtual Disk
(RVD) which was intergrated into BSD 4.3.  RVD was a networked block
device, since for read-only file systems it had better scaling
properties than NFS.

The Athena technical plan talks about it in a fair amount of detail.

	http://web.mit.edu/Saltzer/www/publications/atp.html

By 1988 or so we had hundreds of workstations all over MIT that had
its system softare deliviered via RVD, and for which no data would be
stored on the public workstations, which were managed using the
"cattle" metaphor.  If a system wasn't working correctly, a
workstation could be TFTP booted and the base software could be
reinstalled automatically, and the reinstall was fast because the only
files that had to be installed on the local disk was essentially
enough for the system to come up on the network and to mount the RVD.

       	       	      	      	    - Ted

Re: [TUHS] The origin of /home

[Lyndon Nerenberg]

Surely /home come out of the automounter convention to point
/home/<foo> at whichever /export/<host>/<filesystem>/<homedir>
directory YP said was the logged in users home directory?  This all
originates from the days of diskless/dataless Sun workstations.

--lyndon

Re: [TUHS] The origin of /home

[Dave Horsfall]

I'm quite amused by this thread.

Before I started using /home (Slowaris had yet to appear), I used /u/* 
instead (I didn't want to pollute /usr with home directories).

-- Dave

Re: [TUHS] The origin of /home

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]

On 10/09/2018 08:38 PM, Dave Horsfall wrote:
> I'm quite amused by this thread.

As am I.

> Before I started using /home (Slowaris had yet to appear), I used /u/* 
> instead (I didn't want to pollute /usr with home directories).

@thatcks on Twitter indicates that they still use /u/$USER on their systems.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] The origin of /home

[Donald ODona]

At 27 Sep 2018 12:59:50 +0000 (+00:00) from Donald ODona <mutiny.mutiny@india.com>:
to the /usr device.
> Much later in the 80ths much more disk space was available and a separate /home was created. Exacly when I don't know, but there was no /home in Ed. 7 but System V release 3 had it already.

4.3 BSD had it, as I found out, after login in a few sconds ago. 4.3BSD was released in June 1986. Thus the /home appeared in between 1979 (Ed 7) and 1986.

Re: [TUHS] The origin of /home

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]

On Thu, Sep 27, 2018 at 8:11 AM Cág <ca6c@bitmessage.ch> wrote:

> The earliest I've found to be in the FHS from '94. Are there any earlier
> examples of a home directory being at /home instead of /usr/$(user)? Are
> there any current Unix systems that don't use /home by default (except
> OSX)? Does anybody here do it intentionally? Also, what was the
> rationale of moving the directory to /home?
>

Naming on Unix (and derived systems) is one of those things that has always
had different schools of thought applied to it.

As has been pointed out, the original place for what we now refer to as
"home" directories was /usr, though this may not be entirely accurate: it's
my belief that PDP-7 Unix had separate directories for each user, but I
don't think these were nested under a common 'usr' directory. Someone
please correct me if I'm wrong. The original impetus for moving things
around was surely space considerations on early disk devices: Not only was
space limited, but filesystems couldn't span devices (in the /dev sense)
and often *partition* sizes on a single volume were fixed by the driver for
the underlying storage device. In such a rigidly defined world, varying
conventions would necessary evolve to work around the inevitable
limitations, particular in sites with lots of users like universities and
production-focused corporate groups, including the degeneration of `/usr`
as purely holding user directories. One can easily imagine the
conversation: "we're out of room on the root filesystem and I can't install
this new program in /bin..." "Hmm. Well, we've got space in /usr: create
/usr/bin and we'll fix up the difference in the shell by incorporating some
notion of a search path for binaries." Similarly with lib, man, and all the
rest of it. It's interesting that now /usr is most often devoid of user
data; the intent behind the name seems to be justified after the fact by
asserting that it contains programs, libraries and other data of interest
to users (as opposed to administrators).

That explains why other things starting encroaching and eventually took
over on /usr, but I think the provenance of "/home" specifically relates to
an etymological question. At some point, the "user's directory" as  denoted
in /etc/passwd became known as the "home directory." If that was common
vernacular by the time that `/home` came around as a convention, then it
seems a logical name stemming from that usage. The more intriguing
possibility from the antiquarian point of view is whether someone coined
"/home" and then THAT led to the rise of the "home directory" nomenclature.
man(5) on 7th Edition calls that field the user's "initial working
directory." The first time I see it called "home directory" in my cursory
search is in 4.3 Reno.

I intentionally eschew /home on a few systems. 4.4BSD had a convention of
placing user home directories in /a, /b, etc. 4.4BSD-Lite also had
/var/users. Both of which I occasionally use.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 3530 bytes --]

Re: [TUHS] The origin of /home

[arnold]

Dan Cross <crossd@gmail.com> wrote:

> At some point, the "user's directory" as  denoted in /etc/passwd became
> known as the "home directory." If that was common vernacular by the time
> that `/home` came around as a convention, then it seems a logical name
> stemming from that usage.

It most definitely was common usage before /home came along.

As I recall it, in the System V Release 4 time frame, AT&T, Sun, DEC and
UCB agreed on the division of things into /home, /usr, and /var, with
the impetus being that /usr could be mounted read-only from a single file
server (saving many copies of the same files), /home mounted read-write
(or automounted) and /var holding things that were peculiar to each
system but read-write, such as log files and temporary files.

Diskless workstations, or workstations with very small disks for
holding the root filesystem only, were very popular at the time.

Arnold

Re: [TUHS] The origin of /home

[Cág]

Thanks for such an interesting and informative answer, Mr. Cross.

Dan Cross wrote:

> 4.4BSD had a convention of placing user home directories in /a, /b,
> etc.

Do I understand it correctly: they were in just "slash a/b/etc" in
root? Not /home/a or /usr/a but just /a?

> 4.4BSD-Lite also had /var/users.

Was it /var/users/$(user) or /var/$(user)?


To everyone: thanks for all the answers, it's always interesting to read
such things. I try not to miss a single mail after signing up for the
list.

This question actually came up long ago when I first tried Plan 9,
which, as you know, has the directory in /usr, and it was released in
90s, after 4.4BSD. Of course, Plan 9 is(not) (Research) Unix, and
doesn't have a root user, and apparently has a different rationale
behind it -- if I'm not mistaken, it has bin, lib and something else
there, none of which are usually present in /home these days, even bin
is usually in /usr/local.

--
caóc

Re: [TUHS] The origin of /home

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

On Thu, Sep 27, 2018 at 4:43 PM Cág <ca6c@bitmessage.ch> wrote:

>
> Thanks for such an interesting and informative answer, Mr. Cross.
>

I'm happy to write it!

Dan Cross wrote:
>
> > 4.4BSD had a convention of placing user home directories in /a, /b,
> > etc.
>
> Do I understand it correctly: they were in just "slash a/b/etc" in
> root? Not /home/a or /usr/a but just /a?
>

Correct. I believe the idea was to program the automounter to make these
appear in some directory like /home, but the directories themselves lived
in /a, /b, etc. Presumably these were mount points for separate
disk-resident filesystems.

> 4.4BSD-Lite also had /var/users.
>
> Was it /var/users/$(user) or /var/$(user)?
>

/var/users/$user. For example, 4.4BSD-Lite1 contains entries for Ken and
Dennis in /etc/master.passwd:

dmr:*:10:31::0:0:Dennis Ritchie:/var/users/guest/dmr:
ken:*:11:31::0:0:& Thompson:/var/users/guest/ken:

To everyone: thanks for all the answers, it's always interesting to read
> such things. I try not to miss a single mail after signing up for the
> list.
>
> This question actually came up long ago when I first tried Plan 9,
> which, as you know, has the directory in /usr, and it was released in
> 90s, after 4.4BSD. Of course, Plan 9 is(not) (Research) Unix, and
> doesn't have a root user, and apparently has a different rationale
> behind it -- if I'm not mistaken, it has bin, lib and something else
> there, none of which are usually present in /home these days, even bin
> is usually in /usr/local.
>

Plan 9 represented an opportunity to do things over. Many of us rather
liked it and thought it was a worthy successor to Unix, but it never caught
on in the larger world and now, in the bathed in the cold light of history,
some of its faults are evident.

The issue with bin/ is that it's in several places. In plan9, these are all
bound onto /bin, which is nice.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 2944 bytes --]

Re: [TUHS] The origin of /home

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 5398 bytes --]

I wish I could remember exactly everything happened, but I cannot say I
do.    Dan Cross, Don and Noel have all said things that line up with what
I remember.   I’m actually thinking the /home came out of a set of
discussions that occurred before what would eventually be called UNIX
International.



As, Noel says, I do remember using the term ‘home directory’ as a student,
so it is likely that was a term being used either by the old PDP-10 or IBM
shops; but like Noel, I cannot pin the term down either.



Don noted that the /home does not come to the BSD strain until 1986, which
also makes sense; because one of the goals of 4.3BSD was to try to make BSD
a little less divergent from the other UNIX paths, and one of the things
Keith did was to start to made an effort to try use some of the same
conventions the industry (Sun and AT&T in particular) were using.



Dan Cross made the most important note and that is that in the early days
the size a disk was quite small.  UNIX Sixth and Seventh edition often ran
on systems that 2 or 3 RK05 drives of 2.5M each [
https://en.wikipedia.org/wiki/RK05] and as Dan point out, there were limits
to the what got put in the what file system.   Simply the guiding principle
at that time was that you stored in the root filesystem; just enough to the
boot the system, pushed everything else to /usr and then used UNIX
mount/name space splicing/path mechanisms to make a uniform set of paths.



BTW: A thing to remember is that symbolic links are not a wide spread when
all of this was going on in the early 1980s, so they really did not have a
lot to do with the /home idea.  In the case of symbolic links, Dennis had
created them as part of V8, but 4.1BSD and System III (PWB 3.0) did not
have the idea yet.   BSD 4.2 would later get them as part of FFS, but I
don’t remember if 4.1c did (the kernel source was not in Warren’s browsable
archive so I could not check).   Dennis had showed them to me on a visit, I
thought they were cool and useful, and put them in Masscomp’s RTU (which
was a System III/4.1 mash up) and then created CDL’s shortly thereafter
which we used for what later Pyramid called Universes (we called it modes
originally but started calling it universes also because it sounded
cooler).    Sun picked up symlinks when they went to the 4.2 kernel and BSD
FFS.



The other missing item was quotas.   The universities in particular needed
quotas, which is one of the reasons why Joy added it to 4.2, as it was a
requested feature by the DARPA community. Before 4.2, people used the
partition size within the disk as a way to have some sort of quotas.



So what happened?



The factiod no one has brought up so far is what would become the
/usr/group standards committee (later Unix International (UI) and before
that was the work Heinz Lycklama and Peter Weiner were doing at Interactive
Systems Corp (ISC).  Heinz wanted an industry wide ABI and was pretty vocal
about it.  He felt the ISVs would never take UNIX seriously if there were
not ‘one true >>binary<< system’ that they compiled too.   The /usr/group
API work got started from that and was the compromise, a programming
interface, not an binary one.   But during the discussions that led up to
the standards committee was a series of meetings originally at USENIX ATC,
where we began to talk about the naming conventions.  They were trying to
agree what needs to be in /bin, /usr/bin, /lib, /usr/lib etc…  and to make
them more 'readonly-ish' primarily so that programs that went amok, did the
least amount of damage.     This was also where the idea of /usr/opt and
/var were born.  /usr/local was a UCB-ism, but people used it for stuff the
built themselves.    Most installed systems /usr1 /usr2 … where the actual
user files were stored.  The commercial folks wanted it more like other
systems were there were some sorts of fences around things.



But …it was basically agreed by the commercial side, that if there ever
were going to be any hope for the ISVs to be able to ship a binary, each
ISV needed her/his own spot.  The idea for them was
/usr/opt/hp,  /usr/opt/intel, /usr/opt/msft and then under that the usual
bin, etc, include, lib, …  Equally /var was deal with things like logs
which were being to show up (the printer and shell accounting were first),
but that way ISVs and random programs did not step on each other.    I
think HP might have actuallybeen  the first of the vendors to start to ship
using that convention, but USL did pick it up by the time of System
V. Similarly, at some point the /usr1, /usr2 etc  … switched to /home
/home1 /home2 etc…     I do remember that there HP guys where pretty vocal
in the arguments when it all went down.





There was (should be) an email/netnews article kicking around with the name
something like ‘standardized UNIX file tree’ or some such.   I would think
this was about 1984 or 1985 time frame.   This email/article was part of
the model that Keith used for 4.3BSD later on; but it is also where my
memory gets hazy and I lost those notebooks in the flood.



I cannot swear by it, but I do seem to think I remember that /home was one
of the directories that came out of that discussion.  The timing is
certainly right, as is the reasoning.


ᐧ

[-- Attachment #2: Type: text/html, Size: 9470 bytes --]

Re: [TUHS] The origin of /home

[Henry Bent]

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

On Thu, 27 Sep 2018 at 18:06, Clem Cole <clemc@ccc.com> wrote:

>
> BTW: A thing to remember is that symbolic links are not a wide spread when
> all of this was going on in the early 1980s, so they really did not have a
> lot to do with the /home idea.  In the case of symbolic links, Dennis had
> created them as part of V8, but 4.1BSD and System III (PWB 3.0) did not
> have the idea yet.   BSD 4.2 would later get them as part of FFS, but I
> don’t remember if 4.1c did (the kernel source was not in Warren’s browsable
> archive so I could not check).
>

4.1c did indeed have symlinks; the  "4.1c.1" source on the CSRG CD set has
the code for them.  lib/libc/sys/symlink.c revision 4.1 is dated 82/12/04,
so that's about the time they went in.

-Henry

> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 1670 bytes --]

Re: [TUHS] The origin of /home

[Tony Finch]

Dan Cross <crossd@gmail.com> wrote:
>
> I intentionally eschew /home on a few systems. 4.4BSD had a convention of
> placing user home directories in /a, /b, etc. 4.4BSD-Lite also had
> /var/users. Both of which I occasionally use.

The /a convention seems to go back quite a long way. I was looking through
old password files to see where the home directories were, e.g.

https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/etc/passwd

has a lot of /a/guest whereas 4.3BSD has /usr/guest

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
safeguard the balance of nature and the environment

Re: [TUHS] The origin of /home

[Jeremy C. Reed]

On Fri, 28 Sep 2018, Tony Finch wrote:

> > I intentionally eschew /home on a few systems. 4.4BSD had a convention of
> > placing user home directories in /a, /b, etc. 4.4BSD-Lite also had
> > /var/users. Both of which I occasionally use.
> 
> The /a convention seems to go back quite a long way. I was looking through
> old password files to see where the home directories were, e.g.
> 
> https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/etc/passwd
> 
> has a lot of /a/guest whereas 4.3BSD has /usr/guest

And the 4.3BSD docs show the /a, /b, /c
https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/man/man8/adduser.8

  Traditionally, user files live on a file system different from /usr.
  Typically the user file systems are mounted on a directories in the
  root named sequentially starting from from the beginning of the
  alphabet, eg /a, /b, /c, etc.  On each such file system there are
  subdirectories there for each group of users, i.e.: ``/a/staff'' and
  ``/b/prof''.  This is not strictly necessary but keeps the number of
  files in the top level directories reasonably small.

By the way, Berkeley early on (at time of the first Berkeley tape) had a 
separate /etc/htmp database to list user's home (or alternate home) 
directories (so didn't have to search "large password files" which were 
"unreasonably slow") and terminal type (part of the precursor to 
termcap). The home's then were like /mnt/staff/mosher, 
/mnt/quals/katseff, /mnt/chuck/, /mnt/jeff. Joy's early 2BSD csh docs 
show /mnt/bill and /usr/ken as "home directory" examples. And 3BSD's 
adduser docs show:

  Traditionally, user files live on the file system /mnt and there are
  subdirectories there for each group of users, i.e.: 
  ``/mnt/staff'' and ``/mnt/prof''.

This got changed for 4BSD (4.0BSD):

  Traditionally, user files live on a file system which has the machines 
  single letter net(1) address as the first of two characters.  Thus on 
  the Berkeley CS Department VAX, whose Berknet address is ``csvax'' 
  abbreviated ``v'' the user file systems are mounted on ``/va'',
  ``/vb'', etc.  On each such filesystem there are subdirectories 
  there for each group of users, i.e.: ``/va/staff'' and ``/vb/prof''.  
  This is not strictly necessary but keeps the number of files in the 
  top level directories reasonably small.

(where net(1) is Schmidt's Berkeley Network)

As for 4.3BSD the only reference I find of /home is from the aardvark 
game from Mike Urban of UCLA (/home/urban). (That is the earliest 
reference of a directory called /home/ I found.)

Re: [TUHS] The origin of /home

[Nemo]

On 27/09/2018, Cág <ca6c@bitmessage.ch> wrote (in part):
> Hi,
>
> The earliest I've found to be in the FHS from '94. Are there any earlier
> examples of a home directory being at /home instead of /usr/$(user)? Are
> there any current Unix systems that don't use /home by default (except
> OSX)?

This is a bit late but Solaris uses /export/home by default.

N.

> Does anybody here do it intentionally? Also, what was the
> rationale of moving the directory to /home?
>
> Thanks!
>
> --
> caóc

Re: [TUHS] The origin of /home

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

On 09/28/2018 10:02 AM, Nemo wrote:
> This is a bit late but Solaris uses /export/home by default.

I disagree.

Or at least not as such.

Many Solaris systems I've used have put homes in /export/home.  But they 
are /NOT/ supposed to be used /directly/ as the home directory.  The 
intention that they would be NFS exports and that said export would be 
auto mounted to /home.

The /export/home is really the /export/ point, /not/ the location that 
is supposed to be used.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] The origin of /home

[Arthur Krewat]

On 9/28/2018 12:15 PM, Grant Taylor via TUHS wrote:
> On 09/28/2018 10:02 AM, Nemo wrote:
>> This is a bit late but Solaris uses /export/home by default.
>
> I disagree.
>
> Or at least not as such.
>
> Many Solaris systems I've used have put homes in /export/home. But 
> they are /NOT/ supposed to be used /directly/ as the home directory.  
> The intention that they would be NFS exports and that said export 
> would be auto mounted to /home.
>
> The /export/home is really the /export/ point, /not/ the location that 
> is supposed to be used.
>
>
Solaris 10 u10:

beef / # useradd asdf
beef / # grep asdf /etc/passwd
asdf:x:504:1::/home/asdf:/bin/sh

Solaris 11.3:
medusa# useradd asdf
medusa# grep asdf /etc/passwd
asdf:x:65540:10::/export/home/asdf:/usr/bin/bash

When creating a user on Solaris 11, because it requires you to install a 
regular user because you can't login directly as root, it creates the 
home directory in /export/home

Interesting. To be honest, I did not expect Solaris 10 to use /home as 
the default.

Re: [TUHS] The origin of /home

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

On 09/28/2018 11:28 AM, Arthur Krewat wrote:
> Solaris 10 u10:
> 
> beef / # useradd asdf
> beef / # grep asdf /etc/passwd
> asdf:x:504:1::/home/asdf:/bin/sh
> 
> Solaris 11.3:
> medusa# useradd asdf
> medusa# grep asdf /etc/passwd
> asdf:x:65540:10::/export/home/asdf:/usr/bin/bash
> 
> When creating a user on Solaris 11, because it requires you to install a 
> regular user because you can't login directly as root, it creates the 
> home directory in /export/home
> 
> Interesting. To be honest, I did not expect Solaris 10 to use /home as 
> the default.

Strange.

I'd have to play with things to refine my opinion.

I've long thought that Solaris was a moving target and did things 
inconsistently.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] The origin of /home

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

On 09/28/2018 11:28 AM, Arthur Krewat wrote:
> Solaris 10 u10:
> Solaris 11.3:

Were those fresh installs to test things for this discussion?

Or were they existing installs that you checked?

If they were fresh installs, were they larger kitchen sink type 
installs?  Or minimal installs?



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] The origin of /home

[Arthur Krewat]

On 9/28/2018 3:47 PM, Grant Taylor via TUHS wrote:
> On 09/28/2018 11:28 AM, Arthur Krewat wrote:
>> Solaris 10 u10:
>> Solaris 11.3:
>
> Were those fresh installs to test things for this discussion?
>
> Or were they existing installs that you checked?
>
> If they were fresh installs, were they larger kitchen sink type 
> installs?  Or minimal installs?

One is my home Solaris server 11.3, the other is a customer's Solaris 10 
install from way back when.

Nothing changes behavior like that from version-to-version of Solaris. 
Solaris 11 as a whole was a big jump in terms of GNU user-land stuff, 
etc, so that behavior was changed, again, probably because as of 11, you 
had to create a regular user during the install.

I just checked Solaris 7 and 8 (x86), which are both "vanilla" installs 
I did to a VMware guest. On both, useradd used /home - an 11.2 guest 
used /export/home

Re: [TUHS] The origin of /home

[Nemo]

On 28/09/2018, Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
> On 09/28/2018 10:02 AM, Nemo wrote:
>> This is a bit late but Solaris uses /export/home by default.
>
> I disagree.
>
> Or at least not as such.
>
> Many Solaris systems I've used have put homes in /export/home.  But they
> are /NOT/ supposed to be used /directly/ as the home directory.  The
> intention that they would be NFS exports and that said export would be
> auto mounted to /home.
>
> The /export/home is really the /export/ point, /not/ the location that
> is supposed to be used.

From https://docs.oracle.com/cd/E26505_01/html/E29492/userconcept-36940.html#userconcept-6
:

A home directory can be located either on the user's local system or
on a remote file server. In either case, by convention the home
directory should be created as /export/home/username. For a large
site, you should store home directories on a server. Use a separate
file system for each /export/homen directory to facilitate backing up
and restoring home directories. For example, /export/home1,
/export/home2.

Regardless of where their home directory is located, users usually
access their home directories through a mount point named
/home/username. When AutoFS is used to mount home directories, you are
not permitted to create any directories under the /home mount point on
any system. The system recognizes the special status of /home when
AutoFS is active.


> --
> Grant. . . .
> unix || die

Re: [TUHS] The origin of /home

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

On 09/28/2018 02:00 PM, Nemo wrote:
> From 
> https://docs.oracle.com/cd/E26505_01/html/E29492/userconcept-36940.html#userconcept-6 
> :
> 
> A home directory can be located either on the user's local system or on 
> a remote file server. In either case, by convention the home directory 
> should be created as /export/home/username. For a large site, you should 
> store home directories on a server. Use a separate file system for each 
> /export/homen directory to facilitate backing up and restoring home 
> directories. For example, /export/home1, /export/home2.
> 
> Regardless of where their home directory is located, users usually access 
> their home directories through a mount point named /home/username. When 
> AutoFS is used to mount home directories, you are not permitted to create 
> any directories under the /home mount point on any system. The system 
> recognizes the special status of /home when AutoFS is active.

Yep, that jives with what I thought.

"… by convention the home directory should be created as 
/export/home/username … users usually access their home directories 
through a mount point named /home/username …"

Yep, that jives with my experience and my understanding.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]