I thought Benno Rice’s argument a bit unorganized and ultimately unconvincing, but I think the underlying point that we should from time to time step back a bit and review fundamentals has some merit. Unfortunately he does not distinguish much between a poor concept and a poor implementation.
For example, what does “everything is a file” mean in Unix?
- Devices and files are accessed through the same small API?
- All I/O is through unstructured byte streams?
- I/O is accessed via a single unified name space? etc.
Once that is clear, how can the concept then best be applied to USB devices?
Or: is there a fundamental difference between windows-style completion ports and completion signals?
Many of the underlying questions have been considered in the past, with carefully laid out arguments in various papers. In my view it is worthwhile to go back to these papers and see how the arguments pro and contra various approaches were weighed then and considering if the same still holds true today.
Interestingly, several points that Benno touches upon in his talk were also the topic of debate when Unix was transitioning to a 32 bits address space and incorporating networking in the early 80’s, as the TR/4 and TR/3 papers show. Of course, the system that CSRG delivered is different from the ambitions expressed in these papers and for sure opinions on the best choices differed as much back then as they will now - and that makes for an interesting discussion.
Rich was kind enough to look through the Joyce papers to see if it contained "CSRG Tech Report 4: Proposals for Unix on the VAX”. It did.
As list regulars will know I’ve been looking for that paper for years as it documents the early ideas for networking and IPC in what was to become 4.2BSD.
It is an intriguing paper that discusses a network API that is imo fairly different from what ended up being in 4.1a and 4.2BSD. It confirms Kirk McKusick’s recollection that the select statement was modelled after the ADA select statement. It also confirms Clem Cole’s recollection that the initial ideas for 4.2BSB were significantly influenced by the ideas of Richard Rashid (Aleph/Accent/Mach).
Besides IPC and networking, it also discusses file systems and a wide array of potential improvements in various other areas.
> If you search for "Jolitz"
Oh, I meant in the DDJ search box, not a general Web search.
> One of the items listed in WP, "Copyright, Copyleft, and Competitive
> Advantage" (Apr/1991) wasn't in the search results .. Since it's not in
> the 'releases' page, it might not really be part of the series?
Also, the last article in the series ("The Final Step") says the series was 17
articles long, not the 18 you get if you include "Copyright".
Noel
>Date: Tue, 07 Jan 2020 14:57:40 -0500.
>From: Doug McIlroy <>
>To: tuhs(a)tuhs.org, thomas.paulsen(a)firemail.de
>Subject: Re: [TUHS] screen editors
>Message-ID: <202001071957.007JveQu169574(a)coolidge.cs.dartmouth.edu>
>Content-Type: text/plain; charset=us-ascii
.. snip ..
>% wc -c /bin/vi bin/sam bin/samterm
>1706152 /bin/vi
> 112208 bin/sam
> 153624 bin/samterm
>These mumbers are from Red Hat Linux.
>The 6:1 discrepancy is understated because
>vi is stripped and the sam files are not.
>All are 64-bit, dynamically linked.
That's a real big vi in RHL. Looking at a few (commercial) unixes I get
SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi
- /usr/bin/vi: iAPX 386 executable
Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi
- /usr/bin/vi: COFF format alpha dynamically linked, demand paged
sticky executable or object module stripped - version 3.13-14
HP-UX 11.31 748996 Aug 28 2009 /bin/vi
-- /bin/vi: ELF-32 executable object file - IA64
I'm trying to grab some stuff from bitsavers.org. It seems to be failing to
lookup name records. I'd send mail directly to Al, but the only address I
have for him at at bitsavers.org :(
Anybody have a better contact or good back-channel to Al?
Warner
I would imagine that the user land changes made its way into 386 Mach. Although I haven't seen anything I can recall off the top of my head about 386 commits in user land until much later.
Maybe one day more of that Mt Xinu stuff will surface, although I'm still amazed I got the kernel to build.
Internet legend is that the rift was massive.
From: TUHS <tuhs-bounces(a)minnie.tuhs.org> on behalf of Larry McVoy <lm(a)mcvoy.com>
Sent: Sunday, January 19, 2020, 12:26 a.m.
To: Greg 'groggy' Lehey
Cc: UNIX Heritage Society
Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question")
On Sat, Jan 18, 2020 at 03:19:13PM +1100, Greg 'groggy' Lehey wrote:
> On Friday, 17 January 2020 at 22:50:51 -0500, Theodore Y. Ts'o wrote:
> >
> > In the super-early days (late 1991, early 1992), those of us who
> > worked on it just wanted a "something Unix-like" that we could run at
> > home (my first computer was a 40 MHz 386 with 16 MB of memory). This
> > was before the AT&T/BSD Lawsuit (which was in 1992) and while Jolitz
> > may have been demonstrating 386BSD in private, I was certainly never
> > aware of it
>
> At the start of this time, Bill was working for BSDI, who were
> preparing a commercial product that (in March 1992) became BSD/386.
Wikipedia says he was working on 386BSD as early has 1989 and that
clicks with me (Jolitz worked for me around 1992 or 3). I don't
remember him mentioning working at BSDI, are you sure about that
part? Those guys did not like each other at all.
Ted Ts'o mentioned Bruce Evans in a reply to "On the origins of
Linux". I'm really sorry to have to announce that he died last month.
His family is holding a "small farewell gathering" in Sydney in late
February. To quote his sister Julie Saravanos:
We would be pleased if you, or any other BSD/computer friend, came
There's no date yet, and I don't think it's appropriate to broadcast
details. If anybody is interested, please contact Warren or me.
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA