... 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.
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.
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.
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).
rCLUFSrCY 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:
rCLUFSrCY 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:
rCLUFSrCY 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:
rCLUFSrCY 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.
Bob Eager writes:
I managed a VAXcluster and actually own three VAXes
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.
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.
On Mon, 15 Jun 2026 16:43:18 +0000, Scott Lurndal wrote:
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 think by that time most people had hacked it to have 'cd' as well. I started with v6 in 1975.
As an awakward typist, I found chdir hard to type! And I wasn't the only
one.
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:
rCLUFSrCY 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:
rCLUFSrCY 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:
rCLUFSrCY 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.
On 2026-06-17, Bob Eager <throwaway0008@eager.cx> wrote:
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.
In a way he might be right. Many people's personal computers are now
nothing more than terminals to centralized e-mail and web servers.
We've come full circle: centralized -> distributed -> centralized.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
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:
rCLUFSrCY 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?
Yep. And a 14-character filename length limit.
And that's with disregarding the whole issue of hardware compatibility
(maybe that'd get better if these systems weren't so locked down?).
So not only it becomes harder and more expensive to get PC-style
keyboard computers, it might even lead to a situation where you just
don't have that flexibility anymore because somehow smartphones and
tablets managed to set "fully locked down" as the new normal - which, to
be honest, isn't anything new as a concern, AFAIK this is perhaps the
main issue with "trusted computing" and "secure boot", the potential for abuse is there too?
On 2026-06-17, Charlie Gibbs wrote:or=20
On 2026-06-17, Bob Eager <throwaway0008@eager.cx> wrote:
I remember going to a presentation by our computing service around 1990=
a bit earlier, given by the deputy software manager.
He extolled X terminals (we had NCDs) and confidently predicted that th= ey=20
were the future, and the PC was a passing fad.
In a way he might be right. Many people's personal computers are now
nothing more than terminals to centralized e-mail and web servers.
We've come full circle: centralized -> distributed -> centralized.
A possible danger that I see in this is that cheap, "generic"
computing machinery that you can use freely might end up going away
with pushes towards tablets and smartphones - which tend to be, from
what I understand, quite locked-down, and where the idea of just
booting install media to choose another system seems to be quite alien
to the point of requiring convoluted procedures or even cracks and is
(in what I'm sure can be legally challenged) considered something that
voids the warranty (at least Motorola seems to say this explicitly).
And that's with disregarding the whole issue of hardware compatibility
(maybe that'd get better if these systems weren't so locked down?).
So not only it becomes harder and more expensive to get PC-style
keyboard computers, it might even lead to a situation where you just
don't have that flexibility anymore because somehow smartphones and
tablets managed to set "fully locked down" as the new normal - which, to
be honest, isn't anything new as a concern,=20
AFAIK this is perhaps the main issue with "trusted computing" and
"secure boot", the potential for abuse is there too?
In article <hHxYR.91908$tRR9.48494@fx23.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
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?
Yep. And a 14-character filename length limit.
So inodes were still limited to 16 bits? Yikes. You think they
could have at least gone to 28 char limits for the filename and
4 byte inode numbers. :-)
On 2026-06-17, Charlie Gibbs wrote:
On 2026-06-17, Bob Eager <throwaway0008@eager.cx> wrote:
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.
In a way he might be right. Many people's personal computers are now
nothing more than terminals to centralized e-mail and web servers.
We've come full circle: centralized -> distributed -> centralized.
A possible danger that I see in this is that cheap, "generic" computing machinery that you can use freely might end up going away with pushes
towards tablets and smartphones - which tend to be, from what I
understand, quite locked-down, and where the idea of just booting
install media to choose another system seems to be quite alien to the
point of requiring convoluted procedures or even cracks and is (in what
I'm sure can be legally challenged) considered something that voids the warranty (at least Motorola seems to say this explicitly).
On 2026-06-18 00:56, Nuno Silva wrote:
And that's with disregarding the whole issue of hardware compatibility
(maybe that'd get better if these systems weren't so locked down?).
So not only it becomes harder and more expensive to get PC-style
keyboard computers, it might even lead to a situation where you just
don't have that flexibility anymore because somehow smartphones and
tablets managed to set "fully locked down" as the new normal - which, to
be honest, isn't anything new as a concern, AFAIK this is perhaps the
main issue with "trusted computing" and "secure boot", the potential for
abuse is there too?
When "secure boot" first came out, I saw this up front. A server in my workplace had died, and I rushed to "Best Buy" to get a replacement, and
got an Acer off the shelf. When I got back to the office, I started to
load Fedora Linux on it, but the machine absolutely refused to boot the install CD. I went back to the store, where the sales staff were
perplexed and called their support people who told them that indeed this machine was a Windows-only machine. It took some consultation before
they found a Dell box that was allowed to install Linux.
Yeah, it was just a lack of training on behalf of the store people, but
the effect was as described.
I stay away from secure boot and hard drive encryption for this reason.
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.
I'm curious about the TRS-80 and the lack of ethernet (not
surprised). Isn't there a way to use modern serial wifi adapters to get
that sucker on a network?
it's big, it's heavy, it's power hungry, it's slow, and I don't
have a need for it anymore. :-/
Every once in a while I get the idea that it might be fun to play with
the actual old hardware, but then I shake myself and move on, for the reasons you mention.
When "secure boot" first came out, I saw this up front. A server in
my workplace had died, and I rushed to "Best Buy" to get a
replacement, and got an Acer off the shelf. When I got back to the
office, I started to load Fedora Linux on it, but the machine
absolutely refused to boot the install CD.
You're looking at tablets as computers. They're actually appliances.
On Thu, 18 Jun 2026 06:37:15 -0700, Lars Poulsen wrote:
When "secure boot" first came out, I saw this up front. A server in
my workplace had died, and I rushed to "Best Buy" to get a
replacement, and got an Acer off the shelf. When I got back to the
office, I started to load Fedora Linux on it, but the machine
absolutely refused to boot the install CD.
Did you check the BIOS/UEFI settings?
On 6/18/26 15:51, Lawrence DrCOOliveiro wrote:
On Thu, 18 Jun 2026 06:37:15 -0700, Lars Poulsen wrote:
When "secure boot" first came out, I saw this up front. A server in
my workplace had died, and I rushed to "Best Buy" to get a
replacement, and got an Acer off the shelf. When I got back to the
office, I started to load Fedora Linux on it, but the machine
absolutely refused to boot the install CD.
Did you check the BIOS/UEFI settings?
_For now_ they allow us to change them, but for how long?
On Thu, 18 Jun 2026 06:37:15 -0700, Lars Poulsen wrote:
When "secure boot" first came out, I saw this up front. A server in
my workplace had died, and I rushed to "Best Buy" to get a
replacement, and got an Acer off the shelf. When I got back to the
office, I started to load Fedora Linux on it, but the machine
absolutely refused to boot the install CD.
Did you check the BIOS/UEFI settings?
On Jun 19, 2026 at 09:37:32 CDT, "Peter Flass" <Peter@Iron-Spring.com> wrote:
On 6/18/26 15:51, Lawrence DrCOOliveiro wrote:
On Thu, 18 Jun 2026 06:37:15 -0700, Lars Poulsen wrote:
When "secure boot" first came out, I saw this up front. A server in
my workplace had died, and I rushed to "Best Buy" to get a
replacement, and got an Acer off the shelf. When I got back to the
office, I started to load Fedora Linux on it, but the machine
absolutely refused to boot the install CD.
Did you check the BIOS/UEFI settings?
_For now_ they allow us to change them, but for how long?
Secure Boot has been around for well over a decade, and it's still as configurable as it was at the beginning
Peter Flass wrote to alt.folklore.computers <=-
Every once in a while I get the idea that it might be fun to play with
the actual old hardware, but then I shake myself and move on, for the reasons you mention.
To: Peter Flass
Peter Flass wrote to alt.folklore.computers <=-
Every once in a while I get the idea that it might be fun to play with the actual old hardware, but then I shake myself and move on, for the reasons you mention.
I have an old steel tanker desk
- finally a desk capable of supporting
one of those SUN 21" CRT monitors!
Nuno Silva <nunojsilva@invalid.invalid> writes:
A possible danger that I see in this is that cheap, "generic"
computing machinery that you can use freely might end up going away
with pushes towards tablets and smartphones - which tend to be, from
what I understand, quite locked-down, and where the idea of just
booting install media to choose another system seems to be quite alien
to the point of requiring convoluted procedures or even cracks and is
(in what I'm sure can be legally challenged) considered something that
voids the warranty (at least Motorola seems to say this explicitly).
I can confirm you are right. Android(TM) devices are a good example of
being difficult to change operating system, and android(TM) is a good
example of a non-free software (sometimes misunderstood as being
libre/free).
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 have more fun with the reverse. Hyperbola GNU/Linux with the whole
GNUStep stack + WindowMaker + the GAP suite + GNUMail + ViewPDF...
as a modern but libre NeXTStep replacement.
scott wrote to alt.folklore.computers <=-
I have an old steel tanker desk
I have one (steelcase) as well. Came from the electrodata/burroughs pasadena plant, still has the asset tag. Currently supporting
a very light-weight mac mini and a Burroughs T27 terminal.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 70 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 37:49:24 |
| Calls: | 948 |
| Calls today: | 2 |
| Files: | 1,325 |
| Messages: | 280,561 |
