TUHS

tuhs@tuhs.org

13 participants
6469 discussions

Draft: London and Reiser's UNIX/32V paper, reconstructed

by G. Branden Robinson

Hi folks, Reiser and London's paper documenting their preparation of UNIX/32V, a port of Seventh Edition Unix to the VAX-11/780, is an important milestone in Unix development--as much I think for its frank critique of C as "portable assembly" as for the status of the system documented: the last common ancestor of the BSD and System V branches of development. Because the only version I've ever seen of this paper is a scan of, possibly, a photocopy several generations removed from the original, I thought I'd throw an OCR tool at it and see about reconstructing it, not just for posterity but to put the groff implementation of mm to the test. So even if someone has a beautiful scan of this document elsewhere, this exercise remains worthwhile to me for what it has shown me about Documenter's Workbench mm and groff's mostly compatible reimplementation thereof. Please find attached my first draft of the reconstruction as an mm document as well as a PDF rendered by bleeding edge groff. I did not attempt to fix _any_ typos, solecisms, or non-idiomatic *roff usage (like the employment of hyphens as arithmetic signs or operators) in this document. I may have introduced errors, however, due to human fallibility or incorrect inferences about what lay beneath scanning artifacts. Hence its draft status. I welcome review. Assuming this reconstruction survives peer scrutiny, I aim to put it up on GitHub as I did Kernighan & Cherry's "Typesetting Mathematics" paper.[1] For the casual reader, I extract my documentary annotations below. For groff list subscribers, I will add, because people are accustomed to me venturing radical suggestions for reforms of macro packages, I suggest that we can get rid of groff mm's "MOVE" and "PGFORM" extensions. They're buggy (as the man page has long conceded), and I don't think anyone ever mastered them, not even their author. I rewrote "0.MT", essential to rendering of this document, without requiring them at all. I _tried_ to use them, but "MOVE" in particular introduced baffling errors in vertical spacing. When I threw it aside to attack head-on the layout problems facing me, things got easier. Further, simple caching and restoration of `.i` and `.l` register values (when multiple changes were being made to them within a macro) obviated `PGFORM`. I'm not sure that it is tractable to idiot-proof manipulations of basic layout parameters like these, as these macros seem to have tried to do. If a document author wants to seize control of page layout from a full-service macro package and reach deep into the guts of the formatter, they should glove up and put things back where they found them. My opinion. .\" London & Reiser's UNIX/32V porting paper .\" .\" Reconstruction in groff mm (but DWB 3.3 mm compatible) .\" from scanned/OCRed text by G. Branden Robinson, June 2024 .\" .\" The original scan shows no evidence of superscript usage, except on .\" the cover sheet where "TM" superscripts "UNIX". .\" .\" Some differences may arise due to changes in the mm macro package .\" itself from its PWB incarnation (ca. 1978) and DWB 3.3 (July 1992). .\" Thanks to Dan Plassche for the history. .\" https://www.tuhs.org/pipermail/tuhs/2022-March/025545.html .\" .\" The groff reimplementation of mm was undertaken mostly from .\" 1991-1999 (by Juergen Haegg), based on the DWB documentation. It .\" added features but also parameterized many aspects of package .\" behavior, for example to facilitate easy localization. Later, .\" Werner Lemberg and G. Branden Robinson contributed enhancements, bug .\" fixes, and improvements to the groff_mm(7) man page. .\" .\" I anticipate adding further parameters to groff mm to better .\" emulate the old version of mm used by this paper. (For example, the .\" format of the caption applied to the reference page differs between .\" PWB mm and DWB 3.3.) Where this document exercises such extensions, .\" they should be prefixed with a `do` request so that AT&T troff will .\" ignore them. .\" Override: "By default, ... bold stand-alone headings are printed .\" in a size one point smaller than the body." .\" XXX: The cover "page" (more like a header block) is a mess when .\" typeset with groff mm, and outright horrific in nroff mode. GBR has .\" fixes for these pending for push to GNU Savannah's Git repository. .\" .\" XXX: Original scan capitalizes "Subject:"; DWB 3.3 renders it in .\" full lowercase. .\" .\" XXX: Original scan bears a "TM:" heading for the technical .\" memorandum number(s). DWB 3.3 lacks this. .\" .\" Memorandum captions may have changed from PWB to DWB 3.3 mm. groff .\" mm has changed in Git (June 2024) to use the captions documented in .\" the DWB 3.3 manual. We override the default for authenticity. .\" XXX: Original scan sets reference marks as a typewriter might, at .\" normal size on the baseline between square brackets. DWB 3.3 .\" converts them to superscripts but keeps the brackets(!). groff mm .\" should add a "Rfstyle" register to control this. .\" 0 = auto (nroff/troff); 1 = bracket; 2 = superscript; 3 = both. (?) \" straight quotes in original .ns \" XXX: Hack to keep `VL` from adding pre-list vertical space. \" recte: *(\-\-p+i) \" bad ellipsis spacing in original \" - missing; error in text or scanner fubar? \" recte: \-1 \" sic .\" Either `AL` worked differently in 1978 mm, or didn't exist, or .\" somebody wanted this list _just so_. .\"AL "" 5 .\" XXX: Scan has signatures set farther to the right, not centered as .\" DWB 3.3 mm sets them. groff mm follows DWB here. .\" .\" XXX: PWB and DWB 3.3 put the signature names in bold; groff mm sets .\" them at normal weight. Bug. .\" .\" XXX: Scan has a couple of vees between the signature line and the .\" flush left secretarial annotation. groff mm sets the annotation on .\" the same line as the last author but also puts its information in .\" the cover page header as DWB 3.3 does, described next. DWB 3.3: (1) .\" omits the secretarial annotation altogether, putting it up in the .\" cover page header under the authors' names; (2) does not use author .\" initials (in the cover header) for this memorandum type; (3) puts .\" the department number after "Org." on the line under the author .\" name; (4) puts the abbreviated AT&T site name below that. Should we .\" consider a `Sgstyle` register for groff mm? .\" .\" XXX: groff mm organizes the department and site name differently .\" from DWB 3.3 in the cover head, and I don't see any reason for it .\" to. Fix this. .\" XXX: Scan only breaks between notations; DWB 3.3 and groff put 1v .\" between them. Should we consider an `Nss` register for groff mm? .\" XXX: Scan has references caption set flush left, in mixed case and .\" bold (just like `HU`). DWB 3.3 and groff center it and set it in .\" full caps in italics (at normal weight). If there were a way to .\" dump the accumulated reference list independently of rendering the .\" caption, that would give the author much more flexibility. .\" .\" XXX: The numbered reference list does not look like one produced .\" with `RL` nor with `AL`. The numeric tag is left-aligned within the .\" paragraph indentation. groff mm aligns it to the right. .\" .\" DWB 3.3 and Heirloom mm don't seem to honor `.RP 2` as the DWB .\" manual documents. They start the table immediately after the .\" reference list and go haywire boxing the table. Bug. Regards, Branden [1] https://github.com/g-branden-robinson/retypesetting-mathematics

10 months, 1 week

PID 0 and the scheduler

by Will Senn

All, There's an interesting dive into PID 0 linked to from osnews: https://blog.dave.tf/post/linux-pid0/ In the article, the author delves into the history of the scheduler a bit - going back to Unix v4 (his assembly language skills don't go to PDP variants). I like the article for two reasons - 1) it's clarity 2) it points out the self-reinforcing nature of our search ecosystem. I'm left with the question - how did scheduling work in v0-v4? and the observation that search really sucks these days. Later, Will

10 months, 1 week

[tuhs] Early statistical software in Unix

by Nelson H. F. Beebe

The book ``S: An Interactive Environment for Data Analysis and Graphics'' (Wadsworth, 1984), by Richard A. Becker and John M. Chambers, and an earlier Bell Labs report in 1981, introduced the S statistical software system that later evolved into the commercial S-Plus system (now defunct, I think), and the vibrant and active R system (https://cran.r-project.org/) that we use at Utah in our statistics courses. Almost 21,000 open-source packages for R are available, and they appear to be the dominant form of statistical software package publication, based on extensive evidence in our bibliography archives that completely cover numerous journals in probability and statistics. I'm interested in looking into the early S source code, if possible, to see how some statistical software that I am freshly implementing for high-precision computation was handled at Bell Labs more than four decades ago. Does anyone on this list know whether the original S system was ever distributed in source code to commercial sites, and academic sites, that licensed Unix from Bell Labs in the 1980s? Does that code still exist (and is openly accessible), or has it been lost? As with the B, C, D, and R programming languages, it is rather hard for Web search engines to find things that are known only by a single letter of the alphabet. ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

10 months, 1 week

diving into vi (nvi) - some observations from a slow learner

by Will Senn

Well, I really dove into using vi by way of nvi this past week and I have to say... the water's fine. It turns out that vi is a much simpler editor to understand and use (but no less powerful) than it's great grandchild, vim. To be fair, vim is an interesting editor and having used it off and on since the mid '90s, it's very familiar... but its powers? difficult to attain. vim stands as an excellent example of just how far you can take a product that works, keeping its core, but expanding it in all directions. No matter how much I tried to grasp its essence, it alluded me. The online help files seemed inscrutable to me, mixing environment settings, ex commands, ex mode commands, vi motions, insert mode commands in ways that seemed quite confusing to me. I know that I'm probably among a select few vim users that love it without really having a clue as to how it works. My best resource has been the web and search, but of late I've been wanting more. That's what drove me on this quest to really dig in to how things used to work and nvi is the best surrogate of the old ways that I could find (well, excluding heirloom vi, the traditional vi, which I've confirmed works pretty much the same way as nvi, with lisp support and without a few nice-to-haves nvi has). Anyway, here's something I worked out, after much travail - vi appears to be all about modes, movement, counts, operators, registers, and screens (which I found very weird at first, but simple in retrospect)... with these fundamentals down, it seems like you can do anything and I mean anything... and all of the other functions are just bolted on for the purpose of making their specific tasks work. Getting this out of the existing documentation was a mess. Thankfully the nvi docs (based on the 4.4 docs) are much slimmer and better organized. Even so, they make assumptions of the reader that I don't seem to fit. Take motions as prolly the most glaring example - all of the docs I've ever seen organize these by logical units of text (words, paras, etc), personally and apparently persistently, I think of motion as directed, so it took me a lot of experimentation, head scratching, and writing things out several times in several different ways to realize I could represent the idea on a single notecard as (some commands appear in multiple lines): Leftward motions - [[, {, (, 0, ^|_, B, b, h|^H Rightward Movement - l|SP, e, E, w, W, $, ), }, ]] Upward motions - 1G, ^B, H, ^U, -, k | ^P Downward motions - G, ^F, L, ^D, ^M | +, j | ^J | ^N Absolute - | G Relative - %, H, M, L Marks - m, ', `, '', `` Keeping in mind that movements left-to-right are - section, para, sentence, line, text, word and endword (big, and small), and letter. And up and down are - file, screen, in screen (HML), half-screen, chars-in-line, and line. For me, this inversion from units of motion to direction of motion put forty some-odd commands in much closer reach for me. Looking back at the vim documentation, I see how its sheer volume and the way it is organized got in the way of my seeing the forest. Thankfully, in nvi, there are two incredibly useful ex commands to help - exu[sage] and viu[sage]. I simply printed these out and worked with them making the experimental assumption that they would serve as a baseline that represented the full capabilities of vi... and sure enough, after working and working with them, I am pretty confident they are sufficient for any editing task. Wow, who knew? I loved vi, but now, I'm starting to really appreciate it's simplicity?! I can't believe those words are coming out of my mouth. I never thought of it as simple... those movement commands were far too numerous as I understood them. Are there things I miss from vim? Sure, I miss command line completion in ex mode, I want my help text to appear in a window where I can search, I would like better window control. But, I think I'll stick with nvi a while until I really nail it down. Then all of the cool stuff that vim offers, or neovim, will seem like icing on the cake that is vi. Thanks to Ken Thompson for writing a work of art that serves as the true core of this editor, to Bill Joy for his great work in extending it, again to Bill Joy for bringing vi to life, and to Mary Ann for the macros and making it accessible to the rest of us, and others who contributed. It's 2024 and I still can't find a better terminal editor than vi... as it existed in the late '80s or as it exists today as nvi/vim/neovim. Amazing piece of software. Off to figure out tags!! Arg, seems like it oughtta be really useful in my work with source code, why can't I figure it out?! Sheesh. Will

10 months, 2 weeks

Old documentation - still the best

by Will Senn

A small reflection on the marvels of ancient writing... Today, I went to the local Unix user group to see what that was like. I was pleasantly surprised to find it quite rewarding. Learned some new stuff... and won the door prize, a copy of a book entitled "Introducing the UNIX System" by Henry McGilton and Rachel Morgan. I accepted the prize, but said I'd just read it and recycle it for some other deserving unix-phile. As it turns out, I'm not giving it back, I'll contribute another Unix book. I thought it was just some intro unix text and figured I might learn a thing or two and let someone else who needs it more have it after I read it, but it's a V7 book! I haven't seem many of those around and so, I started digging into it and do I ever wish I'd had it when I was first trying to figure stuff out! Great book, never heard of it, or its authors, but hey, I've only read a few thousand tech books. What was really fun, was where I went from there - the authors mentioned some bit about permuted indexes and the programmer's manual... So, I went and grabbed my copy off the shelf and lo and behold, my copy either doesn't have a permuted index or I'm not finding it, I was crushed. But, while I was digging around the manual, I came across Section 9 - Quick UNIX Reference! Are you kidding me?!! How many years has it taken me to gain what knowledge I have? and here, in 20 pages is the most concise reference manual I've ever seen. Just the SH, TROFF and NROFF sections are worth the effort of digging up this 40 year old text. Anyhow, following on the heels of a recent dive into v7 and Ritchie's setting up unix v7 documentation, I was yet again reminded of the golden age of well written technical documents. Oh and I guess my recent perusal of more modern "heavy weight" texts (heavy by weight, not content, and many hundreds of pages long) might have made me more appreciative of concision - I long for the days of 300 page and shorter technical books :). In case you think I overstate - just got through a pair of TCL/TK books together clocking in at 1565 pages. Thank you Henry McGilton, Rachel Morgan, and Dennis Ritchie and Steve Bourne and other folks of the '70s and '80s for keeping it concise. As a late to the party unix enthusiast, I greatly value your work and am really thankful you didn't write like they do now... Later, Will

10 months, 2 weeks

CSRC Involvement in Non-UNIX AT&T Software Projects

by Douglas McIlroy

> was there ever any crossover regarding UNIX folks applying their developments to other non-UNIX AT&T systems Besides Sandy Fraser's long-term effort to advance digital communication (as distinct from digital transmission), there was TPC; see TUHS https://www.tuhs.org/pipermail/tuhs/2020-April/020802.html and other mentions of TPC in the TUHS archives. Ken Thompson did considerable handholding for early adopters of Unix for applications within the Bell System, notably tracking automatic trouble reports from switching systems and managing the workflow of craftspeople in a wire center. Bob Morris's intimate participation in a submarine signal-processing project that Bell Labs contracted to produce for the US Navy set him on a career path that led to becoming chief scientist at NSA's National Computer Security Center. Gerard Holtzmann collaborated to instill model-checking in switching and transmission projects. Andrew Hume spent much time with AT&T's call records. Lorinda Cherry single-handedly automated the analysis of call centers' notes on customer contacts, This enabled detection of significant human-engineering and public-relations problems. An important part of my role as a department head was to maintain contacts with development labs so that R and D were mutually aware of each other's problems and expertise. This encouraged consulting visits, internships, and occasionally extended collaboration or specific research projects as recounted above. Doug

10 months, 2 weeks

Proliferation of book print styles

by Will Senn

Today, as I was digging more into nroff/troff and such, and bemoaning the lack of brevity of modern text. I got to thinking about the old days and what might have gone wrong with book production that got us where we are today. First, I wanna ask, tongue in cheek, sort of... As the inventors and early pioneers in the area of moving from typesetters to print on demand... do you feel a bit like the Manhattan project - did you maybe put too much power into the hands of folks who probably shouldn't have that power? But seriously, I know the period of time where we went from hot metal typesetting to the digital era was an eyeblink in history but do y'all recall how it went down? Were you surprised when folks settled on word processors in favor of markup? Do you think we've progressed in the area of ease of creating documentation and printing it making it viewable and accurate since 1980? I didn't specifically mention unix, but unix history is forever bound to the evolution of documents and printing, so I figure it's fair game for TUHS and isn't yet COFF :). Later, Will

10 months, 2 weeks

Re: Proliferation of book print styles

by Douglas McIlroy

> Were you surprised when folks settled on word processors in favor of markup? I'm not sure what you're asking. "Word processor" was a term coming into prominence when Unix was in its infancy. Unix itself was sold to management partly on the promise of using it to make a word processor. All word processors used typewriters and were markup-based. Screens, which eventually enabled WYSIWYG, were not affordable for widespread use. Perhaps the question you meant to ask was whether we were surprised when WYSIWYG took over word-processing for the masses. No, we weren't, but we weren't attracted to it either, because it sacrificed markup's potential for expressing the logical structure of documents and thus fostering portability of text among distinct physical forms, e.g. man pages on terminals and in book form or technical papers as TMs and as journal articles. WYSIWYG was also unsuitable for typesetting math. (Microsoft Word clumsily diverts to a separate markup pane for math.) Moreover, WYSIWYG was out of sympathy with Unix philosophy, as it kept documents in a form difficult for other tools to process for unanticipated purposes, In this regard, I still regret that Luca Cardelli and Mark Manasse moved on from Bell Labs before they finished their dream of Blue, a WYSIWYG editor for markup documents, I don't know yet whether that blue-sky goal is achievable. (.docx may be seen as a ponderous latter-day attempt. Does anyone know whether it has fostered tool use?) Doug

10 months, 2 weeks

CSRC Involvement in Non-UNIX AT&T Software Projects

by segaloco

I'm reading about the Automatic Intercept System as discussed in BSTJ Vol. 53 No. 1 this evening. It is a stored program control call handling system designed to respond to calls with potential forwarding or disconnection messages. Reading through the description of the operating system for AIS got me wondering: What with the growing experience in the CSRC regarding kernel technologies and systems programming, was there ever any crossover regarding UNIX folks applying their developments to other non-UNIX AT&T systems projects or vice versa, perhaps folks who worked primarily on switching and support software bringing things over to the UNIX development camp? In other words, was there personnel cross-pollination between Bell System UNIX programmers and the folks working on stuff like AIS, ESS switching software, etc.? Or were the aims and implementation of such projects so different that the resources were relatively siloed? I would imagine some of these projects were at least developed using UNIX given the popularity and demands of PWB. That's just my hunch though, some BSTJs also describe software development and maintenance taking place on S/360 and S/370 machines and various PDPs. Indeed the development process for AIS mentioned above, as of late 1971, involved assembly via S/360 software and then system maintenance and debugging via an attached PDP-9. - Matt G.

10 months, 2 weeks

Mike Karels has died

by Chet Ramey

Sad, horrible news. https://www.facebook.com/groups/BSDCan/permalink/10159552565206372/ -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

10 months, 2 weeks

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