TUHS April 2022

tuhs@tuhs.org

35 participants
20 discussions

by Warner Losh

Greetings, What's the canonical source for patches to 2.9BSD and 2.11BSD? I see we have 2.11BSD patch 469 dated last month in the archive. Where does it come from? Has anybody climbed the hill to import all the patches into a git repo? I've found some mirrors, but moe.2bsd.org has been down for me for ages... How does Warren keep things up to date? I also have a (maybe faulty) memory of a similar series of patches to 2.9BSD because it was the last BSD to support non-split I&D space machines. yet a quick google search turns up nothing other than a set of patches dated August 1985 (also in our archive) and some changes for variants of hardware (pro, mscp). Is that it? Warner

2 years

Old UNIX file system formats

by norman＠nose.cita.utoronto.ca

I've assembled some notes from old manuals and other sources on the formats used for on-disk file systems through the Seventh Edition: http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html Additional notes, comments on style, and whatnot are welcome. (It may be sensible to send anything in the last two categories directly to me, rather than to the whole list.)

2 years, 11 months

[tuhs] Go programming language

by Nelson H. F. Beebe

List readers may enjoy a new article about the history of the Go programming language published today: Russ Cox, Robert Griesemer, Rob Pike, Ian Lance Taylor, and Ken Thompson The Go programming language and environment Comm. ACM 65(5) 70--78 May 2022 https://doi.org/10.1145/3488716 https://dl.acm.org/doi/10.1145/3488716 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

2 years, 11 months

Document management in Unix, back in the day?

by Will Senn

Today I bit the bullet and dropped my many articles and electronic documents related to my technical explorations into Zotero. I was tired of constantly having to remember where the documents were located and I wanted to be able to curate them better (I tried git for a while, back when, but I'm not a fan of non-text data in my repos, and it wasn't really much better than the base file system approach). I've been using Zotero for years now, for academic works, but not for technical works unrelated to my research. I realized the man-years of effort to clean up the entries that I had created in about 30-40 seconds of exciting drag and drop, just about the time I deleted them from their original locations. I think the work will pay off in due time, but we'll see. Then I thought, surely, I'm not the first person to have had this problem... it occurred to me that y'all must have faced this very problem, a few years in, back in the late 70's, early 80's. That is, document management. What did you do, variously, considering both text and non-text? Will

2 years, 11 months

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

2 years, 11 months

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

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

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

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 April 2022