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