TUHS

tuhs@tuhs.org

43 participants
6501 discussions

Re: [TUHS] Capitalization question: UNIX/Unix and MULTICS/Multics?

by Douglas McIlroy

The main FJCC 1964 papar, by Vyssotsky, Corbato, and Graham, spelled Multics with an initial cap. By contrast, Ken transcribed the aural pun as UNIX. The lawyers did their best to keep it that way after most of us had decided it looks better as a proper noun. As I recall, there was an acronymic reading of Multics, but it wasn't taken seriously enough to drag the word into all caps. Nobody proposed an acronymic reading of UNIX. So both words defy the convention of rendering acronyms in upper-case. Doug

3 years

Re: [TUHS] Capitalization question: UNIX/Unix and MULTICS/Multics?

by jnc＠mercury.lcs.mit.edu

> From: Dan Cross > In Kernighan's Unix memoir, on page 9, he touches briefly on the > typography of "Unix": > "(Multics was originally spelled MULTICS ..." > Here, he is talking about interning at MIT in 1966. bwk would certainly > know better than me, but I can find no historical reference to this > "MULTICS" spelling; is anyone familiar with that? I looked at my early Multics stuff, and it's "Multics" almost everywhere: - "GE-645 System Manual", GE, 1968 - "The Multics Virtual Memory", GE, 1970 - "Introduction to Multics", MIT MAC TR-123, 1973 However, in my "A New Remote-Access Man-Machine System", on the title papge it says "Reprints of the MULTICS system presented at the" [FJCC, 1965]. No clue as to who printed it, or when - and all the FJCC papers themselves use "Multics". I have yet to ask Jerry Saltzer, but I suspect that if it ever was 'MULTICS', it was at a _very_ early stage, and was formally changed even before the FJCC papers (which were themselves very early). BTW, ISTR hearing that it was 'Unix' originally, and the 'UNIX' spelling was adopted at the insistence of Bell lawyers. So I went looking for an early (i.e. PDP-7 era) scanned document, to see what it was then, and all I could find was: https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/UnixEditionZ… which seems to be from just after the PDP-7 -> PDP-11/20 transition, and it uses 'UNIX'. Would the Bell lawyers have already been involved at that stage? Noel

3 years

Capitalization question: UNIX/Unix and MULTICS/Multics?

by Dan Cross

This is tangentially related to Unix, and came up randomly at work yesterday. In Kernighan's Unix memoir, on page 9, he touches briefly on the typography of "Unix": "(Multics was originally spelled MULTICS, but the lower-case version is less visually jarring; as with UNIX versus Unix and some other all-caps words, I’ll use the nicer-looking form even though it’s not historically accurate.)" Here, he is talking about interning at MIT in 1966. bwk would certainly know better than me, but I can find no historical reference to this "MULTICS" spelling; is anyone familiar with that? The earliest reference I can find (the 1965 paper from the FJCC: https://dl.acm.org/doi/pdf/10.1145/1463891.1463912) uses the more "Multics" styling, but it may have been typeset later. Alternatively, could someone send me Brian's email address? - Dan C.

3 years

Re: [TUHS] Armando plate

by Clem Cole

I did not realize Shannon must have had it first. Armando had it on his Nisson and he passed it to John Hall (Maddog) when he moved. Somewhere I have a picture of Armando’s car and my then Black Jetta with the MA plate together. On Tue, May 10, 2022 at 9:53 PM Tom Lyon <pugs(a)ieee.org> wrote: > Bill Shannon had the actual NH UNIX plates.Upgraded to VMUNIX for > California. > > On Tue, May 10, 2022 at 6:03 PM Clem Cole <clemc(a)ccc.com> wrote: > >> Ultrix plates were much later. The original Unix plates were there for a >> few years. >> >> On Tue, May 10, 2022 at 8:58 PM Kenneth Goodwin < >> kennethgoodwin56(a)gmail.com> wrote: >> >>> As I recall, The UNIX plates were the first in the series and >>> distributed at a USENIX conference AT THE DEC booth The next year, they >>> came out with the ULTRIX plates. >>> >>> On Tue, May 10, 2022, 8:54 PM Steve Bourne <srb(a)acm.org> wrote: >>> >>>> Armando also responsible for the UNIX "live free or die" plates. I >>>> still have a few. >>>> >>>> Steve >>>> >>> -- >> Sent from a handheld expect more typos than usual >> > > > -- > - Tom > -- Sent from a handheld expect more typos than usual

3 years

Re: [TUHS] {TUHS] Interesting Commentary on Unix from Multicians

by Douglas McIlroy

> Single Level Storage is an awesome concept and removes so many ugly > hacks from algorithms that otherwise have to process data in files. This was Vic Vyssotsky's signature contribution to Multics, though in typical Vyssotsky fashion he never sought personal credit for it. Other awesome Vyssotsky inventions: BLODI (block diagram), the first data-flow language, for sample-data systems. Parallel flow analysis (later reinvented and published by John Cocke). Vic installed this in Fortran to produce diagnostics such as, "If the third branch of IF statement 15 is ever taken, then variable E will be used before being set". Darwin, the original game of predation and self-reproduction among programs. Corewars.org keeps a descendant version going 60 years later. A minimum-spanning-tree algorithm quite different from the well-known methods due to his colleagues Bob Prim and Joe Kruskal, again unpublished. Not long ago on TUHS, Andrew Hume told how Vic found the same isolated bug in dc by mathematically generating hard cases that Andrew stumbled on by accident, As you may infer, Vic is one of my personal computing heroes. Doug

3 years

Armando plate

by Steve Bourne

Armando also responsible for the UNIX "live free or die" plates. I still have a few. Steve

3 years

conventions around zero padding in ip4

by ron minnich

I first learned in the 80s that 127.1 meant 127.0.0.1. I always assumed zero padding was defined in a standard *somewhere*, but am finding out maybe not. I talked to the IP OG, and he tells me that padding was not in any standard. [side note: it's weird and wonderful to still have so many people "present at the creation" of computing as we know it still around, and to find they are so willing to answer naive questions!] Padding is a standard in ip6, possibly because the addresses are so long. :: is your friend. IP4 padding came up recently: the ip command interprets 10.2 as 10.2.0.0, whereas most things (golang libraries, ping, ...) interpret it as 10.0.0.2. The latter interpretation accords with what I learned 40y ago. But, I find myself wondering: where was the first use of the IP4 zero padding convention?

3 years

TUHS web server has changed

by Warren Toomey

Hi all, I've just changed the DNS CNAME record of www.tuhs.org from minnie.tuhs.org (45.79.103.53) to newmin.tuhs.org (50.116.15.146). Minnie is running Ubuntu 18.04LTS and is getting a bit long in the tooth. Newmin is running 22.04LTS. So far I've got the web service up and running on newmin. Doing the e-mail migration will be fun :-) Let me know if you spot anything wrong with the new web server. I've also set up oldwww.tuhs.org which points at minnie, so you can still get to things on the old server. Cheers, Warren

3 years

Re: [TUHS] conventions around zero padding in ip4

by jnc＠mercury.lcs.mit.edu

> There were other ways of specifying a IP address numerically, initially; I decided to set the Way-Back Machine to as close to 0 as I could get, and looked to see what the Terminal Interface Unit: https://gunkies.org/wiki/Terminal_Interface_Unit whose source I recently recovered, did. This is an interesting implementation, because it was definitely one of the first 4 TCP implementations done (before any UNIX ones); likely one of the first two, along with the TENEX one. (Actually, they both likely originally predate the split of TCP and IP into separate protocols, although this version post-dates that split.) The manual: http://ana-3.lcs.mit.edu/~jnc/tech/mos/docs/tiunv1.lpt (in "B. TELNET Commands") and the source: http://ana-3.lcs.mit.edu/~jnc/tech/mos/tiu/telnet-1.mac disagree on how the user gave addresses in numeric form in an 'open' command; both agree that it was '@O <rest>,<net>,<socket>', but the manual claims that 'rest' "may be specified symbolically, or numerically in decimal", but the code shows that '#xxx' could also be used, to give it in hex. (Although if hex were used, the number could be a max of 16 bits; decimal alloweded up to 42 bits.) > From: Michael Kjörling > Looks like [A/B/C addresses] happened in 1978 or thereabouts? > https://www.rfc-editor.org/ien/ien46.txt No; it post-dates the IEN era; "Assigned Numbers" of September 1981 (RFC-790) is the first mention I could find of it. (That Dave Clark IEN is talking about what later became 'IP subnets' - which ironically long pre-date A/B/C - see IEN-82, February 1979.) The Internet Protocol spec of September 1981 (RFC-791) also has A/B/C; my memory is that this change was _not_ discussed in the INWG, Postel just sprung it on us in these two RFCs. I suspect what happened is that Jon (as keeper of the network numbers) realized that there was an increasing demand for network numbers, and 256 would only last so long, so he sprung into action and did the A/B/C thing. (If this topic is of more interest, it should get moved to the 'internet-history' list, it's off-topic here.) Interestingly, RFC-790 says: "One notation for internet host addresses commonly used divides the 32-bit address into four 8-bit fields and specifies the value of each field as a decimal number with the fields separated by periods." Note the "one notation", implying that it wasn't any kind of standard at that point. Noel

3 years

Re: [TUHS] conventions around zero padding in ip4

by jnc＠mercury.lcs.mit.edu

> From: Ron Minnich > I first learned in the 80s that 127.1 meant 127.0.0.1. I always assumed > zero padding was defined in a standard *somewhere*, but am finding out > maybe not. I talked to the IP OG, and he tells me that padding was not > in any standard. I don't think it was very standardized; I've been working on the Internet since 1977, and this is the very first I ever recall hearing of it! :-) > From: Bakul Shah > The converse question is who came up with the a.b.c.d format where each > of a,b,c,d is in 0..255? Again, that was not standardized at an early stage, but was, as best I can now recall, just adopted by general usage (i.e. without any formal discussion). There were other ways of specifying a IP address numerically, initially; e.g. for a while at MIT we were using w,x,y,z (with w-z in octal - note the ','s, which were a syntatic tag for the octal form), which was easier to interpret when looking at a packet dump on a PDP-11. Here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/arc/tftp.c.1 is the source for a user command (from July, 1979) which allowed host addresses to be given in that form. I'm not sure who came up with the dotted decimal form; I suspect you'd need to find some really old email archives, and look in that. There was, early on, a list called "tcp-ip", used by people who were getting their machines ready for the NCP->TCP/IP conversion. However, I suspect the 'dotted quad' predates that; there was an even earlier mailing list, used in early experimental work, by the group working on internet technology, whose name escapes me (it was something like "internet working group"). It's possible that an IEN: https://www.rfc-editor.org/ien/ien-index.html might mention the 'dotted quad' syntax; TCP and IP meeting minutes would be a good place to start. Noel PS: The A/B/C addresses are actually a moderately late stage of IP addresses. At the very start, they were all '8 bits network numbers, and 24 bits of 'rest''.

3 years

Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

by jnc＠mercury.lcs.mit.edu

> From: Tom Lyon > there were a few icustomer nstallations. Bell Labs Indian Hill was one > - so that's why TSS was the base of their UNIX port. "A UNIX System Implementation for System/370" (by W. A. Felton, G. L. Miller, and J. M. Milner): https://www.bell-labs.com/usr/dmr/www/otherports/ibm.html says "code to support System/370 I/O, paging, error recording and recovery, and multiprocessing already existed in several available operating systems, we investigated the possibility of using an existing operating system, or at least the machine-interface parts of one, as a base to provide these functions for the System/370 implementation ... Of the available systems, TSS/370 came the closest to meeting our needs and was thus chosen as the base for our UNIX system implementation". Alas, it doesn't say which other systems were also considered. >> On May 6, 2022, at 09:39, arnold(a)skeeve.com wrote: >> So, why, given the letter from these folks, including DMR, did they go >> ahead and use the TSS solution anyway? That paper says: "We initially thought about porting the UNIX operating system directly to System/370 with minimal changes. Unfortunately, there are a number of System/370 characteristics that, in the light of our objectives and resources, made such a direct port unattractive. The Input/Output (I/O) architecture of System/370 is rather complex; in a large configuration, the operating system must deal with a bewildering number of channels, controllers, and devices, many of which may be interconnected through multiple paths. Recovery from hardware errors is both complex and model-dependent. For hardware diagnosis and tracking, customer engineers expect the operating system to provide error logs in a specific format; software to support this logging and reporting would have to be written. ... Finally, several models of System/370 machines provide multiprocessing, with two (or more) processors operating with shared memory; the UNIX system did not support multiprocessing." Presumably these factors outweighed the factors listed in the Haley/London/Maranzaro/Ritchie letter. Noel

3 years

Alternative Implementation Proposal for Unix/370 (BTL, 1979)

by Tom Lyon

I was (re?)introduced to Chuck Haley recently and discovered he had a copy of a Bell Labs memo from himself, London, Maranzaro, and Ritchie. They suggest that the path pursued to get UNIX running in/under TSS/370 was the hard way to go. Enjoy: http://charles.the-haleys.org/papers/Alternate_Implementation_Proposal_for_… -- - Tom

3 years

tuhs hiccups?

by Tom Lyon

For some reason, against my wishes, I'm not getting TUHS messages as they happen, but in batches (not digest) after 5-7 days. Last I've received right now is from May 2. Anyone know why? -- - Tom

3 years

Bob Widlar Poster

by Janek Gál

Hey folks, there is a cool poster by Bob Widlar, which we would like to have as a big poster in the hackspace: https://august.sax.de/widlar.jpg This is already a high resolution scan (2048 × 3048) but we are looking for something better (for A0 paper). Does anyone have something like this maybe still in his collection? greetings, Janek :) -- Janek Gál <janek(a)sax.de> Dresden, Germany http://www.sax.de

3 years

Re: [TUHS] First Unix-like OSes not derived from AT&T code?

by John Foust

At 04:17 PM 5/2/2022, Dan Cross wrote: >I vaguely remember Metaware being somewhat religiously extreme, but again the details are fuzzy now. Was there some kind of ecclesiastical reference in the man page? I have the manuals around somewhere, and that rings a bell. I used Metaware High C and the Pharlap extender in the early 1990s in the odd 32-bit DOS enviroment to make 3D import/export plugins for Autodesk's 3D Studio. - John

3 years

Re: [TUHS] First Unix-like OSes not derived from AT&T code?

by Ronald Natalie

We got in on the W4 from the IBM Federal Systems guy (later dealt out to Loral, Martin Marietta, and then Lockheed-Martin). I started with those guy doing a contract job to craft the second nework interface into Secure Xenix (Jacob Recter I think was responsible for the first) to provide a secure downgrading system for some government entity. Then Intel developed the i860- and IBM came up with the Wizard card. This was only designed to be.a coprocessor card and was done down in Boca Raton. The fun and games with that one is that we were on early steppings of the processor chips and spent a lot of time coding around chip bugs (mostly with regard to interrupts). IBM/Intel had developed this thing called hostlink that was supposed to be useful, but we decided to port AIX to it. When IBM Owego came up with the W4, we were asked to port AIX again to it. We had one non-functional W4 kicking around for demo purposes that had 4 “delidded” i860 chips in it. I swapped one for an early stepping (useless) chip and kept one of the delidded ones which I still have in a box somewhere.

3 years

In case you haven't heard yet

by Wesley Parish

I went googling for "Thoth operating system source code" while reading the discussion on Unix-like OSes and found the following: https://securitronlinux.com/debian-testing/nextstep-operating-system-source… which led to https://www.nextcomputers.org/forums/index.php?topic=4690.0 which led to various NeXTStep fragments that might be of interest. Share and Enjoy! Wesley Parish

3 years

2.9BSD with MSCP Support

by Warren Toomey

[ This also in from Peter Klapper. The files are at: https://www.tuhs.org/Archive/Distributions/UCB/2.9BSD_MSCP/ ] This is a 2.9BSD kernel with a backported MSCP driver from 2.10BSD I tried to make a clean integration of the driver into the 2.9BSD source tree in order to be able use the standard procedures to configure and build the kernel. To try it, rename the original directories /usr/include/sys and /usr/src/sys and unpack the two tar archives into your /usr directory. Then change into /usr/src/sys/conf and just do a ./config for the kernel you want. I made some configurations for: MSCP23 (MSCP enabled kernel for the PDP11/23) MSCP73 (MSCP enabled kernel for the PDP11/73) FLOP23 (MSCP enabled 11/23 kernel for a boot floppy) FLOP73 (MSCP enabled 11/73 kernel for a boot floppy) MSCPSH (MSCP enabled kernel for an extended SIMH environment) You may need to adapt the kernel configurations for the correct timezone and maybe the line frequency. This is probably the most recent BSD system which runs on the PDP11/23. Read the full story about this here: https://forum.vcfed.org/index.php?threads/scientific-micro-systems-sms-1000… There is NO root password in this distribution. For installation on real hardware, at least a Maxtor XT-1085 (RD53) or larger is recommended. My SMS1000 system currently has a Maxtor XT-1140 installed. Original was an XT-1085 in the system. The disk layout for these two disks during installation is as follows: Maxtor XT-1085 / DEC RD53 ========================= 1024/8/18 interleave 1,4 --- layout --- root = ra(0,0), size 3200 swap = ra(0,6400), size 1920 usr = ra(0,10240), size 64180 Maxtor XT-1140 ============== 918/15/18 interleave 1,4 --- layout ---- root = ra(0,0), size 3200 swap = ra(0,6400), size 1920 usr = ra(0,10240), size 114880 I've split the data into 4 parts in order to not get too much when downloading: 1.) 29bsd-simh.tgz: A SIMH image including configuration file. "pdp11 sms1123.ini" 2.) 29bsd-smstape.tgz: A Linux dump of the QIC24 installation tape which was generated with my SMS1000 system. You can write this under Linux to a 60MB QIC tape with: "dd if=29bsd-sms-tape.dd of=/dev/st0" The SMS1000 generated format is not compatible with Linux, but the Linux dd'ed tape can be read by the SMS1000 system. 3.) 29bsd-tapefiles.tgz: The files to create a SIMH tape image, or real tape for another system. 4.) 29bsd-vtserver.tgz: The version of the vtserver and the corresponding configuration file with which I performed the successful initial installation. I worked with 19200bps, which is the maximum my SMS1000 supports on the console, under 2.9BSD only 9600bps works anyway. Have fun with it, if you find bugs, they may of course be mine. ;) I wish you and the community also a lot of fun with this version of 2.9BSD. // Peter

3 years

Pro/Venix 2.0: reconstructed

by Warren Toomey

Hi all, I just received this in the e-mail a few days ago: [ now at https://www.tuhs.org/Archive/Distributions/DEC/Venix/ProVenix_2.0/ ] From: Peter Klapper Subject: PRO/VENIX 2.0 reconstructed ... ... and tested, for your collection ;-) Probably the best OS for the Pro, see the benchmark: PRO380 - PRO/VENIX V2.0: ======================== pk$ dryr Dhrystone(1.1) time for 50000 passes = 86 This machine benchmarks at 581 dhrystones/second pk$ drynr Dhrystone(1.1) time for 50000 passes = 95 This machine benchmarks at 526 dhrystones/second The four additional floppy disks contain also the source code which I used to rebuild the missing binaries. I wish you and the community much fun with the "new" resurrected PRO/VENIX V2.0.

3 years

whereis command

by ron minnich

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 :-)

3 years

Re: [TUHS] Interesting commentary on Unix from Multicians.

by jnc＠mercury.lcs.mit.edu

> 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

3 years, 1 month

Sad News - we last two wonderful people in the past few weeks.

by Clem Cole

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.

3 years, 1 month

Interesting commentary on Unix from Multicians.

by Dan Cross

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.)

3 years, 1 month

Re: [TUHS] Why does shell write to stderr?

by Douglas McIlroy

How would you wish to interact with /bin/bash >file Doug

3 years, 1 month

Re: [TUHS] Interesting commentary on Unix from Multicians.

by jnc＠mercury.lcs.mit.edu

> 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

3 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS