The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Steve Nickolas <usotsuki@buric.co>
To: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] The origin of /home
Date: Wed, 10 Oct 2018 20:22:34 -0400 (EDT)	[thread overview]
Message-ID: <alpine.BSF.2.02.1810102014060.92712@frieza.hoshinet.org> (raw)
In-Reply-To: <190511dd-f19f-7b76-cf8c-2663b81bad22@spamtrap.tnetconsulting.net>

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

  reply	other threads:[~2018-10-11  0:31 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10 14:43 Norman Wilson
2018-10-10 16:26 ` arnold
2018-10-11 19:10   ` Lyndon Nerenberg
2018-10-10 17:08 ` Grant Taylor via TUHS
2018-10-11  0:22   ` Steve Nickolas [this message]
2018-10-11  2:33     ` David Arnold
  -- strict thread matches above, loose matches on Subject: below --
2018-10-10 15:26 Noel Chiappa
2018-10-10 15:45 ` Clem Cole
2018-10-10 15:48   ` David
2018-10-13  6:58   ` Michael Kjörling
2018-10-12  0:15 ` Dave Horsfall
2018-09-28  2:39 Doug McIlroy
2018-09-27 23:14 Noel Chiappa
2018-09-28  5:27 ` Lars Brinkhoff
2018-09-27 15:33 Noel Chiappa
2018-09-27 20:15 ` Dan Cross
2018-09-27 14:31 Noel Chiappa
2018-09-27 12:08 Cág
2018-09-27 12:30 ` Alec Muffett
2018-09-27 12:58 ` Donald ODona
2018-09-27 13:54   ` John P. Linderman
2018-09-27 14:09     ` Ronald Natalie
2018-09-27 14:18     ` Jon Forrest
2018-09-27 14:28       ` Arrigo Triulzi
2018-09-27 15:36         ` Jon Forrest
2018-09-27 15:54           ` Arrigo Triulzi
2018-09-27 18:49             ` Jon Forrest
2018-09-28  0:50               ` Theodore Y. Ts'o
2018-10-01  1:52                 ` Lyndon Nerenberg
2018-10-10  2:38               ` Dave Horsfall
2018-10-10  3:07                 ` Grant Taylor via TUHS
2018-09-27 17:33   ` Donald ODona
2018-09-27 14:47 ` Dan Cross
2018-09-27 17:20   ` arnold
2018-09-27 20:42   ` Cág
2018-09-27 21:07     ` Dan Cross
2018-09-27 22:04       ` Clem Cole
2018-09-27 22:18         ` Henry Bent
2018-09-28  8:33   ` Tony Finch
2018-09-28 18:23     ` Jeremy C. Reed
2018-09-28 16:02 ` Nemo
2018-09-28 16:15   ` Grant Taylor via TUHS
2018-09-28 17:28     ` Arthur Krewat
2018-09-28 19:38       ` Grant Taylor via TUHS
2018-09-28 19:47       ` Grant Taylor via TUHS
2018-09-28 20:30         ` Arthur Krewat
2018-09-28 20:00     ` Nemo
2018-09-28 21:07       ` Grant Taylor via TUHS

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.BSF.2.02.1810102014060.92712@frieza.hoshinet.org \
    --to=usotsuki@buric.co \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).