[I originally asked the following on Twitter which was probably not the smartest idea]
I was recently wondering about the origins of Linux, i.e. Linux Torvalds doing his MSc and deciding to write Linux (the kernel) for the i386 because Minix did not support the i386 properly. While this is perfectly understandable I was trying to understand why, as he was in academia, he did not decide to write a “free X” for a different X. The example I picked was Plan 9, simply because I always liked it but X could be any number of other operating systems which he would have been exposed to in academia. This all started in my mind because I was thinking about my friends who were CompSci university students with me at the time and they were into all sorts of esoteric stuff like Miranda-based operating systems, building a complete interface builder for X11 on SunOS including sparkly mouse pointers, etc. (I guess you could define it as “the usual frivolous MSc projects”) and comparing their choices with Linus’.
The answers I got varied from “the world needed a free Unix and BSD was embroiled in the AT&T lawsuit at the time” to “Plan 9 also had a restrictive license” (to the latter my response was that “so did Unix and that’s why Linus built Linux!”) but I don’t feel any of the answers addressed my underlying question as to what was wrong in the exposure to other operating systems which made Unix the choice?
Personally I feel that if we had a distributed OS now instead of Linux we’d be better off with the current architecture of the world so I am sad that "Linux is not Plan 9" which is what prompted the question.
Obviously I am most grateful for being able to boot the Mathematics department’s MS-DOS i486 machines with Linux 0.12 floppy disks and not having to code Fortran 77 in Notepad followed by eventually taking over the department with X-Terminals based on Linux connected to the departmental servers (Sun, DEC Alpha, IBM RS/6000s). Without Linux they had been running eXeed (sp?) on Windows 3.11! In this respect Linux definitely filled in a huge gap.
Arrigo
Hi,
Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix?
I had largely dismissed it until a recent conversation in a newsgroup.
I learned that shelling out of programs also increments the shell level.
I.e. :shell or :!/bin/sh in vim.
Someone also mentioned quickly starting a new sub-shell from the current
shell for quick transient tasks, i.e. dc / bc, mount / cp / unmount,
{,r,s}cp, etc., in an existing terminal window to avoid cluttering that
first terminals history with the transient commands.
That got me to wondering if there were other uses for shell level
($SHLVL). Hence my question.
This is more about using (contemporary) shells on Unix, than it is about
Unix history. But I suspect that TUHS is one of the best places to find
the most people that are likely to know about shell level. Feel free to
reply to COFF if it would be better there.
--
Grant. . . .
unix || die
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