All, I've had a fair bit of positive feedback for my TUHS work. In reality
I'm just the facilitator, collecting the stuff that you send me and keeping
the mailing list going.
I think we've captured nearly all we can of the 1970s Unix in terms of
software. After that it becomes commercial, but I am building up the
"Hidden Unix" archive to hold that. Just wish I could open that up ...
What we haven't done a good job yet is to collect other things: photos,
stories, anecdotes, scanned ephemera.
Photos & scanned things: I'm very happy to collect these, but does anybody
know of an existing place that accepts (and makes available online) photos
and scanned ephemera? They are a bit out of scope for bitsavers as far as
I can tell, but I'm happy to be corrected. Al? Other comments here?
Stories & anecdotes: definitely type them in & e-mail them in and/or e-mail
them to me if you want me just to preserve them. There is the Unix wiki I
started here: https://wiki.tuhs.org/doku.php?id=start, but maybe there is
already a better place. Gunkies?
Interviews: Sometimes it's easier to glean stories & knowledge with interviews.
I've never tried this but perhaps it's time. Who is up to have an audio
interview? I'll worry about the technical details eventually, but is there
interest?
All of the above would slot in with the upcoming 50th anniversary. If you
do have photos, bits of paper, stories to tell etc., then let's try to
preserve them so that they are not lost.
Cheers all, Warren
> From: "John P. Linderman"
> 4 bucks a bit!
When IBM went to license the core patent(s?) from MIT, they offered MIT a
choice of a large lump sump (the number US$20M sticks in my mind), or US$.01 a
bit.
The negotiators from MIT took the lump sum.
When I first heard this story, I thought it was corrupt folklore, but I later
found it in one of the IBM histories.
This story repets itself over and over again, though: one of the Watson's
saying there was a probably market for <single-digit> of computers; Ken Olsen
saying people wouldn't want computers in their homes; etc, etc.
Noel
[ A few list members asked me to re-post this out of the existing
thread, so that it is more prominent. ]
All, based on the comments we've had in the past day or so, it seems that
you are mostly happy to stick with one list, and to tolerate a bit of
off-topic material.
I'm also aware that this list is approaching its own quarter-century
anniversary and it has become an important historical record.
So feel free to drift away from Unix now and then. But please self-regulate:
if you (as an individual) think the S/N ratio is dropping, please ask the
list to improve it.
As always, I'll insert my own nudges and requests based on my own eclectic
set of rules :-)
Cheers all, Warren
Because some "off-topic" discussions wander into estoterica that's beyond
me, I superficially thought an off-topic siding would be a good thing for
some trains of thought. But then I wondered, if I ignore the siding how
will I hear of new hear about new topics that get initiated there? I could
miss good stuff. So I'm quite happy with the current arrangement where
occasionally ever-patient Warren gives a nudge. (I'm a digest reader. If
every posting came as a distinct message, I might feel otherwise.)
Doug
> From: "Erik E. Fair"
> ordered a VAX-8810 to replace two 11/780s on the promise from DEC that
> all our UniBus and MASSbus peripherals would still work ... which we
> knew (from others on the Internet who'd and tried reported their
> experiences) to be a lie.
Just out of curiousity, why'd you all order something you knew wouldn't work?
So you could get a better deal out of DEC for whatever you ordered instead,
later, as they tried to make it up to you all for trying to sell you something
broken?
Noel
> From: Warren Toomey
> Computing history is maybe too generic.
There already is a "computer-history" list, hosted at the Postel Institute:
http://www.postel.org/computer-history/
Unlike its sibling "Internet-history" list, it didn't catch on, though. (No
traffic for some years now.)
Noel
> From: Tim Bradshaw
> There is a paper, by Flowers, in the Annals of the History of Computing
> which discusses a lot of this. I am not sure if it's available online
Yes:
http://www.ivorcatt.com/47c.htm
(It's also available behind the IEEE pay-wall.) That issue of the Annals (5/3)
has a couple of articles about Colossus; the Coombs one on the design is
available here:
http://www.ivorcatt.com/47d.htm
but doesn't have much on the reliability issues; the Chandler one on
maintenance has more, but alas is only available behind the paywall:
https://www.computer.org/csdl/mags/an/1983/03/man1983030260-abs.html
Brian Randell did a couple of Colossus articles (in "History of Computing in
the 20th Century" and "Origin of Digital Computers") for which he interviewed
Flowers and others, there may be details there too.
Noel
Tim Bradshaw <tfb(a)tfeb.org> commented on a paper by Tommy Flowers on
the design of the Colossus: here is the reference:
Thomas H. Flowers, The Design of Colossus, Annals of the
History of Computing 5(3) 239--253 July/August 1983
https://doi.org/10.1109/MAHC.1983.10079
Notice that it appeared in the Annnals..., not the successor journal
IEEE Annals....
There is a one-column obituary of Tommy Flowers at
http://doi.ieeecomputersociety.org/10.1109/MC.1998.10137
Last night, I finished reading this recent book:
Thomas Haigh and Mark (Peter Mark) Priestley and Crispin Rope
ENIAC in action: making and remaking the modern computer
MIT Press 2016
ISBN 0-262-03398-4
https://doi.org/10.7551/mitpress/9780262033985.001.0001
It has extensive commentary about the ENIAC at the Moore School of
Engineering at the University of Pennsylvania in Philadelphia, PA. Its
construction began in 1943, with a major instruction set redesign in
1948, and was shutdown permanently on 2 October 1955 at 23:45.
The book notes that poor reliability of vacuum tubes and thousands of
soldered connections was a huge problem, and in the early years, only
about 1 hour out of 24 was devoted to useful runs; the rest of the
time was used for debuggin, problem setup (which required wiring
plugboards), testing, and troubleshooting. Even so, runs generally
had to be repeated to verify that the same answers could be obtained:
often, they differed.
The book also reports that reliability was helped by never turning off
power: tubes were more susceptible to failure when power was restored.
The book reports that reliability of the ENIAC improved significantly
when on 28 April 1948, Nick Metropolis (co-inventor of the famous
Monte Carlo method) had the clock rate reduced from 100kHz to 60kHz.
It was only several years later that, with vacuum tube manufacturing
improvements, the clock rate was eventually moved back to 100Khz.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Tim Bradshaw wrote:
"Making tube (valve) machines reliable was something originally sorted out by Tommy Flowers, who understood, and convinced people with some difficulty I think, that you could make a machine with one or two thousand valves (1,600 for Mk 1, 2,400 for Mk 2) reliable enough to use, and then produced ten or eleven Colossi from 1943 on which were used to great effect in. So by the time of Whirlwind it was presumably well-understood that this was possible."
"Colossus: The Secrest of Bletchley Park's Codebreaking Computers"
by Copeland et al has little to say about reliability. But one
ex-operator remarks, "Often the machine broke down."
Whether it was the (significant) mechanical part or the electronics
that typically broke is unclear. Failures in a machine that's always
doing the same thing are easier to detect quickly than failures in
a mchine that has a varied load. Also the task at hand could fail
for many other reasons (e.g. mistranscribed messages) so there was
no presumption of correctness of results--that was determined by
reading the decrypted messages. So I think it's a stretch to
argue that reliability was known to be a manageable issue.
Doug
