TUHS

tuhs@tuhs.org

6 participants
6532 discussions

Start a nNew thread

Re: [TUHS] FYI: Internet Old Farts Club

by norman＠oclsc.org

I'm too much of an old fart to use FaceBook. a Norman Wilson Toronto ON @oclsc on twitter

3 years, 5 months

Latest release of retro-fuse

by Jay Logue

Hi all, I've been hard at work on my retro-fuse project over the past few months, and so I thought I'd update the list with my progress. I have just released version 7 of retro-fuse on github (https://github.com/jaylogue/retro-fuse) This version adds support for initializing and mounting 2.9 and 2.11BSD filesystems on modern systems. It also includes fixes for a number of bugs in v6 and v7 support. Beyond the work on 2.11 support, I also spent a significant amount of time building an automated test framework. I'm a pretty big fan of automated testing. So I'm happy to say that the project now includes a series of tests verifying basic file I/O functionality as seen from the modern system. While not exhaustive (because filesystem testing is /hard/) the new tests give me reasonable confidence that things are behaving as they should. Additionally (in what was perhaps the most fun part of the project to date) I have also created tests to verify the integrity of the generated filesystems as seen from the historical systems. In particular, for each of the supported Unix versions I've built tests that: launch the os under simulation (simh), mount the generated filesystems, verify the filesystems using the original integrity check tools (icheck/fsck), and enumerate and compare the filesystem contents to that generated on the modern system. As you might imagine, this involved a lot of learning--from how to build size-reduced system images from the original distribution tapes, to how to implement a modern POSIX cksum command with old dev tools. All thoroughly enjoyable. With this under my belt, I'll probably take a break from retro-fuse to concentrate on other things. If anyone has any problems (or successes!) using it, please drop me a line. --Jay

3 years, 5 months

Doug McIlroy and Brian Kernighan talk

by arnold＠skeeve.com

Found this yesterday: https://www.youtube.com/watch?v=Xe5ffO6Ouwg Not quite an hour long. Arnold

3 years, 5 months

Fwd: A bit of BTL Explorer Post Ephemera

by aaron cohen

Wow. Brings back memories On Mon, Jan 24, 2022 at 1:32 PM Robert Diamond <rob(a)robdiamond.com> wrote: > Just found this program from 1979 of an Explorer Club (aka “The Scouts”) > Family Night, which included a talk from Ken Thompson on Computer Chess. > There’s a few notable names in there. > > See PDF at > https://drive.google.com/file/d/15fXhkk9KlmJNrhGlFnWuH23XQ09vLG4o/view?usp=… -- Aaron Cohen 908-759-9069

3 years, 5 months

A bit of BTL Explorer Post Ephemera

by Robert Diamond

Just found this program from 1979 of an Explorer Club (aka “The Scouts”) Family Night, which included a talk from Ken Thompson on Computer Chess. There’s a few notable names in there. See PDF at https://drive.google.com/file/d/15fXhkk9KlmJNrhGlFnWuH23XQ09vLG4o/view?usp=…

3 years, 5 months

Re: [TUHS] roff(7)

by Douglas McIlroy

> Did roff do all of what troff and nroff did? No way. Ossanna deserves all the praise you give him. Roff extended runoff in various ways: relative numeric operators, e.g. .in +8 tabbing (left, right and centered) underlining tripartite headers and footers arabic and roman page numbering adjustable head and foot margins automatic hyphenation, thanks to Molly Wagner footnotes merge patterns for change marks, column separators, etc. various special requests: .ne, .ti, .tr, .po, .op (odd page) But roff did NOT have conditionals, traps, special characters, environments, or arbitrary motion control. Crucially (and ironically, because I was Mr. Macro), it did not have anything like macros, strings and diversions until after Joe pioneered them in nroff. So there was a gaping disparity: nroff was Turing complete, roff wasn't. Roff merely added features to runoff; nroff leapt into a different universe. ----------------------- The features listed above are in the January 1971 manual for BCPL roff, which is probably the anonymous reference cited in the November 1971 v1 manual. The v1 manual lists Osanna, Ken and Dennis as authors of the Unix implementation. I believe Ossanna is named because he added line-numbering--and maybe more--to entice the patent department to switch to roff. BCPL roff allowed all four arithmetic operators in contexts like .ls *3. Only + and - were allowed in nroff. Eventually both BCPL roff and nroff got number registers (defined by different commands); I don't recall which came first. BCPL roff also got a weak macro facility, definitely after nroff. Doug

3 years, 5 months

struct(1) updating - progress

by Arnold Robbins

Hello All. If anyone is interested in struct, I have completed updating it for modern day systems. Thanks to Jay Logue for invaluable help in completing the work and to Bakul Shah for his interest and support. See https://github.com/arnoldrobbins/struct; I have merged the modernization work into the master branch. The README.md describes what was done in more detail. Doug McIlroy - if you want me to add anything to the README.md, please send it on and I will do so, quoting you as appropriate. Jay Logue and Bakul Shah - if you want me to add anything to the README.md, please let me know (privately). Thanks, Arnold

3 years, 5 months

DEC Format floppy (for formatting disk prior to 4.2BSD install)

by Will Senn

Hi all, Has anybody ever seen a console floppy image anywhere on the internet labeled: /"RX11 VAX DSK LD DEV #1"/ It is referenced in BSD 4 documentation with respect to formatting disks (edited): USING DEC SOFTWARE TO FORMAT Warning: These instructions are for people with 11/780 CPU’s. You should shut down UNIX and halt the machine to do any disk formatting. Formatting an RP06. Load the console floppy labeled, "RX11 VAX DSK LD DEV #1" in the console disk drive, and type the following commands: >>>BOOT DIAGNOSTIC SUPERVISOR. ZZ-ESSAA-X5.0-119 23-JAN-1980 12:44:40.03 DS>ATTACH RH780 SBI RHO 8 5 DS>ATTACH RPO6 RHO DBA0 DS>SELECT DBAO DS>LOAD EVRAC DS>START/SEC:PACKINIT This is for drive 0 on mbaO; use 9 instead of 8 for mbal, etc.

3 years, 5 months

Dot (graphviz) to ascii

by Richard Salz

>From Thomas Ptacek on twitter [1], quoting something on HackerNews [2]: a person wrote a dot-file renderer for ASCII diagrams [3] It seems to be a service; source not available. 1. https://twitter.com/tqbf/status/1483181795441004544?t=DoL8RopOYKBojkmMznSlA… 2. https://news.ycombinator.com/item?id=29969770 3. https://dot-to-ascii.ggerganov.com/

3 years, 5 months

Re: [TUHS] BWK talk on early Unix Friday 14 January 2022

by Douglas McIlroy

> I've just watched an interesting presentation given last Friday via > video link to the Linux Conference in Australia: > Brian Kernighan > The early days of Unix at Bell Labs > https://www.youtube.com/watch?v=ECCr_KFl41E Here's an earlier incarnation of the talk: https://www.youtube.com/watch?v=nS-0Vrmok6Y I rather enjoyed seeing it with closed captions in Spanish and speakers turned off. Aided by the slides, I was pretty well able to read the Spanish, which otherwise would have been quite mysterious. Doug

3 years, 5 months

BWK talk on early Unix Friday 14 January 2022

by Nelson H. F. Beebe

I've just watched an interesting presentation given last Friday via video link to the Linux Conference in Australia: Brian Kernighan The early days of Unix at Bell Labs https://www.youtube.com/watch?v=ECCr_KFl41E 48 minutes While most of the talk subjects are well known to TUHS list members, there are nice things said about various people, and about the value of TUHS. Other talks at the conference may be of interest as well: see the schedule at https://linux.conf.au/schedule/ ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - 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/ - -------------------------------------------------------------------------------

3 years, 5 months

7th and 8th edition manuals, plus PDP11 processor handbook

by Terry Jones

Any takers for a (free) two-volume 7th Ed manual (1983), or ring-bound 8th Ed (1985), or PDP11 processor handbook (1981)? These would need to be picked up in Lindfield, Sydney, Australia. Condition is fair, but they've been in storage for 35 years so are slightly mouldy, but still perfectly usable. Images at http://jon.es/other/7th-ed.jpg and http://jon.es/other/8th-ed.jpg If you’d like them, let me know in email ASAP please. Regards, Terry Jones

3 years, 5 months

Re: [TUHS] Brian Kernighan and very early *roff history

by jnc＠mercury.lcs.mit.edu

> From: Angelo Papenhoff > to my knowledge no troff version before the C rewrite in v7 Apologies if I missed something, but between this list and COFF there's so much low S/N traffic I skip a lot of it. Having said that, was there ever a troff in assembler? I'd always had the impression that the first one was in C. > The v6 distribution has deleted directory entries for troff source but > not the files themselves. I hope it is not lost. Maybe someone here has > an idea where it could be found? The MIT 'V6+' (I think it's probably basically PWB1) system had troff - i guess it 'fell off the back of a truck', like a lot of other stuff MIT had, such as 'typesetter C', the Portable C Compiler, etc. Theirs was modified to produce output for a Varian (I forget which model, maybe the docs or driver say). nroff on that system seems to have been generated from the troff sources; the assembler nroff sources aren't present. I looked at its n1.c, and compared it to the V7 one: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff/n1.c and this one appears to be slightly earlier; e.g. it starts: #include "tdef.h" #include "t.h" #include "tw.h" /* troff1.c consume options, initialization, main loop, input routines, escape function calling */ extern int stdi; and in the argument processing, it has quite a lot fewer. So that one is a "troff version before the C rewrite in .. v7", but it is in C. Is that of any interest? Noel

3 years, 5 months

Brian Kernighan and very early *roff history

by Tom Lyon

Most of y'all are aware of Brian Kernighan's troff involvement. My understanding is that he pretty much took over nroff/troff after Joe Ossana died, and came out with ditroff. But Brian had much earlier involvement with non-UNIX *roff. When he was pursuing his PhD at Princeton, he spent a summer at MIT using CTSS and RUNOFF. When he came back to P'ton, he wrote a ROFF for the IBM 7094, later translated to the IBM 360. Many generations of students, myself included, use the IBM ROFF (batch, not interactive) as a much friendlier alternative to dumb typewriters. I don't know if 360 ROFF spread beyond Princeton, but I wouldn't be surprised. BTW, during my summer at Bell, nroff/troff was one of the few programs I could not port to the Interdata 8/32 - it was just a mess of essentially typeless code. I don't think Joe Ossana got around to it either before he died. -- - Tom

3 years, 5 months

struct(1) revived! And a request for help

by arnold＠skeeve.com

Hello All. We recently discussed Brenda Baker's struct program, that read Fortran and generated Ratfor. Many of us remarked as to what a really cool program it was and how much we admired it, myself included. For fun (for some definition of "fun") I decided to try to bring the code into the present. I set up a GitHub repo with the V7, V8 and V10 code, and then started work in a separate branch. (https://github.com/arnoldrobbins/struct, branch "modernize".) The program has three main parts: - structure, which reads Fortran and outputs something that is almost Ratfor on standard output. - beautify, which reads the output of structure and finishes the job, primarily making conditions readable (.not. --> !, removing double negatives, etc.) - struct.sh - a simple shell script that runs the above two components. This is what the user invokes. The code was written in 1974. As such, it is rife with "type punning" between int, int *, int **, and char *. These produce a lot of warnings from a modern day C compiler. The code also uses a, er, "unique" bracing style, making it nearly illegible to my stuck-in-a-rut programming brain. Here is what I've accomplished so far: * Converted every function definition and declaration to use modern (ANSI) C style, adding a header file with function declarations that is included everywhere. * Run all the code through the indent program, formatting it as traditional K&R bracing style, with tabs. * Fixed some macros to use modern style for getting parameter values as strings into the macros. * Fixed a few small bugs here and there. * Fixed beautify to work with modern byacc/bison (%union) and to work with flex instead of lex. This latter was a challenge. In structure, only three files still generate warnings, but they all relate to integer <--> pointer assignment / use as. However, when compiled in 32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer), despite the warnings, structure works!! Beautify works, whether compiled in 32 or 64 bit mode. What I've done so far has been mostly mechanical. I hereby request help from anyone who's interested in making progress on "the hard part" --- those three files that still generate warnings. I think the right way to go is to replace int's with a union that holds and int, a char* and an int*. But I have not had the quiet time to dive into the code to see if this can be done. Anyone who has some time to devote to this and is interested, please drop me a note off-list. Thanks, Arnold Robbins

3 years, 5 months

Re: [TUHS] TeX and groff (was: roff(7))

by Jon Forrest

This is clearly getting off track of TUHS. I'll stop after this reply. > *From:* Blake McBride <blake1024(a)gmail.com> > *Date:* January 11, 2022 at 2:48:23 PM PST > *To:* Jon Forrest <nobozo(a)gmail.com> > *Cc:* TUHS main list <tuhs(a)minnie.tuhs.org> > *Subject:* *[TUHS] TeX and groff (was: roff(7))* > Although I'm not connected with the TeX community, I don't agree with > much of what you said. > > 1. TeX source to C is fine - stable and works. It would be > impossible to rewrite TeX in any other language without introducing > bugs and incompatibilities. Leaving TeX as-is means that it can be > converted to other languages too if/when C goes out of style. TeX > as-is is exactly what it is. Anything else wouldn't be TeX. I agree that Web->C works but it's a major obstacle in doing any development work on TeX. Try making a major change in the Web source that requires debugging. Anything that can pass the TeX Trip Test can be called TeX. I know of a full C reimplementation that passes the test but the author doesn't want to make it free software. There are other rewrites out there that could be candidates but someone will enough power will have to proclaim one as the official TeX alternative. > 2. Drop DVI? Are you kidding me? Although PDF may be popular now, > that may not be the case 20 years from now. A device-independent > format is what is needed, and that's what DVI is. TeX is guaranteed > to produce the exact same output 100 years from now. And .PDF isn't? .DVI was great until .PDF matured. .DVI has almost no penetration these days, whereas .PDF is everywhere. I'm not saying that .PDF will always be the proper alternative but a properly rewritten TeX should make it much easier to replace .PDF will whatever comes next. > 3. I am curious about memory limitations within TeX. TeX has various fixed sized memory pools, and contains clever code to work around limited memory. Some of the newer TeXs, like LuaTeX, use dynamic allocation but this isn't official. Given how primitive things were when TeX was developed it's a miracle it works as well as it does. > 4. Knuth is getting up in age. Someone will have to take over. Exactly. I don't follow the TeX community so I don't know what they're doing about this. Jon Forrest

3 years, 5 months

Coastal cultures, collaboration, creativity and Sun vs DEC.

by Dan Cross

I've been meaning to ask about this for a while.... "... The reason why is because there was tremendous antagonism between New York and L.A. L.A. was, you know, full of color, full of acid, full of hippies, and we were not like that. We dressed in black and white. We did not like free love. ..... We took amphetamine; they took LSD. They were, you know, sort of loving and happy, and we were - we weren't really evil, we were more intellectual, more about art." [Mary Woronov, in an interview with NPR's Terry Gross on "Fresh Air", talking about New York City, Warhol's Factory and shows in Los Angeles while touring with the Velvet Underground: http://www.npr.org/templates/transcript/transcript.php?storyId=241437872] Note: I am not suggesting that anyone involved with Unix ever took amphetamines, nor, despite the usual crack about LSD and BSD, that anyone on the west coast was taking acid, though Markov's "What the Dormouse Said" would indicate that many of you WERE tripping. It seems like Unix is largely a child of the coasts. Notable work in Utah, Colorado and Chicago aside, it seems the bulk of early Unix work happened in either the greater New York metro area in northern New Jersey or the greater Bay area around San Francisco. Notable work was also done in Massachusetts, but again, that's a coastal state and I think it's fair to say that most of that was inside the route 128 corridor. Of course work was done internationally, but I'm particularly curious about differences in US culture here, and how they influenced things. The question is, to what extent did differences in coastal cultures influence things like design aesthetics? I think it's is accurate to characterize early BTL Unix by it's minimalism, and others have echoed this (cf. Richard Gabriel in the "Worse is Better" papers). But similarly, BSD has always felt like a larger system -- didn't Lions go as far as to quip about the succinctness of 6th Edition being "fixed" by 4BSD? Anyway, I believe it is fair to say that early Unix has a rather distinct feel from later BSD-derived systems and the two did evolve in different geographic locations. Furthermore, the world was not as connected then as it is now. So to what extent, if any, was this a function of the larger cultural forces at play near where that work was taking place? - Dan C.

3 years, 5 months

Re: [TUHS] TeX and groff (was: roff(7))

by Douglas McIlroy

> If I can be so bold as to offer an interpretation: Doug's approximations > treat ellipses as mathematical objects and algorithmically determine what > pixels are closest to points on the infinitesimally-thin curves, while > Knuth's (or one his students') method acknowledges that the curve has a > width defined by the nib Just so. > I find it impossible that neither Knuth nor Hobby were unaware of McIlroy's > work and vice-versa; of course he would have known about and examined troff > just as the Bell Labs folks knew about TeX. We were generally aware of each other's work. My papers on drawing lines, circles, and ellipses on rasters, though, were barely connected to troff. Troff did not contain any drawing algorithms. That work was relegated to the rendering programs that interpreted ditroff output. Thus publication-quality rendering with support for thick lines was outsourced to Adobe and Mergenthaler. Various PostScript or ditroff postprocessors for screen-based terminals were written in house. These programs paid little or no attention to fonts and line widths. But the blit renderers made a tenuous connection between my ellipse algorithm and troff, since my work on the topic was stimulated by Rob's need for an ellipse generator. Doug

3 years, 5 months

Re: [TUHS] moving directories in svr2

by jnc＠mercury.lcs.mit.edu

> From: Bakul Shah > My guess is *not* storing a path instead of a ptr to the inode was done > to save on memory. More probably speed; those old disks were not fast, and on a PDP-11, disk caches were so small that converting the path to the current directory to its in memory inode could take a bunch of disk reads. > Every inode has a linkcount so detecting when the last conn. is severed > not a problem. Depends; if a directory _has_ to be empty before it can be deleted, maybe; but if not, no. (Consider if /a/b/c/d exists, and /a/b is removed; the tree underneath it has to be walked and the components deleted. That could take a while...) In the general case (e.g. without the restriction to a tree), it's basically the same problem as garbage collection in LISP. Noel

3 years, 5 months

Re: [TUHS] *roff history as told to GNU

by jnc＠mercury.lcs.mit.edu

> From: Dan Cross > a port of the _CTSS_ BCPL ROFF sources purportedly written by Doug. I > wonder if that was actually a thing, or an error? > ... > Fortunately, the source [of the original CTSS runoff] is online: > ... > Indeed; one finds the following in at least one of the Multics RUNOFF > source files: It sounds like all the steps in the chain have pretty definitive evidence - _except_ whether there was ever a CTSS RUNOFF in BCPL, from Doug. Happily, we have someone here who should be able to answer that! :-) Noel

3 years, 5 months

Re: [TUHS] TeX and groff (was: roff(7))

by Jon Steinhart

Been reading the heirloom docs. Remember one thing that I disliked about troff which maybe Doug can explain. It's the language in the docs. I never understood "interpolating a register" to have any relation to the definition of interpolate that I learned in math. Made it a bit hard to learn initially. Any memory of why that term was used?

3 years, 5 months

Coastal cultures, collaboration, creativity and Sun vs DEC

by Douglas McIlroy

> most, if not all of these things were after I arrived. That may indicate the youth of the narrator more than a lightening of the culture. Some practical jokes and counter-culture customs from an earlier day: When I joined the Labs, everyone talked about the escapades of Claude Shannon and Dave Hagelbarger--unicycle, outguessing machines, the finger-on-the-switch box, etc. When John Kelly became a department head he refused to have his office carpeted. That would have kept him from stubbing out cigarettes on the floor. Bill Baker may have worn a coat and tie, but he kept a jalopy in his VP parking space. Another employee had a rusty vehicle with weeds growing out of the fenders. As early as 1960 BESYS began appending fortune cookies to every printout. The counter where printouts were delivered got messed up by people pawing around to see others' fortunes. One day the audio monitor on the low bit of the 7090 accumulator stopped producing white noise (with an occasional screech for an infinite loop) and intoned in aTexas drawl, "Help, I'm caught in a loop. Help. I'm caught in a loop. Help ..." A pixelated nude mural appeared in Ed David's office. (Maybe this no longer counts as a prank. It is now regarded as a foundational event in computer art.) Ed Gilbert had a four-drawer filing cabinet labeled integers, rationals, reals, and balloon. The latter held the tattered remains of lunchtime hot-air experiments. He also had a chalkboard globe with a world map on it. It sometimes took several spins before a visitor realized that you really shouldn't be able to see all the continents at once--the map appeared twice around the circumference of the globe. CS had a Gilbert-and-Sullivan duo, Mike Lesk and Peter Neumann, who produced original entertainment for department parties. Doug

3 years, 5 months

(no subject)

by Douglas McIlroy

> Ken and Dennis were teaching [the Votrax] to swear "Speak" being a phonetics-based program, I suspect they were exploring multiple spellings. Out of context, lots of spellings were indistinguishable. For example, cheap, cheat, cheek, chief was hard to tell from cheep, cheep, cheep, cheep.. At the risk of repeating myself, the fuck, fuck, fuck, fuck example came to the fore when a "speak" kiosk was installed at Epcot. PR folks were worried that people would try it on bad words in this public setting and asked me to block them. I said I'd block whatever words they told me to. Duly, I was sent a list--on the letterhead of an AT&T vice president. (Was that dictated to a secretary?) Later I heard that girls would often try friends' names, while boys would try bad words and exclaim that the machine didn't know them. In fact, those were among the few words the machine *did* know. Fortunately nobody ever complained that I hadn't blocked misspellings. Doug

3 years, 5 months

Re: [TUHS] Demise of TeX and groff (was: roff(7))

by Douglas McIlroy

> Later Brian's work was updated after V7 and included some new tools, and became known as Writer's Workbench, which eventually was entered in the 'toolchest.' WWB wouldn't exist if text had not routinely existed in machine-readable form, thanks to word-processing. But the impetus for WWB came from "style", not from troff. Style was a spinoff of Lorinda Cherry's "parts", which assigned parts of speech to the words of a document. Style provided a statistical profile of the text: measures such as average word length: frequency of passives, adjectives and compound sentences, reading level, etc. WWB in turn offered writing advice based on such profiles. Style was stimulated by Bill Vesterman, a professor of English at Rutgers, who brought the idea to me. I introduced him to Lorinda, who had it running in a couple of weeks. Then Nina McDonald at USG conceived and packaged WWB as a distinct product, not just a collection of entries in man 1. Wikipedia reports a surmise that WWB sank out of sight because it was not a standard part of Unix distributions. Doug

3 years, 5 months

Re: [TUHS] TeX and groff (was: roff(7))

by Jon Steinhart

Steffen Nurpmeso writes: > Note that heirloom doctools (on github) is a SysV-derived *roff Wow, thanks for mentioning this. I was unaware of it. When I recently wrote that it would be nice to add TeX's 2D formatting to troff I didn't realize that it had already been done. Something new to play with. Jon

3 years, 5 months

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