- TUHS - www.tuhs.org

by Tom Lyon

Anyone sitting on piles of old UNIX newsletters? I find they make for fascinating reading. I haven't found any online archives. If you have a pile, I can scan them. I'm going to scan my 3 copies of commUNIXations, the /usr/group newsletter, and 4 copies of "UNIQUE - Your independent UNIX and C Advisor" - all from 1983/4. Warren can hopefully find a home for these.

4 days, 4 hours

9
11
0 0

xview and open motif files

by arnold＠skeeve.com

Hi All. I found the following files recently: $ ls -l total 8748 -rw-r--r-- 1 arnold ftpusers 5661471 Oct 1 2007 openmotif-2.3.0.tar.gz -rw-r--r-- 1 arnold ftpusers 4888 Jan 18 1999 xvfc.tar.gz -rw-r--r-- 1 arnold ftpusers 3281277 Jan 18 1999 xview3.2.tar.gz They can be retrieved under https://www.skeeve.com/X11/. I have sent them to Warren, who currently has them in his hidden archive. I also have a copy of the OpenLook CDROM, but I notice it's available from GitHub: https://github.com/IanDarwin/OpenLookCDROM. Enjoy, Arnold

5 days, 20 hours

3
3
0 0

Texas UNIX Users Conference 1981

by norman＠oclsc.org

This note gets a bit COFF-y; please redirect any replies to that list. USENIX Summer 1981, in Austin TX. First USENIX conference I ever attended, and the first to which I travelled by train-- mostly. I was somewhat shy about travelling in those days, but my Caltech colleague Mark Bartelt talked me into going, and suggested going by train. Except by the time I booked the trip there was space available only from Los Angeles to San Antonio and back, not onward from San Antonio to Austin. But in those days I did a bit of cycle touring, often in the company of my friend Brian Foster. Brian was also a co-worker at the time, and was interested in attending too. So we decided to travel together by train (in coach) to San Antonio, arriving around 05h30, and spent the rest of that day cycling, mostly up the frontage roads beside I-35, to Austin. After the conference we cycled back, mostly at night, which was somewhat spooky (I remember seeing a thunderstorm off on the horizon but we didn't get rained on) but saved us a second dose of sunburn. They checked into a motel for a day and a night until the return train came through at 02h55. I have gone by train to nearly every other conference I've attended since, but never again have I cycled. It was a fun ride but a harder one than expected. In those days of paper mapes, we visited the Caltech geography department and plotted out what looked like a fairly smooth route, with a slow but steady climb. The topo map we used had a resolution of 50' altitude. Evidently the constant, sometimes steep hills between San Antonio and Austin are all no more than 49' tall. It was a good conference too. One memory that sticks in my head was Jim Joyce using Tinker Toys as a metaphor for connecting Unix tools together. Norman Wilson Toronto ON

2 weeks

1
0
0 0

Re: X.25 stacks on Unix

by Rudi J. Blom

Greg, a long time a go while still working for Computer Division of Philips Electronics I used X.25 and X.21 extensively on various proprietary O.S.-es. X.25/X.21 (or PSDN/CSDN) was used for Teletex (CCITT T series, TTX, better than telex but lost to FAX which was easier, cheaper and legally acceptable). I still have some dedicated boards which Philips used for X.25, X.21 and SDLC. At a customer side in a test environment with SCO UNIX 3.2V4.2 SDLC links are still used, X.25 was phased out a few years ago. Same with DEC Tru64, a multi-port SYNC-2000 with appropriate DEC software could support both X.25 and SDLC. AlphaServer DS25 with SDLC links still in production. I still have all the applicable software for SCO UNIX and DEC Tru64. Cheers, uncle rubl -- The more I learn the better I understand I know nothing. 24 x 7 is not enough but my request for 25 x 8 is still under consideration. 24 x 7 is not enough but my request for 25 x 8 is still under consideration 24 x 7 is not enough but my request for 25 x 8 is still under consideration 24 x 7 is not enough but my request for 25 x 8 is still under consideration

2 weeks

2
1
0 0

Texas UNIX Users Conference 1981

by Tom Lyon

I just discovered that this issue of the Australian UNIX User Group Newsletter contains summaries of all the talks and sessions from the Usenix Texas UNIX Users Conference - Summer 1981. https://vtda.org/pubs/AUUGN/AUUGN-V03.4.pdf In what I believe was my first public speaking role I presented "UNIX vs Godzilla -- UNIX in an IBM Environment" Lots of other familiar names in those notes too.

2 weeks

1
0
0 0

Where/when did TUIs come from

by Adam Koszek

Hi, I got interested in UI design and often study some historical aspects of it as I work on software. It’s hard not to notice how fast/usable Text User Interfaces are—ncurses and its siblings are still alive and well. From the ergonomy point of view, not needing a mouse in those interfaces if perfect. Question: where did TUIs come from originally, and what were their earliest instances? Many pages state that Vi was the first, but I’ve been looking through some old hardware photos, and things capable of more sophisticated interactions existed before Vi: https://en.wikipedia.org/wiki/Light_pen Some terminals with block display: https://en.wikipedia.org/wiki/IBM_3270 ^ ’71. Wiki says Vi showed up in ’76, but I suspect IBM mainframes may have had TUIs before. Question 2: were there any manuals talking about TUIs? I’m thinking some of those spiffy IBM things mandating certain design. Thanks, Adam

2 weeks, 6 days

12
16
0 0

Origins of touch(1)

by Joseph Holsten

A TikTok user was asking the history of the touch(1) command: https://www.tiktok.com/t/ZTjgSMyAQ/ Unix history repo let me find the first occurrence in V7: https://github.com/dspinellis/unix-history-repo/blob/Research-V7-Snapshot-D… But looking at ls source in V6, it’s clear that stat(2) had st_mtime so touch would have been useful earlier. I notice make was added at the same time, which cares significantly about mtime. Was that the impetus? (Also, wow just writing a single char! Compared to present day impls which give fine grained control to modify mtime & atime, the original seems both indirect for the purpose and delightfully literal.) -- Joseph Holsten http://josephholsten.com mailto:joseph@josephholsten.com tel:+1-360-927-7234

3 weeks, 1 day

8
11
0 0

Your Most Prized UNIX Artifacts?

by segaloco

As someone who has been quite attentive to the documentation situation with UNIX, I've managed to build out a pretty appreciable library of historic works. Among my most treasured bits are my 3B20S Release 4.1 manual and Bell Labs copies of the Lions's Commentary. What do folks have around that you're particularly thrilled to have among your UNIX-y possessions? - Matt G.

3 weeks, 3 days

36
47
0 0

Do you have any historical UNIX computers?

by Vicente Collares

Hello TUHS people! Someone recently posted a question about your prized UNIX artifacts to this list, that discussion [1] seems to be about various memorabilia. What about computers made to run UNIX? Do you have or used to any interesting historical hardware? For my part, I have only used UNIX on emulated systems so far but would like to purchase some hardware. Given that I have little space it would need to be something small. According to you how does one get into that specific type of retro computing? See you around cyberspace, Vicente vicente(a)collares.ca [1] https://www.tuhs.org/pipermail/tuhs/2025-June/032020.html

3 weeks, 3 days

11
19
0 0

How did Dennis Ritchie typeset his PhD Thesis? A Typographical mystery

by Dan Cross

I just ran across this. Fascinating: https://fermatslibrary.com/s/how-did-dennis-ritchie-produce-his-phd-thesis-… - Dan C.

3 weeks, 4 days

3
2
0 0

MACRO-11

by Henry Bent

Hi all, Do sources exist for a MACRO-11 assembler for UNIX? The only package I have found is written in MACRO-11 and relies on a provided binary to regenerate itself; it's on the brl.pdp11 archive on the CSRG DVD. -Henry

3 weeks, 5 days

8
14
0 0

Re: Do you have any historical UNIX computers?

by H.J.Thomassen

I still have two 19" racks with the main components of the PDP-11/45, built in 1972, on which we started using UNIX 5th Edition in late summer 1974. Later it ran 6th and 7th Ed. CPU with front panel w. switches and lamps, RK03 cartridge disk (2.5Mb!), floating point processor board (serial number 1), several core memory banks among which 8K ones, DEC-tape, ASR33-TTY, dozens of mini-lightbulbs, not a single LED. Its hour-meter has clocked 122532: that's 13,97 years. It is complete but doesn't run. I remember from the days when I administered it during its productive life that it required .5 day of maintenance per six weeks, by a qualified service engineer: tuning power supplies, adjusting the disk head with the help of a special "alignment" disk cartridge, checking the fans (25+ in just those two racks), etc. etc. The CPU consists of 17 large PCBs. The combined MTBF of these PCBs was 1.5 years approx. Then the service engineer came with his box with exchange boards and swapped until the machine was up&running again. Without a maintenance contract such a board had a 5-figure exchange fee..... Hendrik-Jan Thomassen

3 weeks, 5 days

1
0
0 0

Re: Do you have any historical UNIX computers?

by Vicente Collares

Hello Milo, On Mon, 9 Jun 2025 13:38:54 -0400 Milo Velimirović <milovelimirovic(a)gmail.com> wrote: > What’s your budget and what’s your level of hardware technical skill? If budget is no concern, there are occasional complete pdp11 or vaxen on eBay. Or, you could get CPU cards and interfaces to piece together a system. If you go that route a Unibone or Qbone is highly recommended for both debugging and filling in hardwar gaps via emulation. Alternatively, there are several FPGA projects to emulate -11s. Buying a complete PDP-11 or VAX is the dream, but it's not what I'm aiming for to start. I was thinking of something like a UNIX workstation. I haven't thought about the possibility of piecing together a system using various cards. Thanks for pointing that out, I'll have to look into it. Budget is a concern for me. So ideally I would like to spend around $500 USD on the actual computer. Is that realistic for the type of computer I mentioned above? I'm not hardware savvy, so I would have a limited ability to do repairs on the electronics. I do know someone who is though, so I might be able to get some help on this project. I wish you an excellent week, Vicente vicente(a)collares.ca

3 weeks, 5 days

7
14
0 0

Re: Do you have any historical UNIX computers?

by jnc＠mercury.lcs.mit.edu

> From: Vicente Collares > I'm more interested in its historical signaficance. If that's your interest, PDP-11's are absolutely _the_ way to go. The PDP-11 is _the_ machine that made UNIX. That choice has good points, and a very bad point, though. Good points are that QBUS PDP-11's are pretty easy to find, pretty small (desktop PC-sized), and not very expensive. They're pretty robust, too - I have a large stack of PDP-11 QBUS CPUs, and none of them had failed, as of the last time that I powered them on. The very bad point is that working mass storage for them is very hard to find. The controllers are around, but not the drives. Does anyone know if anyone is making a QBUS mass storage clone? Bridgham and I were going to produce QBUS RK11/RP11 clone that used SD cards to hold the bits. We got the prototype working, and it booted UNIX, but then I came down with COVID and post-COVID myalgic encephalomyelitis, and that was the end of that. Noel

3 weeks, 6 days

4
3
0 0

Re: Your Most Prized UNIX Artifacts?

by Paul McJones

> On Mon, 9 Jun 2025 15:16:08 -0400, Henry Bent <henry.r.bent(a)gmail.com <mailto:henry.r.bent@gmail.com>> wrote: > > On Mon, 9 Jun 2025 at 14:59, Lawrence Stewart <stewart(a)serissa.com <mailto:stewart@serissa.com>> wrote: > >> My rare items are only Unix-adjacent. ... I have some boards for a Digital >> Firefly, a research vax multiprocessor that ran a Modula-2 based OS that >> would run Ultrix binaries. > > That's incredibly cool. Do you know if any of the Firefly machines > survived? I saw a VAXstation 3540 for sale at some point recently but it > was well out of my price range; I hope it found a good home. > > -Henry I have a set of Firefly boards (I worked on the Taos operating system for the Firefly). But as far as I can tell, no software survives. Charles P. Thacker and Lawrence C. Stewart. 1987. Firefly: a multiprocessor workstation. In Proceedings of the second international conference on Architectual support for programming languages and operating systems (ASPLOS II). Association for Computing Machinery, New York, NY, USA, 164–172. https://doi.org/10.1145/36206.36199 Paul McJones and Garret Swart. Evolving the UNIX system interface to support multithreaded programs. Proceedings of the Winter 1989 USENIX Conference, December 1989. http://www.mcjones.org/paul/evolving.pdf Also available as Part I of SRC Research Report 21 (https://mcjones.org/paul/SRC-RR-21.pdf) Part II of which is the Taos Programmer's Manual. Paul McJones and Andy Hisgen. The Topaz system: Distributed multiprocessor personal computing. Workshop on Workstation Operating Systems. IEEE Computer Society Technical Committee on Operating Systems, November 1987. http://www.mcjones.org/paul/wwospos.pdf (Topaz was the name for the Modula-2+ programming environment, which also ran on VAX Ultrix.) Paul

4 weeks

1
0
0 0

Re: Your Most Prized UNIX Artifacts?

by norman＠oclsc.org

I have a number of old Unix artifacts that I value. If I had to pick one (or one set) top one, it would be the complete set of Research Unix manuals, 1/e through 10/e. Other contenders include the AT&T-branded copy of the Lions commentary (with deathstar on the cover), a signed copy of The Unix Programming Environment, several unix-branded plastic containers (not to do with the OS, but bought from a Korean supermarket a few blocks from where I've lived for 30 years), and a plastic-slide Spin Out puzzle from Binary Arts (later ThinkFun but not part of IBM), an educational puzzle/game company founded in the 1980s by Bill Ritchie (Dennis's brother) and his wife Andrea Barthello. (I remember a prototype Spin Out, hand-made of wood, spending some time in the Unix Room.) But far more than any of that, I prize the memories and friendships I've had with fellow Unix people over the decades, particularly (but not exclusively) from my six years as sysadmin-hack in 1127. I'm very disappointed that I won't be at the last-ever USENIX Technical Conference in Boston in a few weeks. A show-and-tell there of prized artifacts sounds like a great idea. I hope those who do make it bring plenty of artifacts and memories to share. Norman Wilson Toronto ON

4 weeks, 1 day

1
0
0 0

Re: Your Most Prized UNIX Artifacts?

by Douglas McIlroy

A complete set of manuals,v1-v10. The 8-volume History of Engineering and Science in the Bell System--not really a Unix artifact but an impressive memento of the Bell Labs experience. Unix rates several pages in it. A mock license plate, generously given to me by Jon Hall. A polyomino puzzle that I solved with the help of Gerard Halzmann's Spin model-checker. The opportunity for such an "abuse of tools" illuminates Unix and CSRC as a productive meeting place for disparate disciplines, occupations, and pastimes. Doug

4 weeks, 1 day

1
0
0 0

No Further LLM messages on TUHS

by Warren Toomey

All, the LLM conversation is no longer Unix-related. Please take it to COFF if you wish to continue it. Thanks, Warren

1 month, 1 week

1
0
0 0

Re: On the unreliability of LLM-based search results (was: Listing of early Unix source code from the Computer History Museum)

by norman＠oclsc.org

G. Branden Robinson: That's why I think Norman has sussed it out accurately. LLMs are fantastic bullshit generators in the Harry G. Frankfurt sense,[1] wherein utterances are undertaken neither to enlighten nor to deceive, but to construct a simulacrum of plausible discourse. BSing is a close cousin to filibustering, where even plausibility is discarded, often for the sake of running out a clock or impeding achievement of consensus. ==== That's exactly what I had in mind. I think I had read Frankfurt's book before I first started calling LLMs bullshit generators, but I can't remember for sure. I don't plan to ask ChatGPT (which still, at least sometimes, credits me with far greater contributions to Unix than I have actually made). Here's an interesting paper I stumbled across last week which presents the case better than I could: https://link.springer.com/article/10.1007/s10676-024-09775-5 To link this back to actual Unix history (or something much nearer that), I realized that `bullshit generator' was a reasonable summary of what LLMs do after also realizing that an LLM is pretty much just a much-fancier and better-automated descendant of Mark V Shaney: https://en.wikipedia.org/wiki/Mark_V._Shaney Norman Wilson Toronto ON

1 month, 1 week

17
21
0 0

Re: 1972 UNIX V2 "Beta" Resurrected

by Thalia Archibald

Yufeng Gao wrote: > The s1 tape is a UNIX INIT DECtape containing the kernel, while s2 includes > most of the distribution files. [https://www.tuhs.org/pipermail/tuhs/2025-February/031420.html] Hello Yufeng, Do you have more details on the format of the s1 tape? I want to reproduce your work. The s2 tape is in the tap format, which was easy to decode, and I assumed that s1 was similar, just with its file headers on an earlier tape. I’ve been able to fairly accurately segment s1 into files by observing that blocks duplicate the tail of the previous block when they are not a full 512 bytes. I’ve written a tool for this and have segmented all the text files and some of the binaries, but I’m floundering on the rest. What you say seems to suggest that s1 actually does have file metadata. Thalia

1 month, 1 week

3
2
0 0

Open source "code" for books typeset in troff

by Adam Koszek

Hello, troff.org <http://troff.org/> maintains a nice list of UNIX/networking books typed in troff: https://troff.org/pubs.html#advctt https://troff.org/books.html#strong There’s one book that’s been released out of the publisher’s copyright, transcribed, and the source is available: https://github.com/larrykollar/Unix-Text-Processing Are there any other other long text/books that have the source code available? The only thing that I can think or are the manuals present in source trees of the current BSD systems. Thanks, Adam

1 month, 1 week

6
7
0 0

Several QD-600A Tapes from Bell Labs Circa Early 90s

by segaloco

Hello everyone, I'm just putting feelers out for a potential data recovery project that may have some UNIX history nuggets hiding somewhere. I just closed on this auction: https://www.ebay.com/itm/267254963191 After the link is an action for a set of 17 Sony QD-600A tapes featuring various backups from at least one machine named Zeus. The listing indicates they were property of a former Western Electric engineer. At least one tape has a label indicating a full /usr backup. My hope is that something downstream of the BTL internal version of System V might be living amongst these tapes, but either way I was wondering if anyone here with access to the correct tape drive would be willing to assist with ripping these tapes? I can also start hunting down a drive but figured I'd ask around first. I'm not currently spotting a drive on eBay but have a few other places I can ask around. Thanks for any input! - Matt G.

1 month, 1 week

5
8
0 0

Re: Demise of AT&T

by jnc＠mercury.lcs.mit.edu

> From: Steve Jenkin > An unanswered question about Silicon Valley is: > Why did it happen in California and not be successfully cloned > elsewhere? One good attempt at answering this is in "Making Silicon Valley: Innovation and the Growth of High Tech, 1930-1970", by Christophe Lecuyer; it's also a very good history of the early Silicon Valley (before the mid-1960's). Most of it's available online, at Google: https://books.google.com/books?id=5TgKinNy5p8C I have neither the time nor energy to comment in detail on your very detailed post, but I think Lecuyer would mostly agree with your points. > It wasn't just AT&T, IBM & DEC that got run over by commodity DRAM & > CPU's, it was the entire Minicomputer Industry, effectively extinct by > 1995. Same thing for the work-station industry (with Sun being merely the most notable example). I have a tiny bit of second-hand personal knowldge in this area; my wife works for NASA, as a structural engineer, and they run a lot of large computerized mathematical models. In the 70's, they were using CDC 7600's; they moved along through various things as technology changed (IIRC, at one point they had SGI machines). These days, they seem to mostly be using high-end personal computers for this. Some specialized uses (various forms of CAD) I guess still use things that look like work-stations, but I expect they are stock personal computers with special I/O (very large displays, etc). So I guess now there are just supercomputers (themselves mostly built out of large numbers of commodity CPUs), and laptops. Well, there is also cloud computing, which is huge, but that also just uses lots of commodity CPUs. Noel

1 month, 1 week

16
21
0 0

Is there a way to mirror Stevens' kohala.com ?

by Adam Koszek

Hi I recently noticed that some references from Richard Stevens’ website aren’t working: https://www.kohala.com/ - many links are broken, including links to the resources that worked before. I found some sub-directory there that appears to have copies of referenced files: http://www.kohala.com/start/ I’d be willing to chip in some $ to extend his domain + server to just work, in case anybody here knows the right people. I also wondered whether we could mirror his site on TUHS? Thanks, Adam

1 month, 1 week

2
3
0 0

Re: Is there a way to mirror Stevens' kohala.com ?

by jnc＠mercury.lcs.mit.edu

> From: Adam Koszek > Try to access his: > Stevens, W. R. 1989. "Heuristics for Disk Drive Positioning in > 4.3BSD," Computing Systems, vol. 2, no. 3, pp. 251-274 (Summer). I'm getting the exact same error you are, so it's nothing specific to your side. There is another copy of that paper here: https://www.usenix.org/legacy/publications/compsystems/1989/sum_stevens.pdf though. (Multiple copies of things are _somewhat_ common.) Noel

1 month, 1 week

1
0
0 0

Off topic: Does anyone know what's going on with the PCC Revived project?

by Aharon Robbins

I'm hoping that someone hear (*BSD folks?) might know what's happened with the PCC Revived project. The site and CVS server for it went offline in October 2023 or so, and I lost the email address for Ragge who was doing it. Thanks, Arnold

1 month, 1 week

11
23
0 0

Re: shells, Re: Listing of early Unix source code from the Computer History Museum.

by jnc＠mercury.lcs.mit.edu

> From: Noel Chiappa > the PWB shell (which I guess Massey worked on; hence the name) Someone pointed out to me that I needed to do a: 1,$s/Massey/Mashey/g The pitfalls of creating replies in editor buffers: typos get replicated! Noel

1 month, 1 week

1
0
0 0

Re: shells, Re: Listing of early Unix source code from the Computer History Museum.

by jnc＠mercury.lcs.mit.edu

> From: "John Levine" > I had heard that called the Mashey shell, also according to Wikipedia > the PWB shell. Wikipedia content is a little better than LLM output, but not much! (The best thing in Wikipedia is the referencs.) The changes to the Thompson shell to make the PWB shell (which I guess Massey worked on; hence the name) are laid out pretty well in "UNIX Time-Sharing System: The Programmer's Workbench" (of which Massey is a co-author): https://archive.org/details/bstj57-6-2177 The projects which used PWB made extensive use of shell command files. So, PWB made two kinds of changes to the shell: i) flow-of-control commands used in shell procedures were made built-ins (which gave a huge decrease in fork() overhead), and ii) minor enhancements to shell command semantics (variables, evaluation of expressions, nestable control structure), which made shell command files much more powerful (and thus used a lot more). Minnie's 'version comparison tool' is useful to use to compare the 'Massey' shell: https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s2/sh.c with the vanilla V6 ('Thompson') shell. The PWB shell is definitely a tweaked version of the Thompson shell. Noel

1 month, 1 week

1
0
0 0

Listing of early Unix source code from the Computer History Museum.

by Jackson Helie G

What program's source code is on pages 145 - 169 (assembly listings are t1 - t8) in the CHM release of UNIX BOOK II?

1 month, 1 week

7
7
0 0

Re: Listing of early Unix source code from the Computer History Museum.

by jnc＠mercury.lcs.mit.edu

> From: Adam Thornton > Maybe this is what "the shell" looked like before Bourne shell came > along. Huh? The Bourne shell was done in the late V6 era, and was included in the release, starting with V7. The classic shell (the Thompson shell, originally) was included starting with V1: http://squoze.net/UNIX/v1man/man1/sh That one was written in PDP-11 assembler: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/sh.s but by V5 it had been re-written in C: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s2/sh.c Mind, I'm not saying that your theory as to what the code being enquired about does is wrong; but the theory that 'this is what the shell was before the Bourne shell' does seem to be off base. Noel

1 month, 1 week

2
1
0 0

Listing of early Unix source code from the Computer History Museum.

by Norman Wilson

I don't know what t1-t8 are, but they're not the shell. The shell, labelled sh, is pages 100-106 of the same book. LLMs are not search engines. They are bullshit generators. Norman Wilson Toronto ON

1 month, 1 week

2
1
0 0

Interesting things about B and NB languages

by Jackson Helie G

Anything interesting in developing B and NB languages?

1 month, 2 weeks

2
1
0 0

Re: Demise of AT&T

by Steve Jenkin

Ric, Thanks for the Real World ‘ground truth’! You’ve woken me up to when the Mythical Golden Years had evaporated. I’ve had my head buried in historical commentary, mainly the 1950’s & 1960’s. Before Silicon Valley got rich :( The net effect of people dealing in Real Estate for 150 years isn’t ‘cheap housing’. Thanks very much for the correction. For my own reference, I should really say ‘once cheap real estate’ or ‘historically cheap’. From the 1850’s to 1900, land was exceedingly cheap in The Wild West, but not for 50 years :( cheers steve j > On 19 May 2025, at 09:05, Rik Farrow <rik(a)rikfarrow.com> wrote: > > Hi Steve: > > Nice analysis, although I would disagree with you on one point: > > > Other people point to the climate, cheap Real Estate, lots of jobs, business opportunities, good pay and other factors… > > Cheap Real Estate? I was living near Washington DC in 1978 when a friend told me about the "Gold Coast". I asked her why they called California that, and she said because it was so expensive to live there. > > I moved there in 1979, and lived there until 1991, when my wife and I decided to move to a less expensive and crowded area in Arizona (Sedona). We had a family of four, plus needed extra rooms for my home office and her art studio, and have been priced out of living within a couple of hours drive of San Francisco. > > We really liked living there, and found people to be generally outgoing, good at communicating, cooperative but also very competitive. It was shocking to move to Arizona, with a much slower pace, but also people who were less friendly to strangers and less cooperative in general. Still, I certainly appreciated being in a place where I could hike and mountain bike, where in Marin County, north of SF, there would actually be cops with radar guns who would ticket bicyclists for coming around a corner on a dirt road faster than 5 mph! And once we had moved north of Marin, the opportunities for being alone in nature were low. The land was private and posted. > > So, no cheap Real Estate, not since the mid-70s. Instead, incredible home price inflation (now common where we live), and crazy-heavy traffic on top of that. > > Rik Farrow -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

1 month, 2 weeks

2
1
0 0

Was the SVID A Foregone Conclusion Pre-usr group?

by segaloco

I'm curious if anyone has the scoop on this. To my knowledge the 1984 /usr/group standard constitutes the earliest attempt at a vendor-neutral UNIX standard. AT&T then comes along in 1985 with the first issue of the SVID, based largely on SVR2 from what I know. What I'm not getting a good read on or not is if the SVID was literally a direct response from AT&T to the creation of the /usr/group standard or if there was already an impetus in AT&T's sphere of influence to produce such a definitive document. In either case, AT&T does list the /usr/group standard as an influence, but doesn't go into the detail of "we made this because /usr/group's standard exists" or "we made this ourselves and oh /usr/group also happens to have a standard." Even outside of this, did AT&T maintain anything comparable to the SVID in prior years or was the manual essentially the interface definition? Thanks for any recollections! - Matt G.

1 month, 2 weeks

11
20
0 0

Demise of AT&T

by sjenkin＠canb.auug.org.au

responding to the SVID thread: <https://www.tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/message/UFYAOAV…> This is my timeline for AT&T : 1956 - Consent decrees for IBM & AT&T, barring each other from entering the others’ business. 1964 - AT&T engages with MULTICS, to build an "Information and Computing Service”, supplying the customer ‘outlets’ 1969 - AT&T / Bell Labs withdraws from MULTICS 1974 - UNIX announced in CACM 1984 - AT&T de-merges, [0] into 7 Regional Operators, keeping ”long lines” and hardware/software development & manufacture. 1991 - IBM declares first loss, increasing losses for another two years. 1994 - Unix sold to Novell, hardware to NCR 2004 - AT&T acquired by SBC [0], a former Baby Bell that’d understood the Mobile phone market & pricing. Both IBM & AT&T were aware of “Silicon Valley” and the rapid evolution of microelectronics. AT&T even considered a 1966 Terman proposal, post-Stanford, to create “Silicon Valley East”. AT&T validly reasoned they couldn’t create it, there wasn’t the needed culture of Cooperation & Collaboration around them. Gordon Bell at DEC certainly understood the changes in technology and admitted “he didn’t believe it” [ i.e. predictions from his own models ]. It wasn’t just AT&T, IBM & DEC that got run over by commodity DRAM & CPU’s, it was the entire Minicomputer Industry, effectively extinct by 1995. [3] One of the causes of AT&T’s management failure was the “East Coat” management culture, documented by Tom Wolfe in 1983 [2] in “The Tinkerings of Robert Noyce”. What Wolfe seems to have missed is the “East Coast” focus on high Gross Margins (50%-90% for product lines, at both IBM & AT&T), compared to the Silicon Valley focus on “Volume” with implied modest Gross Margins: deliberately sharing cost-savings with Customers. An unanswered question about Silicon Valley is: Why did it happen in California and not be successfully cloned elsewhere? There is something different / special about California that for a century has diversified its economy, consistently grown its population faster than other US states, and grown its economy, over a century, faster than any US state or other nation. [ 7 ] I’ve not seen any definitive explanation of the Californian Miracle, it’s incontrovertible in the long-run numbers, before & after Silicon Chips, presumably due to multiple reinforcing factors, that create & maintain exceptional industries. i.e. virtuous circles, like Silicon Valley remaining an economic powerhouse, even as ’technology’ has evolved from Silicon devinces to chips, to software, to Internet Services. The Silicon Revolution didn’t just crush computer companies - it broke other long-term successful innovators: Kodak invented Digital Cameras in 1972, only to be forced into bankruptcy around 2009 after a century plus of operations, continuing after significant restructuring. <https://en.wikipedia.org/wiki/Kodak#Bankruptcy> =================== The SVID thread touches on the reasons that AT&T failed: <https://www.tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/message/UFYAOAV…> Clem Cole was in the room when Bill Gates said “it’s all about volume” [ implying modest margins ] Others mention ‘lawyers’ came to dominate the firm, making poor decisions. Rob Pike has previously mentioned on-list a lawyer killed the music, in PAC format, they’d arranged to put on Plan 9 distribution CD. <https://www.tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/message/NNKHNKQ…> Rachel Chalmers [4] in 1999 quotes Dennis Ritchie on the struggles to get the Version 6 code and Lions Commentary released. The lawyers and Corporate Culture were still hanging on 20 years later, wanting to block public release because they could, not for business reasons. In 1956, AT&T accounted for ~2% of US GDP, equivalent to ~$500B in sales today [1], comparable to Apple’s 2024 earnings of $391B. Tom Wolfe [2] wrote a piece on Noyce at Fairchild, then Intel, and details an “East Coast Management Style”, of opulence, self-indulgence and aggrandisement of ’the ruling class’. Wolfe is excoriating about “East Coast” management, though doesn’t detail the Silicon Valley / California approach in any detail. Noyce & Moore left Fairchild in 1968 with the invention of the Self-Aligned Silicon Gate for MOSFET to pursue devices made of large, regular arrays of transistors, also, quite particularly, to run the business without interference from the East Coast, able to reinvest their profits and grow the business as fast as they could. Fairchild had passed over Noyce in favour of Lester Hogan from Motorola [5] and his management team. Hogan was given a record renumeration package to move to Fairchild, but didn’t save the business. Intel has lasted, quickly growing to be a significant force and holding a lead. Fairchild never recovered after Noyce & Moore left and it sputtered out, underlining the importance of management style in Semiconductor businesses. Fairchild Semiconductor had, for over a decade, grown to be the dominant silicon device manufacturer, despite the parent company consistently using their profits to invest in vanity projects with low returns or losses. In 1963, Fairchild had announced UHF TV transistors for "$1.05” ( ~$11 now ) after the FAA added UHF band to broadcast TV. To compete with Vacuum tubes, given for nothing to TV manufacturers, Fairchild had to drop prices ten-fold ( vs mil.spec devices ) [ Valve manufactures made their money on replacement valves, not on original parts. ] Importantly, Fairchild’s price was below cost at the time. The engineers who pitched this to Noyce knew they’d sell millions and be able to quickly reduce production costs to make large profits. Noyce & Moore seemed to have used their Maths ability to solve a business / economics problem for them: How to optimise long-run revenue and profits in a dynamic, high CapEx / R&D / Non-Recurring Expenditure technology field? Their answer is what we’ve christened “Moore’s Law”: a) run R&D as hard as you can, shortening the ‘generation’ period to 2-3 years, well below the usual 5-10 years for “cost recovery” b) pass on 100% of cost savings to customers, relying on “Elasticity of Demand” to drive Volumes and increase total revenue. I assume they understood enough Game Theory to know once they adopted a “high volume / low-cost / rapid generations” strategy, they’d force all manufacturers in the industry to follow or be left behind. Kenneth Flamm [6], an economist, has written about the sustained “100% pass-through rate” of Silicon Semiconductors until at least 2010. I’ve not seen him or others discuss the origins of this strategy, unique to Semiconductors. Gordon Bell [3] noted the impact of the CMOS CPU revolution created by Silicon Valley. In 1984, there were 92 US Minicomputer Companies using discrete or Small Scale IC’s. In 1990, only 4 survived: Data General, HP, DEC and IBM [ Bell in [3] notes their fates out to 2002 ] IBM declared it’s first loss [$2.6B] in 1991, deepening to ~$5B and then ~$8B in 1992 & 1993 - seemingly without warning, they were caught by the changes in the market as commodity chips surpassed everything. IBM knew microprocessors were rapidly evolving, knew it’s Corporate Culture was antithetical to developing a product quickly & cheaply, so developed the IBM PC in 1981 in Boca Raton, Florida - away from Manhattan & breaking their traditional fully internal development and high gross margin model. During the 1970’s and 1980’s, IBM accounted for over 50% of Industry revenue - bigger than everyone else combined. That they weren’t able to adapt and respond to the challenges they clearly saw speaks of management failure. Like AT&T, they saw technology evolving and correctly forecast it’s impact on their ’traditional’ business lines, but were unable to changed their corporate culture to adapt. ================================================================================= References ================================================================================= [0] <https://en.wikipedia.org/wiki/Breakup_of_the_Bell_System> 1984: Southwestern Bell Corporation (known as SBC Communications after 1995) In 2005, SBC acquired former parent AT&T Corporation and took the AT&T name, becoming AT&T Inc. =================== [1] How Antitrust Enforcement Can Spur Innovation: Bell Labs and the 1956 Consent Decree <https://assets.aeaweb.org/asset-server/files/13359.pdf> As described in Section I, the Bell System was the dominant provider of telecommunications services in the United States. In terms of assets, AT&T was by far the largest private corporation in the world in 1956. AT&T, together with all companies in the Bell system, employed 746,000 people with a total revenue of $5.3 billion or 1.9% of the U.S. GDP at the time (Antitrust Subcommittee, 1959; Temin and Galambos, 1987). =================== [2] THE TINKERINGS OF ROBERT NOYCE How the sun rose on the Silicon Valley Tom Wolfe, Dec 1983 <http://classic.esquire.com/the-tinkerings-of-robert-noyce/> <https://web.stanford.edu/class/e145/2007_fall/materials/noyce.html> A certain instinct Noyce had about this new industry and the people who worked in it began to take on the outlines of a concept. Corporations in the East adopted a feudal approach to organization, without even being aware of it. There were kings and lords, and there were vassals, soldiers, yeomen, and serfs, with layers of protocol and perquisites, such as the car and driver, to symbolize superiority and establish the boundary lines. Back east the CEOs had offices with carved paneling, fake fireplaces, escritoires, bergères, leather-bound books, and dressing rooms, like a suite in a baronial manor house. Fairchild Semiconductor needed a strict operating structure, particularly in this period of rapid growth, but it did not need a social structure. In fact, nothing could be worse. Noyce realized how much he detested the eastern corporate system of class and status with its endless gradations, topped off by the CEOs and vice-presidents who conducted their daily lives as if they were a corporate court and aristocracy. He rejected the idea of a social hierarchy at Fairchild. =================== [3] Rise and Fall of Minicomputers Decline of the Classic Minicomputer (1985-1995) Gordon Bell 2013 <https://ethw.org/Rise_and_Fall_of_Minicomputers#Decline_of_the_Classic_Mini…> While the demise of classic minicomputers was clear by 1985, companies continued offering them until the early 1990s, when the firms went bankrupt or were acquired by more astute competitors. (See Table 1) Wang declared bankruptcy in 1992. Compaq bought DEC in 1998, and HP acquired Compaq in 2002. EMC turned Data General into a data storage business in 1999. Table 1 <https://ethw.org/File:Bell-MinicomputerTable.JPG> 92 U.S. minicomputer companies, 1968-1985 (created by the author with help from colleagues over many years) The following list includes all firms making general and special-purpose minicomputers for real-time processing, communications, business etc., sold to end users through OEMs, and bundled for process control and testing. It does not include scores of military, AT&T, European, and Japanese computers and processing systems developed for niche markets. 49 started up and retained autonomy or died 2 grew at significant rates and continued to grow: Data General (1969), Prime (1972) 8 grew at diminished or declining rates, or found small niches 39 ceased to manufacture 10 merged with larger companies 8 existing computer companies built minicomputers 2 grew rapidly: Digital Equipment Corporation (1960), IBM (1965) 25 existing companies built minicomputers for their own use 1 formed a division, Dymec, around an acquisition and grew rapidly: HP (1966) =================== [4] Code Critic John Lions wrote the first, and perhaps only, literary criticism of Unix, sparking one of open source's first legal battles. Rachel Chalmers November 30, 1999 <https://www.salon.com/test2/1999/11/30/lions_2/> "By the time the seventh edition system came out, the company had begun to worry more about the intellectual property issues and 'trade secrets' and so forth," Ritchie explains. "There was somewhat of a struggle between us in the research group who saw the benefit in having the system readily available, and the Unix Support Group ... Even though in the 1970s Unix was not a commercial proposition, USG and the lawyers were cautious. At any rate, we in research lost the argument.” ——— Ritchie never lost hope that the Lions books could see the light of day. He leaned on company after company. "This was, after all, 25-plus-year-old material, but when they would ask their lawyers, they would say that they couldn't see any harm at first glance, but there was a sort of 'but you never know ...' attitude, and they never got the courage to go ahead," he explains. Finally, at SCO, Ritchie hit paydirt. He already knew Mike Tilson, an SCO executive. With the help of his fellow Unix gurus Peter Salus and Berny Goodheart, Ritchie brought pressure to bear. "Mike himself drafted a 'grant of permission' letter," says Ritchie, "'to save the legal people from doing the work!'" Research, at last, had won. =================== [5] Wikipedia on Fairchild <https://en.wikipedia.org/wiki/Fairchild_Semiconductor> Sherman Fairchild hired Lester Hogan, who was the head of Motorola semiconductor division. Hogan proceeded to hire another hundred managers from Motorola to entirely displace the management of Fairchild. The loss of these iconic executives, coupled with Hogan's displacement of Fairchild managers demoralized Fairchild and prompted the entire exodus of employees to found new companies. =================== [6] Moore's Law and the Economics of Semiconductor Price Trends Flamm, 2018, NBER <https://www.nber.org/system/files/working_papers/w24553/w24553.pdf> ——— Flamm posits semiconductors [ DRAM & Microprocessors at least ] have maintained a 100% cost “pass-through rate” since the 1960’s. He’s been an expert witness for courts many times, as well as writing reports for the NBER and publishing academic papers. ——— In short, if the historic pattern of 2-3 year technology node introductions, combined with a long run trend of wafer processing costs increasing very slowly were to have continued indefinitely, a minimum floor of perhaps a 20 to 30 percent annual decline in quality-adjusted costs for manufacturing electronic circuits would be predicted, due solely to these “Moore’s Law” fabrication cost reductions. On average, over long periods, the denser, “shrink” version of the same chip design fabricated year earlier would be expected to cost 20 to 30 percent less to manufacture, purely because of the improved manufacturing technology. How would reductions in production cost translate into price declines? One very simple way to think about it would be in terms of a “pass-through rate,” defined as dP/dC (incremental change in price per incremental change in production cost). The pass-through rate for an industry-wide decline in marginal cost is equal to one in a perfectly competitive industry with constant returns to scale, but can exceed or fall short of 1 in imperfectly competitive industries. Assuming the perfectly competitive case as a benchmark for long-run pass-through in “relatively competitive” semiconductor product markets, this would then imply an expectation of 20-30% annual declines in price, due solely to Moore’s Law. To summarize these results, then, though there are substantial differences in the magnitude of declines across different time periods and data sources, all of the various types of price indexes constructed concur in showing substantially higher rates of decline in microprocessor price prior to 2004, a stop-and-start pattern after 2004, and a dramatically lower rate of decline since 2010. Taken at face value, this creates a new puzzle. Even if the rate of innovation had slowed in general for microprocessors, if the underlying innovation in semiconductor manufacturing technology has continued at the late 1990s pace (i.e., a new technology node every two years and roughly constant wafer processing costs in the long run), then manufacturing costs would continue to decline at a 30 percent annual rate, and the rates of decline in processor price that are being measured now fall well short of that mark. Either the rate of innovation in semiconductor manufacturing must also have declined, or the declining manufacturing costs are no longer being passed along to consumers to the same extent, or both. The semiconductor industry and engineering consensus seems to be that the pace of innovation derived from continuing feature-size scaling in semiconductor manufacturing has slowed markedly. ————————— [ submission to a court case ] Assessment of the Impact of Overcharges on Canadian Direct and Indirect Purchasers of DRAM and Products Containing DRAM Submitted to: The Honourable Ian Binnie 28 June 2013 <https://www.cfmlawyers.ca/wp-content/uploads/2012/05/DRAM-Ross-Distribution…> VI. Pass-Through in this Case 48. Based upon my review of the information described above, I am of the view that there would likely be a very high degree of pass-through in DRAM distribution channels, all the way down to final consumers. This conclusion is based principally on a review of the structure of the various markets together with an application of standard economic theory. I also draw on pass-through analyses done by a number of experts in the U.S. action, recognizing that they are clearly contradictory on some key points. Evidence from the U.S. Case 49. Let me begin with a brief review of the work done by economists for various parties in the American action. a. In his report Michael Harris (July 10, 2007) estimated pass-through from top to bottom rather than just at one stage. That is, he looked to see if increases in the price of base DRAM were passed all the way down the distribution channels and increased computer prices. In one test he estimated that there was more than 100% pass-through of base DRAM price increased to final computer purchasers. In a second test he studied the effect of increases in spot market DRAM prices on aftermarket DRAM prices. Again, he found more than 100% pass-through.21 b. Professor Kenneth Flamm, in his report (December 15, 2010) provided estimates of the pass-through from retailers to final consumers using data from four major U.S. retailers (Best Buy, Office Depot, CDW, and Tech Depot) for various categories of computer products (desktops, notebooks, servers, memory, printers and graphics). Most pass-through estimates were in a range between 90% and 113%, the desktop and notebook rates were all within a few points above or below 100% with one exception. =================== [7] Links on California, population and economic growth from 1900 to 2000 ————————— Wikipedia <https://en.wikipedia.org/wiki/Economy_of_California> The economy of the State of California is the largest in the United States [ in 2024 ]. It is the largest sub-national economy in the world. If California was an independent nation, it would rank as the fourth largest economy in the world in nominal terms, behind Germany and ahead of Japan. As of 2024, California is home to the highest number of Fortune 500 companies of any U.S. state. As both the most populous US state and one of the most climatologically diverse states the economy of California is varied, with many sizable sectors. ————————— California since c. 1900 <https://www.britannica.com/place/California-state/California-since-c-1900> population in 1900: 2 M. now largest US state by population & GNP. ————————— California’s Economy. [ fact sheet 2025 ] <https://www.ppic.org/publication/californias-economy/> California is an economic powerhouse, nationally and globally. • In 2023, California’s gross domestic product (GDP) was about $3.9 trillion, comprising 14% of national GDP ($27.7 trillion). Texas and New York are the next largest state economies, at 9% and 8%, respectively. • California’s economy ranks fifth internationally, behind the US, China, Germany, and Japan. On a per capita basis, California’s GDP is greater than that of all of these countries. • California’s economy has grown relatively slowly in recent years, averaging 2.3% per year between 2020 and 2023, compared to 3.9% on average over the previous four years. By comparison, Florida (4.6%) and Texas (3.9%) grew faster than California since 2020. • Over the long term, California’s economy has grown faster than the nation overall (111% vs 75% over the past 25 years) and faster than other large states except for Texas (128%). On a per capita basis, California’s economic growth outpaces all other large states over the long term. Growth in jobs and businesses have powered the state’s economy. • California’s labor market grew by 4.2 million jobs (30%) between 1998 and the second quarter of 2024; over the same 25-year period, the number of businesses with employees grew more than 72%. Both outpaced population growth (18%), leading to robust gains in economic output. ————————— California’s Population [ fact sheet 2025 ] <https://www.ppic.org/publication/californias-population/> One in eight US residents lives in California. • With just over 39 million people (according to July 2024 estimates), California is the nation’s most populous state - its population is much larger than that of second-place Texas (31.3 million) and third-place Florida (23.4 million). ————————— =================== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

1 month, 3 weeks

2
2
0 0

Re: Was the SVID A Foregone Conclusion Pre-usr group?

by jnc＠mercury.lcs.mit.edu

> From: Lyndon Nerenberg > I think AT&T's real problem was that the post-1984 UNIX business was > run by the lawyers. This is a common problem in many companies: executives who do not have deep knowledge of the company's fundamental business, but rather in some support area, rise to the top of the business, and proceeed to make bad decisions about that business (through lack of deep understanding of the business' fundamentals). The exact same problem arises not just with support functions, but also with the belief in 'pure managers'. The biggest recent example of this problem in Boeing; the people running a business that is fundamentally an engineering business made some bad decisions in areas that were fundamentally engineering. Car companies have displayed this disorder too. Which is not to say that such people _can't_ be effective leaders of such organizations; the classic example is James Webb, who 'ran' NASA from 1961 to 1968; he was originally a lawyer. I say 'ran' NASA because Webb was smart enough to understand the limits of his expertise, and he delegated all the technical decisions to his chief deputy, Hugh Dryden - who had started his career as an aeronautical scientist (a Ph.D in physics and mathematics). Noel

1 month, 3 weeks

1
0
0 0

ATC'25 is the last ATC?

by Dan Cross

I just heard that, after ATC'25, USENIX will be sunsetting the annual technical conference: this will apparently be the last one. I can't find any reference for it, though, and the web site mentions ATC'26 in Seattle? - Dan C.

1 month, 3 weeks

8
10
0 0

Re: Ken Thomson's email address?

by jnc＠mercury.lcs.mit.edu

> From: Jackson Helie G > I was wondering if anyone knows Ken Thomson's email address? I was > wondering if he has any more archives of Unix from 1972 and before. He does read this ist, and very occasionally posts to it. But there's no point bothering him, to ask; anything he had, he turned over many years ago. (To the point that people have recently been poring through the 'trash' bits in the "s1-bits" and s2-bit" tapes, IIRC, for lack of anything else to look at. Look for "A Census of /etc and /sys Prior to V4" in the TUHS archive to see some discussion of some of this work, by Matt Gilmore. I think somene else was working on it too, but I couldn't find it; I'm not up for looking through TUHS archives for it.) Noel

1 month, 3 weeks

2
1
0 0

Re: What is the intermediate code generated by the bc interpreter?

by jnc＠mercury.lcs.mit.edu

> From: Al Kossow > What was the name of the system(s)? From an early 'hosts' file: HOST MIT-RTS, [CHAOS 470,LCS 10/11],SERVER,UNIX,PDP11,[RTS,DSSR] I'd rather depend on that, than on my memory! (The names at the end are aliases.) While I was looking for a really early host file (I recall our early TFTP command had one; I don't think it was built into the command, but it might have been),~p I found a /jnk directory in MIT-CSR's root; it had a lot of interesting stuff in it. One particularly interesting one was 'kov': The idea of this kernel overlay scheme is to increase the amount of code that can be included in the UNIX kernel. This is done by reserving one of the I space segmentation registers (the highest free, usually KISA5 for non-split systems) and changing its value dynamically so as to map in the appropriate code as needed. I chose to use only one page register (limiting each KOV to 4Kw), in order to minimize the mapping overhead. I wonder if this is an early predecessor to the overlay stuff in BSD 2.9 (and later BSD's)? That stuff is all poorly documented, and I'm not up for poring through both to compare them. This one was all done by Ken Harrenstien (KLH). Noel

1 month, 3 weeks

3
2
0 0

The Official Announcement WRT the USENIX Annual Technical Conference

by Clem Cole

Casey Henderson-Ross is the ED of USENIX. Since the list would not accept her message, she asked me, as a former President, to send this to folks on the TUHS mailing list. ------------------------------- Folks, As you may already be aware, today we made an important announcement about the USENIX Annual Technical Conference via our mailing list. We want to share this news with you directly as well in case you do not currently receive USENIX email. Please read the statement in its entirety here: https://www.usenix.org/blog/usenix-atc-announcement If you don't know me, I've served on the USENIX staff since 2002 and have had the privilege of serving as Executive Director since 2012. USENIX and the Annual Technical Conference are both dear to me as I know they are to many of you. This is difficult news to share even as we're grateful to be celebrating 50 years of USENIX this year. I hope that you'll share your memories via the form mentioned in the statement and that we'll also see many of you at USENIX ATC '25 in Boston in July: https://www.usenix.org/conference/atc25 If you'd like to contribute to activities there, please contact me directly. Thanks to all of you for honoring the history of UNIX and for your support of USENIX and ATC (in its different names and forms) over the decades. Best, Casey Henderson-Ross ᐧ

1 month, 3 weeks

1
0
0 0

Re: Unix Reverse Engineering

by jnc＠mercury.lcs.mit.edu

> From: Thalia Archibald > I'm working on building a decompiler from PDP-11 assembly to C to ease > studying old pre-C Unix sources. To start, I'm translating V5 `as` to > period-idiomatic C That's going to be a real trick; 'as' was written in PDP-11 assembler: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/as Noel

1 month, 3 weeks

5
5
0 0

Re: What is the intermediate code generated by the bc interpreter?

by jnc＠mercury.lcs.mit.edu

> From: Tom Teixeira > before the RTS group at Project MAC (Called the DSSR group at that point om time, if anyone wants to look anything up.) > I got a BCPL compiler from somewhere and made some enhancements - such > as direct support for external variables and routines using a linker > rather than the pure BCPL global array. This entire toolchain, including all the source, has been preserved; the BCPL compiler, the linker ('bind', itself written in BCPL), and a number of tools (including an extra one, 'ldrel', written by the CSR group on the 5th floor). I have in the past put up some pieces for download, but I never got around to doing the whole thing, as there didn't seem to be any interest. We (CSR) started working with the toolchain because it included support for MACRO-11 (the BCPL compiler could produce either MACRO-11 or UNIX assembler source as output). That toolchain used a relocatable formet, .rel': http://ana-3.lcs.mit.edu/~jnc/tech/unix/man5/rel.5 that I think was based on one DEC had done. CSR was working with a semi-real-time operating system, called 'MOS': https://gunkies.org/wiki/MOS_operating_system for the PDP-11, that we'd gotten from SRI. (MOS was used a lot in early work on the Internet; e.g. all the BBN 'core' routers used in the early Internet used it, after the very first ones [written in BCPL, oddly enough], which had used ELF: https://gunkies.org/wiki/ELF_operating_system but BBN soon switched to MOS.) MOS was written in MACRO-11; we started working with MOS with the same toolchain SRI had used for it, which ran on TOPS-20. I soon decided I'd rather work on our group's PDP-11, initially a PDP-11/40 running a clone of the DSSR system (the first UNIX at MIT). So, we started working with the MACRO-11, and bind, on UNIX. I then decided I'd rather write code for our PDP-11 packet switches in this nifty language called C, used on UNIX, which nobody else knew about (at that point). The first step was to write 'ldrel', to convert a.out files (produced by the C compiler) to .rel files, so 'bind' could work with them. After a while, we decided we'd rather use 'ld' as our linker (I think because it supported demand loading from binary libraries, so we didn't have to manually specify every file to link). The DSSR group had long ago written 'relld', which converted .rel files (produced by MACRO-11) to a.out files, so that was pretty easy. There seems to be a version of the BCPL compiler which produces 8080 code. It looks like that pre-dates the 8086 C compiler from MIT (the 8080 C compiler was not done at MIT). (I just ran across a 6502 emulator written by Rae McLellan of DSSR; he and they seem to have done a lot of work with various micros. It may not have all the pieces it needs to work, though; it seems to need "/usr/simulators/s6502/s6502.body" from the DSSR machine.) Pity I didn't save a dump of that machine too; I was once looking for the source of the Algol interpreter, written on the Delphi machine, and made to run under UNIX, and I asked Steve Ward if any dumps of the DSSR/RTS machine still existed, and he thought not. So we have the binary of that Algol interpreter, but not the source. Of course, it was probably written in MACRO-11, so a disassembler would produce a reasonable facsimile. And I should ask Lars if the backup tapes of the DSSR/RTS machine went to the MIT archives - they might well have done, and Prof. Ward just didn't know that. Noel

1 month, 3 weeks

5
5
0 0

What is the intermediate code generated by the bc interpreter?

by Jackson Helie G

I checked Dennis M. Ritchie's "Users' Reference to B" and found an example of implementing a B program at the bottom of the manual. It said that bc generates intermediate code suitable for ba, and then ba generates assembly code. So, I am curious about what the intermediate code generated by bc is?

1 month, 3 weeks

5
5
0 0

Unix Reverse Engineering

by Thalia Archibald

Hello everyone, I'm working on building a decompiler from PDP-11 assembly to C to ease studying old pre-C Unix sources. To start, I'm translating V5 `as` to period-idiomatic C and have finished most of pass 1. Then I'll port it to Rust with a design better suited to static analysis, while keeping exact fidelity to the original. I'll do the same for `cc` and `ld`, after. I stumbled upon Warren's disaout[0] today, which made me wonder: What tools have people for reverse engineering Unix assembly sources or a.out binaries? Things like disassemblers or decompilers. I assume there's some versions of programs which are now only extant as binaries? Are there enough such binaries that were written in C to warrant writing a decompiler that understands the specific codegen of `cc` to improve accuracy? For now, I'm focusing on decompiling hand-written assembly, but I'm keeping this case in mind. Thanks! Thalia [0]: https://github.com/DoctorWkt/unix-jun72/tree/master/tools/disaout

1 month, 3 weeks

1
0
0 0

Off topic: Books on Unix security?

by Aharon Robbins

Hi All. In a book I'm updating, I have the following references for Unix security. 1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, Gene Spafford, and Alan Schwartz, O’Reilly & Associates, Sebastopol, CA, USA, 2003. ISBN-10: 0-596-00323-4, ISBN-13: 978-0596003234. 2. Building Secure Software: How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN- 10: 0-201-72152-X, ISBN-13: 978-0201721522. 3. “Setuid Demystified,” by Hao Chen, David Wagner, and Drew Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, 2002. http://www.cs.berkeley. edu/~daw/papers/setuid-usenix02.pdf. One of my reviewers asked if these weren't "dusty references". So, before I just refer to them as "classics", can anyone recommend more recent books? Feel free to answer in private. Thanks, Arnold

2 months

6
6
0 0

Re: Ken Thomson's email address?

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > The first "C" compiler wa an ephemeral state some time in the process > of its evolution. Dennis started with his B implementation and began to > add features he needed See: The Development of the C Language https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html for detail on the evolution. Noel

2 months

5
4
0 0

Re: Ken Thomson's email address?

by Jackson Helie G

If this is true, it's a pity. Otherwise, I would like to ask Ken Thompson if he has the first C compiler.

2 months

2
1
0 0

Re: Ken Thomson's email address?

by jnc＠mercury.lcs.mit.edu

> From: Jackson Helie G > I would like to ask Ken Thompson if he has the first C compiler. He wouldn't; he didn't do much work on C. Dennis Ritchie (who created C) posted two very early ones here: https://www.nokia.com/bell-labs/about/dennis-m-ritchie/primevalC.html Noel

2 months

1
0
0 0

Ken Thomson's email address?

by Jackson Helie G

Oh, sorry guys, please forgive me for the off-topic question. I was wondering if anyone knows Ken Thomson's email address? I was wondering if he has any more archives of Unix from 1972 and before.

2 months

1
0
0 0

Fwd: An Announcement about the USENIX Annual Technical Conference

by Rik Farrow

I received this earlier today, and wondered if cross-posting it would be appropriate. Here goes... Rik ---------- Forwarded message --------- From: Casey Henderson-Ross <casey.henderson(a)usenix.org> Date: Tue, May 6, 2025 at 2:12 PM Subject: An Announcement about the USENIX Annual Technical Conference To: Rik Farrow <rik(a)rikfarrow.com> Read on for important news. [image: USENIX, the Advanced Computing Systems Association] <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> Hello, Rik, USENIX celebrates its 50th anniversary in 2025. We celebrate decades of innovations, experiments, and gatherings of the advanced computing system community. And in the spirit of our ever-evolving community, field, and industry, we announce the bittersweet conclusion of our longest-running event, the USENIX Annual Technical Conference in July 2025, following USENIX ATC '25. Since USENIX's inception in 1975, it has been a key gathering place for innovators in the advanced computing systems community. The early days of meetings evolved into the two annual conferences, the USENIX Summer and Winter Conferences, which in 1995 merged into the single Annual Technical Conference that has continued to evolve and serve thousands of our constituents for 30 years. For the past two decades, as more USENIX conferences have joined the USENIX calendar by focusing on specific topics that grew out of ATC itself, attendance at ATC has steadily decreased to the point where there is no longer a critical mass of researchers and practitioners joining us. Thus, after many years of experiments to adapt this conference to the ever-changing tech landscape and community, the USENIX Board of Directors has made the difficult decision to sunset USENIX ATC. USENIX ATC in its many iterations has been the home of an incredible list of "firsts" in our industry: - In 1979, ONYX, the first attempt at genuine UNIX hardware, was announced. - In 1982, DEC unveiled the creation of its UNIX product. - In 1983, Eric Allman presented the first paper on Sendmail, "Mail Systems and Addressing in 4.2BSD." - In 1985, Sun Microsystems presented the first paper on NFS, "Design and Implementation of the Sun Network Filesystem." - In 1988, the first light on Kerberos and the X Window system was presented. - In 1989, Tom Christiansen made his first Perl presentation as an Invited Talk. - In 1990, John Ousterhout presented Tcl. - In 1995, the first talk on Oak (later JAVA) was given as a Work-in-Progress report. - In 1998, Miguel de Icaza presented "The GNOME Desktop Environment." These examples represent just a few of the many contributions presented at USENIX ATC over the years, with hundreds of papers that account for thousands of citations of work that the community has presented, discussed, learned from, and built upon as the community evolved. Part of that evolution involved the continued development of subcommunities, as has been the case with USENIX Security, which began as a workshop in 1988 and has since grown to an annual symposium and the largest of our events in terms of both papers published and number of attendees annually, with 417 papers and 1,015 attendees at USENIX Security '24. The LISA (Large Installation System Administration) Conference, which also started as a workshop in 1987, grew in a similar fashion to its peak of over 1,000 attendees, but like USENIX ATC declined as its community changed until its own sunset in 2021. Papers on file and storage systems that would have previously been presented at USENIX ATC in the early 2000s began to find homes at FAST when it was founded in 2002. Networked systems papers started flowing to NSDI in 2003. As the biennial OSDI continued to grow alongside ACM's SOSP, OSDI became annual in 2021 and SOSP followed suit, providing the community with additional venues. While landmark moments in our community have continued at USENIX ATC, many others have also occurred at these other USENIX conferences, as showcased in the USENIX Test of Time Awards <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> and the ACM SIGOPS Hall of Fame Awards <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, which celebrate influential works presented at both SOSP and OSDI. Although numerous papers continue to be submitted to USENIX ATC with significant research being reviewed, accepted, and presented, the community has evolved, and now attends conferences other than USENIX ATC. From 1,698 attendees in San Diego in 2000, ATC attendance dwindled to 165 attendees in Santa Clara in 2024—even as we had over 4,000 people attend all USENIX conferences in 2024. USENIX recognizes the pivotal role that USENIX ATC has played in the shaping of the Association itself as well as the lives and careers of its many attendees and members. We also realize that change is inevitable, and all good things must come to an end: if it weren't for ATC being a "victim of its own great success"—a foundry of so many other successful conferences and workshops—USENIX would never have grown and expanded so much over the decades. Thus our hearts are heavy as we celebrate ATC's history and legacy alongside the evolution of its younger siblings and face the financial realities of the post-pandemic world and volatile global economy. USENIX's resources to support its conferences and communities are not unlimited, particularly as we maintain our commitment to open-access publications that are free for our authors to publish. We have been reporting about these challenges via our Annual Meeting and subsequent reports for the past several years (2024 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2023 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2022 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2021 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2020 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>). We deeply appreciate the financial support we have received from our community in the form of donations, memberships, and conference registrations. However, we continue to operate at a deficit and ATC continues to shrink. In making this hard choice, accepting the reality in front of us that encourages us to innovate in a different direction under challenging circumstances, we seek to embody the values of this community that was founded on curiosity, persistence, and collaboration. As we celebrate 50 years of both USENIX and ATC in its varying forms, we look towards the future of this vibrant community in the form of the many conferences that ATC continues to help create in its image: welcoming, thoughtful environments for the presentation of innovative work that fellow conference attendees help push forward. We look forward to honoring ATC's legacy alongside USENIX's history and its future in Boston in July of 2025. We would love to hear memories of your experience at the USENIX Annual Technical Conference over the years. Please submit your thoughts <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> in words, video, or both by *Monday, June 2*. We will share your memories both at USENIX ATC '25 and afterwards. We hope that you will join us at USENIX ATC '25 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, which will include both a celebration of USENIX's 50th anniversary on the evening of *Monday, July 7*, and a tribute to USENIX ATC on the evening of *Tuesday, July 8*. [image: Casey Henderson headshot] Best Regards, Casey Henderson-Ross Executive Director USENIX Association About this mailing list: You are receiving this email because you are or have been a member of USENIX, have attended USENIX conferences, or have signed up to receive emails from USENIX. USENIX <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> never shares, sells, rents, or exchanges email addresses of its members, conference attendees, and other constituents. Review our privacy policy <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> . We would like to continue sending you occasional email announcements like this one. However, if you no longer want to receive emails from USENIX, please click here <http://s.usenix.org/acton/rif/2452/s-0514-2505/-/l-sf-cl-7018Y000001JtF6QAK…> to opt out of all communications from USENIX. If you have any questions about the mailing list, please email info(a)usenix.org. We may also be reached via postal mail: USENIX Association 2443 Fillmore St, #380-25600, San Francisco, CA 94115-1814, USA

2 months

1
0
0 0

Re: Paragraphs formatted differently depending on previous ones

by G. Branden Robinson

[looping TUHS back in since I'm correcting a message I sent there] Hi Dave, At 2025-05-06T08:36:55-0500, Dave Kemper wrote: > On Fri, May 2, 2025 at 7:35 PM G. Branden Robinson > <g.branden.robinson(a)gmail.com> wrote: > > I guess another way of saying this is that, as I conceive it, a line > > that is "adequately full" contributes to the page's uniformity of > > grayness by definition. > > For an example of less-than-ideal results if this is _not_ considered > the case (groff's behavior before this change), see > http://savannah.gnu.org/bugs/?60673#comment0 (the initial report that > precipitated the commit Doug is commenting on). Yes. In my reply to Doug I incorrectly characterized the resolution of this bug as a "2023" change of mine, but I actually landed the change in 2021. It simply took until 2023 to appear in a released _groff_. To make this message more TUHS-o-riffic, let's observe that input using DWB 3.3 troff and Heirloom Doctools troff (descended from Solaris troff, descended from DWB 2.0 troff [I think]), and both of which descend from Kernighan's device-independent troff circa 1980. $ DWBHOME=. ./bin/nroff groff-60673.roff | cat -s While the example in bug 57836's original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty's balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn't "count" lines that don't need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. $ ./bin/nroff groff-60673.roff | cat -s While the example in bug 57836's original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty's balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn't "count" lines that don't need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. They are the same, and differ from groff 1.22.4 and earlier only in that they adjust spaces starting from the right end of the line instead of the left. At the risk of tooting our own horn, here's how groff 1.23.0+ handles the same input. $ ~/groff-1.23.0/bin/nroff groff-60673.roff | cat -s While the example in bug 57836’s original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty’s balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn’t "count" lines that don’t need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. Three observations: 1. One can find the input at Dave's URL above. 2. The input disables inter-sentence spacing. 3. The adjustment algorithm is a property not of grotty(1) (the output driver), but of GNU troff itself. Regards, Branden

2 months

1
0
0 0

Off topic: Books on Unix security?

by norman＠oclsc.org

Aharon Robbins: So, before I just refer to them as "classics", can anyone recommend more recent books? Feel free to answer in private. === `Unix security' is not the most-specific of terms. Can you give more context? Norman Wilson Toronto ON

2 months

2
1
0 0

Re: Any Interdata war stories?

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Yes, that was one of the RTS compilers for the NU machine. John Romkey > may have done it, as he was the primary person behind PCIP I decided to poke around in the 'MIT-CSR' dump, since that was the machine the PC/IP project started on, to see what I could find. Hoo boy! What an adventure! In the PC/IP area, I found a 'c86' directory - but it was almost empty. It did have a shell file, 'grab', which contained: tftp -g $1 xx "PS:<Wayne>$1" and a 'graball' file which called 'grab' for the list of compiler source files. ('xx' was MIT-XX, the TOPS-20 main time-sharing machint of LCS.) So I did a Web search for Wayne Gramlich (with whom I hadn't communicated in many decades), and he popped right up. (Amazing thing, this Internet thingy. Who'd have ever thought, back in the day, that it would turn into what it did? Well, probably John Brunner, whom I (sadly) never met, who was there before any of us.) I took a chance, and called his number, and he was there, and we had a long chat. He absolutely didn't do it, although he wrote the loader the project used ('l68', the source for which I did find.) He's virtually certain Romkey didn't (which would have been my guess too; Romkey was like a sophmore when the project started). His best (_very_ faded) memory was that they started off with a commercial compiler. (But see below.) That leaves several mysteries. 1) Why would a commercial compiler not come with a linker? 2) Why did people who wanted to work with the PC/IP source need a Bell license? I did some more poking, and the list of files for the 86 compiler, from 'graball': trees.c optim.c pftn.c code.c local.c scan.c xdefs.c table.c reader.c local2.c order.c match.c allo.c comm1.c manifest mfile1 common macdefs mfile2 mac2defs matched the file names from 'pcc', as given in "A Tour Through the Portable C Compiler": https://maibriz.de/unix/ultrix/_root/porttour.pdf (in section "The Source Files"). So whether the 86 compiler was done at MIT (by someone in RTS), or at a company, it was definitely a 'pcc' descendant. (Possibly adding to the confusion, we had some other C compilers for various ISA's in that project [building networking software for various micro-computers], including an 8080 C compiler from Whitesmiths, Ltd, which I have also found. It's possible that Wayne's vague memory of a commercial compiler is of that one?) I really should reach out to Romkey and Bridgham, to see what they remember. Later today. Whether the main motivation for keeping the compiler source on XX was i) because disk space was short on CSR (we had only a hand-me-down pair of CalComp Model 215 drives - capacity 58 Mbytes per drive!); ii) to prevent version skew; or iii) because it was a commercial compiler, and we had to protect the source (e.g. we didn't have the source to the 8080 compiler, only the object modules), I have no idea. > Anyway the MIT RTS folks made hardware and PCC back ends for the 68K, > Z8000 and 8086. I believe that each had separate assemblers, tjt who > sometimes reads this list might know more, as he wrote the 68K assembler. There is an 'a86' directory on CSR, but it too is empty, except for a 'grab' command file. That contains only: tftp -g $1 xx "PS:<novick>$1" I have no memory of who 'novick' might have been. A Web search for 'novick mit lcs' didn' turn anything up. (I wonder if it might have been Carol Novitsky; she was in our group at LCS, and I have a vague memory of her being associated with the networking software for micro-computers project.) Anyway, it probably doesn't matter; the c86 'grab' referred to Wayne, but he didn't write c86; 'novick' might not have written a86. Something else to ask Romkey and Bridgham about. Noel

2 months

7
16
0 0

Re: Paragraphs formatted differently depending on previous ones

by Douglas McIlroy

Branden, > The relevant function fits on one screen, if your terminal window is at > least 36 lines high. :) (Much of it is given over to comments.) > https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp?id=… Actually there's still another function, spread_space that contains the inner R-L and L-R loops. The whole thing has become astonishingly complicated compared to what I remember as a few (carefully crafted) lines of code in the early roff. I admire your intrepid forays into the groff woods, of which this part must be among the less murky. Doug

2 months

2
1
0 0

Surviving System V/VME Artifacts?

by segaloco

So part of Western Electric/AT&Ts developer support for the WE32x00 CPU line was the WE321SB VME-bus single-board computer. The official operating system for this was UNIX System V/VME. This version is referenced in several document catalogues and literature surrounding this VME module. I was curious if anyone on list happens to know of any surviving System V/VME artifacts floating around out there. All I've been able to find are references to the system in other WE32x00 and UNIX documentation. Thanks for any info! - Matt G.

2 months, 1 week

2
2
0 0

Any Interdata war stories?

by arnold＠skeeve.com

> From: Tom Lyon <pugs78(a)gmail.com> > > I was pleased to learn that the first port of S to UNIX was on the > Interdata 8/32, which I had my part in enabling. I would love to hear more about the Interdata port and what happened with it afterwards. Interdata seems to have disappeared into the dustbin of history. And Unix on it apparently never got out of Bell Labs; I don't think the code for it is in the TUHS archives. Was the Interdata system in use at Bell Labs for actual work once the port was complete? ISTR there was a meeting with Interdata about changes in the architecture that Bell Labs wanted, that Interdata didn't want to make. What was the full story? Any other info would be welcome. Thanks, Arnold

2 months, 1 week

13
22
0 0

Re: Any Interdata war stories?

by jnc＠mercury.lcs.mit.edu

> From: Arnold Robbins > CCI made the Tahoe that 4.4 ran on, but I'm guessing it's a different > architecture than the Interdata? I think so. Almost all documentation on the Tahoe has been lost in the mists of time (if ANYONE retains ANY hardcopies of ANY hardware documentation for the Tahoe, PLEASE let me know), but I recently managed to work out a bit about it from the instruction decoding/printing routines in the debuggers from 4.3 BSD Tahoe: https://gunkies.org/wiki/Power_6/32 and it seems to be fairly different from the Interdata: http://bitsavers.org/pdf/interdata/32bit/29-365R01_32BitRefMan_Jun74.pdf Also, 'CCI' is 'Computer Consoles Incorporated', not "Concurrent Computer Corp". Noel

2 months, 1 week

1
0
0 0

Re: V7 ls and dot files?

by Douglas McIlroy

http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_filename.html says > I'm not sure but I believe .. went in during the Version 2 rewrite .. was there from the beginning. The v1 man page directory(v) says, > By convention, the first two entries in each directory are for "." and "..". Doug

2 months, 1 week

8
8
0 0

Re: Any Interdata war stories?

by jnc＠mercury.lcs.mit.edu

> From: Rich Salz > The PC/IP software from MIT included a port of the "Portable C > Compiler" to generate 8086-era code. It ran on a Unix machine and built > binaries that you downloaded to the PC. ... So you need an ATT source > license to get the full PCIP dev kit. That makes sense. The 'MIT license' (about which Jerry Saltzer did a note for the October-December 2020 issue of the 'IEEE Annals of the History of Computing', available here: https://www.mit.edu/~Saltzer/publications/MITLicense.pdf and which mentions that it was initially done for the MIT PC/IP code) only applied to the MIT-written applications, not a 'derived work' (to use the intellectual property law 'term of art') based on Bell code. Noel

2 months, 1 week

1
0
0 0

Searching for game history

by Brian "Beej" Hall

Hi everyone, I'm here with a Unix/Bell Labs history question at the suggestion of BWK. I have a bit of a computing mystery on my hands... _Conquest_ is an old game that apparently came to life in Bell Labs, but no one seems to know anything more about it, including who the author is. The instructions for the game[1] contain the following text at the bottom: Amiga port by Bob Shimbo, orginal author unknown. This game started life on a UNIX system at Bell Labs. It was ported to CP/M 80 by a Scott Kamin. The manual was thrown together in an afternoon. (Typos and corrections welcome). You can reach me through Compuserve (UID 70260,231) or TBBS of colorado (303)-693-4735. The LHA archive for the Amiga was packaged in 1986. I did get in touch with Bob Shimbo, but he writes: You can imagine how long ago I did that port given I referenced my Compuserve account. I don't recall where I found the code originally. Sorry. We've been through 3 house moves since then and I don't know where any references might have gotten to. Scott Kamin--I found a reference to someone by his name in the CP/M world in the 80s in New Jersey. (Internet Archive has lots of old computer magazine scans and his name showed up in the classified ads.) And a search turned up a snail mail address for someone in the right age range living a few miles from the business listed in the ad. A Hail Mary snail mail got no reply. Does any of it ring a bell, by any chance? I've begun the work of getting it to run on modern systems[2], and it would be great to be able to include more history in the man page. Cheers, -Beej [1] https://github.com/beejjorgensen/conquest/blob/master/instructions.txt [2] https://github.com/beejjorgensen/conquest/ -- Brian "Beej Jorgensen" Hall beej(a)beej.us https://beej.us/

2 months, 1 week

3
3
0 0

BTL 'S' manual from 1981

by Tom Lyon

Not UNIX, but adjacent... With the permission of John Chambers, I'm sharing a scan of "S - A Language and System for Data Analysis" by Richard Becker and John Chambers, January 1981. Enjoy: https://drive.google.com/drive/folders/14ijVPw1DihydXFqTzj-wgl3C5LYEJdKX?us… I was pleased to learn that the first port of S to UNIX was on the Interdata 8/32, which I had my part in enabling.

2 months, 1 week

1
0
0 0

V7 ls and dot files?

by Aharon Robbins

Hi All. The V7 ls.c ignores `.' and `..', unless given the -a option. The V1 - V6 ls ignores all files that start with `.', unless given -a, and this is the default for all modern versions of ls. BWK tells me there's a story about the V7 behavior but he doesn't remember what it is. Does anyone here know? Thanks, Arnold

2 months, 1 week

3
2
0 0

Re: UniPress Emacs V2.20 from 1989

by Lars Brinkhoff

Mark Seiden writes: > the display updating code, as i recall, had a skull and crossbones on it > i remember there was a bit of a kerfuffle when richard stallman introduced > that code into gnu emacs This is true. Gosling Emacs from 1984 and GNU Emacs 13 from 1985 both have the skull and crossbones comment.

2 months, 2 weeks

2
1
0 0

UniPress Emacs V2.20 from 1989

by Lars Brinkhoff

The floppy label says it's for AIX, but the source code hits it runs on Sun, IRIS, Apollo, HP, X10, X11, Amiga, Mac, MS-DOS, Xenix. https://github.com/larsbrinkhoff/emacs-history/tree/sources/Hans%20H%C3%BCb…

2 months, 2 weeks

6
5
0 0

Pre-Symposium on Operating System Principles Public UNIX Mentions?

by segaloco

I see in many places the 1973 Symposium on Operating System Principles mentioned as one of the earliest if not the earliest discussion of UNIX in the public eye. This would be around the time of the Fourth Edition and the rewrite of the system for the PDP-11/45 in C. Well, I recently picked up Aho and Ullman's The Theory of Parsing, Translation, and Compiling. The very last sentence of the preface in Volume 1 reads: > The use of UNIX, an operating system for the PDP-11 computer designed by > Dennis Ritchie and Kenneth Thompson, expedited the preparation of certain > parts of this manuscript. Given that this text was published in 1972, would this have been a completely esoteric reference to the general target audience of these books or was knowledge of UNIX already well circulated in the computing community by then? What other sorts of notoriety/publicity did UNIX get out in the general public prior to its presentation in 1973 and subsequent publication of the paper in CACM? - Matt G.

2 months, 3 weeks

1
0
0 0

running BSD 2.11 on my PDP 11/70 emulator

by Folkert van Heusden

Hi, For fun I'm developing a PDP 11/70 emulator. It runs on everything from ESP32 microcontrollers up to linux, windows, etc https://vanheusden.com/emulation/PDP-11/kek/ Currently it can run UNIX 7 in multi user mode. Of course I would like it to run BSD 2.11 as well (because of the networking support). It boots, but after outputting the memory amounts it produces a lot of garbage. It does eventually complete booting and then allows you to log in. I wonder if you sees this: https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI (text) or https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935… (image), does this ring a bell to anyone? I verified with simh that the disk-image should work. regards -- www.vanheusden.com

2 months, 3 weeks

5
10
0 0

Current Status of AT&T/USL Licensing?

by segaloco

So System V shops had to hold a license with AT&T to modify and redistribute code based on UNIX System V and they would then license directly with their customers correct? This being distinct from the way licensing with BSD was concerned in that you had to pursue the license with AT&T to then use BSD. That is my current understanding anyway that I base this question on. So IBM, DEC, Sun, HP, Microsoft, etc. approach AT&T, got a source license, and started producing their System V value adds out there in the world. In this present day and age, for those still shipping genuine System V derivatives, what does this licensing landscape actually look like? Do the players still in the game still refer to whatever license they started with back in the 80s, did they renew up until say SVR4 when folks stopped drinking from the USL well, or are there still ongoing licenses that the remaining vendors have to renew to distribute their software? Where I'm going with this is just another angle on the whole "who owns System V" question which comes up in my mind all the time. Knowing the specific legal entities involved in the most recent licensing documentation would certainly factor into understanding the landscape a little better. To boil that down to a specific example, once upon a time, Sun held a license with AT&T to use, modify, and redistribute UNIX System V. At the present moment, Oracle is the distributor of Solaris. If there is a piece of licensing paperwork sitting in a filing cabinet at Oracle somewhere, who would that paperwork say is the original licensor of the product? Would that even matter in this year of 2025? - Matt G.

2 months, 4 weeks

6
5
0 0

2.11BSD Patch Announcements

by Henry Bent

Hi all, I see that there has been quite a bit of activity in the last few weeks with 2.11BSD, resulting in the release of a number of patches. Is there any sort of announcement list that one could subscribe to in order to be notified of when these patch releases occur? Would it make sense to post patch announcements to the TUHS or SIMH lists? TUHS seems somewhat natural since one of the patch distribution methods is through their archive, though I am open to thoughts that anyone else has about this. I only happened to be aware of the patches because I have the "History of the Berkeley Software Distribution" page on my Wikipedia watchlist and someone has been very diligent about updating the 2.11BSD patch status there. -Henry

3 months

2
2
0 0

Re: non-Posix input files

by Douglas McIlroy

> "The requirement that awk add a trailing <newline> to the program argument > text is to simplify the grammar, making it match a text file in form." This should no more be a *requirement* for awk than globbing should have been a requirement for MS-DOS apps. A widespread principle deserves a widespread answer. If it is a requirement on awk, then for interoperability it should be made a requirement on all programs that handle text files, especially editors. The way to do that, of course, would be to redefine text file to allow a non-newline as the last character. Ugh. Not warning perpetuates travesties like "awk END{print NR}' " giving a different answer than "wc -l". I agree that awk does the kind thing by supplying the final newline. But it should recognize that this is non-standard behavior and warn in the interest of discouraging the proliferation of garbage. Postel's so-called "robustness principle" is in play here. "Be conservative in what you send, be liberal in what you accept" would better read, "Send conservatively; receive amply but grudgingly". Doug

3 months, 1 week

4
4
0 0

Re: non-Posix input files

by Steve Simon

Re: newlines at the end of files. I hesitate to ask this in such exalted company, but isn’t it a question of whether the newline is (or should be) a line terminator, or a statement separator? -Steve

3 months, 1 week

2
1
0 0

Re: non-Posix input files

by Douglas McIlroy

>> info groff gives semantics for including nonempty files that don't end >> with newline. Such files violate the Posix definition of text file. >> >> Although groff is certainly justified in providing semantics for >> non-Posix text, I suggest that it should warn when it does so. > That's true but I'm hesitant to put groff in the business of wagging its > finger at users feeding it non-strictly-conforming text files when doing > so doesn't cause it any problems. Causing groff problems is an odd criterion. The fact that groff will paste files together unless the first happens to end in a newline is a sign of groff 's internals, not of the underlying problem. A newline missing at the end of a file is typically a symptom of either the incaution of some other program (perhaps an editor) or of a file having been unexpectedly truncated (as by a program abort). The latter cause is common enough to justify warning always, not just about cases that are inconvenient to groff. Groff is what it is, but if the treatment of absent final newlines were up for grabs, I'd argue for the more common solution: in all cases insert a newline and warn. Doug

3 months, 1 week

6
17
0 0

Marc Rochkind's article on SCCS has been published

by Nelson H. F. Beebe

The March 2025 issue of an IEEE journal has published Marc Rochkind's article on SCCS. TUHS list members discussed a draft version of the article last fall. Here is its BibTeX entry: @String{j-IEEE-TRANS-SOFTW-ENG = "IEEE Transactions on Software Engineering"} @Article{Rochkind:2025:RSC, author = "Marc J. Rochkind", title = "A Retrospective on the {Source Code Control System}", journal = j-IEEE-TRANS-SOFTW-ENG, volume = "51", number = "3", pages = "695--699", month = mar, year = "2025", CODEN = "IESEDJ", DOI = "https://doi.org/10.1109/TSE.2024.3524947", ISSN = "0098-5589 (print), 1939-3520 (electronic)", ISSN-L = "0098-5589", bibdate = "Tue Mar 25 08:57:56 2025", bibsource = "https://www.math.utah.edu/pub/tex/bib/ieeetranssoftweng2020.bib", acknowledgement = ack-nhfb, ajournal = "IEEE Trans. Softw. Eng.", fjournal = "IEEE Transactions on Software Engineering", journal-URL = "https://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=32", keywords = "Codes; Control systems; CSSC; Mainframes; Merging; Programming; SCCS; Software; software configuration management; Software development management; software engineering; Software engineering; software reliability; Software reliability; software tools; Source coding; source control management; version control systems", } ------------------------------------------------------------------------------- - 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: https://www.math.utah.edu/~beebe - -------------------------------------------------------------------------------

3 months, 1 week

4
3
0 0

Moore's Law: PDP-11 1970 vs TI's low-power small chip for under 20 cents.

by sjenkin＠canb.auug.org.au

The specs aren’t that quite equivalent: 1Kb SRAM vs 48K core memory, 32-bit vs 16-bit CPU and 24Mhz vs 1MHz, but what does that clock mean in MIPS? Anyone want to take a stab at the Moore’s Law constant over 55 years, given the specs non-equivalence? ~2.5M times price change, = 2^22 times. ===================== <https://www.nokia.com/bell-labs/unix-history/firstport.html> In 1970, they proposed buying a PDP-11 for about $65,000. [ $535,000 in 2025 according to US Inflation Calculator ] ===================== Texas Instruments Introduces MSPM0C1104 as the Smallest Available Microcontroller <https://linuxgizmos.com/texas-instruments-introduces-mspm0c1104-as-the-smal…> Measuring only 1.38mm², this wafer chip-scale package MCU is 38% smaller than existing alternatives. The MSPM0C1104 includes a 24MHz Arm Cortex-M0+ core (32-bit), 16KB of flash memory, 1KB of SRAM, a 12-bit ADC with three channels, and six GPIO pins. It also supports standard communication interfaces, including UART, SPI, and I2C. Additional features include 5V-tolerant I/Os, a 1-channel DMA controller, a CRC-16 accelerator, and various timers, including a 16-bit advanced timer and two 16-bit general-purpose timers. These MCUs operate in an extended temperature range from -40°C to 125°C and support supply voltages from 1.62V to 3.6V. The MSPM0 series starts at $0.16 in 1,000-unit quantities, with multiple configurations available. ===================== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

3 months, 1 week

1
0
0 0

"Imake: an obsolete build tool" -- anybody got this?

by ron minnich

I know it's out there, I just can't find it. It's also called the "imake rhymes with mistake" paper, a nice companion to "going for baroque..."

3 months, 2 weeks

15
28
0 0

A Unix Code Walkthrough by Ken Thompson

by Warren Toomey

Hi all, I've just received a set of MP3 recordings from Bob Kridle. He says: These are recordings of Ken Thompson doing a read through of one of an early UNIX kernel code listing with a group of grad students at UC Berkeley while he was a visiting prof. there. The date is roughly 1975. I've put the recordings here along with his e-mails about the recordings: https://www.tuhs.org/Archive/Recordings/1975_Unix_Code_Walkthru/ I've only just listened to the first few minutes of each. The quality is fine, but I might spend some time reducing the noise, bringing up the quiet parts and removing a few clicks and pops. If anybody else has more details of these recording, please let us know! Cheers, Warren

3 months, 3 weeks

2
4
0 0

MPM macros and code from 2002

by arnold＠skeeve.com

Hi All. A while back I found a copy of the MPM macros and code that I undoubtedly got from Brian Kernighan. Warren has put it in the archives: > Date: Mon, 17 Mar 2025 08:04:55 +1000 > From: Warren Toomey <wkt(a)tuhs.org> > To: Aharon Robbins <arnold(a)skeeve.com> > Cc: Warren Toomey <wkt(a)tuhs.org> > Subject: Re: MPM macros and code > > On Fri, Mar 07, 2025 at 03:11:47PM +0200, Aharon Robbins wrote: > > I have the following file: > > -rw-r--r-- 1 arnold arnold 100770 Feb 17 2002 mpm.shar > > Thanks Arnold, I've just put it here: > > https://www.tuhs.org/Archive/Applications/Typesetting/ > > Cheers! Warren Thanks Warren! Arnold

3 months, 3 weeks

3
3
0 0

Caldera release of awk, grep, and libregex from 2001

by arnold＠skeeve.com

Hi All. A while back I found the Caldera release of awk, grep and libregex from 2001. The tar file is dated 2012, but the actual code is from earlier. Warren has put it in the archive: > Date: Mon, 17 Mar 2025 08:07:12 +1000 > From: Warren Toomey <wkt(a)tuhs.org> > To: Aharon Robbins <arnold(a)skeeve.com> > Cc: Warren Toomey <wkt(a)tuhs.org> > Subject: Re: Caldera release of awk, grep, and libregex from 2001 > > On Mon, Feb 24, 2025 at 06:42:50PM +0200, Aharon Robbins wrote: > > I'm looking through my Downloads directory to try to clean it up > > a bit. I found this: > > > > $ ls -l osutils.tar.gz > > -rw-rw-r-- 1 arnold arnold 101072 Nov 25 2012 osutils.tar.gz > > Thanks for this as well, it's now at: > https://www.tuhs.org/Archive/Applications/Awk_Grep/ > > Cheers, Warren Thanks Warren! Arnold

3 months, 3 weeks

1
0
0 0

Question about compiled programs on a newer machine type be usable ?

by babydr DBA James W. Laferriere

Hello all , Here I am again , Maybe my ? might be relative to the community . I grabbed an archive of precompiled gnu software , During the extraction I got a 'warning' from a gzip'd tar & decided to dig into the underlying tarball to see if it was trully corrupted or repairable . Tada , I did a silly and less'd one of the binary files and noticed that the underlying file was 'ar'd by /usr/local/alphaev6-dec-osf5.1b/bin/ar , well all said and done My ol' as100 ain't a ev6 . So my Question , Could I use these programs that were created on a ev6 cpu system on my ev4 ? Tia , JimL -- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml(a)system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+

3 months, 3 weeks

2
2
0 0

a bit of Plan9 history

by Jan Schaumann

Hi, This was seen on Dave Farber's IP list; with many of the Dramatis Personae on this list it seems worthwhile to share it here, too: "What I Saw at the Evolution of Plan 9" by Geoff Collyer https://adi.onl/oral.pdf -Jan

3 months, 3 weeks

2
1
0 0

When/how did ctime change from inode "creation" to "change" time?

by Theodore Ts'o

As part of a discusion on the Linux kernel mailing list, there was an assertion that ctime was orginally "creation time". From the v7 sources in TUHS, we can see: struct dinode { unsigned short di_mode; /* mode and type of file */ short di_nlink; /* number of links to file */ short di_uid; /* owner's user id */ short di_gid; /* owner's group id */ off_t di_size; /* number of bytes in file */ char di_addr[40]; /* disk block addresses */ time_t di_atime; /* time last accessed */ time_t di_mtime; /* time last modified */ time_t di_ctime; /* time created */ }; ... although the v7 kernel sources does seem to update ctime when the inode metadata changes, regardless of what the coment in /usr/src/sys/h/ino.h might say. More interestingly, this comment seems to continue in newer versions up to 3BSD, and then the comments becomes "change time" in BSD 4.2, probably coincident with the File System Implementation? The best we can guess is that the change from "creation time" to "inode change time" happened sometime between 1979 and 1982. Does anyone who was around can give the story about how and when this happened? - Ted

3 months, 3 weeks

15
20
0 0

Sad news: we lost George Colouris

by H.J.Thomassen

In July 1974 I visited Bell Labs Murray Hill, and Ken & Dennis showed me around. I was very impressed because we (Univ of Nijmegen, NL) had a PDP-11/45 just like theirs and I knew that machine quite well. It was clear that their software kicked the machine much heavier than our (DEC-original) DOS-system did. But I was a naive student so I wanted more information and asked Ken: are there many UNIX users in Europe? Ken brought us to the library where a Ms. Irma B. Biren, librarian, kept the record of licenses. We found prof. Colouris in London... When I asked whether maybe somebody closer by our place was present, Ken found Gideon Yuval in Tel Aviv. Nobody closer.... Hendrik-Jan Thomassen

3 months, 3 weeks

1
0
0 0

Re: What would early alternatives to C have been?

by Douglas McIlroy

> everyone should write for their first compiler in Pascal for a > simple language and no cheating using YACC. You need to write the whole > thing if you want to understand how parsing really works. Yacc certainly makes it easier to write parsers for big grammars, but it's far from cheating. You need to know a lot more about parsing to use Yacc than you need to roll your own. Hand parsing of a tiny grammar is almost a necessary step on the way to understanding Yacc. But I think hand-building the whole parser for a compiler is unnecessary torture--like doing trigonometry with log tables. Doug

3 months, 3 weeks

15
20
0 0

Sad news: we lost George Coulouris

by Arrigo Triulzi

Found out today that we lost George Coulouris about a month ago, he was at QMC (then QMW, now Queen Mary, University of London) in CompSci and an old Unix hand (but not only). Obituary from his PhD student (who wrote a Unix editor called “ded”): https://www.theguardian.com/education/2025/jan/19/george-coulouris-obituary

3 months, 3 weeks

1
0
0 0

"Webster's Second on the Head of a Pin"?

by Royce Williams

Someone I know is seeking the original version of an internal Bell Labs memo from 1974 titled "Webster's Second on the Head of a Pin" by Morris and Thompson. The topic appears to be related to improving the speed of lookups or search. It's cited in a few papers as "Unpublished Technical Memo, Bell Laboratories, Murray Hill, NJ 1974." All I can find online is citations. Any leads appreciated! -- Royce

3 months, 3 weeks

8
17
0 0

What would early alternatives to C have been?

by Dan Cross

As I mentioned in the discussion about C, it's easy to look back with a modern perspective and cast aspersions on C. But this got me thinking, what would possible alternatives have been? In the context of the very late 1960s heading into the early 70s, and given the constraints of the PDP-7 and early PDP-11s, what languages would one consider for implementing a system like early Unix? Dennis's history paper mentioned a very short-lived effort at Fortran, and I asked about that a few years ago, but no one really remembered much about it; I gather this was an experiment that lasted a few days or weeks and was quickly abandoned. But what else? My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was already mentioned. I don't think PL/1 (or PL/I) could have fit on those machines. Pascal was really targeted towards teaching and would have required pretty extensive work to be usable. The big question mark in my mind is Algol/W; how well known was it at the time? Was any consideration for it made? Obviously, the decision to go with BCPL (as the basis for B, which beget C) was made and the rest is history. But I'm really curious about how, in the research culture at the time, information about new programming languages made its way through the community. - Dan C.

3 months, 4 weeks

19
45
0 0

Re: uphill both ways, was Re: What would early alternatives to C have been?

by Bakul Shah

On Mar 10, 2025, at 7:26 PM, John Levine <johnl(a)taugh.com> wrote: > > In my 1971 compiler course at Yale, Alan Perlis made us try to write a compiler > that translated a subset of APL into Basic. He suggested we write it in APL, > which was a terrible idea, so I wrote it in Trac, for which I happened to have > written my own interpreter. > > I think my compiler was the only one that worked, and it was pretty clever, > turning the APL array expressions into structures with array boundaries and > example expressions, with no array temporaries. It only generated the loops to > evaluate the expressions when storing into another array. > > Someone got a PhD in 1978 for a similar compiling technique but in 1971 I was a > 17 year old twerp so what did I know? > > R's, > John Pretty impressive for a 17yo! Isn’t APL syntax rather context sensitive[1]? Neither yacc nor a RD parser would’ve helped! Unless the subset was limited to a context free subset. Tim Budd in his 1978 work made quite a few changes to APL to ease compilation and used yacc. [I have the book somewhere....] [1] I do not recall if Iverson's original APL had a context sensitive grammar but modern APLs do. Given an expression ‘x y z’, its parse depends on the types of x, y & z. Example: y(x,z) if y is a dyadic verb, x & z are values, x(y(z)) if x & y are monadic verbs, z a value etc.

3 months, 4 weeks

2
1
0 0

DCJ-11 processor with 20k FPGA

by Jason Stevens

I assume people have seen this? https://github.com/ryomuk/TangNanoDCJ11MEM/tree/main It's capable of running Unix v1 & some limited amount of v6 among other things. The FPGA in question the Tang Nano 20k is sub 30GBP delivered from AliExpress. Kind of neat to combine a real processor with a simple FPGA implementation of the hardware.

3 months, 4 weeks

3
2
0 0

Re: What would early alternatives to C have been?

by Paul McJones

Ken, Was smalgol also known as BC Algol, as described here: https://www.softwarepreservation.org/projects/ALGOL/algol60impl/#BC_ALGOL > On Mar 9, 2025, at 12:06 PM, Ken Thompson <kenbob(a)gmail.com <mailto:kenbob@gmail.com>> > wrote: > > how about smalgol? > > it was an algol-like language with just int and float types. > i dont know its history, but it came out of berkeley near > when Niklaus Wirth was there. it compiled for the ibm 7094 > in normal batch processing fashion. i converted it to a jit > into memory in order to skip the loading phase. i used > it for a lot of my fun-work. (1965-66) > > mainframe time, then, was a big factor in the computing process. > smalgol could compile, load, and run in about 1 cpu-second. > > smalgol was all ibm-cards, but it was on my mind through > the bcpl to b to nb phases. i would use the modern word > "influencer.” Paul McJones

4 months

2
1
0 0

Re: BWK on possible alternative programming languages

by Douglas McIlroy

Adding to Brian's remarks. Both PL/I, which had been adopted by Multics, and BCPL/B were very familiar. PL/I , even gutted as it had been for Multics, was much too big to contemplate. BCPL's integration of subscripting and pointers was nice, as was its closeness to the machine. Typlessness was a drawback: how would one integrate floating point or characters? Another was the global vector, like Fortran COMMON. Algol W was known (to me, at least) only via its publication in CACM. I don't recall it having been considered. Because Algol W had more concepts than BCPL,was not as closely matched to machine-level coding, and (I believe) was equally lacking in separate-compilation facilities, I suspect it would not have made the cut. Doug

4 months

1
0
0 0

BWK on possible alternative programming languages

by arnold＠skeeve.com

I asked BWK if he had any thoughts about possible alternative languages. Here is his response, forwarded by permission. Arnold > Date: Sun, 9 Mar 2025 08:27:57 -0400 (EDT) > From: Brian Kernighan <bwk(a)cs.princeton.edu> > To: arnold(a)skeeve.com > cc: crossd(a)gmail.com, Brian Kernighan <bwk(a)cs.princeton.edu> > Subject: Re: An interesting history question > > Dan raises an interesting question. I don't have a good answer, > but there are possibilities. > > Typeless languages like BCPL were in the air; Bliss, from CMU in > 1970, was a significant example, used mostly on the PDP-10 but it > could run on a PDP-11. It was definitely a contender for doing > systems work. > > I used MAD in the summer of 1966 at MIT and remembered it as being > much nicer than Fortran, though when I looked at a description a > while ago, it wasn't clear what the attraction was. > > Bell Labs (Doug McIlroy and Bob Morris, mostly) made a PL/I subset > called EPL that was at least compilable and a lot easier to manage > than the full language. I don't know whether that would have > worked, but it would seem that Ken didn't think so, since he went > off on his own direction. Doug would know more; he sent me some > corrective info a month ago, on the errata page here: > > https://www.cs.princeton.edu/~bwk/memoir.html > > Fortran would have needed major work to handle non-numeric data. > I wrote a text formatter in it by hacking with the Logical*1 type; > that let me handle one character at a time by basically lying, > though I've long since forgotten the details. > > Pascal was hopeless, as I have described elsewhere, though > variants that repaired some of the type system might have worked. > > The US military used Jovial; it sounds like it's still sort of in > use, since it handles the avionics in a lot of planes. It looks > like a direct descendant of Algol 58. > > I never used Algol/W, but of all the options, it seems like it > might have been the strongest contender. > > Xerox PARC had Mesa, but my dim memory is that it was big and > complicated, which is the opposite of what was needed at the time. > It also came along too late, mid to late 1970s. It did influence > Java and Modula-2, says Wikipedia. > > HOPL 1 includes papers on other languages of the time, most of > which would not have worked, and/or have died by now. There's a > lot of history, and I have no idea how to get on top of it all. > But still interesting to look at and speculate about. > > Brian > > > On Sat, 8 Mar 2025, arnold(a)skeeve.com wrote: > > > Hi Brian. > > > > Any thoughts on this? > > > > (cc-ing Dan, the original poster) > > > > Thanks, > > > > Arnold > > > >> From: Dan Cross <crossd(a)gmail.com> > >> Date: Sat, 8 Mar 2025 22:46:58 -0500 > >> To: TUHS <tuhs(a)tuhs.org> > >> Subject: [TUHS] What would early alternatives to C have been? > >> > >> As I mentioned in the discussion about C, it's easy to look back with > >> a modern perspective and cast aspersions on C. But this got me > >> thinking, what would possible alternatives have been? In the context > >> of the very late 1960s heading into the early 70s, and given the > >> constraints of the PDP-7 and early PDP-11s, what languages would one > >> consider for implementing a system like early Unix? Dennis's history > >> paper mentioned a very short-lived effort at Fortran, and I asked > >> about that a few years ago, but no one really remembered much about > >> it; I gather this was an experiment that lasted a few days or weeks > >> and was quickly abandoned. But what else? > >> > >> My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was > >> already mentioned. I don't think PL/1 (or PL/I) could have fit on > >> those machines. Pascal was really targeted towards teaching and would > >> have required pretty extensive work to be usable. The big question > >> mark in my mind is Algol/W; how well known was it at the time? Was any > >> consideration for it made? > >> > >> Obviously, the decision to go with BCPL (as the basis for B, which > >> beget C) was made and the rest is history. But I'm really curious > >> about how, in the research culture at the time, information about new > >> programming languages made its way through the community. > >> > >> - Dan C. > >> > > >

4 months

4
4
0 0

Step Into the Real-Life Lumon Industries, the Breakout Star of ‘Severance’

by Rich Salz

Gift article about Holmdel facility... Bell Works, the setting of the hit serial for Apple TV+, is now a tourist attraction, drawing fans to the architectural wonder. https://www.nytimes.com/2025/03/07/realestate/severance-lumon-industries-bu… <https://urldefense.com/v3/__https://www.nytimes.com/2025/03/07/realestate/s…>

4 months

12
14
0 0

Re: Any UNIX With No C In Userland?

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy > Not once did I think about packing, the structs somehow just worked on > the machines I was working on. Maybe the TCP/IP guys knew about spacing > in the structs. Not really! Of the first 6 TCP/IP implementations: https://gunkies.org/wiki/TCP_and_IP_bake_offs only 1 was in C - and it was a relatively late one. The earliest ones were mostly in assembler (PDP-10 and PDP-11). Noel

4 months

6
7
0 0

Re: Any UNIX With No C In Userland?

by jnc＠mercury.lcs.mit.edu

> There may have been a better way to do it CLR R0 BISB (R1)+, R0 SWAB R0 BISB (R1)+, R0 That saved one instruction over the previous one. Noel

4 months

1
0
0 0

Re: Any UNIX With No C In Userland?

by jnc＠mercury.lcs.mit.edu

> From: Phil Budne > BUT, the basic TCP and IP protocols seem to have been created with a > general care that two byte fields should be aligned at multiples of two > bytes Yes, because dealing with a 16-bit field that spans two PDP-11 16-bit words is a pain (espcially because the PDP-11 does not have a 'load byte into register _without_ extending the sign bit into the high half' instruction). Do realize that in addition to the early TCP implementation, the _first_ TCP router (at that stage, TCP and IP were not separate protocols) was also a PDP-11 (albeit programmed in BCPL, not MACRO-11). I remember the extension being a real PITA. To load an un-aligned 16-bit quantity into R0, one would have had to do something like (assuming a pointer to the un-aligned 16-bit quantity was in R1): MOVB (R1)+, R0 SWAB R0 BIC #0377, R0 BISB (R1)+, R0 There may have been a better way to do it, but that's the best I can come up with now; I recall we had to do something like that. Yes, the 16-bit fields were 16-bit word aligned. Noel

4 months

1
0
0 0

Re: DCJ-11 processor with 20k FPGA

by Jason Stevens

the code in the repo is for the FPGA, the processor that is strapped to the FPGA well it runs the real code. It's like the 'minimig' Amiga emulator platform, a real processor, and FPGA to do all the IO heavy lifting. So it's not 100% FPGA but you are executing code on a real processor so you aren't exactly full emulation either. And it doesn't cost a fortune, assuming you can find one of these ancient microprocessors. -----Original Message----- From: emanuel stiebler To: Jason Stevens; 'tuhs(a)tuhs.org' Sent: 3/5/25 2:50 PM Subject: Re: [TUHS] DCJ-11 processor with 20k FPGA On 2025-03-01 07:11, Jason Stevens via TUHS wrote: > I assume people have seen this? > > https://github.com/ryomuk/TangNanoDCJ11MEM/tree/main > > > It's capable of running Unix v1 & some limited amount of v6 among other > things. The FPGA in question the Tang Nano 20k is sub 30GBP delivered from > AliExpress. > > Kind of neat to combine a real processor with a simple FPGA implementation > of the hardware. I just had a look at it, but he doesn't show the code, which runs on the TangNano?

4 months

2
1
0 0

Re: Any UNIX With No C In Userland?

by jnc＠mercury.lcs.mit.edu

> From: Rob Pike > The notion that the struct layout must correspond to the hardware > device's layout is about as non-portable as thinking can get. I'm confused; I thought device register layout is inherently about as non-portable a thing as one could have, generally. (Exceptions: 1) the device is basically a single chip, so interfaces on two machines might be essentially identical, if they use the same chip; 2) someone made a 68K card that plugged into a QBUS, so drivers on a PDP-11 and that 68K could be identical.) Or did you mean that one could somehow disassociate the struct layout and the details of the device (assuming it has addressable registers, as became common)? How (I'm missing it)? Noel

4 months

2
1
0 0

Re: Any UNIX With No C In Userland?

by jnc＠mercury.lcs.mit.edu

> From: "G. Brandn Robinson" > C was a language for people who wanted to get that crap out of the way > so they could think about binary representations. Huh? Sometimes C gets in the way of doing that; see below. > From: Dan Cross > They did indicate that alignment makes sharing _binary_ data between > VAX and PDP-11 harder, but that's truerepresentation of other aspects of product > types as well. Alignment is just one aspect of low-level binary representation; there's also length (in bits), which is critically important in several problem domains; device registers have already been mentioned, but more below. > From: Peter Yardley > Problems I have with C as a systems language is there is no certainty > about representation of a structure in memory and hence when it is > written to disk. That's yet another one. The area I'm thinking of (and which I saw a lot of) is code to implement network protocols (and I'm fairly astounded that nobody else has mentioned this yet). One has to have _absolute_ control over how the bits are laid out in the packet (which of course might wind up in any one of countless other machine types) - which generally means how they are laid out in memory. The whole concept of C declarations is not rich enough to really deal with this properly. For each field in the header, one absolutely needs to be able to separately specify the syntax (e.g. size in bits) and semantics (unsigned integer, etc). And if you want the code to be portable, so that one set of sources will compile to working code on several different architctures, it gets worse. Device registers, already mentioned, often only have to run on one type of machine, but having protocol implementions run on a number of different machine types is really common. I came up with a way to do this, without _any_ #ifdefs (which I don't like, for a reason I won't get into) in most source files. Dealing with byte order issues was similarly dealt with (one can't deal with it just in types, really, without making the type specification, and the language, somewhat complicated). I know later C's got better about richer variable semantics and syntax selection than the circa 1985 ones I was working with, but I don't think it was ever made completely simple and orthogonal (e.g. 'signed/unsigned/boolean/etc char/short/long/quad/word/etc') as it should have been. Noel

4 months

7
7
0 0

Any UNIX With No C In Userland?

by segaloco

Given that anything that obeys the ABI and has assembler entries to the kernel can request services, it seems to me it would be possible to stand up a user-land without C being present. Have any UNIXen ever done this after the advent of C? - Matt G.

4 months

28
65
0 0

Language-lawyers' field day (was Any UNIX With No C In Userland?)

by Douglas McIlroy

> Everything that can possibly be represented in a machine > register with all bits clear shows up as an integral zero literal. > '\0' == 0 == nullptr == struct { } == union { } Well, some things. 0.0f and other floating-point zero constants are represented by all-zero words (of various sizes) and are not integral constants. NULL does not "show up as an integral zero literal". 0==NULL is true only because 0 can be converted to NULL. Getting really lawyerly, one can cook up any number of bizarre "things that can possibly be represented" by an all-zero word, for example (char[4]){0,0,0,0}, and have no representation as an integral constant. Only 3 of the 5 examples fit the description of possibly being represented by an all-zero word. struct{} and union{} are gnu extensions with size zero. Even if you accept them as C, they have no machine representation and cannot be cast to int. The null pointer makes the list only thanks to the weasel-word "possibly". Although 0 can be cast to the null pointer, the result of casting a null pointer to int depends on its unspecified machine representation. Zero, of course, is a good choice because it's easy to test for, and is easy to omit from virtual address spaces. Doug

4 months, 1 week

1
0
0 0

Having dickens of a time compiling gcc-4.4.7 on tru64 .

by babydr DBA James W. Laferriere

Hello Anyone interested in this silliness , I am just recently trying to reacquaint myself with this os . Which I had a decent passing knowledge of at one time . Not any real OS level or driver coding , But was least decently acquainted . Now on with the preliminaries ... Any good software items to update on this ol'thing that give me a better chance of completing this task , Greatly welcome . I have folowed , ths article which is a copy from (imo) several places , tho all of them are using a axp-Emulator . <https://gist.github.com/jamesy0ung/eeac82997ebeae92873d1f2844a14ac3> I am using (I'll admit) a REAL AlphaStation 200 (4/100) with 384MB main memory & three disks all are U160's 2x4G+1x72G , OS is installed on the 72G(now) & has a /home dir for users rather that the default location . See info & error during make of gcc . Those numbers for the allocation & total have been exactly the same accross many iterations of attempts in that exact file . # sizer -v HP Tru64 UNIX V5.1B (Rev. 2650); Sun Feb 23 19:43:32 AKST 2025 It is at patch level 008 . and had successfully compiled & installed all the prerequisites shown in the article mentioned above . It Seems the OS doesn't know how to access the swap properly . root@as200:/home/buildnfs/gcc-4.4.7# env PATH=/usr/local/bin:/sbin:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/dt/bin:~/bin:. make ... many lines snipped ... /home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/xgcc -B/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/ -B/usr/local/alpha-dec-osf5.1b/bin/ -c -g -$ cc1: out of memory allocating 135816 bytes after a total of 796519376 bytes make[3]: *** [fold-const.o] Error 1 make[3]: Leaving directory `/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/buildnfs/gcc-4.4.7' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/buildnfs/gcc-4.4.7' make: *** [all] Error 2 # swapon -s Swap partition /dev/disk/dsk2g: Allocated space: 249774 pages (1.91GB) In-use space: 1520 pages ( 0%) Free space: 248254 pages ( 99%) Swap partition /dev/disk/dsk1b: Allocated space: 49152 pages (384MB) In-use space: 1630 pages ( 3%) Free space: 47522 pages ( 96%) Swap partition /dev/disk/dsk0b: Allocated space: 49152 pages (384MB) In-use space: 1618 pages ( 3%) Free space: 47534 pages ( 96%) Total swap allocation: Allocated space: 348078 pages (2.66GB) In-use space: 4768 pages ( 1%) Available space: 343310 pages ( 98%) # hwmgr show scsi SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH ------------------------------------------------------------------------- 42: 0 as200 cdrom none 0 1 cdrom0 [0/4/0] 43: 1 as200 disk none 2 1 dsk0 [1/0/0] 44: 2 as200 disk none 2 1 dsk1 [1/1/0] 45: 3 as200 disk none 2 1 dsk2 [1/2/0] # hwmgr -view dev HWID: Device Name Mfg Model Location ------------------------------------------------------------------------------ 3: /dev/dmapi/dmapi 4: /dev/scp_scsi 5: /dev/kevm 29: /dev/disk/floppy0c 3.5in floppy fdi0-unit-0 42: /dev/disk/cdrom0c TOSHIBA DVD-ROM SD-M1401 bus-0-targ-4-lun-0 43: /dev/disk/dsk0c IBM DDRS-34560D bus-1-targ-0-lun-0 44: /dev/disk/dsk1c COMPAQ BD07286224 bus-1-targ-1-lun-0 45: /dev/disk/dsk2c COMPAQ ST34371W bus-1-targ-2-lun-0 46: /dev/random 47: /dev/urandom Tia , JimL -- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml(a)system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+

4 months, 1 week

16
21
0 0

Re: Pre-Struct C Compiler with Funny Syntax Resurrected

by Douglas McIlroy

Yufeng, > I've recently brought the "prestruct-c" compiler back to "life" Great archeology! It seems you've unearthed a snapshot from the brief period when Dennis was struggling to reconcile byte addressing with BCPL pointers--the seminal innovation of C. In characteristic Unix fashion, he was trying out his ideas as they developed. I had forgotten that product types were under con-struct-ion at the same time. That really was a big bang. Doug

4 months, 2 weeks

1
0
0 0

Pre-Struct C Compiler with Funny Syntax Resurrected

by Yufeng Gao

Hi again, I've recently brought the "prestruct-c" compiler back to "life" (https://github.com/TheBrokenPipe/C-Compiler-Dec72) and thought it might be worth documenting here. One thing I have to say first - it's barely working and probably never worked to begin with. There were some efforts in the distant past to revive this compiler; however, the compiled compiler never worked. The reasons are as follows: - The compiled executable is too big (exceeds 32K, making pointers effectively negative). This triggers a bug in the liba I/O routines. - The compiler assumes an origin of 0 and writes temp data at the NULL pointer. Without an MMU, this kills the interrupt vectors and possibly the kernel on the 11/20. - The compiler is missing ALL code/tables written in assembly language. This is pretty fatal, and internal changes rendered files from the last1120c compiler incompatible. - Calling convention changes make the s2/last1120c libc library incompatible. I'm a big fan of the C programming language, and the reason I was so insistent on getting this compiler to work is that it has a funny struct syntax not seen in any other C compiler. Structs are defined like: struct name ( type field; ... ); ... with round brackets (parentheses) instead of curly braces. Another notable thing introduced in this compiler is that certain things are no longer lvalues. In the past (B and last1120c), functions, labels, and arrays were lvalues, meaning they could be assigned. For instance, this code: func1() { return (1); } func2() { return (2); } main() { printf("func1() = %d\n", func1()); printf("func2() = %d\n", func2()); printf("func1 = func2\n"); func1 = func2; printf("func1() = %d\n", func1()); } produces the output: func1() = 1 func2() = 2 func1 = func2 func1() = 2 This code: main() { second = first; goto second; first: printf("first\n"); second: printf("second\n"); } produces the output: first second And this code: main(argc, argv) { int arr1[10]; int arr2[10]; arr1[0] = 5; arr2[0] = 8; printf("arr1[0] = %d\n", arr1[0]); printf("arr2[0] = %d\n", arr2[0]); printf("arr1 = arr2\n"); arr1 = arr2; printf("arr1[0] = %d\n", arr1[0]); } produces the output: arr1[0] = 5 arr2[0] = 8 arr1 = arr2 arr1[0] = 8 Now, the rules of the game have changed with the prestruct-c compiler, and these are no longer lvalues. I don't know why this change was made, but if I had to guess, speed was probably the biggest driving factor, with security also playing a role. Anyhow, they're no longer lvalues, so there's now one less level of indirection involving functions and labels. This means the codegen tables from last1120c have to be modified to suit this compiler change. However, even with it generating the correct code, there is still one fatal problem - the libc. The libc from s2/last1120c was designed for the older compiler and therefore has one extra layer of indirection for functions. Luckily, the source code of the libc is available on the last1120c tape, and it wasn't too much work to remove the indirection manually. Okay, what else? Well, this compiler also seems to be the first to introduce the "modern" pointer syntax. Before this compiler, pointers were declared using the same syntax as arrays/vectors, like "char name[];". This compiler introduced the "modern" syntax of "char *name;". No big deal, right? Well, the compiler itself was written using the old syntax, meaning it cannot compile itself. I think this indicates that this compiler (or the new syntax) was so unstable that the production compiler still used the old syntax. With everything carefully put back into place, I managed to get this to work: struct foo ( char x; int y; char *z; ); main(argc, argv) char **argv; { struct foo bruh; bruh.x = 'C'; bruh.y = 123; bruh.z = "test"; printf("x = '%c', y = %d, z = \"%s\"\n", bruh.x, bruh.y, bruh.z); } However, if I rename the variable "bruh" to something like "bar", it throws the error "Unimplemented pointer conversion". I have no clue why. I've also never gotten struct pointers to work - it always complains about "Illegal structure ref" when I try to use "->". It also seems to accept "." on structure pointers (and does not actually dereference the pointer when accessing the members), so something is probably very wrong with referencing and dereferencing. Anyway, there are plenty of other issues with the compiler, like the code may not compile correctly with pointers and switch statements. I'm not sure if the issues are caused by my poor reconstruction of the assembly tables, or if the compiler itself never worked properly in the first place (or both). Either way, I've managed to get it to spit out a correct hello world, as well as the struct test above, so I think I've fulfilled my goal of seeing this compiler "work". The code, build instructions and pre-built binaries are here: https://github.com/TheBrokenPipe/C-Compiler-Dec72 Ideally, it runs under a PDP-11/45 environment with 0 as the origin and generates code for the PDP-11/45. However, I made it target the 11/20 since I couldn't get the 11/45 toolchain to work, and I haven't implemented 11/45 instructions in my simulator yet. If anyone wants to pick up the baton and get it working for the 11/45 or fix my bugs, be my guest! Sincerely, Yufeng

4 months, 2 weeks

1
0
0 0

Re: 1972 UNIX V2 "Beta" Resurrected

by jnc＠mercury.lcs.mit.edu

> From: Yufeng Gao > The s1 kernel is, to date, the earliest machine-readable UNIX kernel, > sitting between V1 and V2. It will be interesting to see what it reveals, as it's in the UNIX 'dark age' between V1 and V4. Working from hints and clues in the extant 'UNIX Programmer's Manual: Second Edition', I had tried to figure out how V2 differed from V1: https://gunkies.org/wiki/UNIX_Second_Edition but I was mostly interested in 'big picture' issues (like how a process'es address space was laid out), not details like 'the foo() call was added', or 'how exec() differs'. (If someone _does_ create lists of the calls in V1 and V2, and their details, and compares them, that _will_ be of value, don't get me wrong; I was mostly just trying to work out how the mysterious KS11 worked.) > It's somewhat picky about the environment. So far, aap's PDP-11/20 > emulator .. is the only one capable of booting the kernel. SIMH and > Ersatz-11 both hang before reaching the login prompt. It would be very interesting to know what fails. By 'hang', do you mean 'ceases making progress', or 'halts'? If the former, since I've almost always had good experiences with Ersatz-11, my _guess_ would be a problem with the RF11 emulation. (The RF11 was a very early, and smalll, disk, so I wouldn't be surprised if there hasn't been a lot of software run on those emulators that uses it, to flush out bugs. It's also kind of an odd duck; it's word-oriented, not block-orientd.) So, for instance, a 'lost' disk interrupt would produce this symptom. Are there any RF11 diagnostics online? That would be the thing I would start with. And I guess this system doesn't include the KS11; a pity, code that uses it would allow re-creation of the programming manual (the way the: https://gunkies.org/wiki/ANTS/ISI_IMP_Interface programming instructions were re-created). > From: Angelo Papenhoff > So the next step would be to restore the assembly source? :) Having only the binary to work from (to start with) is not optimal; those early versions of UNIX ran on a number of very different hardware configurations (e.g. with or without the KS11), with conditional assembly to handle different configurations. Having only the dis-assembled code for _this_ configuration would obviously leave the code for the others missing. Still, having _this_ source _would_ be useful; e.g. the 'hang-up' problem above; the easiest way to debug that would to put 'print' statements in the code, where a disk operation was started, and completes. If it's 'losing' a disk interrupt completion, that will show right up. (Been there, done that, on the RK11 hardware emulator Bridgham and I built, when UNIX wouldn't boot, just hung.) Although I suppose one could put break-points there. Trying to debug it any other way would be painfu beyond belief. Noel

4 months, 2 weeks

3
3
0 0

Typesetting ROFF/NROFF Documents

by Yufeng Gao

Hi everyone, I've cobbed together a crude Teletype Model 37 emulator that generates PDF files (https://github.com/TheBrokenPipe/Teletype-37-PDF) It produces sane-looking PDFs for most (all?) of the early UNIX ROFF/NROFF documents. The biggest advantage of this over something like "roff $1 | enscript -c -f Courier12 -l -M Letter --margins=67:-9:0:-9 -p $1.ps -s -0.05" is it supports half (forward/reverse) line feeds which enscript does not. Early ROFF stuff like the UNIX manuals and memos made extensive use of subscripts (and superscripts), making them rather painful to typeset. As an experiment, I re-set Ken Thompson's "Users' Reference to B" memo from early 1972 (https://github.com/TheBrokenPipe/kbman-reset) I picked this one because it contains a BNF-alike description of the grammar as well as fractions in code comments, both of which make extensive use of sub/superscripts. I went to the extent of overlaying the re-set pages on top of the originals to make sure everything lined up. I'd really appreciate it if someone could review my work on the B manual. If everything looks good, I may tackle other documents, starting with low hanging fruits like the "V0" manual and potentially moving on to re-setting the V1 and V2 manuals in the future (building on aap's work). Sincerely, Yufeng

4 months, 2 weeks

2
1
0 0

1972 UNIX V2 "Beta" Resurrected

by Yufeng Gao

Hi everyone, First-time poster here. Near the end of last year, I did some forensic analysis on the DMR tapes (https://www.tuhs.org/Archive/Applications/Dennis_Tapes) and had some fun playing around with them. Warren forwarded a few of my emails to this list at the end of last year and the beginning of this year, but it was never my intention for him to be my messenger, so I'm posting here myself now. Here's an update on my work with the s1/s2 tapes - I've managed to get a working system out of them. The s1 tape is a UNIX INIT DECtape containing the kernel, while s2 includes most of the distribution files. The s1 kernel is, to date, the earliest machine-readable UNIX kernel, sitting between V1 and V2. It differs from the unix-jun72 kernel in the following ways: - It supports both V1 and V2 a.outs out of the box, whereas the unmodified unix-jun72 kernel supports only V1. - The core size has been increased to 16 KiB (8K words), while the unmodified unix-jun72 kernel has an 8 KiB (4K word) user core. On the other hand, its syscall table matches that of V1 and the unix-jun72 kernel, lacking all V2 syscalls. Since it aligns with V1 in terms of syscalls, has the V2 core size and can run V2 binaries, I consider it a "V2 beta". login: root root # ls -la total 42 41 sdrwrw 7 root 80 Jan 1 00:02:02 . 41 sdrwrw 7 root 80 Jan 1 00:02:02 .. 43 sdrwrw 2 root 620 Jan 1 00:01:30 bin 147 l-rwrw 1 root 16448 Jan 1 00:33:51 core 42 sdrwrw 2 root 250 Jan 1 00:01:51 dev 49 sdrwrw 2 root 110 Jan 1 00:01:55 etc 54 sdrwrw 2 root 50 Jan 1 00:00:52 tmp 55 sdrwrw 7 root 80 Jan 1 00:00:52 usr # ls -la usr total 8 55 sdrwrw 7 root 80 Jan 1 00:00:52 . 41 sdrwrw 7 root 80 Jan 1 00:02:02 .. 56 sdrwrw 2 28 60 Jan 1 00:02:22 fort 57 sdrwrw 2 jack 50 Jan 1 00:02:39 jack 58 sdrwrw 2 6 30 Jan 1 00:02:36 ken 59 sdrwrw 2 root 120 Jan 1 00:00:52 lib 60 sdrwrw 2 sys 50 Jan 1 00:02:45 sys 142 s-rwrw 1 jack 54 Jan 1 00:52:29 x # ed a main() printf("hello world!\n"); . w hello.c 33 q # cc hello.c I II # ls -l a.out total 3 153 sxrwrw 1 root 1328 Jan 1 00:02:12 a.out # a.out hello world! # It's somewhat picky about the environment. So far, aap's PDP-11/20 emulator (https://github.com/aap/pdp11) is the only one capable of booting the kernel. SIMH and Ersatz-11 both hang before reaching the login prompt. This makes installation from the s1/s2 tapes difficult, as aap's emulator does not support the TC11. The intended installation process involves booting from s1 and restoring files from s2. What I did was I extracted the files from the s1 tape and placed them on an empty RF disk, then installed the unix-jun72 kernel. After booting from the RF under SIMH, I extracted the remaining files from s2. Finally, I replaced the unix-jun72 kernel with the s1 kernel using a hex editor, resulting in an RF disk image containing only files from s1/s2. This RF image is bootable under aap's emulator but not SIMH. The RF disk image can be downloaded from here (https://github.com/TheBrokenPipe/Research-UNIX-V2-Beta) Direct link - https://github.com/TheBrokenPipe/Research-UNIX-V2-Beta/raw/refs/heads/main/… Interestingly, its init(7) program does not mount the RK to /usr, suggesting that /usr was stored on the RF. Sincerely, Yufeng

4 months, 2 weeks

2
1
0 0

Unix page at the Multicians web site.

by Dan Cross

Tom Van Vleck just posted to the multicians mailing list that he is doing an update to the Unix page at multicians.org and is soliciting feedback. I figure some folks here may have useful suggestions. His draft is here: https://multicians.org/unix2.html Comments directly to Tom, I suppose, but if interested parties would rather discuss here I'd be happy to summarize and send to him as well. - Dan C.

4 months, 2 weeks

1
0
0 0

Re: Unix V10 Volume 2 PDFs

by norman＠oclsc.org

For the non-TUHS folks who don't know me, I worked in Center 1127 (the Bell Labs Computing Science Research Center) 1984-1990, and had some hand in 9th and 10th Edition Manuals and what passed for the V8-V10 `distributions.' To answer Branden's points: A. I do know what version of troff was used to typeset the 8th through 10th Edition manuals. It was the version we were using in 1127 at the time, which was indeed Kernighan's. The macro packages probably matter more than the particular troff edition. For the 10th Edition (which files I have at hand), there was an individual mkfile (mk(1)) for each paper, so in principle there was no fixed formatting package, but in practice everything appears to have used troff -mpm, with various preprocessors according the paper: prefer, tbl, pic, ideal, and in some cases additional macros and even odds and ends of sed and awk. If you wanted to re-render things from scratch you'd want all the tools. But if you have the real troff sources you'll have all the mkfiles--things were stored one paper per directory. -mpm (mpm(6) in 10/e vol 1) was a largely ms-compatible package with special expertise in page layout. B. There was no such thing as a `release' after V7. In fall 1984 we made a single V8 snapshot. Making that involved a lot of fiddly work, because we didn't normally try to build systems from scratch; when we brought in a new computer we cloned it from an existing one. So there was lots of fiddly work to make sure every program in /bin and /usr/bin on the tape compiled correctly from the source code that would be on the tape when the cc and as and ld and libraries on the tape were used. We sent V8 tapes to about a dozen external places, few of which did anything with it (many probably never even installed it). Which makes sense, by then we really weren't a central source for Unix even within AT&T, let alone to the world. Neither did we want the support burden that would have carried--the group's charter was research, after all, not software support. So the 9th and 10th editions existed as manuals, but not as releases. We did occasionally make one-off snapshots for other parts of AT&T, and maybe for a university or two. (I definitely remember taking a snapshot to help the official AT&T System N Unix people set up a Research system at one point, and have a vague memory that I may have carried a tape to a university under a special one-off license letter.) On the other hand, troff wasn't a rapid moving target, and unlike the stars of the modern software world, we tried not to break things unless there was a real reason to do so. So I suspect the troff from any system of that era would render the Volume 2 papers properly, and am all but certain the 10th-edition-era troff would do so even for older manuals. C. Just to be clear, the official 10th Edition manuals published by Saunders College Publishing were made from camera-ready copy prepared by us in 1127 (Doug McIlroy did all the final work, I think) and printed on our phototypesetter. We didn't ship them troff source, nor even Postscript. We did everything including the tables of contents and indexes and page numbering. D. troff is indeed not TeX, and some of us think of that as a feature, not a bug. I think the odds are fairly good (but not 100%) that groff would do a reasonable job of rendering the papers; as I said, the hard part is the macro packages. I'm not sure -mpm ever made it out of Research. And there are probably copyright issues not just with the software but with the papers themselves. The published manuals bear a copyright notice, after all. Norman Wilson Toronto ON (A much nicer place than suburban NJ, which is why I left the Labs when I did)

4 months, 3 weeks

6
7
0 0

Re: The Case of UNIX vs. The UNIX System

by Douglas McIlroy

Although I edited the v7 through v10 manuals, I have no recollection of why "system" crept into the title between v7 and v8. Resistance to trademark edicts did grow. In v10, the cover and the man pages proclaimed "Unix". However, the fossilized spelling, "UNIX", still appeared in the introduction to Volume 1 and scattered throughout Volume 2. Doug

4 months, 3 weeks

4
3
0 0

The Case of UNIX vs. The UNIX System

by segaloco

So in most technical circles and indeed in the research communities surrounding UNIX, the name of the system was just that, UNIX, prefixed often with some descriptor of which stream, be it Research, USG, BSD/Berkeley, but in any case the name UNIX itself was descriptive of the operating system for many of its acolytes and disciples. However, in AT&T literature and media, addition of "System" to the end of the formal name seemed to become de facto if not de jure. This can be seen for instance in manual edits in the early 80s with references to just "UNIX" being replaced with variations on "The UNIX System", sometimes haphazardly as if done via a search and replace with little review. This too is evident in some informative films published by AT&T, available on YouTube today as "The UNIX Operating System" and "UNIX: Making Computers Easier to Use"[1][2]. Discrepancies in the titles of the videos notwithstanding, throughout it seems there are several instances where audio of an interviewee saying "The UNIX System" were edited over what I presume were instances of them simply saying UNIX. I'm curious if anyone has the scoop on whether this was an attempt to echo the "One Bell System" and related terminology, marketing tag lines like "The System is the Solution", and/or the naming of the revisions themselves as "System <xyz>". On the other hand, could it have simply been for clarity, with the uninitiated not being able to glean from the product name anything about it, making the case for adding "System" in formal descriptions to give them a little bit of a hint. Bell Labs folks especially, was there ever some grand thou shalt call it "The UNIX System" in all PR directive or was it just something that organically happened over time as bureaucratic powers at be got their hands on a part of the steering wheel? - Matt G. [1] - https://www.youtube.com/watch?v=tc4ROCJYbm0 [2] - https://www.youtube.com/watch?v=XvDZLjaCJuw

4 months, 3 weeks

8
10
0 0

Re: Unix V10 Volume 2 PDFs

by Douglas McIlroy

> My understanding is that Unix V8-V10 were not full distributions but patches. "Patch" connotes individually distributed small fixes, not complete working systems. I don't believe Brendan meant that v8 was only a patch on v7, but that's the natural interpretation of the statement. V8-v10 were snapshots, yes, possibly not perfectly in sync with the printed editions. But this was typical of Research editions, and especially of Volujme 2, which was originally called something like "Documents for Use with Unix". Doug

4 months, 3 weeks

1
0
0 0

Re: Unix V10 Volume 2 PDFs

by G. Branden Robinson

[looping in TUHS so my historical mistakes can be corrected] Hi Alex, At 2025-02-13T00:59:33+0100, Alejandro Colomar wrote: > Just wondering... why not build a new PDF from source, instead of > scanning the book? A. I don't think we know for sure which version of troff was used to format the V10 manual. _Probably_ Kernighan's research version, which was similar to a contemporaneous DWB troff...but what "contemporaneous" means in the 1989-1990 period is a little fuzzy. Also, Kernighan may not have a complete source history of his version of troff, it is presumably still encumbered by AT&T copyrights, and he's been using groff for at least his last two books (his Unix memoir and the 2nd edition of the AWK book). B. It is hard to recreate a Research Unix V10 installation. My understanding is that Unix V8-V10 were not full distributions but patches. And because troff was commercial/proprietary software at that (the aforementioned DWB troff), I don't know if Kernighan's "Research troff" escaped Bell Labs or how consistently it could be expected to be present on a system. Presumably any of a variety of DWB releases would have "worked fine". How much they would have varied in extremely fiddly details of typesetting is an open question. I can say with some confidence that the mm package saw fairly significant development. Of troff itself (and the preprocessors one bumps into in the Volume 2 white papers) I'm much more in the dark. C. Getting a scan out there tells us at least what one software configuration deemed acceptable by producers of the book generated, even if it's impossible to identify details of that software configuration. That in turn helps us to judge the results of _known_ software configurations--groff, and other troffs too. D. troff is not TeX. Nothing like trip.tex has ever existed. A golden platonic ideal of formatter behavior does not exist except in the collective, sometimes contentious minds of its users. > Doesn't groff(1) handle the Unix sources? Assuming the full source of a document is available, and no part of its toolchain requires software that is unavailable (like Van Wyk's "ideal" preprocessor) then if groff cannot satisfactorily render a document produced by the Bell Labs CSRC, then I'd consider that presumptively a bug in groff. It's a rebuttable presumption--if one document in one place relied upon a _bug_ in AT&T troff to produce correct rendering, I think my inclination would be to annotate the problem somewhere in groff's documentation and leave it unresolved. For a case where groff formats a classic Unix document "better" (in the sense of not unintentionally omitting a formatted equation) than AT&T troff, see the following. https://github.com/g-branden-robinson/retypesetting-mathematics > I expect the answer is not licenses (because I expect redistributing > the scanned original will be as bad as generating an apocryphal PDF in > terms of licensing). I've opined before that the various aspects of Unix "IP" ownership appear to be so complicated and mired in the details of decades-old contracts in firms that have changed ownership structures multiple times, that legally valid answers to questions like this may not exist. Not until a firm that thinks it holds the rights decides it's worth the money to pay a bunch of archivists and copyright attorneys to go on a snipe hunt. And that decision won't be made unless said firm thinks the probability is high that they can recover damages from infringers in excess of their costs. Otherwise the decision simply sets fire to a pile of money. ...which isn't impossible. Billionaires do it every day. > I sometimes wondered if I should run the Linux man-pages build system > on the sources of Unix manual pages to generate an apocryphal PDF book > of Volume 1 of the different Unix systems. I never ended up doing so > for fear of AT&T lawyers (or whoever owns the rights to their manuals > today), but I find it would be useful. It's the kind of thing I've thought about doing. :) If you do, I very much want to know if groff appears to misbehave. Regards, Branden

4 months, 3 weeks

2
1
0 0

Re: In some cults...

by norman＠oclsc.org

Dave Horsfall: Silent, like the "p" in swimming? :-) === Not at all the same. Unix smelled much better than its competitors in the 1970s and 1980s. Norman Wilson Toronto ON

4 months, 3 weeks

2
1
0 0

Re: In some cults...

by norman＠oclsc.org

John P. Linderman (not the JPL in Altadena): On a faux-cultural note, Arthur C Clark wrote the "Nine Billion Names of God" in the 50s. === Ken wishes he'd spelled it Clarke, as the author did. Norman Wilson Toronto ON

4 months, 3 weeks

7
6
0 0

In some cults...

by Dave Horsfall

... it is possible to kill a person if you know his true name. I'm trying to find the origin of that phrase (which I've likely mangled); V5 or thereabouts? -- Dave

4 months, 3 weeks

8
10
0 0

What looks like a nice article on Unix spell

by Aharon Robbins

https://blog.codingconfessions.com/p/how-unix-spell-ran-in-64kb-ram I haven't finished reading it yet. Arnold

5 months, 2 weeks

1
0
0 0

Re: Perkin-Elmer Sort/Merge II vs Unix sort(1)

by Douglas McIlroy

All-in-one vs pipelined sorts brought to mind NSA's undeservedly obscure dataflow language, POGOL, https://doi.org/10.1145/512927.512948 (POPL 1973). In POGOL one wrote programs as collections of routines that communicated via named files, which the compiler did its best to optimize away. Often this amounted to loop jamming or to the distributive law for map over function composition. POGOL could, however, handle general dataflow programming including feedback loops. One can imagine a program for pulling the POGOL trick on a shell pipeline. That could accomplish--at negligible cost--the conversion of a cheap demo into a genuine candidate for intensive production use. This consideration spurs another thought. Despite Unix's claim to build tools to make tools, only a relativelly narrow scope of higher-order tools that take programs as dara ever arose. After the bootstrapping B, there were a number of compilers, most notably C, plus f77, bc, ratfor, and struct. A slight variant on the idea of compiling was the suite of troff preprocessors. The shell also manipulates programs by composing them into larger programs. Aside from such examples, only one other category of higher-order Unix program comes to mind: Peter Weinberger's lcomp for instrumenting C programs with instruction counts. An offshoot of Unix were Gerard Holzmann's tools for extracting model-checker models from C programs. These saw use at Indian Hill and most notably at JPL, but never appeared among mainstream Unix offerings. Similar tools exist in-house at Microsoft and elsewhere. But generally speaking we have vey few kinds of programs that manipulate programs. What are the prospects for computer science advancing to a stage where higher-level programs become commonplace? What might be in one's standard vocabulary of functions that operate on programs? Doug

5 months, 2 weeks

1
0
0 0

Perkin-Elmer Sort/Merge II vs Unix sort(1)

by Diomidis Spinellis

I chanced upon a brochure describing the Perkin-Elmer Series 3200 / (previously Interdata, later Concurrent Computer Corporation) Sort/Merge II utility [1]. It is instructive to compare its design against that of the contemporary Unix sort(1) program [2]. - Sort/Merge II appears to be marketed as a separate product (P/N S90-408), whereas sort(1) was/is an integral part of the Unix used throughout the system. - Sort/Merge II provides interactive and batch command input modes; sort(1) relies on the shell to support both usages. - Sort/Merge II appears to be able to also sort binary files; sort(1) can only handle text. - Sort/Merge II can recover from run-time errors by interactively prompting for user corrections and additional files. In Unix this is delegated to shell scripts. - Sort/Merge II has built-in support for tape handling and blocking; sort(1) relies on pipes from/to dd(1) for this. - Sort/Merge II supports user-coded decision subroutines written in FORTRAN, COBOL, or CAL. Sort(1) doesn't have such support to this day. One could construct a synthetic key with awk(1) if needed. - Sort/Merge II can automatically "allocate" its temporary file. For sort(1) file allocation is handled by the Unix kernel. To me this list is a real-life demonstration of the differences between the, prevalent at the time, thoughtless agglomeration of features into a monolith approach against Unix's careful separation of concerns and modularization via small tools. The same contrast appears in a more contrived setting in J. Bentley's CACM Programming Pearl's column where Doug McIlroy critiques a unique word counting literate program written by Don Knuth [3]. (I slightly suspect that the initial program specification was a trap set up for Knuth.) I also think that the design of Perkin-Elmer's Sort/Merge II shows the influence of salespeople forcing developers to tack-on whatever features were required by important customers. Maybe the clean design of Unix owes a lot to AT&T's operation under the 1956 consent decree that prevented it from entering the computer market. This may have shielded the system's design from unhealthy market pressures during its critical gestation years. [1] https://bitsavers.computerhistory.org/pdf/interdata/32bit/brochures/Sort_Me… [2] https://s3.amazonaws.com/plan9-bell-labs/7thEdMan/v7vol1.pdf#page=166 [3] https://doi.org/10.1145/5948.315654 Diomidis - https://www.spinellis.gr

5 months, 2 weeks

10
13
0 0

Re: Perkin-Elmer Sort/Merge II vs Unix sort(1)

by Douglas McIlroy

> To me this list is a real-life demonstration of the differences between > the, prevalent at the time, thoughtless agglomeration of features into a > monolith approach against Unix's careful separation of concerns and > modularization via small tools. The same contrast appears in a more > contrived setting in J. Bentley's CACM Programming Pearl's column where > Doug McIlroy critiques a unique word counting literate program written > by Don Knuth [3]. (I slightly suspect that the initial program > specification was a trap set up for Knuth.) It wasn't a setup. Although Jon's introduction seems to imply that he had invited both Don and me to participate, I actually was moved to write the critique when I proofread the 2-author column, as I did for many of Jon's Programming Pearls. That led to the 3-author arrangement. Knuth and I are still friends; he even reprinted the critique. It is also memorably depicted at https://comic.browserling.com/tag/douglas-mcilroy. Doug

5 months, 3 weeks

2
1
0 0

Robert Morris's UUCP

by Douglas McIlroy

> I often repeat a throwaway sentence that UUCP was Lesk, > building a bug fix distribution mechanism. > Am I completely wrong? I am sure Mike said this to me mid 80s. That was an important motivating factor, but Mike also had an unerring anticipatory sense of public "need". Thus his programs spread like wildfire despite their bugs. UUCP itself is the premier example. Its popularity impelled its inclusion in v7 despite its woeful disregard for security. > Does anyone have [Robert Morris's UUCP CSTR]? Doug? Not I. Doug

5 months, 3 weeks

5
4
0 0

Robert Morris's UUCP

by arnold＠skeeve.com

The Reeds paper mentions that Robert Morris rewrote UUCP. Did that ever see the light of day anywhere? V9? V10? Just wondering. Arnold

5 months, 3 weeks

4
8
0 0

Re: Robert Morris's UUCP

by norman＠oclsc.org

Robert's uucp was in use in the Research world when I arrived in late summer of 1984. It had an interesting and sensible structure; in particular uucico was split into two programs, ci and co. One of the first things I was asked to do when I got there was to get Honey Danber working as a replacement. I don't remember why that was preferred; possibly just because Robert was a summer student, not a full-fledged member of the lab, and we didn't want something as important to us as uucp to rely on orphaned code. Honey Danber was in place by the time we made the V8 tape, toward the end of 1984. Norman Wilson Toronto ON

5 months, 3 weeks

2
1
0 0

"/bin/sh: the biggest Unix security loophole"

by Douglas McIlroy

I have sent a scan of Jim Reeds's 1984 technical memorandum on Bourne-shell security risks to Warren Toomey for posting in the TUHS archives. Doug

5 months, 3 weeks

4
3
0 0

Bell-Era UNIX Audio/DSP Interfaces?

by segaloco

The sound situation in the UNIX world to me has always felt particularly fragmentary, with OSS offering some glimmer of hope but faltering under the long shadow of ALSA, with a hodge podge of PCM and other low level interfaces littered about other offerings. Given AT&T's involvement with the development of just about everything "sound over wires" for decades by the time UNIX comes along, one would suspect AT&T would be quite invested in standardizing interfaces for computers interacting with audio signals on copper wire. Indeed much of the ESS R&D was taking in analog telephone signals, digitizing them, and then acting on those digitized results before converting back to analog to send to the other end. Where this has me curious is if there were any efforts in Bell Labs, prior to other industry players having their hands on the steering wheel, to establish an abstract UNIX interface pattern for interacting with streams of converted audio signal. Of course modern formats didn't exist, but the general idea of PCM was well established, concepts like sampling rates, bit depths, etc. could be used in calculations to interpret and manipulate digitized audio streams. Any recollections? Was the landscape of signal processing solutions just so particular that trying to create a centralized interface didn't make sense at the time? Or was it a simple matter of priorities, with things like language development and system design taking center stage, leaving a dearth of resources to direct towards these sorts of matters? Was there ever a chance of seeing, say, the 5ESS handling of PCM, extended out to non-switching applications, or was that stuff firmly siloed over in the switching groups, having no influence on signal processing outside? - Matt G.

5 months, 3 weeks

3
3
0 0

How can I see what is in the tape image?

by Jackson Helie G

5 months, 3 weeks

1
0
0 0

A Retrospective on the Source Code Control System

by Marc Rochkind

I mentioned a few weeks ago that I was writing this invited paper for an upcoming 50-year anniversary of the first issue of IEEE Transactions on Software Engineering. The paper has now been accepted for publication and here's a preprint version of it: https://www.mrochkind.com/mrochkind/docs/SCCSretro2.pdf Marc

6 months

5
6
0 0

Re: Bell-Era UNIX Audio/DSP Interfaces?

by Douglas McIlroy

> Was the landscape of signal processing solutions just so > particular that trying to create a centralized interface didn't make sense at > the time? Or was it a simple matter of priorities, with things like language > development and system design taking center stage, leaving a dearth of resources > to direct towards these sorts of matters? Was there ever a chance of seeing, > say, the 5ESS handling of PCM, extended out to non-switching applications, In the early days of Unix there were intimate ties between CS Research and Visual and Acoustic Research. V&A were Bell Labs' pioneer minicomputer users because they needed interactive access to graphics and audio, which would have been prohibitively expensive on the Labs' pre-timesharing mainframes. Also they generally had EE backgrounds, so were comfortable working hands-on with hardware, whereas CS had been largely spun off from the math department. Ed David, who led Bell Labs into Multics, without which Unix might not have happened, had transferred from V&A to CS. So had Vic Vyssotsky and Elliot Pinson (Dennis's department head and coauthor with me of the introduction to the 1978 BSTJ Unix issue). John Kelly, a brilliant transferee who died all too young pre-Unix, had collaborated with Vic on BLODI, the first dataflow language, which took digital signal processing off breadboards and into computers. One central member of the Unix lab, Lee McMahon, never left V&A. The PDP-7 of Unix v0 was a hand-me-down from Pinson's time in V&A. And the PDP-11 of v1 was supported by a year-end fund surplus from there. People came from V&A to CS because their interests had drifted from signal processing to computing per se. With hindsight, one can see that CS recruiting--even when it drew on engineering or physics talent--concentrated on similarly motivated people. There was dabbling in acoustics, such as my "speak" text-to-speech program. And there were workers dedicated to a few specialties, such as Henry Baird in optical character recognition. But unlike text processing, say, these fields never reached a critical mass of support that might have stimulated a wider array of I/O drivers or full toolkits to use them. Meanwhile, in V&A Research linguists adopted Unix, but most others continued to roll their own one-off platforms. It's interesting to speculate whether the lack of audio interfaces in Unix was a cause or a result of this do-it-yourself impulse. Doug

6 months

6
5
0 0

Re: Bell-Era UNIX Audio/DSP Interfaces?

by Serissa

In the lost-in-time department, my group at Digital Cambridge Research lab in 1993 did an audio interface patterned after the X Window system. Paper in the Summer USENIX: https://www.usenix.org/legacy/publications/library/proceedings/cinci93/gett… For extra fun, the lab director of CRL at the time was Vic Vyssotsky. But there must have been some Bell work, because around 1983 (?) when I was doing Etherphone at PARC I visited John DeTreville at Holmdel. He was building a voice - over - Ethernet system as well. -Larry > On Jan 6, 2025, at 4:51 PM, Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote: > segaloco via TUHS wrote in > <BWYwXjScYdFHM1NV0KEtgvazEfJM1PX7WaZ8lygZ45Bw2pEQG6JQr5OCtX-KMwEwr_k2zLD\ > GXac7wymRCtifnU9VKnlsrJCrKFqGZSgM6-0=(a)protonmail.com>: > |The sound situation in the UNIX world to me has always felt particularly > |fragmentary, with OSS offering some glimmer of hope but faltering under \ > |the long > |shadow of ALSA, with a hodge podge of PCM and other low level interfaces > |littered about other offerings. > > Oh, but *how* great it was when FreeBSD came on over with those > "virtual sound devices", in 4.7 or 4.9 i think it was. Ie instead > of one blocking device, one could open dev.1 and dev.2 and it was > multiplexed in the kernel. It did some format conversion in the > kernel alongside this. > > It was *fantastic*!, and i had a recording program sitting on > a Cyrix 166+ and it took me ~1.5 percent of (single) CPU to record > our then still great Hessenradio HR3 for long hours (Clubnight > with worldwide known DJs, Chill with great sets in the Sunday > mornings), and oh yes HR2 with the wonderful Mr. Paul Bartholomäi > in "Notenschlüssel" (classical music), and the fantastic "Voyager" > hour with Robert Lug on Sunday evening. It cannot be any better. > I could code and compile and there was no stuttering alongside. > 1.5 percent of CPU, honestly! > > I say this because FreeBSD has replaced that very code last year, > if i recall correctly. It now all scales dynmically, if i read > the patches that flew by right. (So it may be even better as of > now, but by then, over twenty years ago, it blew my mind. And the > solution was so simple, you know. The number of concurrent > devices was a compile time constant if i recall correctly, four by > default.) > > I also say this because today i am lucky i can use ALSA on Linux, > and apulse for the firefox i have to use (and do use, too > .. i also browse the internet in such a monster, and at least in > parts still like that). I always hated those server solutions, > where those masses of audio data flow through several context > switches. What for? I never understood. Someone convinced me to > try that pulseaudio server, but i think it was about 20 percent of > CPU for a simple stream, with a terrible GUI, and that on > a i5-8250U CPU @ 1.60GHz with up to 3.4 Ghz (four core; the four > HT are alwys disabled). 20 percent!! > > ... > |Any recollections?[.] > > Sorry, the above is totally apart, but for me the above is still > such a tremendous thing that someone did; and for free. Whoever > it was (i actually never tried to check it, now that i track their > git for so many years), *thank you*! > (And that includes the simple usual format conversions in between > those 22050/44100 etc etc. Just like that -- open a device and > read it, no thousands of callbacks, nothing. And 1.5 percent CPU. > Maybe it is not good/exact enough for studio level audio editing. > But i still have lots of those recordings, except that the "Balkan > piss box" chill somehow disappeared. (Sorry Pedja, shall you read > this.)) > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > | > |In Fall and Winter, feel "The Dropbear Bard"s pint(er). > | > |The banded bear > |without a care, > |Banged on himself for e'er and e'er > | > |Farewell, dear collar bear

6 months

1
0
0 0

userland exec -- wasn't exec that way originally?

by ron minnich

Do I remember correctly that the early linux exec as a userland exec? I think this came up before, I just can't recall. I just learned about: https://github.com/hardenedlinux/userland-exec

6 months

1
0
0 0

Was the compressed dictionary used?

by arnold＠skeeve.com

Hi. The paper on compressing the dictionary was interesting. In the day of 20 meg disks, compressing a ~ 2.5 meg file down to ~ .5 meg is a big savings. Was the compressed dictionary put into use? I could imaging that spell(1) at least would have needed some library routines to return a stream of words from it. Just wondering. Thanks, Arnold

6 months

5
8
0 0

Bergson Quote, Forward, BSTJ, 57:6 1978

by durtal

I am curious about the apposite Bergson quote (intelligence...tools) found at the beginning of the Forward mentioned in the subject. Specifically, I am wondering if the quote was originally discovered in _Creative Evolution_ as a part of a course or through private reading. I am interested in the diffusion of Continental ideas concerning technology in English speaking countries during the 20th Century. Dr Rick Hayes durtal(a)sdf.org SDF Public Access UNIX System - https://sdf.org

6 months, 1 week

1
0
0 0

Fwd: dmr DECtape Analysis, part N

by Warren Toomey

All, Yufeng Gao has done more amazing work at extracting binaries, source code and text documents from the DECtapes that Dennis Ritchie provided for the Unix Archive: https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ His latest e-mail is below. I've temporarily placed his attachments here: https://minnie.tuhs.org/wktcloud/index.php/s/aWkck2Ljay6c5sB He needs some help with formatting old *roff documents. If someone could offer him help, that would be great. His e-mail address is yufeng.gao AT uq.edu.au Cheers, Warren ----- Forwarded message from Yufeng Gao ----- Date: Tue, 31 Dec 2024 Subject: RE: UNIX DECtapes from dmr Hi Warren, Happy New Year! Here's another update. I found more UNIX bins on another tape ('ken-sky'). They appear to be between V3 and V4. I have attached them as "ken_sky_bins.tar". I have also attached an updated tarball of the V2/V3 bins recovered from the 'e-pi' tape (with a few names corrected), see "identified_v2v3_bins_r2.tar". So far, the rough timeline of UNIX binaries (RTM hereinafter refers to the exact version of the OS described by the preserved manuals) is as follows: Sys: V1 RTM <= unix-study-src < s1/s2 < V2 RTM < V3 RTM < nsys < V4 RTM Bin: V1 RTM < s1/s2 < epi-V2 < epi-V3 < ken-sky-bins < V4 RTM There is a possibility that the V2 bins from the 'e-pi' tape belong to V2 RTM, as they're all PDP-11/20 bins with V2 headers. In contrast, most of the bins from the s1/s2 tapes are V1 bins. Some of them are identical to those from the 's2' tape, and if the timestamps from the 's2' tape can be trusted, they're from May/June 1972. The V3 bins from the 'e-pi' tape are most likely from late 1972 or early 1973, but no later than Feb 1973, as they've been overwritten by files from Feb 1973. This suggests they're from a V3 beta, supported by the fact that some features described in the V3 manual are missing. The files were laid out in perfect alphabetical order on the tape. The bins from the 'ken-sky' tape fall somewhere between V3 RTM and V4 RTM. The directory structure and other elements match the V3 manual, as do the syscalls (e.g., the arguments for kill(2) differ between V3 and V4, and these bins use the V3 arguments). The features, however, are closer to V4. For example, nm(1) had already been rewritten in C and matches the V4 manual's description. The assembler also matches the V4 manual in terms of the number of temp files, and the C compiler refers to the assembler as 'nas.' The assembler is located physically between files starting with "n" and "o," and the files around it follow a weak alphabetical order, so it is logical to assume that it was named "nas". It is a bit difficult to version these binaries, especially without any timestamps. The lines between versions for early UNIX are blurry, and modern software versioning terms like "beta" and "RTM" don't really apply well. If these binaries are to be preserved (which I hope they will be, even though the kernels are long gone), I'd put the V2 bins from 'e-pi' under V2, the V3 bins from 'e-pi' under V3, and the bins from 'ken-sky' under V4 (I'd argue that nsys also falls under V4, as the biggest change between V3 and V4 was the kernel being rewritten in C). There are other overwritten files on the tapes, and I will address them later. There are quite a few patents, papers, and memos in *roff format, but I'm not entirely sure what to do with them. Among those, I have picked out some V4 distribution documents and attached them as a ZIP folder :-). If you know of ways to generate PDFs from these ancient *roff files accurately, please lend a hand - I'm struggling to get accurate results from groff. Sincerely, Yufeng ----- End forwarded message -----

6 months, 1 week

2
2
0 0

B programming language interpreter

by Jackson Helie G

I am currently looking for an interpreter for the B programming language. Can anyone provide one?

6 months, 1 week

1
0
0 0

On the uniqueness of DMR's C compiler

by Paul Ruizendaal

In the last months, I've spent a little time on curating John Walker's Unix clone and software stack, including an emulator to run it: https://gitlab.com/marinchip After creating a basic tool chain (edit, asm, link and a simple executive), John set out to find a compiler. Among the first programs were a port of the META 3 compiler-generator (similar to TMG on early Unix) and a port of Birch-Hansen’s Pascal compiler. META was used to create a compiler that generated threaded code. He found neither compiler good enough for his goals and settled on writing his Unix-like OS in assembler. As the 9900 architecture withered after 1980, this sealed the fate of this OS early on -- had he found a good compiler, the code might have competed alongside Coherent, Idris, and Minix during the 80’s. This made me realise once more how unique the Ritchie C compiler was. In my view its uniqueness combines three aspects: 1. The C language itself 2. The ability to run natively on small hardware (even an LSI-11 system) 3. Generating code with modest overhead versus handwritten assembler (say 30%) As has been observed before, working at a higher abstraction level makes it easier to work on algorithms and on refactoring, often earning back the efficiency loss. John Walkers work may be case in point: I estimate that his hand-coded kernel is 10% larger than an equivalent V6 Unix kernel (as compiled for the 9900 architecture). There are three papers on DMR’s website about the history of the compiler and a compare-and-contrast with other compilers of the era: https://www.bell-labs.com/usr/dmr/www/primevalC.html https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/hopl.html It seems to me that these papers rather understate the importance of generating good quality code. As far as I can tell, BCPL and BLISS came close, but were too large to run on a PDP-11 and only existed as cross-compilers. PL/M was a cross-compiler and generated poorer code. Pascal on small machines compiled to a virtual machine. As far as I can tell, during most of the 70s there was no other compiler that generated good quality code and ran natively on a small (i.e. PDP-11 class) machine. As far as I can tell the uniqueness was mostly in the “c1” phase of the compiler. The front-end code of the “c0” phase seems to use more or less similar techniques as many contemporary compilers. The “c1” phase seems to have been unique in that it managed to do register allocation and instruction selection with a pattern matcher and associated code tables squeezed into a small address space. On a small machine, other native compilers of the era typically proceeded to generate threaded code, code for a virtual machine or poor quality native code that evaluated expressions using stack operations rather than registers. I am not sure why DMR's approach was not more widely used in the 1970’s. The algorithms he used do not seem to be new and appear to have their roots in other (larger) compilers of the 1960’s. The basic design seems to have been in place from the very first iterations of his compiler in 1972 (see V2 tree on TUHS) and he does not mention these algorithms as being special or innovative in his later papers. Any observations / opinions on why DMR’s approach was not more widely used in the 1970’s?

6 months, 1 week

10
17
0 0

SCCS, TeamWare, BitKeeper, and Git

by Marc Rochkind

As I mentioned in another post, I'm writing an invited paper for an upcoming issue of IEEE Transactions on Software Engineering that will be a 50-year retrospective of my original 1975 SCCS paper ( mrochkind.com/aup/talks/SCCS-Slideshow.pdf) Can some people here review a couple of paragraphs for accuracy? *Decentralized Version Control (DVCS)* *While VCSs like CVS and Subversion were centralized and had pre-commit merging, a further advance was towards decentralization, with post-commit merging. Probably the first DVCS was Sun WorkShop TeamWare, created by Larry McVoy and announced in 1992 [sun]. It was implemented as a layer on top of SCCS. McVoy later commercialized a successor system called BitKeeper [Bitkeeper], which was layered on a re-implementation of SCCS, which he called BitSCCS. TeamWare and BitKeeper took advantage of the interleaved delta algorithm, also known as a weave, to implement an efficient way to represent merged deltas by reference, instead of reproducing code inside the repository. This is a lot more complicated to do with reverse deltas, introduced by RCS.* *In 2005 Linus Torvalds, creator of Linux [linux], invented the DVCS Git [git] for Linux development, and since then Git has become widely used and has supplanted BitKeeper.* [more about DVCS follows] I don't want to add more detail that would make these paragraphs any longer, but I do want them to be accurate. Thanks! Marc Rochkind -- *My new email address is mrochkind(a)gmail.com <mrochkind(a)gmail.com>*

6 months, 3 weeks

22
41
0 0

Re: SCCS roach motel

by norman＠oclsc.org

Rob Pike: According to the Unix room fortunes file, the actual quote is SCCS: the source-code motel -- your code checks in but it never checks out. Ken Thompson ==== As a Unix-room-culture aside: I believe this quote was what inspired Andrew Hume to call his backup system the File Motel. Norman Wilson Toronto ON

6 months, 3 weeks

2
1
0 0

Re: mmap, was SCCS, TeamWare, BitKeeper, and Git

by Douglas McIlroy

>> Does anyone know whether there are implementations of mmap that >> do transparent file sharing? It seems to me that should be possible by >> making the buffer cache share pages with mmapping processes. > These days they all do. The POSIX rationale says: > ... When multiple processes map the same memory object, they can > share access to the underlying data. Notice the weasel word "can". It is not guaranteed that they will do so automatically without delay. Apparently each process may have a physically distinct copy of the data, not shared access to a single location. The Linux man page mmap(2), for example, makes it very clear that mmap has a cache-coherence problem, at least in that system. The existence of msync(2) is a visible symptom of the problem. [Weasel words of my own: I have not read the POSIX definition of mmap.] Doug

6 months, 3 weeks

7
11
0 0

Re: mmap, was SCCS, TeamWare, BitKeeper, and Git

by John R Levine

On Mon, 16 Dec 2024, Konstantin Belousov wrote: > On Mon, Dec 16, 2024 at 02:08:43PM -0500, John Levine wrote: >> PS: I can believe there are some versions of linux that screwed up disk cache >> coherency, but that just means they don't properly implement the spec, not for >> the first time. I mean, it's not *that* hard to make all the maps point to the >> same physical page frame, even on a machine like POWER with reverse page maps. > > This is not enough. There are (were ?) architectures, typically with the > virtually addressed caches, which require all mappings of the same page > to be suitably aligned, at least. ... > > If addresses of different mappings are not aligned, caches were not coherent. I think we're in "so don't do that" territory. mmap() normally lets the system pick the memory address to map so it can pick something suitably aligned. You can pass the MAP_FIXED flag to tell it to map at a particular address, but it can return EINVAL if the address doesn't work. The POSIX description says "The use of MAP_FIXED is discouraged, as it may prevent an implementation from making the most effective use of resources." It's not always trivial to make this work. On systems with reverse maps, a physical page can only be mapped to one virtual address at a time, so for shared pages it has to mark all of the aliases nonresident and on a fault remap the page into the map of the process that is running. But it's not rocket science, either. R's, John

6 months, 3 weeks

1
0
0 0

Re: M<some number> macros, wasRe: SCCS

by Douglas McIlroy

> "John Levine" <johnl(a)taugh.com> wrote: >> M4 was written in the 1970s by Kernighan and Ritchie in C ... > In private mail, BWK told me that it was DMR who wrote m4. He t> hen reimplemented it in Ratfor for "Software Tools". > Arnold The book says colorfully, "... [and] we are grateful to him for letting us steal it." Doug

6 months, 3 weeks

1
0
0 0

Re: SCCS, TeamWare, BitKeeper, and Git

by Douglas McIlroy

> well after Unix had fledged, its developers at CSRC found it necessary > and/or desirable to borrow back a Multics concept: they named it mmap(). As far as I know no Research version of Unix ever had mmap. Multics had a segmented universal memory. A process incorporated segments into its address space The universal memory was normally addressed via a hierachical segment-name directory. With enhancement to provide for multisegment "files", the directory could serve as a file system and file I/O became data transfer between segments. Unix originally imitated the Multics file system, but not the universal memory. mmap(2) weakly imitates universal memory by allowing a process to nominally incorporate a portion of a file into the process address space at page-level granularity. However, an update is guaranteed to be visible to the file and other processes only upon specific request. Does anyone know whether there are implementations of mmap that do transparent file sharing? It seems to me that should be possible by making the buffer cache share pages with mmapping processes. Doug

6 months, 3 weeks

3
2
0 0

BSD talk program?

by Dan Cross

I'm curious if anyone has any history they can share about the BSD "talk" program. I was fond of this back when it was still (relatively) common, but given the way it's architected I definitely see why it fell out of use as the Internet grew. Still, does anybody know what the history behind it is? Initially, I thought it was written by Mike Karels, but that was just my speculation from SCCS spelunking, and looking at the sources from 4.2, I see RCS header strings that indicate it was written by "moore" (Peter Moore?). talk.c says, "Written by Kipp Hickman". It seems to have arrived pretty early on with respect to the introduction of TCP/IP in BSD: the README alludes to some things coming up in 4.1c. Clem, you seem to have had a hand in it, and are credited (along with Peter Moore) for making it work on 4.1a. So I guess the question is, what was the motivation? Was it just to have a more pleasing user-to-user communications experience, or was discussion across the network an explicit goal? There's a note in talk.c ("Modified to run between hosts by Peter Moore, 8/19/82") that suggests this wasn't the original intent. Who thought up the character-at-a-time display mode? Thanks for any insights. - Dan C.

6 months, 3 weeks

9
12
0 0

SCCS roach motel

by Marc Rochkind

IEEE Transactions on Software Engineering has asked me to write a retrospective on the influence of SCCS over the last 50 years, as my SCCS paper was published in 1975. They consider it one of the most influential papers from TSE's first decade. There's a funny quote from Ken Thompson that circulates from time-to-time: "SCCS, the source motel! Programs check in and never check out!" But nobody seems to know what it means exactly. As part of my research, I asked Ken what the quote meant, sunce I wanted to include it. He explained that it refers to SCCS storing binary data in its repository file, preventing UNIX text tools from operating on the file. Of course, this is only one of SCCS's many weaknesses. If you have anything funny about any of the others, post it here. I already have all the boring usual stuff (e.g., long-term locks, file-oriented, no merging). Marc Rochkind mrochkind.com

6 months, 3 weeks

8
14
0 0

BSD Talk History -- Credit Where Credit is Due

by Clem Cole

I was thinking about this some more. IIRC: Peter and I sketched out the protocol for the sockets version on a whiteboard in our office one night after a beer and pizza run. Rick Spicklemeir, Tom Quarles, and Jim Kleckner also participated in those bull sessions. I started writing the program soon after that and had it working to a point in a couple of hours. I don't remember the issues, but a couple of them were when I left for the USENIX conference later that week. When I got back Peter had finished it and put it into RCS. The key is that the coding was primarily Peter and myself, but Rick, TQ, and Jim all had contributed in some manner, too, Although the famous bug of using a vax integer, you can squarely blame me — and as I said, having worked on networking for several years before my time at UCB, I should have known better. But did not even think about it. I failed Henry's ten programming commandments and concluded that the world was a Vax. Mei culpa. ᐧ

6 months, 3 weeks

2
2
0 0

Re: SCCS roach motel

by Marc Rochkind

On Fri, Dec 13, 2024 at 10:03 AM Mark Seiden <mseiden(a)gmail.com> wrote: > (I know there is a special place in hell for those who explain a joke, > but, you asked…) > > it’s just an allusion to the Black Flag Roach Motel product (still being > produced) > which has a trademark on the phrase “Roaches Check in… But they Don’t > Check Out”. > > Yeah, I knew that much. My question to Ken was about what this was saying about SCCS. Marc

6 months, 3 weeks

3
6
0 0

Re: SCCS roach motel

by norman＠oclsc.org

This is verging on COFF material, and I won't mind if someone moves the discussion thither: Clem Cole: As a satisfied user of SCCS (and later Bitkeeper), it's still my preferred choice. ==== I have to admit SCCS is one of the many pieces of software I tried for a week or two > 40 years ago and abandoned because I couldn't stand it. I don't think I ever tried RCS, because I could see it didn't what I saw as the underlying problems. CVS likewise. Subversion was the earliest version-control system that felt usable to me. What bugged me so much? The earlier systems were focussed entirely (or for CVS, almost entirely) on individual files. There was no way to link changes that affected more than one file: -- SCCS and RCS don't (so far as I can tell) understand any relation between files at all. When I'm working on a real project of any size, there is almost always more than one file, and there are often changes that affect multiple files at once: if an interface changes, the changes to definitions and uses really all should be a single commit, logged in one go and reversible as a single coordinated operation; if I refactor code, moving it between files and perhaps adding files or removing them, likewise. It is possible to check in a bunch of files at once and reuse the log message, but I couldn't find a way to make it a true coordinated single commit; and neither SCCS nor RCS has a way I could find to record, as a structured commit, that files are added or removed from a directory or directory tree. -- CVS can track adds and deletes and can bundle changes into a single commit on the command line, but the changes are still stored individually per file. -- None of the systems even tries to track file renames, something I also do occasionally as programs and especially documentation evolves. It wasn't until I discovered Subversion that I started using version control regularly in my own work. Ironically, a few years after I began using svn for myself, I ended up working in places that had great compost heaps of RCS and CVS. This would have made sense in the 1990s, but it was in the 2010s, and continues in the 2020s. I now use hg for my personal work, and have been attempting to drag my workplace into using git if only so new hires don't have to learn clumsy outdated stuff just to do their jobs. I expect to retire (not for this reason) before I really succeed, though. Norman Wilson Toronto ON

6 months, 3 weeks

3
3
0 0

[rick@rbsmith.com: Re: SCCS roach motel]

by Larry McVoy

----- Forwarded message from Rick Smith <rick(a)rbsmith.com> ----- Date: Fri, 13 Dec 2024 18:22:29 -0500 From: Rick Smith <rick(a)rbsmith.com> To: Larry McVoy <lm(a)mcvoy.com> Subject: Re: [TUHS] SCCS roach motel X-Mailer: Apple Mail (2.3826.300.87.4.3) Hi Larry, I likely can???t post to TUHS without joining, though I can read it fine. Anyway, feel free to edit and post: Marc, I remember in 1992 driving to the UCSD library to get that issue of TSE and make make copy of the article. I still have it and wrote about it on HN [1]. The link I posted at the end there is dead (wayback [2]). It is a post by J??rg Schilling about your post here on TUHS about SCCS. Yes, we could get lost in the weeds about choice of control-A, lack of merge bookkeeping and the corner cases with -i and -x when applying strict order to a partial order when computing the graph-to-set but in the big picture, the SCCS system is a huge contribution. Congratulations on writing one of the most influential papers in TSE's first decade! Certainly is that for me. Aside, Larry wrote: > ... He [Rick] did point out that my weave implementation was the only > one written such that I could have N serial sets in my hand, and do one > pass through the weave and get N different checked out files. I don't > think we ever used that but if we did it would be in smerge.c. The original makepatch() uses it in sccs_getdiffs() which walks the weave calling changestate() once to track weave structure and printstate() twice, generating a diff in one pass. While this is a hats off to Marc, there is also a hats off to Larry for extending the SCCS work with TeamWare and Bitkeeper. I studied SCCS (and other engines). Larry built systems. [1] https://news.ycombinator.com/item?id=26225001 [2] https://web.archive.org/web/20190403213137/http://sccs.sourceforge.net/sccs… ----- End forwarded message ----- -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat

6 months, 3 weeks

1
0
0 0

Interesting post about Microsoft and UNIX

by Marc Rochkind

I just came across a 1995 post from Gordon Letwin, early Microsoft employee and lead architect of OS/2, about the history of OS/2. There are a few paragraphs in it about Microsoft and UNIX. Here's Letwin's post: https://gunkies.org/wiki/Gordon_Letwin_OS/2_usenet_post And the UNIX-related paragraphs: *It's extremely hard to do development work on an operating system when someone else controls the standard. "Control" in this case is a matter of public perception. For example, Microsoft was once very big in the Unix world. In fact, we considered it our candidate for the future desktop operating system, when machines got powerful enough to run something good. We were the worlds biggest seller of Unix systems. DOS was, when we first wrote it, a one-time throw-away product intended to keep IBM happy so that they'd buy our languages.The UNIX contracts were all done when Bell Labs was regulated and couldn't sell Unix into the commerical marketplace. So although they wrote it and were paid royalties, they couldn't develop it in competition to us. But after a few years that changed. Bell was degregulated and now they were selling Unix directly, in competition to us! They might sell it for cheaper than we had to pay them in royalties! But that wasn't the real killer, the real killer was the Bell now controlled the standard. If we wrote an API extension that did X, and Bell wrote an incompatible one that did Y, which one would people write for? The ISVs know that AT&T was a very big company and that they'd written the original, so they'd believe that AT&T controlled the standard, not MS, and that belief would then define reality. So we'd always just be waiting for what AT&T announced and then frantically trying to duplicate it.Bill Gates knew, right away, that there was no strong future in Unix for us any more. Fortunately at that time, DOS was taking off and we were learning, along with everyone else, about the power of standards. So the primary OS team - the Unix guys - joined with the secondary OS team - the DOS guys - and the earliest versions of OS/2 were born. (This was before IBM came on board, so it wasn't called OS/2!)* Marc Rochkind

6 months, 4 weeks

13
25
0 0

A re-analysis of some DECtapes from dmr

by Warren Toomey

All, I received this detailed e-mail from Yufeng Gao who has done a great job at analysing some of the DECtapes that Dennis made available to the Unix Archive. I'm sure many of you would be interested and, possibly, could provide some feedback on his work. A tarball of his efforts are here: https://mega.nz/file/1cJFTJxT#BgszYuFc_ebSMaQXAIG5b2NtaGInPWMoaxExPM5Lr9Y Cheers, Warren P.S. I have a follow-up e-mail coming ... ----- Forwarded message from Yufeng Gao ----- Subject: UNIX DECtapes from Ritchie Hi Warren, I am writing you this email after seeing the DECtapes from Dennis Ritchie that you put up last year. I found them while playing around with the early C compilers on Ritchie's site. After some research into the tapes, I have written a parser to parse them and convert them into tarballs suitable for preservation. Most importantly, the 'dmr' tape and 's1' tape are currently not decoded properly. The biggest issue with the current decoding of the 's1' tape is, well, there is none. After quickly glancing over the tape, I have concluded that it is in fact not one of the middle tapes of an rkd(1) backup, but a copy of UNIX INIT DECtape from a version of UNIX between V1 and V2. I have extracted its contents: Mode UID GID Size Date Name ---------- --- --- ----- ------------------- ------------ -rw-rw-rw- 0 0 512 1970-01-01 00:00:00 [vcboot] -rw-rw-rw- 0 0 2048 1970-01-01 00:00:00 [bos] -rw-rw-rw- 0 0 12288 1970-01-01 00:00:00 [wunix] -rw-rw-rw- 0 0 12288 1970-01-01 00:00:00 [cunix] -rw-rw-rw- 0 0 3072 1970-01-01 00:00:00 [unassigned] -rwxr-xr-x 1 0 424 1970-01-01 00:00:00 /etc/init -rwxrwxrwx 3 0 446 1970-01-01 00:00:00 /etc/getty -rwxr-xr-x 3 0 82 1970-01-01 00:00:00 /bin/chmod -rwsr-xr-x 0 0 794 1970-01-01 00:00:00 /bin/date -rwsr-xr-x 0 0 1290 1970-01-01 00:00:00 /bin/login -rwsr-xr-x 0 0 232 1970-01-01 00:00:00 /bin/mkdir -rwxr-xr-x 1 0 954 1970-01-01 00:00:00 /bin/sh -rwsr-xr-x 0 0 3678 1970-01-01 00:00:00 /bin/tap -rwxr-xr-x 3 0 2010 1970-01-01 00:00:00 /bin/ls 578 blocks, 98 (16.96%) used, 480 (83.04%) free. B = boot; D = directroy; . = free; X = file data; O = bos; W = wunix; C = cunix; S = rf slack; U = unassigned program; |0123456789ABCDEF --+---------------- 00|BOOOOWWWWWWWWWWW 01|WWWWWWWWWWWWWCCC 02|CCCCCCCCCCCCCCCC 03|CCCCCUUUUUUSSSSS 04|SDXDXDXDXXDXXXDX 05|DXXDXXXXXXXXDXXX 06|XD.............. 07|................ <...> What is significant here is it contains the vcboot and bos programs mentioned in bproc(7), as well as a Warm and a Cold UNIX kernel. This version of UNIX appears to be between V1 and V2, which I believe is the earliest to exist in binary form. The reason why I say it's between V1 and V2 is its bos program accepts the following console switches compared to V1 and V2: | UNIX V1 | s1 | UNIX V2 ----------------------+----------+-------+--------- Warm boot | [1]73700 | ??? | ??? Cold boot | 1 | 1 | 1 Unassigned 3K prog | 2 | 2 | Dump core & halt | 10 | 10 | 10 Boot from RK | | 20 | 20 Dump core & warm boot | | 40 | 40 Boot from paper tape | 0 | 0 | 0 Load DEC loaders | 57500 | 57500 | 77500 ----------------------+----------+-------+--------- UNIX load address | 400 | 400 | 600 ----------------------+----------+-------+--------- The boot-from-unassigned-3K-program option was probably in the process of being depreciated, as the 3K of space is also loaded as a part of the Cold UNIX despite it not being used by the Cold UNIX kernel. The list of files on the 's1' tape also appear to be between V1 and V2: | V1 | s1 | V2 -----------+-----+-----+----- /etc/init | Yes | Yes | Yes /etc/getty | No | Yes | Y/N /bin/chmod | Yes | Yes | Yes /bin/chown | Yes | No | No /bin/date | No | Yes | Yes /bin/login | No | Yes | Yes /bin/cp | Yes | No | No /bin/ln | Yes | No | No /bin/ls | Yes | Yes | Yes /bin/mkdir | Yes | Yes | Yes /bin/mv | Yes | No | No /bin/rm | Yes | No | No /bin/rmdir | Yes | No | No /etc/mount | No | No | Yes /bin/sh | Yes | Yes | Yes /bin/stat | Yes | No | No /bin/tap | Yes | Yes | Yes -----------+-----+-----+----- Given that the files on this tape are identical to the same files on the 's2' tape and that the files on the 's2' tape are also sort of between V1 and V2, and that this tape is named 's1' while the other is named 's2', they are probably from the same version of UNIX. I have tried booting the 's1' tape using SIMH, but unfortunately it did not work and I have not yet attempted to debug it. Next I'm going to talk about the 'dmr' tape. It’s interesting, most of it was written by tap(1) running under UNIX V1-V2, but files in the ./paper directory were written by tap(1) running under UNIX V4. When decoded using the tap(1) program itself, the timestamps and access modes of those files are garbled. My program corrected the timestamps and access modes in the converted tar(1) archive. The same goes for the 'nsys' tape. The tar(1) conversion of 's2' (/Archive/Distributions/Research/1972_stuff/s2-bits.tar.gz) in the TUHS archives is missing some files in the /etc directory - compare it with mine and Ritchie's (Ritchie's has wrong timestamps and access modes, however). Speaking of timestamps and the 's2' tape, the timestamps outputted by tap(1) are inaccurate because 1972 is a leap year and the ctime(3) function hard coded 28 for the number of days in February. I have attached an archive of my tar(1) conversion of each tape, as well as tarballs containing all the slack space data and unused blocks which I dumped for data recovery and forensic analysis purposes. There are some interesting bits and pieces in the unused blocks of various tapes, but I have not had time to look into them in detail. Just a very quick summary: * The 'config' tape has leftover of a dictionary file. * The 'dmr' tape has some assembler manual ?roff leftover. * The 'dmr2' tape has some paper ?roff leftover. * The 'e-pi' tape has a lot of interesting binary stuff, including bits and pieces of a B compiler from what I can tell. * The 'ken' tape has some C source fragments and Thompson’s mail templates and some UNIX manual ?roff leftover. * The 'ken-du' tape has some paper ?roff leftover. * The 'ken-sky' tape has some binary leftover. * The 'nsys' tape has some source code leftover of what seems to be the kernel. * The 's1' tape has some source code leftover of what seems to be userland programs. * The 'scratch' tape has some binary and source listing and ?roff leftover. * The 'unix' tape has some binary leftover. I hope that these newly extracted stuff could be put up in the TUHS archives :). If the attachment in this email somehow doesn't come through, I have also uploaded the archive [1]here. I have a disassembly of vcboot and bos from 's1', they may help with the UNIX V1 reconstruction project - let me know if you need them. If you can get the 's1' kernel to boot, I'd like to also receive an update. Sincerely, Yufeng Gao ----- End forwarded message -----

7 months

2
3
0 0

Re: A re-analysis of some DECtapes from dmr

by jnc＠mercury.lcs.mit.edu

> From: Yufeng Gao > This version of UNIX appears to be between V1 and V2 It's too bad it's not 'between V2 and V3', since the UNIX kernels V2 and V3 are missing. (V4 is the earlist one that we have, after the V2 and onward gap.) So, depending on how far from V1 (which we have) it is, it _might_ be worth dis-assenbling. It would be particularly worth having it if it suppports the KS11, since almost no documentation of that has survived; code that uses it would allow re-creation of a programming manual for it. > From: Lars Brinkhoff > Is the kernel for a PDP-11/20 or /45? I don't think it can be the /45; as of V2, the /45 was apparently expected in the near future, and this was before the V2. Noel

7 months

1
0
0 0

After 50 years, what has the Impact of Unix been?

by sjenkin＠canb.auug.org.au

I was looking at the question of “impact of Unix" and thought that: initiating (Portable) Open Source Software including the BSD TCP/IP & Berkeley sockets libraries, the Unix -> Minix -> Linux -> Android sequence and BSD -> NeXtstep -> OS/X -> iOS sequence, plus running the Top 500 supercomputers and most of the Top 500 websites, including the infrastructure for trillion dollars companies, Facebook, Amazon (Netflix uses them), and Google plus so many embedded Linux / NetBSD based appliances even going into space - on small experiments or driving SpaceX’s Falcon 9 & presumably Starship, would be a slam-dunk for “really high impact” - dominating everywhere important, except Windows desktops. Unix wasn’t just a ’research project’, it was the result of years of work by a team of very capable, professional programmers, who weren’t looking for kudos or recognition, nor trying to add every conceivable ‘feature’ possible, but the inverse: how _small_ could it be and still be enough. When it left the Labs, Unix wasn’t just “Performant”, it came with a very useful set of tools for creating other tools (‘developing’) and while the kernel wasn’t perfect (some ‘panic’s), it was of “Production Quality”. For v6, I believe there were patches for 50-100 bugs circulating, perhaps the first demonstration of “no bug is intractable with ‘many eyeballs’”. All that in under 5 years of ‘development’, with the “initial release” stable & performant enough for cash-strapped Universities to gamble their reputations & budgets on running it. Imagine the grief academics would’ve got if their basic teaching systems failed continuously! This adoption path pushed Unix through another barrier: ’Security’ - with a lot of bright, bored & curious students banging on it as hard as they could for bragging rights. How long, in releases or years, did it take for other O/S’s to hit the “very stable” benchmark? I don’t know enough of Linux to answer that definitively, the *BSD’s grew there through usage and contribution, while Microsoft NT derivates widely suffered “Blue Screen of Death” for years. Even now, MS-Windows has serious Security / compromise issues, like the highly visible, global “Crowdstrike” event. Not a break-in or takeover, but an own-goal from Security perimeter control. ========== I now think Unix has had a much larger, direct and important impact - the C language and associated tools & libraries that begat modern toolchains and endless portability across platforms. In 1991, Bill Plauger had a year sabbatical at UNSW in Sydney, and happened to say : “C is wallpaper - people expect it everywhere”. C gained formal recognition with the POSIX standard, satisfying conservative users / enterprises that it wasn’t the work of a bunch of Hippies or ill-disciplined Hackers. Even Microsoft wrote 32-bit Windows NT in C, I presume starting by writing it’s own compiler and toolchain to start. Borland, Watcom and many others - including Microsoft - offered (Visual) C compile & build environments for Windows, directly responsible for creating the ’shrink-wrap’ third party software market that drove sales of Windows and x86 machines. Nobody had seen a market for a billion systems before, nor sold 300M+ CPU’s in a single year. People don’t buy Silicon Chips or nice Boxes, they buy Applications that solve their problems: Software drives Sales of Hardware - something that IBM deeply understood first with first the 1401 line, then 360-series. The other ’small’ achievement of C and Unix was creating the market for RISC chips. MIPS in the mid-1980’s was only able to design and build the first commercial RISC chip because it knew it could port Unix to it and find an immediate market - not at zero-cost, but a tiny fraction of what every other Vendor had done before reinventing the wheel from scratch to provide incompatible O/S & tools for their hardware. Unix on MIPS not only came with a host of proven software, that a large pool of people knew how to use, but it arrived as “Production Quality” - the porting team had to test their parts - compiler, linker, libraries - hard, but could trust the existing high-quality codebase. In "A New Golden Age for Computer Architecture”, 2019 by Hennessy & Patterson, make an aside: In today's post-PC era, x86 shipments have fallen almost 10% per year since the peak in 2011, while chips with RISC processors have skyrocketed to 20 billion. Today, 99% of 32-bit and 64-bit processors are RISC. i suggest this goes back to PCC followed by the MIPS R2000 - made possible by Dennis’ C language. The 1977 invention of ‘pcc’ and rewriting of Unix for cross-machine portability was the first time I’m aware of this being done. ( Miller @ UoW did a one-off hack, not to devalue his work, he ported, didn’t invent a multi-target portable compiler ) One of the effects of “portable C” was creating whole new industries for third party software developers or enabling niche products, like CISCO routers and the many embedded devices. C and Unix came with the tools to create new languages and new tools. AWK, sed (!) and shells are obvious examples, with Perl, Python & PHP very big in Internet of 2000. C was a new class of language - a tool to create tools. It creates a perfect mechanism to bootstrap any new language, tool or product, allowing to be refined & used enough to become reliable before being made self-hosting. Very widely used languages such as Python are written in C. ORACLE achieved its market dominance by providing ‘portability’ - exactly the same on every platform. Underpinned by portable C. The original 1127 team went on to create other systems and languages, not the least being a new Software Engineering tool, “Go” / golang, addressing a whole slew of deficiencies in the C/C++ approach and We’d have no Internet today without Apache written in C and being ported to every environment. Also, there’s a connection between C and ‘modern’ Software Engineering - distributed Repositories, automated builds & regression tests, and the many toolchains and tools used. They tended to be built in C to address problems (Open Source) developers were finding with existing toolchains. ‘make’ arose at Bell Labs to automate builds, along with PWB and Writers Workbench. There’s two questions / observations about 50 years of C in broad use: - Just how much C is out there and used ‘in production’? - C is ‘obviously’ a product of the 1970’s, not reflecting needs of modern hardware, networks, storage and systems, but _what_ can replace it? There is simply too much critical code written in C to convert it to another ‘better, modern’ language. Any new language that is a simple 1:1 rewriting of C cannot address any of the deficiencies, while any incompatible language requires redesign and reimplementation of everything - an unachievable goal. The Linux Kernel’s “rust” project shows the extent of the problem - even with the best team of the best developers, its a mammoth undertaking, with uncertain payoffs, unquantifiable effort & deadlines. My thesis is that portable, standard C: - not only co-evolved with other tools & needs to create the Modern Software Engineering environment, the basis for multiple Trillion dollar enterprises (FAANG) but - drove the biggest, most profitable software market ever seen (Wintel) - which drove sales volume of x86 chips (& DRAM, motherboards, LAN, GPU, monitors, peripherals…) over 2-3 decades, - which drove Silicon Valley, paying for new generations of Fabs and lowering chip prices further & further - and eventually created the Fabless RISC CPU company, which in the Post-PC era absolutely dominates chip sales. No Software, no Silicon… Gordon Moore, in an early comment on his 1968 startup with Robert Noyce, said: “we are the real revolutionaries" (vs Hippies & 1967 Summer of Love). I think Ken & Dennis [ and 1127/ Bell Labs folk ] can say the same. ========== I’ve written some notes, with links to Programming Languages, especially Jean Sammet’s Histories, and would like some critiques, suggestions & corrections if people have time and interest. Unix and C are intimately related - neither was possible or useful without the other. i think there’s an interesting article in there, but I’m not sure I have what it takes to write it, not in a finite time :) Very happy to help anyone who does! Did-C-lang-create-modern-software-industry.txt <https://drive.google.com/file/d/1k936sgqHc-vHBvfCdLoSxFhdT9NaijU2/view?usp=…> steve jenkin 04 - dec - 2024 ========== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

7 months

22
34
0 0

Xenix Distribution for PDP-11

by Henry Bent

Hello all, The recent discussion about Xenix has me curious: does any Xenix distribution for the PDP-11 survive? I've never seen one and it would be a fascinating historical artifact. That being said, I am not soliciting copyrighted software; I would be more than happy with a simple answer of, "yes, one has been archived." -Henry

7 months

1
0
0 0

Re: Pipes (was Re: After 50 years, what has the Impact

by Steve Simon

helios supported DAG shell syntax. helios was a unix style os (was it actually posix compliant?) for networks of transputers. -Steve

7 months

5
6
0 0

Re: Pipes (was Re: After 50 years, what has the Impact of Unix been?)

by Douglas McIlroy

Many tree and dag pipe notations have been proposed. Marc's was one of the first. I devised one myself, but didn't like it enough to publish it even as a TM. A recent one is Spinellis's dgsh. More elaborate networks with feedback loops evolve for power-series computation. The idea of implementing cellular automata as arrays of processes with nearest neighbors connected by pipes was suggested early on, but I've never seen such an arrangement implemented--it would be hideously slow. I once wrote a general plumber that worked from a connection list: connect fd m in process A to fd n in process B. The main challenge was to find an order of hooking things up so that the number of live file descriptors in the plumber didn't exceed the system limit. Doug

7 months

1
0
0 0

Re: After 50 years, what has the Impact of Unix been?

by Douglas McIlroy

> Pipes were invented at least three times I would add a 4th: POGOL--a remarkable data-processing language from NSA, described by Gloria Lambert at the first POPL conference, 1973. A POGOL program is made of processes that read and write notional files. The compiler considers all the processes together and optimizes files out of existence wherever it sees that written data can be read immediately. Otherwise a buffering file is instantiated. Unlike Unix pipes, though, a pair of communicating processes must share common knowledge about the connection--the file name. A ready-made theory of pipe networks was published essentially simultaneously with the advent of DTSS communication files: R.M. Karp, R.E. Miller, and S. Winograd. The organization of computations for uniform recurrence equations. Journal of the ACM, 14(3):563-590, July 1967. Completely unsuspecting processes could have been connected by a pair of DTSS communication files controlled by a master relay process. As far as I know this was never done, although such a mechanism was used for the DTSS chat facility. For the special case of clocked sample-data networks, BLODI (block diagram compiler) by Lochbaum, Kelly and Vyssotsky was way ahead (1960) of all the pipe-based formalisms. Doug

7 months

1
0
0 0

I threw together a MINIX 1.5 system call emulator

by Chris Hanson

Since MINIX was a UNIX V7 clone for teaching, I figure this is at least somewhat on-topic. I’ve wanted to port MINIX 1.5 for M68000 to other systems besides Amiga, Atari ST, and the classic Mac, but trying to do that within a system emulator is a pain and doesn’t help you use a modern editor or SCM system. So I took the Musashi M68000 emulator and, using the MINIX 1.5 sources for Atari ST for reference, I’ve implemented a system call emulator that’s now _almost_ sufficient to run /usr/bin/cc. It’s up on GitHub at https://github.com/eschaton/MINIXCompat and I’ve released it under an MIT license. It requires my forked version of the Musashi project that supports implementing a TRAP instruction via a callback, which is necessary for implementing system calls on the host side. I reference this via a submodule so it can be kept at least logically distinct from the rest of the code. There’s no Makefile as I’m using Xcode on macOS to develop it, though I expect to write one at some point so I can run it on NetBSD and Linux as well as on macOS; writing one should be straightforward. -- Chris

7 months

1
0
0 0

Amdahl UTS use by 386 designers

by Jonathan Gray

I found it interesting that Amdahl UTS was used by designers of the 386. "we instituted Unix for the 386 design. Again if management knew what we were doing they wouldn't have let us do it." https://archive.computerhistory.org/resources/text/Oral_History/Intel_386_D… pp. 14-15 Intel Alumni Network, 386 panel https://www.youtube.com/watch?v=fj8fnwuJGto&t=1540s Pat Gelsinger - UTS for Design Engineers https://www.gregbryant.com/intel/pat_gelsinger_unix_1984.pdf via https://mastodon.social/@aka_pugs/111723262047370983 "Given Pat was a bit of a UNIX hacker at the time, he set up the entire design team inside of his CMS account which was running the UTS UNIX environment from Amdahl." Gelsinger, Kirkpatrick, Kolodny, Singer Coping with the Complexity of Microprocessor Design at Intel - A CAD History https://kolodny.net.technion.ac.il/files/2016/07/IntelCADPaperFinal2.pdf

7 months

2
1
0 0

Re: Typesetter C Compiler and Troff (Re: Re: v6 Unix Documents)

by jnc＠mercury.lcs.mit.edu

> From: > I was able to rebuild both the UNSW and the native PWB compiler on PWB > 1.0, but not to backport either to vanilla v6. Any idea what the problem was? I'm curious, because we ran a version of the Typesetter compiler on the MIT systems, which ran an enhanced V6. Noel

7 months

4
4
0 0

Re: After 50 years, what has the Impact of Unix been?

by Douglas McIlroy

Rich's remark about file types reminded me of an ancient non-Unix story that I sent to Coff. Doug

7 months

1
0
0 0

The History of the BSD Daemon

by Jan Schaumann

Marshall Kirk McKusick gave a talk on the history of the BSD Daemon: https://www.youtube.com/watch?v=AeDaD-CEzzg "This video tells the history of the BSD Daemon. It starts with the first renditions in the 1970s of the daemons that help UNIX systems provide services to users. These early daemons were the inspiration for the well-known daemon created by John Lasseter in the early 1980s that became synonymous with BSD as they adorned the covers of the first three editions of `The Design and Implementation of the BSD Operating System' textbooks. The talk will also highlight many of the shirt designs that featured the BSD Daemon."

7 months

2
2
0 0

Re: v6 Unix Documents

by Jonathan Gray

On Sun, Oct 20, 2024 at 01:23:23AM -0400, Dan Plassche wrote: > > On Sat, 19 Oct 2024, Jonathan Gray wrote: > > > PWB was an early external distribution with troff. > > > > Documents for the PWB/UNIX Time-Sharing System > > https://datamuseum.dk/wiki/Bits:30007124 > > https://bitsavers.org/pdf/att/unix/PWB_UNIX/ > > > > NROFF/TROFF User's Manual > > October 11, 1976 > > datamuseum.dk, pp 325-357 > > bitsavers, pp 217-249 > > > > Addendum to the NROFF/TROFF User's Manual > > May 1977 > > datamuseum.dk, p 358 > > bitsavers, p 250 > > > > fonts described in: > > Administrative Advice for PWB/UNIX > > 23. PHOTOTYPESETTING EQUIPMENT AND SUPPLIES > > datamuseum.dk, p 647 > > Thank you Jonathan. I was previously not sure where to place the > PWB documentation in the timeline but a clearer picture is > emerging. > > Based on the v6 "NROFF User's Manual" revised in 1974 and > published in 1975, I can now see that the PWB documentation with > the "NROFF/TROFF User's Manual" from 1976-77 has most of the > content that later appears in v7. The major change immediately > beforehand was the rewrite of troff into C.[1] Some clear > differences are the combination of nroff and troff manpages and > the addition of troff specific features like the special fonts > into the user's manual. > > [1]. Apparently in 1976: > https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description-tr… "It was rewritten in C around 1975" Kernighan in CSTR 97, A Typesetter-independent TROFF I've seen references to "Documents for Use with the Phototypesetter (Version 7)" which was likely distributed with the licensed phototypesetter tape in 1977. What may have been the manual distributed with that tape is also close to v7. https://www.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/troff/doc https://www.tuhs.org/Archive/Distributions/Other/Interdata/ tuhs Applications/Spencer_Tapes/unsw3.tar.gz usr/source/formatters/troff/doc/

7 months, 1 week

2
3
0 0

Re: Canonical Historic Approach to iconv(1)

by Rudi Blom

The "man 1 iconv" page on both HP-UX 11i 11.23 (Aug 2003) and 11.31 (Feb 2007) remark that iconv was developed by HP. Cheers, uncle rubl -- The more I learn the better I understand I know nothing.

7 months, 1 week

1
0
0 0

Canonical Historic Approach to iconv(1)

by segaloco

So a project I'm working on recently includes a need to store UTF-8 Japanese kana text in source files for readability, but then process those source files through tools only guaranteed to support single-byte code points, with something mapping the UTF-8 code points to single-byte points in the destination execution environment. After a bit of futzing, I've landed on the definition of iconv(1) provided by the Single UNIX Specification to push this character mapping concern to the tip of my pipelines. It is working well thus far and insulates the utilities down-pipe from needing multi-byte support (I'm looking at you Apple). I started thumbing through my old manuals and noted that iconv(1) is not a historic utility, rather, SUS picked it up from HP-UX along the way. Was there any older utility or set of practices for converting files between character encodings besides the ASCII/EBCDIC stuff in dd(1)? As I understand it, iconv(1) is just recognizing sequences of bytes, mapping them to a symbolic name, then emitting them in the complementary series of bytes assigned to that symbolic name in a second charmap file. This sounds like a simple filter operation that could be done in a few other ways. I'm curious if any particular approach was relatively ubiquitous, or if this was an exercise largely left to the individual and so solutions were wide and varied? My tool chain doesn't need to work on historic UNIX, but it would be cool to understand how to make it work on the least common denominator. - Matt G.

7 months, 1 week

3
3
0 0

Proposed release goal: [PATCH] [pic] Add support for arbitrary polygons

by Douglas McIlroy

A worthy objective, but it should not be released without user documentation. Where can one see that? Doug

7 months, 2 weeks

2
2
0 0

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

by Douglas McIlroy

>>> malloc(0) isn't undefined behaviour but implementation defined. >> >> In modern C there is no difference between those two concepts. > Can you explain more about your view There certainly is a difference, but in this case the practical implications are the same: avoid malloc(0). malloc(0) lies at the high end of a range of severity of concerns about implementation-definedness. At the low end are things like the size of ints, which only affects applications that may confront very large numbers. In the middle is the default signedness of chars, which generally may be mitigated by explicit type declarations. For the size of ints, C offers guardrails like INT_MAX. There is no test to discern what an error return from malloc(0) means. Is there any other C construct that implementation-definedness renders useless? Doug

7 months, 2 weeks

17
30
0 0

Looking for historical vi sources

by Anton Shepelev

Hello, all. Have you an idea where one could find the sources of the various versions of the ex/vi editor, besides those archived at TUHS: 1BSD/ex-1.1 2.11BSD/src/ucb/ex 2.9BSD/usr/src/ucb/ex/ex2 2.9BSD/usr/src/ucb/ex/ex3 2BSD/src/ex 3BSD/usr/src/cmd/ex 4.1cBSD/usr/src/ucb/ex 4.2BSD/usr/src/ucb/ex 4.3BSD-Reno/src/usr.bin/ex 4.3BSD-Tahoe/usr/src/ucb 4.3BSD-UWisc/src/ucb/ex 4.3BSD/usr/src/ucb/ex 4.4BSD/usr/src/usr.bin/ex 4BSD/usr/src/cmd/ex OpenSolaris_b135/cmd/vi There include vv. 1.1, 2.13, 3.2, 3.6, and many variants of 3.7. Has anything else been preserved to your knowledge?

7 months, 3 weeks

1
0
0 0

RIP Darl McBride former CEO of SCO

by Will Senn

It happened in September, apparently, but is only now making the rounds. Darl McBride, known for taking everybody and his brother to court over stolen code, has passed away. https://fossforce.com/2024/11/once-linuxs-biggest-enemy-darl-mcbride-dies-a… I actually remember liking SCO back in the day, before the company leadership went dark-side. These days, we get to play with ancient unix cuz of their license. What a topsy turvy world. Is there a concise summary of the SCO suits and fallout out there? I've seen a lot on the AT&T side of things, but other than having lived through it, I've not seen much on what eventually happened and why it all sort of just dissappeared. Will

7 months, 3 weeks

10
29
0 0

Fwd: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

by Warner Losh

---------- Forwarded message --------- From: Warner Losh <imp(a)bsdimp.com> Date: Fri, Nov 8, 2024 at 3:17 PM Subject: Re: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) To: David Barto <barto(a)kdbarto.org> On Fri, Nov 8, 2024 at 1:07 PM David Barto <barto(a)kdbarto.org> wrote: > > > On Nov 8, 2024, at 12:27 PM, Warner Losh <imp(a)bsdimp.com> wrote: > > > > On Fri, Nov 8, 2024, 6:20 AM Dan Cross <crossd(a)gmail.com> wrote: > >> On Tue, Nov 5, 2024 at 2:02 PM Warner Losh <imp(a)bsdimp.com> wrote: >> > On Tue, Nov 5, 2024 at 11:52 AM ron minnich <rminnich(a)gmail.com> wrote: >> >> I keep wondering if this assertion of code difference or lack thereof >> can be tested. Are not all these sources available? Which bits are missing? >> > >> > Yes. Great question. >> > >> > https://people.freebsd.org/~imp/pmap/pmap.32v >> > https://people.freebsd.org/~imp/pmap/pmap.4.2 >> > https://people.freebsd.org/~imp/pmap/pmap.4.3 >> > https://people.freebsd.org/~imp/pmap/pmap.net.2 >> >> Hmm; these all 404 for me? > > > Doh! Too much muscle memory. Those should all be bmap: > > https://people.freebsd.org/~imp/bmap/bmap.32v > <https://people.freebsd.org/~imp/pmap/pmap.32v> > https://people.freebsd.org/~imp/bmap/bmap.4.2 > <https://people.freebsd.org/~imp/pmap/pmap.4.2> > https://people.freebsd.org/~imp/bmap/bmap.4.3 > <https://people.freebsd.org/~imp/pmap/pmap.4.3> > https://people.freebsd.org/~imp/bmap/bmap.net.2 > <https://people.freebsd.org/~imp/pmap/pmap.net.2> > > https://people.freebsd.org/~imp/bmap/bmap.32v https://people.freebsd.org/~imp/bmap/bmap.4.2 https://people.freebsd.org/~imp/bmap/bmap.4.3 https://people.freebsd.org/~imp/bmap/bmap.net.2 Not sure why the previous... Warner

8 months

2
1
0 0

Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

by Warner Losh

On Fri, Nov 8, 2024, 6:20 AM Dan Cross <crossd(a)gmail.com> wrote: > On Tue, Nov 5, 2024 at 2:02 PM Warner Losh <imp(a)bsdimp.com> wrote: > > On Tue, Nov 5, 2024 at 11:52 AM ron minnich <rminnich(a)gmail.com> wrote: > >> I keep wondering if this assertion of code difference or lack thereof > can be tested. Are not all these sources available? Which bits are missing? > > > > Yes. Great question. > > > > https://people.freebsd.org/~imp/pmap/pmap.32v > > https://people.freebsd.org/~imp/pmap/pmap.4.2 > > https://people.freebsd.org/~imp/pmap/pmap.4.3 > > https://people.freebsd.org/~imp/pmap/pmap.net.2 > > Hmm; these all 404 for me? Doh! Too much muscle memory. Those should all be bmap: https://people.freebsd.org/~imp/bmap/bmap.32v <https://people.freebsd.org/~imp/pmap/pmap.32v> https://people.freebsd.org/~imp/bmap/bmap.4.2 <https://people.freebsd.org/~imp/pmap/pmap.4.2> https://people.freebsd.org/~imp/bmap/bmap.4.3 <https://people.freebsd.org/~imp/pmap/pmap.4.3> https://people.freebsd.org/~imp/bmap/bmap.net.2 <https://people.freebsd.org/~imp/pmap/pmap.net.2> which shows the progression before the rewrite in 4.4BSD-lite. Warner

8 months

1
0
0 0

Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh >> On Mon, Nov 4, 2024 at 8:14PM Larry McVoy wrote: >> The bmap implementations I saw were bit for bit identical, same code, >> same variables, same style, same indentation. I'm 100% sure they were >> not independent. > They are different in 4.3BSD. They are different in 4.2BSD (but less > different). The underlying filesystems are different on disk, so they > routines have to be different. That last sentence points out something important that people need to remember in this discussion: in between 4.1 and 4.2 (technically, in 4.1B), BSD switched to the BSD Fast File System, so I very much doubt that the low-level (i.e. logical file block to disk block) file system code in anything after 4.1A looks much like the AT+T low-level file system code. (I have no idea how the BSD code compares to the Linux file system code, but that's between the Linux people, and Berkeley.) Noel

8 months

4
5
0 0

IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO))

by Douglas McIlroy

As a bit-part expert witness for the other side of the SCO case, I saw hundreds of pages of evidence in the form of side-by-side code comparison. As I recall, the vast majority of highlighted correspondences were small snippets, often rearranged. I didn't interact with the lawyers enough to form a solid opinion about where this stood on the spectrum of coincidence to fair use to plagiarism. It certainly wasn't wholesale copying. I do not recall being asked to opine on whether trade secrets had been stolen. Apropos of rearranged snippets, one of the diff algorithms I experimented with in the mid-70s identified rearrangements. I abandoned it because real life code contains lots of similar lines, so many in PDP-11 assembler programs as to suggest that these programs are largely permutations of each other. The phenomenon is much less common in C, but still present; witness the prevalence of code like int i, n; for(i=0; i<n; i++) { The phenomenon may have been afoot in the SCO evidence. In regard to trade secrets, I was surprised when I moved from Unix at Bell Labs to Linux at Dartmouth and found calendar(1) to be completely rewritten, but with logic absolutely identical to the original version I wrote at the Labs. That was so idiosyncratic that the identity of the two could not have been an accident. Doug

8 months

1
0
0 0

QED Archive updated

by arnold＠skeeve.com

Hi All. For anyone who's interested, my QED archive at https://github.com/arnoldrobbins/qed-archive has been updated. Changes were provided by Sean Jensen. The usenix-80-caltech subdirectory is now more complete and the README.md points at Sean's updated QED port which now works with Unicode. I thank him. Arnold

8 months, 2 weeks

1
0
0 0

Other UNIX Archival Efforts?

by segaloco

So with all that has happened with the Internet Archive lately, I do find myself a bit concerned regarding the UNIX materials that I know to only exist there. Selfishly, this includes my own uploads here: https://archive.org/details/@segaloco I was curious if anyone has any suggestions on places beyond just IA and TUHS where I could see about getting this stuff mirrored? Unfortunately my stuff runs afoul of bitsavers's DPI requirements, that's the only other source that immediately comes to mind where these materials would find home. Any thoughts? Warren, I know you had mentioned a "write only" archive you maintain regarding materials that need to be mothballed until legal understandings are reached, would you be comfortable with my contributing any of my materials the Caldera license does not apply to there? - Matt G.

8 months, 2 weeks

3
2
0 0

v6 Unix Documents

by Dan Plassche

Hi, A scan of the printed UNIX Version 6 documents set is now online at the link below since last week. The set consists of documents accompanying the manual pages in the programmer's manual (similar to volume 2 in v7). https://www.computerhistory.org/collections/catalog/102659317 The [nt]roff user manual, tmg compiler-compiler, and m6 macro processor memos were previously missing from the distributions in TUHS and later efforts to re-create the documentation. I have been working on finding this documentation as part of researching roff history. Still interested in earlier copies of the internal memoranda from Ossanna that served as the NROFF User's Manual since v3, the TROFF User's Manual after v5, and TROFF Made Trivial starting around v4. Based on the manpage histories, the documentation was revised for v4, 5, and 6. Best, Dan Plassche

8 months, 2 weeks

4
5
0 0

Re: On computerese

by Douglas McIlroy

> Who created the "cat" command and did they have the > word "catenate" or "concatenate" in their heads? Ken Thompson wrote "cat" for the PDP-7, with "concatenate" in mind. The cat(1) page in the v1 manual is titled, "concatenate (or print) files". Only later did someone in Research--I don't know who--remark on the existence of the shorter synonym. It was deliberately adopted in v7, perhaps because it better mirrored the command name. But brevity is the defensible argument for "catenate", while familiarity boosts "concatenate". It stll takes some conscious effort for me to use the former, However, I sense sinister vibes in "concatenate", driven by the phrase "concatenation of events", which often is used to explain misfortune. Doug

8 months, 3 weeks

26
38
0 0

Re: lilian schwartz has died

by Rob Pike

I always forget that TUHS can't handle pictures. Perhaps Warren will let my post through, but in any case here's a link to the mail, reformatted but otherwise intact, with photos, on Mastodon. https://hachyderm.io/@robpike/113322062117546253 To pique your interest, here's the first paragraph. *In August 1981 we had a persistent problem with the RP06 on our PDP-11/70 crashing disks. It even crashed once while the DEC repairman was standing next to it trying to figure out why the previous pack had died. We collected a few dead packs, and they were forming a pile. Lillian, never one to miss an opportunity, suggested building a mobile.* -rob

8 months, 3 weeks

2
1
0 0

Can Ancient Unix be relicensed?

by Anton Shepelev

Hello, all. In 2002, Caldera released Ancient Unix code under Caldera license: <https://www.tuhs.org/Archive/Caldera-license.pdf> based on the four-clause BSD license: <https://spdx.org/licenses/BSD-4-Clause.html> Consequently, it was used by derived projects, such as Traditional Vi: <https://ex-vi.sourceforge.net/> This proect having been abandoned and orphaned since 2005, I wanted to host it on GNU Savanna and there to breath some life into it. Unfortunately, the 4-clause BSD license is incompatible with GPL: <https://www.gnu.org/licenses/license-list.html#OriginalBSD> The incompatibilty is due entirely to the infamous third clause about adverising. Three years prior to Caldera's release of old Unix code, The Berkley Univercity removed this clause, producing the GNU-compatible modified BSD License: <https://opensource.org/license/BSD-3-clause> They published a notice to that effect on their FTP: <ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change> Although it has been taken down[1], copies exist all over the internet, e.g.: <https://raw.githubusercontent.com/abbrev/punix/refs/heads/master/README.Imp…> That said, is there a chance that the copyright holder of Ancient Will agree to release a similar note regarding everying released under Caldera license? If there is, whom shall I contact about it? It will benefit everybody using Ancient Unix code. ____________________ 1. Why the murrain of FTP servers all over the world?

8 months, 3 weeks

5
6
0 0

Draft v5: London and Reiser's UNIX VAX port paper, reconstructed

by G. Branden Robinson

Hi folks, A few months ago I reported on my efforts to reconstruct London & Reiser's paper on their port of Unix to the VAX-11/780.[1] I formerly characterized this as "the UNIX/32V port", but since London & Reiser's paper predates the release of Seventh Edition Unix by about six months, UNIX/32V came _after_ Seventh Edition by about the same number of months, and the pace of Unix development was particularly ferocious in this period[2], I felt that my identification of London & Reiser's work with UNIX/32V may have been hasty. I also may have overinterpreted Dennis Ritchie's words on the subject. "Tom London and John Reiser, working from the 7th Edition and the Interdata 8/32 system, generated a VAX 11/780 version of the system, which, in its distribution format, would be called 32V." That phrase "in its distribution format" could cover a variety of changes, some of which perhaps did not match London & Reiser's intentions or views expressed in their paper. More conservative implications seemed prudent. I'd thus like to present what I consider to be my "final" draft, subject of course to feedback from these mailing lists. I'm pleased to report that I've addressed all of the XXX points I identified in the source of my first draft, points where I felt groff mm could be enhanced to aid the rendering of historical documents like this. I consequently expect groff 1.24's mm package to support several new features prompted specifically by this work. Quoting the forthcoming NEWS file... * The m (mm) macro package now supports a user-definable hook macro `AFX`, which if defined is called by `AF` in lieu of the latter's normal operation. Applications include customization of letterhead. * The m (mm) macro package now supports a user-definable hook macro `RPX`, which if defined is called by `RP` to format the reference list caption string `Rp` instead of the default formatting. * The m (mm) macro package now supports an `Aumt` string to suppress the appearance of positional arguments to the `AU` macro in the document heading used by memorandum types 0-3 and 6. By default, all such arguments appear, except the second (author initials). For example, a value of "3 4" more accurately reproduces London & Reiser's 1978 paper describing the porting of Unix to the VAX-11/780. * The m (mm) macro package now supports an `Rpfmt` string specifying the `LB` macro arguments that the package uses to format the items in a reference list. * The m (mm) macro package no longer superscripts _and_ brackets a reference mark (the `Rf` string). Instead, the new `Rfstyle` register controls its formatting. The default, 0, selects bracketing in nroff mode and superscripting in troff mode. Set `Rfstyle` to 3 in a document to obtain groff mm's previous mark formatting behavior. [I might still update or revert the changed default; I want to research the behavior of historical mm implementations.] The "32vscan.pdf" document from which I prepared this reconstruction is available at Dennis Ritchie's memorial home page.[3] I have attached the reconstructed mm source document and two PDFs, rendered with groff 1.23.0 (the current stable release), and groff Git HEAD (exercising the new features listed above).[4] I offer the caveat that these cannot be pixel-perfect recreations because (1) I have no information about the precise paper dimensions or margins London & Reiser used[5]; (2) the fonts employed in rendering the documents are not identical, metrically or otherwise; and (3) AT&T and GNU troffs use different hyphenation systems and therefore sometimes break words differently. These factors all impact the placement of line and page breaks, and these are avowedly and clearly distinguishable. There are furthermore a few discrepancies that I decided weren't worth the trouble at this time to reconcile, like selective encroachment of cover sheet material beyond the page margins. None affect the utility of the document (in my opinion). With that large disclaimer in place, I welcome feedback on the quality of the reproduction. Finally, I reiterate my encouragement that the document be _read_. In my opinion, the final two sections "Commands" and "Software portability" are well worth consideration in hindsight. To the extent that we continue to boast, sometimes glibly, of C as a "portable assembly language", be it in its current ISO C23 incarnation; as ANSI C89, the last revision blessed by Ritchie; or in the form used when London and Reiser wrote, their experiences and recommendations laid out a program of better delivering on that promise. Regards, Branden [1] https://www.tuhs.org/pipermail/tuhs/2024-June/030041.html [2] 1980, for example, saw releases of 3BSD, System III, PWB/UNIX 2.0, and 4BSD. [3] https://www.bell-labs.com/usr/dmr/www/portpapers.html [4] You may notice a difference in the sizes of the two PDFs, surprising in light of their shared source document. This is thanks to a new feature forthcoming in Deri James's gropdf(1) output driver: font subsetting. [5] ...or where, if anywhere, the authors "cheated" the margins temporarily, for instance with `ll` or `pl` requests. Even with mm macro package sources available, such things would be invisible to the reconstructor.

8 months, 3 weeks

1
0
0 0

Old troff files (1988-2007)

by Jacobson, Doug W [E CPE]

Folks: Long story short, I have a unpublished manuscript that a faculty member in my department wrote late 1980's early 2000's. He did the entire thing in troff, eqn, and pic. The faculty member is still alive. A publisher is interested in the manuscript. I have all of the source files on an old unix machine that still has troff, eqn and pic. It also has groff. This issue is that the pic commands are bracketed by .G1 and .G2 not .PS & .PE. The original machine he would have used would have ran AT&T Sys V on an AT&T 3B20. Below is one of the files. Any thoughts on the .G1 .G2? I can get the files that have only eqn and troff to create postscript, but the .G1/.G2 is not understood by pic. I tried replacing the .G1/.G2 with .PS/PE and it failed. I must be missing another program that uses the .G1/2 Thanks .sp -3.5 .fp 1 Z .fp 2 XI .ps 11 .tl ' ' '1-10' .EQ delim $$ gsize 11 .EN .po 0.9i .vs 15 .G1 frame wid 5.7 ht 6.0 invis coord x 0.2, 100 y -40, +22 log x grid left from -30 to +20 by 10 "" grid left from -40.04 to +19.96 by 10 "" grid left from -39.96 to +20.04 by 10 "" grid left from -39 to +22 by 1 "" grid bot from 0.4 to 40 by *10 "" grid bot from 1 to 100 by *10 "" grid bot from 0.2 to 20 by *10 "" grid bot from 0.3 to 30 by *10 "" grid bot from 0.5 to 50 by *10 "" grid bot from 0.6 to 60 by *10 "" grid bot from 0.7 to 70 by *10 "" grid bot from 0.8 to 80 by *10 "" grid bot from 0.9 to 90 by *10 "" ticks out left from -40 to +20 by 10 ticks out bot from 0.2 to 20 by *10 ticks out bot from 0.4 to 40 by *10 ticks out bot from 1 to 100 by *10 draw solid 0.2 19.93 2 19.93 10 5.97 100 -34.02 new solid 0.2 20.07 2 20.07 10 6.05 100 -33.95 new dotted for i=0.45 to 23 by *1.05 do { w=i*i f=200/sqrt(w*w+104*w+400) next at i,20*log(f) } label left "\u\udB \d\d" label bot "\(*w, rad/s" .G2 .in 2 Fig. 1.4. Graph of the magnitude in dB of $H(s)~=~200 over{s sup 2~+~12^s~+~20}^,$$~s~=~j^omega$. Doug Jacobson University Professor, Dept. Electrical & Computer Engineering Sunil & Sujata Gaitonde Professorship in Cybersecurity Director: ISU Center for Cybersecurity Innovation and Outreach Mail Address: 2520 Osborn Dr, 2215 Coover Hall Iowa State University PH: (515) 294-8307 Fax (515) 294-8432 Office: 371 Durham Hall Center web site: http://www.cyio.iastate.edu/<https://urldefense.com/v3/__http:/www.cyio.iastate.edu/__;!!DZ3fjg!oVZir7OL…> Personal web site: http://www.dougj.net<https://urldefense.com/v3/__http:/www.dougj.net/__;!!DZ3fjg!oVZir7OL4VMZHCY…>

8 months, 3 weeks

10
19
0 0

Re: lilian schwartz has died

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

8 months, 3 weeks

1
0
0 0

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.

8 months, 3 weeks

2
1
0 0

Copyright on 4.2BSD?

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

8 months, 3 weeks

6
6
0 0

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

8 months, 4 weeks

4
3
0 0

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

9 months

2
1
0 0

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.

9 months

1
0
0 0

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

9 months

1
1
0 0

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

9 months

17
42
0 0

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

9 months

1
0
0 0

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

9 months

2
1
0 0

Re: UNIX NEWS, volumes 1-7 out there?

by sjenkin＠canb.auug.org.au

In Sept 2019 Warner Losh was looking for copies of the first volumes of UNIX NEWS / Login. Clem Cole noted that the Usenix Archives were also looking. Kurt H Maier, noted he had pages from 1976, Volume 1, Number 4. Jeremy C. Reed pointed to multiple items available online. His email appears in a separate email thread on TUHS. <https://tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/thread/C2L346YQTFU2…> <https://tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/message/FMSC3426GK2…> I stumbled on UNIX NEWS Number 1 in the Internet Archive <https://archive.org/details/unix_news_july-30-1975> Which is from a near complete Usenix collection of ‘;login' from 1975 to 2000 <https://archive.org/details/usenix-login?tab=collection&sort=-date>. 1979 (Volume 4) is missing from the series [ as at Oct 2024 ] I wasn’t able to navigate the Usenix website to find the Archives Clem Cole mentioned, to confirm they also had copies. I also stumbled on a pointer to “John Gilmore’s original scans” from 1975 - 1978, presumably the base for the Usenix / Archive.org set. <http://www.toad.com/early-usenix-newsletters/> It’s seems that the call for materials was pretty successful. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

9 months

1
0
0 0

Fwd: Trove of CSTR's

by Warren Toomey

All, I got this e-mail and thought many of you would appreciate the link. Cheers, Warren ----- Forwarded message from Poul-Henning Kamp ----- I stumbled over this: https://www.telecomarchive.com/lettermemo.html is the TUHS crew aware of that resource ? ----- End forwarded message -----

9 months, 1 week

7
8
0 0

Origins of "Unix Philosophy"

by Phil Budne

I'm wondering if there are places where people who were in the Unix Room wrote about the origins and evolution of what people (at least used to(*)) refer to as "Unix Philosophy", and since some are in THIS (TUHS) room, what they might have to say about it. How much was in reaction to the complexity of Multics, and how much was simply a response to the limited address spaces of available and affordable hardware? Eric S. Raymond wrote in "The Art of Unix Programming" quoting Doug McIlroy and Rob Pike: http://www.catb.org/esr/writings/taoup/html/ch01s06.html And I wonder if they care to comment on it? I have trouble taking ESR as authoritative, as, it seems to me that Research Unix was more a product of the "Cathedral" (or at least a contained community) than the "Bazaar" (at least the modern bazaar, where everyone needs to leave a new feature grafito on the town walls), and ESR A side question for Rob Pike, is the "Not only is UNIX dead, it's starting to smell really bad." quote accurate? Was it in reaction to BSD, GNU, or all of the above? (*) I say "used to", because, for the most part, minimalism seems to have left the building. I can't look at modern GNU utilities, and many, if not most open source packages and think they've gone WAY past classic Unix minimalism, especially since I remember hearing that Bell Research had happily stripped excess features (removal of "cat -s" sticks in my mind) from later day research Unix, and because Stallman is said to have coined the term "New Jersey" style as a synonym for what Richard P. Gabriel called "Worse is Better", which seems, an attack on minimalism (nothing less than "the right thing" is acceptable) Worse is.... readings: https://dreamsongs.com/WorseIsBetter.html https://dreamsongs.com/RiseOfWorseIsBetter.html https://dreamsongs.com/Files/IsWorseReallyBetter.pdf https://dreamsongs.com/Files/worse-is-worse.pdf Anti-flamage disclainmers: Inclusion of links above does not imply any agreement on my part! My apologies in advance for any offense, misquote, or misunderstanding on my part.

9 months, 1 week

2
1
0 0

Re: On computerese

by jnc＠mercury.lcs.mit.edu

> From: Rik Farrow <rik(a)rikfarrow.com> > Was the brevity typical of Unix command names a function of the tiny > disk and memory available? Or more a function of having a Teletype 33 > for input? I'm not sure the answer was ever written down (e.g. in a memo); we will probably have to rely on memory - and memories that far back are now fairly thin on the ground by now. Perhaps Mr. McIlroy (or Mr. Thompson, if we're _really_ lucky) will humor us? :-) I have the impression that some of the names are _possibly_ inherited from Multics (which the early Unicians all used before Unix existed) - but maybe not. The command to list a directory, on Multics, is 'ls' (but see below) - but the Multics qcommand to remove a file is 'del' (not 'rm'); and change working directory is 'cwd'. So maybe ls' is just chance? Multics had a 'feature' where a segment (file) could have additional names (to the main name), and this is used to add short aliases to many commands, so the 'base name'' for the directory list command is 'list'; 'ls' is a short alias. A list of Multics commands (with short forms) is available here: https://www.multicians.org/multics-commands.html I'm not sure how early that alias mechanism came in, though; my copy of "Introduction to Multics" (February, 1974) doesn't have short names (or, at least, it doesn't use them). It won't have anything to do with disk and memory. Having used a Teletype, it would take noticeably longer to type in a longer name! It's also more effort and time. I would expect those are the reasons for the short names. Noel

9 months, 1 week

17
32
0 0

Re: Fwd: Trove of CSTR's

by Douglas McIlroy

> I wonder what happened to the amazing library at Murray Hill. Last I knew, the Bell Labs archives were intact under supervision of a professional archivist. Formally speaking, the archives and the library were distinct entities. The library, which was open to self service 24 hours a day, declined rapidly after the bean counters decreed that it should henceforth support itself on rental fees. Departments immediately turned to buying books rather than borrowing them. It's very likely that this was bad for the Labs' bottom line, but the cost (both monetary and intellectual) was not visible as a budgetary line item. The 24-hour library contributed to one of Ken's programming feats. Spurred by a lunchtime remark that it would be nice to have a unit-conversion program, Ken announced units(1) the next morning. Right from the start, the program knew more than 200 units, thanks to a book Ken grabbed from the library in the middle of the night. Doug

9 months, 1 week

2
2
0 0

Re: Fwd: Trove of CSTR's

by Douglas McIlroy

> That CSTR number 1 is nicely formatted, is that troff? The archive's CSTR 1 is ersatz. It's a 1973 journal article obtained from JSTOR. I imagine the manuscript was largely copied from the CSTR, but the printed paper certainly differs in meta-content and in layout, say nothing of font. Having gone through the usual route of journal submission and revision, the body text is probably not word-for-word identical to the CSTR either. Doug

9 months, 1 week

1
0
0 0

Re: Classic FoxTrot cartoon

by norman＠oclsc.org

Clem Cole: Interesting -- 'Jason' had always been a Pascal hacker when the strip was first created. As I recall, Berkeley Breathed had Wendell (his hacker character) comment on that during the time of Pascal/C Wars. ==== But Jason later was revealed to be wearing Unix underpants: https://www.gocomics.com/foxtrot/2002/02/25 Norman Wilson Toronto ON

9 months, 1 week

2
1
0 0

Classic FoxTrot cartoon

by arnold＠skeeve.com

https://www.gocomics.com/foxtrotclassics/2024/09/27 IIRC correctly the original version left out the \n. I was told he got some many comments that he later published a strip that was just: \n Arnold

9 months, 1 week

2
1
0 0

Any Surviving BELLMAC-8 Development Tools?

by segaloco

Hello everyone, I've found myself in the exceptionally fortunate circumstance of securing ownership of a MAC-TUTOR BELLMAC-8 SBC unit. It is still in shipment so I can't assess its operation yet, but I was wondering if anyone is aware of any surviving assemblers, linkers, etc. for this architecture? If not, I'm prepared to roll my own based on available documentation, but figured I'd ask to see if there's anything I can start with. From what I can tell, the main development environment was PWB, specifically the Bell System internal varieties, with the BTL edition of Release 5.0 literature describing things like m8as(1), m8cc(1), etc. as Division 452 Computer Center standard commands. There is a bit of information here as well: http://ferretronix.com/march/sbc/mactutor/ Thanks for any tips! Regardless of how much I can manage to do with it, I'll be sure to get some good pictures and take some notes on what I am able to figure out with the thing. I presume the Gunkies wiki would be a good place to document that sort of thing? - Matt G. P.S. Pardon if this belongs on COFF, I figured since UNIX was the canonical development system and it is also a Bell Labs thing, I'd ask here first.

9 months, 2 weeks

1
0
0 0

kernel boots kernel in 1977

by ron minnich

I noticed there are kexec talks this year at Linux Plumbers. Kexec, kernel boots kernel, has had a 25 year gestation in Linux, but it looks like it's finally coming together, driven by need. Thereby hangs a tale. in 1977, I was working at udel with Ed Szurkowski, the first sysadmin of the Unix systems we got in 1976 (first machine was an 11/70). Ed was a gifted engineer and did all kinds of neat work on v6. He later went to the Labs once he got his PhD and I lost track of him. Ed got tired of watching the bootstrap slowness, and wrote a system call that did the following: 1. load kernel in memory from system call argument 2. put special signature in low memory telling bootstrap "look in memory" 3. reboot via reset. Now, this works, because back then, ROM boot code did not zero memory. Memory was unchanged across reset. So the bootstrap could find the magic bits and start the kernel. I've lost the code, I carried the listings for decades but finally dumped them. A shame. But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or was there something before?

9 months, 2 weeks

11
25
0 0

Re: Maximum Array Sizes in 16 bit C

by Douglas McIlroy

> The array size} limit that I found through trial and error is (2^15)-1. > Declaring an array that is [larger] results in an error of "Constant required", On its face, it states that anything bigger cannot be an integer constant, which is reasonable because that's the largest (signed) integer value. Does that version of C support unsigned constants? Doug

9 months, 2 weeks

13
15
0 0

Free computing books in SF area

by John Floren

It's a bit off-topic but Warren OK'd it: I'm trying to tidy the absolute dragon's hoard I call an office, so I'm looking to give away some books I haven't touched in years. These are free for the taking for anybody who wants to drive to SF and get them. I'd really prefer for somebody to take them all at once, of course. - DEC PDP11/70 Processor Handbook - DEC VAX11 Architecture Handbook - DEC PDP11 Peripherals and Interfacing Handbook - DEC Introduction to Programming (PDP-8) - Programming Languages: History and Fundamentals (Sammet) - Computer Networks, 1st ed (Tanenbaum) - Modern Operating Systems, 2nd ed (Tanenbaum) - Operating Systems Design and Implementation, 1st ed (Tanenbaum) - Advanced Programming in the UNIX Environment (Stevens) - Computer Architecture and Organization, 2nd ed (Hayes) - Compilers: Principles, Techniques, and Tools (Aho, Sethi, Ullman) - The Undocumented PC, 2nd ed (van Gilluwe) - Cybernetics (Wiener) If you want these, please email me *off-list* to set it up. John

9 months, 2 weeks

1
0
0 0

Re: kernel boots kernel in 1977

by jnc＠mercury.lcs.mit.edu

> From: Ron Minnich > Ed got tired of watching the bootstrap slowness This may be a dumb question (in which case, my apologies), but which part of booting a PDP-11 UNIX was slow? And thus, which parts did he bypass in a 'quick reboot'? (I'm having a bit of a hard time working it out.) I can think of the following stages as potentially being 'slow': 1 - reading in the kernel image from disk 2 - sizing/clearing main memory 3 - loading running /etc/init 3A - creating all the 'loqin's 3B - starting all the daemons/etc with /etc/rc (There's obviously a conflict between 2 and 3*; one can't avoid 3* if one does 2.) Which ones did he want to avoid? Avoiding 3* puts some limitations on the system, obviously, because it means one has to keep running processes around; the process table has to have the same format (and be in the same location - or it has to be moved before the new system is started). (Technically, I guess one would have to save the inode and file tables, too; there isn't enough saved data in the kernel to re-open files, plus there are file read/write ocation pointers, etc.) One could sort of do 2 also, if one were prepared to 1) swap all processes out to secondary storage before 'rebooting', and ii) saving the process table. > But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" > or was there something before? Are you talking about for UNIX, or across all operating systems? I don't have that broad a memory any more, to know - did TWENEX have something like that? Noel

9 months, 2 weeks

3
2
0 0

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