TUHS February 2023

tuhs@tuhs.org

65 participants
41 discussions

by steve jenkin

I’m re-reading Brian Kernighan’s book on Early Unix (‘Unix: A History & Memoir’) and he mentions the (on disk) documentation that came with Unix - something that made it stand out, even for some decades. Doug McIlroy has commented on v2-v3 (1972-73?) being an extremely productive year for Ken & Dennis. But as well, they wrote papers and man pages, probably more. I’ve never heard anyone mention keyboard skills with the people of the CSRC - doesn’t anyone know? There’s at least one Internet meme that highly productive coders necessarily have good keyboard skills, which leads to also producing documentation or, at least, not avoiding it entirely, as often happens commercially. Underlying this is something I once caught as a random comment: The commonality of skills between Writing & Coding. Does anyone has any good refs for this crossover? Is it a real effect or a biased view. That great programmers are also “good writers”: takes time & focus, clarity of vision, deliberate intent and many revisions, chopping away the cruft that’s isn’t “the thing” and “polishing”, not rushing it out the door. Ken is famous for his brevity and succinct statements. Not sure if that’s a personal preference, a mastered skill or “economy in everything”. steve j ========= A Research UNIX Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986 M.D. McIlroy <https://www.cs.dartmouth.edu/~doug/reader.pdf> <https://archive.org/details/a_research_unix_reader/page/n13/mode/2up> pg 10 3.4. Languages CC (v2 page 52) V2 saw a burst of languages: a new TMG, a B that worked in both core-resident and software-paged versions, the completion of Fortran IV (Thompson and Ritchie), and Ritchie's first C, conceived as B with data types. In that furiously productive year Thompson and Ritchie together wrote and debugged about 100,000 lines of production code. ========= Programming's Dirtiest Little Secret Wednesday, September 10, 2008 <http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret…> It's just simple arithmetic. If you spend more time hammering out code, then in order to keep up, you need to spend less time doing something else. But when it comes to programming, there are only so many things you can sacrifice! You can cut down on your documentation. You can cut down on commenting your code. You can cut down on email conversations and participation in online discussions, preferring group discussions and hallway conversations. And... well, that's about it. So guess what non-touch-typists sacrifice? All of it, man. They sacrifice all of it. Touch typists can spot an illtyperate programmer from a mile away. They don't even have to be in the same room. For starters, non-typists are almost invisible. They don't leave a footprint in our online community. ========= -- 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

4 months

Early multiprocessor Unix

by Paul Ruizendaal

The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate? My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code. Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()” calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s. Any other notable work in this area prior to 1985? How was the SMP implementation in SVr3 judged back in its day? Paul

4 months

Latest 2.9BSD and 2.11BSD

by Warner Losh

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

8 months

Any Bell 8-bit UNIX Efforts?

by segaloco

So in working on an unrelated 6502 project, I got to wondering about UNIX on it and other 8-bits. Did some Googling, and while I was able to turn up some attempts at UNIX-likes on 6502 as well as Z80, the only one I found that might have some Bell connection is "uNIX" as documented here: https://bitsavers.org/pdf/uNIX/uNIX_Jan82.pdf A forum post I read suggested those involved were some former Bell folks from NJ. In any case, this begs the question for me: Were there ever any serious attempts at an 8-bit UNIX in the labs or Bell System at large? Certainly it would've provided quite the challenge without much return compared with 16 and 32-bit efforts, but does anyone know if, say, an LSX/Mini-UNIX-ish attempt was ever made at the 6502, Z80, or other 8-bits? Thanks all! - Matt G.

9 months, 1 week

Early GUI on Linux

by Paul Ruizendaal

I think discussion of early Linux is in scope for this list, after all that is 30 years ago. Warren, if that is a mis-assumption please slap my wrist. Following on from the recent discussion of early workstations and windowing systems, I’m wondering about early windowing on Linux. I only discovered Linux in the later nineties (Red Hat 4.x I think), and by that time Linux already seemed to have settled on Xfree86. At that time svgalib was still around but already abandoned. By 1993 even student class PC hardware already outperformed the workstations of the early/mid eighties, memory was much more abundant and pixels were no longer bits but bytes (making drawing easier). Also, early Linux was (I think) more local machine oriented, not LAN oriented. Maybe a different system than X would have made sense. In short, I could imagine a frame buffer device and a compositor for top-level windows (a trail that had been pioneered by Oriel half a decade before), a declarative widget set inspired by the contemporary early browsers and the earlier NeWS, etc. Yet nothing like that happened as far as I know. I vaguely recall an OS from the late 90’s that mixed Linux with a partly in-kernel GUI called “Berlin” or something like that, but I cannot find any trace of that today, so maybe I misremember. So here are a few things that I am interested in and folks on this list might remember: - were there any window systems popular on early Linux other than X? - was there any discussion of alternatives to X? - was there any discussion of what kernel support for graphics was appropriate?

9 months, 1 week

Unix V7 enblock.c

by KenUnix

Morning, I am using enblock to create tap files from tar files. Was a program ever written to convert tap files to tar files or a Linux program that could read tap files? I also see that writing to a tap file from Unix the size increases when writing multiple files however when writing 1 file to the tap file "tar cv0 ..." the tap file still remains at its larger size from the previous larger writes. Is this what is expected? Thanks, Ken -- WWL 📚

9 months, 1 week

Unix/Linux games [was Re: Early GUI on Linux]

by Andy Kosela

On Monday, February 27, 2023, Dan Cross <crossd(a)gmail.com> wrote: > On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS <tuhs(a)tuhs.org> > wrote: > > Thanks all for the insights. Let me attempt a summary. > > > <SNIP> > Oh, and lots of games; I had a nice > Solitaire version that I can no longer recall the name of. > > Coming from the 8-bit microcomputer world (Atari 8-bit, C64), and then upgrading to 16-bit (Amiga and PC MS-DOS) I experienced a myriad of unforgettable games on those platforms. They were mostly commercial but they were very much different from modern games. It was the era of innovation and pouring all your soul into the games you produce. I still think that some of them have not been surpassed in quality and playability. I still play them on period correct hardware as they are still extremely fun and challenging. This is my top 10 list (sorted by year): * Prince of Persia * The Secret of Monkey Island * Civilization * Dune II * Master of Orion * Reunion * Warcraft * Ascendancy * Quake * Half-Life As I started to play with Linux in the mid 90s I remember a port of Doom and then Quake, but not that many other games. Can you elaborate more on what Unix afficionados played in the late 80s/early 90s? --Andy

9 months, 1 week

Fwd: Re: Generational development [was Re: Re: Early GUI on Linux]

by Adam Thornton

And, you know, let's say you have all the time and patience in the world and you download the source and read it carefully and determine it's not malicious... I believe there might have been a lecture/paper about this once. https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrust… (I can just hear them damn kids standing on my lawn chanting "You can't spell 'trust' without 'rust'!") I keep trying to give VSCode a go. It seems really nifty. And somehow I keep bouncing off and landing in Emacs, every time. Maybe when I finally get around to writing, rather than cargo-culting TypeScript, or Unity/C#, it'll be a better fit. But for my current life, which is mostly Python...I appear to be sticking with Emacs. Adam

9 months, 1 week

UNIX 4.1 User's Manual Restoration

by segaloco

Got a little present for folks today. Been working on this for a little while now, and while there'll probably be some edits here and there, I believe it to be quite accurate. After the link is a manpage restoration of the UNIX 4.1 User's Manual (3B20S) that I bought a little while ago: https://gitlab.com/segaloco/pwb4u_man The permuted index is the only significant piece that isn't done, but that shouldn't impact the informational value. Note this is just u_man, I haven't found a complimentary a_man copy yet. I hope one will turn up one of these days, but I plan on at least analyzing the gap between System III and System V with regards to those pages as a future project. My process involved diff'ing the available III and V manpage sources and reconciling differences between the two and 4.1 with some copy-paste here and some restoration there. Where differences couldn't be resolved, I simply removed content to match the physical pages. One minute detail that is also not filled in is the page count in M.folio. So I didn't count the pages. Maybe someday. In any case, I appreciate the opportunity this has given me to learn the manpage macros pretty well. Anywho, in the second pass of verifying the changes I took some notes on noteworthy mentions. This list is not an exhaustive analysis but represents some of the areas where significant developments shine through in the text: System III->4.1 (No claims are made as to what occurred at 4.0): - The documentation is cleaned up quite a bit in general, in what seems like a push towards commercial-ready manuals. Many sections are edited to be more clear and descriptive. There is also a notable shift towards gender neutral language. The editors and acknowledgements info are removed, casting an anonymous shadow over the manual maintainers and their muses alike. - The tty manpage is renamed termio, reflecting the shifting terminal interface landscape at this time. - This release adds IPC with a familiar interface to what is in System V. According to various accounts the IPC was under heavy development at this time, but while the underlying components may have been shifting and changing, the documentation changes suggest a relatively stable programmer API by this point. The only IPC-related piece System V adds is icprm(1). - The LP print service is added here. The old lpr system is still there in the background; it is in System V. However, it is relegated to DEC only status. - SGS and COFF development components show up with 4.1 3B-20. No telling what else they officially supported in the 4.x timeframe. The System V pages as described below indicate a number of supported platforms. - The shell gets the $CDPATH and ulimit features - Many system features show a trend towards portability (except the PDP-11, the system appears to be moving away from it) - The Virtual Protocol Machine (VPM) seems to go from targeting KMC11 to UN53 and V.35. Haven't researched what these are yet, but VPM is on the move. - As of 4.1, 3B-20 does *not* support: Fortran, BASIC, Honeywell/GCOS 6000 connectivity, lpr printing, SNOBOL, standalone C - Added pages include cflow(1), cprs(1), cxref(1), dis(1), dump(1) (was a tape dump (1m), now a SGS tool), enable(1), hpio(1), ipcs(1), list(1), lp(1), lpstat(1), newform(1), sadp(1), trouble(1), x25pvc(1), msgctl(2), msgget(2), msgop(2), plock(2), semctl(2), semget(2), semop(2), shmctl(2), shmget(2), shmop(2), sys3b(2), drand48(3c), getcwd(3c), hsearch(3c), ld*(3x) (COFF library), setbuf(3s), stdipc(3c), strtol(3c), termio(4) (renamed from tty(4)), ldfcn(5), mosd(5), mptx(5), jotto(6) - Removed pages include cref(1), dump(1m), fget.odemon(1c), odpd(1c), orjestat(1c), reform(1), tp(1), typo(1), xref(1), tp(4), tty(4) (renamed to termio(4)) - Some pages were skipped and show back up in System V with minimal changes, meaning they were probably in 4.x: adb(1), arcv(1), bs(1), dpd(1c), dpr(1c), efl(1), f77(1), factor(1), fget(1c), fget.demon(1c), fsend(1c), gcat(1c), gcosmail(1c), kas(b)/kun(b)(1), lpd(1c), lpr(1), ratfor(1), scc(1), sno(1), vpr(1) 4.1->System V (Likewise, there was at least a 4.2): - Documentation is cleaned up and edited some more. Almost everywhere that the name "UNIX" occurs, it has been replaced with some variation on "The UNIX System" with a capital S. This is lower case in my 5.0 manual which I have not combed for differences with System V yet. Still, the "system" following is standard by 5.0 it seems. This is right around the time of dashing Bell associations too, so variations of this manual exist with and without the Bell logo on the front, and with varying degrees of modification to explain the legal landscape involved. - Section 3 in particular sees a pretty significant rewrite effort. This coincides with MR 1055 here: https://archive.org/details/unix-system-release-description-system-v/I%20-%… - A new portable archive format is introduced. By the sounds of it, this introduces a new header type into the ar(4) format. - A new 1024-block filesystem is introduced, along with necessary support. - A new synchronous terminal interface is added. - VAX is supported by SGS/COFF now. Additional platforms as suggested by formatting marks in the pages include: Basic-16, Bellmac 32, and 8086, in addition to the already supported 3B-20. Unknown whether these platforms found any support with USG releases. - ex(1) is added (along with vi(1) and edit(1)). There is also the se(1) editor which I don't know much about. - CB-init is added, shaking up the /etc/inittab format and many login-related features. MAUS also steps in from CB for shared memory on PDP-11. - Added pages include asa(1), convert(1), cpp(1), edit(1), ex(1), fsplit(1), ipcrm(1), machid(1), makekey(1), net(1c), nscstat(1c), nsctorje(1c), nusend(1c), scat(1), se(1), stlogin(1), ststat(1), vi(1), maus(2), clock(3c), dial(3c), erf(3m), getut(3c), matherr(3m), memory(3c), sputl(3x), ttyslot(3c), x25*(3c), filehdr(4), gettydefs(4), issue(4), linenum(4), reloc(4), scnhdr(4), syms(4) - Removed pages include vpmc(1c), vpmsave(1c), vpmset(1c), x25pvc(1c), fptrap(3x) That's all I've got. As time goes on I'll start documenting worthwhile tidbits in the Wiki. If there's any question of the contents of any of the pages, I'll happily consult the original and make corrections, and can scan any page to verify the contents if needed. I'll eventually be scanning the whole thing, just not right now. Feel free to open a pull request if you think something needs to change. - Matt G.

9 months, 1 week

Unix v7 vi

by KenUnix

Was work ever done for v7 Unix to support 'vi' when using a tek or vt05 terminal? And, is it available? Thanks, Ken -- WWL 📚

9 months, 1 week

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 February 2023