From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31169 invoked from network); 21 Jul 2020 18:34:39 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 21 Jul 2020 18:34:39 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 21DFA9C8F9; Wed, 22 Jul 2020 04:34:38 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 082A69C8DD; Wed, 22 Jul 2020 04:33:40 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="BSsApf6f"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 645E69C8DD; Wed, 22 Jul 2020 04:33:38 +1000 (AEST) Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by minnie.tuhs.org (Postfix) with ESMTPS id 2A28993D09 for ; Wed, 22 Jul 2020 04:33:37 +1000 (AEST) Received: by mail-qk1-f179.google.com with SMTP id d14so8632389qke.13 for ; Tue, 21 Jul 2020 11:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dEkkzkAOsRSgJ0nfSUlMTSqgrNF6fx8tOGFtqwTtA8E=; b=BSsApf6fSWsCDeFqm0grA7pbO9M9VBKmVJOhKIkFRvJmT0C8xwJKZTGhU21eSxbH7M 8W3r6ZUyLt2Wyx6KA4Dgo7U9GGOrICzs9ymF7yGyVdj06FDXeAdZITIkfo1vyaHBgjVW t29B/9W1Fv5iUU2QYQOSSnTGGM893aBilS09Iv1X+HHKvS43MFhXCU7bQBIFTV75MQ2/ Kg/jSU0yKBysfjChbSk+oFAq075ED7QlJtWflxMq1Bu2Quwx3OgYpIhQP/CkIoLvGqMA vusFvc1lJzXzLZv2qJk5TDydC7WcAp76zAQIoFIL6dFk55xNZbjtjuQoB+ib8yUY/kp1 S4yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dEkkzkAOsRSgJ0nfSUlMTSqgrNF6fx8tOGFtqwTtA8E=; b=CqOfQGAeo/ML3yvshDXF2+DCCumHlCzhBXxUlvd6g1GBFv68CE2KU6ti5uzSAtv30G UDPXC/C3qI6mV6AP2pb89wD+tFehJWqALNywXONAJzUrcIpGdJjkXXRiS3zfdcDKAo6l JR+zF1UPl5YofV/8jVGVu1/JMtTuvI9BLlM1vrbFLYkEctK1wIbdOaeuMSm80l62ZPWv I1n89WEd4bdaARpHZ7VZOgsWyYLO81T2uKBtfdFrwTRzNZMbrUG5g3uNgoAv4RJcmMl7 UoACaXYrdomsyNSDzcaTn750JqulsZY+jj2Mpm2/sESVAgfDyEY3urrqRHI+fhqOvB// 4cPA== X-Gm-Message-State: AOAM530PvQT+f/S8EfqI89aXaU/9yCA9BKrRxULJ7R7tSL1pyLxrotzH 24GCN8+5u5D2EViPeVf55uZqUrFJ5WqcbjSyeciKnBX5 X-Google-Smtp-Source: ABdhPJyKDRYq7M2kyoks8VC/arrgeHIkIlQ7iRFl9b0eimrDFpsEGASd3LpJ01g26mgeAY/8FHEocX/qVRvoHIs1YEw= X-Received: by 2002:a37:4015:: with SMTP id n21mr25658665qka.240.1595356416269; Tue, 21 Jul 2020 11:33:36 -0700 (PDT) MIME-Version: 1.0 References: <862d8a34-456d-33c1-7ef0-58c6e8089de9@tnetconsulting.net> <202007211822.06LIMBJ4018831@freefriends.org> In-Reply-To: <202007211822.06LIMBJ4018831@freefriends.org> From: Warner Losh Date: Tue, 21 Jul 2020 12:33:25 -0600 Message-ID: To: Arnold Robbins Content-Type: multipart/alternative; boundary="0000000000007b751e05aaf7dc85" Subject: Re: [TUHS] /bin vs /sbin X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list , Grant Taylor Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000007b751e05aaf7dc85 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 21, 2020 at 12:23 PM wrote: > Grant Taylor via TUHS 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. > > Does anyone have any history of /sbin from other traditional Unixes? > > I'd be quite interested in learning more. > > /sbin and /usr/sbin came into being in the late 80s when Berkeley > and USG were standardizing on file system layouts for diskless > workstations; > Sun and DEC and others were also in on this. > > /sbin specifically was meant to hold the executables meant for use by > root that previously had been in /etc along with config files. > (sbin ==> super-user bin.) > /sbin showed up in 4.3-Reno (1990), but wasn't in 4.3-Tahoe (1988). This predates Linux by a year or so. The changes were due to the filesystem standardization and layout changes prompted by, among other things, diskless workstations as you stated later. Sun's NFS drove a lot of the adaptation in this area since it quickly became the de-facto network file system (though others did exist). > 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. > > This avoided having umpteen zillion copies of the same files > (executables, man pages, libraries, etc.) since they could be mounted > read-only from one or a few servers. At the time, disk space was not > nearly as cheap as it is now. > A big cost savings in having 20 diskless workstations was that you didn't need the 2-4gb of disks for each individual one, but instead could have one copy of the 100MB-200MB of the core OS. When. X started getting libraries out the wazoo with toolkit wars, it saved even more. IIRC, the Sun 3/50's ethernet port was faster than its disk port, so your diskless workstation could be faster than one with a disk (assuming the network wasn't overloaded). >From an era that will be remembered best by "The network is the connector" corruption of a famous marketing slogan... > This is also when /var came into being for log files and such; > again - it was per machine space, so it lived either on a small disk > in the workstation or on a per-client chunk of space on the server > if the client was totally diskless. > All true. Warner --0000000000007b751e05aaf7dc85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
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.=C2=A0 At least in Linux.

Dunno about that.

I'm skeptical as = well.
=C2=A0
> Does anyone have any history of /sbin from other traditional Unixes? <= br> > I'd be quite interested in learning more.

/sbin and /usr/sbin came into being in the late 80s when Berkeley
and USG were standardizing on file system layouts for diskless workstations= ;
Sun and DEC and others were also in on this.

/sbin specifically was meant to hold the executables meant for use by
root that previously had been in /etc along with config files.
(sbin =3D=3D> super-user bin.)

/sbin= showed up in 4.3-Reno (1990), but wasn't in 4.3-Tahoe (1988). This pre= dates Linux by a year or so.=C2=A0 The changes were due to the filesystem s= tandardization and layout changes=C2=A0prompted by, among=C2=A0other things= , diskless workstations as you stated later.=C2=A0 Sun's NFS drove a lo= t of the adaptation in this area since it quickly became the de-facto=C2=A0= network file system (though others did exist).
=C2=A0
The idea was that /etc held things specific to a box, while /bin, /sbin, /usr could be remote mounted from a server.=C2=A0 This is also when /home came into practice as the place to hold home directories.

This avoided having umpteen zillion copies of the same files
(executables, man pages, libraries, etc.) since they could be mounted
read-only from one or a few servers.=C2=A0 At the time, disk space was not<= br> nearly as cheap as it is now.

A big cos= t savings in having 20 diskless workstations was that you didn't need t= he 2-4gb of disks for each individual one, but instead could have one copy = of the 100MB-200MB of the core OS. When. X started getting libraries out th= e wazoo with toolkit wars, it saved even more. IIRC, the Sun 3/50's eth= ernet port was faster than its disk port, so your diskless workstation coul= d be faster than one with a disk (assuming the network wasn't overloade= d).

From an era that will be remembered best by &q= uot;The network is the connector" corruption of a famous marketing slo= gan...
=C2=A0
This is also when /var came into being for log files and such;
again - it was per machine space, so it lived either on a small disk
in the workstation or on a per-client chunk of space on the server
if the client was totally diskless.

All= true.

Warner
--0000000000007b751e05aaf7dc85--