The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Attempting To Build NOSC and BBN UNIXs + ARPANET code
@ 2022-10-10 18:33 Michael Casadevall
  2022-10-10 19:48 ` [TUHS] " Lars Brinkhoff
  2022-10-10 20:31 ` Clem Cole
  0 siblings, 2 replies; 19+ messages in thread
From: Michael Casadevall @ 2022-10-10 18:33 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 4084 bytes --]

Hey all,
I've been recently working on researching ARPANET and the like for use in
an upcoming video. As a starting point, I've been looking at the early UNIX
networking code in archives, specifically, the NOSC tarball, and I've spent
quite a few hours trying to get building on livestreams.

What I've found is that there's corruption issues in code; which is noted
in JOHNS-NOTE, although it's more severe than I realized. For example
sys4.c is entirely corrupted, and part of impio.c is cut off. However, this
isn’t quite as bad as it sounds. For example, by kitbashing both the
original v6 source code, and the later BBN TCP code, I was able to create a
sys4.c that builds and links which should be close to the original.
Furthermore, it is possible to use the “vdh” target instead of the imp
target to at least try and get the code building. I did successfully get a
kernel to build, and it even prints out a mem message before deadlocking.

My guess is it's either deadlocked waiting for the IMP, or there’s
something wrong with the build. There’s some indication that it might need
a split kernel, although I’ve not had any success with that thus far. I
have uploaded my current build tree to git, as well as tarball with simh
images if anyone wants to try and figure out what has gone wrong. I admit,
my knowledge of PDP-11 assembly and debugging platforms is a bit wanting :)

There’s some indication that this, and the later BBN TCP (which is from
around the same time period) code were built on top of the Programmer’s
Workbench vs. stock v6; especially because some code patches were needed to
get it to build. I did look at the TUHS PWB archives, I see a bunch of
binaries, but absolutely no idea how to install them. I’ve heard that none
of these archives are actually complete, but I'm hoping someone might have
some idea of how to go forward, since, if nothing else, I’d like to end
this with a success story, although I’m happy with as far as I got.

Furthermore, I do know that I can run some of the ARPA level utilities in
MIT ITS on CHAOSNET, which will be an upcoming project, although that is
going to be a dive in and of itself.

In short, I’m hoping someone might be able to provide some insight into
where things have gone wrong:
  * Is the netunix kernel I built hanging because of corrupted code, or is
it waiting for non-existent hardware.
* NOTE: The DC-11 driver was not included, but I don’t think I need that
for a single console?
  * Is there any versions of PWB that is “easily” installable, since its
very clear the later BBN code requires it (it refers to ncc explicitly)?
  * I know IMPs have been emulated, and even have successfully routed
packets, so I’m also trying to figure out how much would still be necessary
to actually recreate a minimal ARPA network?

I did try to build some of the NCP applications regardless; it does appear
that some parts are simply missing. Mailer.cc seems to want a hnconv.o but
no source file exists. The FTP daemon on the other hand wants a library
simply called “j”.

My guess is that even if the NCP code was buildable, the applications might
not be. However, this did make me take a closer look at the BBN code, and
it does have an ifdef for NCP, suggesting that it was still
usable/supported? It makes sense, it seems to have been written before the
TCP/IP flag day. I’m just not sure where to approach compiling it.

I’ve uploaded the code with patches to build with the v6 compiler to github
here: https://github.com/NCommander/network-unix-v6/tree/attempted-repair

NOTE: v6's cc needs a seperate patch to increase the symbol table size;
that's done in the disk image.

Files, with SIMH configuration available here:
https://drive.google.com/file/d/1QS0B3RU_mwXSGtl2En-d0WI3PJ1-udEs/view?usp=sharing

My livestreams (12 hours or so) are on my YouTube channel:
https://youtube.com/c/NCommander

Feel free to forward this to other lists that may have PDP-11 or ARPANET
experts!
~ NCommander

[-- Attachment #2: Type: text/html, Size: 4414 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-10 18:33 [TUHS] Attempting To Build NOSC and BBN UNIXs + ARPANET code Michael Casadevall
@ 2022-10-10 19:48 ` Lars Brinkhoff
  2022-10-10 20:31   ` Michael Casadevall
  2022-10-10 20:31 ` Clem Cole
  1 sibling, 1 reply; 19+ messages in thread
From: Lars Brinkhoff @ 2022-10-10 19:48 UTC (permalink / raw)
  To: Michael Casadevall; +Cc: tuhs

Michael Casadevall wrote:
> part of impio.c is cut off. However, this isn’t quite as bad as it
> sounds. For example, by kitbashing both the original v6 source code,
> and the later BBN TCP code, I was able to create a sys4.c that builds
> and links which should be close to the original. Furthermore, it is
> possible to use the “vdh” target instead of the imp target to at least
> try and get the code building.

Too bad about impio.c!  Maybe something can be extracted from the
unix.greg binary?  I see there's also the ACC interface, another
alternative to IMP11A.

> My guess is it's either deadlocked waiting for the IMP, or there’s
> something wrong with the build.

Since you don't have anything backing the hardware registers for the IMP
interface, it seems likely something will be upset.

> Furthermore, I do know that I can run some of the ARPA level utilities
> in MIT ITS on CHAOSNET, which will be an upcoming project, although
> that is going to be a dive in and of itself.

It's complicated.  Many of the utilities have parallels between the two,
and some work on both.  And there's a server to provide a gateway from
Chaosnet to Arpanet.  Give me a ping when you're looking into ITS.

> I know IMPs have been emulated, and even have successfully routed
> packets, so I’m also trying to figure out how much would still be
> necessary to actually recreate a minimal ARPA network?

Reviving the host software, like you are are doing, is one vital part of
it.  Another it adding emulators for various IMP interfaces.  I.e. you
will not get anywhere without adding one of IMP11A, ACC, or VDH to SIMH.

For adding other nodes to the network, PDP-10 hosts are your best bet.
There isn't much else left.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-10 19:48 ` [TUHS] " Lars Brinkhoff
@ 2022-10-10 20:31   ` Michael Casadevall
  2022-10-11  5:31     ` Lars Brinkhoff
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Casadevall @ 2022-10-10 20:31 UTC (permalink / raw)
  To: Lars Brinkhoff; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 3643 bytes --]

Replies inline

On Mon, Oct 10, 2022 at 3:48 PM Lars Brinkhoff <lars@nocrew.org> wrote:

> Michael Casadevall wrote:
> > part of impio.c is cut off. However, this isn’t quite as bad as it
> > sounds. For example, by kitbashing both the original v6 source code,
> > and the later BBN TCP code, I was able to create a sys4.c that builds
> > and links which should be close to the original. Furthermore, it is
> > possible to use the “vdh” target instead of the imp target to at least
> > try and get the code building.
>
> Too bad about impio.c!  Maybe something can be extracted from the
> unix.greg binary?  I see there's also the ACC interface, another
> alternative to IMP11A.
>
>
Well, there is an impio.c in the BBN TCP code which has #define NCPs, which
I used to rebuild the original impio.c; although this is very much a devil
in the
details situation.

I do need to do a readthrough for the VDH driver, which says its for "very
distant hosts".
I think that might be for the radio links to Hawaii and the UK? I vaguely
remember coming
across that term in my reading, but I'm drawing a blank ATM.

I did try to run the unix binaries in green and green47, but they seem to
be configured
for a RL0x drive of some sort; the driver is in the NOSC source, so it
might be possible
to get running, but without the host binaries, you'r enot going to get far.

> My guess is it's either deadlocked waiting for the IMP, or there’s
> > something wrong with the build.
>
> Since you don't have anything backing the hardware registers for the IMP
> interface, it seems likely something will be upset.
>
>
Well, I'm not sure if its trying to initialize the IMP on startup; there's
a userspace daemon,
ncpd which talks to the /dev nodes to do stuff; with network nodes showing
up as /dev/net/*host.

I did determine I at least seem to make it to sched() with my home cooked
kernel, but I can't even
start in single user mode.

Honestly, it reminds me of Plan 9 more than anything.


> > Furthermore, I do know that I can run some of the ARPA level utilities
> > in MIT ITS on CHAOSNET, which will be an upcoming project, although
> > that is going to be a dive in and of itself.
>
> It's complicated.  Many of the utilities have parallels between the two,
> and some work on both.  And there's a server to provide a gateway from
> Chaosnet to Arpanet.  Give me a ping when you're looking into ITS.
>
>
Will do. ITS feels like an extremely deep (if interesting) rabbithole :)


> > I know IMPs have been emulated, and even have successfully routed
> > packets, so I’m also trying to figure out how much would still be
> > necessary to actually recreate a minimal ARPA network?
>
> Reviving the host software, like you are are doing, is one vital part of
> it.  Another it adding emulators for various IMP interfaces.  I.e. you
> will not get anywhere without adding one of IMP11A, ACC, or VDH to SIMH.
>
>
Yup, that's what I figured. I've been trying to evaluate how much survives
here, but
my general feeling is one of the UNIX stacks might be recoverable, plus the
ARPA
stuff in ITS. I don't know if a runnable build of TENEX has been archived,
or if ARPA
stuff for TOPS-10/20 survived.

I also want to look into System/360 and 370, but I get the sense none of
the mainframe stuff survived.

The other problem is of the surviving stacks, they all seem to be for the
later 96-bit leader,
I'm not certain if any of the IMP software that has been archived is new
enough to work with that.

That said, that isn't an insurmountable problem.
~ NCommander

[-- Attachment #2: Type: text/html, Size: 4842 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-10 18:33 [TUHS] Attempting To Build NOSC and BBN UNIXs + ARPANET code Michael Casadevall
  2022-10-10 19:48 ` [TUHS] " Lars Brinkhoff
@ 2022-10-10 20:31 ` Clem Cole
  2022-10-10 20:48   ` Michael Casadevall
  1 sibling, 1 reply; 19+ messages in thread
From: Clem Cole @ 2022-10-10 20:31 UTC (permalink / raw)
  To: Michael Casadevall; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 2677 bytes --]

below...


On Mon, Oct 10, 2022 at 2:33 PM Michael Casadevall <michael@casadevall.pro>
wrote:

>  For example sys4.c is entirely corrupted, and part of impio.c is cut off.
>
Hmmm

 % sha256sum impio.c sys4.c
1f3d10a7e6989996dae8a07992684881fa8bc05ddc5d512c86efdaf34b4437d2  impio.c
7bd82c560d7bd74f64b03dac10550620b70d88340f02e31b56c6002f2ae6c88d  sys4.c

This is from my system - check to see if what you have are different




>
> There’s some indication that this, and the later BBN TCP (which is from
> around the same time period) code were built on top of the Programmer’s
> Workbench vs. stock v6;
>
Where did you see that?  Possible of course, but less likely.   PWB 1.0 was
not released outside of BTL.  Parts leaked to some of the Universities and
the MIT systems were famously PWBish, so it's possible it leaked from MIT
to BBN.  AGN is the comments -- Al Nemeth who is a friend of mine and Al
told me in those days, BBN was pretty spooked about where UNIX stuff came
from at BBN.

I think it's more likely if something is not stock V6, is using the
typesetter C compiler - which is the compiler described in K&R1 and would
later be part of V7 and PWB 2.0.  That was released independently a lot of
places had it and if you upgraded your V6 system to it, it was hard to go
backward.



>
> In short, I’m hoping someone might be able to provide some insight into
> where things have gone wrong:
>   * Is the netunix kernel I built hanging because of corrupted code, or is
> it waiting for non-existent hardware.
>
Could not a ton of things - where is stopping -- use simh to get an address
and then check then look UNIX symbol table and see what routine you are in
and see if you can egt a hint.

> * NOTE: The DC-11 driver was not included, but I don’t think I need that
> for a single console?
>
Should not need it - you can make sure /dev entry is nuked for it.   check
c.c and see what entry it was -- it should be commented it.   The look in
/dev and rm the entry so you don's accidentially try to open


>   * Is there any versions of PWB that is “easily” installable, since its
> very clear the later BBN code requires it (it refers to ncc explicitly)?
>
See comments -- I'm thinking this might not be PWB -- but if it is then go
to gunkies and get Noel's MIT system maybe.



>  NOTE: v6's cc needs a seperate patch to increase the symbol table size;
> that's done in the disk image.
>
Yep - done many times - also if you use a 45 or 70, make the compiler image
split I/D that helps too.   Although we ran them on 40s all the time - even
before Fred's overlay code.
ᐧ
ᐧ

[-- Attachment #2: Type: text/html, Size: 6317 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-10 20:31 ` Clem Cole
@ 2022-10-10 20:48   ` Michael Casadevall
  2022-10-10 21:37     ` Clem Cole
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Casadevall @ 2022-10-10 20:48 UTC (permalink / raw)
  To: Clem Cole; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 4405 bytes --]

Replies inline

On Mon, Oct 10, 2022 at 4:31 PM Clem Cole <clemc@ccc.com> wrote:

> below...
>
>
> On Mon, Oct 10, 2022 at 2:33 PM Michael Casadevall <michael@casadevall.pro>
> wrote:
>
>>  For example sys4.c is entirely corrupted, and part of impio.c is cut
>> off.
>>
> Hmmm
>
>  % sha256sum impio.c sys4.c
> 1f3d10a7e6989996dae8a07992684881fa8bc05ddc5d512c86efdaf34b4437d2  impio.c
> 7bd82c560d7bd74f64b03dac10550620b70d88340f02e31b56c6002f2ae6c88d  sys4.c
>
> This is from my system - check to see if what you have are different
>
>
From the NOSC tarball from THUS:

 % sha256sum ncpk/drivers/impio.c ken/sys4.c
ace2b7dae48bacf86b3bf1260a7715b66264308d67eb3232d963794481910c6a
 ncpk/drivers/impio.c
e5e727139e10b476c4dfa534155ddc07c0b3d32f132c98939c58d24f9a5efc41  ken/sys4.c

sys4.c is just garbage characters, impio.c stops in the middle of a
function.

There's also some corruption (mostly single bytes stuff) in other files,
i.e., I had to edit some non ASCII characters out because cc was unhappy,
so if a redump is possible, it would be good.


>
>>
>> There’s some indication that this, and the later BBN TCP (which is from
>> around the same time period) code were built on top of the Programmer’s
>> Workbench vs. stock v6;
>>
> Where did you see that?  Possible of course, but less likely.   PWB 1.0
> was not released outside of BTL.  Parts leaked to some of the Universities
> and the MIT systems were famously PWBish, so it's possible it leaked from
> MIT to BBN.  AGN is the comments -- Al Nemeth who is a friend of mine and
> Al told me in those days, BBN was pretty spooked about where UNIX stuff
> came from at BBN.
>
> I think it's more likely if something is not stock V6, is using the
> typesetter C compiler - which is the compiler described in K&R1 and would
> later be part of V7 and PWB 2.0.  That was released independently a lot of
> places had it and if you upgraded your V6 system to it, it was hard to go
> backward.
>
>
There are SCCS references in the code from 78/79, references to the V7 CC
compiler and updates. SCCS was introduced publicly with PWB, which is why I
suspect it might have been used. The code also uses some C syntax the stock
compiler dislikes (specifically, it was unhappy register in the function
declaration). The documentation discusses updating the C supervisor, and
also using the Yale shell included in the source before trying to build.

I know there's an updated cc that was on some of the disk dumps of later v6
systems, which might also be where things like "libg", and such are.
There's a few .a bundles that there are binaries but no sources in the
archive, but I didn't make a comprehensive list on it.

>
>
>>
>> In short, I’m hoping someone might be able to provide some insight into
>> where things have gone wrong:
>>   * Is the netunix kernel I built hanging because of corrupted code, or
>> is it waiting for non-existent hardware.
>>
> Could not a ton of things - where is stopping -- use simh to get an
> address and then check then look UNIX symbol table and see what routine you
> are in and see if you can egt a hint.
>

I'll check this next time I get the system out. I did follow the code a
fair bit, and it looks like I do at least get as far as sched() since mem =
is posted, and *then* it falls over.

* NOTE: The DC-11 driver was not included, but I don’t think I need that
>> for a single console?
>>
> Should not need it - you can make sure /dev entry is nuked for it.   check
> c.c and see what entry it was -- it should be commented it.   The look in
> /dev and rm the entry so you don's accidentially try to open
>

Awesome, thanks. That's what I suspected, but that's what I thought.


>
>
>>  NOTE: v6's cc needs a seperate patch to increase the symbol table size;
>> that's done in the disk image.
>>
> Yep - done many times - also if you use a 45 or 70, make the compiler
> image split I/D that helps too.   Although we ran them on 40s all the
> time - even before Fred's overlay code.
> ᐧ
>

Beside the startup code (which is in mch.c and uses a preprocessor macro),
is there anything specific gotchas in regards to models? I tried building
CPU40 and CPU70, and configuring simh, just to eliminate that gotcha, but
the only difference seems to be early initialization code ...

Michael

[-- Attachment #2: Type: text/html, Size: 8801 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-10 20:48   ` Michael Casadevall
@ 2022-10-10 21:37     ` Clem Cole
  0 siblings, 0 replies; 19+ messages in thread
From: Clem Cole @ 2022-10-10 21:37 UTC (permalink / raw)
  To: Michael Casadevall; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 3270 bytes --]

On Mon, Oct 10, 2022 at 4:49 PM Michael Casadevall <michael@casadevall.pro>
wrote:

>
> There are SCCS references in the code from 78/79, references to the V7 CC
> compiler and updates.
>
The 'V7 compiler' is 'Typesetter C' - it was released two compiler DWB on
V6.

SCCS had a interesting life.


> SCCS was introduced publicly with PWB,
>
Indeed.



> which is why I suspect it might have been used.
>
It might have been at MIT (it was a UCB and CMU BTW) - but I believe Al
Nemeth  - while it might have been a person disk, -- I'm pretty sure BBN
would have tried to kept those bits out of the building. - certainly out of
the mainstream of any project -- you see in the directories foo.c and
foo.c~ files -- this was typical of the day.  If you were using SCCS less
you would see a lot more evidence in the trees (again look at the UCB trees
- you can see once Ken brought it to UCB, wnj started to use it).




> The code also uses some C syntax the stock compiler dislikes
> (specifically, it was unhappy register in the function declaration).
>
As I said -- I suspect the typesetter compiler by then.  If userspace code
is using <stdio.h> and linking libS.a not Mike Lesk's portable I/O
library that's a huge clue also BTW.  But Dennis did a lot of work to the
compiler in the DWB timeframe.  A number of language features were added,
he changed the syntax of things like =+ to += and the like.   This is why
code that targets the Typesetter C compiler has a very difficult time going
back to the V6 (or basic PWB 1.0) compilers.   As I said in the other
message, this was the compiler he and Brian describe in the book - also
note a couple of us here reviewed different editions of it.

I suspect what you need is the original DWB 1.0 release that includes the
'typesetter' compiler -- that will bootstrap on a V6 system and will create
a v6 compiler.  I'm not sure we have that in the archives.  I think we have
the later PWB 2.0 release - that comes without the compiler.

Beside the startup code (which is in mch.c and uses a preprocessor macro),
> is there anything specific gotchas in regards to models? I tried building
> CPU40 and CPU70, and configuring simh, just to eliminate that gotcha, but
> the only difference seems to be early initialization code ...
>
Quick glance is that BBN was running a 45 - so I'd build for that to
start.   45s and 70s's are more similar but not exactly the same.  Don't
build for a 40. They are quite different.
Set simh up as a 45 and see if that just works.

If not .... then I would drop back and pull everything out to as simple a
UNIX as possible...  since it's a v6 system without any of the networking
-- as much line Ken and Dennis as you can.  Configure that a 40 and follow
Dennis's and Ken's instructions (which for v6 is a a 40) -- get that to
boot and a simh based 40.    Then reconfigure as a simh based 45 and make
that work.  Then and only then turn on the BBN stuff.

Feel free to send me email off line and I can try to help a little.  Note:
I have not played with a 45 in years. But I ran V5, V6. and V7 on 40s, 45
and 70s back in the day.  I have a PiDP 11/70 behind me so modulo being way
to busy, I can try to help a little.
ᐧ

[-- Attachment #2: Type: text/html, Size: 6598 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-10 20:31   ` Michael Casadevall
@ 2022-10-11  5:31     ` Lars Brinkhoff
  2022-10-11 12:57       ` Michael Casadevall
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Brinkhoff @ 2022-10-11  5:31 UTC (permalink / raw)
  To: Michael Casadevall; +Cc: tuhs

TUHS Disclaimer: I will claim this is primarily about getting Unix onto
the Arpanet, but it does also contain trace amounts of off-topic
information.  Reader discretion is adviced.

Michael Casadevall wrote:
> I do need to do a readthrough for the VDH driver, which says its for
> "very distant hosts".  I think that might be for the radio links

The hardware interfaces between a host and an IMP came in three flavors:
local host, distant host, and very distant host.  The first two are more
or less directly connected and I forget what the difference is.  But a
very distant host is basically connected over a phone line with a modem
at each end, so it's a different beast.  The VHD driver would be for
this, whilst IMP11A and ACC are local or distant.

> Hawaii

Side note: apparently tapes from the unique Hawaii BCC 500 have been
saved.  So maybe that's one more possible re-Arpanet host.

> Yup, that's what I figured. I've been trying to evaluate how much
> survives

Here's my take:
https://gunkies.org/wiki/Network_Control_Program_(ARPANET)#Implementations

So there are like four PDP-10 systems and two PDP-11.  The ELF system
will be a major challenge, RATS haven't been scanned off the printer
listing, and the BCC 500... oh boy, let's not go there now.

> I don't know if a runnable build of TENEX has been archived,

I think so.  I "almost" got one running but there was some problem...

> or if ARPA stuff for TOPS-10/20 survived.

TOPS-20AN seems to be there.  TOPS-10, nothing so far.

> I also want to look into System/360 and 370, but I get the sense none
> of the mainframe stuff survived.

I asked around; found nothing.  CDC, same.

> The other problem is of the surviving stacks, they all seem to be for
> the later 96-bit leader, I'm not certain if any of the IMP software
> that has been archived is new enough to work with that.

Nothing for the 316/516 IMP, as far as I know.  Pluribus IMP emulator,
anyone?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-11  5:31     ` Lars Brinkhoff
@ 2022-10-11 12:57       ` Michael Casadevall
  2022-10-11 13:57         ` Lars Brinkhoff
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Casadevall @ 2022-10-11 12:57 UTC (permalink / raw)
  To: Lars Brinkhoff; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 3564 bytes --]

>
>
> Replies inline:
>
> On Tue, Oct 11, 2022 at 1:31 AM Lars Brinkhoff <lars@nocrew.org> wrote:
>
>> TUHS Disclaimer: I will claim this is primarily about getting Unix onto
>> the Arpanet, but it does also contain trace amounts of off-topic
>> information.  Reader discretion is adviced.
>>
>> Michael Casadevall wrote:
>> > I do need to do a readthrough for the VDH driver, which says its for
>> > "very distant hosts".  I think that might be for the radio links
>>
>> The hardware interfaces between a host and an IMP came in three flavors:
>> local host, distant host, and very distant host.  The first two are more
>> or less directly connected and I forget what the difference is.  But a
>> very distant host is basically connected over a phone line with a modem
>> at each end, so it's a different beast.  The VHD driver would be for
>> this, whilst IMP11A and ACC are local or distant.
>>
>>
> That makes sense; most of the time, the documentation that survives implies
> the IMP is always local; knowing this is important. From what I got the
> impression
> From the docs, very early ARPA, you had systems directly on the network,
> but most
> users had to dial into a specific terminal machine, which, based on the
> comments
> on the RFCs, was less than ideal, although I haven't quite figured out how
> things like
> netmail worked.
>
> VHD I guess was more to get more hosts online?
>
> > Hawaii
>>
>> Side note: apparently tapes from the unique Hawaii BCC 500 have been
>> saved.  So maybe that's one more possible re-Arpanet host.
>>
>>
> Oh very nice. Depending on how that works, it might be possible to make a
> radio link
> over ham. I haven't seen anything about these links aside from them being
> marked
> the logicial maps.
>
>
>> > Yup, that's what I figured. I've been trying to evaluate how much
>> > survives
>>
>> Here's my take:
>> https://gunkies.org/wiki/Network_Control_Program_(ARPANET)#Implementations
>>
>> So there are like four PDP-10 systems and two PDP-11.  The ELF system
>> will be a major challenge, RATS haven't been scanned off the printer
>> listing, and the BCC 500... oh boy, let's not go there now.
>>
>>
>  Well, there's multiple UNIX v6 stacks. There's the NOSC one which I tried
> to build,
> and I think is the oldest. The BBN  with TCP stack is a bit mislabeled: it
> still appears
> to support NCP, but none of the client apps are there, but its directly
> built off the NOSC
> stack. it's probably a fork from earlier in development. 79-80 timespawn
> would have been
> *very* early in TCP's life
>
> > I don't know if a runnable build of TENEX has been archived,
>>
>> I think so.  I "almost" got one running but there was some problem...
>
>
>>
> > or if ARPA stuff for TOPS-10/20 survived.
>>
>> TOPS-20AN seems to be there.  TOPS-10, nothing so far.
>>
>> > I also want to look into System/360 and 370, but I get the sense none
>> > of the mainframe stuff survived.
>>
>> I asked around; found nothing.  CDC, same.
>>
>>
> Oof, although par the corse for mainframe preservation :(
>
>
>> > The other problem is of the surviving stacks, they all seem to be for
>> > the later 96-bit leader, I'm not certain if any of the IMP software
>> > that has been archived is new enough to work with that.
>>
>> Nothing for the 316/516 IMP, as far as I know.  Pluribus IMP emulator,
>> anyone?
>>
>
> I do actually wonder how hard that would be. The NCP kernel code seems to
> suggest
> it would be straightforward all things considered. It honestly reminds me
> Hayes modem
> commands of all things ...
> Michael
>

[-- Attachment #2: Type: text/html, Size: 5671 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-11 12:57       ` Michael Casadevall
@ 2022-10-11 13:57         ` Lars Brinkhoff
       [not found]           ` <CAJq=PCV7o_kMvRLXXK9prddmyvf0hAodX+NuqqVF=49iCYt63w@mail.gmail.com>
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Brinkhoff @ 2022-10-11 13:57 UTC (permalink / raw)
  To: Michael Casadevall; +Cc: tuhs

Michael Casadevall wrote:
> From what I got the impression From the docs, very early ARPA, you had
> systems directly on the network, but most users had to dial into a
> specific terminal machine, which, based on the comments on the RFCs,
> was less than ideal

Sounds like a TIP, "Terminal IMP".  It was an IMP with double the amount
of memory.  In the upper half there was software to talk to a modem pool
for dial-in access to the network.  "Less than ideal", sure.  Modem
speeds were often 10-30 characters per second.  Much more fun to sit at
a video terminal next to the host.

> VHD I guess was more to get more hosts online?

In some cases there was an IMP which hooked up to some local hosts, but
they also wanted to connect a computer that not in the same building but
in the area.  That's when a VDH type interface was used.

> The BBN with TCP stack is a bit mislabeled: it still appears to
> support NCP, but none of the client apps are there, but its directly
> built off the NOSC stack.

That's very good.  I hope the NCP support there is in good shape.

> it's probably a fork from earlier in development. 79-80 timespawn
> would have been *very* early in TCP's life

TCP had been underway since 1973.  Experiments called "TCP bakeoffs"
started around 1979.

> > Pluribus IMP emulator,  anyone?
>
> I do actually wonder how hard that would be.

I'm not sure.  I have the impression the Pluribus computer isn't well
documented.

It might not be too hard to write an IMP replacement from scratch.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
       [not found]           ` <CAJq=PCV7o_kMvRLXXK9prddmyvf0hAodX+NuqqVF=49iCYt63w@mail.gmail.com>
@ 2022-10-11 19:58             ` Lars Brinkhoff
  0 siblings, 0 replies; 19+ messages in thread
From: Lars Brinkhoff @ 2022-10-11 19:58 UTC (permalink / raw)
  To: Tom Perrine; +Cc: Michael Casadevall, tuhs

Tom Perrine wrote:
> A specific example of the VDH interface was the IMP at NOSC.
>
> IIRC it had 4 ports?

Normally yes (depending on the hardware configuration).

> One was a local connection to the machine at NOSC in the same room/building.
> One was a VDH to UCSD
> One was a VDH to LOGICON - the connection at the LOGICON end was a "56K
> wideband modem", which was a little larger than a 2-drawer file cabinet. I
> also seem to recall that the power supply had tubes.
> Not sure where the 4th port went - I only saw the UCSD and LOGICON ends in
> person.

Maybe this information for IMP 3 and 35 from 1979 can jog your memory.

HOST NOSC-SECURE2,      0/35,USER,TENEX,PDP10,[USC-ISIR1,ISIR1]
HOST LOGICON,           1/35,USER,UNIX,PDP11
HOST ACCAT-TIP,         2/35,USER,TIP,H316,[NELC-TIP]
HOST NOSC-SECURE3,      3/35,USER,UNIX,PDP11
HOST NOSC-CC,           0/3,SERVER,,UNIVAC-1110,[NUC-CC,NOSC-ELF]
HOST NOSC-SECURE1,      1/3,SERVER,UNIX,PDP11,[NUC-SECURE]
HOST NOSC-SDL,          2/3,SERVER,UNIX,PDP11,[NELC-ELF,NELC]
HOST NWC,               3/3,SERVER,EXEC-8,UNIVAC-1110
HOST NPRDC-11,          4/3,SERVER,UNIX,PDP11

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
@ 2022-10-14 20:30 Noel Chiappa
  0 siblings, 0 replies; 19+ messages in thread
From: Noel Chiappa @ 2022-10-14 20:30 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    >> Looking at net_vdh.h, it seems to be a "VDH-11C"
    >> ...
    >> I wasn't able to find anything out about it at all. (I have some
    >> hardcopy manuals for other ACC IMP interface products, and I was going
    >> to look in them to see if any of them listed its manual in a 'see
    >> also', but I can't find them.)

    > From: Lars Brinkhoff

    > Noel Chiappa wrote:

    >> Did VDH PDP-11's have a special VDH interface

    > Sorry, no idea.

That was a semi-rhetorical question; after I typed it, I did some looking,
and came up with the answer above, the ACC VDH-11.

I did eventually find the hardcopy manuals for other ACC IMP interface
products, but none of them mention the VDH11.

On a hunch, I looked to see if there was a VDH11 driver for ELF, and
sure enough, there was:

  https://github.com/pdp11/elf-operating-system/blob/master/files/kdvdh.m11%5Blep%2Cjrl%5D168

(If anyone wants to look at it, ktbl.sml hold the register definitions.)

With no manual for the device, and no museum catalog hits to show that
someone has one which hasn't been scanned in yet, that's probably a dead end,
although with the two drivers, one could probably mock up a rudimentary
programmming manual.

I'm not sure there's any point, though; using an LH/DH interface is going to
work as well, and those device are already supported.


    > From: Paul Ruizendaal

    > impio.c: available here:

Thanks for chasing those all down; I knew the BBN system was based on the NCP
Unix (called in this discussion the 'NOSC' system), so I figured it would
have the missing files, in some form.

Looking at a diff between the damaged impio.c in the NOSC tree, and the
impio.c in the BBN tree, there are some changes (in the section where we have
both versions) between the NOSC one and the BBN one, but it will probably be
possible to take the missing piece off the bank end of the BBN one and tack
it on to the NOSC one.


Somewhere in the document scans available online from DOD, there used to
be a long thing from the UIUC people who did the original NCP Unix. I don't
know if it included source; it might have.

	Noel

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-14 16:37   ` Clem Cole
@ 2022-10-14 19:06     ` Warner Losh
  0 siblings, 0 replies; 19+ messages in thread
From: Warner Losh @ 2022-10-14 19:06 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On Fri, Oct 14, 2022, 10:39 AM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Fri, Oct 14, 2022 at 12:09 PM Phil Budne <phil@ultimate.com> wrote:
>
>> Paul Ruizendaal <pnr@planet.nl> wrote:
>> > sys4.c: I think this is available in BBN V6:
>> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken <
>> https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken>
>> > In this file the only real network addition is Jack Haverty’s user
>> timer variable, I think. What else is missing?
>>
>> Side question: What/when is the origin of the pty driver?
>>
> IIRC Rand - there were around for the V6
>


Yea, pseudo terminalsquite common common and clearly RAND implemented them
too. It's quite possible the bell lab folks learned of the RAND additions,
maybe via Berkeley where several bell Labs folks spent time and who had
these RAND tapes...

Warner

> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 2575 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-14 11:55 Paul Ruizendaal
  2022-10-14 16:08 ` Phil Budne
@ 2022-10-14 18:47 ` Lars Brinkhoff
  1 sibling, 0 replies; 19+ messages in thread
From: Lars Brinkhoff @ 2022-10-14 18:47 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: The Eunuchs Hysterical Society

Paul Ruizendaal wrote:
> Maybe I’m dim, but I’ve lost track in this discussion of what is
> missing / corrupted.

In the tarball called nosc.tar, the files sys4.c and impio.c are
damaged.  For sys4.c it seems identical copies can be found elsewhere.
For impio.c there are variants that are similar but not identical.  So,
no a big deal; workaround were found.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-14 16:08 ` Phil Budne
@ 2022-10-14 16:37   ` Clem Cole
  2022-10-14 19:06     ` Warner Losh
  0 siblings, 1 reply; 19+ messages in thread
From: Clem Cole @ 2022-10-14 16:37 UTC (permalink / raw)
  To: Phil Budne; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

On Fri, Oct 14, 2022 at 12:09 PM Phil Budne <phil@ultimate.com> wrote:

> Paul Ruizendaal <pnr@planet.nl> wrote:
> > sys4.c: I think this is available in BBN V6:
> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken <
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken>
> > In this file the only real network addition is Jack Haverty’s user timer
> variable, I think. What else is missing?
>
> Side question: What/when is the origin of the pty driver?
>
IIRC Rand - there were around for the V6
ᐧ

[-- Attachment #2: Type: text/html, Size: 1623 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-14 11:55 Paul Ruizendaal
@ 2022-10-14 16:08 ` Phil Budne
  2022-10-14 16:37   ` Clem Cole
  2022-10-14 18:47 ` Lars Brinkhoff
  1 sibling, 1 reply; 19+ messages in thread
From: Phil Budne @ 2022-10-14 16:08 UTC (permalink / raw)
  To: tuhs

Paul Ruizendaal <pnr@planet.nl> wrote:
> sys4.c: I think this is available in BBN V6:
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken <https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken>
> In this file the only real network addition is Jack Haverty’s user timer variable, I think. What else is missing?

Side question: What/when is the origin of the pty driver?

https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/dmr/pty.c

Has a revision history, but no date/author for its origin.

And
https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/dmr/pty.c

is simpler, and lacks the changes and history.

https://en.wikipedia.org/wiki/Pseudoterminal#History
claims:
	"Unix pseudoterminals originated in 1983 during the
	development of Eighth Edition Unix and were based on a similar
	feature in TENEX."

But the above pty.c clearly predates that.

Wikipedia continues with further bogosity:

	They were part of the 4.2 release of BSD, with a rather
	cumbersome openpty() interface defined for use.

with a link to https://www.freebsd.org/cgi/man.cgi?query=openpty&sektion=3
which says
"The openpty() and forkpty() functions first appeared in 4.3BSD Reno."

ISTR in 4.2 days there wasn't any library code to open a ptyXX/ttyXX pair,
which was CERTAINLY cumbersome.  forkpty is downright handy, and portable.

phil

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
@ 2022-10-14 11:55 Paul Ruizendaal
  2022-10-14 16:08 ` Phil Budne
  2022-10-14 18:47 ` Lars Brinkhoff
  0 siblings, 2 replies; 19+ messages in thread
From: Paul Ruizendaal @ 2022-10-14 11:55 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

Maybe I’m dim, but I’ve lost track in this discussion of what is missing / corrupted.

sys4.c: I think this is available in BBN V6:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken <https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken>
In this file the only real network addition is Jack Haverty’s user timer variable, I think. What else is missing?

imp11a.c: available in two versions here:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/dmr <https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/dmr>

impio.c: available here:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ncpkernel/impio.c <https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ncpkernel/impio.c>

Maybe the compiler has a different opinion, but they don’t look obviously corrupted [??]

Also, the BBN-VAX files may be a solution. BBN sent four tapes with snap shots to CSRG in 1981. The TUHS website has the newest version, but there are 3 older ones (all 4 come from Kirk McKusick’s DVD set). They all have a slightly different set of files. These tapes also have IMP and ACC drivers in them, along with a token ring driver that was apparently based on Noel’s work back in the day. These files may also help filling in blank spots in PDP11 files.

Paul



[-- Attachment #2: Type: text/html, Size: 1974 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
  2022-10-12 19:38 Noel Chiappa
@ 2022-10-13  5:50 ` Lars Brinkhoff
  0 siblings, 0 replies; 19+ messages in thread
From: Lars Brinkhoff @ 2022-10-13  5:50 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

Noel Chiappa wrote:
> Did VDH PDP-11's have a special VDH interface, or did they simply use
> an off-the-rack DEC synchronous serial interface like a DU11?

Sorry, no idea.  I have only studied PDP-10 interfaces.

> Anyway, you don't want to use VDH.

If imp11a.c is beoynd repair, I'd say go with the ACC interface.  There
is documentation and a working emulator already exists, albeit for a
PDP-10.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code
@ 2022-10-12 19:38 Noel Chiappa
  2022-10-13  5:50 ` Lars Brinkhoff
  0 siblings, 1 reply; 19+ messages in thread
From: Noel Chiappa @ 2022-10-12 19:38 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Michael Casadevall

    > sys4.c is entirely corrupted, and part of impio.c is cut off

The copy on MIT-CSR (the origin of the copy at TUHS) has the same issues. I
doubt it's possible to recover them from that system; you'll have to find
some other way to recover them (perhaps through a dump of the BBN system), or
re-code them (as you did with sys4.c).

    > I do need to do a readthrough for the VDH driver ... I think that might
    > be for the radio links to Hawaii and the UK? 

No. Read BBN 1822.

The LH and DH bit-serial physical interfaces only work up to about 1000 feet
or so. (Less for LH; DH is logically idential to LH, but uses differential
pairs - the LH is single-sided). VDH is, in the bottom layer, simply a
synchronous serial link, allowing the host to be up to hunreds of miles from
the IMP.


    > From: Lars Brinkhoff

    > Another it adding emulators for various IMP interfaces. I.e. you will
    > not get anywhere without adding one of IMP11A, ACC, or VDH to SIMH.

Did VDH PDP-11's have a special VDH interface, or did they simply use an
off-the-rack DEC synchronous serial interface like a DU11? (More of them
here:

  http://gunkies.org/wiki/Category:DEC_Synchronous_Serial_Interfaces

if anyone wants.) Looking at net_vdh.h, it seems to be a "VDH-11C"

Looking online, the VDH-11 seems to be an ACC prodict, but I wasn't able to
find anything out about it at all. (I have some hardcopy manuals for other
ACC IMP interface products, and I was going to look in them to see if any of
them listed its manual in a 'see also', but I can't find them.)

I'm not sure why people did just use an off-the-rack DEC synchronous serial
interface; maybe the VDH11 did a BBN specific CRC, or something (in addition
to using DMA; mostr DEC sync interfaces didn't, IIRC)?

Anyway, you don't want to use VDH.

	Noel

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET  code
@ 2022-10-11 15:08 Paul Ruizendaal
  0 siblings, 0 replies; 19+ messages in thread
From: Paul Ruizendaal @ 2022-10-11 15:08 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

>> The BBN with TCP stack is a bit mislabeled: it still appears to
>> support NCP, but none of the client apps are there, but its directly
>> built off the NOSC stack.
> 
> That's very good.  I hope the NCP support there is in good shape.
> 
>> it's probably a fork from earlier in development. 79-80 timespawn
>> would have been *very* early in TCP's life
> 
> TCP had been underway since 1973.  Experiments called "TCP bakeoffs"
> started around 1979.

That is what the “V6 with TCP” on TUHS is:

Following the success of NCP Unix, it became a base for various TCP experiments in the ’77-’79 era. The first was an implementation by Jack Haverty, that wrapped an existing TCPv2 stack that was written in PDP-11 assembler into a Unix application. It ran in user mode and depended on Rand ports and several extensions that Jack added to the kernel (await/capac and a user mode timing variable, where the clock routine incremented a variable in user space). He used a PDP-11 with little core and the pipes (ports) did not stay in the file buffers, but flushed onto disk. This killed performance: Jack recalls that a bad run would average a few characters per second.

Next Mike Wingfield wrote a TCPv4 stack in C, more or less using the architecture of the above. It was the “winner" of the December 1979 bake-off. I think it is the first TCPv4 implementation for Unix and maybe the oldest surviving source for TCPv4 overall. I wanted to try if it would still interoperate with modern TCP/IP, but I never got around to that. An actual printout survives in the SRI archives and I painstakingly retyped that source, just weeks before Noel found the right tapes :^). Later still, Craig Partridge found a full report and listing in the BBN archives (report no. 3724). This NCP Unix with the Wingfield library is the version that is labeled “BBN V6 with TCP” on TUHS.

Some of the code in the Wingfield stack is to test the protocol. Arpanet essentially offers circuit switching, and some of the code is there to simulate dropped packets, out-of-order packets, etc. It also tested security features that were under consideration, but subsequently dropped as interest shifted to end-to-end encryption.

Again, user mode TCP was not found to be practical, the 16-bit era was ending and that is when Rob Gurwitz was assigned to write a new stack for the VAX (1980). By that time Jack Haverty was his boss. Some parts of the BBN VAX-TCP design still echo the user space origins and experiences of the BBN team in the immediate years before. This stack I got working and it still interoperates with modern TCP/IP (at least it did some 5 years ago).

Jack Haverty can easily be reached via the internet-history mailing list.

I’ve summarised the history here: http://chiselapp.com/user/pnr/repository/TUHS_wiki/wiki?name=early_networking
I should transfer it to the TUHS wiki or to Gunkies one of these days.

===

I am not sure I understood which files are missing or corrupted and in which NCP Unix trees. Noel retrieved the files from old (mouldy even) tapes so some corruption is quite possible. Pulling together material from various sources can hopefully lead to a working source tree. Glad to help.

Further note that NCP Unix was initially developed on 5th Edition, but soon migrated to 6th edition. I am sure that the various installations tracked new developments and installed extra bits and pieces. The surviving images are from 1979 and for sure would have picked up bits from newer releases and other sources (such as the Uni of Calgary buffer extensions).

Paul


^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2022-10-14 20:30 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-10 18:33 [TUHS] Attempting To Build NOSC and BBN UNIXs + ARPANET code Michael Casadevall
2022-10-10 19:48 ` [TUHS] " Lars Brinkhoff
2022-10-10 20:31   ` Michael Casadevall
2022-10-11  5:31     ` Lars Brinkhoff
2022-10-11 12:57       ` Michael Casadevall
2022-10-11 13:57         ` Lars Brinkhoff
     [not found]           ` <CAJq=PCV7o_kMvRLXXK9prddmyvf0hAodX+NuqqVF=49iCYt63w@mail.gmail.com>
2022-10-11 19:58             ` Lars Brinkhoff
2022-10-10 20:31 ` Clem Cole
2022-10-10 20:48   ` Michael Casadevall
2022-10-10 21:37     ` Clem Cole
2022-10-11 15:08 Paul Ruizendaal
2022-10-12 19:38 Noel Chiappa
2022-10-13  5:50 ` Lars Brinkhoff
2022-10-14 11:55 Paul Ruizendaal
2022-10-14 16:08 ` Phil Budne
2022-10-14 16:37   ` Clem Cole
2022-10-14 19:06     ` Warner Losh
2022-10-14 18:47 ` Lars Brinkhoff
2022-10-14 20:30 Noel Chiappa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).