Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #235018 > unrolled thread
| Started by | Piper McCorkle <contact@piperswe.me> |
|---|---|
| First post | 2026-06-15 08:27 +0200 |
| Last post | 2026-06-22 22:29 +0000 |
| Articles | 20 on this page of 73 — 24 participants |
Back to article view | Back to alt.folklore.computers
Old commercial UNIX in '26 Piper McCorkle <contact@piperswe.me> - 2026-06-15 08:27 +0200
Re: Old commercial UNIX in '26 mechanicjay@sol.smbfc.net (Mechanicjay) - 2026-06-15 06:57 +0000
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-15 09:25 +0000
Re: Old commercial UNIX in '26 ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-15 10:01 +0000
Re: Old commercial UNIX in '26 ted@loft.tnolan.com (Ted Nolan <tednolan>) - 2026-06-15 13:39 +0000
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-15 14:06 +0000
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-15 14:36 +0000
Re: Old commercial UNIX in '26 jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-06-15 11:14 -0400
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-15 15:29 +0000
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-15 16:23 +0000
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-15 16:43 +0000
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-15 19:06 +0000
Re: Old commercial UNIX in '26 Pluted Pup <plutedpup@outlook.com> - 2026-06-16 20:07 -0700
Re: Old commercial UNIX in '26 drb@ihatespam.msu.edu (Dennis Boone) - 2026-06-15 15:16 +0000
Re: Old commercial UNIX in '26 Daniel <me@sc1f1dan.com> - 2026-06-15 07:13 -0700
Re: Old commercial UNIX in '26 mechanicjay@sol.smbfc.net (Mechanicjay) - 2026-06-18 15:47 +0000
Re: Old commercial UNIX in '26 jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-06-15 11:34 -0400
Re: Old commercial UNIX in '26 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-15 23:55 +0000
Re: Old commercial UNIX in '26 Piper McCorkle <contact@piperswe.me> - 2026-06-16 04:50 +0200
Re: Old commercial UNIX in '26 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 03:34 +0000
Re: Old commercial UNIX in '26 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-16 12:49 +0000
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-16 14:40 +0000
Re: Old commercial UNIX in '26 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-17 11:49 +0000
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-17 13:55 +0000
Re: Old commercial UNIX in '26 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-18 09:52 +0000
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-18 14:45 +0000
Re: Old commercial UNIX in '26 Piper McCorkle <contact@piperswe.me> - 2026-06-16 21:59 +0200
Re: Old commercial UNIX in '26 John Ames <commodorejohn@gmail.com> - 2026-06-16 13:53 -0700
Re: Old commercial UNIX in '26 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-17 12:00 +0000
Re: Old commercial UNIX in '26 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-17 13:21 +0000
Re: Old commercial UNIX in '26 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 19:35 +0000
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-15 20:01 +0000
Re: Old commercial UNIX in '26 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-16 12:50 +0000
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-15 22:40 +0000
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-16 09:19 +0000
Re: Old commercial UNIX in '26 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-16 13:00 +0000
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-16 13:44 +0000
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-16 14:47 +0000
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-16 14:59 +0000
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-16 16:24 +0000
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-16 20:19 +0000
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-16 21:27 +0000
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-17 08:44 +0000
Re: Old commercial UNIX in '26 Andy Burns <usenet@andyburns.uk> - 2026-06-16 21:39 +0100
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-16 21:19 +0000
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-16 21:29 +0000
Re: Old commercial UNIX in '26 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-16 12:59 +0000
Re: Old commercial UNIX in '26 Peter Flass <Peter@Iron-Spring.com> - 2026-06-16 07:30 -0700
Re: Old commercial UNIX in '26 "Phigan" <phigan@mutinybbs.com.remove-54f-this> - 2026-06-18 16:28 -0400
Re: Old commercial UNIX in '26 "Kurt Weiske" <kurt.weiske@realitycheckbbs.org.remove-83z-this> - 2026-06-20 08:22 -0700
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-20 18:59 +0000
Re: Old commercial UNIX in '26 "Kurt Weiske" <kurt.weiske@realitycheckbbs.org.remove-jv-this> - 2026-06-28 14:16 -0700
Re: Old commercial UNIX in '26 Bud Frede <frede@mouse-potato.com> - 2026-07-04 14:19 -0400
Re: Old commercial UNIX in '26 Bud Frede <frede@mouse-potato.com> - 2026-07-04 14:08 -0400
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-16 14:51 +0000
Re: Old commercial UNIX in '26 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-16 21:32 +0000
Re: Old commercial UNIX in '26 scott@slp53.sl.home (Scott Lurndal) - 2026-06-17 13:54 +0000
Re: Old commercial UNIX in '26 Bob Eager <throwaway0008@eager.cx> - 2026-06-17 14:21 +0000
Re: Old commercial UNIX in '26 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-17 19:35 +0000
[OT] Shifts in type of computing machinery (was: Re: Old commercial UNIX in '26) Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-18 08:56 +0100
Re: [OT] Shifts in type of computing machinery Lars Poulsen <lars@beagle-ears.com> - 2026-06-18 06:37 -0700
Re: [OT] Shifts in type of computing machinery Peter Flass <Peter@Iron-Spring.com> - 2026-06-18 07:57 -0700
Re: [OT] Shifts in type of computing machinery Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 22:51 +0000
Re: [OT] Shifts in type of computing machinery Peter Flass <Peter@Iron-Spring.com> - 2026-06-19 07:37 -0700
Re: [OT] Shifts in type of computing machinery Piper McCorkle <contact@piperswe.me> - 2026-06-19 18:46 +0200
Re: [OT] Shifts in type of computing machinery Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-20 09:28 +0100
Re: [OT] Shifts in type of computing machinery Lars Poulsen <lars@beagle-ears.com> - 2026-06-19 19:57 -0700
Re: [OT] Shifts in type of computing machinery Daniel Cerqueira <dan.list@lispclub.com> - 2026-06-18 15:27 +0100
Re: [OT] Shifts in type of computing machinery Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-21 09:15 +0100
Re: [OT] Shifts in type of computing machinery Peter Flass <Peter@Iron-Spring.com> - 2026-06-18 07:52 -0700
Re: [OT] Shifts in type of computing machinery Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 22:52 +0000
Re: Old commercial UNIX in '26 Anthk GM <anthk@disroot.org> - 2026-06-22 19:14 +0000
Re: Old commercial UNIX in '26 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-22 22:29 +0000
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-16 12:49 +0000 |
| Message-ID | <110rgoc$ldq$1@reader1.panix.com> |
| In reply to | #235044 |
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.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-16 14:40 +0000 |
| Message-ID | <wfdYR.493866$_BG8.262449@fx24.iad> |
| In reply to | #235050 |
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.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-17 11:49 +0000 |
| Message-ID | <110u1kp$g8g$1@reader1.panix.com> |
| In reply to | #235057 |
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? vxfs was a commercial thing, wasn't it? I guess with a clean DDI/DDK environment you can do things like that out-of-tree. >SGI had XFS, IBM had JFS which supported journaling, and there >was the clearcase (MVFS) filesystem as well. DEC had AdvFS as well, which I think came from MICA. 4.4BSD had a log-structured filesystem and started experimenting with some Plan 9'ish things. Soft updates for UFS fixed one of the major performance complaints for FFS. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-17 13:55 +0000 |
| Message-ID | <hHxYR.91908$tRR9.48494@fx23.iad> |
| In reply to | #235075 |
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: >>>>> “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? Yep. And a 14-character filename length limit.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-18 09:52 +0000 |
| Message-ID | <1110f4i$42r$1@reader1.panix.com> |
| In reply to | #235079 |
In article <hHxYR.91908$tRR9.48494@fx23.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >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: >>>>>> “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? > >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. :-) - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-18 14:45 +0000 |
| Message-ID | <iwTYR.68164$0o1c.32839@fx08.iad> |
| In reply to | #235087 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
>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. :-)
Even in Unixware, they maintained backward compatibility.
#ifndef DIRSIZ
#define DIRSIZ 14
#endif
typedef struct direct {
o_ino_t d_ino; /* s5 inode type */
char d_name[DIRSIZ];
} direct_t;
#define SDSIZ (sizeof(struct direct))
Not that anyone was actually using s5 filesystems that late
in the game.
[toc] | [prev] | [next] | [standalone]
| From | Piper McCorkle <contact@piperswe.me> |
|---|---|
| Date | 2026-06-16 21:59 +0200 |
| Message-ID | <nnd$330d094a$7f573b8a@590899249c30700a> |
| In reply to | #235050 |
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. > > - Dan C. 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! -- Piper McCorkle (she/her) contact@piperswe.me https://www.piperswe.me/ "Not ChatGPT output—I'm just like this" -https://www.xkcd.com/3126/
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2026-06-16 13:53 -0700 |
| Message-ID | <20260616135300.00006b48@gmail.com> |
| In reply to | #235064 |
On Tue, 16 Jun 2026 21:59:37 +0200 Piper McCorkle <contact@piperswe.me> wrote: > 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! Lots of interesting brains to pick here, indeed.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-17 12:00 +0000 |
| Message-ID | <110u29j$snt$1@reader1.panix.com> |
| In reply to | #235064 |
In article <nnd$330d094a$7f573b8a@590899249c30700a>, Piper McCorkle <contact@piperswe.me> wrote: >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! 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 - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-17 13:21 +0000 |
| Message-ID | <110u71k$6b6$1@reader1.panix.com> |
| In reply to | #235076 |
In article <110u29j$snt$1@reader1.panix.com>, Dan Cross <cross@spitfire.i.gajendra.net> wrote: >[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 Oops; this is for a different fsck (this is exactly what I mean about my being fallible; I should have double-checked the reference!). Here's a link to the actual `fsck` reference I was thinking of: https://docs-archive.freebsd.org/44doc/smm/03.fsck/paper.pdf >Soft updates: >https://www.usenix.org/legacy/publications/library/proceedings/usenix99/mckusick.html - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-15 19:35 +0000 |
| Message-ID | <110pk59$2tr$1@reader1.panix.com> |
| In reply to | #235018 |
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. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <throwaway0008@eager.cx> |
|---|---|
| Date | 2026-06-15 20:01 +0000 |
| Message-ID | <n9b417FkpanU6@mid.individual.net> |
| In reply to | #235037 |
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
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-16 12:50 +0000 |
| Message-ID | <110rgqh$9v6$1@reader1.panix.com> |
| In reply to | #235038 |
In article <n9b417FkpanU6@mid.individual.net>, Bob Eager <throwaway0008@eager.cx> wrote: >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 There ya' go. I set up a VAX running that and hooked it up to my packet radio station. No one ever logs in other than me, though. :-D - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-15 22:40 +0000 |
| Message-ID | <gb%XR.132106$I0Ta.47907@fx05.iad> |
| In reply to | #235037 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <throwaway0008@eager.cx> |
|---|---|
| Date | 2026-06-16 09:19 +0000 |
| Message-ID | <n9cip1FapsoU1@mid.individual.net> |
| In reply to | #235040 |
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).
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-16 13:00 +0000 |
| Message-ID | <110rhd2$4fn$1@reader1.panix.com> |
| In reply to | #235049 |
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? - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <throwaway0008@eager.cx> |
|---|---|
| Date | 2026-06-16 13:44 +0000 |
| Message-ID | <n9d29bFapsoU2@mid.individual.net> |
| In reply to | #235053 |
On Tue, 16 Jun 2026 13:00:18 +0000, Dan Cross wrote: > 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? Yes, but he'd gone by that time. And the moving target is probably still there.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-16 14:47 +0000 |
| Message-ID | <5mdYR.493867$_BG8.30443@fx24.iad> |
| In reply to | #235049 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <throwaway0008@eager.cx> |
|---|---|
| Date | 2026-06-16 14:59 +0000 |
| Message-ID | <n9d6mbFapsoU3@mid.individual.net> |
| In reply to | #235058 |
On Tue, 16 Jun 2026 14:47:29 +0000, Scott Lurndal wrote: > 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/ 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.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-16 16:24 +0000 |
| Message-ID | <SMeYR.66987$WQ_e.16586@fx14.iad> |
| In reply to | #235061 |
Bob Eager <throwaway0008@eager.cx> writes: >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? 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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web