The Unix Heritage Society mailing list
 help / color / mirror / 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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
                     ` (2 more replies)
  1 sibling, 3 replies; 24+ 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] 24+ 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
  2021-01-29 23:50   ` Chris Hanson
  2 siblings, 3 replies; 24+ 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] 24+ 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; 24+ 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] 24+ 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
  2021-01-29 23:50   ` Chris Hanson
  2 siblings, 1 reply; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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
  2021-01-27  5:56         ` Greg A. Woods
  0 siblings, 2 replies; 24+ 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] 24+ 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; 24+ 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] 24+ messages in thread

* Re: [TUHS] /bin vs /sbin
  2020-07-22  3:27       ` Grant Taylor via TUHS
@ 2020-07-22  3:35         ` Warner Losh
  2021-01-27  5:56         ` Greg A. Woods
  1 sibling, 0 replies; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ messages in thread

* Re: [TUHS] /bin vs /sbin
  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
  1 sibling, 1 reply; 24+ messages in thread
From: Greg A. Woods @ 2021-01-27  5:56 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

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

[not replying privately even though this is an old thread from back in
the time when I was still enjoying a care-free summer vacation, and even
though Grant and/or his mailer set "reply-to" to be his own address, not
the list address, but because I'm still having rDNS issues and Grant's
mailer won't let mine deliver to him...]

At Tue, 21 Jul 2020 21:27:59 -0600, Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
Subject: Re: [TUHS] /bin vs /sbin
>
> Did Solaris follow in SunOS's foot steps?  Or did Solaris do something
> different?

Note that "Solaris" is a marketing name for a whole OS package including
the kernel, base system, user interface, and even some applications.

On the other hand "SunOS" the name of the base system OS (i.e. kernel
and userland).  The name "SunOS" pre-dated the name "Solaris" but
continues on as the name of the base OS within the Solaris package.

E.g. from the Wikipedia Solaris article:

    "For example, Solaris 2.4 incorporates SunOS 5.4. After Solaris 2.6,
    the 2. was dropped from the release name, so Solaris 7 incorporates
    SunOS 5.7, and the latest release SunOS 5.11 forms the core of
    Solaris 11.4."

and from the Wikipedia SunOS article:

    "Today, SunOS 5 is universally known as Solaris, although the SunOS
    name is still visible within the OS itself – in the startup banner,
    the output of the uname command, and man page footers, among other
    places.

    Matching a SunOS 5.x release to its corresponding Solaris marketing
    name is simple: each Solaris release name includes its corresponding
    SunOS 5 minor version number. For example, Solaris 2.4 incorporated
    SunOS 5.4. There is one small twist: after Solaris 2.6, the "2." was
    dropped from the Solaris name and the SunOS minor number appears by
    itself. The latest Solaris release is named Solaris 11 and
    incorporates SunOS 5.11."

Sun even back-pedaled and re-branded SunSO 4 as Solaris 1.0 before the
switch from BSD to something Sun liked to think was akin to SVR4.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

* Re: [TUHS] /bin vs /sbin
  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
  0 siblings, 2 replies; 24+ messages in thread
From: Grant Taylor via TUHS @ 2021-01-27 19:06 UTC (permalink / raw)
  To: tuhs

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

On 1/26/21 10:56 PM, Greg A. Woods wrote:
> [not replying privately even though this is an old thread from back 
> in the time when I was still enjoying a care-free summer vacation,

<thumbs up>

> and even though Grant and/or his mailer set "reply-to" to be his 
> own address, not the list address,

It's not me or my mailer setting the Reply-To:.  It seems as if the 
mailing list is setting that on senders who's domain uses DMARC, which 
mine does.

> but because I'm still having rDNS issues and Grant's mailer won't 
> let mine deliver to him...]

I've added central... to my hosts file, so hopefully you can email me 
directly if you want to.

> Note that "Solaris" is a marketing name for a whole OS package 
> including the kernel, base system, user interface, and even some 
> applications.

<head tilt>

That's ... a different explanation than I've heard before.

I'm not saying I disagree with it, just that it's completely new to me.

> On the other hand "SunOS" the name of the base system OS (i.e. kernel 
> and userland).

Please elaborate.  Including using the same terms for both names.  How 
does "userland" compare to "base system" and / or "user interface"?

I'm also curious what differentiates between SunOS and a minimal install 
of Solaris.

> The name "SunOS" pre-dated the name "Solaris" but continues on as 
> the name of the base OS within the Solaris package.

I thought the "SunOS" vs "Solaris" was a marketing change around the 
time SunOS / Solaris transitioned from being more BSD to more Sys V.

I also thought that the retention of "SunOS" in the kernel name and 
versioning was for backward compatibility.

> Sun even back-pedaled and re-branded SunSO 4 as Solaris 1.0 before 
> the switch from BSD to something Sun liked to think was akin to SVR4.

I was not aware that some of -- what I'll call -- the naming shenanigans 
happened to SunOS 4.  I was only aware of things at SunOS 5.



-- 
Grant. . . .
unix || die


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

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

* Re: [TUHS] /bin vs /sbin
  2021-01-27 19:06           ` Grant Taylor via TUHS
@ 2021-01-27 22:22             ` Warner Losh
  2021-01-27 22:35             ` Greg A. Woods
  1 sibling, 0 replies; 24+ messages in thread
From: Warner Losh @ 2021-01-27 22:22 UTC (permalink / raw)
  To: Grant Taylor; +Cc: TUHS main list

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

On Wed, Jan 27, 2021 at 12:06 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 1/26/21 10:56 PM, Greg A. Woods wrote:
> > [not replying privately even though this is an old thread from back
> > in the time when I was still enjoying a care-free summer vacation,
>
> <thumbs up>
>
> > and even though Grant and/or his mailer set "reply-to" to be his
> > own address, not the list address,
>
> It's not me or my mailer setting the Reply-To:.  It seems as if the
> mailing list is setting that on senders who's domain uses DMARC, which
> mine does.
>
> > but because I'm still having rDNS issues and Grant's mailer won't
> > let mine deliver to him...]
>
> I've added central... to my hosts file, so hopefully you can email me
> directly if you want to.
>
> > Note that "Solaris" is a marketing name for a whole OS package
> > including the kernel, base system, user interface, and even some
> > applications.
>
> <head tilt>
>
> That's ... a different explanation than I've heard before.
>
> I'm not saying I disagree with it, just that it's completely new to me.
>
> > On the other hand "SunOS" the name of the base system OS (i.e. kernel
> > and userland).
>
> Please elaborate.  Including using the same terms for both names.  How
> does "userland" compare to "base system" and / or "user interface"?
>
> I'm also curious what differentiates between SunOS and a minimal install
> of Solaris.
>

Solaris 2.x == SunOS 5.x + OpenWindows
Solaris 1.x == SunOS 4.x + OpenWindows

Solaris, back in the day, was SunOS + OpenWindows.


> > The name "SunOS" pre-dated the name "Solaris" but continues on as
> > the name of the base OS within the Solaris package.
>
> I thought the "SunOS" vs "Solaris" was a marketing change around the
> time SunOS / Solaris transitioned from being more BSD to more Sys V.
>

No. Solaris 2 was System V. Solaris 1 was BSD. Though it did pop up around
SunOS 4.1 time frame when it became clear that SunOS 5 would be System V
based and a big rewrite.

When Solbourne chose their name, Sun told them they could pick anything
they wanted, except Solaris because they were going to use that to market
SunOS.


> I also thought that the retention of "SunOS" in the kernel name and
> versioning was for backward compatibility.
>

Not entirely... It was very explicit in the marketing literature that SunOS
5 was the kernel for Solaris 2, but that Solaris 2 also included other
components like OpenWindows. The status of the base userland tools (eg
/bin/ls) wasn't ever talked about, but was generally understood to be in
the SunOS side of the world...


> > Sun even back-pedaled and re-branded SunSO 4 as Solaris 1.0 before
> > the switch from BSD to something Sun liked to think was akin to SVR4.
>
> I was not aware that some of -- what I'll call -- the naming shenanigans
> happened to SunOS 4.  I was only aware of things at SunOS 5.
>

Yes. I had (but no longer have) a Solaris 1.1 Sparc CD that had SunOS 4.1.4
and  OpenWindows 1.1  on it. I think Solaris 1.0 had 4.1.3 on it.

I worked for Solbourne Computers in Longmont CO  in the early 1990s and
this distinction was what drove our group to create OI (Object Interface)
set of tools that implemented the OpenWindows and Motif look and feel since
it wasn't clear that Sun would license OpenWindows when Solbourne started
and we needed a desktop story...

Warner

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

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

* Re: [TUHS] /bin vs /sbin
  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
  1 sibling, 1 reply; 24+ messages in thread
From: Greg A. Woods @ 2021-01-27 22:35 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

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

At Wed, 27 Jan 2021 12:06:26 -0700, Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
Subject: Re: [TUHS] /bin vs /sbin
>
> I've added central... to my hosts file, so hopefully you can email me
> directly if you want to.

Thanks!  (but I still need to pester my service provider for rDNS!)

> > On the other hand "SunOS" the name of the base system OS
> > (i.e. kernel and userland).
>
> Please elaborate.  Including using the same terms for both names.  How
> does "userland" compare to "base system" and / or "user interface"?
>
> I'm also curious what differentiates between SunOS and a minimal
> install of Solaris.

Sorry, I should have been a tiny bit more specific:  the "user
interface" here refers to a Graphical UI.  Unix of course didn't start
out with a GUI of any kind, and workstation vendors like Sun and many
others at the time made a big deal out of how they were offering a
better user interface for their systems.

I separate "kernel" and "userland" (here meaning all the command-line
programs, etc.) only because that's become a more common way to define
the "base OS" in unixy, i.e. linuxy, circles.

This distinction between the traditional Unix layer and the GUI is quite
important in the history of SunOS, since there have been a number of
different offerings from Sun for their GUI (Sun Windowing System,
SunView, NeWS, SunWindows); and also in how Sun promoted their various
GUI offerings as the solutions for wider use.

Even with the advent of a common choice of The X Window System as the
basis for most workstation vendor's GUIs, there were still battles over
which toolkit and window manager and "look and feel" would prevail
(Athena vs. Motif vs. OpenLook), with Sun even evolving their offerings
(SunWindows, OpenLook) over time.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

* Re: [TUHS] /bin vs /sbin
  2021-01-27 22:35             ` Greg A. Woods
@ 2021-01-28  5:24               ` Grant Taylor via TUHS
  0 siblings, 0 replies; 24+ messages in thread
From: Grant Taylor via TUHS @ 2021-01-28  5:24 UTC (permalink / raw)
  To: tuhs

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

On 1/27/21 3:35 PM, Greg A. Woods wrote:
> Thanks!  (but I still need to pester my service provider for rDNS!)

You're welcome.

> Sorry, I should have been a tiny bit more specific:  the "user 
> interface" here refers to a Graphical UI.  Unix of course didn't start 
> out with a GUI of any kind, and workstation vendors like Sun and many 
> others at the time made a big deal out of how they were offering a 
> better user interface for their systems.

Hum ...

> I separate "kernel" and "userland" (here meaning all the command-line 
> programs, etc.) only because that's become a more common way to define 
> the "base OS" in unixy, i.e. linuxy, circles.

When I think of Base OS, I think of AIX, because it's the first place I 
saw Base OS, referred to as BOS, explicitly called out.  But, I know 
that Solaris and HP-UX also have a very minimal install.  Even Linux has 
very minimal installs (debootstrap, Slackware boot+root, and DSL come to 
mind).

I think of development applications / compilers, fancy text processing, 
networking, X11, office applications as all being add on products. 
Sure, Linux tends to come with a LOT of them installed by default.

I guess the base OS to me is what's required to boot, maintain, and 
install a system.  Anything else is ancillary as far as -- what I 
consider to be -- the base OS is concerned.

> This distinction between the traditional Unix layer and the GUI is 
> quite important in the history of SunOS, since there have been a number 
> of different offerings from Sun for their GUI (Sun Windowing System, 
> SunView, NeWS, SunWindows); and also in how Sun promoted their various 
> GUI offerings as the solutions for wider use.

Hum.  I guess my exposure to Solaris installations has tainted my view. 
I helped support some DB servers with the full GUI developers 
workstation installed, just in case it was needed.  The people that 
installed them didn't want to ever go back and pull something else in. 
Which is why we had to patch Firefox, Thunderbird, and Pidgen / 
libpurple on Solaris database servers.  At least until I ripped those 
things, along with the kitchen sink, out.  It made patching so much 
faster and smaller.

> Even with the advent of a common choice of The X Window System as the 
> basis for most workstation vendor's GUIs, there were still battles 
> over which toolkit and window manager and "look and feel" would prevail 
> (Athena vs. Motif vs. OpenLook), with Sun even evolving their offerings 
> (SunWindows, OpenLook) over time.

I'm vaguely aware of CDE and that there were others before / around 
that.  But my personal experience is largely after that.  As such, I 
wasn't aware of some of the things that you are talking about.  Thank 
you for enlightening me.



-- 
Grant. . . .
unix || die


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

^ permalink raw reply	[flat|nested] 24+ 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
@ 2021-01-29 23:50   ` Chris Hanson
  2 siblings, 0 replies; 24+ messages in thread
From: Chris Hanson @ 2021-01-29 23:50 UTC (permalink / raw)
  To: arnold; +Cc: tuhs, gtaylor

On Jul 21, 2020, at 11:22 AM, arnold@skeeve.com wrote:
> 
> 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.

And then NeXT went a little further, making /etc, /var, and /tmp symlinks to entries in /private, so each netbooted system only needed two main mount points:

/ could be read-only, served from any number of servers for load-balancing, and shared among all systems running NEXTSTEP (even across architectures, thanks to multi-arch binaries).

/private could be per-machine and could come from a server near that machine to manage load.

It meant your admins just needed the MAC address of a new system (to create the NetInfo /machines entry for it) and it would be immediately usable on the network.

All of our NeXT-derived operating systems still follow this filesystem layout, though only a tiny number (relatively speaking) are netbooted these days. (I don't even remember whether netboot is supported any more…)

  -- Chris


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

end of thread, other threads:[~2021-01-30  0:00 UTC | newest]

Thread overview: 24+ 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
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

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