The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jcapp@anteil.com (Jim Capp)
Subject: [TUHS] Ideas for a Unix paper I'm writing
Date: Mon, 27 Jun 2011 23:36:17 -0400 (EDT)	[thread overview]
Message-ID: <32496006.7412.1309232177333.JavaMail.root@zimbraanteil> (raw)
In-Reply-To: <20110628001140.GA23711@minnie.tuhs.org>

Warren,

In regard to Unix, the most important revelations to me personally are:

1) detailed documentation of every aspect of the system - Having instant access to consistent documentation on commands, system calls, libraries, and the bit level formats of inodes, directory structures, and the filesystem, was a revelation both in terms of productivity and expanse of knowledge.

2) uniform device handling - Rendering all I/O as a stream of bytes, without regard to content or record sizes, provided a universal foundation for data exchange among heterogenous devices.

3) pipelining - In my opinion, this is the computing equivalent to the invention of interchangeable parts.  Many programming tasks could be completed by the successive processing of a stream of data by a series of small but well defined set of utility programs.

4) C - Writing 90% of the system in a "portable assembler" reduced the cost of implemention on new architectures by a magnitude.

For these reasons, I jumped on board and Unix became a central part (if not the foundation) of my career in software development.


I'm sure you've read these at one time or another, but here are a few of my favorites. Some of them might help you chase down the quotes you are looking for:

Excerpt from UNIX Time-Sharing System: UNIX Implementation, By K. Thompson, The Bell System Technical Journal, Vol. 57, No. 6, July-August 1978, pp. 1931:

"The kernel is the only UNIX code that cannot be substituted by a user to his own liking.  For this reason, the kernel should make as few real decisions as possible.  This does not mean to allow the user a million options to do the same thing.  Rather, it means to allow only one way to do one thing, but have that way be the least-common divisor of all the options that might have been provided."


Excerpt from UNIX Time-Sharing System: A Retrospective, By D. M. Ritchie, The Bell System Technical Journal, Vol. 57, No. 6, July-August 1978, pp. 1948:

"UNIX was never a 'project'; it was not designed to meet any specific need except that felt by its major author, Ken Thompson, and soon after its origin by the author of this paper, for a pleasant environment in which to write and use programs."


Excerpt from The UNIX Programming Environment, By Brian W. Kernighan & Rob Pike, Prentice-Hall 1984, pp. viii:

"Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well.  Instead, what makes it effective is an approach to programming, a philosophy of using the computer.  Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves.  Many UNIX programs do quite trivial tasks in isolation, but, combined with other programs, become general and useful tools."


Finally, attached is a .png of a collage that I had intended to put together for the 40th Anniversary of UNIX last year.  I hope that you find it interesting at least.

Cheers,

Jim



----- Original Message -----
From: "Warren Toomey" <wkt@tuhs.org>
To: tuhs at tuhs.org
Sent: Monday, June 27, 2011 8:11:40 PM
Subject: [TUHS] Ideas for a Unix paper I'm writing

All, IEEE Spectrum have asked me to write a paper on Unix to celebrate the
40th anniversary of the release of 1st Edition in November 1971. I'm after
ideas & suggestions!

I think my general thrust is that Unix is an elegant design, and the
design elements are still relevant today. The implementation is mostly
irrelevant (consider how much the code has changed from assembly -> C,
from the simple data structures in V7 through to current BSD), but the
original API is classic. Note that about 28 of the 1st Ed syscalls are
retained in current BSDs and Linux, and with the same syscall numbers.

I'm having some trouble thinking of the right way to explain what is
an elegant design at the OS/syscall level, so any inspirations/ideas
would be most welcome. I might highlight a couple of syscall groups:
open/close/read/write, and fork/exec/exit/wait.

If you have any references/URLs you think I should look at, please
pass them on to me.

I'm also trying to chase down some quotes; my memory seems to be failing me
but I'm sure I've seen these somewhere:

 - in a paper, I think by Thompson & Ritchie, where they assert that the
   kernel should provide no more than the most minimal services to the
   userland programs. I thought this was the CACM paper, but I can't spot
   this bit. Maybe it's in Thompson's preface to the Lions Commentary,
   of which my copy is elsewere at present.

 - I'm sure I remember someome (Kernighan?) say that Ritchie encouraged
   them to espouse the use of processes as context switching was cheap,
   but later measurements showed that in fact it wasn't that cheap in
   the early versions of Unix.

Anyway, if you can think of good ideas/references about the elegance of
Unix, especially from the design perspective, I would much appreciate them.

Cheers,
	Warren 
_______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CACM-collage.png
Type: image/png
Size: 437184 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20110627/95f3b43a/attachment.png>


  parent reply	other threads:[~2011-06-28  3:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-28  0:11 Warren Toomey
2011-06-28  0:26 ` Larry McVoy
2011-06-28  0:32 ` Nick Downing
2011-06-28  1:00 ` Tim Newsham
2011-06-28  3:36 ` Jim Capp [this message]
2011-07-02  4:03   ` Warner Losh
2011-08-07 20:26   ` Alan D. Salewski
2011-09-02 18:33     ` Jose R. Valverde
2011-06-28  3:53 ` Jim Capp
2011-06-28  4:13 ` Greg 'groggy' Lehey
2011-06-28  5:48   ` Nick Downing
2011-06-28  7:22     ` Tim Newsham
2011-06-28 14:18   ` Wesley Parish
2011-06-28  7:32 ` Wilko Bulte
2011-06-28 15:22 ` Al Kossow
2011-06-29  1:30 A. P. Garcia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32496006.7412.1309232177333.JavaMail.root@zimbraanteil \
    --to=jcapp@anteil.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).