[TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

[TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

[Warren Toomey]

All, I'm writing a paper based on my June 2016 talk on PDP-7 Unix. As part
of that I was looking at the BCPL -> B -> NB -> C history. And as part of
that, I was reading Ken's B manual, written in 1972:

https://www.bell-labs.com/usr/dmr/www/kbman.pdf

Then I noticed at the end Ken refers to:

	Ritchie, D.M.  The UNIX Time Sharing System.  MM 71-1273-4.

which makes me think that the draft version Doug McIlroy found
(now at http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/UnixEditionZero-Threshold_OCR.pdf)
must have made it into a full memorandum.

Given that we  have the memorandum number, does anybody know if it
would be possible to find it in the archives from what was Bell Labs?

Cheers, Warren

[TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

[Noel Chiappa]

    > 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

[TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

[Dan Cross]

On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > 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!)


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? :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161219/6edbcd20/attachment.html>

[TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2769 bytes --]

On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa <jnc at 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.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161219/0a844aac/attachment-0001.html>

[TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3200 bytes --]

On Mon, Dec 19, 2016 at 3:59 PM, Clem Cole <clemc at ccc.com> wrote:
>
> On Mon, Dec 19, 2016 at 3:10 PM, Noel Chiappa <jnc at 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.
>

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
>> ​ ​
>> 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.
>

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
>> 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.​
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161219/e51dac2e/attachment.html>

[TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

On Mon, Dec 19, 2016 at 4:11 PM, Dan Cross <crossd at 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

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161219/cead2f41/attachment.html>

[TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

[Tim Bradshaw]

> On 19 Dec 2016, at 20:10, Noel Chiappa <jnc at 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