... but I've heard plenty of horror stories about
actually operating these things. Are there any commercial UNIX variants from >the '90s-early '00s that aren't a complete and utter pain in the ass to >administer? (especially coming from a Linux background)
On Mon, 15 Jun 2026 08:27:34 +0200, Piper McCorkle <contact@piperswe.me> wrote:
... but I've heard plenty of horror stories about actually operating
these things. Are there any commercial UNIX variants from the '90s-early >>'00s that aren't a complete and utter pain in the ass to administer? >>(especially coming from a Linux background)
If you're fluent on the Linux Command Line, sometimes it feels like
you're having a stroke when working on an old Unix. Things are just different enough,
or the command line switch you need for whatever util hadn't been
invented yet,
or whatever.
In article <n99uoqFkpanU2@mid.individual.net>,
Bob Eager <throwaway0008@eager.cx> wrote:
On Mon, 15 Jun 2026 06:57:44 +0000, Mechanicjay wrote:
On Mon, 15 Jun 2026 08:27:34 +0200, Piper McCorkle
<contact@piperswe.me>
wrote:
... but I've heard plenty of horror stories about actually operating >>>>these things. Are there any commercial UNIX variants from the >>>>'90s-early '00s that aren't a complete and utter pain in the ass to >>>>administer? (especially coming from a Linux background)
If you're fluent on the Linux Command Line, sometimes it feels like
you're having a stroke when working on an old Unix. Things are just
different enough,
or the command line switch you need for whatever util hadn't been
invented yet,
or whatever.
I remember the days when the command to change directory was chdir (it >>still is, but cd works too). Awakward to type. And there was no alias >>facility either.
The nice thing about "chdir" is you can do:
mkdir foo ^mk^ch
On Mon, 15 Jun 2026 08:27:34 +0200, Piper McCorkle <contact@piperswe.me> wrote:
... but I've heard plenty of horror stories about
actually operating these things. Are there any commercial UNIX variants from >>the '90s-early '00s that aren't a complete and utter pain in the ass to >>administer? (especially coming from a Linux background)
If you're fluent on the Linux Command Line, sometimes it feels like you're having a stroke when working on an old Unix. Things are just different enough,
or the command line switch you need for whatever util hadn't been invented yet,
or whatever.
That said, Ultrix 4.5 on this Mips DecStation hasn't been too bad, a little bit
of a learning curve, but not too terrible. I've been able to get some GNU tools
on here, gcc 3, bash 2, etc. That's allowed me to build all sort of stuff, like
slrn, pine, lynx, ircii, trek, adventure. It's been pretty rewarding and it's
turned into a machine I use all the time for the fun of it.
I've had a much harder time trying to figure out Solaris 5.x for my SparcStation...to the point that it just sits on a shelf and doesn't get used.
Xenix on the TRS-80 Model 16 is actually very easy to use, but that's a little
earlier and was geared as a office document system...and no ethernet, so I'm not
sure it really counts.
On Mon, 15 Jun 2026 06:57:44 +0000, Mechanicjay wrote:
On Mon, 15 Jun 2026 08:27:34 +0200, Piper McCorkle <contact@piperswe.me>
wrote:
... but I've heard plenty of horror stories about actually operating >>>these things. Are there any commercial UNIX variants from the '90s-early >>>'00s that aren't a complete and utter pain in the ass to administer? >>>(especially coming from a Linux background)
If you're fluent on the Linux Command Line, sometimes it feels like
you're having a stroke when working on an old Unix. Things are just
different enough,
or the command line switch you need for whatever util hadn't been
invented yet,
or whatever.
I remember the days when the command to change directory was chdir (it
still is, but cd works too).
Classic unix did not ever have a chdir command.Unix v6 on the PDP-11 has 'chdir' and 'cd' does not work. I have this
It did have a chdir(2) system call, however.
I remember the days when the command to change directory was chdir (it still is, but cd works too). Awakward to type. And there was no alias facility either.
scott@slp53.sl.home (Scott Lurndal) writes:
Classic unix did not ever have a chdir command.Unix v6 on the PDP-11 has 'chdir' and 'cd' does not work. I have this
It did have a chdir(2) system call, however.
system under emulation.
http://squoze.net/UNIX/v6man/man1/chdir
jayjwa <jayjwa@atr2.ath.cx.invalid> writes:
scott@slp53.sl.home (Scott Lurndal) writes:
Classic unix did not ever have a chdir command.Unix v6 on the PDP-11 has 'chdir' and 'cd' does not work. I have this >>system under emulation.
It did have a chdir(2) system call, however.
http://squoze.net/UNIX/v6man/man1/chdir
I sit corrected, however 'cd' was the standard command, 'chdir'
was supported as an alias by the bourne shell.
On Mon, 15 Jun 2026 15:29:42 +0000, Scott Lurndal wrote:
jayjwa <jayjwa@atr2.ath.cx.invalid> writes:
scott@slp53.sl.home (Scott Lurndal) writes:
Classic unix did not ever have a chdir command.Unix v6 on the PDP-11 has 'chdir' and 'cd' does not work. I have this >>>system under emulation.
It did have a chdir(2) system call, however.
http://squoze.net/UNIX/v6man/man1/chdir
I sit corrected, however 'cd' was the standard command, 'chdir'
was supported as an alias by the bourne shell.
The Bourne shell did not exist at the 'classic' time I am talking about.
It was 'sh' or nothing.
switch(t[DTYP]) {
case TCOM:
cp1 = t[DCOM];
if(equal(cp1, "chdir")) {
if(t[DCOM+1] != 0) {
if(chdir(t[DCOM+1]) < 0)
err("chdir: bad directory");
} else
err("chdir: arg count");
return;
}
if(equal(cp1, "shift")) {
if(dolc < 1) {
Bob Eager <throwaway0008@eager.cx> writes:
On Mon, 15 Jun 2026 15:29:42 +0000, Scott Lurndal wrote:The last time I used v6 was 1979. Memory fail.
jayjwa <jayjwa@atr2.ath.cx.invalid> writes:
scott@slp53.sl.home (Scott Lurndal) writes:
Classic unix did not ever have a chdir command.Unix v6 on the PDP-11 has 'chdir' and 'cd' does not work. I have this >>>>system under emulation.
It did have a chdir(2) system call, however.
http://squoze.net/UNIX/v6man/man1/chdir
I sit corrected, however 'cd' was the standard command, 'chdir'
was supported as an alias by the bourne shell.
The Bourne shell did not exist at the 'classic' time I am talking about.
It was 'sh' or nothing.
switch(t[DTYP]) {
case TCOM:
cp1 = t[DCOM]; if(equal(cp1, "chdir")) {
if(t[DCOM+1] != 0) {
if(chdir(t[DCOM+1]) < 0)
err("chdir: bad directory");
} else
err("chdir: arg count");
return;
}
if(equal(cp1, "shift")) {
if(dolc < 1) {
I've always been quite curious about commercial Unices, but when I was born >Linux had already put the writing on the wall for them. I think it would be >quite fun to set up a UNIX server in my homelab and have it host some services >(WWW, Gopher, Gemini, etc), but I've heard plenty of horror stories about >actually operating these things. Are there any commercial UNIX variants from >the '90s-early '00s that aren't a complete and utter pain in the ass to >administer? (especially coming from a Linux background)
I'm thinking of going with Solaris, if only because I have some hardware (a >Sun Fire system in unknown condition) that I could try to restore. But I know >the installation process will definitely be a pain in the ass. The system >doesn't have an optical drive, so I'll need to install Solaris over the >network. No clue how to set up the server necessary for that - hopefully I can >do it on OpenIndiana!
In article <nnd$6ea886ba$1c547b7f@9c94dd43bc13ac30>,
Piper McCorkle <contact@piperswe.me> wrote:
I've always been quite curious about commercial Unices, but when I was
born Linux had already put the writing on the wall for them. I think it >>would be quite fun to set up a UNIX server in my homelab and have it
host some services (WWW, Gopher, Gemini, etc), but I've heard plenty of >>horror stories about actually operating these things. Are there any >>commercial UNIX variants from the '90s-early '00s that aren't a complete >>and utter pain in the ass to administer? (especially coming from a Linux >>background)
I'm thinking of going with Solaris, if only because I have some hardware
(a Sun Fire system in unknown condition) that I could try to restore.
But I know the installation process will definitely be a pain in the
ass. The system doesn't have an optical drive, so I'll need to install >>Solaris over the network. No clue how to set up the server necessary for >>that - hopefully I can do it on OpenIndiana!
I hate to be the one saying it, but ... it wasn't that cool. :-)
Something that is kind of fun is to set up 4.3BSD on an emulated VAX,
though.
In article <nnd$6ea886ba$1c547b7f@9c94dd43bc13ac30>,
Piper McCorkle <contact@piperswe.me> wrote:
I've always been quite curious about commercial Unices, but when I was born >>Linux had already put the writing on the wall for them. I think it would be >>quite fun to set up a UNIX server in my homelab and have it host some services
(WWW, Gopher, Gemini, etc), but I've heard plenty of horror stories about >>actually operating these things. Are there any commercial UNIX variants from >>the '90s-early '00s that aren't a complete and utter pain in the ass to >>administer? (especially coming from a Linux background)
I'm thinking of going with Solaris, if only because I have some hardware (a >>Sun Fire system in unknown condition) that I could try to restore. But I know >>the installation process will definitely be a pain in the ass. The system >>doesn't have an optical drive, so I'll need to install Solaris over the >>network. No clue how to set up the server necessary for that - hopefully I can
do it on OpenIndiana!
I hate to be the one saying it, but ... it wasn't that cool. :-)
Something that is kind of fun is to set up 4.3BSD on an emulated
VAX, though.
Solaris 9 has UFS as its filesystem, which is very fragil (in my
experience).
?UFS? is the name for a whole family of filesystems, found among
proprietary Unixes and also the BSDs (where it originated).
All related, and yet all subtly incompatible with one another.
My understanding is that UFS is a retroactive name for the File
System introduced by the original UNIX ...
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <nnd$6ea886ba$1c547b7f@9c94dd43bc13ac30>,
Piper McCorkle <contact@piperswe.me> wrote:
I've always been quite curious about commercial Unices, but when I was >>>born Linux had already put the writing on the wall for them. I think it >>>would be quite fun to set up a UNIX server in my homelab and have it
host some services (WWW, Gopher, Gemini, etc), but I've heard plenty of >>>horror stories about actually operating these things. Are there any >>>commercial UNIX variants from the '90s-early '00s that aren't a
complete and utter pain in the ass to administer? (especially coming
from a Linux background)
I'm thinking of going with Solaris, if only because I have some
hardware (a Sun Fire system in unknown condition) that I could try to >>>restore. But I know the installation process will definitely be a pain
in the ass. The system doesn't have an optical drive, so I'll need to >>>install Solaris over the network. No clue how to set up the server >>>necessary for that - hopefully I can do it on OpenIndiana!
I hate to be the one saying it, but ... it wasn't that cool. :-)
As a long-time SVR3/4/4.2MP user, I found SunOs foreign, but Solaris was
much more comfortable to work with.
I have a T1 in storage, with an external SCSI CDROM. Have no idea if it still works.
Something that is kind of fun is to set up 4.3BSD on an emulated VAX, >>though.
I recently got VMS running on simh - it's been fun to revisit the late
70's and early 80's. I started on a PDP-8 (TSS8.24) in 1976,
followed by the HP-3000 in 1977 and the VAX in 1979. I now have all
three running in simulation for old-times-sake.
On Jun 15, 2026 at 18:55:25 CDT, "Lawrence D?Oliveiro" <ldo@nz.invalid> wrote: >> ?UFS? is the name for a whole family of filesystems, found among
proprietary Unixes and also the BSDs (where it originated).
All related, and yet all subtly incompatible with one another.
My understanding is that UFS is a retroactive name for the File System >introduced by the original UNIX, and every UNIX derivative just tweaked it >without regard for compatibility. Essentially, UFS is just a generic term for >"this UNIX-like's native filesystem which is probably a descendant of the >original UNIX File System."
On Mon, 15 Jun 2026 19:35:05 +0000, Dan Cross wrote:
In article <nnd$6ea886ba$1c547b7f@9c94dd43bc13ac30>,
Piper McCorkle <contact@piperswe.me> wrote:
I've always been quite curious about commercial Unices, but when I was >>>born Linux had already put the writing on the wall for them. I think it >>>would be quite fun to set up a UNIX server in my homelab and have it
host some services (WWW, Gopher, Gemini, etc), but I've heard plenty of >>>horror stories about actually operating these things. Are there any >>>commercial UNIX variants from the '90s-early '00s that aren't a complete >>>and utter pain in the ass to administer? (especially coming from a Linux >>>background)
I'm thinking of going with Solaris, if only because I have some hardware >>>(a Sun Fire system in unknown condition) that I could try to restore.
But I know the installation process will definitely be a pain in the
ass. The system doesn't have an optical drive, so I'll need to install >>>Solaris over the network. No clue how to set up the server necessary for >>>that - hopefully I can do it on OpenIndiana!
I hate to be the one saying it, but ... it wasn't that cool. :-)
Something that is kind of fun is to set up 4.3BSD on an emulated VAX,
though.
Like this?
https://unixhistory.tavi.co.uk/quasijarus.html
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <nnd$6ea886ba$1c547b7f@9c94dd43bc13ac30>,
Piper McCorkle <contact@piperswe.me> wrote:
I've always been quite curious about commercial Unices, but when I was born >>>Linux had already put the writing on the wall for them. I think it would be >>>quite fun to set up a UNIX server in my homelab and have it host some services
(WWW, Gopher, Gemini, etc), but I've heard plenty of horror stories about >>>actually operating these things. Are there any commercial UNIX variants from >>>the '90s-early '00s that aren't a complete and utter pain in the ass to >>>administer? (especially coming from a Linux background)
I'm thinking of going with Solaris, if only because I have some hardware (a >>>Sun Fire system in unknown condition) that I could try to restore. But I know
the installation process will definitely be a pain in the ass. The system >>>doesn't have an optical drive, so I'll need to install Solaris over the >>>network. No clue how to set up the server necessary for that - hopefully I can
do it on OpenIndiana!
I hate to be the one saying it, but ... it wasn't that cool. :-)
As a long-time SVR3/4/4.2MP user, I found SunOs foreign, but
Solaris was much more comfortable to work with.
I have a T1 in storage, with an external SCSI CDROM. Have no
idea if it still works.
Something that is kind of fun is to set up 4.3BSD on an emulated
VAX, though.
I recently got VMS running on simh - it's been fun to revisit
the late 70's and early 80's. I started on a PDP-8 (TSS8.24) in 1976, >followed by the HP-3000 in 1977 and the VAX in 1979. I now have all
three running in simulation for old-times-sake.
On Mon, 15 Jun 2026 22:40:12 +0000, Scott Lurndal wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <nnd$6ea886ba$1c547b7f@9c94dd43bc13ac30>,
Piper McCorkle <contact@piperswe.me> wrote:
I've always been quite curious about commercial Unices, but when I was >>>>born Linux had already put the writing on the wall for them. I think it >>>>would be quite fun to set up a UNIX server in my homelab and have it >>>>host some services (WWW, Gopher, Gemini, etc), but I've heard plenty of >>>>horror stories about actually operating these things. Are there any >>>>commercial UNIX variants from the '90s-early '00s that aren't a >>>>complete and utter pain in the ass to administer? (especially coming >>>>from a Linux background)
I'm thinking of going with Solaris, if only because I have some >>>>hardware (a Sun Fire system in unknown condition) that I could try to >>>>restore. But I know the installation process will definitely be a pain >>>>in the ass. The system doesn't have an optical drive, so I'll need to >>>>install Solaris over the network. No clue how to set up the server >>>>necessary for that - hopefully I can do it on OpenIndiana!
I hate to be the one saying it, but ... it wasn't that cool. :-)
As a long-time SVR3/4/4.2MP user, I found SunOs foreign, but Solaris was
much more comfortable to work with.
I have a T1 in storage, with an external SCSI CDROM. Have no idea if it
still works.
Something that is kind of fun is to set up 4.3BSD on an emulated VAX, >>>though.
I recently got VMS running on simh - it's been fun to revisit the late
70's and early 80's. I started on a PDP-8 (TSS8.24) in 1976,
followed by the HP-3000 in 1977 and the VAX in 1979. I now have all
three running in simulation for old-times-sake.
I take it you found a PAK generator for VMS.
Thew HP simulator guy broke away from the SIMH 4 project as it was (a) a >moving target and (b) the scandal about trying to restrict the code was >getting messy. The latest official versions are here:
https://simh.trailing-edge.com/hp/
(I am basing my new simulator on the Classic SIMH for similar reasons).
In article <n9cip1FapsoU1@mid.individual.net>,
Bob Eager <throwaway0008@eager.cx> wrote:
On Mon, 15 Jun 2026 22:40:12 +0000, Scott Lurndal wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <nnd$6ea886ba$1c547b7f@9c94dd43bc13ac30>,
Piper McCorkle <contact@piperswe.me> wrote:
I've always been quite curious about commercial Unices, but when I >>>>>was born Linux had already put the writing on the wall for them. I >>>>>think it would be quite fun to set up a UNIX server in my homelab and >>>>>have it host some services (WWW, Gopher, Gemini, etc), but I've heard >>>>>plenty of horror stories about actually operating these things. Are >>>>>there any commercial UNIX variants from the '90s-early '00s that >>>>>aren't a complete and utter pain in the ass to administer? >>>>>(especially coming from a Linux background)
I'm thinking of going with Solaris, if only because I have some >>>>>hardware (a Sun Fire system in unknown condition) that I could try to >>>>>restore. But I know the installation process will definitely be a >>>>>pain in the ass. The system doesn't have an optical drive, so I'll >>>>>need to install Solaris over the network. No clue how to set up the >>>>>server necessary for that - hopefully I can do it on OpenIndiana!
I hate to be the one saying it, but ... it wasn't that cool. :-)
As a long-time SVR3/4/4.2MP user, I found SunOs foreign, but Solaris
was much more comfortable to work with.
I have a T1 in storage, with an external SCSI CDROM. Have no idea if
it still works.
Something that is kind of fun is to set up 4.3BSD on an emulated VAX, >>>>though.
I recently got VMS running on simh - it's been fun to revisit the late
70's and early 80's. I started on a PDP-8 (TSS8.24) in 1976,
followed by the HP-3000 in 1977 and the VAX in 1979. I now have all
three running in simulation for old-times-sake.
I take it you found a PAK generator for VMS.
Thew HP simulator guy broke away from the SIMH 4 project as it was (a) a >>moving target and (b) the scandal about trying to restrict the code was >>getting messy. The latest official versions are here:
https://simh.trailing-edge.com/hp/
(I am basing my new simulator on the Classic SIMH for similar reasons).
OpenSIMH was supposed to fix this, I thought?
In article <gb%XR.132106$I0Ta.47907@fx05.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <nnd$6ea886ba$1c547b7f@9c94dd43bc13ac30>,
Piper McCorkle <contact@piperswe.me> wrote:
I've always been quite curious about commercial Unices, but when I was born
Linux had already put the writing on the wall for them. I think it would be
quite fun to set up a UNIX server in my homelab and have it host some services
(WWW, Gopher, Gemini, etc), but I've heard plenty of horror stories about >>>> actually operating these things. Are there any commercial UNIX variants from
the '90s-early '00s that aren't a complete and utter pain in the ass to >>>> administer? (especially coming from a Linux background)
I'm thinking of going with Solaris, if only because I have some hardware (a
Sun Fire system in unknown condition) that I could try to restore. But I know
the installation process will definitely be a pain in the ass. The system >>>> doesn't have an optical drive, so I'll need to install Solaris over the >>>> network. No clue how to set up the server necessary for that - hopefully I can
do it on OpenIndiana!
I hate to be the one saying it, but ... it wasn't that cool. :-)
As a long-time SVR3/4/4.2MP user, I found SunOs foreign, but
Solaris was much more comfortable to work with.
It's more commercial Unix as a whole that I didn't find all that
cool.
I have a T1 in storage, with an external SCSI CDROM. Have no
idea if it still works.
I have some old Sun hardware down the basement that I need to
figure out how to jetison. Kind of a shame in some sense, but
it's big, it's heavy, it's power hungry, it's slow, and I don't
have a need for it anymore. :-/
In article <nnd$4682d28c$0d318bf6@b19d6313421837aa>,
Piper McCorkle <contact@piperswe.me> wrote:
On Jun 15, 2026 at 18:55:25 CDT, "Lawrence D?Oliveiro" <ldo@nz.invalid> wrote:
?UFS? is the name for a whole family of filesystems, found among
proprietary Unixes and also the BSDs (where it originated).
All related, and yet all subtly incompatible with one another.
My understanding is that UFS is a retroactive name for the File System >>introduced by the original UNIX, and every UNIX derivative just tweaked it >>without regard for compatibility. Essentially, UFS is just a generic term for >>"this UNIX-like's native filesystem which is probably a descendant of the >>original UNIX File System."
The original-original Unix filesystem on the PDP-7 was radically
different from what we know today; the way it worked was kind of
hard to explain. It's kind of recognizable, but using it feels
odd.
After they moved to the PDP-11, they did a pretty good
filesystem that looks an awful lot like what we've got today.
However, it didn't make particularly efficient use of the disc
devices of that era, as the filesystem didn't take block
locality into account when allocating blocks on the physical
device; this meant you could have logically contiguous data
in a file that was spread across the platters so that reading
required doing lots of arm and head movement, which is slow (and
puts wear and tear on the physical components in the device).
You could get better efficiency by increasing the logical block
size used by the FS, but that made inefficient use of storage:
lots of little files wasted space.
Around the time of 4.1BSD, Kirk McKusick got interested in
addressing this, and did a new filesystem design that made two
major changes: first, it introduced a notion of locality into
the design by providing things called "cylinder groups" and
(roughly) trying to assign files to CGs so that blocks that go
into them come from regions of the device that are closer,
physically, than before. This minimizes seek times. The second
was to increase block sizes, but also introduce the notion of a
sub-block "fragment" for the trailing part of a file. Blocks
can be evenly divided into fragments (the fragment size is some
power-of-two factor smaller than the block size), and a bitmap
of fragments available in a block is maintained by the
filesystem; fragments are only allocated to the last block in a
file (this reduces the need to seek; blocks are physically
contiguous on the device) while controlling fragmentation
(blocks are small enough that you're not wasting space unduly).
This filesystem became available for production use with 4.2BSD,
and so is sometimes called, "The 4.2BSD Fast File System".
FFS also went to great lengths to order write operations to the
file structures on the device so that it could tolerate a crash;
you might lose some data, but at least the filesystem would be
consistent on recovery. The `fsck` utility could generally
repair what might have been damaged.
This was such an improvement over the earlier filesystems that
most vendors adopted it, and over time, it become referred to as
"UFS". Of course, each vendor had to pee on it to make it smell
like their own code, so gradually implementations became
slightly mutually incompatible. Caveat emptor.
I suppose one could describe UFS as a descendent of the original
Unix filesystem, but it was sufficiently different that I would
consider that a bit of a reach.
On Mon, 15 Jun 2026 22:40:12 +0000, Scott Lurndal wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <nnd$6ea886ba$1c547b7f@9c94dd43bc13ac30>,
Piper McCorkle <contact@piperswe.me> wrote:
I've always been quite curious about commercial Unices, but when I was >>>>born Linux had already put the writing on the wall for them. I think it >>>>would be quite fun to set up a UNIX server in my homelab and have it >>>>host some services (WWW, Gopher, Gemini, etc), but I've heard plenty of >>>>horror stories about actually operating these things. Are there any >>>>commercial UNIX variants from the '90s-early '00s that aren't a >>>>complete and utter pain in the ass to administer? (especially coming >>>>from a Linux background)
I'm thinking of going with Solaris, if only because I have some >>>>hardware (a Sun Fire system in unknown condition) that I could try to >>>>restore. But I know the installation process will definitely be a pain >>>>in the ass. The system doesn't have an optical drive, so I'll need to >>>>install Solaris over the network. No clue how to set up the server >>>>necessary for that - hopefully I can do it on OpenIndiana!
I hate to be the one saying it, but ... it wasn't that cool. :-)
As a long-time SVR3/4/4.2MP user, I found SunOs foreign, but Solaris was
much more comfortable to work with.
I have a T1 in storage, with an external SCSI CDROM. Have no idea if it
still works.
Something that is kind of fun is to set up 4.3BSD on an emulated VAX, >>>though.
I recently got VMS running on simh - it's been fun to revisit the late
70's and early 80's. I started on a PDP-8 (TSS8.24) in 1976,
followed by the HP-3000 in 1977 and the VAX in 1979. I now have all
three running in simulation for old-times-sake.
I take it you found a PAK generator for VMS.
In article <gb%XR.132106$I0Ta.47907@fx05.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
I have a T1 in storage, with an external SCSI CDROM. Have no
idea if it still works.
I have some old Sun hardware down the basement that I need to
figure out how to jetison. Kind of a shame in some sense, but
it's big, it's heavy, it's power hungry, it's slow, and I don't
have a need for it anymore. :-/
Bob Eager <throwaway0008@eager.cx> writes:
On Mon, 15 Jun 2026 22:40:12 +0000, Scott Lurndal wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <nnd$6ea886ba$1c547b7f@9c94dd43bc13ac30>,
Piper McCorkle <contact@piperswe.me> wrote:
I've always been quite curious about commercial Unices, but when I >>>>>was born Linux had already put the writing on the wall for them. I >>>>>think it would be quite fun to set up a UNIX server in my homelab and >>>>>have it host some services (WWW, Gopher, Gemini, etc), but I've heard >>>>>plenty of horror stories about actually operating these things. Are >>>>>there any commercial UNIX variants from the '90s-early '00s that >>>>>aren't a complete and utter pain in the ass to administer? >>>>>(especially coming from a Linux background)
I'm thinking of going with Solaris, if only because I have some >>>>>hardware (a Sun Fire system in unknown condition) that I could try to >>>>>restore. But I know the installation process will definitely be a >>>>>pain in the ass. The system doesn't have an optical drive, so I'll >>>>>need to install Solaris over the network. No clue how to set up the >>>>>server necessary for that - hopefully I can do it on OpenIndiana!
I hate to be the one saying it, but ... it wasn't that cool. :-)
As a long-time SVR3/4/4.2MP user, I found SunOs foreign, but Solaris
was much more comfortable to work with.
I have a T1 in storage, with an external SCSI CDROM. Have no idea if
it still works.
Something that is kind of fun is to set up 4.3BSD on an emulated VAX, >>>>though.
I recently got VMS running on simh - it's been fun to revisit the late
70's and early 80's. I started on a PDP-8 (TSS8.24) in 1976,
followed by the HP-3000 in 1977 and the VAX in 1979. I now have all
three running in simulation for old-times-sake.
I take it you found a PAK generator for VMS.
I found this last December:
https://www.openvmshobby.com/vax-vms/openvms-on-vax-simh/
On Tue, 16 Jun 2026 14:47:29 +0000, Scott Lurndal wrote:
I recently got VMS running on simh - it's been fun to revisit the late >>>> 70's and early 80's. I started on a PDP-8 (TSS8.24) in 1976,
followed by the HP-3000 in 1977 and the VAX in 1979. I now have all
three running in simulation for old-times-sake.
I take it you found a PAK generator for VMS.
I found this last December:
https://www.openvmshobby.com/vax-vms/openvms-on-vax-simh/
That's a good one. But I managed a VAXcluster and actually own three
VAXes, so I was OK.
I was referring to license PAKs, now that HP have stopped issuing them. Or >was that mentioned in the above, and I missed it?
I managed to grab the manual set before it disappeared.
In article <nnd$4682d28c$0d318bf6@b19d6313421837aa>,
Piper McCorkle <contact@piperswe.me> wrote:
On Jun 15, 2026 at 18:55:25 CDT, "Lawrence D?Oliveiro" <ldo@nz.invalid> wrote:
?UFS? is the name for a whole family of filesystems, found among
proprietary Unixes and also the BSDs (where it originated).
All related, and yet all subtly incompatible with one another.
My understanding is that UFS is a retroactive name for the File System
introduced by the original UNIX, and every UNIX derivative just tweaked it >> without regard for compatibility. Essentially, UFS is just a generic term for
"this UNIX-like's native filesystem which is probably a descendant of the
original UNIX File System."
The original-original Unix filesystem on the PDP-7 was radically
different from what we know today; the way it worked was kind of
hard to explain. It's kind of recognizable, but using it feels
odd.
After they moved to the PDP-11, they did a pretty good
filesystem that looks an awful lot like what we've got today.
However, it didn't make particularly efficient use of the disc
devices of that era, as the filesystem didn't take block
locality into account when allocating blocks on the physical
device; this meant you could have logically contiguous data
in a file that was spread across the platters so that reading
required doing lots of arm and head movement, which is slow (and
puts wear and tear on the physical components in the device).
You could get better efficiency by increasing the logical block
size used by the FS, but that made inefficient use of storage:
lots of little files wasted space.
Around the time of 4.1BSD, Kirk McKusick got interested in
addressing this, and did a new filesystem design that made two
major changes: first, it introduced a notion of locality into
the design by providing things called "cylinder groups" and
(roughly) trying to assign files to CGs so that blocks that go
into them come from regions of the device that are closer,
physically, than before. This minimizes seek times. The second
was to increase block sizes, but also introduce the notion of a
sub-block "fragment" for the trailing part of a file. Blocks
can be evenly divided into fragments (the fragment size is some
power-of-two factor smaller than the block size), and a bitmap
of fragments available in a block is maintained by the
filesystem; fragments are only allocated to the last block in a
file (this reduces the need to seek; blocks are physically
contiguous on the device) while controlling fragmentation
(blocks are small enough that you're not wasting space unduly).
This filesystem became available for production use with 4.2BSD,
and so is sometimes called, "The 4.2BSD Fast File System".
FFS also went to great lengths to order write operations to the
file structures on the device so that it could tolerate a crash;
you might lose some data, but at least the filesystem would be
consistent on recovery. The `fsck` utility could generally
repair what might have been damaged.
This was such an improvement over the earlier filesystems that
most vendors adopted it, and over time, it become referred to as
"UFS". Of course, each vendor had to pee on it to make it smell
like their own code, so gradually implementations became
slightly mutually incompatible. Caveat emptor.
I suppose one could describe UFS as a descendent of the original
Unix filesystem, but it was sufficiently different that I would
consider that a bit of a reach.
- Dan C.
I was referring to license PAKs, now that HP have stopped issuing them.
Or was that mentioned in the above, and I missed it?
It's not mentioned explicitly, however, the instructions as followed
produced a working VMS system. It doesn't include the Pascal
compiler, however, which I had hoped would be there.
I managed to grab the manual set before it disappeared.
I have a few printed manuals from VMS 2.0 and 3.0 days;
although pdf versions are available on bitsavers.
Something I love about Usenet - the folks on here generally know a
lot more about the details of computing history than me merely
browsing Wikipedia :) Thanks for the rundown of this history!
Scott Lurndal wrote:
Bob Eager writes:
I managed a VAXcluster and actually own three VAXes
I only own one, a VAXserver 3300
I have a few printed manuals from VMS 2.0 and 3.0 days;I've got large parts of a VMS 4.7 orange wall, and 5.5/6.1 grey wall.
On Tue, 16 Jun 2026 16:24:18 +0000, Scott Lurndal wrote:
I was referring to license PAKs, now that HP have stopped issuing them. >>>Or was that mentioned in the above, and I missed it?
It's not mentioned explicitly, however, the instructions as followed
produced a working VMS system. It doesn't include the Pascal
compiler, however, which I had hoped would be there.
Does the system allow users other than SYSTEM? Gnenerally, if not
licensed, it won't.
Scott Lurndal wrote:
Bob Eager writes:
I managed a VAXcluster and actually own three VAXes
I only own one, a VAXserver 3300
I have a few printed manuals from VMS 2.0 and 3.0 days;I've got large parts of a VMS 4.7 orange wall, and 5.5/6.1 grey wall.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <gb%XR.132106$I0Ta.47907@fx05.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
I have a T1 in storage, with an external SCSI CDROM. Have no
idea if it still works.
I have some old Sun hardware down the basement that I need to
figure out how to jetison. Kind of a shame in some sense, but
it's big, it's heavy, it's power hungry, it's slow, and I don't
have a need for it anymore. :-/
Yeah. I had a couple of Indigos and an Indy that I finally
dropped off at a swap meet at the CHM, along with a couple
of NCD 17c X terminals.
I had used the X terminals for a few years before linux
grew up.
Bob Eager <throwaway0008@eager.cx> writes:
On Tue, 16 Jun 2026 16:24:18 +0000, Scott Lurndal wrote:
I was referring to license PAKs, now that HP have stopped issuing
them.
Or was that mentioned in the above, and I missed it?
It's not mentioned explicitly, however, the instructions as followed
produced a working VMS system. It doesn't include the Pascal
compiler, however, which I had hoped would be there.
Does the system allow users other than SYSTEM? Gnenerally, if not
licensed, it won't.
It's been a few months.
I'll have to give it another shot when I get time (and this time write
down the SYSTEM password :-( ).
I noticed messages saying VMS wasn't licenced during the boot.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <nnd$4682d28c$0d318bf6@b19d6313421837aa>,
Piper McCorkle <contact@piperswe.me> wrote:
On Jun 15, 2026 at 18:55:25 CDT, "Lawrence D?Oliveiro" <ldo@nz.invalid> wrote:
?UFS? is the name for a whole family of filesystems, found among
proprietary Unixes and also the BSDs (where it originated).
All related, and yet all subtly incompatible with one another.
My understanding is that UFS is a retroactive name for the File System >>>introduced by the original UNIX, and every UNIX derivative just tweaked it >>>without regard for compatibility. Essentially, UFS is just a generic term for
"this UNIX-like's native filesystem which is probably a descendant of the >>>original UNIX File System."
The original-original Unix filesystem on the PDP-7 was radically
different from what we know today; the way it worked was kind of
hard to explain. It's kind of recognizable, but using it feels
odd.
After they moved to the PDP-11, they did a pretty good
filesystem that looks an awful lot like what we've got today.
However, it didn't make particularly efficient use of the disc
devices of that era, as the filesystem didn't take block
locality into account when allocating blocks on the physical
device; this meant you could have logically contiguous data
in a file that was spread across the platters so that reading
required doing lots of arm and head movement, which is slow (and
puts wear and tear on the physical components in the device).
You could get better efficiency by increasing the logical block
size used by the FS, but that made inefficient use of storage:
lots of little files wasted space.
Around the time of 4.1BSD, Kirk McKusick got interested in
addressing this, and did a new filesystem design that made two
major changes: first, it introduced a notion of locality into
the design by providing things called "cylinder groups" and
(roughly) trying to assign files to CGs so that blocks that go
into them come from regions of the device that are closer,
physically, than before. This minimizes seek times. The second
was to increase block sizes, but also introduce the notion of a
sub-block "fragment" for the trailing part of a file. Blocks
can be evenly divided into fragments (the fragment size is some >>power-of-two factor smaller than the block size), and a bitmap
of fragments available in a block is maintained by the
filesystem; fragments are only allocated to the last block in a
file (this reduces the need to seek; blocks are physically
contiguous on the device) while controlling fragmentation
(blocks are small enough that you're not wasting space unduly).
This filesystem became available for production use with 4.2BSD,
and so is sometimes called, "The 4.2BSD Fast File System".
FFS also went to great lengths to order write operations to the
file structures on the device so that it could tolerate a crash;
you might lose some data, but at least the filesystem would be
consistent on recovery. The `fsck` utility could generally
repair what might have been damaged.
This was such an improvement over the earlier filesystems that
most vendors adopted it, and over time, it become referred to as
"UFS". Of course, each vendor had to pee on it to make it smell
like their own code, so gradually implementations became
slightly mutually incompatible. Caveat emptor.
I suppose one could describe UFS as a descendent of the original
Unix filesystem, but it was sufficiently different that I would
consider that a bit of a reach.
The system V unices had the 's5' filesystem
(and supported ufs, vxfs, and a few others).
SGI had XFS, IBM had JFS which supported journaling, and there
was the clearcase (MVFS) filesystem as well.
On Jun 16, 2026 at 07:49:16 CDT, "Dan Cross" <Dan Cross> wrote:
In article <nnd$4682d28c$0d318bf6@b19d6313421837aa>,
Piper McCorkle <contact@piperswe.me> wrote:
On Jun 15, 2026 at 18:55:25 CDT, "Lawrence D?Oliveiro" <ldo@nz.invalid> wrote:
?UFS? is the name for a whole family of filesystems, found among
proprietary Unixes and also the BSDs (where it originated).
All related, and yet all subtly incompatible with one another.
My understanding is that UFS is a retroactive name for the File System
introduced by the original UNIX, and every UNIX derivative just tweaked it >>> without regard for compatibility. Essentially, UFS is just a generic term for
"this UNIX-like's native filesystem which is probably a descendant of the >>> original UNIX File System."
The original-original Unix filesystem on the PDP-7 was radically
different from what we know today; the way it worked was kind of
hard to explain. It's kind of recognizable, but using it feels
odd.
After they moved to the PDP-11, they did a pretty good
filesystem that looks an awful lot like what we've got today.
However, it didn't make particularly efficient use of the disc
devices of that era, as the filesystem didn't take block
locality into account when allocating blocks on the physical
device; this meant you could have logically contiguous data
in a file that was spread across the platters so that reading
required doing lots of arm and head movement, which is slow (and
puts wear and tear on the physical components in the device).
You could get better efficiency by increasing the logical block
size used by the FS, but that made inefficient use of storage:
lots of little files wasted space.
Around the time of 4.1BSD, Kirk McKusick got interested in
addressing this, and did a new filesystem design that made two
major changes: first, it introduced a notion of locality into
the design by providing things called "cylinder groups" and
(roughly) trying to assign files to CGs so that blocks that go
into them come from regions of the device that are closer,
physically, than before. This minimizes seek times. The second
was to increase block sizes, but also introduce the notion of a
sub-block "fragment" for the trailing part of a file. Blocks
can be evenly divided into fragments (the fragment size is some
power-of-two factor smaller than the block size), and a bitmap
of fragments available in a block is maintained by the
filesystem; fragments are only allocated to the last block in a
file (this reduces the need to seek; blocks are physically
contiguous on the device) while controlling fragmentation
(blocks are small enough that you're not wasting space unduly).
This filesystem became available for production use with 4.2BSD,
and so is sometimes called, "The 4.2BSD Fast File System".
FFS also went to great lengths to order write operations to the
file structures on the device so that it could tolerate a crash;
you might lose some data, but at least the filesystem would be
consistent on recovery. The `fsck` utility could generally
repair what might have been damaged.
This was such an improvement over the earlier filesystems that
most vendors adopted it, and over time, it become referred to as
"UFS". Of course, each vendor had to pee on it to make it smell
like their own code, so gradually implementations became
slightly mutually incompatible. Caveat emptor.
I suppose one could describe UFS as a descendent of the original
Unix filesystem, but it was sufficiently different that I would
consider that a bit of a reach.
Something I love about Usenet - the folks on here generally know a lot more >about the details of computing history than me merely browsing Wikipedia :) >Thanks for the rundown of this history!
[snip]
Sure! But caveat that I'm (highly) fallible; I recommend that
you verify against primary sources. :-) Here are a few
references:
UFS: https://dl.acm.org/doi/10.1145/989.990
FSCK: https://dl.acm.org/doi/10.1145/2560011
Soft updates: >https://www.usenix.org/legacy/publications/library/proceedings/usenix99/mckusick.html
In article <OpdYR.493868$_BG8.200357@fx24.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <gb%XR.132106$I0Ta.47907@fx05.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
I have a T1 in storage, with an external SCSI CDROM. Have no
idea if it still works.
I have some old Sun hardware down the basement that I need to
figure out how to jetison. Kind of a shame in some sense, but
it's big, it's heavy, it's power hungry, it's slow, and I don't
have a need for it anymore. :-/
Yeah. I had a couple of Indigos and an Indy that I finally
dropped off at a swap meet at the CHM, along with a couple
of NCD 17c X terminals.
I had used the X terminals for a few years before linux
grew up.
I remember those. I thought they were pretty nice for the time.
They had some kind of RISC CPU, right?
In article <wfdYR.493866$_BG8.262449@fx24.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <nnd$4682d28c$0d318bf6@b19d6313421837aa>,
Piper McCorkle <contact@piperswe.me> wrote:
On Jun 15, 2026 at 18:55:25 CDT, "Lawrence D?Oliveiro" <ldo@nz.invalid> wrote:
?UFS? is the name for a whole family of filesystems, found among
proprietary Unixes and also the BSDs (where it originated).
All related, and yet all subtly incompatible with one another.
My understanding is that UFS is a retroactive name for the File System >>>>introduced by the original UNIX, and every UNIX derivative just tweaked it >>>>without regard for compatibility. Essentially, UFS is just a generic term for
"this UNIX-like's native filesystem which is probably a descendant of the >>>>original UNIX File System."
The original-original Unix filesystem on the PDP-7 was radically >>>different from what we know today; the way it worked was kind of
hard to explain. It's kind of recognizable, but using it feels
odd.
After they moved to the PDP-11, they did a pretty good
filesystem that looks an awful lot like what we've got today.
However, it didn't make particularly efficient use of the disc
devices of that era, as the filesystem didn't take block
locality into account when allocating blocks on the physical
device; this meant you could have logically contiguous data
in a file that was spread across the platters so that reading
required doing lots of arm and head movement, which is slow (and
puts wear and tear on the physical components in the device).
You could get better efficiency by increasing the logical block
size used by the FS, but that made inefficient use of storage:
lots of little files wasted space.
Around the time of 4.1BSD, Kirk McKusick got interested in
addressing this, and did a new filesystem design that made two
major changes: first, it introduced a notion of locality into
the design by providing things called "cylinder groups" and
(roughly) trying to assign files to CGs so that blocks that go
into them come from regions of the device that are closer,
physically, than before. This minimizes seek times. The second
was to increase block sizes, but also introduce the notion of a
sub-block "fragment" for the trailing part of a file. Blocks
can be evenly divided into fragments (the fragment size is some >>>power-of-two factor smaller than the block size), and a bitmap
of fragments available in a block is maintained by the
filesystem; fragments are only allocated to the last block in a
file (this reduces the need to seek; blocks are physically
contiguous on the device) while controlling fragmentation
(blocks are small enough that you're not wasting space unduly).
This filesystem became available for production use with 4.2BSD,
and so is sometimes called, "The 4.2BSD Fast File System".
FFS also went to great lengths to order write operations to the
file structures on the device so that it could tolerate a crash;
you might lose some data, but at least the filesystem would be
consistent on recovery. The `fsck` utility could generally
repair what might have been damaged.
This was such an improvement over the earlier filesystems that
most vendors adopted it, and over time, it become referred to as
"UFS". Of course, each vendor had to pee on it to make it smell
like their own code, so gradually implementations became
slightly mutually incompatible. Caveat emptor.
I suppose one could describe UFS as a descendent of the original
Unix filesystem, but it was sufficiently different that I would
consider that a bit of a reach.
The system V unices had the 's5' filesystem
(and supported ufs, vxfs, and a few others).
Yeah, `s5` was basically the research filesystem with larger
blocks and a doubly-indirect block or something, right?
We originally had the monochrome NCD-16's. The screen resolution wasn't great, but it was better than using serial terminals.I had used the X terminals for a few years before linux grew up.
I remember those. I thought they were pretty nice for the time.
They had some kind of RISC CPU, right?
I remember going to a presentation by our computing service around 1990 or
a bit earlier, given by the deputy software manager.
He extolled X terminals (we had NCDs) and confidently predicted that they were the future, and the PC was a passing fad.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 4 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 494928:16:19 |
| Calls: | 162 |
| Files: | 568 |
| D/L today: |
14 files (349K bytes) |
| Messages: | 74,957 |
