can someone point me at the earliest version of whereis? I first saw
it in 4.1, but maybe it came sooner. Also, if you've got a link to man
pages, thanks in advance.
I'm trying but failing to find it. My daughter says I suck at web
search, which, given where I work, is a bid sad :-)
> From: Rich Morin <rdm(a)cfcl.com>
> I'd love to hear from some folks who have used both Multics and
> Unix(ish) systems about things that differ and how they affect the
> user experience.
{This is a bit behind the flow of the conversation, because I wanted to
ponder for a while what I was going to say on this, to me, important topic.}
Technicaly, I don't quite qualify (more below), but I do have an interesting
perspective: I was the very first Unix person in the 'Multics' group at
MIT-LCS - the Computer Systems Group, which contained Corby and Jerry Saltzer.
The interesting thing, which may surprise some people, is that I _never_ got
any 'anti-Unix' static from anyone in the group, that I can remember. (Maybe
one grad student, who was a bit abrasive, but he and I had a run-in that was
mostly? caused by my fairly rapid assumption, as an un-paid undergrad, of a
significant role in the group's on-going research work. So that may have bled
across a bitt, to Unix, which was 'my' baby.)
I'm not sure what _they_ all made of Unix. None of us knew, of course, where
it was going to go. But I don't recall getting any 'oh, it's just a toy
system' (an attitude I'm _very_ familiar with, since it was what the TCP/IP
people got from _some_ members of what later became the ISO effort). Of
course, our Unix was a tiny little PDP-11/40 - not a building-sized
multi-processor 'information utility' mainframe - so they may well have not
thought of it in the same frame as Multics. Also, by the time I arrived the
group was doing nothing on Multics (except below); everyone was focused on
networks. So OS's were no longer a topic of much research interest, which may
also have contributed.
Anyway, technically, I don't count for the above, because I never actualy
wrote code on Multics. However, I had studied it extensively, and I worked
very closely with Dave Clark (a younger Multics light, later a leading figure
in the early TCP/IP work) on projects that involved Multics and my machine,
so I got to see up close what Multics was like as a system environment, as he
worked on his half of the overall project. I've also pondered Multics in the
decades since; so here's my take.
I really, really liked Unix (we were running what turns out to have been
basicaly a PWB1 system - V6, with some minor upgrades). I learned about it
the way many did; I read the manuals, and then dove into the system source
(which I came to know quite well, as I was tasked with producing a piece that
involved a major tweak - asynchronous 'raw' DMA I/O directly to user
processes).
Unfortunately, one of the two (to me) best things about Unix, is something it
has since lost - which is its incredible bang/buck ratio - to be more
precise, the functionality/complexity ratio of the early versions of the
system.
(Its other important aspect, I think, was that its minimal demands of the
underlying hardware [unlike Multics, which was irretrievably bound to the
segmentation, and the inter-segment data and code connection] along with its
implementation in what turned out to be a fairly portable language (except
for the types; I had to make up what amounted to new ones.)
So, what was Multics' major difference from other systems - and why
was it good?
I'd say that it was Multics' overall structuring mechanisms - the
single-level store, with the ability to have code and data pointers between
segments - and what that implied for both the OS itself, and major
'applications' (some of them part of the OS, although not the 'kernel' - like
networking code).
Unix had (and still may have, I'm not up on Linux, etc) a really major, hard
boundary beween 'user' code, in processes,and the kernel. There are
'instructions' that invoke system primitives - but not too many, and limited
interactions across that boundary. So, restricted semantics.
Which was good in that it helped keep the system simple and clear - but it
limited the flexibilty and richness of the interface. (Imagine building a
large application which had a hard boundary across the middle of it, with
extremely limited interactions across the boundary. Just so with the
interface in Unix between 'user' code, and the kernel.)
Multics is very different. The interface to the OS is subroutine calls, and
one can easily pass complex data structures, including pointers to other
data, any of which can be in the 'user's' memory, as arguments to them. The
_exact_ same _kind_ of interface was available to _other_ major subsystems,
not just the OS kernel.
As I've mentioned before, Dave's TCP/IP for Multics was not in the kernel -
it was ordinary user code! And he was able to work on it, test and install
new versions - while the system was up for normal useage!
Dave's TCP/IP subsystem included i) a process, which received all incoming
ackets, and also managed/handled a lot of the timers involved (e.g.
retransmission timeouts); ii) data segment(s), which included things like
buffered un-acknowledged data (so that if a retransmission timer went off,
the process would wake up and retransmit the data); iii) code segment(s):
iiia) some for use by the process, like incoming packet processing; iiib)
some which were logically part of the subsystem, but which were called by
subroutine calls from the _user_'s process; and iiic) some which were
commands (called by the user's shell), which called those iiib) procedures.
(There were issues in security because Multics didn't have the equivalent of
'set-user-id' on a cross-subsystem subroutine calls - although I think there
had been plans early on for that. When Dave's code was taken over by
Honeywell, for 'production' use, whole whole thing was moved into a lower
ring, so the database didn't have to be world-writeable in the user ring.)
This is typical of the kind of structure that was relatively easy to build in
Multics. Yes, one can do similar application without all those underlying
mechanism; but Turing-completeness says one doeesn't need stacks to compute
anything - but would any of us want to work in a system that didn't have
stacks? We have stacks because they are useful.
True, simple user applications don't need all that - but as one builds more
and more complex support subsytems, that kind of environment turns out to be
good to have. Think of a window system, in that kind of environment. Those
'tools' (inter-segment subroutine calls, etc) were created to build the OS,
but they turned out to be broadly useful for _other_ complicated subsystems.
I'm not sure I've explained this all wel, but I'm not sure I can fully
cover the topic with less than a book.
Noel
I personally lost two friends and former colleagues recently that these
list probably wants to know about.
I just heard from Lynne Jolitz, Bill's wife. It seems he passed away
about a month ago after a long illness. Most of you know he was the
original force behind the BSD 386 development. I know little more than
what I have just reported at this time, but will pass on any info as I
learn it.
Also in other news, not Unix related, but PDP-11 and the computer graphics
world. We lost Jack Burness a few weeks ago. Jack was the author of the
original "Moonlander" for the PDP-11 with which many of us wasted many
hours trying to pick up "a Big Mac with fries" at "Mare Assabet." [Note: There
was no WWW/Wikipedia in those days to find it, but to look up Assabet
River, so many people naively thought it was a legitimate lunar landmark -
its the River that the DEC Maynard bldg sits]. He was a larger than life
person [his joke's mailing list was a whos-who of the computer industry -
it was an honor to be on it]. We all have a passel of stories about Jack.
I have written separately about Jack a number of times and if you have
never looked at the source to Moonlander, you own it yourself to read it.
Remember he wrote it as a throw-away demo for the GT-40 for trade show [his
integer transcendental funcs are quite instructive]. As one of the folks
on the Masscomp Alumni list put it, 'Jack was someone that just does not
deserve to die.'
This is the announcement Maureen published in the DEC Alumni list.
************************** January 20, 2022 ********************************
Our sincere condolences to Maureen Burness and all friends in CXO and
elsewhere on the passing of her husband, *Jack Burness*, 75, Colorado
Springs, who left us on January 20, 2022. Maureen said: With his bigger
than life personality, humor, and intellect, he was loved and respected by
so many people, including his devoted family. Born in Brooklyn, NY in 1946,
he received his Engineering Degree from Brooklyn Polytechnic Institute and
was employed by DEC, Maynard in the early days and then here in Colorado
Springs. Many of you knew he had a huge appetite for the outdoors of
Colorado and Martha’s Vineyard and joined him in his sometimes-disastrous
adventures.
I came across this talk that, apparently, was meant to be part of a
documentary about timesharing systems at MIT:
https://www.youtube.com/watch?v=KZPYBDA6XVo
This "episode" features McCarthy, Corbato, Fano, Fredkin, and Philip Morse
talking about Multics.
Starting at ~12:15m they talk about the triumvirate of MIT, GE and Bell
Labs and some of the challenges with distributed work. Around the 14 minute
mark, they talk about Bell Labs exiting the project, and touch briefly on
the development of Unix. Interesting quotes include Fano talking about
different objectives from the different organizations, Corby saying, "they
[Bell Labs] dropped out three-quarters of the way through the race"
(referring to Multics), Fano asserting that BTL left after the _research_
part of the project was essentially completed, and Corbato talking about
the influence of Multics on Unix design (Corby refers to Multics as Ken and
Dennis's "prototype" and calls Unix a "second generation Multics"). This
was all shot in the early 1980s.
The rest is interesting, but mostly unrelated to Unix.
- Dan C.
(PS: As an aside, Fano lighting up a cigarette at about 19:20 was
particularly striking: my, how times have changed.)
> From: Clem Cole
> Not to put too fine a point on it, It seems like it would be fair to
> say Multics was 'complete' by the time Organick published his book
This is a pretty ill-judged claim, IMO - but not for any particulars about
the Organick book, etc. The problem is more global.
When was UNIX 'complete' - when the first people were able to do real work on
the PDP-7? When non-programmer clerks from the patent group were able to use
the assembler UNIX on the PDP-11 to format parent documents? When it was
re-written in C for the 4th Edition (since the _portability_ of UNIX was IMO
perhaps the greatest factor in its eventual domination)? Etc, etc, etc.
The exact same problem applies to the question of 'when was Multics
'complete''.
> don't know when it first appeared and can not seem to find it. ... I
> bet I have the 3rd printing. ... Anyone have a first edition around
> with the publication date?
The third printing _is_ the first edition. Anyway, it doesn't matter - see
above. And of course even if the book _wriring_ was finished at time T, it
wouldn't have been printed until some unknown time later. So that's really
pretty useless as a temporal marker; we have much better ones availablw.
> From: Dan Cross
> I can't see any indication that this is anything other than the first
> printing.
My 3rd printing says 3rd was 1980, 2nd in 1976, and copyright 1972.
> Organick's book is often said to describe an earlier version of the
> system
Yes; I'm not sure if the version described in it was ever available for
general usege (which could be my definition of 'complete') - or even usage my
Multics system programmers. I don't remember all the details of the
differences (it's been way too long since I read it, and I don't know the
details of the 'first operational' Multics well enough), but for instance:
ISTR that it describes a version which had a linkage segment (holding
intermediate locations in outbound links - since segment >a>b>c might well
have different segment numbers assigned to it in the address spaces of
processes X and Y, so one copy of >a>b>c, shared between X and Y, couldn't
contain direct outbound links) _per segment_ (data or code) - but operational
Multics (I don't know if this is from 'first available to users', or 'first
available to Multics system programmers', or what) collapsed all the linkage
info into a 'combined linkage segment', in which the linkage info from all
the segments in a process' address space were combined (by copying) into a
single linkage segment.
Etc, etc, etc.
> I understand that Multics got much better after the move to the 6180
I'm not sure that the 6180 made that big a difference to the environment the
average use saw. My understanding (not having been there) was that the big
_architectural_ difference was that cross-ring inter-segment references were
done and monitored in hardware, so a host of security holes caused by
insufficient checking of cross-ring inter-segment pointers were caught
automatically. (The 6180 was also built out of SSI chips, unlike the 645 which
was individual transistors, like a KA10.)
Noel
So this is weird. My publisher contacted me this week asking for permission
to send a copy of my book to these folks: https://archiveprogram.github.com/
Hadn't heard of them before. Looks like they're filling their archive with
stuff from github which means that most of the stuff being preserved by TUHS
is likely not there. Might be a good idea to see if it can be included. I
have no contact with these folks but can probably get a contact from my
publisher if this is something that y'all think is worth doing.
Jon
> Does {Reiser's bitblt replacement] exist for the rest of us to study?
A not-very-thorough search at tuhs turned up V9/jerq/src/lib/j/bitblt.c
It appears to be a pre-Reiser bitblt, not what was asked for. But
weighing in at over 800 lines of C, it vivifies the challenge that
Reiser met in half the space.
Doug
The recent discussion about Research choosing BSD's paging over
Reiser-London's brought to mind a stunning program by Reiser that
Research did adopt.
A critical primitive in the Blit terminal was bitblt (block transfer
of a rectangular area). It was used ubiquitously, for example to
refresh data when window-stacking changed, to move data within a
window, or to pop up a menu.. The display memory was word-oriented, so
bitblt was fraught with niggling details about bit alignment and
overlap of source and destination. A general bitblt subroutine was a
rats' nest of conditionals--grossly inefficient for important special
cases like scrolling.
Bitblt got refined (i.e. elaborated) several times before Reiser did
away with it entirely. Instead he wrote a just-in-time generator of
optimal code. Thousands of distinct variants, which varied in size
from 16 to 72 bytes, could be produced by the same 400 lines of
assembler code.
Doug
> From: Clem Cole
> Ward had a nice history here: TecoEditor
> <http://c2.com/wiki/remodel/?TecoEditor> - worth reading
Yeah, pretty good. A couple of minor points:
"TECO Madness -- a moment of convenience, a lifetime of regret" - I
have seen this attributed to Dave Moon.
"the [ITS] version of TECO was used by Richard Stallman to implement the
original Emacs Editor" - accurate if read _just_ the right way, but incorrect
in the 'naive' reading.
Stallman didn't _originate_ the body of stuff that eventually turned into ITS
EMACS, although he did take over maintenance of it once it was rolling; and
later wrote Gnu Emacs from scratch himself.
The mostly accurate one-line history is the one given in Dan Weinreb's blog
"the original (TECO-based) Emacs was created and designed by Guy L. Steele
Jr. and David Moon. After they had it working, and it had become established
as the standard text editor at the AI lab, Stallman took over its
maintenance", to which Moon added "in all fairness I have to say that
Stallman greatly improved Emacs after he 'liberated' it from Guy and me".
More people were involved than Moon, Steele and Stallman, though; a lot of
people were writing stuff before Stallman took over; and even after that,
others (like Eugene Ciccarelli, a member of the CSR group) helped a lot with
ITS EMACS.
Stallman's EMACS paper ("sEMACS: The Extensible, Customizable,
Self-Documenting Display Editor") contains _many_ statements that are
_demonstrably_ wrong, e.g. "it is simply impossible to implement an extensible
system in [languages like PASCAL or C]" ... "This eliminates most popular
programming languages except LISP, APL and SNOBOL." Given that I've been using
a heavily customized Epsilon for decades, which is written completely in EEL
(a dialect of C enhanced with editing primitives like buffers, etc), that's
clerly very confused.
Noel
> From: George Michaelson
> Teco was painful.
Some of us can recall when the _only_ choices for editing on UNIX (on the
PWB1 systems at MIT) were 'ed' and TECO!
But to add some real history (not just the usual low S/N flaming about
people's opinions of various relatively recent software, which is way too
common on this list), the guys at MIT in DSSR/RTS (the group which later did
the 68K version of PCC), who had done the port of PDP-11 TECO (in MACRO-11)
from the Delphi system at MIT (which preceded adoption of UNIX there) - a
comment in one source file alludes to Delphi, so that's where it came from, to
UNIX (I think this TECO was written there, and was not a port of a DEC one,
since it's all in lower case, and doesn't have other DEC stylisms), after the
port, added a '^R mode' similar to the one added to the PDP-10 ITS TECO and
used there to write EMACS (in TECO's usual 'line noise' code - historical
aside: at one point there was a whole 'Ivory' package for ITS TECO which could
'purify' ITS TECO code so that one copy in core [actual, real core!] could be
shared by multiple processes). That was used to write an EMACS-like package
for the PDP-11 UNIX TECO (but much simpler than real EMACS), which we used for
quite a while before Montgomery EMACS for UNIX showed up.
The full dump of the MIT-CSR PWB1 UNIX system which I retrieved has all the
sources and documentation for that TECO, and the ^R-mode code, etc. If anyone
is interested in seeing it (or maybe even playing with it, which will need
the UNIX MACRO-11), let me know, and I'll upload it.
Noel
PS: Speaking of the full dump of the MIT-CSR PWB1 UNIX system, I was poking
around it a couple of days ago, and I found V6 'multiplexor' kernel drivers -
mpio.c and mpx.c, etc - I think thay 'fell off the back of a truck' at Bell,
like a lot of other stuff we weren't supposed to have, like the circuit design
tools, etc. I'm not sure if I have the user programs to go with them; I think
I may have found some of them for Paul Ruizendaal a while back, but the memory
has faded. Again, if interested, let me know.
I never really used it but i do remember an editor called le on the v7 interdata/Perkin Elmer i used at Leeds poly.
I read electronics and we all used vi, the computer science people at a different campus used le on their Interdata; no idea why.
anyone any background on le? ihave not seen sight nor sound of it since.
-Steve
Evening all,
Seeing as our leader is worried about aliveness, I felt it fitting to send a link to a part-time project I’m working on.
A couple of weeks ago, I fired up Virtualbox and installed NetBSD/i386 1.0 from floppy images. Virtualbox can be persuaded to read 1.2MB floppies - I’ve had less luck on Qemu with this. But after I setup the VM, I quickly converted it to one that Qemu could use.
Then I loaded all the source floppies for 1.1 and 1.2 onto the VM, then upgraded the VM to 1.1 then 1.2 by compiling from source. By which time the pcnet network interface worked reliably. NetBSD still provides a pserver CVS method, so I was able then to CVS update, upgrade to 1.3.3 onwards.
1.4.3 -> 1.5.4 involves a change of binary format from a.out -> ELF.
From 1.6 onwards, life becaomes simpler because of the build.sh system, but I spent the time to go all the way up to 9.2 via sources between each release. (I managed to build 9.2 from 6.1 as well.)
The VMs can be found on this landing page:
https://chrispinnock.com/stuff/netbsd/
I’m working on a write-up which I will publish at some point and I’m also working on OpenBSD branching off at NetBSD 1.1 - I’ve build a OpenBSD 2.0 VM from the NetBSD 1.1 VM on the page above.
amnesiac# ls -l /ne*
-rwxr-xr-x 1 root wheel 19089180 Mar 26 02:47 /netbsd
-rwxr-xr-x 1 root wheel 659600 Mar 13 22:09 /netbsd.10
-rwxr-xr-x 1 root wheel 1332275 Mar 13 22:09 /netbsd.11
-rwxr-xr-x 1 root wheel 1477949 Mar 13 16:13 /netbsd.12
-rwxr-xr-x 1 root wheel 1530049 Mar 13 17:47 /netbsd.121
-rwxr-xr-x 1 root wheel 2211878 Mar 14 02:23 /netbsd.133
-rwxr-xr-x 1 root wheel 3407541 Mar 14 05:12 /netbsd.143
-rwxr-xr-x 1 root wheel 4941157 Mar 14 05:50 /netbsd.154.aout
-rwxr-xr-x 1 root wheel 5048054 Mar 14 09:20 /netbsd.154.elf
-rwxr-xr-x 1 root wheel 6182687 Mar 14 11:53 /netbsd.162
-rwxr-xr-x 1 root wheel 7447216 Mar 14 14:35 /netbsd.203
-rwxr-xr-x 1 root wheel 7476202 Mar 15 01:12 /netbsd.21
-rwxr-xr-x 1 root wheel 8577892 Mar 15 11:50 /netbsd.31
-rwxr-xr-x 1 root wheel 10343742 Mar 15 23:47 /netbsd.4
-rwxr-xr-x 1 root wheel 12002769 Mar 16 05:31 /netbsd.52
-rwxr-xr-x 1 root wheel 13116694 Mar 16 14:53 /netbsd.61
-rwxr-xr-x 1 root wheel 17143555 Mar 17 04:50 /netbsd.72
-rwxr-xr-x 1 root wheel 19695304 Mar 20 09:12 /netbsd.82
-rwxr-xr-x 1 root wheel 19089180 Mar 28 10:46 /netbsd.92
All the best
Chris
> From: Angelo Papenhoff
> By 'upload it' do you mean the full dump or TECO only?
At this point in time, not the full dump (below for why).
I have previously uploaded lots of other bits, e.g. (looks quickly): the
TCP/IP that was written for it (with the TCP in the 'user process', making
for a small system, good for -11/23's and -11/40's); Montgomery EMACS; TECO
(already done - along with the MACRO-11, but I still need to do the linker,
and the BCPL compiler one needs for the linker).
> That system sounds very interesting and I'd love to see the whole thing.
Unfortunately, the dump includes _everything_ on the system, including
personal email, etc, etc. So I have to curate it anything I upload.
I suppose I should put together an 'index page', which lists (and links
to) everything that has been uploaded?
Noel
> Just checking that the TUHS list hasn't gone belly up, as it's been pretty
> quiet for a week :-)
>
> Cheers, Warren
Not relevant to a sudden dip, but overall my observation is that retro computing interest tends to focus on a period 30-40 years ago. For example, in the late 80’s people were going retro on the LGP-30, the story of Mel, etc. Probably this matches with people retracing their formative years in the industry when they retire.
If correct, we should see a rise in interest around early Linux in the upcoming years, with interest in 80’s Unix and early networking declining. We’re probably already past peak for interest in 1970’s Unix.
The historical log of this mailing list is important. Documenting historical events will get much harder after the "40 year window" has closed.
Paul
I did not have a lot of time to work on documenting the evolution of paging / virtual memory code in 32V, Sys III and early SysV in the past months, but I did get some more background information that seems worth sharing.
My understanding of the virtual memory story at USG is now as follows:
Somewhere in 1981/82 a project plan for Unix 5 / System V was made and evolving John Reiser’s virtual memory code for 32V-r3 was part of that plan. “Evolving” in this context meant making it more maintainable and more hardware independent. John’s code assumed a memory page, a disk block and a file block all to be the same size, and it needed to be more general. It was also designed around the VAX MMU and this too needed to be generalised. The person assigned to that job was Bob (Robert) Baron, reporting to Tom Raleigh. The project involved quite a bit of re-architecting and progress was slowish. On top of that Bob left for CMU to work on Mach. Tom Raleigh tried to pick up where Bob had left off, but progress remained slowish.
In parallel, Keith Kelleman and Steve Burroff were working on Unix for the 3B20 Unix. They did paging code from scratch around the 3B20 MMU (which used a more or less ‘modern’ page table design) and developed their idea for the “regions” abstraction to support large, non-contiguous address spaces. It seems that they built on the main working set ideas/concepts in the Reiser/Baron/Raleigh code base, combined these with their “regions” idea, made it multi-processor capable and made it all work on the 3B20. Around that time Tom Raleigh seems to have transferred to Bellcore, and the VAX code base got orphaned.
Two young engineers appear to have picked up the work on the VAX code base: Dean Jagels and Jim McCormick. My understanding is that they essentially back ported the 3B20 work to the VAX, falling back on the Reiser/Baron/Raleigh work where necessary. They got it working, and as far as I can tell, this is what got released in 1984 as part of SysV R2.4 for the VAX (the oldest surviving source code for this that I could find).
This somewhat tortuous birth may in part explain why Research chose to use the 4BSD virtual memory code for 8th edition.
> From: Bakul Shah
> My impression is that there is much less traffic on pretty much all the
> mailing lists I am on and I am wondering why.
Ukraine? That's certainly been absorbing a lot of my attention (but it
seems like it's going to go on for quite a while now).
Noel
> From: Warren Toomey
> Just checking that the TUHS list hasn't gone belly up, as it's been
> pretty quiet for a week :-)
Thank goodness!
That's one way to improve the S/N ratio.
Noel