20 Dec
2016
20 Dec
'16
2:10 a.m.
From: Warren Toomey
Ritchie, D.M. The UNIX Time Sharing System. MM
71-1273-4.
which makes me think that the draft version Doug McIlroy found
Not really a response to your question, but I'd looked at that
'UnixEditionZero' and was very taken with this line, early on:
"the most important features of UNIX are its simplicity [and] elegance"
and had been meaning for some time to send in a rant.
The variants of Unix done later by others sure fixed that, didn't they? :-(
On a related note, great as my respect is for Ken and Doug for their work on
early Unix (surely the system with the greatest bang/buck ratio ever), I have
to disagree with them about Multics. In particular, if one is going to have a
system as complex as modern Unices have become, one might as well get the
power of Multics for it. Alas, we have the worst of both worlds - the size,
_without_ the power.
(Of course, Multics made some mistakes - primarly in thinking that the future
of computing lay in large, powerful central machines, but other aspects of
the system - such as the single-level store - clearly were the right
direction. And wouldn't it be nice to have AIM boxes to run our browers and
mail-readers in - so much for malware!)
Noel
20 Dec
20 Dec
2:50 a.m.
New subject: Dennis' Draft of the Unix Timesharing System: not so draft?
On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
I've been thinking that there's likely a PhD hiding in building a
Multics-style ring-like abstraction from nested virtual machines; the Dune
work at Stanford took a similar tack, if one squints at it a little bit.
Come to think of it, I always kind of wanted to get a PhD. Maybe that'd be
an interesting research idea. Anyone looking for a student? :-)
From: Warren
Toomey
Ritchie, D.M. The UNIX Time Sharing System. MM
71-1273-4.
which makes me think that the draft version Doug McIlroy found
Not really a response to your question, but I'd looked at that
'UnixEditionZero' and was very taken with this line, early on:
"the most important features of UNIX are its simplicity [and] elegance"
and had been meaning for some time to send in a rant.
The variants of Unix done later by others sure fixed that, didn't they? :-(
On a related note, great as my respect is for Ken and Doug for their work
on
early Unix (surely the system with the greatest bang/buck ratio ever), I
have
to disagree with them about Multics. In particular, if one is going to
have a
system as complex as modern Unices have become, one might as well get the
power of Multics for it. Alas, we have the worst of both worlds - the size,
_without_ the power.
(Of course, Multics made some mistakes - primarly in thinking that the
future
of computing lay in large, powerful central machines, but other aspects of
the system - such as the single-level store - clearly were the right
direction. And wouldn't it be nice to have AIM boxes to run our browers and
mail-readers in - so much for malware!) 
2:59 a.m.
New subject: Dennis' Draft of the Unix Timesharing System: not so draft?
On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
Not really a response to your question, but I'd looked at that
'UnixEditionZero' and was very taken with this line, early on:
"the most important features of UNIX are its simplicity [and] elegance"
and had been meaning for some time to send in a rant.
The variants of Unix done later by others sure fixed that, didn't they? :-(
One of my favorite comparisons and definitions of "bloat" came when I
discovered years ago that the SVR3 >>boot<< system was larger than the V6
kernel.
On a related note, great as my respect is for Ken and Doug for their work
on
early Unix (surely the system with the greatest bang/buck ratio ever),
+1
I have
to disagree with them about Multics. In particular, if one is going to
have a
system as complex as modern Unices have become, one might as well get the
power of Multics for it. Alas, we have the worst of both worlds - the size,
_without_ the power.
Mumble -- Other than one important idea (single-level-store as you said),
I'm not so sure. I think we ended up with most of what was envisioned,
and some of the SW things (like the "continuation" model and how
dyn-linking ended up working in practice) - I think we are ahead of
Multics. Winders more than UNIX (IMO) ended up with the complexity and
bloat and most of the bad ideas without the good. But I think UNIX mostly
was able to stick to what was important (except for the loss of "small is
beautiful" - my rant). Some of the HW idea moved on - Intel picked up
segments and rings. Look at INTEL*64, we use 2 rings and stopped using
using segments because it too hard to program around them --- both proved
to be unusable/impractical when they were released.
(Of course, Multics made some mistakes - primarily in thinking that the
future
of computing lay in large, powerful central machines, but other aspects of
the system - such as the single-level store - clearly were the right
direction.
I agree, and this may yet come back. It's too bad too many of the
younger engineers have not studied it. I was recently reviewing some stuff
from a couple of our younger Linux jockeys and they have re-invented
something like it. I smiled and said -- yes it >>is<< a great idea, but
it has been done.
And wouldn't it be nice to have AIM boxes to run
our browsers and
mail-readers in - so much for malware!)
Indeed.
3:11 a.m.
New subject: Dennis' Draft of the Unix Timesharing System: not so draft?
On Mon, Dec 19, 2016 at 3:59 PM, Clem Cole <clemc(a)ccc.com> wrote:
Yeah. The only remaining vestige of x86 segmentation seems to be FS and GS,
which are often used for thread local storage.
(Of course, Multics made some mistakes - primarily in thinking that the
On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
To be fair, I think some of the complexity is because hardware is more
complex now. It never ceases to amaze me how baroque some of Intel's stuff
has become.
On a related note, great as my respect is for Ken and Doug for their work on
Not really a response to your question, but I'd looked at that
'UnixEditionZero' and was very taken with this line, early on:
"the most important features of UNIX are its simplicity [and] elegance"
and had been meaning for some time to send in a rant.
The variants of Unix done later by others sure fixed that, didn't they?
:-(
One of my favorite comparisons and definitions of "bloat" came when I
discovered years ago that the SVR3 >>boot<< system was larger than the V6
kernel.
early Unix (surely the system with the greatest bang/buck ratio ever),
+1
I have
to disagree with them about Multics. In particular, if one is going to
have a
system as complex as modern Unices have become, one might as well get the
power of Multics for it. Alas, we have the worst of both worlds - the
size,
_without_ the power.
Mumble -- Other than one important idea (single-level-store as you
said), I'm not so sure. I think we ended up with most of what was
envisioned, and some of the SW things (like the "continuation" model and
how dyn-linking ended up working in practice) - I think we are ahead of
Multics. Winders more than UNIX (IMO) ended up with the complexity and
bloat and most of the bad ideas without the good. But I think UNIX mostly
was able to stick to what was important (except for the loss of "small is
beautiful" - my rant). Some of the HW idea moved on - Intel picked up
segments and rings. Look at INTEL*64, we use 2 rings and stopped using
using segments because it too hard to program around them --- both
proved to be unusable/impractical when they were released.
future
of computing lay in large, powerful central machines, but other aspects of
the system - such as the single-level store - clearly were the right
direction.
I agree, and this may yet come back. It's too bad too many of the
younger engineers have not studied it. I was recently reviewing some stuff
from a couple of our younger Linux jockeys and they have re-invented
something like it. I smiled and said -- yes it >>is<< a great idea, but
it has been done.
And wouldn't it be nice to have AIM boxes to
run our browsers and
mail-readers in - so much for malware!)
Indeed.
3:34 a.m.
New subject: Dennis' Draft of the Unix Timesharing System: not so draft?
On Mon, Dec 19, 2016 at 4:11 PM, Dan Cross <crossd(a)gmail.com> wrote:
To be fair, I think some of the complexity is because
hardware is more
complex now. It never ceases to amaze me how baroque some of Intel's stuff
has become.
May the record show - the boot was for the WE32100 - AT&T's "UNIX"
chip-set. My copy of the AT&T book on same show a publication date of
January 1985.
Clem
22 Dec
22 Dec
10:36 p.m.
New subject: Dennis' Draft of the Unix Timesharing System: not so draft?
On 19 Dec 2016, at 20:10, Noel Chiappa
<jnc(a)mercury.lcs.mit.edu> wrote:
On a related note, great as my respect is for Ken and Doug for their work on
early Unix (surely the system with the greatest bang/buck ratio ever), I have
to disagree with them about Multics. In particular, if one is going to have a
system as complex as modern Unices have become, one might as well get the
power of Multics for it. Alas, we have the worst of both worlds - the size,
_without_ the power.
This is slightly tangential, but I think it's fairly hard to take a simple system and
turn it into a complicated system without ending up with a mess (and I claim that modern
Unix is a mess).
I spent a bunch of my life programming in Common Lisp: CL was famously thought of in the
about 1990 as an *extremely* large language with many baroque complexities: the standards
document I think was over a thousand pages, even with lots of things you actually need
missing, and there were features which people regarded as hard to implement efficiently
without special hardware support (they were wrong, but it was a common thing for people to
say at the time).
And whatever CL was it was not particularly pretty or elegant as a language, at least on
the surface: the standards people valued agreement with each other and easy compatibility
with older Lisps over elegance, so there were just lots of things which were there for no
really good reason other than that they had been there in older Lisps.
(Of course 'extremely large & baroque language' means 'a tiny fraction
the size of modern C++', but this was in the early 1990s before the true horror of
C++ had become apparent.)
A lot of people were just derisive about CL: in particular the Scheme people. Scheme was
this tiny and *extremely* elegant language. Programming in Scheme was just nice, because
it was so small: R4RS seems to be 55 pages, including formal semantics and macros, I
can't find R3RS in page-countable form, but it must have been 40 pages or something
(no macros). And tail-call elimination with first-class continuations: all the guilty
pleasure of GO TO without the guilt.
Scheme was just great, except you couldn't do anything useful because it was so
minimal. But apart from that, great.
So now I use Racket which is a sort of Scheme which has eaten too much and read too many
computer science text books. And although it's just an enormously nice language, the
moment you try to use some of its more industrial parts (structures or the object system)
you realise *just how careful the design of those things in CL was*. Nothing about the CL
design was pretty, but it was designed by people who had both used the system themselves
*and talked to many other users*, and addressed the things that made their lives hard.
So, of course, I still program in CL because, though it's ugly as shit, it's
very very sorted out.
So, finally getting to the point: I think it's significantly hard, to take small
elegant systems and turn them into large industrial systems: if you want large industrial,
you need to design for large industrial and not worry too much about elegance. Unix is
kind of the poster child for what happens when you don't do that.
--tim
2921
days inactive
2924
days old
5 comments
4 participants
participants (4)
-
Clem Cole -
Dan Cross -
jnc＠mercury.lcs.mit.edu -
Tim Bradshaw