From tuhs at tuhs.org Wed Apr 1 13:20:47 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 1 Apr 2026 13:20:47 +1000 Subject: [TUHS] Problems with TUHS and COFF mailing lists Message-ID: Hi all, I'm back from a 3 1/2 week overseas holiday. Of course, partway through the trip the TUHS server "minnie" decided to hit 0% free disk space. I was able to clean things out remotely using a tablet and Bluetooth keyboard. However, since then I've had a few e-mails saying that submissions to TUHS and COFF have gone to /dev/null. I haven't deduced the issue yet. So, if in the next few weeks you post to TUHS or COFF and you don't see your posting, please e-mail with as much details as you can provide; a copy of the logs from your mail server would be wonderful! Thanks, Warren From tuhs at tuhs.org Wed Apr 1 18:08:31 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 01 Apr 2026 08:08:31 +0000 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro Message-ID: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> Surprise surprise, another hyper-specific topic incoming. I am curious if anyone on-list can provide insight on this topic. Setting Up Unix - Seventh Edition indicates: > The tape is 9-track 800 BPI... Was this a matter of convention given the general computing ecosystem at the time, or was this more driven by Bell System standards for magtape? I find myself curious as I recently procured a 7-track 556 BPI transport which, while not applicable to V7 UNIX tapes as so described, has me itching to explore the world of magtape further, including eventually tracking down a 9-track supporting the necessary BPI should another UNIX tape needing preservation surface. I also recently got a QIC drive (not the right size for the early 90s BTL tapes I have) and am exploring repurposing the read head to yank data off these janky QIC tapes I have. Needless to say, magnetic tape media and preservation is on the mind lately. Further on the subject of UNIX tapes though, was there any regular shipment of other media not matching this description or was it pretty settled that order_unix() has a return type of mt_track_9_bpi_800_t ? - Matt G. From tuhs at tuhs.org Wed Apr 1 18:51:12 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 01 Apr 2026 02:51:12 -0600 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> References: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> Message-ID: <202604010851.6318pCpZ096750@freefriends.org> In that time frame, 800 BPI was pretty standard. 9 tracks gave you eight bits of data plus a parity bit. By the mid-80s, 1600 BPI was pretty common for the same media, so the BSD distributions might have been 1600 BPI tapes. I think at some point 9 track tape drives hit something like 6400 BPI, but I may be hallucinating the memory. HTH, Arnold segaloco via TUHS wrote: > Surprise surprise, another hyper-specific topic incoming. I am curious > if anyone on-list can provide insight on this topic. Setting Up Unix - > Seventh Edition indicates: > > > The tape is 9-track 800 BPI... > > Was this a matter of convention given the general computing ecosystem at > the time, or was this more driven by Bell System standards for magtape? > > I find myself curious as I recently procured a 7-track 556 BPI transport > which, while not applicable to V7 UNIX tapes as so described, has me > itching to explore the world of magtape further, including eventually > tracking down a 9-track supporting the necessary BPI should another UNIX > tape needing preservation surface. > > I also recently got a QIC drive (not the right size for the early 90s > BTL tapes I have) and am exploring repurposing the read head to yank > data off these janky QIC tapes I have. Needless to say, magnetic tape > media and preservation is on the mind lately. > > Further on the subject of UNIX tapes though, was there any regular > shipment of other media not matching this description or was it pretty > settled that > > order_unix() > > has a return type of > > mt_track_9_bpi_800_t > > ? > > - Matt G. From tuhs at tuhs.org Wed Apr 1 20:10:39 2026 From: tuhs at tuhs.org (Peter Yardley via TUHS) Date: Wed, 1 Apr 2026 21:10:39 +1100 Subject: [TUHS] Fwd: Choice of Tape Format for BTL UNIX Distro References: <202604010941.6319f4uM099912@freefriends.org> Message-ID: Thanks I’ll try sending this to the list. > Begin forwarded message: > > From: arnold at skeeve.com > Subject: Re: [TUHS] Choice of Tape Format for BTL UNIX Distro > Date: 1 April 2026 at 8:41:04 pm AEDT > To: peter.martin.yardley at gmail.com, arnold at skeeve.com > > I don't see the list in the To: or CC: > > Thanks for confirming my memory that 6400 BPI drives existed. > > Peter Yardley wrote: > >> Don’t know if this will hit the list. >> >> My memory is we had a 1600 BPI tape drive. Of course that would have read 800BPi tapes. >> >> The 6400 BPI drives were much more expensive so not everyone had one. >> >>> On 1 Apr 2026, at 7:51 pm, Arnold Robbins via TUHS wrote: >>> >>> In that time frame, 800 BPI was pretty standard. 9 tracks gave you >>> eight bits of data plus a parity bit. >>> >>> By the mid-80s, 1600 BPI was pretty common for the same media, so >>> the BSD distributions might have been 1600 BPI tapes. >>> >>> I think at some point 9 track tape drives hit something like 6400 BPI, >>> but I may be hallucinating the memory. >>> >>> HTH, >>> >>> Arnold >>> >>> segaloco via TUHS wrote: >>> >>>> Surprise surprise, another hyper-specific topic incoming. I am curious >>>> if anyone on-list can provide insight on this topic. Setting Up Unix - >>>> Seventh Edition indicates: >>>> >>>>> The tape is 9-track 800 BPI... >>>> >>>> Was this a matter of convention given the general computing ecosystem at >>>> the time, or was this more driven by Bell System standards for magtape? >>>> >>>> I find myself curious as I recently procured a 7-track 556 BPI transport >>>> which, while not applicable to V7 UNIX tapes as so described, has me >>>> itching to explore the world of magtape further, including eventually >>>> tracking down a 9-track supporting the necessary BPI should another UNIX >>>> tape needing preservation surface. >>>> >>>> I also recently got a QIC drive (not the right size for the early 90s >>>> BTL tapes I have) and am exploring repurposing the read head to yank >>>> data off these janky QIC tapes I have. Needless to say, magnetic tape >>>> media and preservation is on the mind lately. >>>> >>>> Further on the subject of UNIX tapes though, was there any regular >>>> shipment of other media not matching this description or was it pretty >>>> settled that >>>> >>>> order_unix() >>>> >>>> has a return type of >>>> >>>> mt_track_9_bpi_800_t >>>> >>>> ? >>>> >>>> - Matt G. >> >> >> .1.3.6.1.4.1.8852.4.2 >> Peter Yardley >> peter.martin.yardley at gmail.com .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From tuhs at tuhs.org Wed Apr 1 20:18:31 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 01 Apr 2026 04:18:31 -0600 Subject: [TUHS] Fwd: Choice of Tape Format for BTL UNIX Distro In-Reply-To: References: <202604010941.6319f4uM099912@freefriends.org> Message-ID: <202604011018.631AIVqY002680@freefriends.org> Clem Cole reminds me that the denser drives were 6250 BPI, not 6400. Thanks, Arnold Peter Yardley via TUHS wrote: > Thanks I’ll try sending this to the list. > > > Begin forwarded message: > > > > From: arnold at skeeve.com > > Subject: Re: [TUHS] Choice of Tape Format for BTL UNIX Distro > > Date: 1 April 2026 at 8:41:04 pm AEDT > > To: peter.martin.yardley at gmail.com, arnold at skeeve.com > > > > I don't see the list in the To: or CC: > > > > Thanks for confirming my memory that 6400 BPI drives existed. > > > > Peter Yardley wrote: > > > >> Don’t know if this will hit the list. > >> > >> My memory is we had a 1600 BPI tape drive. Of course that would have read 800BPi tapes. > >> > >> The 6400 BPI drives were much more expensive so not everyone had one. > >> > >>> On 1 Apr 2026, at 7:51 pm, Arnold Robbins via TUHS wrote: > >>> > >>> In that time frame, 800 BPI was pretty standard. 9 tracks gave you > >>> eight bits of data plus a parity bit. > >>> > >>> By the mid-80s, 1600 BPI was pretty common for the same media, so > >>> the BSD distributions might have been 1600 BPI tapes. > >>> > >>> I think at some point 9 track tape drives hit something like 6400 BPI, > >>> but I may be hallucinating the memory. > >>> > >>> HTH, > >>> > >>> Arnold > >>> > >>> segaloco via TUHS wrote: > >>> > >>>> Surprise surprise, another hyper-specific topic incoming. I am curious > >>>> if anyone on-list can provide insight on this topic. Setting Up Unix - > >>>> Seventh Edition indicates: > >>>> > >>>>> The tape is 9-track 800 BPI... > >>>> > >>>> Was this a matter of convention given the general computing ecosystem at > >>>> the time, or was this more driven by Bell System standards for magtape? > >>>> > >>>> I find myself curious as I recently procured a 7-track 556 BPI transport > >>>> which, while not applicable to V7 UNIX tapes as so described, has me > >>>> itching to explore the world of magtape further, including eventually > >>>> tracking down a 9-track supporting the necessary BPI should another UNIX > >>>> tape needing preservation surface. > >>>> > >>>> I also recently got a QIC drive (not the right size for the early 90s > >>>> BTL tapes I have) and am exploring repurposing the read head to yank > >>>> data off these janky QIC tapes I have. Needless to say, magnetic tape > >>>> media and preservation is on the mind lately. > >>>> > >>>> Further on the subject of UNIX tapes though, was there any regular > >>>> shipment of other media not matching this description or was it pretty > >>>> settled that > >>>> > >>>> order_unix() > >>>> > >>>> has a return type of > >>>> > >>>> mt_track_9_bpi_800_t > >>>> > >>>> ? > >>>> > >>>> - Matt G. > >> > >> > >> .1.3.6.1.4.1.8852.4.2 > >> Peter Yardley > >> peter.martin.yardley at gmail.com > > > .1.3.6.1.4.1.8852.4.2 > Peter Yardley > peter.martin.yardley at gmail.com > From tuhs at tuhs.org Wed Apr 1 21:17:36 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 1 Apr 2026 07:17:36 -0400 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: <202604010851.6318pCpZ096750@freefriends.org> References: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> <202604010851.6318pCpZ096750@freefriends.org> Message-ID: Matt, 1/2” 7-track magnetic tape was developed assuming the then 6-bit byte of early computers (IIRC by Univac originally). Tape was an imperfect media, so a 7th parity bit was added to help detect errors. Each byte plus its parity is written in parallel on the tape. In 1964, when Fred Brooks required Gene Amdahl to make a byte and a full word on the S/360 a power of two, the 9-track transport was created allowing a user can store a byte (8-bit) + parity. The traditional ½” magnetic tape reels varied in diameter depending on the tape length, with standard 9-track capacities ranging from 20 MB to 220 MB depending on the recording encoding and density a block size (used to reduce the IRGs). Also, remember 9-track was defined assuming start/stop operation of the tape transport (as opposed to streaming - used in ¼”, 4mm and many later DLT formats). The reason is that time is needed to “spin up” or “slow down” the tape reel motor between read or write operations - so the size of IRG is part of the ANSI standard. When the QIC standard was developed the assumption is that once started, the motor doesn’t stop. Data must be ready for the drive on writes or under run occurs, and motor stops backs up the tape and starts again when it has data [over run occurrs on read when the host cannot accept the data]. Also modern “streamers” write serially and traditionally use a serpentine data path and read/write in both direction. ½” tape media has been sold in the three factors, with the diameter of the reel determined by the total length of the tape it was designed to hold: - *600’*: 7-inch diameter reel. - *1200’*: 8.5-inch diameter reel. - *2400’*: 10.5-inch diameter reel (the most common industry standard). There was also a 3600’ tape made by 3M that used a thinner tape, so it fit on a 2400’ reel. The downside, was the risk of stretching, so it was ok as an archival (write once) use, but could be risky when used for things like incremental backup where the physical tape was reused many times. *Capacities and Recording Schemes* Each standard density used a specific encoding method to ensure data integrity and timing. Capacities listed below are approximate for a standard *2400’* reel: *800 bpi* *NRZI*(Non-Return-to-Zero, Inverted) *20–22.5 MB* Older format where a "1" bit is represented by a change in magnetic state. *1600 bpi* *PE* (Phase Encoding) *40–45 MB* Most common interchange format; every bit is represented by a transition in the middle of a bit cell. *6250 bpi* *GCR*(Group Coded Recording) *140–175 MB* High-density format using complex error detection and correction codes.It was often achieved by modifying the Phase Encoding (PE) scheme to double the recording density (sometimes called "Double Density PE"). It was popular on desktop/minicomputer drives in the 1980s to create higher-density tapes on a budget before 6250 GCR became universal. I don’t remember if it had a ANSI standard, but Cipher created 3200 bpi option, that I believe a couple of other transport vendors offered (IIRC Overland Data, but I don’t remember if Kennedy did also). The 3200 bpi encoding achieved by modifying the Phase Encoding (PE) scheme to double the recording density (sometimes called "Double Density PE"). It was popular on workstation/minicomputer drives in the 1980s to create higher-density tapes on a budget before 6250 GCR became universal. *Note: the capacity of a tape is highly dependent on the block **size/factor used; smaller blocks increased the number of Inter-Record Gaps (IRGs) [**reducing capacity]. Record sizes were traditionally limited to under 64k bytes as the tape controllers of the day were often unable to support records of larger size. With 512 byte block used by the minicomputers, blocking factors of 10 or 20 times such as tar’s 20b (10240 bytes) became a defacto standard. 36-bit systems like the PDP-10 often used record sizes such as 512 words * 36 bits + some header (2950 was typical) and the IBM mainframes were all over the map. * Sent from a handheld expect more typos than usual On Wed, Apr 1, 2026 at 4:51 AM Arnold Robbins via TUHS wrote: > In that time frame, 800 BPI was pretty standard. 9 tracks gave you > eight bits of data plus a parity bit. > > By the mid-80s, 1600 BPI was pretty common for the same media, so > the BSD distributions might have been 1600 BPI tapes. > > I think at some point 9 track tape drives hit something like 6400 BPI, > but I may be hallucinating the memory. > > HTH, > > Arnold > > segaloco via TUHS wrote: > > > Surprise surprise, another hyper-specific topic incoming. I am curious > > if anyone on-list can provide insight on this topic. Setting Up Unix - > > Seventh Edition indicates: > > > > > The tape is 9-track 800 BPI... > > > > Was this a matter of convention given the general computing ecosystem at > > the time, or was this more driven by Bell System standards for magtape? > > > > I find myself curious as I recently procured a 7-track 556 BPI transport > > which, while not applicable to V7 UNIX tapes as so described, has me > > itching to explore the world of magtape further, including eventually > > tracking down a 9-track supporting the necessary BPI should another UNIX > > tape needing preservation surface. > > > > I also recently got a QIC drive (not the right size for the early 90s > > BTL tapes I have) and am exploring repurposing the read head to yank > > data off these janky QIC tapes I have. Needless to say, magnetic tape > > media and preservation is on the mind lately. > > > > Further on the subject of UNIX tapes though, was there any regular > > shipment of other media not matching this description or was it pretty > > settled that > > > > order_unix() > > > > has a return type of > > > > mt_track_9_bpi_800_t > > > > ? > > > > - Matt G. > From tuhs at tuhs.org Wed Apr 1 21:24:36 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 1 Apr 2026 07:24:36 -0400 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: References: <0_pCTqJs25OWOWWkqXp1O2Rq8EA5Is0KtZHS0KBj6YnVBJIqHeWUkQDYaEi8xUfDlPvecAS5vvztFa-oyYcClrpJy0HJ8z9OlS6OXXrbcMQ=@protonmail.com> <202604010851.6318pCpZ096750@freefriends.org> Message-ID: Bad cut & paste on the iPhone. The comment field on GCR included stuff and PE that should not been there (GCR and PE are unrelated in this case). It should have simply read: “High-density format using complex error detection and correction codes.” Sent from a handheld expect more typos than usual On Wed, Apr 1, 2026 at 7:17 AM Clem Cole wrote: > Matt, > > 1/2” 7-track magnetic tape was developed assuming the then 6-bit byte of > early computers (IIRC by Univac originally). Tape was an imperfect media, > so a 7th parity bit was added to help detect errors. Each byte plus its > parity is written in parallel on the tape. In 1964, when Fred Brooks > required Gene Amdahl to make a byte and a full word on the S/360 a power of > two, the 9-track transport was created allowing a user can store a byte > (8-bit) + parity. > > The traditional ½” magnetic tape reels varied in diameter depending on > the tape length, with standard 9-track capacities ranging from 20 MB to > 220 MB depending on the recording encoding and density a block size (used > to reduce the IRGs). Also, remember 9-track was defined assuming > start/stop operation of the tape transport (as opposed to streaming - used > in ¼”, 4mm and many later DLT formats). The reason is that time is needed > to “spin up” or “slow down” the tape reel motor between read or write > operations - so the size of IRG is part of the ANSI standard. When the QIC > standard was developed the assumption is that once started, the motor > doesn’t stop. Data must be ready for the drive on writes or under run > occurs, and motor stops backs up the tape and starts again when it has data > [over run occurrs on read when the host cannot accept the data]. Also > modern “streamers” write serially and traditionally use a serpentine data > path and read/write in both direction. > > ½” tape media has been sold in the three factors, with the diameter of > the reel determined by the total length of the tape it was designed to hold: > > > - *600’*: 7-inch diameter reel. > - *1200’*: 8.5-inch diameter reel. > - *2400’*: 10.5-inch diameter reel (the most common industry standard). > > > There was also a 3600’ tape made by 3M that used a thinner tape, so it fit > on a 2400’ reel. The downside, was the risk of stretching, so it was ok as > an archival (write once) use, but could be risky when used for things like > incremental backup where the physical tape was reused many times. > > *Capacities and Recording Schemes* > > Each standard density used a specific encoding method to ensure data > integrity and timing. Capacities listed below are approximate for a > standard *2400’* reel: > > > *800 bpi* *NRZI*(Non-Return-to-Zero, Inverted) *20–22.5 MB* Older format > where a "1" bit is represented by a change in magnetic state. > *1600 bpi* *PE* (Phase Encoding) *40–45 MB* Most common interchange > format; every bit is represented by a transition in the middle of a bit > cell. > *6250 bpi* *GCR*(Group Coded Recording) *140–175 MB* High-density format > using complex error detection and correction codes.It was often achieved > by modifying the Phase Encoding (PE) scheme to double the recording density > (sometimes called "Double Density PE"). It was popular on > desktop/minicomputer drives in the 1980s to create higher-density tapes on > a budget before 6250 GCR became universal. > I don’t remember if it had a ANSI standard, but Cipher created 3200 bpi > option, that I believe a couple of other transport vendors offered (IIRC > Overland Data, but I don’t remember if Kennedy did also). The 3200 bpi > encoding achieved by modifying the Phase Encoding (PE) scheme to double the > recording density (sometimes called "Double Density PE"). It was popular on > workstation/minicomputer drives in the 1980s to create higher-density tapes > on a budget before 6250 GCR became universal. > > > *Note: the capacity of a tape is highly dependent on the block **size/factor used; > smaller blocks increased the number of Inter-Record Gaps (IRGs) [**reducing > capacity]. Record sizes were traditionally limited to under 64k bytes as > the tape controllers of the day were often unable to support records of > larger size. With 512 byte block used by the minicomputers, blocking > factors of 10 or 20 times such as tar’s 20b (10240 bytes) became a defacto > standard. 36-bit systems like the PDP-10 often used record sizes such as > 512 words * 36 bits + some header (2950 was typical) and the IBM mainframes > were all over the map. * > > Sent from a handheld expect more typos than usual > > > On Wed, Apr 1, 2026 at 4:51 AM Arnold Robbins via TUHS > wrote: > >> In that time frame, 800 BPI was pretty standard. 9 tracks gave you >> eight bits of data plus a parity bit. >> >> By the mid-80s, 1600 BPI was pretty common for the same media, so >> the BSD distributions might have been 1600 BPI tapes. >> >> I think at some point 9 track tape drives hit something like 6400 BPI, >> but I may be hallucinating the memory. >> >> HTH, >> >> Arnold >> >> segaloco via TUHS wrote: >> >> > Surprise surprise, another hyper-specific topic incoming. I am curious >> > if anyone on-list can provide insight on this topic. Setting Up Unix - >> > Seventh Edition indicates: >> > >> > > The tape is 9-track 800 BPI... >> > >> > Was this a matter of convention given the general computing ecosystem at >> > the time, or was this more driven by Bell System standards for magtape? >> > >> > I find myself curious as I recently procured a 7-track 556 BPI transport >> > which, while not applicable to V7 UNIX tapes as so described, has me >> > itching to explore the world of magtape further, including eventually >> > tracking down a 9-track supporting the necessary BPI should another UNIX >> > tape needing preservation surface. >> > >> > I also recently got a QIC drive (not the right size for the early 90s >> > BTL tapes I have) and am exploring repurposing the read head to yank >> > data off these janky QIC tapes I have. Needless to say, magnetic tape >> > media and preservation is on the mind lately. >> > >> > Further on the subject of UNIX tapes though, was there any regular >> > shipment of other media not matching this description or was it pretty >> > settled that >> > >> > order_unix() >> > >> > has a return type of >> > >> > mt_track_9_bpi_800_t >> > >> > ? >> > >> > - Matt G. >> > From tuhs at tuhs.org Thu Apr 2 08:07:20 2026 From: tuhs at tuhs.org (Peter Yardley via TUHS) Date: Thu, 2 Apr 2026 09:07:20 +1100 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: References: <202604010941.6319f4uM099912@freefriends.org> Message-ID: <8C84C7FC-4DB7-4F72-A99A-0DE97A27E1CB@gmail.com> Thanks Clem My submissions to the list were getting lost. Been about 30 years since I last used tape in anger. Your answer was quite comprehensive. > On 1 Apr 2026, at 11:11 pm, Clem Cole wrote: > > Take a look at what I sent to whole list. If you have questions let me know off list. Clem > > Sent from a handheld expect more typos than usual > > > On Wed, Apr 1, 2026 at 6:11 AM Peter Yardley via TUHS wrote: > Thanks I’ll try sending this to the list. > > > Begin forwarded message: > > > > From: arnold at skeeve.com > > Subject: Re: [TUHS] Choice of Tape Format for BTL UNIX Distro > > Date: 1 April 2026 at 8:41:04 pm AEDT > > To: peter.martin.yardley at gmail.com, arnold at skeeve.com > > > > I don't see the list in the To: or CC: > > > > Thanks for confirming my memory that 6400 BPI drives existed. > > > > Peter Yardley wrote: > > > >> Don’t know if this will hit the list. > >> > >> My memory is we had a 1600 BPI tape drive. Of course that would have read 800BPi tapes. > >> > >> The 6400 BPI drives were much more expensive so not everyone had one. > >> > >>> On 1 Apr 2026, at 7:51 pm, Arnold Robbins via TUHS wrote: > >>> > >>> In that time frame, 800 BPI was pretty standard. 9 tracks gave you > >>> eight bits of data plus a parity bit. > >>> > >>> By the mid-80s, 1600 BPI was pretty common for the same media, so > >>> the BSD distributions might have been 1600 BPI tapes. > >>> > >>> I think at some point 9 track tape drives hit something like 6400 BPI, > >>> but I may be hallucinating the memory. > >>> > >>> HTH, > >>> > >>> Arnold > >>> > >>> segaloco via TUHS wrote: > >>> > >>>> Surprise surprise, another hyper-specific topic incoming. I am curious > >>>> if anyone on-list can provide insight on this topic. Setting Up Unix - > >>>> Seventh Edition indicates: > >>>> > >>>>> The tape is 9-track 800 BPI... > >>>> > >>>> Was this a matter of convention given the general computing ecosystem at > >>>> the time, or was this more driven by Bell System standards for magtape? > >>>> > >>>> I find myself curious as I recently procured a 7-track 556 BPI transport > >>>> which, while not applicable to V7 UNIX tapes as so described, has me > >>>> itching to explore the world of magtape further, including eventually > >>>> tracking down a 9-track supporting the necessary BPI should another UNIX > >>>> tape needing preservation surface. > >>>> > >>>> I also recently got a QIC drive (not the right size for the early 90s > >>>> BTL tapes I have) and am exploring repurposing the read head to yank > >>>> data off these janky QIC tapes I have. Needless to say, magnetic tape > >>>> media and preservation is on the mind lately. > >>>> > >>>> Further on the subject of UNIX tapes though, was there any regular > >>>> shipment of other media not matching this description or was it pretty > >>>> settled that > >>>> > >>>> order_unix() > >>>> > >>>> has a return type of > >>>> > >>>> mt_track_9_bpi_800_t > >>>> > >>>> ? > >>>> > >>>> - Matt G. > >> > >> > >> .1.3.6.1.4.1.8852.4.2 > >> Peter Yardley > >> peter.martin.yardley at gmail.com > > > .1.3.6.1.4.1.8852.4.2 > Peter Yardley > peter.martin.yardley at gmail.com > .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From tuhs at tuhs.org Thu Apr 2 09:04:51 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 01 Apr 2026 23:04:51 +0000 Subject: [TUHS] More Lost BTL UNIX Literature Procured Message-ID: Howdy folks, I've got some exciting news for UNIX document preservation. I just closed this purchase: https://www.ebay.com/itm/147235873077 After the link is an auction for several original BTL UNIX manuals and technical memoranda, including: Documents for UNIX - Sixth Edition Seventh Edition Volume 2A/2B UNIX Product Release Description - Release 4.0 Program Generic PG-1C300 Issue 3 UNIX Release 4.0 Release Notes Package Several Technical Memoranda For me the most exciting parts are the Release 4.0 material and the Program Generic Issue 3 manual. This all should be arriving in a week or two, at which point I'll bump it to the top of my scan list (right under the SVR2 BTL manual I'm halfway through right now). More to come! Also, the seller also has original print BBN UNIX literature, I expressed no personal interest as I'm keeping focused on BTL and UCB, but I'll share when that auction is posted as they seem like quite rare pieces someone here might be interested in. - Matt G. From tuhs at tuhs.org Thu Apr 2 09:16:28 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 1 Apr 2026 19:16:28 -0400 Subject: [TUHS] Choice of Tape Format for BTL UNIX Distro In-Reply-To: <8C84C7FC-4DB7-4F72-A99A-0DE97A27E1CB@gmail.com> References: <202604010941.6319f4uM099912@freefriends.org> <8C84C7FC-4DB7-4F72-A99A-0DE97A27E1CB@gmail.com> Message-ID: Most welcome. Glad it was helpful. I’ve actually been considered a tape wizard by many of my friends. It really goes back to learning my learn how to handle tapes on TSS/360 an Exec 8 on the Univac, early in my career. The later had three 7-track drives (5-20 M 6-bit bytes) and very little drum/disk. I still can speak a bit of the language with term like LRECL [Logical RECord length - IBM speak for block size]. Tapes often had file systems on them. Technically that can be read or written in both directions in the old mainframe world. Sent from a handheld expect more typos than usual On Wed, Apr 1, 2026 at 6:07 PM Peter Yardley wrote: > Thanks Clem > > My submissions to the list were getting lost. > > Been about 30 years since I last used tape in anger. Your answer was quite > comprehensive. > > > On 1 Apr 2026, at 11:11 pm, Clem Cole wrote: > > > > Take a look at what I sent to whole list. If you have questions let me > know off list. Clem > > > > Sent from a handheld expect more typos than usual > > > > > > On Wed, Apr 1, 2026 at 6:11 AM Peter Yardley via TUHS > wrote: > > Thanks I’ll try sending this to the list. > > > > > Begin forwarded message: > > > > > > From: arnold at skeeve.com > > > Subject: Re: [TUHS] Choice of Tape Format for BTL UNIX Distro > > > Date: 1 April 2026 at 8:41:04 pm AEDT > > > To: peter.martin.yardley at gmail.com, arnold at skeeve.com > > > > > > I don't see the list in the To: or CC: > > > > > > Thanks for confirming my memory that 6400 BPI drives existed. > > > > > > Peter Yardley wrote: > > > > > >> Don’t know if this will hit the list. > > >> > > >> My memory is we had a 1600 BPI tape drive. Of course that would have > read 800BPi tapes. > > >> > > >> The 6400 BPI drives were much more expensive so not everyone had one. > > >> > > >>> On 1 Apr 2026, at 7:51 pm, Arnold Robbins via TUHS > wrote: > > >>> > > >>> In that time frame, 800 BPI was pretty standard. 9 tracks gave you > > >>> eight bits of data plus a parity bit. > > >>> > > >>> By the mid-80s, 1600 BPI was pretty common for the same media, so > > >>> the BSD distributions might have been 1600 BPI tapes. > > >>> > > >>> I think at some point 9 track tape drives hit something like 6400 > BPI, > > >>> but I may be hallucinating the memory. > > >>> > > >>> HTH, > > >>> > > >>> Arnold > > >>> > > >>> segaloco via TUHS wrote: > > >>> > > >>>> Surprise surprise, another hyper-specific topic incoming. I am > curious > > >>>> if anyone on-list can provide insight on this topic. Setting Up > Unix - > > >>>> Seventh Edition indicates: > > >>>> > > >>>>> The tape is 9-track 800 BPI... > > >>>> > > >>>> Was this a matter of convention given the general computing > ecosystem at > > >>>> the time, or was this more driven by Bell System standards for > magtape? > > >>>> > > >>>> I find myself curious as I recently procured a 7-track 556 BPI > transport > > >>>> which, while not applicable to V7 UNIX tapes as so described, has me > > >>>> itching to explore the world of magtape further, including > eventually > > >>>> tracking down a 9-track supporting the necessary BPI should another > UNIX > > >>>> tape needing preservation surface. > > >>>> > > >>>> I also recently got a QIC drive (not the right size for the early > 90s > > >>>> BTL tapes I have) and am exploring repurposing the read head to yank > > >>>> data off these janky QIC tapes I have. Needless to say, magnetic > tape > > >>>> media and preservation is on the mind lately. > > >>>> > > >>>> Further on the subject of UNIX tapes though, was there any regular > > >>>> shipment of other media not matching this description or was it > pretty > > >>>> settled that > > >>>> > > >>>> order_unix() > > >>>> > > >>>> has a return type of > > >>>> > > >>>> mt_track_9_bpi_800_t > > >>>> > > >>>> ? > > >>>> > > >>>> - Matt G. > > >> > > >> > > >> .1.3.6.1.4.1.8852.4.2 > > >> Peter Yardley > > >> peter.martin.yardley at gmail.com > > > > > > .1.3.6.1.4.1.8852.4.2 > > Peter Yardley > > peter.martin.yardley at gmail.com > > > > > .1.3.6.1.4.1.8852.4.2 > Peter Yardley > peter.martin.yardley at gmail.com > > From tuhs at tuhs.org Thu Apr 2 16:41:25 2026 From: tuhs at tuhs.org (Rich Kulawiec via TUHS) Date: Thu, 2 Apr 2026 02:41:25 -0400 Subject: [TUHS] George Goble (Purdue University) In-Reply-To: References: <20260323135651.GA4848@gsp.org> Message-ID: <20260402064125.GA25443@gsp.org> On Mon, Mar 23, 2026 at 10:24:44PM +0100, Martin Schr??der via TUHS wrote: > Is there an "official" obituary somewhere that can be cited by e.g. Wikipedia? There is. The link was sent by one of the other long, LONG-time Purdue folks: George Goble - Obituary - Journal and Courier https://www.jconline.com/obituaries/psbn1445636 ---rsk From tuhs at tuhs.org Mon Apr 6 17:37:10 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 06 Apr 2026 07:37:10 +0000 Subject: [TUHS] 9P Communities like TUHS? Message-ID: So several recommendations here coupled with a recent system transition has finally landed me on 9front for my personal computer. I'm super excited to finally take this step, its a long time coming. I was curious if anyone can recommend a community much like this but 9P focused? I haven't "started fresh" since I first picked up GNU nearly 2 decades ago now, so its an exciting time of discovery and learning I'd love to find some folks to chit chat with. - Matt G. P.S. Big UNIX manual shipment slated for tomorrow. Between that and now aiming to get a full 9front print manual set...I'm gonna need a bigger bookshelf... From tuhs at tuhs.org Mon Apr 6 20:47:34 2026 From: tuhs at tuhs.org (=?utf-8?q?Rodrigo_G=2E_L=C3=B3pez_via_TUHS?=) Date: Mon, 6 Apr 2026 12:47:34 +0200 Subject: [TUHS] 9P Communities like TUHS? In-Reply-To: References: Message-ID: hi matt, you should join the 9front ml: https://lists.9front.org/ welcome! -rodri On Mon, Apr 6, 2026, 09:37 segaloco via TUHS wrote: > So several recommendations here coupled with a recent system transition > has finally landed me on 9front for my personal computer. I'm super > excited to finally take this step, its a long time coming. I was curious > if anyone can recommend a community much like this but 9P focused? I > haven't "started fresh" since I first picked up GNU nearly 2 decades ago > now, so its an exciting time of discovery and learning I'd love to find > some folks to chit chat with. > > - Matt G. > > P.S. Big UNIX manual shipment slated for tomorrow. Between that and now > aiming to get a full 9front print manual set...I'm gonna need a bigger > bookshelf... > From tuhs at tuhs.org Mon Apr 6 23:21:03 2026 From: tuhs at tuhs.org (Stanley Lieber via TUHS) Date: Mon, 6 Apr 2026 09:21:03 -0400 Subject: [TUHS] 9p discussion Message-ID: <5282DF63-A000-4019-8A79-20E3D18C24AE@stanleylieber.com> hello, i saw your post on tuhs. you’ll probably dig this up eventually, but: https://fqa.9front.org/fqa2.html#2.2 regards, sl From tuhs at tuhs.org Mon Apr 6 23:43:29 2026 From: tuhs at tuhs.org (Sevan Janiyan via TUHS) Date: Mon, 6 Apr 2026 14:43:29 +0100 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> Message-ID: <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> On 27/03/2026 05:05, Greg 'groggy' Lehey wrote: > OK, I've tried in a different system and got the same errors, so it's > the CD. But strangely I could mount it, and I've made a tar archive > of it:http://lax.lemis.com/grog/panic-cdrom.tar. It's only 1722 kB > in size. I can untar it and get the files, but of course I can't > confirm that they're correct. Can you compare? Thanks for digging in, Greg. Unfortunately your URL never worked for me. A kind person sent me an archive from their CD, off-list, which I've posted on my site. Just to be helpful to scrapers, the file is up at /files/panic-cdrom-files.zip on the domain of my email address, accessible via HTTPS :-) Sincerely, Sevan From tuhs at tuhs.org Tue Apr 7 02:47:12 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Mon, 06 Apr 2026 18:47:12 +0200 Subject: [TUHS] 9p discussion In-Reply-To: <5282DF63-A000-4019-8A79-20E3D18C24AE@stanleylieber.com> References: <5282DF63-A000-4019-8A79-20E3D18C24AE@stanleylieber.com> Message-ID: <20260406164712.MG3cTU5i@steffen%sdaoden.eu> Stanley Lieber via TUHS wrote in <5282DF63-A000-4019-8A79-20E3D18C24AE at stanleylieber.com>: |i saw your post on tuhs. you’ll probably dig this up eventually, but: | |https://fqa.9front.org/fqa2.html#2.2 And i wanted to post the following, but did not yet. Hello Stanley! Rodrigo G. López via TUHS wrote in : |On Mon, Apr 6, 2026, 09:37 segaloco via TUHS wrote: | |> So several recommendations here coupled with a recent system transition |> has finally landed me on 9front for my personal computer. I'm super |> excited to finally take this step, its a long time coming. I was curious |> if anyone can recommend a community much like this but 9P focused? I |> haven't "started fresh" since I first picked up GNU nearly 2 decades ago |> now, so its an exciting time of discovery and learning I'd love to find |> some folks to chit chat with. |> |> - Matt G. |> |> P.S. Big UNIX manual shipment slated for tomorrow. Between that and now |> aiming to get a full 9front print manual set...I'm gonna need a bigger |> bookshelf... |you should join the 9front ml: https://lists.9front.org/ And 9fans at 9fans.net (the ~"what were they thinking?" group, posted after the last systemcall was added to the "labs version" ... sysnsec?), at times posts appear. And plan9port-dev at googlegroups.com for the plan9-on-XY layer. The "Introduction to Operating Systems Abstractions. Using Plan9 from Bell Labs" of Francisco J Ballesteros is a great book. (The V4 commentary of Rodriguez "just appeared", also is, i find.) I kept a farewell program that umbraticus_at_prosimetrum_dot_com posted once Mycroftiv, a well known person in the Plan9 community, died, and that source code alone is so "extraterristrian" in the Linux / BSD* environment i live in! My terminal (font) cannot even display it in full. UNIX boy and girl become real Eunuchs when facing Plan9. So they sing higher. What i also like is their coding style, "continued" on 9front. That is the style Kernighan used in v6's RAT[FOR], and Johnson used in v6's yacc, in 1975. Fun fact: it seems the gigabyte big clang compiler framework, which also includes a code formatter, is incapable to be configurable to reiterate this coding style! Eg for(i=0; i References: Message-ID: On Monday, April 6th, 2026 at 03:48, Rodrigo G. López via TUHS wrote: > hi matt, > > you should join the 9front ml: https://lists.9front.org/ > > welcome! > > > -rodri > > On Mon, Apr 6, 2026, 09:37 segaloco via TUHS wrote: > > > So several recommendations here coupled with a recent system transition > > has finally landed me on 9front for my personal computer. I'm super > > excited to finally take this step, its a long time coming. I was curious > > if anyone can recommend a community much like this but 9P focused? I > > haven't "started fresh" since I first picked up GNU nearly 2 decades ago > > now, so its an exciting time of discovery and learning I'd love to find > > some folks to chit chat with. > > > > - Matt G. > > > > P.S. Big UNIX manual shipment slated for tomorrow. Between that and now > > aiming to get a full 9front print manual set...I'm gonna need a bigger > > bookshelf... > > > Thanks for the recommendations everyone! I try and keep my subscription list pretty small so appreciate the opportunity for some second opinions before I go signing up for a new list. - Matt G. From tuhs at tuhs.org Tue Apr 7 07:02:07 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Mon, 6 Apr 2026 14:02:07 -0700 Subject: [TUHS] the device tree, hardware, and kernels. Message-ID: I'm trying to refresh my memory on something. The first machines to have a device tree were, .. Sun 4/Power/Mac? Of these, which was first, first? The intent of the device tree was to be embedded in a ROM (or writable ROM) such that a kernel could figure out properties of hardware, as I recall. Is this even vaguely correct? It seems to track with my current digging. The reason I ask: somehow, the device tree is now something that gets packaged with the kernel, which seems a violation of its purpose. But, for example, linux kexec on risc-v will fail (EINVAL) if it is not passed a device tree. The Image struct for arm and riscv usually has a device tree at the front. And the risc-v linux source includes a bunch of device trees. For some boards, there is more than one choice, and if you pick the wrong one, you get a brick. Was the device tree a Mitch Bradley thing? From tuhs at tuhs.org Tue Apr 7 07:03:18 2026 From: tuhs at tuhs.org (Sevan Janiyan via TUHS) Date: Mon, 6 Apr 2026 22:03:18 +0100 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> Message-ID: <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> On 06/04/2026 14:43, Sevan Janiyan via TUHS wrote: > A kind person sent me an archive from their CD, off-list, which I've > posted on my site. Forgot to say, they also had read issues with the disk too. They removed the disk from the book's sleeve for the first time to grab the files so it may be that there was a mastering problem with the CDs as it's the 3rd occurrence?!? Sevan From tuhs at tuhs.org Tue Apr 7 07:09:17 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Mon, 6 Apr 2026 14:09:17 -0700 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: On 4/6/26 2:02 PM, ron minnich via TUHS wrote: > Was the device tree a Mitch Bradley thing? > yes. Sun's Open Firmware was first From tuhs at tuhs.org Tue Apr 7 07:11:37 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Mon, 6 Apr 2026 14:11:37 -0700 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: <122b9e3c-5cf0-7394-cfb3-1925bff5dd1f@bitsavers.org> On 4/6/26 2:09 PM, Al Kossow via TUHS wrote: > On 4/6/26 2:02 PM, ron minnich via TUHS wrote: > >> Was the device tree a Mitch Bradley thing? >> > > yes. Sun's Open Firmware was first Apple adopted PCI assuming that card vendors would include OF along with PC BIOS. Unfortunately that rarely happened. It ended up that only cards required during boot ended up with OF in rom. From tuhs at tuhs.org Tue Apr 7 07:14:09 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Mon, 6 Apr 2026 14:14:09 -0700 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: <122b9e3c-5cf0-7394-cfb3-1925bff5dd1f@bitsavers.org> References: <122b9e3c-5cf0-7394-cfb3-1925bff5dd1f@bitsavers.org> Message-ID: On 4/6/26 2:11 PM, Al Kossow wrote: > On 4/6/26 2:09 PM, Al Kossow via TUHS wrote: >> On 4/6/26 2:02 PM, ron minnich via TUHS wrote: >> >>> Was the device tree a Mitch Bradley thing? >>> >> >> yes. Sun's Open Firmware was first > > Apple adopted PCI assuming that card vendors would include OF along > with PC BIOS. Unfortunately that rarely happened. It ended up that > only cards required during boot ended up with OF in rom. > The other difference was OF hung around on Suns after the OS booted. On the Mac, it was discarded after the first stage bootstrap. From tuhs at tuhs.org Tue Apr 7 08:12:48 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 06 Apr 2026 22:12:48 +0000 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: On Monday, April 6th, 2026 at 14:02, ron minnich via TUHS wrote: > The reason I ask: somehow, the device tree is now something that gets > packaged with the kernel, which seems a violation of its purpose. Somewhat, you get a DTB in your boot partition (usually FAT to appease UEFI these days afaik) but this boot partition may be loading a kernel directly on some systems, dropping in a uboot loader on others, but the DTB gets loaded usually pretty darn early, in my experience prior to jumping into the actual kernel bootstrap, much like how PCs dump a bunch of information in a know memory location ala BIOS for the bootstrap to inspect. Granted the sources that become DTBs I see distributed as DTSs with i.e. the Linux kernel. I don't know DTB holistically, if there is some upstream that feeds the penguins or if they run the show on their DTB stuff. > The Image struct for arm and riscv usually has a device tree > at the front. This is not my experience on Raspberry Pi and RISC-V distros of Linux and FreeBSD I've used. They all had a directory of DTBs in their boot partition that were selected from by whatever bootloader stage straps in the kernel, initramfs, etc. The kernel Image file, initrd, and dtb are transferred as separate BLOBs, so could exist independently of one another. - Matt G. From tuhs at tuhs.org Tue Apr 7 08:17:52 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 06 Apr 2026 22:17:52 +0000 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> Message-ID: On Monday, April 6th, 2026 at 14:03, Sevan Janiyan via TUHS wrote: > On 06/04/2026 14:43, Sevan Janiyan via TUHS wrote: > > A kind person sent me an archive from their CD, off-list, which I've > > posted on my site. > > Forgot to say, they also had read issues with the disk too. They removed > the disk from the book's sleeve for the first time to grab the files so > it may be that there was a mastering problem with the CDs as it's the > 3rd occurrence?!? > > Sevan > Weird disk that isn't a straightforward single track ISO9660? I used to run into that all the time with preserving optical media for game consoles. Our goto in that scene was bin/cue for funky optical media. - Matt G. From tuhs at tuhs.org Tue Apr 7 08:30:23 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Mon, 6 Apr 2026 15:30:23 -0700 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: in linux, there are 236 files in the riscv part of the tree, for 60 boards. Riscv kexec is pretty insistent on having a dts for kernels it boots. There are 2821 files fitting this pattern: "dts$" in the tree. They seem to each apply to one board; in some cases, there are DTS for different versions of the same board (I'm seeing this with some risc-v boards). I think my notions of where the DTS lives are pretty much obsolete :-) Anyway, thanks all, and especially Tom for getting Mitch here, and to Mitch for his reply :-) On Mon, Apr 6, 2026 at 3:12 PM segaloco via TUHS wrote: > On Monday, April 6th, 2026 at 14:02, ron minnich via TUHS > wrote: > > > The reason I ask: somehow, the device tree is now something that gets > > packaged with the kernel, which seems a violation of its purpose. > > Somewhat, you get a DTB in your boot partition (usually FAT to appease > UEFI these days afaik) but this boot partition may be loading a kernel > directly on some systems, dropping in a uboot loader on others, but the DTB > gets loaded usually pretty darn early, in my experience prior to jumping > into the actual kernel bootstrap, much like how PCs dump a bunch of > information in a know memory location ala BIOS for the bootstrap to > inspect. Granted the sources that become DTBs I see distributed as DTSs > with i.e. the Linux kernel. I don't know DTB holistically, if there is > some upstream that feeds the penguins or if they run the show on their DTB > stuff. > > > The Image struct for arm and riscv usually has a device tree > > at the front. > > This is not my experience on Raspberry Pi and RISC-V distros of Linux and > FreeBSD I've used. They all had a directory of DTBs in their boot > partition that were selected from by whatever bootloader stage straps in > the kernel, initramfs, etc. The kernel Image file, initrd, and dtb are > transferred as separate BLOBs, so could exist independently of one another. > > - Matt G. > From tuhs at tuhs.org Tue Apr 7 08:49:32 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Mon, 6 Apr 2026 18:49:32 -0400 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: On Mon, Apr 6, 2026 at 5:02 PM ron minnich via TUHS wrote: > I'm trying to refresh my memory on something. > > The first machines to have a device tree were, .. Sun 4/Power/Mac? Of > these, which was first, first? Sun, with OpenBoot, for sure. > The intent of the device tree was to be embedded in a ROM (or writable ROM) > such that a kernel could figure out properties of hardware, as I recall. As I understood it, it was constructed in memory by the ROM monitor, and the OS walked and parsed it, by reaching back into the PROM monitor to get the actual data. > Is this even vaguely correct? It seems to track with my current digging. I think it served two purposes: 1) it provided some mechanism for the machine to boot. If the OS was on a storage device that itself is on the far side of an HBA that needs non-trivial support to get itself going, what do you do? Answer: embed an interpreter for a small, low-level language into your ROM monitor and have an option ROM on each device that contains a program in that language with enough smarts to load a real OS from it. Sun chose Forth, but UEFI went a different route. 2) provide an accounting of the machine that the OS could absorb so that it didn't have to (re)probe everything. Presumably the PROM monitor had already enumerated the SBus or PCI; in that case, having the OS do it again feels like busy-work. I think now days we mostly use it for the latter, and the former has been more or less lost. > The reason I ask: somehow, the device tree is now something that gets > packaged with the kernel, which seems a violation of its purpose. I can kind of see it. For a small SBC where devices are physically soldered onto the board, there's not a lot of expansion to be done: the device tree itself is pretty much static. If you just plop it into an flash device or something, you can skip the full PROM monitor/Forth interpreter/option ROM thing. > But, for > example, linux kexec on risc-v will fail (EINVAL) if it is not passed a > device tree. The Image struct for arm and riscv usually has a device tree > at the front. And the risc-v linux source includes a bunch of device trees. > For some boards, there is more than one choice, and if you pick the wrong > one, you get a brick. > > Was the device tree a Mitch Bradley thing? From tuhs at tuhs.org Tue Apr 7 09:12:03 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 06 Apr 2026 23:12:03 +0000 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: On Monday, April 6th, 2026 at 15:50, Dan Cross via TUHS wrote: > I can kind of see it. For a small SBC where devices are physically > soldered onto the board, there's not a lot of expansion to be done: > the device tree itself is pretty much static. If you just plop it > into an flash device or something, you can skip the full PROM > monitor/Forth interpreter/option ROM thing. > Well and the prevailing SBC ecosystems aren't nearly as standardized as PC has historically been. These devices don't have some least common denominator "I'm an 8086 with bus characteristics " so the kernel needs a little more help. DTB to me is better than having to go twiddling baked in kernel addresses at build time, then you really do need a kernel-per-machine rather than being able to spin a "defconfig" kernel that'll hopefully at least give you serial TTY on whatever you're messing with. Plus, sometimes this means if you already have kernel support for device *xyz* in your current image and add one such device at some I/O address, you just have to rebuild your dtb rather than the kernel hiding all of that info deep inside. Much lower risk to roll back a dtb than a whole kernel too. Annoyingly it makes provision of quality documentation on memory maps and bus architecture a little worse, seems like you just have to "trust the dts" in many cases these days... - Matt G. From tuhs at tuhs.org Tue Apr 7 13:03:02 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 07 Apr 2026 03:03:02 +0000 Subject: [TUHS] More Lost BTL UNIX Literature Procured In-Reply-To: References: Message-ID: On Wednesday, April 1st, 2026 at 16:05, segaloco via TUHS wrote: > Howdy folks, I've got some exciting news for UNIX document preservation. > I just closed this purchase: > > ... > > - Matt G. > I just couldn't hold my excitement any longer, I decided to short circuit my scan backlog and scan this, the Product Release Description for UNIX Release 4.0: https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/UNIX_Product_Release_Description_Release_4.0.pdf Lots of good stuff there, this is the predecessor of the System Release Description distributed with System V, similarly it has an MR report which, with the System V one, could be used to reconstruct Release 4.0 to a highly accurate degree at least as far as the interface is concerned. I've been feeling quite sentimental scanning this one because it was nearly two decades ago when I first got into UNIX-like systems and started getting curious about why there wasn't a System IV. That single question, what happened to System IV, is the flashpoint that eventually lead me to all of this documentation work. This feels like the conclusion of a long and winding road, but also just the beginning. Now I can set about the task of reconstructing a UNIX Release 4.0 work-alike, achieving partially the goal of preserving the running system, although that would be in name only. I'm still holding out hope some real tapes might surface eventually. In any case, I'm over the moon about finally finding these. This isn't the only Release 4.0 literature in this lot, the other I plan on scanning after I finish that SVR2 manual is a manpage supplement and the original release notification for Release 4.0. The PRD here indicates that indeed: > No new hardcopy user's manual will be produced for this release, but the > delivered on-line copy is correct and up-to-date. In addition, some > machine reproducible documents are included on the release tape. Confirming what Arnold Robbins and others have indicated, that BTL saw no need to do a print run of the Release 4.0 literature. That makes this stack of manpage edits the closest thing to a Release 4.0 physical manual publication. Couple that with the Volume 2 issues and flipbook from Arnold Robbins and there are now very few holes left in the documentation history of Release 4.0. I will be sharing more documents from this lot as time goes on but this one was just so special and sentimental to me that I had to bump it to the top. Enjoy! - Matt G. From tuhs at tuhs.org Tue Apr 7 13:41:10 2026 From: tuhs at tuhs.org (r.stricklin via TUHS) Date: Mon, 6 Apr 2026 20:41:10 -0700 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> Message-ID: <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> > On Apr 6, 2026, at 3:17 PM, segaloco via TUHS wrote: > > Weird disk that isn't a straightforward single track ISO9660? I used to run into that all the time with preserving optical media for game consoles. Our goto in that scene was bin/cue for funky optical media. More likely just that CD-ROM isn’t an archival medium. I’ve encountered any number of e.g. early ‘90s Sun CDs with optical rot of one kind or another. Oxidation of the aluminum layer, clouding in the polycarbonate layer… It doesn’t surprise me to hear that, having encountered one bad CD, several other copies had similar problems. ok bear. From tuhs at tuhs.org Tue Apr 7 15:03:15 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 6 Apr 2026 23:03:15 -0600 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> Message-ID: On Mon, Apr 6, 2026 at 9:42 PM r.stricklin via TUHS wrote: > > > > On Apr 6, 2026, at 3:17 PM, segaloco via TUHS wrote: > > > > Weird disk that isn't a straightforward single track ISO9660? I used to > run into that all the time with preserving optical media for game > consoles. Our goto in that scene was bin/cue for funky optical media. > > More likely just that CD-ROM isn’t an archival medium. I’ve encountered > any number of e.g. early ‘90s Sun CDs with optical rot of one kind or > another. Oxidation of the aluminum layer, clouding in the polycarbonate > layer… It doesn’t surprise me to hear that, having encountered one bad CD, > several other copies had similar problems. > The Solaris 2.0 Alpha binary CD that I have has been unreadable for at least 15 years. Warner From tuhs at tuhs.org Tue Apr 7 16:09:34 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 07 Apr 2026 06:09:34 +0000 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> Message-ID: On Monday, April 6th, 2026 at 22:03, Warner Losh via TUHS wrote: > On Mon, Apr 6, 2026 at 9:42 PM r.stricklin via TUHS wrote: > > > > > > > > On Apr 6, 2026, at 3:17 PM, segaloco via TUHS wrote: > > > > > > Weird disk that isn't a straightforward single track ISO9660? I used to > > run into that all the time with preserving optical media for game > > consoles. Our goto in that scene was bin/cue for funky optical media. > > > > More likely just that CD-ROM isn’t an archival medium. I’ve encountered > > any number of e.g. early ‘90s Sun CDs with optical rot of one kind or > > another. Oxidation of the aluminum layer, clouding in the polycarbonate > > layer… It doesn’t surprise me to hear that, having encountered one bad CD, > > several other copies had similar problems. > > > > The Solaris 2.0 Alpha binary CD that I have has been unreadable for at > least 15 years. > > Warner > I guess the question then becomes whether the multiple bad dumps have the proper complement of good blocks between them to assemble a proper image. This may also suggest performing something like a bin/cue backup that captures more sector information, that way you can also use that metadata to better reconstruct a complete image. This has been done for a few video games where just enough good blocks could be pulled from known-but-decayed specimens that the correct image could ultimately be produced. Heck just recently in the NES circle I chit-chat in, a few folks were able to recover a lost bootleg title by visually analyzing mis-matched cartridge traces to the particular ROM chip involved coupled with analysis of a good dump of the title the pirate was built on, resulting in determining which address and data bus bits were reversed and both the precise bit twiddling on both data and addresses that was necessary to reproduce a functional, playable copy of the game, and also the banking logic that was buried under a chip-on-board blob. This subject of creative recovery methods is quite interesting to me, I often times worry that the video game and general systems history communities don't have a lot of crossover because several of my go-to "archaeological" techniques derive from practices in the video game ROM hacking and emulation communities rather than the folks in institutions with credentials archiving UNIVAC magtapes and Western Electric ROMs. All to say I do love these moments when the oddball techniques from the video game preservation microcosm are also applicable to the other tech history stuff I appreciate. - Matt G. From tuhs at tuhs.org Tue Apr 7 16:11:18 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 07 Apr 2026 06:11:18 +0000 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: Message-ID: Bounced for Greg below: On Monday, April 6th, 2026 at 23:01, Greg 'groggy' Lehey wrote: > I've been having difficulties with the TUHS mailing list. Warren is > informed. If you get this directly but not from the list, could you > bounce it, please? > > On Monday, 6 April 2026 at 14:43:29 +0100, Sevan Janiyan wrote: > > On 27/03/2026 05:05, Greg 'groggy' Lehey wrote: > >> OK, I've tried in a different system and got the same errors, so it's > >> the CD. But strangely I could mount it, and I've made a tar archive > >> of it:http://lax.lemis.com/grog/panic-cdrom.tar. It's only 1722 kB > >> in size. I can untar it and get the files, but of course I can't > >> confirm that they're correct. Can you compare? > > > > Thanks for digging in, Greg. > > Unfortunately your URL never worked for me. > > Sorry, it got removed automatically, presumably too soon for you. > It's there again now, and I'll leave it there for a while longer. > > > A kind person sent me an archive from their CD, off-list, which I've posted > > on my site. > > Just to be helpful to scrapers, the file is up at > > /files/panic-cdrom-files.zip on the domain of my email address, accessible > > via HTTPS :-) > > I've downloaded it and compared. All the files are the same and have > the same contents, so I assume that they're (both) correct. > > On Monday, 6 April 2026 at 22:03:18 +0100, Sevan Janiyan wrote: > > On 06/04/2026 14:43, Sevan Janiyan via TUHS wrote: > >> A kind person sent me an archive from their CD, off-list, which I've > >> posted on my site. > > > > Forgot to say, they also had read issues with the disk too. They removed the > > disk from the book's sleeve for the first time to grab the files so it may > > be that there was a mastering problem with the CDs as it's the 3rd > > occurrence?!? > > Sounds just like what I did. I wonder how many people actually used > the CD at the time. > > On Monday, 6 April 2026 at 22:17:52 +0000, segaloco wrote: > > On Monday, April 6th, 2026 at 14:03, Sevan Janiyan via TUHS wrote: > >> On 06/04/2026 14:43, Sevan Janiyan via TUHS wrote: > >>> A kind person sent me an archive from their CD, off-list, which I've > >>> posted on my site. > >> > >> Forgot to say, they also had read issues with the disk too. They removed > >> the disk from the book's sleeve for the first time to grab the files so > >> it may be that there was a mastering problem with the CDs as it's the > >> 3rd occurrence?!? > > > > Weird disk that isn't a straightforward single track ISO9660? I > > used to run into that all the time with preserving optical media for > > game consoles. Our goto in that scene was bin/cue for funky optical > > media. > > Possibly. As I said, I had issues mounting it, but I could still read > the files. That suggests that it's not age-related deterioration, but > some incompatibility. If you have any ideas about how to investigate, > I'd be interested. > > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php > From tuhs at tuhs.org Tue Apr 7 16:49:41 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Tue, 07 Apr 2026 00:49:41 -0600 Subject: [TUHS] More Lost BTL UNIX Literature Procured In-Reply-To: References: Message-ID: <202604070649.6376nfH0099434@freefriends.org> Matt, This is great! I remember reading this document, but apparently I didn't copy it for myself at the time. My favorite part is to be found on page 5 of attachment 1, indicating changes: sort(1) The destroy-your-input-file feature is gone. This used to be accomplished by saying sort -ooutput input. If there was no space between the -o and the output file, the input file was assumed to be the argument to the -o and truncated to zero. Thanks for recovering this. Arnold segaloco via TUHS wrote: > On Wednesday, April 1st, 2026 at 16:05, segaloco via TUHS wrote: > > > Howdy folks, I've got some exciting news for UNIX document preservation. > > I just closed this purchase: > > > > ... > > > > - Matt G. > > > > I just couldn't hold my excitement any longer, I decided to short > circuit my scan backlog and scan this, the Product Release Description > for UNIX Release 4.0: > > https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/UNIX_Product_Release_Description_Release_4.0.pdf > > Lots of good stuff there, this is the predecessor of the System Release > Description distributed with System V, similarly it has an MR report > which, with the System V one, could be used to reconstruct Release 4.0 > to a highly accurate degree at least as far as the interface is > concerned. > > I've been feeling quite sentimental scanning this one because it was > nearly two decades ago when I first got into UNIX-like systems and > started getting curious about why there wasn't a System IV. That single > question, what happened to System IV, is the flashpoint that eventually > lead me to all of this documentation work. This feels like the > conclusion of a long and winding road, but also just the beginning. Now > I can set about the task of reconstructing a UNIX Release 4.0 > work-alike, achieving partially the goal of preserving the running > system, although that would be in name only. I'm still holding out hope > some real tapes might surface eventually. > > In any case, I'm over the moon about finally finding these. This isn't > the only Release 4.0 literature in this lot, the other I plan on > scanning after I finish that SVR2 manual is a manpage supplement and the > original release notification for Release 4.0. The PRD here indicates > that indeed: > > > No new hardcopy user's manual will be produced for this release, but the > > delivered on-line copy is correct and up-to-date. In addition, some > > machine reproducible documents are included on the release tape. > > Confirming what Arnold Robbins and others have indicated, that BTL saw > no need to do a print run of the Release 4.0 literature. That makes > this stack of manpage edits the closest thing to a Release 4.0 physical > manual publication. Couple that with the Volume 2 issues and flipbook > from Arnold Robbins and there are now very few holes left in the > documentation history of Release 4.0. > > I will be sharing more documents from this lot as time goes on but this > one was just so special and sentimental to me that I had to bump it to > the top. > > Enjoy! > > - Matt G. From tuhs at tuhs.org Tue Apr 7 18:25:38 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 07 Apr 2026 08:25:38 +0000 Subject: [TUHS] Program Generic Issue 3 Findings Message-ID: Long initial post for "PG-III General" incoming: After scanning the Release 4.0 PRD, I started thumbing through the Program Generic Issue 3 manual and hoo boy am I excited to get this one scanned. I've only bounced around but there are just so many little tidbits that I've been waiting to sink my teeth into for years. I'll leave a few highlights and due to the excitement, I am also going to scan this before I resume the schedule I set for myself weeks ago. Notable: sh(I) - The USG shell took a different track concerning capturing stderr via redirection. Rather than giving the three redirection symbols of the Thompson Shell (<, >, >>), the following are also given: %name causes 'name' to be used as the error output file for the associated command. 'Name' is created if it did not exist and is truncated at the outset. %%name causes 'name' to be used as the error output for the associated command. If 'name' did not exist, it is created; if it existed, the error output is appended to the file. s/2>>/%%/g s/2>/%/g May the USG shell be with you. msg(II) - USG PG-III is now the earliest confirmed manual sighting I know of demonstrating the early BTL IPC (which is actually proposed in one of the BTL library documents recently scanned by Stephen Searle[1]). The msg(II) page here, for instance ([2] from MERT 0 which is scanned and has this page verbatim) indicates the same interface that then gets pulled into the PWB line as of Release 4.0, albeit with a few new bits. This interface's influence can also be seen in CB-UNIX as of Edition 2.3[3] albeit with some differences. However, even as early as 1977 this interface was also intertwined with CB-UNIX as described in another technical report[4] which also brings in things like MAUS. As of Release *4.1* for the 3B20S, however, the IPC starts to look a bit more like System V IPC[5]. All in all this puts the development of this early IPC that was replaced in System V either in the SCCS/CB branch or squarely in USG PG-III (give or take whatever UNIX tide-pool it first gestated in.) In any case, this sets the backstop on manpages for pre-V IPC at March 1977. This makes the picture from 1976 to 1983 with IPC much more clear. I'm glad I don't actually have to scan anything else to aggregate this info together. lines(V) - My suspicion that System V init(8) derived from PG-III init is stronger than ever. A part of this page is found in the scanned CB-UNIX 2.3 manual[6][7] but the first is cut-off and the second indicates replacement by inittab(5). In CB-UNIX 2.3[8], inittab(5) adds the powerfail and powerwait actions as well as initdefault. These enhancements also then show up in 5.0/System V[9], at which point a paper is added to the SRD[10]. I have not identified yet whether this paper derives from a specific Technical Memorandum or if it was drafted for the System V SRD itself. Either way, this confirms a heritage of System V init going back to at least March 1977 with Program Generic Issue 3. Will the sysvinit project rename to pg3init for my sake? Probably not...but I get to know the hidden truth. hd(IV) - From the page: "This section describes the half-duplex protocol implemented as a line discipline which permits access to UNIX using Teletype Model 40/1's and Model 40/2's (in 202 mode) using 202S data sets or null modems." I haven't completely done my homework on the Teletype Model 40's origins, I just know that it became the standard Bell System terminal for a while, showing up in for instance the 3B20S Release 4.1 User's Manual cover art[11] and other AT&T materials in the early 80s (I've got some non-UNIX-related American Bell stuff, 1982, I intend to scan soon. Very early, some nice pictures of a bunch of AT&T hardware, also first year the Death Star was on any of their stuff afaik, so formative "Death Star AT&T" ephemera). This one is significant to me as I do find myself quite interested in the Teletype 40/2 (also known as Dataspeed 40/2), although I haven't gone looking too hard to determine its true age. Either way, the service manual has copyrights as early as 1973[12] but according to one of the BTL Library papers[13] initial development of this driver was complete as of December 1975 (source code included!!!). The driver is not present as of Program Generic Issue 2[14] nor is it in research, PWB, or CB-UNIX. I haven't gone looking for what, if any, Teletype 40- specific bits might have been in other streams...but still luckily much of the history of this period of Teletype 40 support is now known. That's all for now, but I knew I wouldn't be able to sleep tonight if I didn't start the marble rolling on discussing the significance of Program Generic Issue 3 to the history of a number of UNIX's features that would become ubiquitous with later releases. Maybe it's just me, but this manual already paints a picture of an experience in 1977 not all that different from what the PWB and CB folks were getting up to in the early 80s. Needless to say, I hope to have this scanned soon and tossed up on the archive as well. More to come! - Matt G. P.S. Fun fact, while doing this analysis, I was using a Motorola Bellboy pager and Western Electric ruler I purchased recently to hold pages open. Something about that feels auspicious[15]. [1] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1090_Proposal_for_UNIX_Interprocess_Communication.pdf [2] - https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Unix%20Programmer%20Manual%20-%20UPM%20-%20White%20Tabs/System%20Calls%20-%20man2/msg.2.pdf [3] - https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/msg.2.pdf [4] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1234_Interprocess_Communication_Mechanisms_in_CB_UNIX.pdf [5] - https://gitlab.com/segaloco/pwb4u_man/-/blob/master/man2/msgop.2 [6] - https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man5/lines.5.pdf [7] - https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man5/lines.5l.pdf [8] - https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man5/inittab.5.pdf [9] - https://www.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/man/u_man/man4/inittab.4 [10] - https://archive.org/details/unix-system-release-description-system-v/C%20-%20UNIX%20System%20V%20Init%20and%20Getty [11] - https://commons.wikimedia.org/wiki/File:UNIX4.1UsersManualCover.png [12] - https://bitsavers.org/communications/teletype/40/325-077_Teletypewriter_Compatable_Model_40_Service_Jan82.pdf [13] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1077_UNIX_DH_11_Driver_to_Support_Both_TTY_and_Dataspeed_40_Terminals.pdf [14] - https://bitsavers.org/pdf/att/unix/6th_Edition/UNIX_Programmers_Manual_197601.pdf [15] - https://ibb.co/35hC5Tk9 From tuhs at tuhs.org Tue Apr 7 20:51:50 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Tue, 7 Apr 2026 06:51:50 -0400 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: On Mon, Apr 6, 2026 at 7:12 PM segaloco via TUHS wrote: > On Monday, April 6th, 2026 at 15:50, Dan Cross via TUHS wrote: > > I can kind of see it. For a small SBC where devices are physically > > soldered onto the board, there's not a lot of expansion to be done: > > the device tree itself is pretty much static. If you just plop it > > into an flash device or something, you can skip the full PROM > > monitor/Forth interpreter/option ROM thing. > > > > Well and the prevailing SBC ecosystems aren't nearly as standardized as PC has historically been. These devices don't have some least common denominator "I'm an 8086 with bus characteristics " so the kernel needs a little more help. DTB to me is better than having to go twiddling baked in kernel addresses at build time, then you really do need a kernel-per-machine rather than being able to spin a "defconfig" kernel that'll hopefully at least give you serial TTY on whatever you're messing with. Plus, sometimes this means if you already have kernel support for device *xyz* in your current image and add one such device at some I/O address, you just have to rebuild your dtb rather than the kernel hiding all of that info deep inside. Much lower risk to roll back a dtb than a whole kernel too. Trust me, the PC world ain't that standard, either. :-D UEFI has devolved as a way to paper over the differences between systems at the mainboard level, and it serves a similar function as OpenBoot: it gives the board vendors a place to do platform enablement: initializing IO bridges and kicking off PCIe links training, allocating physical address space for MMIO, etc; it also bundles up a bunch of information about the system so that software, specifically kernels and boot loaders, is reasonably decoupled from the underlying hardware; and it solves the boot problem: vendors can plug their device-specific code into a UEFI stack and ship it in flash or on a ROM and it can start devices "enough" to load a boot loader or OS. It also subsumes the traditional BIOS function of being a least-common denominator for driving IO devices: it can implement USB, for example, and provide simulation of PS/2 keyboards and mice for OS's that don't know how to drive USB HID devices (the system trapping through SMIs and SMM to reach into the UEFI layer, so the system is none the wiser), for example. But on balance, ACPI tables are like device trees in a lot of ways; some would argue they're less expressive and overall the whole UEFI stack is a lot less elegant than OpenBoot was. I would agree with them. > Annoyingly it makes provision of quality documentation on memory maps and bus architecture a little worse, seems like you just have to "trust the dts" in many cases these days... Sadly, with very few exceptions, we generally "trust" that the ACPI tables firmware leaves in memory adequately describe the system, too. Nothing new under the Sun.... (Sorry for the terrible pun.) - Dan C. From tuhs at tuhs.org Tue Apr 7 22:04:33 2026 From: tuhs at tuhs.org (Sevan Janiyan via TUHS) Date: Tue, 7 Apr 2026 13:04:33 +0100 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: Message-ID: <71cbd2f9-7a3e-4505-ba0f-54317e2df84f@geeklan.co.uk> On 07/04/2026 07:00, Greg 'groggy' Lehey wrote: > Sorry, it got removed automatically, presumably too soon for you. > It's there again now, and I'll leave it there for a while longer. Managed to fetch it now. Thanks. >> Weird disk that isn't a straightforward single track ISO9660? I >> used to run into that all the time with preserving optical media for >> game consoles. Our goto in that scene was bin/cue for funky optical >> media. > Possibly. As I said, I had issues mounting it, but I could still read > the files. That suggests that it's not age-related deterioration, but > some incompatibility. If you have any ideas about how to investigate, > I'd be interested. There are a couple of tools recommended in the following post for archiving CDs, though I'm not sure if they cope with unreadability, like in this situation. https://www.mistys-internet.website/blog/blog/2024/09/13/the-working-archivists-guide-to-enthusiast-cd-rom-archiving-tools/ Sevan From tuhs at tuhs.org Wed Apr 8 03:48:34 2026 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Tue, 7 Apr 2026 10:48:34 -0700 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> Message-ID: cdparanoia, last time I used it, was pretty good at recovering data from busted CDs. I suspect that doing that across multiple copies might indeed get you, in aggregate, a good image. On Mon, Apr 6, 2026 at 11:20 PM segaloco via TUHS wrote: > > I guess the question then becomes whether the multiple bad dumps have > the proper complement of good blocks between them to assemble a proper > image. This may also suggest performing something like a bin/cue backup > that captures more sector information, that way you can also use that > metadata to better reconstruct a complete image. This has been done for > a few video games where just enough good blocks could be pulled from > known-but-decayed specimens that the correct image could ultimately be > produced. > > From tuhs at tuhs.org Wed Apr 8 12:05:52 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 8 Apr 2026 12:05:52 +1000 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM Message-ID: Something is definitely going wrong with Greg's posts to TUHS. I need to investigate. Here is his latest post, forwarded: ----- Forwarded message from Greg 'groggy' Lehey ----- Subject: Re: [TUHS] Re: Panic! - Unix System Crash Dump Analysis companion CD-ROM On Tuesday, 7 April 2026 at 6:09:34 +0000, The UNIX Heritage Society wrote: > > I guess the question then becomes whether the multiple bad dumps have > the proper complement of good blocks between them to assemble a proper > image. In general, maybe. In this particular case I suspect that there's a format incompatibility. Remember Rock Ridge? Joliet? El Torito? Is it possible that at the time Sun was using something other than ISO 9660? Sevan's dump was identical to mine, which doesn't smell of medium corruption. All the errors could be format-related. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php ----- End forwarded message ----- From tuhs at tuhs.org Wed Apr 8 12:46:52 2026 From: tuhs at tuhs.org (Tom Lyon via TUHS) Date: Tue, 7 Apr 2026 19:46:52 -0700 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: Message-ID: Early Sun CDs used 512 byte blocksize, but the industry settled on 2K. (IIRC) So maybe that has something to do with it? On Tue, Apr 7, 2026 at 7:25 PM Warren Toomey via TUHS wrote: > Something is definitely going wrong with Greg's posts to TUHS. > I need to investigate. Here is his latest post, forwarded: > > ----- Forwarded message from Greg 'groggy' Lehey ----- > Subject: Re: [TUHS] Re: Panic! - Unix System Crash Dump Analysis companion > CD-ROM > > On Tuesday, 7 April 2026 at 6:09:34 +0000, The UNIX Heritage Society > wrote: > > > > I guess the question then becomes whether the multiple bad dumps have > > the proper complement of good blocks between them to assemble a proper > > image. > > In general, maybe. In this particular case I suspect that there's a > format incompatibility. Remember Rock Ridge? Joliet? El Torito? Is > it possible that at the time Sun was using something other than ISO > 9660? Sevan's dump was identical to mine, which doesn't smell of > medium corruption. All the errors could be format-related. > > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php > ----- End forwarded message ----- > From tuhs at tuhs.org Wed Apr 8 20:11:16 2026 From: tuhs at tuhs.org (Kevin Bowling via TUHS) Date: Wed, 8 Apr 2026 03:11:16 -0700 Subject: [TUHS] AUUGN book review list Message-ID: Here is a list of books aggregated from the TUHS AUUGN archive book reviews courtesy of Claude.. Brave New World. Probably missing some as it was just looking for ISBNs. https://claude.ai/public/artifacts/35294957-feec-45f5-9db8-89f7a07d1a7c Regards, Kevin From tuhs at tuhs.org Wed Apr 8 20:16:42 2026 From: tuhs at tuhs.org (Kevin Bowling via TUHS) Date: Wed, 8 Apr 2026 03:16:42 -0700 Subject: [TUHS] AUUGN book review list In-Reply-To: References: Message-ID: On Wed, Apr 8, 2026 at 3:11 AM Kevin Bowling wrote: > > Here is a list of books aggregated from the TUHS AUUGN archive book > reviews courtesy of Claude.. Brave New World. Probably missing some > as it was just looking for ISBNs. > > https://claude.ai/public/artifacts/35294957-feec-45f5-9db8-89f7a07d1a7c More complete that punched through some trivial OCR transcription errors and includes some without ISBN https://claude.ai/public/artifacts/ecfc1c6c-f592-4fd3-9b2f-536a3fe559e7 > Regards, > Kevin From tuhs at tuhs.org Wed Apr 8 20:31:26 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 08 Apr 2026 10:31:26 +0000 Subject: [TUHS] AUUGN book review list In-Reply-To: References: Message-ID: Thank you, Kevin I was going to reply to your first post that, "...I didn't realize Aldous Huxley had contributed to the AUUGN...". But, soma aside, that's an impressive list! 249 books with ISBNs and 36 books without. Nice. Best wishes, Cameron -------- Original Message -------- On Wednesday, 04/08/26 at 11:17 Kevin Bowling via TUHS wrote, in part: More complete that punched through some trivial OCR transcription errors and includes some without ISBN https://claude.ai/public/artifacts/ecfc1c6c-f592-4fd3-9b2f-536a3fe559e7 > Regards, > Kevin From tuhs at tuhs.org Wed Apr 8 21:40:52 2026 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Wed, 08 Apr 2026 13:40:52 +0200 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: <0b2988e9-f5e3-4c63-b48f-9de2d56e21e7@geeklan.co.uk> <42a03374-2697-48e5-ae9f-62df4d2d4481@geeklan.co.uk> <02fc60b8-59f7-4ffd-8b58-58f827e7c184@geeklan.co.uk> <682D6A8E-3B80-4D69-9B22-CF3AA14DD0A6@typewritten.org> Message-ID: <20260408114052.kmITURDX@steffen%sdaoden.eu> Adam Thornton via TUHS wrote in : |On Mon, Apr 6, 2026 at 11:20 PM segaloco via TUHS wrote: |> I guess the question then becomes whether the multiple bad dumps have |> the proper complement of good blocks between them to assemble a proper |> image. This may also suggest performing something like a bin/cue backup |> that captures more sector information, that way you can also use that |> metadata to better reconstruct a complete image. This has been done for |> a few video games where just enough good blocks could be pulled from |> known-but-decayed specimens that the correct image could ultimately be |> produced. |cdparanoia, last time I used it, was pretty good at recovering data from |busted CDs. I suspect that doing that across multiple copies might indeed |get you, in aggregate, a good image. You may also want to have a look at xorriso[1]. Can check media for damages and copy readable blocks to disk. The maintainer had a tremendous run a couple of years ago, one that included sending kernel patches to certain BSDs (at least), ie, to improve the ISO 9660 (handling) support, and more. (Could be ten years even, though .. you know.) (Thankfully so he did, so i could sit down in the early Corona months, and write a "modern" digital audio CD accessor program for BSD* and Linux, s-cdda.c, one that only uses SCSI Multimedia Commands, for extracting CD-TEXT and such. Does not test CRC itself, at least yet, but only certain logical data conditions.) [1] https://www.gnu.org/software/xorriso/ --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Wed Apr 8 22:11:01 2026 From: tuhs at tuhs.org (Kenneth Goodwin via TUHS) Date: Wed, 8 Apr 2026 08:11:01 -0400 Subject: [TUHS] Panic! - Unix System Crash Dump Analysis companion CD-ROM In-Reply-To: References: Message-ID: Memory fades, but wasn't it an initial 512 boot program that then loaded that 2k super boot block? Mostly because the system board boot roms at the time only could load a 512 byte bootstrap program. On Tue, Apr 7, 2026, 10:47 PM Tom Lyon via TUHS wrote: > Early Sun CDs used 512 byte blocksize, but the industry settled on 2K. > (IIRC) > So maybe that has something to do with it? > > On Tue, Apr 7, 2026 at 7:25 PM Warren Toomey via TUHS > wrote: > > > Something is definitely going wrong with Greg's posts to TUHS. > > I need to investigate. Here is his latest post, forwarded: > > > > ----- Forwarded message from Greg 'groggy' Lehey ----- > > Subject: Re: [TUHS] Re: Panic! - Unix System Crash Dump Analysis > companion > > CD-ROM > > > > On Tuesday, 7 April 2026 at 6:09:34 +0000, The UNIX Heritage Society > > wrote: > > > > > > I guess the question then becomes whether the multiple bad dumps have > > > the proper complement of good blocks between them to assemble a proper > > > image. > > > > In general, maybe. In this particular case I suspect that there's a > > format incompatibility. Remember Rock Ridge? Joliet? El Torito? Is > > it possible that at the time Sun was using something other than ISO > > 9660? Sevan's dump was identical to mine, which doesn't smell of > > medium corruption. All the errors could be format-related. > > > > Greg > > -- > > Sent from my desktop computer. > > Finger grog at lemis.com for PGP public key. > > See complete headers for address and phone numbers. > > This message is digitally signed. If your Microsoft mail program > > reports problems, please read http://lemis.com/broken-MUA.php > > ----- End forwarded message ----- > > > From tuhs at tuhs.org Sat Apr 11 10:06:05 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 11 Apr 2026 00:06:05 +0000 Subject: [TUHS] Pirzada's Thesis Missing? Message-ID: Does anyone have handy a copy of Pirzada's thesis "A Statistical Examination of the Evolution of the Unix System"? I'm having a bit of trouble finding a live link to a PDF at present. Given the detailed history too, should/can a copy be placed in the archive? I imagine if it's been publicly accessible elsewhere its probably fine to mirror. - Matt G. From tuhs at tuhs.org Sat Apr 11 10:29:40 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Sat, 11 Apr 2026 10:29:40 +1000 Subject: [TUHS] Pirzada's Thesis Missing? In-Reply-To: References: Message-ID: On Sat, Apr 11, 2026 at 12:06:05AM +0000, segaloco via TUHS wrote: > Does anyone have handy a copy of Pirzada's thesis "A Statistical Examination of the Evolution of the Unix System"? I'm having a bit of trouble finding a live link to a PDF at present. Given the detailed history too, should/can a copy be placed in the archive? I imagine if it's been publicly accessible elsewhere its probably fine to mirror. > > - Matt G. https://spiral.imperial.ac.uk/entities/publication/700a4f59-117e-4a67-a5be-e1a4c0ef396d From tuhs at tuhs.org Sun Apr 12 09:41:22 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 11 Apr 2026 23:41:22 +0000 Subject: [TUHS] Program Generic Issue 3 Findings In-Reply-To: References: Message-ID: And here you have it: https://www.tuhs.org/Archive/Documentation/Manuals/Program_Generic_Issue_3/UNIX_Programmers_Manual_Program_Generic_Issue_3.pdf After the link is the UNIX Programmer's Manual for Program Generic PG-1C300 Issue 3, the last release of USG Generic UNIX prior to the establishment of the UNIX/TS and UNIX/RT projects and eventual absorption into the PWB/commercial line. USG first adopted the Program Generic nomenclature with a maintenance revision of USG UNIX Release 2. At the time, this system was still quite comparable to research[1], but with Issue 2[2] and then Issue 3 here, things start to diverge. Based on the issue numbers, I believe now having Issue 2 and Issue 3 manuals completes the preservation of available Program Generic manuals, as the issue numbering for the manuals (as opposed to the versions) begins with Issue 1 in January, 1976, and Issue 2 in March, 1977, trailing the underlying generic issue by one. I get the feeling print literature prior to Issue 2 was limited to copies of the research literature if any distribution was done en masse, but can't confirm this. Either way, I suspect it is unlikely any "produced" paper manuals of USG Release 1, Release 2, or Program Generic Issue 1 will surface. If anything is out there, it is likely (n)roff printouts from a user's terminal. Minute changes in the Program Generic line after Issue 3 may be represented in the MERT Release 0 manual, which is based on it[3]. An older MERT manual was present in the USG library items[4] which could then prove useful for determining MERT vs USG contributions to Release 0 and later versions. In any case, plenty of holes now filled in the USG situation in the mid 70s leading up to UNIX/TS and UNIX/RT (and PWB expansion). As far as manuals, cross-referencing Pirzada's thesis as well as references available in the USG library and other UNIX manuals, at the very least I suspect these manuals may have been formally published (in other words, are likely to survive somewhere in a "standard" form) by USG: CB-UNIX Edition 1.0 UNIX/TS Edition 1.1 UNIX/RT Release 1 CB-UNIX Edition 2.1 PWB/UNIX Release 2.0 Of these, there's really only a lead on the latter right now. I can't confirm the others ever existed as a distributed (as opposed to one-off) printed BTL package, but they're the most likely candidates to have had print distribution by USG otherwise. Anywho, enjoy! I plan on doing an in-depth analysis of Program Generic literature sometime this year, resulting in both a navigable git repository with commits/tags representing research->PG II->PG III manual revisions as well as updates to the wiki describing the various differences. This will all eventually be worked back into my mandiff project as well, which I'm probably going to start over since so much new literature is available since last I touched that. - Matt G. [1] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1017_Setting_Up_UNIX_Issue_Three.pdf [2] - https://www.bitsavers.org/pdf/att/unix/6th_Edition/UNIX_Programmers_Manual_197601.pdf [3] - https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/ [4] - https://www.tuhs.org/Archive/Documentation/TechReports/USG_Library/1070_MERT_Programmers_Manual_First_Edition.pdf From tuhs at tuhs.org Mon Apr 13 19:12:46 2026 From: tuhs at tuhs.org (Folkert van Heusden via TUHS) Date: Mon, 13 Apr 2026 11:12:46 +0200 Subject: [TUHS] BSD 2.11 on PDP11/70 (emulated), connecting to it via a slip interface Message-ID: <78fd6b691956993193ad28b90b3dc0ce@vanheusden.com> Hi, As I mentioned a year ago I'm working on a pdp11/70 emulator. Just for fun, not serious like simh. Currently it can run BSD 2.11 multiuser on an ESP32-S3 (altough booting takes almost 50 minutes on that platform). It also runs on Linux etc. So I setup a BSD kernel with slip and dz11 support to allow telnet over IP with slip. Unfortunately that hangs. I can ping, I can nmap the virtual PDP but telnet to the PDP just does SYN/SYNACK/ACK and then nothing. Any ideas why telnet would hang? Pinging the pdp: root at snsv:~# ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=77.5 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=185 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=90.2 ms ^C --- 192.168.1.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 77.503/117.547/184.895/47.905 ms nmap: Nmap scan report for 192.168.1.2 Host is up (0.069s latency). Not shown: 990 closed tcp ports (reset) PORT STATE SERVICE 1/tcp open tcpmux 7/tcp open echo 9/tcp open discard 21/tcp open ftp 23/tcp open telnet 79/tcp open finger 113/tcp open ident 513/tcp open login 514/tcp open shell 515/tcp open printer Device type: general purpose Running (JUST GUESSING): BSD 2.X (85%) OS CPE: cpe:/o:bsd:bsd:2.11 Aggressive OS guesses: 2.11BSD (85%) No exact OS matches for host (test conditions non-ideal). OS detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 27.90 seconds telnet network trace: 10:39:41.390230 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [S], seq 730571314, win 65535, options [mss 256,sackOK,TS val 1346414773 ecr 0,nop,wscale 10], length 0 10:39:41.458696 IP 192.168.1.2.23 > 192.168.1.1.55606: Flags [S.], seq 43457, ack 730571315, win 4096, options [mss 966], length 0 10:39:41.458753 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [.], ack 1, win 65535, length 0 10:39:41.459364 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] 10:39:42.035173 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] 10:39:43.123157 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] ... regards -- www.vanheusden.com [1] Links: ------ [1] http://www.vanheusden.com From tuhs at tuhs.org Mon Apr 13 23:25:26 2026 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Mon, 13 Apr 2026 09:25:26 -0400 Subject: [TUHS] BSD 2.11 on PDP11/70 (emulated), connecting to it via a slip interface In-Reply-To: <78fd6b691956993193ad28b90b3dc0ce@vanheusden.com> References: <78fd6b691956993193ad28b90b3dc0ce@vanheusden.com> Message-ID: On Mon, Apr 13, 2026 at 5:13 AM Folkert van Heusden via TUHS wrote: > As I mentioned a year ago I'm working on a pdp11/70 emulator. Just for > fun, not serious like simh. "(just a hobby, won't be big and professional like gnu}" --Linus Torvalds, 1991 From tuhs at tuhs.org Tue Apr 14 05:25:27 2026 From: tuhs at tuhs.org (Rik Farrow via TUHS) Date: Mon, 13 Apr 2026 12:25:27 -0700 Subject: [TUHS] BSD 2.11 on PDP11/70 (emulated), connecting to it via a slip interface In-Reply-To: <78fd6b691956993193ad28b90b3dc0ce@vanheusden.com> References: <78fd6b691956993193ad28b90b3dc0ce@vanheusden.com> Message-ID: IIRC, telnet might be started by inetd, configured in /etc/inetd.con. It handles connections (and the built-in, like echo) and then passes the connection off to the actual telnetd. I suggest taking a look there, and making sure you have the actual server... Rik On Mon, Apr 13, 2026 at 2:13 AM Folkert van Heusden via TUHS wrote: > Hi, > > As I mentioned a year ago I'm working on a pdp11/70 emulator. Just for > fun, not serious like simh. > > Currently it can run BSD 2.11 multiuser on an ESP32-S3 (altough booting > takes almost 50 minutes on that platform). > > It also runs on Linux etc. So I setup a BSD kernel with slip and dz11 > support to allow telnet over IP with slip. Unfortunately that hangs. I > can ping, I can nmap the virtual PDP but telnet to the PDP just does > SYN/SYNACK/ACK and then nothing. Any ideas why telnet would hang? > > Pinging the pdp: > > root at snsv:~# ping 192.168.1.2 > PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. > 64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=77.5 ms > 64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=185 ms > 64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=90.2 ms > ^C > --- 192.168.1.2 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2004ms > rtt min/avg/max/mdev = 77.503/117.547/184.895/47.905 ms > > nmap: > > Nmap scan report for 192.168.1.2 > Host is up (0.069s latency). > Not shown: 990 closed tcp ports (reset) > PORT STATE SERVICE > 1/tcp open tcpmux > 7/tcp open echo > 9/tcp open discard > 21/tcp open ftp > 23/tcp open telnet > 79/tcp open finger > 113/tcp open ident > 513/tcp open login > 514/tcp open shell > 515/tcp open printer > Device type: general purpose > Running (JUST GUESSING): BSD 2.X (85%) > OS CPE: cpe:/o:bsd:bsd:2.11 > Aggressive OS guesses: 2.11BSD (85%) > No exact OS matches for host (test conditions non-ideal). > > OS detection performed. Please report any incorrect results at > https://nmap.org/submit/ . > Nmap done: 1 IP address (1 host up) scanned in 27.90 seconds > > telnet network trace: > > 10:39:41.390230 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [S], seq > 730571314, win 65535, options [mss 256,sackOK,TS val 1346414773 ecr > 0,nop,wscale 10], length 0 > 10:39:41.458696 IP 192.168.1.2.23 > 192.168.1.1.55606: Flags [S.], seq > 43457, ack 730571315, win 4096, options [mss 966], length 0 > 10:39:41.458753 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [.], ack 1, > win 65535, length 0 > 10:39:41.459364 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq > 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO > SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL > LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] > 10:39:42.035173 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq > 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO > SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL > LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] > 10:39:43.123157 IP 192.168.1.1.55606 > 192.168.1.2.23: Flags [P.], seq > 1:31, ack 1, win 65535, length 30 [telnet DO ENCRYPT, WILL ENCRYPT, DO > SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL > LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] > ... > > regards > > -- > www.vanheusden.com [1] > > Links: > ------ > [1] http://www.vanheusden.com > From tuhs at tuhs.org Tue Apr 14 06:28:09 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 13 Apr 2026 20:28:09 +0000 Subject: [TUHS] AT&T SVR4 MP RAS? Message-ID: <5B3UbBBZEXGtg_58yEUhwPwSAP7cwtXBleuFo7NVRgI3pJJVHelCkHjw5a6hqwItn3YZ8TpOKXUeSevked6UA9aWVUK18FNjlFCsIUiFxJI=@protonmail.com> Passing this one up, but wanted to share there is some late oddball SVR4 box on eBay, might be significant: https://www.ebay.com/itm/377109437421 After the link is a box set for AT&T UNIX SVR4 MP-RAS. Looks to be SVR4 with some fault tolerance stuff from NCR? I haven't done my research but in case someone else is looking to get into the UNIX archival business, I'm not jumping at this one. - Matt G. From tuhs at tuhs.org Tue Apr 14 14:26:26 2026 From: tuhs at tuhs.org (Chris Hanson via TUHS) Date: Mon, 13 Apr 2026 21:26:26 -0700 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: References: Message-ID: <6F578299-2A93-49C6-8C39-9F714705C2A3@eschatologist.net> On Apr 6, 2026, at 4:12 PM, segaloco via TUHS wrote: > > DTB to me is better than having to go twiddling baked in kernel addresses at build time, then you really do need a kernel-per-machine rather than being able to spin a "defconfig" kernel that'll hopefully at least give you serial TTY on whatever you're messing with. This is the main reason I think someone is working on improving device tree adoption in NetBSD; availability of community and vendor device trees could reduce the number of more specialized kernel builds needed, and reduce the requirement to do a full port to support new hardware. -- Chris From tuhs at tuhs.org Tue Apr 14 17:44:41 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 14 Apr 2026 07:44:41 +0000 Subject: [TUHS] More Lost BTL UNIX Literature Procured In-Reply-To: <202604070649.6376nfH0099434@freefriends.org> References: <202604070649.6376nfH0099434@freefriends.org> Message-ID: <88ChQJL-Z7OpvvBOUFJb1oYQGLcYj83YThpjyxEqMms7EIF3kh8mvBpVs1HbwhQJC2-A8nesGNyw5ZBE-VG2caqNeC3vm1e7q2gFEpGuG5Q=@protonmail.com> Alright, here's the last bit of Release 4.0 stuff from the recent document haul: https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/UNIX_Selected_Manual_Pages_Release_4.0.pdf This time around is the letter included with a Release 4.0 tape shipment as well as the selected manual pages indicated as document set 10 in the letter. While no hard-copy manuals were published, BTL did offer these specific pages with the shipment. This list also includes the recently scanned PRD as document 1. Documents 4-9 are accounted for in the Documents For UNIX set scanned a few years back. Between all of these documents, I believe the only remaining published Release 4.0 documents to preserve are: UNIX Release 4.0 - Highlights of Changes to Commands - F. M. Carlson & R. R. Rush Setting up UNIX - R. C. Haight, M. J. Petrella, and L. A. Wehr Administrative Advice for UNIX - R. C. Haight The former is referenced in the PRD whereas the latter are referenced in a few spots, most notably in "Recommended Reading" in the Documents For UNIX TOC. The reason given for their not being included: > Because this document changes with each release of UNIX, it is not > included here; it is distributed with each copy of the UNIX system > itself. Hopefully if any of these papers for Release 4.0 *do* show up, they are accompanying tapes...in any case, I now plan on getting back to the SVR2 BTL stuff then probably the Release 4.1 manual, although with all this new stuff there is much to do in on-line reconstructions as well... - Matt G. P.S. I'll be updating the documentation section of the wiki quite a bit with all this recent stuff pretty soon. From tuhs at tuhs.org Tue Apr 14 19:54:42 2026 From: tuhs at tuhs.org (Kevin Bowling via TUHS) Date: Tue, 14 Apr 2026 02:54:42 -0700 Subject: [TUHS] AT&T SVR4 MP RAS? In-Reply-To: <5B3UbBBZEXGtg_58yEUhwPwSAP7cwtXBleuFo7NVRgI3pJJVHelCkHjw5a6hqwItn3YZ8TpOKXUeSevked6UA9aWVUK18FNjlFCsIUiFxJI=@protonmail.com> References: <5B3UbBBZEXGtg_58yEUhwPwSAP7cwtXBleuFo7NVRgI3pJJVHelCkHjw5a6hqwItn3YZ8TpOKXUeSevked6UA9aWVUK18FNjlFCsIUiFxJI=@protonmail.com> Message-ID: On Mon, Apr 13, 2026 at 1:28 PM segaloco via TUHS wrote: > > Passing this one up, but wanted to share there is some late oddball SVR4 box on eBay, might be significant: > > https://www.ebay.com/itm/377109437421 > > After the link is a box set for AT&T UNIX SVR4 MP-RAS. Looks to be SVR4 with some fault tolerance stuff from NCR? I haven't done my research but in case someone else is looking to get into the UNIX archival business, I'm not jumping at this one. Interesting, I grabbed it because I have a non-zero chance of running into a NCR 43xx at some point. I'm somewhat surprised by the AT&T branding and not NCR.. with the 1996 date. This era of ATT-IS/NCR had some very interesting x86 systems: https://www.ardent-tool.com/NCR/Docs/ncr3000overview.pdf http://ps-2.kev009.com/ncr3xxx/thecorememory/html/ncr_system_3000.html What little I gleaned back in the day, before some of this was memory holed, is that they sold some of these 128-256 CPU x86 systems and they were basically synonymous with Teradata and used by large retailers like Walmart to do datamining. Would have been impressive to see one in the early 90s. The smaller ones were normal PC servers, but they did have SMP and pushed it a few years before most other vendors who waited for Intel with the glueless P54C SMP and APIC. > - Matt G. From tuhs at tuhs.org Wed Apr 15 06:40:43 2026 From: tuhs at tuhs.org (Adam Koszek via TUHS) Date: Tue, 14 Apr 2026 13:40:43 -0700 Subject: [TUHS] UNIX testing / error injection Message-ID: Hello, A friend told me that UNIX engineers went through great pains to test software. I heard a story about bubble gum wrapper being stuck into IDE disk cable to short some lines to inject errors, and see if the filesystem would handle/survive this. Were there any more examples of this? After UNIX was already running many program, were any of the complex pieces of system code ever developed in the user-space first? Filesystems/schedulers/networking are inherently hard to get right, and the compile -> boot -> see kernel fail wasn’t ever fun cycle for me, and it had to be hell on slow machines.. How was all this good code delivered? :) I’ve learnt a buzzword: “deterministic simulation testing”. It’s when you stub everything and run program in a fully controllable virtual world, and can inject faults etc. These days I can build mini datacenter in a single Golang program, but I’m wondering how the software that came before was developed. Adam From tuhs at tuhs.org Wed Apr 15 22:43:49 2026 From: tuhs at tuhs.org (Yufeng Gao via TUHS) Date: Wed, 15 Apr 2026 12:43:49 +0000 Subject: [TUHS] Help Scanning UNIX V5-V7 Manuals Message-ID: Hi, I've borrowed these UNIX manuals (full V5-V7) from Prof. Ian Hayes, to have them preserved. https://thebrokenpipe.com/uploads/unix_manuals.jpg They're from UNSW and are slightly different compared to the existing scans/troff sources. Does anyone know if there's any way to scan these? These are bound books, which makes them difficult to scan as they do not lay flat on flatbed scanners or work at all with auto document feed. Given these aren't mine and I need to return them, I cannot scan them destructively. Would appreciate any pointers/tips. Sincerely, Yufeng From tuhs at tuhs.org Wed Apr 15 23:26:17 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 15 Apr 2026 13:26:17 +0000 Subject: [TUHS] Help Scanning UNIX V5-V7 Manuals In-Reply-To: References: Message-ID: Hello, Yufeng, Try using either a standalone scanning app on a smartphone such as Camscanner or a smartphone which has that ability built into its camera app such as a Samsung. If you use trial and error to get the lighting correct and, possibly, use a simple framework or support for the smartphone, you should achieve consistent results. I used to use the CamScanner app but since moving to a Samsung smartphone, for work, I can simply use the camera app which comes with the phone. Correction for angle of document, correction of detected edge(s) and, with Samsung camera app, even OCR is catered for. Here: https://ibb.co/Kj88mxsV Is the result for a small, A6, soft card which was not perfectly flat and with the smartphone merely held by hand. With proper planning, lighting and set-up, an improved result can be achieved. I once copied an entire technical document for a locomotive, whilst onboard the locomotive and with no pre-planning, and the results were acceptable. Best wishes, Cameron -------- Original Message -------- On Wednesday, 04/15/26 at 13:44 Yufeng Gao via TUHS wrote: Hi, I've borrowed these UNIX manuals (full V5-V7) from Prof. Ian Hayes, to have them preserved. https://thebrokenpipe.com/uploads/unix_manuals.jpg They're from UNSW and are slightly different compared to the existing scans/troff sources. Does anyone know if there's any way to scan these? These are bound books, which makes them difficult to scan as they do not lay flat on flatbed scanners or work at all with auto document feed. Given these aren't mine and I need to return them, I cannot scan them destructively. Would appreciate any pointers/tips. Sincerely, Yufeng From tuhs at tuhs.org Wed Apr 15 23:40:44 2026 From: tuhs at tuhs.org (Marc Rochkind via TUHS) Date: Wed, 15 Apr 2026 15:40:44 +0200 Subject: [TUHS] UNIX testing / error injection In-Reply-To: References: Message-ID: When you use the phrase "UNIX engineers," to whom are you referring? At the beginning and for years afterwards, UNIX was a research project. If there was engineering, it came along much later. On Tue, Apr 14, 2026, 10:41 PM Adam Koszek via TUHS wrote: > Hello, > > A friend told me that UNIX engineers went through great pains to test > software. I heard a story about bubble gum wrapper being stuck into IDE > disk cable to short some lines to inject errors, and see if the filesystem > would handle/survive this. > > Were there any more examples of this? > > After UNIX was already running many program, were any of the complex > pieces of system code ever developed in the user-space first? > Filesystems/schedulers/networking are inherently hard to get right, and the > compile -> boot -> see kernel fail wasn’t ever fun cycle for me, and it had > to be hell on slow machines.. > > How was all this good code delivered? :) > > I’ve learnt a buzzword: “deterministic simulation testing”. It’s when you > stub everything and run program in a fully controllable virtual world, and > can inject faults etc. These days I can build mini datacenter in a single > Golang program, but I’m wondering how the software that came before was > developed. > > Adam From tuhs at tuhs.org Wed Apr 15 23:54:08 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Wed, 15 Apr 2026 07:54:08 -0600 Subject: [TUHS] UNIX testing / error injection In-Reply-To: References: Message-ID: <202604151354.63FDs8W8077836@freefriends.org> On Tue, Apr 14, 2026, 10:41 PM Adam Koszek via TUHS wrote: > > [ .... ] > > After UNIX was already running many program, were any of the complex > pieces of system code ever developed in the user-space first? > Filesystems/schedulers/networking are inherently hard to get right, and the > compile -> boot -> see kernel fail wasn’t ever fun cycle for me, and it had > to be hell on slow machines.. If I recall correctly, the initial work on the 4.2BSD fast filesystem was done in user space. I'm not sure where I read that, but it might be discussed in the TUHS archives. Arnold From tuhs at tuhs.org Thu Apr 16 00:03:57 2026 From: tuhs at tuhs.org (Larry McVoy via TUHS) Date: Wed, 15 Apr 2026 07:03:57 -0700 Subject: [TUHS] UNIX testing / error injection In-Reply-To: <202604151354.63FDs8W8077836@freefriends.org> References: <202604151354.63FDs8W8077836@freefriends.org> Message-ID: <20260415140357.GO25708@mcvoy.com> On Wed, Apr 15, 2026 at 07:54:08AM -0600, Arnold Robbins via TUHS wrote: > On Tue, Apr 14, 2026, 10:41???PM Adam Koszek via TUHS wrote: > > > > [ .... ] > > > > After UNIX was already running many program, were any of the complex > > pieces of system code ever developed in the user-space first? > > Filesystems/schedulers/networking are inherently hard to get right, and the > > compile -> boot -> see kernel fail wasn???t ever fun cycle for me, and it had > > to be hell on slow machines.. > > If I recall correctly, the initial work on the 4.2BSD fast filesystem > was done in user space. I'm not sure where I read that, but it might > be discussed in the TUHS archives. When srk prototyped extents in UFS, it was in user space. He basically wacked mkfs to not put a rot delay in there, made a file system, made some files, and mounted it to prove it worked. He handed that to me and told me to make it work in the kernel. It doubled throughput for sequential I/O but didn't have much of an effect for normal work loads. A far greater win is still waiting for someone to do it, do read ahead on stuff in /usr/include or wherever. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Thu Apr 16 00:36:40 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Wed, 15 Apr 2026 07:36:40 -0700 Subject: [TUHS] Help Scanning UNIX V5-V7 Manuals In-Reply-To: References: Message-ID: <617cc070-1d46-cc9d-d410-62698cd28145@bitsavers.org> On 4/15/26 6:26 AM, Cameron Míċeál Tyre via TUHS wrote: > Hello, Yufeng, > > Try using either a standalone scanning app on a smartphone such as Camscanner or a smartphone which has that ability built into its camera app such as a Samsung. Be EXTREMELY careful attempting to correctly archive documents with smartphones, especially at high resolutions. They have been known to apply AI slop to the images. I had a friend that took a high resolution picture of a pc board and the markings on the chips were made illegible. From tuhs at tuhs.org Thu Apr 16 00:48:13 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 15 Apr 2026 14:48:13 +0000 Subject: [TUHS] Help Scanning UNIX V5-V7 Manuals In-Reply-To: <617cc070-1d46-cc9d-d410-62698cd28145@bitsavers.org> References: <617cc070-1d46-cc9d-d410-62698cd28145@bitsavers.org> Message-ID: On Wednesday, April 15th, 2026 at 07:36, Al Kossow via TUHS wrote: > On 4/15/26 6:26 AM, Cameron Míċeál Tyre via TUHS wrote: > > Hello, Yufeng, > > > > Try using either a standalone scanning app on a smartphone such as Camscanner or a smartphone which has that ability built into its camera app such as a Samsung. > > Be EXTREMELY careful attempting to correctly archive documents with smartphones, especially at high resolutions. > They have been known to apply AI slop to the images. I had a friend that took a high resolution picture of a > pc board and the markings on the chips were made illegible. > > If the spines aren't too fragile...there is always just brute forcing it and going page by page on a flatbed. Takes time but thats how I do my stuff non-destructively. There are also those overhead projector camera platform things, dunno what they're called, but an arts org in town has one and we used it for archiving copies of a local music magazine. - Matt G. From tuhs at tuhs.org Thu Apr 16 00:52:03 2026 From: tuhs at tuhs.org (Cody Logan via TUHS) Date: Wed, 15 Apr 2026 14:52:03 +0000 Subject: [TUHS] Help Scanning UNIX V5-V7 Manuals In-Reply-To: <617cc070-1d46-cc9d-d410-62698cd28145@bitsavers.org> References: <617cc070-1d46-cc9d-d410-62698cd28145@bitsavers.org> Message-ID: If you have an iOS device, the Halide camera app has the ability to capture RAW photos without any AI processing, though the resolution in that mode is limited to 12 megapixels. -------- Original Message -------- On Wednesday, 04/15/26 at 07:37 Al Kossow via TUHS wrote: On 4/15/26 6:26 AM, Cameron Míċeál Tyre via TUHS wrote: > Hello, Yufeng, > > Try using either a standalone scanning app on a smartphone such as Camscanner or a smartphone which has that ability built into its camera app such as a Samsung. Be EXTREMELY careful attempting to correctly archive documents with smartphones, especially at high resolutions. They have been known to apply AI slop to the images. I had a friend that took a high resolution picture of a pc board and the markings on the chips were made illegible. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Thu Apr 16 01:06:18 2026 From: tuhs at tuhs.org (Dennis Boone via TUHS) Date: Wed, 15 Apr 2026 11:06:18 -0400 Subject: [TUHS] Help Scanning UNIX V5-V7 Manuals In-Reply-To: (Your message of Wed, 15 Apr 2026 14:52:03 -0000.) References: <617cc070-1d46-cc9d-d410-62698cd28145@bitsavers.org> Message-ID: <20260415150618.9F9D2545C5D@yagi.h-net.msu.edu> > If you have an iOS device, the Halide camera app has the ability to > capture RAW photos without any AI processing, though the resolution > in that mode is limited to 12 megapixels. While I am inclined to agree with Al that using a phone for this project probably isn't a good choice, - I feel you should aim for 600 dpi. For a US letter sized page, that's about 33 megapixels. - For iPhone 14 Pro and later, the standard camera app will let you enable ProRaw, which gets you 48 megapixels, and disables most of the assorted "computational photography" features (running adjacent pixels at different ISO levels for "HDR included" photos, taking a continuous stream of images and selecting one near button-press time that's "best", maybe inclusion of the distance data from the LIDAR sensor, etc). It also disables the part where the output pixel is a result of multiple input sensor pixels, a behavior which helps defeat the issues of the rgb layout and Bayer filters and such, producing better color. None of the things disabled seem likely to be a problem for document scanning. ;) De From tuhs at tuhs.org Thu Apr 16 01:06:22 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 15 Apr 2026 15:06:22 +0000 Subject: [TUHS] Help Scanning UNIX V5-V7 Manuals In-Reply-To: References: <617cc070-1d46-cc9d-d410-62698cd28145@bitsavers.org> Message-ID: Using an iOS device would make Hexley the Platypus jump for joy also! http://www.hexley.com/ -------- Original Message -------- On Wednesday, 04/15/26 at 15:52 Cody Logan via TUHS wrote: If you have an iOS device, the Halide camera app has the ability to capture RAW photos without any AI processing, though the resolution in that mode is limited to 12 megapixels. From tuhs at tuhs.org Thu Apr 16 02:46:56 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Wed, 15 Apr 2026 12:46:56 -0400 Subject: [TUHS] UNIX testing / error injection In-Reply-To: References: Message-ID: On Tue, Apr 14, 2026 at 4:51 PM Adam Koszek via TUHS wrote: > Hello, > > A friend told me that UNIX engineers went through great pains to test software. I heard a story about bubble gum wrapper being stuck into IDE disk cable to short some lines to inject errors, and see if the filesystem would handle/survive this. > > Were there any more examples of this? I can't speak to historical examples, but I can say that at work we've taken a big magnet and pointed it at traces on our boards to induce errors to see how software handles them. - Dan C. From tuhs at tuhs.org Thu Apr 16 02:58:50 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 15 Apr 2026 16:58:50 +0000 Subject: [TUHS] UNIX testing / error injection In-Reply-To: References: Message-ID: On Wednesday, April 15th, 2026 at 09:47, Dan Cross via TUHS wrote: > On Tue, Apr 14, 2026 at 4:51 PM Adam Koszek via TUHS wrote: > > Hello, > > > > A friend told me that UNIX engineers went through great pains to test software. I heard a story about bubble gum wrapper being stuck into IDE disk cable to short some lines to inject errors, and see if the filesystem would handle/survive this. > > > > Were there any more examples of this? > > I can't speak to historical examples, but I can say that at work we've > taken a big magnet and pointed it at traces on our boards to induce > errors to see how software handles them. > > - Dan C. > Literature states that the initial work on the filesystem was all simulated in GECOS on the 635. How deeply they simulated potential hardware errors in the midst of that I couldn't say, but my understanding is there is a long tradition of simulation in UNIX development, but I don't know how much this implies direct instrumentation of test cases vs. experimentation on the more abstract design elements. - Matt G. From tuhs at tuhs.org Thu Apr 16 03:31:01 2026 From: tuhs at tuhs.org (Sevan Janiyan via TUHS) Date: Wed, 15 Apr 2026 18:31:01 +0100 Subject: [TUHS] UNIX testing / error injection In-Reply-To: References: Message-ID: <472ec01e-560d-4182-b3fa-fc51e28ecb09@geeklan.co.uk> On 14/04/2026 21:40, Adam Koszek via TUHS wrote: > Were there any more examples of this? File System eXerciser (aka fxr.c) by Avie Tevanian at NeXT. Covered in Avie Tevanian CHM oral history interview, can't remember which part though. There's 2 lengthy sessions. Good excuse to watch both? :) Sevan From tuhs at tuhs.org Thu Apr 16 03:45:35 2026 From: tuhs at tuhs.org (Sevan Janiyan via TUHS) Date: Wed, 15 Apr 2026 18:45:35 +0100 Subject: [TUHS] UNIX testing / error injection In-Reply-To: <472ec01e-560d-4182-b3fa-fc51e28ecb09@geeklan.co.uk> References: <472ec01e-560d-4182-b3fa-fc51e28ecb09@geeklan.co.uk> Message-ID: <2fa9306f-a0c5-4462-8625-48d36ba7c74d@geeklan.co.uk> On 15/04/2026 18:31, Sevan Janiyan via TUHS wrote: > aka fxr.c that should've been fsx.c Sevan From tuhs at tuhs.org Thu Apr 16 03:47:04 2026 From: tuhs at tuhs.org (Adam Koszek via TUHS) Date: Wed, 15 Apr 2026 10:47:04 -0700 Subject: [TUHS] UNIX testing / error injection In-Reply-To: References: Message-ID: <87224C5B-4448-42BE-B8D0-682616D3A510@koszek.com> I intuitively assumed there weren't a lot of simulators going on in the early days? When OS itself was a problem, but after the concurrency was there, and perhaps the filesystem was there, I could imagine people writing some C code to simulate disk, network etc. But perhaps I’m wrong? In my research on DST there was only YouTube comment about “spin network simulator from Bell Labs”, which may have been an early simulator of some sort — Holtzmann’s first paper on this was 1987. His recollections: https://scispace.com/pdf/software-verification-at-bell-labs-one-line-of-development-3rj2ypjdo9.pdf but it turned into a SPIN model checker, which is a differenet thing. Adam > On Apr 15, 2026, at 6:40 AM, Marc Rochkind via TUHS wrote: > > When you use the phrase "UNIX engineers," to whom are you referring? At the > beginning and for years afterwards, UNIX was a research project. If there > was engineering, it came along much later. > > On Tue, Apr 14, 2026, 10:41 PM Adam Koszek via TUHS wrote: > >> Hello, >> >> A friend told me that UNIX engineers went through great pains to test >> software. I heard a story about bubble gum wrapper being stuck into IDE >> disk cable to short some lines to inject errors, and see if the filesystem >> would handle/survive this. >> >> Were there any more examples of this? >> >> After UNIX was already running many program, were any of the complex >> pieces of system code ever developed in the user-space first? >> Filesystems/schedulers/networking are inherently hard to get right, and the >> compile -> boot -> see kernel fail wasn’t ever fun cycle for me, and it had >> to be hell on slow machines.. >> >> How was all this good code delivered? :) >> >> I’ve learnt a buzzword: “deterministic simulation testing”. It’s when you >> stub everything and run program in a fully controllable virtual world, and >> can inject faults etc. These days I can build mini datacenter in a single >> Golang program, but I’m wondering how the software that came before was >> developed. >> >> Adam From tuhs at tuhs.org Thu Apr 16 03:51:53 2026 From: tuhs at tuhs.org (Sevan Janiyan via TUHS) Date: Wed, 15 Apr 2026 18:51:53 +0100 Subject: [TUHS] UNIX testing / error injection In-Reply-To: <2fa9306f-a0c5-4462-8625-48d36ba7c74d@geeklan.co.uk> References: <472ec01e-560d-4182-b3fa-fc51e28ecb09@geeklan.co.uk> <2fa9306f-a0c5-4462-8625-48d36ba7c74d@geeklan.co.uk> Message-ID: <457c28cb-c2a0-4ae2-aabe-146d0f944172@geeklan.co.uk> On 15/04/2026 18:45, Sevan Janiyan via TUHS wrote: > that should've been fsx.c https://web.archive.org/web/20190115144026/http://codemonkey.org.uk/projects/fsx/ Apologies for all the emails. Sevan From tuhs at tuhs.org Thu Apr 16 04:32:23 2026 From: tuhs at tuhs.org (Theodore Tso via TUHS) Date: Wed, 15 Apr 2026 14:32:23 -0400 Subject: [TUHS] UNIX testing / error injection In-Reply-To: <472ec01e-560d-4182-b3fa-fc51e28ecb09@geeklan.co.uk> References: <472ec01e-560d-4182-b3fa-fc51e28ecb09@geeklan.co.uk> Message-ID: <20260415183223.GB20667@macsyma-wired.lan> On Wed, Apr 15, 2026 at 06:31:01PM +0100, Sevan Janiyan via TUHS wrote: > On 14/04/2026 21:40, Adam Koszek via TUHS wrote: > > Were there any more examples of this? > > File System eXerciser (aka fxr.c) by Avie Tevanian at NeXT. > Covered in Avie Tevanian CHM oral history interview, can't remember which > part though. There's 2 lengthy sessions. Good excuse to watch both? :) Fsx[1] is still used to test file systems in Linux today[2]. It came through xfstests from SGI, so it was used to test Irix file systems before it came to Linux. It's doesn't do error injectionm and in general it runs on the system under test (SUT) so it's not an example of something that tested the file system in userspace --- unless you consider using a VMM such as qemu as "userspace testing". [1] https://github.com/tytso/xfstests/blob/master/ltp/fsx.c [2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/what-is-xfstests.md - Ted From tuhs at tuhs.org Thu Apr 16 05:01:26 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 15 Apr 2026 15:01:26 -0400 Subject: [TUHS] UNIX testing / error injection In-Reply-To: <202604151354.63FDs8W8077836@freefriends.org> References: <202604151354.63FDs8W8077836@freefriends.org> Message-ID: On Wed, Apr 15, 2026 at 9:54 AM Arnold Robbins via TUHS wrote: > If I recall correctly, the initial work on the 4.2BSD fast filesystem > was done in user space. > You do. Kirk started on a system running 4.1BSD [I think it was one of the 750s that CSRG had in Evans, but it might have been on one of the shared 780s like Ernie]. Not only did it allow the core FS to be debugged, but the tools that would support it (newfs/mkfs, fsck, dump, and the like) all had their first pass written and debugged in user space. IIRC, 4.1B was when Kirk started integrating it, and we started pounding on it. I remember one of the issues that was not discovered until integration was the quadratic search for a free block. If you remember, Joy's solution was to define "full" as 10% from actually full. The problem, of course, was that with the price of rotating storage in those days [a Fujitsu Eagle (474MB) and Eagle II (689MB), which were approximately $10K and $14K], your file system was always full. As for the OP's question, it was pretty normal for a new physical FS to be simulated in user space. In some OS cases, such as Apollo's Domain, when Jim Rees, Paul Levine, Nat Mishkin, and Paul Leach implemented NFS, the FS code is called out of the kernel to user space (their solution, which they called "An Extensible I/O System," is extremely cool; there is a Chapter about it by that name in Domain/OS Design Principles doc you can find on bitsavers — https://bitsavers.org/pdf/apollo/014962-A00_Domain_OS_Design_Principles_Jan89.pdf ). From tuhs at tuhs.org Thu Apr 16 05:32:00 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Wed, 15 Apr 2026 15:32:00 -0400 Subject: [TUHS] Help Scanning UNIX V5-V7 Manuals In-Reply-To: References: Message-ID: You need a book scanner. A really good one can cost many thousands of dollars. I have a CZAR Shine Ultra Series, which sells for about $250-$350 depending on the model. Its big brother is the ET24, which is around $590 on Amazon. On Wed, Apr 15, 2026 at 8:44 AM Yufeng Gao via TUHS wrote: > Hi, > > I've borrowed these UNIX manuals (full V5-V7) from Prof. Ian Hayes, to have > them preserved. > > https://thebrokenpipe.com/uploads/unix_manuals.jpg > > They're from UNSW and are slightly different compared to the existing > scans/troff sources. Does anyone know if there's any way to scan these? > These > are bound books, which makes them difficult to scan as they do not lay > flat on > flatbed scanners or work at all with auto document feed. Given these aren't > mine and I need to return them, I cannot scan them destructively. > > Would appreciate any pointers/tips. > > Sincerely, > Yufeng From tuhs at tuhs.org Thu Apr 16 07:11:00 2026 From: tuhs at tuhs.org (Adam Koszek via TUHS) Date: Wed, 15 Apr 2026 14:11:00 -0700 Subject: [TUHS] Help Scanning UNIX V5-V7 Manuals In-Reply-To: References: Message-ID: Yufeng, If you’re in Bay Area, the bigger libraries have the book scanners. Call Mountain View public library. Stanford’s Green Library has such scanner for sure for public use. The folks at the frontdesk are helpful - they may give you hints on digitizing this stuff. Adam > On Apr 15, 2026, at 12:32 PM, Clem Cole via TUHS wrote: > > You need a book scanner. A really good one can cost many thousands of > dollars. I have a CZAR Shine Ultra Series, which sells for about $250-$350 > depending on the model. Its big brother is the ET24, which is around $590 > on Amazon. > > On Wed, Apr 15, 2026 at 8:44 AM Yufeng Gao via TUHS wrote: > >> Hi, >> >> I've borrowed these UNIX manuals (full V5-V7) from Prof. Ian Hayes, to have >> them preserved. >> >> https://thebrokenpipe.com/uploads/unix_manuals.jpg >> >> They're from UNSW and are slightly different compared to the existing >> scans/troff sources. Does anyone know if there's any way to scan these? >> These >> are bound books, which makes them difficult to scan as they do not lay >> flat on >> flatbed scanners or work at all with auto document feed. Given these aren't >> mine and I need to return them, I cannot scan them destructively. >> >> Would appreciate any pointers/tips. >> >> Sincerely, >> Yufeng From tuhs at tuhs.org Thu Apr 16 07:25:41 2026 From: tuhs at tuhs.org (Sevan Janiyan via TUHS) Date: Wed, 15 Apr 2026 22:25:41 +0100 Subject: [TUHS] UNIX testing / error injection In-Reply-To: <20260415183223.GB20667@macsyma-wired.lan> References: <472ec01e-560d-4182-b3fa-fc51e28ecb09@geeklan.co.uk> <20260415183223.GB20667@macsyma-wired.lan> Message-ID: On 15/04/2026 19:32, Theodore Tso wrote: > Fsx[1] is still used to test file systems in Linux today[2]. It came > through xfstests from SGI, so it was used to test Irix file systems > before it came to Linux. It's doesn't do error injectionm and in > general it runs on the system under test (SUT) so it's not an example > of something that tested the file system in userspace --- unless you > consider using a VMM such as qemu as "userspace testing". > > [1]https://github.com/tytso/xfstests/blob/master/ltp/fsx.c > [2]https://github.com/tytso/xfstests-bld/blob/master/Documentation/what-is- > xfstests.md Thanks for the background on the version in Linux today. I was actually thinking of the story of the original fsx which Avi Tevanian described how it came about in 1988: https://youtu.be/vwCdKU9uYnE?t=6360 - 1:46:00 mark for 3 minutes Sevan From tuhs at tuhs.org Thu Apr 16 10:19:36 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Thu, 16 Apr 2026 00:19:36 +0000 Subject: [TUHS] UNIX testing / error injection In-Reply-To: References: <472ec01e-560d-4182-b3fa-fc51e28ecb09@geeklan.co.uk> <20260415183223.GB20667@macsyma-wired.lan> Message-ID: Hello Sevan, I looked through the source code that someone posted a link to earlier, directly or indirectly I can't remember, sorry. The authorship is commented to be as follows: * 𝙵𝚒𝚕𝚎: 𝚏𝚜𝚡.𝚌 * 𝙰𝚞𝚝𝚑𝚘𝚛: 𝙰𝚟𝚊𝚍𝚒𝚜 𝚃𝚎𝚟𝚊𝚗𝚒𝚊𝚗, 𝙹𝚛. * 𝚁𝚎𝚠𝚛𝚒𝚝𝚝𝚎𝚗 8/98 𝚋𝚢 𝙲𝚘𝚗𝚛𝚊𝚍 𝙼𝚒𝚗𝚜𝚑𝚊𝚕𝚕. * 𝚂𝚖𝚊𝚕𝚕 𝚌𝚑𝚊𝚗𝚐𝚎𝚜 𝚝𝚘 𝚠𝚘𝚛𝚔 𝚞𝚗𝚍𝚎𝚛 𝙻𝚒𝚗𝚞𝚡 -- 𝚍𝚊𝚟𝚎𝚓. Rewritten and then small changes but still credited to Avi Tevanian. I would like to see the original source code Avi wrote, for comparison, I confess. Best regards, Cameron -------- Original Message -------- On Wednesday, 04/15/26 at 22:26 Sevan Janiyan via TUHS wrote: Thanks for the background on the version in Linux today. I was actually thinking of the story of the original fsx which Avi Tevanian described how it came about in 1988: https://youtu.be/vwCdKU9uYnE?t=6360 - 1:46:00 mark for 3 minutes Sevan From tuhs at tuhs.org Thu Apr 16 11:48:26 2026 From: tuhs at tuhs.org (Alexis via TUHS) Date: Thu, 16 Apr 2026 11:48:26 +1000 Subject: [TUHS] UNIX testing / error injection In-Reply-To: ("Cameron =?utf-8?B?TcOtxItlw6Fs?= Tyre via TUHS"'s message of "Thu, 16 Apr 2026 00:19:36 +0000") References: <472ec01e-560d-4182-b3fa-fc51e28ecb09@geeklan.co.uk> <20260415183223.GB20667@macsyma-wired.lan> Message-ID: <87se8vzndh.fsf@gmail.com> Cameron Míċeál Tyre via TUHS writes: > The authorship is commented to be as follows: > > [snip use of mathematical symbols for English text] i'd like to discourage this sort of use of mathematical symbols from Unicode (the capital 'A' in the snipped text was MATHEMATICAL MONOSPACE CAPITAL A) as a way of producing 'fancy font' output in plain text. This post provides a good overview of why it's problematic: https://www.foundationwebdev.com/2025/05/unicode-on-social-media/ i don't use a screenreader myself, but i know devs who do. Alexis. From tuhs at tuhs.org Thu Apr 16 14:47:42 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Thu, 16 Apr 2026 04:47:42 +0000 Subject: [TUHS] UNIX testing / error injection In-Reply-To: <87se8vzndh.fsf@gmail.com> References: <472ec01e-560d-4182-b3fa-fc51e28ecb09@geeklan.co.uk> <20260415183223.GB20667@macsyma-wired.lan> <87se8vzndh.fsf@gmail.com> Message-ID: Hello Alexis, Yes, my mistake, sorry. On every other forum I am on, use of typewriter style monospace text to represent code snippets is, it seems, de rigueur. It becomes so ingrained that I forgot I was posting on TUHS. For anyone who got a garbled mess, it was supposed to read as follows: * File: fsx.c * Author: Avadis Tevanian, Jr. * * File system exerciser. * * Rewritten 8/98 by Conrad Minshall. * * Small changes to work under Linux -- davej. Best wishes, Cameron Sent from Proton Mail for Android. -------- Original Message -------- On Thursday, 04/16/26 at 02:48 Alexis via TUHS wrote: Cameron Míċeál Tyre via TUHS writes: > The authorship is commented to be as follows: > > [snip use of mathematical symbols for English text] i'd like to discourage this sort of use of mathematical symbols from Unicode (the capital 'A' in the snipped text was MATHEMATICAL MONOSPACE CAPITAL A) as a way of producing 'fancy font' output in plain text. This post provides a good overview of why it's problematic: https://www.foundationwebdev.com/2025/05/unicode-on-social-media/ i don't use a screenreader myself, but i know devs who do. Alexis. From tuhs at tuhs.org Thu Apr 16 18:18:38 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Thu, 16 Apr 2026 08:18:38 +0000 Subject: [TUHS] Old Unix tapes from University of Nottingham Message-ID: <7wtstbtj1d.fsf@junk.nocrew.org> 23 magtapes found at University of Notthingham, spanning roughly 1985-1993. Is there anything of interest? https://github.com/larsbrinkhoff/bagley-nottingham-tapes From tuhs at tuhs.org Thu Apr 16 21:22:41 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 16 Apr 2026 11:22:41 +0000 Subject: [TUHS] Old Unix tapes from University of Nottingham In-Reply-To: <7wtstbtj1d.fsf@junk.nocrew.org> References: <7wtstbtj1d.fsf@junk.nocrew.org> Message-ID: On Thursday, April 16th, 2026 at 01:18, Lars Brinkhoff via TUHS wrote: > 23 magtapes found at University of Notthingham, spanning roughly > 1985-1993. Is there anything of interest? > > https://github.com/larsbrinkhoff/bagley-nottingham-tapes > I'd certainly be interested in the V8 tapes being archived. I understand the current archives we have are original snapshots from a BTL server in the Plan9 days, but it'd be cool to have proper images of the distro tapes, for instance, for SimH. Other than that, lots of font and Sun stuff there, can't speak to the value or how much has already been preserved anywhere. - Matt G. From tuhs at tuhs.org Thu Apr 16 21:32:51 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Thu, 16 Apr 2026 11:32:51 +0000 Subject: [TUHS] Old Unix tapes from University of Nottingham In-Reply-To: <7wtstbtj1d.fsf@junk.nocrew.org> (Lars Brinkhoff via TUHS's message of "Thu, 16 Apr 2026 08:18:38 +0000") References: <7wtstbtj1d.fsf@junk.nocrew.org> Message-ID: <7wpl3zta1o.fsf@junk.nocrew.org> Some backstory. In the 80s, U of Nottingham decided to set up their own printing shop. They purchased the same type of typesetter Bell labs had. They got a PDP-11 to drive it, and contacted the lab for support. Brian Kernigman would regularly vacation in the UK, and often make a stop to visit the Nottingham faculty. From tuhs at tuhs.org Thu Apr 16 21:57:52 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Thu, 16 Apr 2026 04:57:52 -0700 Subject: [TUHS] Old Unix tapes from University of Nottingham In-Reply-To: References: <7wtstbtj1d.fsf@junk.nocrew.org> Message-ID: <4f50aa85-2854-96b2-f1c7-266368998e13@bitsavers.org> As far as I know, no one in the UK has the experience to successfully recover 1980's QIC media. There are only a few people in the whole world that have been able to do this consistently, and I don't even consider myself one of them. From tuhs at tuhs.org Thu Apr 16 22:15:15 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Thu, 16 Apr 2026 07:15:15 -0500 Subject: [TUHS] Old Unix tapes from University of Nottingham In-Reply-To: <7wpl3zta1o.fsf@junk.nocrew.org> Message-ID: <20260416121515.3eejf44cdqvvcno7@illithid> Hi Matt & Lars, At 2026-04-16T11:22:41+0000, segaloco via TUHS wrote: > On Thursday, April 16th, 2026 at 01:18, Lars Brinkhoff via TUHS > wrote: > > > 23 magtapes found at University of Notthingham, spanning roughly > > 1985-1993. Is there anything of interest? > > > > https://github.com/larsbrinkhoff/bagley-nottingham-tapes > > I'd certainly be interested in the V8 tapes being archived. Ditto. V8 is represented by an unfortunate gap on the software side. (Thanks to good luck and being in Australia at the right time, I acquired a hard copy of the V8 manual, which is interesting reading.) > I understand the current archives we have are original snapshots from > a BTL server in the Plan9 days, but it'd be cool to have proper images > of the distro tapes, for instance, for SimH. Vigorously agree. > Other than that, lots of font and Sun stuff there, can't speak to the > value or how much has already been preserved anywhere. Sounds like it might be too early for MoOLIT. I really want to see the sources for that. At 2026-04-16T11:32:51+0000, Lars Brinkhoff via TUHS wrote: > Some backstory. In the 80s, U of Nottingham decided to set up their > own printing shop. They purchased the same type of typesetter Bell > labs had. An Autologic APS-5? > They got a PDP-11 to drive it, and contacted the lab for support. > Brian Kernigman would regularly vacation in the UK, and often make a > stop to visit the Nottingham faculty. A copy of the troff sources from V8 or from DWB 2.0 would be valuable. To have both would be tremendous. Much of troff history in the gap between Seventh Edition Unix in 1979 on one side and and DWB 3.3 (~1993) and Plan 9 (mid-1990s) on the other is a dark tunnel.[1] I guess because AT&T was trying to monetize it. Regards, Branden [1] The recovery and scan (by Matt?) of "UNIX 4.0"'s version of CSTR #54 which appears to be a previously unattested revision made, presumably by Kernighan, almost immediately after the device- independence changes landed, were a breakthrough in the reconstruction of troff history, IMO. https://lists.gnu.org/archive/html/groff/2022-06/msg00033.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tuhs at tuhs.org Fri Apr 17 01:50:20 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Thu, 16 Apr 2026 11:50:20 -0400 (EDT) Subject: [TUHS] Old Unix tapes from University of Nottingham Message-ID: <20260416155020.3D03018C086@mercury.lcs.mit.edu> > From: Lars Brinkhoff > Is there anything of interest? I was momentarily taken by the: BSD/386 Release 0.3.3 Beta Copright BSDI 1992 tape (as I wasn't sure if we had that one), but then I saw that it read "X11R5" - not so exciting! Noel From tuhs at tuhs.org Fri Apr 17 02:31:14 2026 From: tuhs at tuhs.org (James Frew via TUHS) Date: Thu, 16 Apr 2026 09:31:14 -0700 Subject: [TUHS] Old Unix tapes from University of Nottingham In-Reply-To: <4f50aa85-2854-96b2-f1c7-266368998e13@bitsavers.org> References: <7wtstbtj1d.fsf@junk.nocrew.org> <4f50aa85-2854-96b2-f1c7-266368998e13@bitsavers.org> Message-ID: <569f7f24-3e1a-43ce-896f-ca72d16a0eb3@ucsb.edu> True THAT. It was iffy enough recovering data from 1980s QIC media in the 1980s. /Frew On 2026-04-16 4:57 AM, Al Kossow via TUHS wrote: > > As far as I know, no one in the UK has the experience to successfully > recover 1980's QIC media. There are only a few people in the whole > world that have been able to do this consistently, and I don't even > consider myself one of them. From tuhs at tuhs.org Fri Apr 17 02:55:26 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Thu, 16 Apr 2026 09:55:26 -0700 Subject: [TUHS] Old Unix tapes from University of Nottingham In-Reply-To: <569f7f24-3e1a-43ce-896f-ca72d16a0eb3@ucsb.edu> References: <7wtstbtj1d.fsf@junk.nocrew.org> <4f50aa85-2854-96b2-f1c7-266368998e13@bitsavers.org> <569f7f24-3e1a-43ce-896f-ca72d16a0eb3@ucsb.edu> Message-ID: On 4/16/26 9:31 AM, James Frew via TUHS wrote: > True THAT. It was iffy enough recovering data from 1980s QIC media in the 1980s. > > /Frew > > On 2026-04-16 4:57 AM, Al Kossow via TUHS wrote: >> >> As far as I know, no one in the UK has the experience to successfully >> recover 1980's QIC media. There are only a few people in the whole >> world that have been able to do this consistently, and I don't even >> consider myself one of them. I mentioned on another list that one of the UK institutions needs to step up and establish a media recovery lab There will be many bread crumbs left for them to follow in http://bitsavers.org/BBofBS They also need to be willing to release the contents of said media. (hint: "no commercial value") From tuhs at tuhs.org Fri Apr 17 03:34:13 2026 From: tuhs at tuhs.org (Pete Wright via TUHS) Date: Thu, 16 Apr 2026 10:34:13 -0700 Subject: [TUHS] AT&T SVR4 MP RAS? In-Reply-To: References: <5B3UbBBZEXGtg_58yEUhwPwSAP7cwtXBleuFo7NVRgI3pJJVHelCkHjw5a6hqwItn3YZ8TpOKXUeSevked6UA9aWVUK18FNjlFCsIUiFxJI=@protonmail.com> Message-ID: <6bed781c-960c-4819-9c4a-214e0c093620@nomadlogic.org> On 4/14/26 02:54, Kevin Bowling via TUHS wrote: > On Mon, Apr 13, 2026 at 1:28 PM segaloco via TUHS wrote: >> >> Passing this one up, but wanted to share there is some late oddball SVR4 box on eBay, might be significant: >> >> https://www.ebay.com/itm/377109437421 >> >> After the link is a box set for AT&T UNIX SVR4 MP-RAS. Looks to be SVR4 with some fault tolerance stuff from NCR? I haven't done my research but in case someone else is looking to get into the UNIX archival business, I'm not jumping at this one. > > Interesting, I grabbed it because I have a non-zero chance of running > into a NCR 43xx at some point. I'm somewhat surprised by the AT&T > branding and not NCR.. with the 1996 date. > not going to lie that that posting brought back lots of memories of when i was working for Intersolv Software in their warehouse packaging their software. One of my responsibilities, as a college student, was creating Unix license floppies in pretty much identical packaging. Spent lots of "downtime" there reading the physical manuals on that job... glad it found a good home -pete -- Pete Wright pete at nomadlogic.org From tuhs at tuhs.org Fri Apr 17 08:07:05 2026 From: tuhs at tuhs.org (Matt Day via TUHS) Date: Thu, 16 Apr 2026 16:07:05 -0600 Subject: [TUHS] Old Unix tapes from University of Nottingham In-Reply-To: <4f50aa85-2854-96b2-f1c7-266368998e13@bitsavers.org> References: <7wtstbtj1d.fsf@junk.nocrew.org> <4f50aa85-2854-96b2-f1c7-266368998e13@bitsavers.org> Message-ID: I haven't tried them yet, but Howard Atherton at Apex Technology in Sandbach, Cheshire, UK claims to have had some success at recovering from QIC: https://disktransfer.co.uk/tape.php I have a QIC and an 8mm circa 1991 that I've been meaning to send to him, but it sounds like a longshot now. On Thu, Apr 16, 2026 at 1:41 PM Al Kossow via TUHS wrote: > As far as I know, no one in the UK has the experience to successfully > recover 1980's QIC media. There are only a few people in the whole > world that have been able to do this consistently, and I don't even > consider myself one of them. > > > From tuhs at tuhs.org Fri Apr 17 08:22:00 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Thu, 16 Apr 2026 15:22:00 -0700 Subject: [TUHS] Old Unix tapes from University of Nottingham In-Reply-To: References: <7wtstbtj1d.fsf@junk.nocrew.org> <4f50aa85-2854-96b2-f1c7-266368998e13@bitsavers.org> Message-ID: <39b01ae9-993b-6880-d1ca-c6440558a2a4@bitsavers.org> On 4/16/26 3:07 PM, Matt Day wrote: > I haven't tried them yet, but Howard Atherton at Apex Technology in Sandbach, Cheshire, UK claims to have had some success at recovering > from QIC: > https://disktransfer.co.uk/tape.php > I would REALLY be interested in what they would quote you to do this. Len Shustek mentioned in the Unix V4 recovery video he paid $1000 for a 1/2" tape recovery that was inferior to the one we did of the same tape. I would REALLY be interested in what they would charge to do this. Len Shustek mentioned in the Unix V4 recovery video he paid $1000 for a 1/2" tape recovery that was inferior to the one we did of the same tape. From tuhs at tuhs.org Fri Apr 17 08:40:18 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 16 Apr 2026 22:40:18 +0000 Subject: [TUHS] Old Unix tapes from University of Nottingham In-Reply-To: <39b01ae9-993b-6880-d1ca-c6440558a2a4@bitsavers.org> References: <7wtstbtj1d.fsf@junk.nocrew.org> <4f50aa85-2854-96b2-f1c7-266368998e13@bitsavers.org> <39b01ae9-993b-6880-d1ca-c6440558a2a4@bitsavers.org> Message-ID: On Thursday, April 16th, 2026 at 15:22, Al Kossow via TUHS wrote: > On 4/16/26 3:07 PM, Matt Day wrote: > > I haven't tried them yet, but Howard Atherton at Apex Technology in Sandbach, Cheshire, UK claims to have had some success at recovering > > from QIC: > > https://disktransfer.co.uk/tape.php > > > > I would REALLY be interested in what they would quote you to do this. > > Len Shustek mentioned in the Unix V4 recovery video he paid $1000 for a 1/2" tape recovery > that was inferior to the one we did of the same tape. > > > I would REALLY be interested in what they would charge to do this. > > Len Shustek mentioned in the Unix V4 recovery video he paid $1000 for a 1/2" tape recovery > that was inferior to the one we did of the same tape. > > Moving to COFF re: QIC tapes. I still have that box of 17 QIC from BTL from the early 90s. I recently got a real cheap QIC drive (wrong size, mini) but mostly to just play with the read head, see how it responds to manual transport of the tape over the head. If that works out all fine and good, given how stupid QIC backup is currently, vs the mountain of tapes out there in the world...it seems like there might be a need for a modified piece of hardware to just pull the reels out of the cartridge entirely and let something else do the transport. Granted I'm still kinda green in this area, but I snagged a 7-track Kennedy read-write unit I'm also experimenting with. I'm hoping between the two of them I might be able to fashion something that'll pass the tape over the head properly. There's still the matter of serpentine reading on a single track head, but the hacky solution may just be track at a time, read, tick the head up to the next track with a knob or lever, read, wash rinse repeat. Broaching the topic as discussions over time have me convinced a good QIC recovery solution is pretty direly needed. I want to contribute what I can to that effort. - Matt G. From tuhs at tuhs.org Fri Apr 17 09:43:10 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Thu, 16 Apr 2026 19:43:10 -0400 Subject: [TUHS] Old Unix tapes from University of Nottingham In-Reply-To: References: <7wtstbtj1d.fsf@junk.nocrew.org> Message-ID: I agree with Matt WRT to the two V8 tapes. Turning them into *TAP format would be useful. Much of the other is likely repeats of things already in one archive or another and given most are QIC format, unless we identify something we don't already have, I suspect it too much trouble to try to read them. I'll review the Sun tapes. Other than possibly the two front tapes and SUNSRC 3.2, I believe we already have much of what is there. On Thu, Apr 16, 2026 at 7:23 AM segaloco via TUHS wrote: > On Thursday, April 16th, 2026 at 01:18, Lars Brinkhoff via TUHS < > tuhs at tuhs.org> wrote: > > > 23 magtapes found at University of Notthingham, spanning roughly > > 1985-1993. Is there anything of interest? > > > > https://github.com/larsbrinkhoff/bagley-nottingham-tapes > > > > I'd certainly be interested in the V8 tapes being archived. I understand > the current archives we have are original snapshots from a BTL server in > the Plan9 days, but it'd be cool to have proper images of the distro tapes, > for instance, for SimH. Other than that, lots of font and Sun stuff there, > can't speak to the value or how much has already been preserved anywhere. > > - Matt G. > From tuhs at tuhs.org Fri Apr 17 10:42:45 2026 From: tuhs at tuhs.org (Alexis via TUHS) Date: Fri, 17 Apr 2026 10:42:45 +1000 Subject: [TUHS] UNIX testing / error injection In-Reply-To: ("Cameron =?utf-8?B?TcOtxItlw6Fs?= Tyre via TUHS"'s message of "Thu, 16 Apr 2026 04:47:42 +0000") References: <472ec01e-560d-4182-b3fa-fc51e28ecb09@geeklan.co.uk> <20260415183223.GB20667@macsyma-wired.lan> <87se8vzndh.fsf@gmail.com> Message-ID: <87se8uxvqy.fsf@gmail.com> Cameron Míċeál Tyre via TUHS writes: > Yes, my mistake, sorry. > > On every other forum I am on, use of typewriter style monospace > text > to represent code snippets is, it seems, de rigueur. It becomes > so > ingrained that I forgot I was posting on TUHS. Ah, fair enough! Although i'm sorry to hear that so many forums are effectively requiring misuse of Unicode .... > For anyone who got a garbled mess, it was supposed to read as > follows: Thanks for providing this. :-) Alexis. From tuhs at tuhs.org Sat Apr 18 03:36:27 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Fri, 17 Apr 2026 13:36:27 -0400 Subject: [TUHS] Michael O Rabin has died Message-ID: I just heard that Michael O Rabin passed away a few days ago, on April 14th. In addition to producing a number of advances in cryptography and computability, he shared the 1976 ACM Turing Award with Dana S Scott for their joint paper titled, "Finite Automata and Their Decision Problems", that introduced non-deterministic finite automata. These machines are, of course, familiar to TUHS and COFF readers because of their applications to practical software implementations of pattern matching with regular expressions. I was fortunate to be able to take his introductory cryptography course during one of the semesters when he taught it at Columbia[*]. It was an amazing experience: for someone so eminent, he was a phenomenal instructor who was clearly animated by the joy of teaching. One presumes he didn't have to teach that course, but he wanted to, and rather obviously enjoyed doing so. Condolences to his friends and family, and, as I believe it is customary to say in Judaism, may his memory be a blessing. - Dan C. [*] Rabin's daughter, Tal Rabin, is herself a respected computer scientist and is at IBM TJ Watson in Yorktown Heights; her father would venture down to New York City for a semester here and there, teach at Columbia, and spend time with his grand children, who he would occasionally mention in class: I remember a discussion of some primitive that would be resilient to data loss, and he mentioned "grandchildren stuffing peanut butter and jelly sandwiches into computers" as a concrete example of such loss: it was unclear whether he meant it literally. From tuhs at tuhs.org Sat Apr 18 06:50:22 2026 From: tuhs at tuhs.org (Dan Plassche via TUHS) Date: Fri, 17 Apr 2026 16:50:22 -0400 Subject: [TUHS] Help Scanning UNIX V5-V7 Manuals In-Reply-To: References: Message-ID: Hi Yufeng, I will send further details off list because I regularly use each of the approaches mentioned for capturing images of records. In summary, I would say that your best fit is probably either a Czur ET24 (equivalent to 300 dpi at 16") for a reading copy or a higher quality cellphone/dedicated camera on a microphone arm for something you can off-print if you are willing to spend time in post-processing (cropping, background levelling, and running OCR). Both are very quick to capture images, but you would definitely want to turn off everything but flattening and page splitting with export to png or tiff on the Czur. There is some loss of fidelity there where I would still do any color adjustments separately after capturing. Looking forward to seeing the manuals! Best, Dan Plassche From tuhs at tuhs.org Sat Apr 18 10:17:29 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sat, 18 Apr 2026 10:17:29 +1000 Subject: [TUHS] TUHS: Maintenance, Succession and Funding Message-ID: Hi all, I'm going to turn 60 in May and I've been running (and paying for) the TUHS server since I was about 30 :-) I've also retired from work and now live a life full of horse-related activities -- my wife rides, I'm just the ground crew and pooh collector. Hitting 60 has made me realise that we need to have some form of succession plan for TUHS for when I'm no longer able to keep maintaining the system. To that end, over the past year I've picked a few of the people on the TUHS list to help with the general management of the server, Minnie. The "TUHS team" are: Clem Cole, Dan Cross, David Arnold, Greg Lehey, Kevin Bowling, Larry McVoy, Matt G, Thalia Archibald, Warner Losh and Will Senn The TUHS team also forms the basis of the succession plan: they have the authority to make changes on the TUHS server, based on consensus within the team. And, if/when I'm not able to keep doing things, the TUHS team will continue with the care and feeding of Minnie. Also, now that I no longer have a salary, I've decided that it's time to allow others to help out with the yearly funding of the TUHS server. It's about US$1000 for the Linode plan that we are using. So, after 30 years, I'm finally announcing this GoFundMe plan for the TUHS service: https://gofund.me/7cc603ea3 Once we hit the yearly target, I'll turn off further contributions: I am only after enough to keep the server up and running. So that's where we are. I hope you've been happy with the TUHS work over the past 30 years, and I'm keen to see it continue indefinitely :-) Cheers, Warren From tuhs at tuhs.org Sat Apr 18 10:51:52 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 17 Apr 2026 20:51:52 -0400 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: Simply thank you. As a community you have done something that is wonderful. Clem Sent from a handheld expect more typos than usual On Fri, Apr 17, 2026 at 8:17 PM Warren Toomey via TUHS wrote: > Hi all, I'm going to turn 60 in May and I've been running (and paying for) > the TUHS server since I was about 30 :-) > > I've also retired from work and now live a life full of horse-related > activities -- my wife rides, I'm just the ground crew and pooh collector. > > Hitting 60 has made me realise that we need to have some form of > succession plan for TUHS for when I'm no longer able to keep maintaining > the system. To that end, over the past year I've picked a few of the > people on the TUHS list to help with the general management of the server, > Minnie. The "TUHS team" are: > > Clem Cole, Dan Cross, David Arnold, Greg Lehey, Kevin Bowling, > Larry McVoy, Matt G, Thalia Archibald, Raul.Warner Losh and Will Senn > > The TUHS team also forms the basis of the succession plan: they have the > authority to make changes on the TUHS server, based on consensus within > the team. And, if/when I'm not able to keep doing things, the TUHS team > will continue with the care and feeding of Minnie. > > Also, now that I no longer have a salary, I've decided that it's time to > allow others to help out with the yearly funding of the TUHS server. It's > about US$1000 for the Linode plan that we are using. So, after 30 years, > I'm finally announcing this GoFundMe plan for the TUHS service: > > https://gofund.me/7cc603ea3 > > Once we hit the yearly target, I'll turn off further contributions: > I am only after enough to keep the server up and running. > > So that's where we are. I hope you've been happy with the TUHS work > over the past 30 years, and I'm keen to see it continue indefinitely :-) > > Cheers, Warren > From tuhs at tuhs.org Sat Apr 18 11:38:23 2026 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Fri, 17 Apr 2026 21:38:23 -0400 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: On Fri, Apr 17, 2026 at 8:17 PM Warren Toomey via TUHS wrote: > Once we hit the yearly target, I'll turn off further contributions: > I am only after enough to keep the server up and running. I recommend against that. You should allow people to pay in advance, especially as so many of us have fluctuating incomes nowadays. If you get five years' worth of support right away, good: you or your successors won't need to run more campaigns for a while. From tuhs at tuhs.org Sat Apr 18 11:59:31 2026 From: tuhs at tuhs.org (steve jenkin via TUHS) Date: Sat, 18 Apr 2026 11:59:31 +1000 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: <78C5364B-9A6A-4A00-B414-5E899EDC3185@canb.auug.org.au> > On 18 Apr 2026, at 10:17, Warren Toomey via TUHS wrote: > > So that's where we are. I hope you've been happy with the TUHS work > over the past 30 years, and I'm keen to see it continue indefinitely :-) > > Cheers, Warren It’s worth remembering the future we could’ve had if SCO had won. We are very lucky to have had leaders and communities around them that prevented this, including this one. Not just no ‘Historical Unix’, no TUHS, but no Free Linux and a much reduced Open Source Software movement as a result. Which would’ve squeezed Apache, MySQL and the post-PERL languages. Including no ‘Git’ and ‘github’. The Web as we know it, could never have developed. No Linux, No Android? or could a BSD variant have been the base? XKCD’s “Dependency” is a visualisation of the complex web of interrelated, necessary, free-to-use software that supports our modern world. ——— Diomidis Spinellis took the TUHS archives and gave us the Continuous Unix History Repository from 1970… A brilliant exposition of capability & source code history. ——— The SCO lawsuit, 20 years later 2021 Magazines like Forbes were warning the "Linux-loving crunchies in the open-source movement” that they "should wake up”. SCO was suggesting a license fee of $1,399 - per-CPU - to run Linux. [ in 2001 ] SCO managed to prove the cleanliness of the (linux) kernel's pedigree in a far more convincing way than anybody else could have. Nobody now questions the legitimacy of the kernel's source code. Many other projects have adopted similar procedures (to Linux’s 'certificate of origin’), most of which have the happy result of documenting the provenance of code without imposing heavy bureaucracy on the process. [ github publicly proves provenance ] It was not just IBM's lawyers and money that won this fight; it was a widespread community that had built something special and had no intention of letting a failing company steal it. ——— -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From tuhs at tuhs.org Sat Apr 18 12:13:43 2026 From: tuhs at tuhs.org (Wesley Parish via TUHS) Date: Sat, 18 Apr 2026 14:13:43 +1200 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: <78C5364B-9A6A-4A00-B414-5E899EDC3185@canb.auug.org.au> References: <78C5364B-9A6A-4A00-B414-5E899EDC3185@canb.auug.org.au> Message-ID: <3dc4ca59-d89e-4260-ada1-a4753d03be56@gmail.com> Amen to that! Without a community who weren't willing to let allegations mislead others, who were willing to dig through the Unix history and share their findings, things would've been different - and much worse. Wesley Parish On 18/04/2026 13:59, steve jenkin via TUHS wrote: > > >> On 18 Apr 2026, at 10:17, Warren Toomey via TUHS wrote: >> >> So that's where we are. I hope you've been happy with the TUHS work >> over the past 30 years, and I'm keen to see it continue indefinitely :-) >> >> Cheers, Warren > It’s worth remembering the future we could’ve had if SCO had won. > > We are very lucky to have had leaders and communities around them > that prevented this, including this one. > > Not just no ‘Historical Unix’, no TUHS, but no Free Linux > and a much reduced Open Source Software movement as a result. > > Which would’ve squeezed Apache, MySQL and the post-PERL languages. > > Including no ‘Git’ and ‘github’. > > The Web as we know it, could never have developed. > > No Linux, No Android? > or could a BSD variant have been the base? > > XKCD’s “Dependency” is a visualisation of the complex web of interrelated, > necessary, free-to-use software that supports our modern world. > > > > ——— > > Diomidis Spinellis took the TUHS archives and gave us > the Continuous Unix History Repository from 1970… > > A brilliant exposition of capability & source code history. > > > ——— > > The SCO lawsuit, 20 years later > 2021 > > > Magazines like Forbes were warning the > "Linux-loving crunchies in the open-source movement” > that they "should wake up”. > > SCO was suggesting a license fee of $1,399 - per-CPU - to run Linux. [ in 2001 ] > > SCO managed to prove the cleanliness of the (linux) kernel's pedigree in a far more convincing way > than anybody else could have. > Nobody now questions the legitimacy of the kernel's source code. > > Many other projects have adopted similar procedures (to Linux’s 'certificate of origin’), > most of which have the happy result of documenting the provenance of code > without imposing heavy bureaucracy on the process. [ github publicly proves provenance ] > > It was not just IBM's lawyers and money that won this fight; > it was a widespread community that had built something special > and had no intention of letting a failing company steal it. > > ——— > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin > From tuhs at tuhs.org Sat Apr 18 14:24:10 2026 From: tuhs at tuhs.org (Vicente Collares via TUHS) Date: Sat, 18 Apr 2026 00:24:10 -0400 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: <920be2f4-9f6e-4ed0-86f5-45988e44fc43@collares.ca> Warren, thank you very much for running this mailing list for this long! The quality of the discussions, the interesting people, and your stewardship make it an excellent community. May it flourish and continue to exist as long as there's people interested in Unix. Cheers, Vicente. From tuhs at tuhs.org Sat Apr 18 14:27:45 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 17 Apr 2026 22:27:45 -0600 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: On Fri, Apr 17, 2026 at 7:38 PM John Cowan via TUHS wrote: > On Fri, Apr 17, 2026 at 8:17 PM Warren Toomey via TUHS > wrote: > > > Once we hit the yearly target, I'll turn off further contributions: > > I am only after enough to keep the server up and running. > > I recommend against that. You should allow people to pay in advance, > especially as so many of us have fluctuating incomes nowadays. If you > get five years' worth of support right away, good: you or your > successors won't need to run more campaigns for a while. > So I think there needs to be a balance here. We want to have enough money to pay for maintenance of the archive. We need there to be some flexibility in terms of how much we're paying, since our needs may change, especially if unexpected artifacts come to light where we need more storage, rates go up, etc. Yet we don't want to have too much money, which attracts the wrong kinds of attention. We want to have enough reserves to weather lean times, as interest in Unix history waxes and wanes. So if we're so fortunate enough to raise our goal, maybe we keep it on until we have 6 months reserve so we can some buffer should fundraising not pick up quickly next year. Or maybe we encourage many people to give $5 or $10 a month instead so we have $100ish coming in each month and fundraise when we run short. I think that would still be in line with the goals of not raising too much, but also ensuring that we're able to keep the lights on. Warner From tuhs at tuhs.org Sat Apr 18 14:34:02 2026 From: tuhs at tuhs.org (Al Kossow via TUHS) Date: Fri, 17 Apr 2026 21:34:02 -0700 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: <22063a15-4a8c-337b-5347-a7d980e07fde@bitsavers.org> >>> Once we hit the yearly target, I'll turn off further contributions: >>> I am only after enough to keep the server up and running. There should be international mirrors of the content. From tuhs at tuhs.org Sat Apr 18 14:49:23 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Fri, 17 Apr 2026 22:49:23 -0600 Subject: [TUHS] the device tree, hardware, and kernels. In-Reply-To: <6F578299-2A93-49C6-8C39-9F714705C2A3@eschatologist.net> References: <6F578299-2A93-49C6-8C39-9F714705C2A3@eschatologist.net> Message-ID: On Mon, Apr 13, 2026 at 10:26 PM Chris Hanson via TUHS wrote: > On Apr 6, 2026, at 4:12 PM, segaloco via TUHS wrote: > > > > DTB to me is better than having to go twiddling baked in kernel > addresses at build time, then you really do need a kernel-per-machine > rather than being able to spin a "defconfig" kernel that'll hopefully at > least give you serial TTY on whatever you're messing with. > > This is the main reason I think someone is working on improving device > tree adoption in NetBSD; availability of community and vendor device trees > could reduce the number of more specialized kernel builds needed, and > reduce the requirement to do a full port to support new hardware. > Yes. FreeBSD has been doing the same thing for a long time. Years ago, we switched to primarily using DTS for ARM systems, while also including ACPI support so we could get system information from either or both. DTS are, in theory, a pure description of the hardware that any OS can implement. Sadly, the reality has fallen short of this ideal in many areas of the DTS world. Often times, the DTS and the Linux driver co-evolve (and change year by year), which makes it hard to keep up. It also tends to enforce a policy of updating everything (at least within an arch) at once (it's just easier that way). However, this approach causes churn and reduces longevity. For example, parts of our TI ARMv7 support were broken for years before we removed them, and bringing the other parts back up to standard required many hours. Overall, it's been great, but it hasn't been without cost. Though armv7 supporters in FreeBSD have also been thinning out too. Warner From tuhs at tuhs.org Sat Apr 18 17:59:47 2026 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Sat, 18 Apr 2026 07:59:47 +0000 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: <2r7ZxQZxywhmFoXxdiluOOh3Iidby1rW4ghS-GqKWXJxBVGv6FRg8RflajxoD_8vo5wHuoncAF8A4ibr1lJpJKrMROMKWd4Scn5wam6rDWw=@protonmail.ch> Hi Warren, Happy to be here and happy to pay! Someone suggested smaller monthly payments and I guess maybe that might not work with GoFundMe but I'd be happy to pay up to AU$10 every month. I do have PayPal and Wise so could pay either into a PayPal account or into a bank account, every four weeks when I get paid. Either way I see the GoFundMe page is locked right now but I definitely want to... $ support -TUHS Have a great weekend! Cameron -------- Original Message -------- On Saturday, 04/18/26 at 01:17 Warren Toomey via TUHS wrote: Hi all, I'm going to turn 60 in May and I've been running (and paying for) the TUHS server since I was about 30 :-) I've also retired from work and now live a life full of horse-related activities -- my wife rides, I'm just the ground crew and pooh collector. Hitting 60 has made me realise that we need to have some form of succession plan for TUHS for when I'm no longer able to keep maintaining the system. To that end, over the past year I've picked a few of the people on the TUHS list to help with the general management of the server, Minnie. The "TUHS team" are: Clem Cole, Dan Cross, David Arnold, Greg Lehey, Kevin Bowling, Larry McVoy, Matt G, Thalia Archibald, Warner Losh and Will Senn The TUHS team also forms the basis of the succession plan: they have the authority to make changes on the TUHS server, based on consensus within the team. And, if/when I'm not able to keep doing things, the TUHS team will continue with the care and feeding of Minnie. Also, now that I no longer have a salary, I've decided that it's time to allow others to help out with the yearly funding of the TUHS server. It's about US$1000 for the Linode plan that we are using. So, after 30 years, I'm finally announcing this GoFundMe plan for the TUHS service: https://gofund.me/7cc603ea3 Once we hit the yearly target, I'll turn off further contributions: I am only after enough to keep the server up and running. So that's where we are. I hope you've been happy with the TUHS work over the past 30 years, and I'm keen to see it continue indefinitely :-) Cheers, Warren From tuhs at tuhs.org Sat Apr 18 19:46:03 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sat, 18 Apr 2026 19:46:03 +1000 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: On Sat, Apr 18, 2026 at 10:17:29AM +1000, Warren Toomey via TUHS wrote: > I'm finally announcing this GoFundMe plan for the TUHS service: > Once we hit the yearly target, I'll turn off further contributions: > I am only after enough to keep the server up and running. Well, it didn't take long to hit the target, and I left it open until we reached twice the amount that we need for a year: that will give us some buffer in case the costs rise and/or we want to increase the size of the VM disk space etc. A few people have e-mailed saying that they missed out contributing to the cause: I will try to make some arrangements for them. A few people dug very deeply into their pockets with their donations, and I wasn't expecting that. Thank you all so very much for the contributions that you all made, regardless of the amount. Finally, I just want to say that I didn't desperately need the funds to keep TUHS going; I am able to keep paying myself if I had to. But I wanted to signal to you all (and myself, actually) that TUHS isn't just _my_ thing, it is really _your_ thing and you all need the opportunity to keep it going and improve it. Thanks again! I'm not going anywhere, but I'm no longer the benevolent "dictator". Now I'm one of the people, along with you, who are helping to keep TUHS going. Cheers, Warren From tuhs at tuhs.org Sat Apr 18 19:46:56 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sat, 18 Apr 2026 19:46:56 +1000 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: <22063a15-4a8c-337b-5347-a7d980e07fde@bitsavers.org> References: <22063a15-4a8c-337b-5347-a7d980e07fde@bitsavers.org> Message-ID: On Fri, Apr 17, 2026 at 09:34:02PM -0700, Al Kossow via TUHS wrote: > There should be international mirrors of the content. Absolutely! Here's the list of them: https://wiki.tuhs.org/doku.php?id=source:unix_archive Cheers, Warren From tuhs at tuhs.org Sat Apr 18 19:58:05 2026 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Sat, 18 Apr 2026 11:58:05 +0200 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: <42833F9E-52B4-4298-812E-479D3A01FFBF@alchemistowl.org> On 18 Apr 2026, at 11:47, Warren Toomey via TUHS wrote: > > On Fri, Apr 17, 2026 at 09:34:02PM -0700, Al Kossow via TUHS wrote: >> There should be international mirrors of the content. > > Absolutely! Here's the list of them: > > https://wiki.tuhs.org/doku.php?id=source:unix_archive Hello from unix-archive.eu! Please note that I only mirror weekly and, right now, my main problem are the AI scrapers which take my bandwidth usage and CPU load through the roof… I wish I had a good solution to that: they continue downloading the same file over and over again, at 1s intervals from multiple IPs, no concept of “has this file changed?” at all, just download repeatedly. Have started blocking IPs at the firewall but, as you all know, that is a losing battle… Before someone suggests it: no, Cloudflare is not a solution, the centralisation of the Internet is a huge problem, not a solution. Cheers, Arrigo From tuhs at tuhs.org Sat Apr 18 20:07:15 2026 From: tuhs at tuhs.org (Maurizio Boriani via TUHS) Date: Sat, 18 Apr 2026 12:07:15 +0200 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: On Sat, Apr 18, 2026 at 10:17:29AM +1000, Warren Toomey via TUHS wrote: > Hi all, I'm going to turn 60 in May and I've been running (and paying for) > the TUHS server since I was about 30 :-) simply thank you for all what you had done > I've also retired from work and now live a life full of horse-related > activities -- my wife rides, I'm just the ground crew and pooh collector. enjoy your retire :-) live long and prosper -- Maurizio Boriani ssh-rsa: SHA256:t96eIBaOZqROKZ63rQTkvu4IBH8dD+QKjiuhSejTyE4 From tuhs at tuhs.org Sat Apr 18 21:01:39 2026 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Sat, 18 Apr 2026 07:01:39 -0400 (EDT) Subject: [TUHS] TUHS: Maintenance, Succession and Funding Message-ID: <20260418110139.E42BA18C074@mercury.lcs.mit.edu> > From: Al Kossow > There should be international mirrors of the content. "International" is a minor optimization; "mirror" ('replication', i.e. copies) is the key concept. There was a complete copy of all 40 volumes of Diodorus Siculus' magisterial universal history, Bibliotheca Historica: https://en.wikipedia.org/wiki/Bibliotheca_historica written between 60 and 30 BC, in a library in Constantinople - until 1453. (In 1453, Constantinople was sacked.) We now only have about 15 volumes, from about 3 partial copies made before that date, and preserved in libraries in the West (more here: https://www.tertullian.org/rpearse/manuscripts/diodorus_sicilus.htm for anyone other than me who is interested in such things.) In other words, it survived for 1500 years - and was only then lost, because there weren't enough copies. (Other Greek and Roman works survived because there ha been more interest in them, and multiple copies had made their way to libraries in the West.) I suspect things other than sackings (as a Constantinople) are the biggest threat in this age. Much of the early work on internet technologies, and the early Internet, was conducted via email, through a list hosted (I believe) at CNRI. I suspect the archive of that list has been lost, because (I assume) during a switch from one generation of machines, to the next, someone decided it was not worth - or necessary to - keeping it. (If they thought about it at all.) If it is indeed lost, historians of the future are gnashing their teeth. Noel From tuhs at tuhs.org Sat Apr 18 21:42:11 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Sat, 18 Apr 2026 11:42:11 +0000 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: <20260418110139.E42BA18C074@mercury.lcs.mit.edu> (Noel Chiappa via TUHS's message of "Sat, 18 Apr 2026 07:01:39 -0400 (EDT)") References: <20260418110139.E42BA18C074@mercury.lcs.mit.edu> Message-ID: <7w1pgctrzg.fsf@junk.nocrew.org> Noel Chiappa wrote: > > There should be international mirrors of the content. > "International" is a minor optimization; "mirror" is the key concept. I think it's more than a optimization. It's risky to have all copies in a single jurisdiction. > If it is indeed lost, historians of the future are gnashing their teeth. I'm already gnashing plenty. From tuhs at tuhs.org Sat Apr 18 23:59:36 2026 From: tuhs at tuhs.org (John Cowan via TUHS) Date: Sat, 18 Apr 2026 09:59:36 -0400 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: <7w1pgctrzg.fsf@junk.nocrew.org> References: <20260418110139.E42BA18C074@mercury.lcs.mit.edu> <7w1pgctrzg.fsf@junk.nocrew.org> Message-ID: On Sat, Apr 18, 2026 at 7:42 AM Lars Brinkhoff via TUHS wrote: > I think it's more than a optimization. It's risky to have all copies in > a single jurisdiction. Agreed, and for at least three different reasons: 1) At any time, a regime may decide to cut off foreign access to information hosted in their jurisdiction. 2) At any time, a regime may decide to forbid or even criminalize the possession of that information within its boundaries. 3) At any time, war or civil unrest may destroy that information. From tuhs at tuhs.org Sun Apr 19 00:25:02 2026 From: tuhs at tuhs.org (steve jenkin via TUHS) Date: Sun, 19 Apr 2026 00:25:02 +1000 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: <2378D5A0-FF71-4F25-88B3-95C978B0BB95@canb.auug.org.au> > On 18 Apr 2026, at 19:46, Warren Toomey via TUHS wrote: > > Thanks again! I'm not going anywhere, but I'm no longer the benevolent > "dictator". Now I'm one of the people, along with you, who are helping to > keep TUHS going. > > Cheers, Warren Regular holidays & travel, now you’ve a moderation team :) -- From tuhs at tuhs.org Sun Apr 19 00:41:45 2026 From: tuhs at tuhs.org (Jay Logue via TUHS) Date: Sat, 18 Apr 2026 07:41:45 -0700 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: Message-ID: <2c18bf6a-f7b3-493f-92f2-89473d2f04ca@toaster.com> On 4/18/26 02:46, Warren Toomey via TUHS wrote: > Well, it didn't take long to hit the target, and I left it open until > we reached twice the amount that we need for a year: that will give us > some buffer in case the costs rise and/or we want to increase the size > of the VM disk space etc. Glad to hear this.  I missed the opportunity to contribute, but I stand ready when you need more. Given the apparent appetite for contributing, maybe some thought should be given to channeling a portion of that towards the mirrors?  Not sure the best way to go about this; perhaps its just encouraging them to setup their own funding efforts (to which I would gladly contribute).  But has people have observed elsewhere, I think the mirrors are an important part of ensuring access to Unix history. Thank you for all that you do, Warren. --Jay From tuhs at tuhs.org Sun Apr 19 00:58:45 2026 From: tuhs at tuhs.org (Johan Helsingius via TUHS) Date: Sat, 18 Apr 2026 16:58:45 +0200 Subject: [TUHS] TUHS: Maintenance, Succession and Funding In-Reply-To: References: <20260418110139.E42BA18C074@mercury.lcs.mit.edu> <7w1pgctrzg.fsf@junk.nocrew.org> Message-ID: On 18/04/2026 3:59 pm, John Cowan via TUHS wrote: > 1) At any time, a regime may decide to cut off foreign access to > information hosted in their jurisdiction. > > 2) At any time, a regime may decide to forbid or even criminalize the > possession of that information within its boundaries. > > 3) At any time, war or civil unrest may destroy that information. 1) and 2) will probably lead to 3) anyway. Julf