21 Jul
2020
21 Jul
'20
11:55 p.m.
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
22 Jul
22 Jul
12:15 a.m.
On Tue, Jul 21, 2020 at 11:56 AM Grant Taylor via TUHS <tuhs(a)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
4:42 a.m.
On 22 Jul 2020, at 04:15, Warner Losh
<imp(a)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
9:33 a.m.
On Tue, Jul 21, 2020, 4:52 PM David Arnold <davida(a)pobox.com> wrote:
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
On 22 Jul
2020, at 04:15, Warner Losh <imp(a)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.
somewhat inclined away from the BSD way of doing
things (in favour of
Solaris/SVR4).
d
12:22 a.m.
Grant Taylor via TUHS <tuhs(a)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
12:33 a.m.
On Tue, Jul 21, 2020 at 12:23 PM <arnold(a)skeeve.com> wrote:
/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).
Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org>
wrote:
I'm skeptical as well.
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.
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
12:43 a.m.
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.
7:16 a.m.
On Tue, Jul 21, 2020 at 12:33:25PM -0600, Warner Losh wrote:
On Tue, Jul 21, 2020 at 12:23 PM
<arnold(a)skeeve.com> wrote:
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.
Grant Taylor via TUHS
<tuhs(a)minnie.tuhs.org> wrote:
I'm skeptical as well. To me, this makes it fairly self evident that
/sbin was originally for
statically linked binaries. At least in Linux.
Dunno about that. > 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
9:27 a.m.
On 7/21/20 7:16 PM, tytso(a)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
9:35 a.m.
On Tue, Jul 21, 2020, 9:30 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org>
wrote:
On 7/21/20 7:16 PM, tytso(a)mit.edu wrote:
I think it was Ted clarifying me :)
Warner
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
27 Jan
27 Jan
11:56 a.m.
[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(a)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(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
28 Jan
28 Jan
1:06 a.m.
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
4:22 a.m.
On Wed, Jan 27, 2021 at 12:06 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org>
wrote:
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.
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
On 1/26/21 10:56 PM, Greg A. Woods wrote:
Solaris 2.x == SunOS 5.x + OpenWindows
Solaris 1.x == SunOS 4.x + OpenWindows
Solaris, back in the day, was SunOS + OpenWindows.
[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.
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.
4:35 a.m.
At Wed, 27 Jan 2021 12:06:26 -0700, Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org>
wrote:
Subject: Re: [TUHS] /bin vs /sbin
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(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
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.
11:24 a.m.
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
22 Jul
22 Jul
7:44 a.m.
On Tue, Jul 21, 2020 at 2:35 PM Warner Losh <imp(a)bsdimp.com> wrote:
On Tue, Jul 21, 2020 at 12:23 PM
<arnold(a)skeeve.com> 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.
[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).
8:17 a.m.
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/OGENDh…
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
8:20 a.m.
On Jul 21, 2020, at 7:17 PM, Jon Forrest
<nobozo(a)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
7:30 p.m.
On Tue, Jul 21, 2020 at 10:22 PM Adam Thornton <athornton(a)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.
7:43 p.m.
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
8:27 a.m.
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
1:24 a.m.
On Tue, Jul 21, 2020 at 2:23 PM <arnold(a)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.
7:39 p.m.
On Tue, Jul 21, 2020 at 3:24 PM Clem Cole <clemc(a)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.
30 Jan
30 Jan
5:50 a.m.
On Jul 21, 2020, at 11:22 AM, arnold(a)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
1431
days inactive
1623
days old
23 comments
14 participants
participants (14)
-
Adam Thornton -
arnold＠skeeve.com -
Chris Hanson -
Clem Cole -
Dan Cross -
David Arnold -
Grant Taylor -
Greg A. Woods -
Jon Forrest -
Kurt H Maier -
Larry McVoy -
Richard Salz -
tytso＠mit.edu -
Warner Losh