The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: wes.parish@paradise.net.nz (Wesley Parish)
Subject: [TUHS] Ideas for a Unix paper I'm writing
Date: Wed, 29 Jun 2011 02:18:59 +1200	[thread overview]
Message-ID: <31BD4AA9-40E3-4441-A4A7-757B1B046897@paradise.net.nz> (raw)
In-Reply-To: <20110628041302.GR39651@dereel.lemis.com>

FWIW, the Unix habit of leaving the files as streams, instead of  
diving into the then-current concept of files as either hierarchical  
database or network database files. That left the FILE interface  
simple, and allowed the applications to do all the necessary work.

Then there's Lion's comment about the nearest - at the time -  
competitor for teaching, Brinch Hansen's Solo Concurrent Pascal OS  
and permutations thereof, which he didn't think was anywhere near the  
same standard. I've read the Loin's books and the Concurrent Pascal  
book, and I can see his point. You can do things with Unix V6 that  
you couldn't think of with Solo.

Just my 0.02c,from a Unix latecomer.

Wesley Parish


On 28/06/2011, at 4:13 PM, Greg 'groggy' Lehey wrote:

> On Tuesday, 28 June 2011 at 10:11:40 +1000, Warren Toomey wrote:
>>
>> 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.
>
> The system call interface is one thing, but I'm not sure it's the most
> important one.  Older operating systems (in my experience, IBM OS/360
> and UNIVAC Omega and OS 1100) had similar interfaces.  Omega also had
> the concept of integer file descriptors (including 0, 1 and 2
> preassigned).  All of these systems had open/close/read/write, for
> example.
>
> I came to UNIX relatively late, and my first impression wasn't
> favourable.  It took me a while to realise what the real advantages
> were.  For me, they're:
>
> - Text files.  At the time, any data of any importance was stored in
>   custom-designed file formats.  That was more efficient, both in
>   terms of processing time and space, but it made things difficult if
>   anything went wrong.
>
> - The file system itself.  I think the design of the file system,
>   especially the separation of names and the files themselves, but
>   also special files, is one of the most far-reaching designs I've
>   ever come across.  To this day, I haven't found anything that even
>   comes close.
>
> You might also get some ideas from
> http://en.wikipedia.org/wiki/Unix_philosophy
>
> Greg
> --
> Finger grog at FreeBSD.org for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  See
> http://www.lemis.com/grog/email/signed-mail.php for more details.
> If your Microsoft MUA reports problems, please read
> http://tinyurl.com/broken-mua
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs




  parent reply	other threads:[~2011-06-28 14:18 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
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 [this message]
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=31BD4AA9-40E3-4441-A4A7-757B1B046897@paradise.net.nz \
    --to=wes.parish@paradise.net.nz \
    /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).