The Unix Heritage Society mailing list
 help / color / Atom feed
* [TUHS] /bin vs /sbin
@ 2020-07-21 17:55 Grant Taylor via TUHS
  2020-07-21 18:15 ` Warner Losh
  2020-07-21 18:22 ` arnold
  0 siblings, 2 replies; 18+ messages in thread
From: Grant Taylor via TUHS @ 2020-07-21 17:55 UTC (permalink / raw)
  To: TUHS


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

One of the things that I've noticed in my explorations into the H.J. Lu 
bootable root disks is that some of them predate the /sbin split in Linux.

One of them has exactly one file in /sbin and other commands spread 
across /bin, /usr/bin, and /etc.  The single file in /sbin is sln.

To me, this makes it fairly self evident that /sbin was originally for 
statically linked binaries.  At least in Linux.

Does anyone have any history of /sbin from other traditional Unixes? 
I'd be quite interested in learning more.

I also noticed that (at least) one of the early versions of the H.J. Lu 
disks had root's home directory in /usr/root.

I seem to recall that one version used an atypical of /users vs /usr. 
Which as I understand it, goes back to the original / vs /usr split in 
Unix, before /home became a thing.



-- 
Grant. . . .
unix || die


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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-21 17:55 [TUHS] /bin vs /sbin Grant Taylor via TUHS
@ 2020-07-21 18:15 ` Warner Losh
  2020-07-21 22:42   ` David Arnold
  2020-07-21 18:22 ` arnold
  1 sibling, 1 reply; 18+ messages in thread
From: Warner Losh @ 2020-07-21 18:15 UTC (permalink / raw)
  To: Grant Taylor; +Cc: TUHS


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

On Tue, Jul 21, 2020 at 11:56 AM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> One of the things that I've noticed in my explorations into the H.J. Lu
> bootable root disks is that some of them predate the /sbin split in Linux.
>
> One of them has exactly one file in /sbin and other commands spread
> across /bin, /usr/bin, and /etc.  The single file in /sbin is sln.
>
> To me, this makes it fairly self evident that /sbin was originally for
> statically linked binaries.  At least in Linux.
>

The root disks date from a time before Linux had shared libraries, I
thought, though I've not looked at HJ Lu's disks in a very, very long time.
And I stopped looking very early on once I had my system bootstrapped... I
do recall going through some pain to bootstrap shared libraries on my
system...


> Does anyone have any history of /sbin from other traditional Unixes?
> I'd be quite interested in learning more.
>

/sbin has never been for static binaries in BSD land. It's always for
system admin binaries that used to live in /etc. They moved to /sbin or
/usr/sbin. This split is due to historically tiny / filesystems and the
need to have just enough binaries on them to check and mount /usr later in
boot. It dates from 4.3-RENO. There were no shared libraries in BSD at the
time (though I think contemporaneous Sun systems had them, which is where
Linux got its first a.out shared library scheme from (kinda, sorta, more
inspired by with some code snatched from gcc/binutils SunOS compat impl,
but with more limitations)).


> I also noticed that (at least) one of the early versions of the H.J. Lu
> disks had root's home directory in /usr/root.
>
> I seem to recall that one version used an atypical of /users vs /usr.
> Which as I understand it, goes back to the original / vs /usr split in
> Unix, before /home became a thing.
>

Early days this was actually quite common. You put your users under
/usr/foo because there weren't many of them, and you'd save a inode lookup
over /usr/users/foo and you didn't need a separate filesystem for your
users. I saw it more on 'small' systems with limited number of users rather
than big, university systems with student populations on them (which needed
a separate filesystem to hold all the user content, even with draconian
quota limits).

Warner


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

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-21 17:55 [TUHS] /bin vs /sbin Grant Taylor via TUHS
  2020-07-21 18:15 ` Warner Losh
@ 2020-07-21 18:22 ` arnold
  2020-07-21 18:33   ` Warner Losh
  2020-07-21 19:24   ` Clem Cole
  1 sibling, 2 replies; 18+ messages in thread
From: arnold @ 2020-07-21 18:22 UTC (permalink / raw)
  To: tuhs, gtaylor

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.

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

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.

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.

HTH,

Arnold

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-21 18:22 ` arnold
@ 2020-07-21 18:33   ` Warner Losh
  2020-07-21 18:43     ` Larry McVoy
                       ` (2 more replies)
  2020-07-21 19:24   ` Clem Cole
  1 sibling, 3 replies; 18+ messages in thread
From: Warner Losh @ 2020-07-21 18:33 UTC (permalink / raw)
  To: Arnold Robbins; +Cc: TUHS main list, Grant Taylor


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

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.


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

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-21 18:33   ` Warner Losh
@ 2020-07-21 18:43     ` Larry McVoy
  2020-07-22  1:16     ` tytso
  2020-07-22  1:44     ` Dan Cross
  2 siblings, 0 replies; 18+ messages in thread
From: Larry McVoy @ 2020-07-21 18:43 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list, Grant Taylor

On Tue, Jul 21, 2020 at 12:33:25PM -0600, Warner Losh wrote:
> 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).

Huh, I'm not sure about the Sun 3/50 ethernet being faster than disk.  It
is possible because diskless 3/50's worked fairly well.  The similar
era Apollos were miserable without disk, I wanted nothing to do with
them but I was fine on a 3/50.  Not great but it worked.  They worked
better with 8MB of ram, 4 was tight.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-21 18:22 ` arnold
  2020-07-21 18:33   ` Warner Losh
@ 2020-07-21 19:24   ` Clem Cole
  2020-07-22 13:39     ` Clem Cole
  1 sibling, 1 reply; 18+ messages in thread
From: Clem Cole @ 2020-07-21 19:24 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: TUHS main list, Grant Taylor


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

On Tue, Jul 21, 2020 at 2:23 PM <arnold@skeeve.com> wrote:

> /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.
>
Right, I was part of that discussion.   Although the real driver
economically was the ISVs were getting really annoyed and pushing for a
cleaner namespace.  *The excuse to compromise was the diskless systems. *   I
think I may even have a memo or two from the discussion in a file cabinet.
 So was IBM and CMU IIRC.  This is before UI or OSF, but was an effort that
was started by the /usr/group folks.  Pretty much a similar group behind
Heinz's Standard's committee and what would eventually become POSIX for
IEEE.

Bostic, Jim Issack, Armando, myself, Shannon, are some of the people I
remember at the early meetings.  But it was still pretty contentious.
 Getting Bostic to come helped a great deal because without CSRG buying in
it was not going to happen.

A few years later (post the first POSIX), UI would fund Locus to do the
SPEC 1170 study, finding 1170 different interfaces in Unix that an ISV had
to deal with to make code portable.  But IIRC, that worked started before
the big UI vs. OSF battle but completed after it started.


>
> /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.)
>
Right... (and a few random strays from /lib if I remember on a couple of
systems)



>
> 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.
>
I offer a slight rewording but agree with intention  ...

{/usr,}/etc was supposed to be databases that customized the node itself
and changed infrequently.
{/usr,}/lib was stuff that was also mostly readonly, but did not need
customization.
{/usr,}/sbin was supposed to be binaries that only an admin needs
{/usr,}/bin was simple binaries needed to boot the system
{/usr,}/opt was supposed to be were ISV's installed things [IMHO: to bad
not enough people use(s) it].
/var was introduced to remove the stuff that was mostly in /usr/spool or
/usr/lib to a place for things that were systems specific and updated.  As
opposed to {/usr,}/tmp which was supposed to be clearly scratch space and
shared.

Using /usr or not, was a concession to UCB left over from the original
Research namespace split leftover from RK05's being 2.5M.

By then user directories were all over the place, often in /u1 /u2 /u3,
etc... And nobody could agree to what to do.  If my memory serves me it was
someone like Pat Parsigiean that suggested a whole new name and /home was
born.

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-21 18:15 ` Warner Losh
@ 2020-07-21 22:42   ` David Arnold
  2020-07-22  3:33     ` Warner Losh
  0 siblings, 1 reply; 18+ messages in thread
From: David Arnold @ 2020-07-21 22:42 UTC (permalink / raw)
  To: TUHS

> On 22 Jul 2020, at 04:15, Warner Losh <imp@bsdimp.com> wrote:

<…>

> The root disks date from a time before Linux had shared libraries, I thought,

IIRC, Linux had two different shared library implementations?  I haven’t looked, and don’t remember the details, but it might have been linked to the switch from a.out to ELF for executables?  IIRC, the pre-ELF shared libs were a hack on the a.out executable format.

Not sure where that fits into the /etc vs. /sbin timeline.  ISTR Linux was somewhat inclined away from the BSD way of doing things (in favour of Solaris/SVR4).




d


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-21 18:33   ` Warner Losh
  2020-07-21 18:43     ` Larry McVoy
@ 2020-07-22  1:16     ` tytso
  2020-07-22  3:27       ` Grant Taylor via TUHS
  2020-07-22  1:44     ` Dan Cross
  2 siblings, 1 reply; 18+ messages in thread
From: tytso @ 2020-07-22  1:16 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list, Grant Taylor

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-21 18:33   ` Warner Losh
  2020-07-21 18:43     ` Larry McVoy
  2020-07-22  1:16     ` tytso
@ 2020-07-22  1:44     ` Dan Cross
  2020-07-22  2:17       ` Jon Forrest
  2020-07-22  2:27       ` Kurt H Maier
  2 siblings, 2 replies; 18+ messages in thread
From: Dan Cross @ 2020-07-22  1:44 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list, Grant Taylor


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

On Tue, Jul 21, 2020 at 2:35 PM Warner Losh <imp@bsdimp.com> wrote:

> On Tue, Jul 21, 2020 at 12:23 PM <arnold@skeeve.com> wrote:
>
>> [snip]
>
> 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).
>

When I first came on the scene, there was a convention that I thought
worked well: the "dataless" node. I have no idea why it was called that; I
suppose because most interesting data was on a centrally managed file
server. Anyway, this was under SunOS 4: the idea was that each node had a
small disk; enough to hold / and swap, but mounted /usr, /usr/local and
user directories from a file server. So commonly used stuff (/bin/csh, ls,
etc etc) all came from a local disk, while everything else was shared.
Disks in workstations were small and basically turn-key so that we didn't
back them up: if one crashed, oh well: throw a new one in it and reimage /.
Swap was transient anyway. A variation was to have an owning-user's home
directory on the node if the local disk was big enough. Sometimes there'd
be a /scratch partition for bulk storage that persisted across reboots
(/tmp came from tmpfs and was a swap-backed RAM disk). We'd back up local
home dirs and maybe the scratch directories.

In our network, we used `amd` and NIS (YP!) to get access to everyone's
home dir on every node.

I rather liked the overall setup; it was nice. It became a deprecated
configuration on the move to Solaris 2.x: a workstation was either diskfull
or diskless. The idea of a compromise between the two extremes went away.

        - Dan C.

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-22  1:44     ` Dan Cross
@ 2020-07-22  2:17       ` Jon Forrest
  2020-07-22  2:20         ` Adam Thornton
  2020-07-22  2:27       ` Kurt H Maier
  1 sibling, 1 reply; 18+ messages in thread
From: Jon Forrest @ 2020-07-22  2:17 UTC (permalink / raw)
  To: tuhs



On 7/21/2020 6:44 PM, Dan Cross wrote:

> When I first came on the scene, there was a convention that I thought 
> worked well: the "dataless" node. I have no idea why it was called that; 

I don't know either, but I implemented a dataless architecture for
all the OSF/1 machines in the CS department at UC Berkeley in the
1990s.  I wrote this up (see

https://groups.google.com/forum/#!msg/comp.unix.osf.osf1/-s1xW80zXPE/OGENDhH2Sc0J

and it eventually made the OSF1 FAQ.

It made a huge difference back when disks were small.
This was done with NFS 3.X which had no local caching.
I've always wondered how a dataless environment would
work on NFS 4.X, which could do local caching.

Jon


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-22  2:17       ` Jon Forrest
@ 2020-07-22  2:20         ` Adam Thornton
  2020-07-22 13:30           ` Clem Cole
  0 siblings, 1 reply; 18+ messages in thread
From: Adam Thornton @ 2020-07-22  2:20 UTC (permalink / raw)
  To: Jon Forrest, The Eunuchs Hysterical Society



> On Jul 21, 2020, at 7:17 PM, Jon Forrest <nobozo@gmail.com> wrote:
> 
> 
> It made a huge difference back when disks were small.
> This was done with NFS 3.X which had no local caching.
> I've always wondered how a dataless environment would
> work on NFS 4.X, which could do local caching.
> 

I miss AFS.

Adam


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-22  1:44     ` Dan Cross
  2020-07-22  2:17       ` Jon Forrest
@ 2020-07-22  2:27       ` Kurt H Maier
  1 sibling, 0 replies; 18+ messages in thread
From: Kurt H Maier @ 2020-07-22  2:27 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list, Grant Taylor

On Tue, Jul 21, 2020 at 09:44:31PM -0400, Dan Cross wrote:
>
> When I first came on the scene, there was a convention that I thought
> worked well: the "dataless" node. I have no idea why it was called that; I
> suppose because most interesting data was on a centrally managed file
> server. Anyway, this was under SunOS 4: the idea was that each node had a
> small disk; enough to hold / and swap, but mounted /usr, /usr/local and  
> user directories from a file server. So commonly used stuff (/bin/csh, ls,
> etc etc) all came from a local disk, while everything else was shared.
> Disks in workstations were small and basically turn-key so that we didn't
> back them up: if one crashed, oh well: throw a new one in it and reimage /.
> Swap was transient anyway. A variation was to have an owning-user's home   
> directory on the node if the local disk was big enough. Sometimes there'd  
> be a /scratch partition for bulk storage that persisted across reboots
> (/tmp came from tmpfs and was a swap-backed RAM disk). We'd back up local  
> home dirs and maybe the scratch directories.
>
> In our network, we used `amd` and NIS (YP!) to get access to everyone's
> home dir on every node.
>
> I rather liked the overall setup; it was nice. It became a deprecated
> configuration on the move to Solaris 2.x: a workstation was either diskfull
> or diskless. The idea of a compromise between the two extremes went away.  
>
>         - Dan C.
        
This is how we run our clusters, but instead of NFS-mounting the system
directories, it fetches a cpio archive and unpacks it into a RAM disk, 
then switches root to that.  Any local disk is mounted as scratch space,
home directories come from an NFS server, and the main working
filesystem is a high-performance distributed filesystem.  It works
exceptionally well at the cost of whatever RAM is used to store the root
filesystem -- these days, negligible.  AFS is available but not much
engaged by our users.  Everything boots over PXE and entirely changing
the purpose and loadout of a computer is one or two commands away.  It's
very pleasant.
       
khm


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-22  1:16     ` tytso
@ 2020-07-22  3:27       ` Grant Taylor via TUHS
  2020-07-22  3:35         ` Warner Losh
  0 siblings, 1 reply; 18+ messages in thread
From: Grant Taylor via TUHS @ 2020-07-22  3:27 UTC (permalink / raw)
  To: tuhs


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

On 7/21/20 7:16 PM, tytso@mit.edu wrote:
> Yeah, that's definitely not right.  /sbin had been around for 
> "essential system binaries" long before Linux, and Linux took it 
> from there.

I'm sorry, I think there has been a misunderstanding.  I did not mean to 
imply that Linux influenced the larger Unix community with /sbin. 
Rather the other way around, that that's the time that Linux had been 
influenced about /sbin.

> You can see this from the Linux Filesystem Hierarchy Standard (earlier 
> named fsstnd, which specified /sbin as "essential system binaries").

I should revisit that, particularly in light of an older name and use.

> SunOS used that nomenclature and the GNU tools all used /sbin for 
> that purpose.

Did Solaris follow in SunOS's foot steps?  Or did Solaris do something 
different?

> The other thing I'd again urge is that you not take HJ Lu's boot/root 
> disks as being influencial after early 1992.

Okay.  I naively thought that HJ Lu's boot/root was falling out of favor 
in '93, a year later.  Thank you for clarifying Warner.



-- 
Grant. . . .
unix || die


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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-21 22:42   ` David Arnold
@ 2020-07-22  3:33     ` Warner Losh
  0 siblings, 0 replies; 18+ messages in thread
From: Warner Losh @ 2020-07-22  3:33 UTC (permalink / raw)
  To: David Arnold; +Cc: TUHS


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

On Tue, Jul 21, 2020, 4:52 PM David Arnold <davida@pobox.com> wrote:

> > On 22 Jul 2020, at 04:15, Warner Losh <imp@bsdimp.com> wrote:
>
> <…>
>
> > The root disks date from a time before Linux had shared libraries, I
> thought,
>
> IIRC, Linux had two different shared library implementations?  I haven’t
> looked, and don’t remember the details, but it might have been linked to
> the switch from a.out to ELF for executables?  IIRC, the pre-ELF shared
> libs were a hack on the a.out executable format.
>

Yes. Those were the SunOS like ones, but with weird address location quirks.

Warner

Not sure where that fits into the /etc vs. /sbin timeline.  ISTR Linux was
> somewhat inclined away from the BSD way of doing things (in favour of
> Solaris/SVR4).
>
>
>
>
> d
>
>

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-22  3:27       ` Grant Taylor via TUHS
@ 2020-07-22  3:35         ` Warner Losh
  0 siblings, 0 replies; 18+ messages in thread
From: Warner Losh @ 2020-07-22  3:35 UTC (permalink / raw)
  To: Grant Taylor; +Cc: TUHS main list


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

On Tue, Jul 21, 2020, 9:30 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 7/21/20 7:16 PM, tytso@mit.edu wrote:
> > Yeah, that's definitely not right.  /sbin had been around for
> > "essential system binaries" long before Linux, and Linux took it
> > from there.
>
> I'm sorry, I think there has been a misunderstanding.  I did not mean to
> imply that Linux influenced the larger Unix community with /sbin.
> Rather the other way around, that that's the time that Linux had been
> influenced about /sbin.
>
> > You can see this from the Linux Filesystem Hierarchy Standard (earlier
> > named fsstnd, which specified /sbin as "essential system binaries").
>
> I should revisit that, particularly in light of an older name and use.
>
> > SunOS used that nomenclature and the GNU tools all used /sbin for
> > that purpose.
>
> Did Solaris follow in SunOS's foot steps?  Or did Solaris do something
> different?
>
> > The other thing I'd again urge is that you not take HJ Lu's boot/root
> > disks as being influencial after early 1992.
>
> Okay.  I naively thought that HJ Lu's boot/root was falling out of favor
> in '93, a year later.  Thank you for clarifying Warner.
>

I think it was Ted clarifying me :)

Warner

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

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-22  2:20         ` Adam Thornton
@ 2020-07-22 13:30           ` Clem Cole
  2020-07-22 13:43             ` Richard Salz
  0 siblings, 1 reply; 18+ messages in thread
From: Clem Cole @ 2020-07-22 13:30 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society


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

On Tue, Jul 21, 2020 at 10:22 PM Adam Thornton <athornton@gmail.com> wrote:

> I miss AFS.
>
The server still runs on BSD.  Ran it at home for a fairly long time.

Its really too bad AFS 4.0 got mixed up in the Sun vs OSF wars and ended up
as part of DCE as opposed to being its own technology.

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-21 19:24   ` Clem Cole
@ 2020-07-22 13:39     ` Clem Cole
  0 siblings, 0 replies; 18+ messages in thread
From: Clem Cole @ 2020-07-22 13:39 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: TUHS main list, Grant Taylor


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

On Tue, Jul 21, 2020 at 3:24 PM Clem Cole <clemc@ccc.com> wrote:

>
>   I think I may even have a memo or two from the discussion in a file
> cabinet.
>
Just for grins, I peaked in a file I had last night.  I found about 4-5
cm's thickness of the 'requirements for a next-gen kernel' documents from
the UI kernel group.  They went to dev null as they are so unuseful at this
point and I'm short on filing space/my wife has been on me to weed.  I did
decide to save the who was on the committee page, that seems like it might
have value.

It was 1993, and  Linux was just appearing, who knew?   UI was backing the
SRV4 ABI on top of Chorus as a reaction to OSF's Mach system.

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-22 13:30           ` Clem Cole
@ 2020-07-22 13:43             ` Richard Salz
  0 siblings, 0 replies; 18+ messages in thread
From: Richard Salz @ 2020-07-22 13:43 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society


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

> Its really too bad AFS 4.0 got mixed up in the Sun vs OSF wars and ended
> up as part of DCE as opposed to being its own technology.
>

OpenAFS is (still) a thing.  Runs at Morgan-Stanley (or some other finsvc
house) and is kept going, reasonably healthy, by hackers.  www.openafs.org

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, back to index

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-21 17:55 [TUHS] /bin vs /sbin 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
2020-07-22  3:27       ` Grant Taylor via TUHS
2020-07-22  3:35         ` Warner Losh
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

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git