We lost a co-inventor of ENIAC, John Mauchly, on this day in 1980. ENIAC
is claimed to be the "first general purpose electronic digital computer",
but I guess it comes down to a matter of definition[*], as every culture
likes to be the "first" (just ask the Penguins, for example); for
"computer" you could go all the way back to the Mk-I Antikythera (Hellenic
variation, from about the 100BC production run)...
[*]
Analogue/digital/hybrid
Mechanical/electrical/electronic/hybrid
General/special
Wired/programmable/Turing
Prototype/production
Harvard/Neumann/quantum
Etc...
-- Dave
Augusta Ada King-Noel, Countess of Lovelace, was lost to us in 1852 from
uterine cancer. Regarded as the first computer programmer and a
mathematical prodigy (when such things were unseemly for a mere woman),
she was the daughter of Lord Byron, and a friend of Charles Babbage.
-- Dave
A replica of EDSAC, the Electronic Delay Storage Automatic Calculator, was
switched on at Bletchley Park on this day in 2014; EDSAC was the first
practical general purpose stored program electronic computer (and how's
that for hair-splitting?).
-- Dave
(I decided it was more suitable for COFF instead of TUHS (but sadly the
membership does not overlap much.)
https://en.wikipedia.org/wiki/Leonard_Kleinrock#ARPANET
``The first permanent ARPANET link was established on November 21, 1969,
between the IMP at UCLA and the IMP at the Stanford Research Institute.''
And thus from little acorns...
-- Dave
> From: Grant Taylor
> Thank you for the reply
Sure; I love to yap about stuff like this.
> I occasionally bump into some Multicians and am always pleasantly
> surprised at how different their world is.
Yes, it's very unlike most of what's been done since. Some of it (e.g. a
strictly ordered set of rings for protection) was wrong, but there's a lot of
good stuff there yet to be mined.
>> Which is a pity, because when done correctly (which it was - Intel
>> hired Paul Karger to architect it)
Ooops, it was Roger Schell, I get them mixed up all the time. His oral
history, here:
https://conservancy.umn.edu/handle/11299/133439
is a Must Read.
>> it's just what you > need for a truly secure system (which Multics also
>> had) - but that's another long message.
> If you're ever feeling bored and would like to share that story.
OK, soon.
> From: Bakul Shah
> All of this would be easily possible on the Mill arch. if ever it gets
> built. Mill has segments and protected function calls.
What I found about that mostly talked about the belt stuff. Do you happen to
have a pointer to the segment/call stuff?
> set-uid has its own issues. Plan9 doesn't have it.
Ah, what were the issues (if you happen to know)?
Noel
> From: Grant Taylor
>> as an operating system person, I was, and remain, a big fan of Multics
>> ... which I still think was a better long-term path for OSes (long
>> discussion of why elided to keep this short).
> Can I ask for the longer discussion?
Sure. (Note that I'm not on COFF, so if anyone replies, please make sure I'm
CC'd directly.)
Basically, it boils down to 'monolithic OS's are bad' - for all the reasons
laid out in the usual ukernel places (I first saw them in the BSTJ MERT
paper, IIRC).
{What follows is not the crispest way to explain it; sorry. I didn't feel like
deleting it all and re-writing to get straight to the point, which is 'Multics
had many of the advantages of a ukernel - and a long time before the ukernel
idea arrived - but without the IPC overhead, which seems to be the biggest
argument against ukernels'.}
Now, early UNIX may have done pretty well in a _tiny_ amount of memory (I
think our -11/40 V6 had about 64KB of main memory _total_, or some such
ridiculous number), and to do that, maybe you have to go monolithic, but
monolithic is pretty Procrustean.
This was brought home to me in doing early TCP/IP work on PDP-11 Unix. The
system was just not well suited to networking work - if what you wanted to do
didn't fit into the UNIX model, you were screwed. Some people (e.g. BBN) did
TCP as a process (after adding IPC; no IPC in UNIX, back then), but then
you're talking a couple of process switches to do anything.
I looked at how Dave Clark was doing it on Multics, and I was green with envy.
He added, debugged and improved his code _on the running main campus system_,
sharing the machine with dozens of real users! Try doing that on UNIX
(although nowadays it's getting there, with loadable kernel stuff - but this
was in the 70's)!
To explain how this was even possible, you need to know a tiny bit about
Multics. It was a 'single level store' system; process memory and files were
not disjoint (as in UNIX), there were only segments (most of which were
long-lived, and survived reboots); processes had huge address spaces (up to
2^18 segments), and if you needed to use one, you just mapped it into your
address space, and off you went.
So he wrote his code, and if I in my command process executed the 'TELNET'
command, when it needed to open a TCP connection, it just mapped in his TCP
code, and called TCP$open() (or whatever he named it). It fiddled around in
the networking state (which was in a data segment that Dave had set up in his
'networking' process when it started up), and set things up. So it was kind of
doing a subroutine call to code in another process.
The security wasn't good, because Multics didn't have set-uid (so that only
Dave's code would have had access to that state database) - when they later
productized the code, they used Multics rings to make it secure.
But still, that was pretty amazing. The key thing here is that nobody had to
modify the Multics 'kernel' to support adding networking - the basic
mechanisms (the single-level store, etc) were so powerful and general you
could write entirely new basic things (like networking) and add them 'on the
fly'.
What Multics had was quite different from ukernels, but it amounted to the
same thing; the system wasn't this monolithic blob, it was
layered/modularized, and you could see (and gain access to, and in some cases
replace - either just for yourself, or for everyone) the layers/modules.
The nice thing was that to call up some subsystem to perform some service for
you, you didn't have to do IPC and then a process switch - it was a
_subroutine call_, in the CPU's hardware.
I don't think anyone else ever tried to go down that path as a way to
structure an operating system (in part because you need hardware support), and
it's a pity. (UNIX, which would run on anything, killed just about _everything
else_ off.)
The 386-Pentium actually had support for many segments, but I gather they are
in the process of deleting it in the latest machines because nobody's using
it. Which is a pity, because when done correctly (which it was - Intel hired
Paul Karger to architect it) it's just what you need for a truly secure system
(which Multics also had) - but that's another long message.
Noel
On this day in 1970 computer pioneer Douglas Engelbart was awarded the
patent for the computer mouse. It was a fugly thing: just a squarish box
with two wheels underneath it mounted at right-angles and a button.
Ergonomic it wasn't...
-- Dave
For some reason, I have in my calendar for today:
VMS Epoch
http://h41379.www4.hpe.com/wizard/wiz_2315.html
Epoch of the Smithsonian Astrophysical Observatory, and is Julian Day
2400000 (to allow date to fit into a 36-bit word on the IBM 704).
When I visited that page, NoScript went bersek...
-- Dave
On 11/16/2018 12:29 PM, Noel Chiappa wrote:
> _That_ is what made me such a huge fan of Unix, even though as an
> operating system person, I was, and remain, a big fan of Multics (maybe
> the only person in the world who really likes both :-), which I still
> think was a better long-term path for OSes (long discussion of why elided
> to keep this short).
Can I ask for the longer discussion? It sounds like an enlightening
sidebar that would be good to have over a cup of COFFee. Maybe the
barista on the COFF mailing list will brew you a cup to discuss this
there. ~wink~wink~nudge~nudge~
--
Grant. . . .
unix || die
