> From: Larry McVoy
> I'd really like the SCCS history.
Any idea if that even still exists, or did it get shredded somewhere along the
way?
Anyway, should I spin up my nephew on trying to find the right person to put
out a historic, personal-use license?
Noel
Missed the cc line. Also I have mailman up @ lakewoodmicro.com at Digital Ocean. If we need mailing lists.
-----Original Message-----
From: William Pechter <pechter(a)gmail.com>
To: Grant Taylor <gtaylor(a)tnetconsulting.net>
Sent: Wed, 29 Aug 2018 14:46
Subject: Re: [TUHS] RetroNet…
Damn. Television was autocorrect but I wrote "Telebit" at the time.
Perhaps setting up a mumble server for voice chat makes sense.
Bill
-----Original Message-----
From: Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org>
To: tuhs(a)minnie.tuhs.org
Sent: Wed, 29 Aug 2018 14:42
Subject: Re: [TUHS] RetroNet…
On 08/29/2018 12:26 PM, William Pechter wrote:
> Count me in.
Cool!
Welcome!
We're currently hanging out in the #retronet group on the Synchronet
network (I'm accessing through irc.chivanet.org)
> I think a UUCP over ssh would be nice as would an SSL version.
I've personally done UUCP over SSH multiple times.
It looks like TCP port 540 is reserved for UUCP over TCP and TCP port
4031 is reserved for UUCP over SSL.
So, we'll definitely be offering those services inside of RetroNet.
Currently the idea is to make services available inside of RetroNet. I
don't know how many services will be openly available across the
Internet. Primarily for security / safety reasons.
That being said, I think we are planing on a gateway for things. We're
certainly willing to talk about other options too.
> I would like to see UUCP over ether as serial for backwards compatibility
> to talk to old machines and emulation.
I / we would like to know more about the "over ether as serial" part.
I'd think the goal would be to have RS-232 (et al) serial ports that can
connect to retro computers and make things look like what they would
expect to see. That being said, we will either need an RS-232 (et al)
serial port on a gateway, or something else to translate from serial to
likely an IP~>telnet connection.
If you have ideas, please bring them and share them.
> Some of the kid's I know would be blown away by Cnews and television or
> transported over Internet or PPP links.
Yep. :-)
--
Grant. . . .
unix || die
> From: Noel Chiappa
> I'll update the page as well.
I have to do it since, after severe issues with spam, a login is required to
make changes.
If anyone is interested in adding content (please, we need more in just about
every area - I've done a lot of PDP-11's, but that's a fairly small corner
overall :-), please drop me a short line, and I'll set you up (just let me
know the account name you want, and what email address to associate with it).
> From: William Pechter
> Just a plug for the 4.3+University of Wisconsin version on Simh.
I don't think I see that in the TUHS repository that Clem just pointed to? Got a
URL?
Any chance I can convince you to add a bit of content about it? :-)
Noel
> From: Rares Aioanei
> gunkies.org works. The URL for getting the sets doesn't
Ah, OK.
Link-rot; sigh. The bane of the Web!
If someone can provide a working alternative for you to use, I'll update the
page as well.
Noel
> From: Rares Aioanei
> Link doesn't seem to work, I get "Connection reset".
Which link - the gunkies.org (Computer History Wiki) one?
It's working for me at the moment.
Does your browser accepts non-HTTPS URLs? (There's apparently a craze on
to denigrate them at the moment.)
Noel
> Has anyone experimented with building Unix using C++, to take
> advantage of strong typing? My guess is no--it would be a Herculean task
likely to introduce more bugs than it would fix.
I'm not sure what "strong typing" gain you expect to find. With the
exception of the void* difference, C++ isn't much more "type strong" than C.
A lot of the type issues you can find on the Kernel just by turning up the
compiler warnings (or use lint).
The biggest issue we had was BSD didn't use void* at all. Had they
converted pointers to void*, which is in implementation necessarily the same
as char*,
C would have done the right thing. The problem is they did what I call
"Conversion by union." They would store a char* into one element of a
union and read it out of another typed pointer.
This works fine for a VAX where all pointers are the same format, but fails
on word address machines (notably in our case the HEP where the target size
is encoded in the low order bits of the pointer).
Still, running around and fixing those was only a few hours work.
The DevSwitch is the beginnings of an object oriented philosophy. Alas,
the original UNIX used it only for mapping major dev numbers to functions.
It got some later use for other things like multi filesystemsupport.
The scary supportability thing in the kernel, isn't so much typing, but the
failuer to "hide" implementation details of one part of the kernel from the
other.
Seth Morabito:
After the past several years of focusing on 3B2 preservation and
emulation, I've begun to wonder whether 3B2 hardware was used very much
inside of Bell Labs. Has anyone ever heard whether Research UNIX was
ever ported to the WE32100? I've certainly never seen anything that
would suggest it was, but I'd love to be proven wrong.
=====
I never heard of anyone doing such a thing. Had they ported
the kernel I would almost certainly have heard about it, because
they'd have asked me a question or two. Much VAX-specific
structure inside there that I'd love to have had the time and
energy to clean up.
It's possible that someone did a semi-port, moving a lot of
the user-mode tools like the shell and the Jerq software.
Dave Kapilow did something like that for early SunOS, including
a mux-like X11 terminal program called sux, built atop a
library that did a simple mapping from Jerq graphics-library
calls to X11.
Certainly nobody inside 1127 ever did either of those things.
A few of us played with 3B1 or 3B2 systems (I remember Tom
Duff had a 3B1 at home at one point), but never very seriously.
Norman Wilson
Toronto ON
> From: Clem Cole
> Looking at the v6 distribution tape I have, the assembler versions of
> roff and nroff was there
Whoa! The standard V6 distribution tape, as in the one there are a couple of
copies of in the repository, does not have that.
Do you have that in machine-readable form? If so, can you get it to Mr. Toomey
ASAP?
> The order I remember is this ... V5, V6, Patches, Typesetter C, TS, V7
Where do USG and PWB fit into that?
The repository has PWB (or, what is _claimed_ to be PWB), which is how I know
the MIT system is PWB. But there is nothing of the others (except the kernel
manual for USG, which shows that the version described in it is basically V6).
If anyone has TS in _any_ form (including hardcopy listings, please speak up!
Those 'early' PDP-11 versions are very poorly documented now, and I'd love to
get more on them.
Noel
My two cents, ...
> From: Clem Cole <clemc(a)ccc.com>
> Date: Thu, 23 Aug 2018 20:30:19 -0400
> To: ron(a)ronnatalie.com
> Subject: Re: [TUHS] C++ / Kernel
>
> Yep. Im pretty sure I remember void being in typesetter C also. IIRC the
> differences between that version of Dennis???s compiler and what was included
> in 7th Edition was mostly in the libraries ie stdio was first released as
> part of the typesetter compiler but it was still a work in progress.
K&R 1 did not have void or structure assignment. Those came later,
although I'm not sure when. They may have been mentioned in an
appendix; my copy isn't handy to check.
At what point did each struct become its own namespace? I think
around the time of K&R1.
> From: Clem cole <clemc(a)ccc.com>
> Date: Thu, 23 Aug 2018 22:52:24 -0400
> To: Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
> Subject: Re: [TUHS] C++ / Kernel
>
> ...
>
> The big changes to the language were between 6th Edition and Typesetter
> which were done in concert if not to support Brian???s work on the troff
> rewrite. Plus the first draft of book was being written around then also.
The troff rewrite was later, circa '81 or so. Definitely NOT in the
V6/V7 timeframe.
Arnold
> From: Jaap Akkerhuis
> I've been told that when troff was rewritten from assembler to C
Was TROFF ever in assembler?
I'm pretty sure NROFF was, as of V6; the source is not in the V6 distro, and
the binary is stripped, but looking at the object code, it doesn't look like C
compiler output.
As of the PWB system that MIT had (or maybe it was TS - how can one tell the
difference, does anyone know?), NROFF and TROFF were generated from the same C
source (which I have, if anyone wants to look at it).
> the compiler needed some rework and thus typesetter C was born.
I heard he needed features (e.g. longs and unsigned), but... looking at the
N/TROFF source, there are _no_ 'unsigned's, and only a handful of 'long'
variables! There also don't seem to be any bit fields, typedefs, etc.
There is _one_ initialized structure (array of structures, to be precise).
(Although there are a lot of places were an int is initialized with a
double-character constant!)
About the only features in "C Changes" that it uses are i) register types on
arguments, and the 'static' storage class.
So now I'm wondering about that meme...
Noel