TUHS October 2024

tuhs@tuhs.org

45 participants
23 discussions

by Douglas McIlroy

> lilian worked at bell labs in the 80s (and maybe 90s) > around tech and films and suchlike. Lillian was a real pioneer. She began collaborating at the Labs in the mid 1960s. Doug

2 months

lilian schwartz has died

by andrew＠humeweb.com

lilian worked at bell labs in the 80s (and maybe 90s) around tech and films and suchlike.

2 months

by arnold＠skeeve.com

Hi All. I'm working on revising my book on basic *nix programming, and for the new chapter on sockets, I want to include some code from 4.2 BSD. Is there a copyright file somewhere for that code? I'm sure it's copyright the Regents of the University of California, but I'd like to include the text of the copyright in the book, so that everything's clear. Thanks! Arnold

2 months, 1 week

V8 and V9 manual covers

by Aharon Robbins

Hello All, I took a picture of my V8 and V9 manuals the other day. It's available at https://www.skeeve.com/V8-V9-Covers.jpg. @segaloco: This one's for you. :-) Enjoy, Arnold

2 months, 1 week

Re: BTL Involvement in Publication Imagery?

by Douglas McIlroy

Unix folk were barely involved in the branding or advertising of the system. I recall that we got to proofread and edit the first Unix ad, but essentially nothing later. Nor did we contribute to the cover designs of the 7th edition trade verson or the 8th-10th in-house versions of the manual. Doug

2 months, 1 week

BTL Involvement in Publication Imagery?

by segaloco

So in the course of AT&T's involvement with UNIX, a number of different images and motifs have graced advertisements and covers of literature, among them: - Letter Blocks (V7 HRW manuals, Release 4.0 Starter Packages) - Criss-crossing grid lines on a black background (Release 5.0/SVR1) - Variations on an image of earth with UNIX superimposed (SVR3/SVR4) - Covers mirroring publication motifs of other AT&T products and literature (SVR2/SVR3) Did the folks actually involved in the production of UNIX have any influence on the choice of design motifs for such materials, or would those sorts of decisions have been largely in the hands of marketing folks several layers removed from the Labs? My understanding is that this sort of visual branding started in the early 80s, with the earliest example of a printed piece of UNIX literature outside of generic Bell Laboratories covers I'm aware of being the "Starter Package" documents featuring UNIX spelled out on four letter blocks in primary colors. Everything I've seen branded predating these 1981 publications is either 8.5/11 pages in a Bell Labs or Western Electric report cover or the form factor of the Release 3.0 manual using generic Bell Labs covers. I'm certainly intrigued if anyone has any recollection of any sort of visual motifs in play prior to 1981. - Matt G.

2 months, 1 week

Re: groff_man.7.man.in: Some remarks and editorial changes for this man page

by Douglas McIlroy

The titled post reminds me of Ted Dolotta, a guru of PWB Unix, whose eye for editorial detail was unsurpassed. He could spot the difference between italic and roman periods at twenty paces. Bjarni is in good company. Doug

2 months, 2 weeks

Re: Minimum Array Sizes in 16 bit C (was Maximum)

by Douglas McIlroy

> C's refusal to specify dynamic memory allocation in the language runtime > (as opposed to, eventually, the standard library) This complaint overlooks one tenet of C: every operation in what you call "language runtime" takes O(1) time. Dynamic memory allocation is not such an operation. Your hobbyhorse awakened one of mine. malloc was in v7, before the C standard was written. The standard spinelessly buckled to allow malloc(0) to return 0, as some implementations gratuitously did. I can't imagine that any program ever actually wanted the feature. Now it's one more undefined behavior that lurks in thousands of programs. There are two arguments for malloc(0), Most importantly, it caters for a limiting case for aggregates generated at runtime--an instance of Kernighan's Law, "Do nothing gracefully". It also provides a way to create a distinctive pointer to impart some meta-information, e.g. "TBD" or "end of subgroup", distinct from the null pointer, which merely denotes absence. Doug

2 months, 2 weeks

Why groff ms doesn't completely support historical documents

by G. Branden Robinson

Someone on the TUHS list mailed me privately, prompting me to write this lengthy apology (in the classical sense) of why groff doesn't make a certain application easier. I have slightly revised my response. This message also may serve as a summary of the challenges that need to be overcome if someone else wants to tackle the job, and potentially contribute it to groff. [person creates PDFs of historical Unix documents (many of which are written using the ms macros) and wishes groff ms made the task easier] I sympathize. I sometimes render historical documents, so I prescribed in groff ms's documentation the approach that I take myself. I decided against trying to support a "-matt" or "-msatt" option in groff because it's flatly impossible to know which definition of `UX` to use. Even a date declaration in the document sheds little light, as we then have to consider the question of whether we want fidelity to the actual state of the mark at the time of that declared date, or to what would have been rendered in the author's environment--and they may have been using an ms that wasn't "up to date" in the same respect. That information, too, is not recorded in the document.[1] Providing all the macros _except_ `UX` didn't seem likely to satisfy users since that's the most important one! It shows up in body text whereas all the others seldom do--if you can live without the cover page then, often, you're golden. Except for `UX`. Finally there is the name collision problem with Berkeley. 4.2BSD and later ms defined `CT` and `TM` macros (aspects of their "thesis mode") and once again there's no declarator within the document to tell you which dialect of ms is in use. This one can be heuristically figured out with pretty good odds, I suspect, but troff works as a filter--what was I going to do, write a preprocessor just for this? (Hmm, maybe grog(1) could do it, and that would be in its wheelhouse. But there's no point until and unless we reimplement support for Berkeley thesis mode in the first place [so that grog has an option argument to report], and that is an undertaking I have demurred.[2]) It seemed like a moderate amount of work for almost zero upside. It's also hard to validate/verify my work. The only historical troffs to which I have access are Seventh Edition Unix troff (1979, before Kernighan) and DWB 3.3 (early 1990s). It's a right pain in the butt to inspect typesetter output on V7 because I have nothing that emulates a C/A/T or translates it to device-independent troff output for a "ditroff"-style device description that Kernighan troff, DWB/Hierloom Doctools troff, or GNU troff could use. And even if I had either of those, they'd have to be vetted to a _high_ degree of quality before they'd be fit for purpose; else I wouldn't know whether I was chasing bugs in the groff ms macros or the C/A/T emulator/translator. So, to summarize, I confine my compatibility efforts to _nroff_ output, and rule the Bell Labs "site" macros out of scope. I feel there is not much more I can do, and have confidence my results, without resources that I'm lacking. I hope this sheds some light on my reasoning. Regards, Branden [1] Still, if someone wants to start, I'd start here. https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/vol2/ms/tmac.s [2] One person, ever, has requested it, 20 years ago. And I have no specimens of input or corresponding model output rendered by an "authentic" BSD troff [formatter executable PLUS support files] against which to develop a reconstruction. (On the bright side, the Berkeley modifications to the once-encumbered AT&T "tmac.s" are, of themselves, presumably BSD-licensed.) https://savannah.gnu.org/bugs/?64455

2 months, 2 weeks

30 days of awktober

by Rich Salz

Someone is trying to write something interesting about awk every day of this month. The thread starts here: https://mastodon.mit.edu/@eichin/113240121988228925

2 months, 2 weeks

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 October 2024