https://fosdem.org/2020/schedule/event/early_unix/
The video of Warner Losh's FOSDEM presentation "The Hidden Early History of Unix" is now available.
Cheers, Warren
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
maybe if interest, i have a copy of an article by sandy fraser, “early experiments with time division networks” from ieee networks, jan 1993, pp12-26.
this is a high level paper and describes spider, datakit, incon.
it may have little new but i felt it had a lot of good background and a useful references list.
i am wary of scanning it as its the ieee...
-Steve
> On 15 Feb 2020, at 2:00 am, tuhs-request(a)minnie.tuhs.org wrote:
>
> Send TUHS mailing list submissions to
> tuhs(a)minnie.tuhs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> or, via email, send a message with subject or body 'help' to
> tuhs-request(a)minnie.tuhs.org
>
> You can reach the person managing the list at
> tuhs-owner(a)minnie.tuhs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of TUHS digest..."
>
>
> Today's Topics:
>
> 1. Datakit early end-to-end protocol(s) (Paul Ruizendaal)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 14 Feb 2020 17:22:37 +0100
> From: Paul Ruizendaal <pnr(a)planet.nl>
> To: TUHS main list <tuhs(a)minnie.tuhs.org>
> Subject: [TUHS] Datakit early end-to-end protocol(s)
> Message-ID: <7128AB08-C99E-490E-BD81-7D62503FF676(a)planet.nl>
> Content-Type: text/plain; charset=utf-8
>
>
> I’m looking for the end-to-end datakit network protocol as it existed in 7th Edition.
>
> Context is as follows:
>
> - The Spider network guaranteed reliable, in-order delivery of packets at the TIU interface. There does not seem to have been a standard host end-to-end protocol, although applications did of course contain sanity checks (see for instance the ‘nfs’ source here: http://chiselapp.com/user/pnr/repository/Spider/tree?ci=tip)
>
> - Datakit dropped the reliable delivery part (although it did retain the in-order guarantee) and moved this responsibility to the host. It is the (early) evolution of the related protocol that I’m trying to dig up.
>
> - 7th Edition appears to have had a (serial line based) Datakit connection. Datakit drivers are not in the distributed files, but its tty.h file has defines for several Datakit related constants. Also, as the first Datakit switches became operational at Murray Hill in ’78 or ’79, it seems a reasonable assumption that the Research code base included drivers & protocols for it around that time.
>
> - After that the trail continues with the 8th edition which has a stream filter (dkp.c) for the “New Datakit Protocol”: http://chiselapp.com/user/pnr/repository/v8unix/artifact/01b4f6f05733aba5 This suggests that there was an “Old Datakit Protocol” as well - if so, this may have been the protocol in use at the time of 7th Edition.
>
> The “New Datakit Protocol” appears to be (more or less) the same as what was later called URP (Universal Receiver Protocol). At the time of Plan9 its IL/IP protocol appears to have been designed as an equivalent for URP/Datakit. The early protocols where apparently (co-)designed by Greg Chesson and maybe also stood at the base of his later XTP protocol work.
>
> Any recollections about the early history and evolution of this Datakit protocol are much appreciated. Also, if the source to the 7th Edition Datakit network stack survived I’d love to hear.
>
> Paul
>
>
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> TUHS mailing list
> TUHS(a)minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
>
>
> ------------------------------
>
> End of TUHS Digest, Vol 51, Issue 18
> ************************************
I’m looking for the end-to-end datakit network protocol as it existed in 7th Edition.
Context is as follows:
- The Spider network guaranteed reliable, in-order delivery of packets at the TIU interface. There does not seem to have been a standard host end-to-end protocol, although applications did of course contain sanity checks (see for instance the ‘nfs’ source here: http://chiselapp.com/user/pnr/repository/Spider/tree?ci=tip)
- Datakit dropped the reliable delivery part (although it did retain the in-order guarantee) and moved this responsibility to the host. It is the (early) evolution of the related protocol that I’m trying to dig up.
- 7th Edition appears to have had a (serial line based) Datakit connection. Datakit drivers are not in the distributed files, but its tty.h file has defines for several Datakit related constants. Also, as the first Datakit switches became operational at Murray Hill in ’78 or ’79, it seems a reasonable assumption that the Research code base included drivers & protocols for it around that time.
- After that the trail continues with the 8th edition which has a stream filter (dkp.c) for the “New Datakit Protocol”: http://chiselapp.com/user/pnr/repository/v8unix/artifact/01b4f6f05733aba5 This suggests that there was an “Old Datakit Protocol” as well - if so, this may have been the protocol in use at the time of 7th Edition.
The “New Datakit Protocol” appears to be (more or less) the same as what was later called URP (Universal Receiver Protocol). At the time of Plan9 its IL/IP protocol appears to have been designed as an equivalent for URP/Datakit. The early protocols where apparently (co-)designed by Greg Chesson and maybe also stood at the base of his later XTP protocol work.
Any recollections about the early history and evolution of this Datakit protocol are much appreciated. Also, if the source to the 7th Edition Datakit network stack survived I’d love to hear.
Paul
All, I've also set this up to try out for the video chats:
https://meet.tuhs.org/COFF
Password to join is "unix" at the moment.
I just want to test it to confirm that it works; I'll be heading
out the door to go to the shops soon.
Cheers, Warren
I rather enjoyed having the “unix50.org” website around: very handy to test out bits and pieces of Unix history.
It seems to have been taken down. Would it make sense to have this resource available permanently?
> What i like is the autocorrect feature in v8:
>
> $ cd /usr/blot
> /usr/blit
> $ pwd
> /usr/blit
Here I am, editor of the v8 manual and unaware of the feature.
We now know that silent correction is a terrible idea.
Postel's principle: "be conservative in what you do, be liberal
in what you accept from others" was doctrine in early HTML
specs, and led to disastrous disagreement among browsers'
interpretation of web pages. Sadly, the "principle" lives on
despite its having been expunged from the HTML spec.
Today's "langsec" movement grew out of bitter experience
with malicious inputs exploiting "liberal" interpretation of
nonconforming data.
Today's NYT has an article about fake knockoffs of George Orwell
for sale on Amazon. It cites an edition of "Animal Farm"
apparently pirated by lowgrade OCR autocorrected and never
proofread. One of the many gaffes is that every instance of
"iv" beame ChapterIV, as in "prChapterIVacy".
I didn't like some Lisp systems' DWIM (do what I mean) when I
first heard about the feature, and I like it even less 40-some
years on. I would probably have remonstrated with Rob had I
realized the shell was doing it.
Doug
>What's funny is that in doing the work to get 'se' running on Georgia
>Tech's Vax, I had to learn vi. By the time I was done, vi had become
>my main editor and had burned itself into my finger's ROMs.
I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang.
I have always suspected that the brevity of the Unix command names was strongly
influenced by the clunky keyboards on the teletypes that were being used. Can
anyone confirm, deny, and/or comment on this?
-r
On 1/17/20, Brantley Coile <brantley(a)coraid.com> wrote:
> what he said.
>
>> On Jan 17, 2020, at 6:20 PM, Rob Pike <robpike(a)gmail.com> wrote:
>>
>> Plan 9 is not a "single-system-image cluster".
>>
>> -rob
>>
>
>
I guess SSI isn't the right term for Plan 9 clustering since not
everything is shared, although I would still say it has some aspects
of SSI. I was talking about systems that try to make a cluster look
like a single machine in some way even if they don't share everything
(I'm not sure if there's a better term for such systems besides the
rather vague "distributed" which could mean anything from full SSI to
systems that allow transparent access to services/devices on other
machines without trying to make a cluster look like a single system).
[x-posting to COFF]
Idea: anybody interested in a regular video chat? I was thinking of
one that progresses(*) through three different timezones (Asia/Aus/NZ,
then the Americas, then Europe/Africa) so that everybody should be
able to get to two of the three timezones.
(* like a progressive dinner)
30-60 minutes each one, general old computing. Perhaps a guest speaker
now and then with a short presentation. Perhaps a theme now and then.
Perhaps just chew the fat, shoot the breeze as well.
Platform: Zoom or I'd be happy to set up a private Jitsi instance.
Something else?
How often: perhaps weekly or fortnightly through the three timezones,
so it would cycle back every three or six weeks.
Comments, suggestions?!
Cheers, Warren
> From: Dave Horsfall <dave(a)horsfall.org>
> [ Getting into COFF territory, I think ]
I'm sending this reply to TUHS since the message I'm replying to has some
errors, and I'd like for the corrections to be in the record close by.
> On Thu, 30 Jan 2020, Clem Cole wrote:
>> They way they tried to control it was to license the bus interface chips
>> (made privately by Western Digital for them IIRC but were not available
>> on the open market).
Although DEC did have some custom chips for QBUS interfacing, they didn't
always use them (below). And for the UNIBUS, the chips were always, AFAIK,
open market (and the earliest ones may have predated the UNIBUS).
E.g. the M105 Address Selector, a single-width FLIP CHIP, used in the earliest
PDP-11's when devices such as the RK11-C, RP11 and TM11 were made out of a
mass of small FLIP CHIPS, used SP380A's for its bus receivers and 8881's for
transmitters.
On the QBUS, the KDF11-A and KDJ11-A CPU cards used AMD 2908's as bus
transceivers, even though DEC had its own custom chips. The KDF11-A also
used DS8640's and DS8641's (transmitters and receivers), and also an 8881!
(The UNIBUS and QBUS were effectively identical at the analog level, which is
why a chip that historical was still in use.)
>> If I recall it was the analog characteristics that were tricky with
>> something like the BUS acquisition for DMA and Memory timing, but I
>> admit I've forgotten the details.
One _possibility_ for what he was talking about was that it took DEC a while
to get a race/metastability issue with daisy-chained bus grant lines under
control. (The issue is explained in some detail here:
https://gunkies.org/wiki/Bus_Arbitration_on_the_Unibus_and_QBUS
and linked pages.) This can been seen in the myriad of etch revisions for the
M782 and related 'bus grant' FLIP CHIPs:
https://gunkies.org/wiki/M782_Interrupt_Control
By comparison, the M105 only had 3 through it's whole life!
It wasn't until the M7821 etch D revision, which came out in 1977, almost a
decade after the first PDP-11's appeared, that they seemed to have absorbed
that the only 'solution' to the race/metastability issue involved adding
delays.
In all fairness, the entire field didn't really appreciate the metastability
issue until the LINC guys at WUSTL did a big investigation of it, and then
started a big campaign to educate everyone about it - it wasn't DEC being
particularly clueless.
> Hey, if the DEC marketoids didn't want 3rd-party UNIBUS implementations
> then why was it published?
Well, exactly - but it's useful to remember the differening situation for DEC
from 1970 (first PDP-11's) and later.
In 1970 DEC was mostly selling to scientists/engineers, who wanted to hook up
to some lab equipment they'd built, and OEM's, who often wanted to use a mini
to control some value-added gear of their own devising. An open bus was really
necessary for those markets. Which is why the 1970 PDP-11/20 manual goes into
a lot of detail on how to interface to the PDP-11's UNIBUS.
Later, of course, they were in a different business model.
Noel
Talking of editors...
Once I learned Wordstar in old CP/M (before that it was mostly line
editing), and then soon, other editors that supported the Wordstar key
combinations, I got hooked on those. Joe is, to date, one of my
favorites.
On ancient UNIX, my editor of choice was 's' from Software Tools, its
main advantage being that it didn't require curses. Then we got VMS and
'eve' and that took over for a while (though I never took advantage of
all its power), mostly until I ported 's' and 'joe'.
Then came X, and when nedit was released, I was hooked on it. It has
been for decades almost the only one that could do block selection 'a
la' RAND editor.
I have been struggling to continue using it despite it lack of support
for UTF, trying various projects spun off nedit, until I recently
discovered xnedit, which is an update available on GitHub and is again
all I need, with support for UTF8, some minor UI improvements and
support for modern fonts.
Now, I still use 's' for ancient Unix emulators, 'joe' for the
command line and 'xnedit' for X.
j
--
Scientific Computing Service
Solving all your computer needs for Scientific
Research.
http://bioportal.cnb.csic.es
I’ve seen the archives of Atari System V Release 4 for the TT030, and the scanned user and developer manuals. Has anything else been preserved, e.g. the installation tapes and any other manuals?
Is there even a full accounting of what was in the box and what shipped afterwards (patches etc.)?
-- Chris
> Does anybody have or know of a list of system calls that describes
> when and what version of UNIX (and descendents) they were added?
Hardly a week goes by in which I don't refer to the attached
condensed listing of all the man pages in v1-v9, taken from
my "Research Unix Reader". It casts a much narrower net than
Diomedes Spinelli's repository. but it takes no clicking to
look thing up--just a quick grep.
Doug
[ Getting into COFF territory, I think ]
On Thu, 30 Jan 2020, Clem Cole wrote:
> BTW: Dave story is fun, but I think a tad apocryphal. He's right that
> DEC marketing was not happy about people using it, but it was well
> spec'ed if you had CPU schematics. They way they tried to control it
> was to license the bus interface chips (made privately by Western
> Digital for them IIRC but were not available on the open market). IIRC
> if you did not use DEC's chips, you could have issues if you >>similar<<
> function chips from National Semi. I remember Ken O'Munhundro giving a
> talk at a USENIX (while he was CEO of Able) talking about 'be careful
> with foreign UNIBUS implementations.' If I recall it was the analog
> characteristics that were tricky with something like the BUS acquisition
> for DMA and Memory timing, but I admit I've forgotten the details.
Ah; the chips could explain it. I can't remember where I heard the story,
but it was likely in ";login:" or some place. Hey, if the DEC marketoids
didn't want 3rd-party UNIBUS implementations then why was it published?
> I think you are confusing VAX's SBI with UNIBUS. With the Vax, unlike
> PDP-11, the systems did not come with complete schematics for all
> boards. So to design for the SBI you had to reverse engineer the CPU
> and Memory boards. DEC having successfully won the CalData suit, went
> after Systems Industries who was the first to build SBI controllers.
> DEC lost, but the truth was that because they had work had been reverse
> engineering, SI was close but not 100% right and they had a number of
> issues when the boards first hit the street, particularly with UNIX
> which did a better job of overlapped I/O than VMS did. At UCB we had a
> logic analyzer in one of the 780s at all times, and the phone number of
> the SI engineers. We eventually helped them put out a couple ECO's
> that make the original boards work in practice much better.
No; it was definitely UNIBUS (I wasn't aware of the SBI at the time).
As for overlapped seeks, when they were implemented in Unix it broke the
RK-11 controller, and DEC pointed the finger at Unix (of course) since
their own gear worked. To cut a long story short, they were forced to use
some fancy diagnostic (DECEX?) which hammered everything at the same time,
and the problem showed up. Turned out that their simpler diagnostics did
not test for overlapped seeks, because they knew that it didn't work; out
same the FE to modify the controller...
> BTW: My friend Dave Cane lead the BI at DEC after finishing up the
> VAX/750 project (he had designed the SBI for 780 before that). In
> fact, the BI was >>supposed<< to be 'open' like Multibus and VME and all
> chips were supposed to be from the merchant market. But at the last
> minute, DEC marketing refused and locked down the specs/stopped shipping
> schematics with the new systems destined to use BI. Dave was so pissed,
> he left DEC to found Masscomp and design the MC500 (using the
> Multibus).
Yet another reason why DEC went under, I guess...
-- Dave
Greetings,
Is this issue online? I may have a copy buried in my boxes of books, and am
on the road. I'd like to read the article on portability and/or the one on
performance. One of those has a table of internal vs external release names
/ dates. archive.org and elsewhere only has through 83. I discovered I
might have it this morning 20 minutes before I had to leave for the airport
for another talk. :(
Thanks for any help you can provide....
Warner
> From: Warner Losh
> this predates everything except Whirlwind which I can't find a paper for.
Given the 'Whirlwind is a ringer' comment, I asssume this:
https://en.wikipedia.org/wiki/Whirlwind_I<
is what they mean.
Pretty interesting machine, if you study its instruction set, BTW; with no
stack, subroutines are 'interesting'.
Noel
> From: Clem Cole
> So WD designs and builds a few LSI-11 as a sales demo of what you could
> do
> ...
> he put it on the QBUS which DEC could not lock up because they did not
> create it as WD had.
Wow! WD created the QBUS? Fascinating. I wonder if DEC made any changes to the
QBUS between the original demo WD boards and the first DEC ones? Are there any
documents about the WD original still extant, do you know?
(FWIW, it seems that whoever did the QBUS interrupt cycle had heard about the
metastability issues when using a flop to do the grant-passing arbitrations;
see here for more:
https://gunkies.org/wiki/Bus_Arbitration_on_the_Unibus_and_QBUS#QBUS_Interr…
DEC had previously bent themselves into knots trying to solve it on the UNIBUS:
https://gunkies.org/wiki/M782_Interrupt_Control#Revisions
so it would be interesting to know if it was WD or DEC who did the DIN thing to
get rid of it on the QBUS.)
Noel
> Always use '\&' (a non-printing, zero width character) to
> make it clear to the software, that the _function_ of the
> character next to it, is neither a sentence-terminating nor
> a control one.
It is unfortunate that such advice has to be given. One should
not have to defend against stupid AI. This is one of only two
really unfortunate design choices (in my opinion) in original
[nt]roff. (The other is beginning a new page when the vertical
position reaches--as distinct from definitively passing--the
bottom of a page.)
If AI is used, it should be optional. I happen not to like
double-width intersentence space, but it keeps getting foisted
on me essentially at random. Instead of fattening the manual
with annoying duties like that quoted above, I suggest fattening
it with a new request, "turn on/off doubling of spaces between
apparent sentences", or "put at least the specified space
between apparent sentences". One can still use \&, but then
it's for a chosen purpose, not just defense against gremlins.
Incidentally, "next to" in the quoted advice must be read with
care. Sometimes it means before, sometimes after.
------------------------------------------------------------
In this old AI-induced trouble I see a cautionary lesson for
paragraph-based line breaking. fmt(1) is an existing program
that tries to do this. On unjustified text (i.e. all text
handled by fmt) it produces paragraphs of different "optimal"
widths, which can be even more distracting than unusually
ragged right margins.
Doug
All, I was asked by Max to pass this query on to the TUHS list. Can
you e-mail back to Max directly. Thanks, Warren
----- Forwarded message from Maximilian Lorlacks <maxlorlax(a)protonmail.com> -----
Date: Sun, 26 Jan 2020 19:46:38 +0000
From: Maximilian Lorlacks <maxlorlax(a)protonmail.com>
To: "wkt(a)tuhs.org" <wkt(a)tuhs.org>
Subject: Fwd request: Text of Caldera's free licenses for UnixWare/OpenServer
Hi Warren,
Could you please forward this to the TUHS list? I'm not a subscriber
to the list, but I perhaps someone there might know something about
this.
In 2001 and early 2002 (I can't believe it's already been almost two
decades), Caldera Systems, Inc. offered non-commercial licenses at no
cost for OpenServer 5.0.6, UnixWare 7.1(.1?) and Open UNIX 8. However,
the web archive could not to capture the actual agreement hidden behind
the entrypoint form. I failed to get a license during that time since I
wasn't really interested in UNIX at that point, but in the interest of
historical preservation, I'm interested if anyone got those licenses
from back then and if so, if they've saved the actual license agreement
text. I'm interested in what it reads. I'm also curious about whether
the license keys from back then still work with Xinuos's new
registration platform, but it's probably too much to ask for people to
test that.
Please note that I am *not* trying to revive the trainwreck that is
the issue of the validity and scope of the Ancient UNIX license. The
only way to properly resolve that would be a letter signed from Micro
Focus's legal department, but they've made it exceedingly clear that
they will persistently ignore any and all attempts to elicit any kind
of response regarding Ancient UNIX.
Cheers,
Max
----- End forwarded message -----
> It might be worth mentioning that the Cambridge Ring (in the UK) used a very
> similar idea: a head end circulated empty frames which stations could fill in.
I'm quite sure the similarity is not accidental. Fraser began the Spider
project almost immediately upon moving from Cambridge to Bell Labs.
Doug