The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: Warner Losh <imp@bsdimp.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>,
	Grant Taylor <gtaylor@tnetconsulting.net>
Subject: Re: [TUHS] /bin vs /sbin
Date: Tue, 21 Jul 2020 21:16:03 -0400	[thread overview]
Message-ID: <20200722011603.GA1536749@mit.edu> (raw)
In-Reply-To: <CANCZdfpMORPnd1A3ZvRuP_isATpRCB8eBse3ucQYCDxMgwZ7kA@mail.gmail.com>

On Tue, Jul 21, 2020 at 12:33:25PM -0600, Warner Losh wrote:
> On Tue, Jul 21, 2020 at 12:23 PM <arnold@skeeve.com> wrote:
> 
> > Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
> >
> > > To me, this makes it fairly self evident that /sbin was originally for
> > > statically linked binaries.  At least in Linux.
> >
> > Dunno about that.
> 
> I'm skeptical as well.

Yeah, that's definitely not right.  /sbin had been around for
"essential system binaries" long before Linux, and Linux took it from
there.  You can see this from the Linux Filesystem Hierarchy Standard
(earlier named fsstnd, which specified /sbin as "essential system
binaries").  SunOS used that nomenclature and the GNU tools all used
/sbin for that purpose.

The other thing I'd again urge is that you not take HJ Lu's boot/root
disks as being influencial after early 1992.  The Manchester Computing
Centre (MCC) released their "MCC Interim Linux" distribution in
February 1992, and it was so much more convenient than HJ's boot/root
disk that it very quickly swept the field.  MCC was succeeded by TAMU,
Yggdrasil, SLS, Slackware, and by '94 you started seeing names like
Debian, Red Hat, Caldera, SuSE, etc. that would be recognizeable
today.

Xiafs and ext2 date from '93, and so by that point while HJ was still
producing his distribution, most Linux users were using other
distributions.  So whatever choices HJ may have made should not be
considered as being representative of what "Linux" was doing at that
time.

> > The idea was that /etc held things specific to a box, while /bin, /sbin,
> > /usr could be remote mounted from a server.  This is also when /home
> > came into practice as the place to hold home directories.

Well, /bin and /sbin contained those binaries which would be needed so
you could *mount* /usr from a server.  /bin would be in normal users'
PATH; while /sbin would have those binaries which only root could
profitably use.  So /bin/sh, /bin/cat, etc., because users and root
needed to use those binaries.  But /sbin/ifconfig and /sbin/route
because they were primarily only useful if you were root.

I'll also note that MIT Project Athena had architected a scheme using
Remote Virtual Disk (essentially a network block device) so that large
numbers of workstations (mostly MicroVaxen, but also some IBM PC/RT's)
could share /usr mounted over RVD.  This was documented in Professor
Saltzer's Project Athena Technical Plan dated November 1986[1].

[1] http://web.mit.edu/saltzer/www/publications/athenaplan/e.3.1.pdf

Cheers,

						- Ted

  parent reply	other threads:[~2020-07-22  1:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-21 17:55 Grant Taylor via TUHS
2020-07-21 18:15 ` Warner Losh
2020-07-21 22:42   ` David Arnold
2020-07-22  3:33     ` Warner Losh
2020-07-21 18:22 ` arnold
2020-07-21 18:33   ` Warner Losh
2020-07-21 18:43     ` Larry McVoy
2020-07-22  1:16     ` tytso [this message]
2020-07-22  3:27       ` Grant Taylor via TUHS
2020-07-22  3:35         ` Warner Losh
2021-01-27  5:56         ` Greg A. Woods
2021-01-27 19:06           ` Grant Taylor via TUHS
2021-01-27 22:22             ` Warner Losh
2021-01-27 22:35             ` Greg A. Woods
2021-01-28  5:24               ` Grant Taylor via TUHS
2020-07-22  1:44     ` Dan Cross
2020-07-22  2:17       ` Jon Forrest
2020-07-22  2:20         ` Adam Thornton
2020-07-22 13:30           ` Clem Cole
2020-07-22 13:43             ` Richard Salz
2020-07-22  2:27       ` Kurt H Maier
2020-07-21 19:24   ` Clem Cole
2020-07-22 13:39     ` Clem Cole
2021-01-29 23:50   ` Chris Hanson

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=20200722011603.GA1536749@mit.edu \
    --to=tytso@mit.edu \
    --cc=gtaylor@tnetconsulting.net \
    --cc=imp@bsdimp.com \
    --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).