From woods at robohack.ca Tue Jul 1 06:23:54 2025 From: woods at robohack.ca (Greg A. Woods) Date: Mon, 30 Jun 2025 13:23:54 -0700 Subject: [TUHS] Old UNIX newsletters? In-Reply-To: References: Message-ID: At Sat, 28 Jun 2025 17:26:21 -0700, Tom Lyon wrote: Subject: [TUHS] Old UNIX newsletters? > > Anyone sitting on piles of old UNIX newsletters? I find they make for > fascinating reading. > I haven't found any online archives. Hmmm.... I've still got the troff sources for the UniForum Canada (nee /usr/group/cdn) newsletters ("README") I produced when I was the editor. These span July 1990 through February 1993. They were distributed to members in print form. There were some issues before my time, but I don't think I managed to even keep the printed copies of those. I suppose I could/should just wrap them in a tar and put it on my web server.... I'll have to sort out including the wrapper tmac file I used -- the primary macros were MM, but I adapted them for the newsletter with some additions and replacements. I though I had lost it, but it seems I did manage to keep everything, even including the SCCS files. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms From arnold at skeeve.com Tue Jul 1 07:25:55 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 30 Jun 2025 15:25:55 -0600 Subject: [TUHS] xview and open motif files Message-ID: <202506302125.55ULPtCv148436@freefriends.org> 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 From pugs78 at gmail.com Tue Jul 1 08:47:32 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Mon, 30 Jun 2025 15:47:32 -0700 Subject: [TUHS] Old UNIX newsletters? In-Reply-To: References: Message-ID: As promised, my scanned newsletters are here: https://drive.google.com/drive/folders/1su6vVa5vXe5FpI-4WB5AQyex_jS_t2XI?usp=sharing Warren, please fetch them. On Sat, Jun 28, 2025 at 5:26 PM Tom Lyon wrote: > 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuff at riddermarkfarm.ca Wed Jul 2 10:27:24 2025 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Tue, 1 Jul 2025 20:27:24 -0400 Subject: [TUHS] xview and open motif files In-Reply-To: <202506302125.55ULPtCv148436@freefriends.org> References: <202506302125.55ULPtCv148436@freefriends.org> Message-ID: <03813740-4884-edd3-32b9-ed40df49fbcd@riddermarkfarm.ca> On 2025-06-30 17:25, arnold at skeeve.com wrote: > 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/. "Forbidden You don't have permission to access this resource." S. > > 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 From amp1ron at gmail.com Wed Jul 2 11:33:56 2025 From: amp1ron at gmail.com (amp1ron at gmail.com) Date: Tue, 1 Jul 2025 21:33:56 -0400 Subject: [TUHS] xview and open motif files In-Reply-To: <03813740-4884-edd3-32b9-ed40df49fbcd@riddermarkfarm.ca> References: <202506302125.55ULPtCv148436@freefriends.org> <03813740-4884-edd3-32b9-ed40df49fbcd@riddermarkfarm.ca> Message-ID: <008401dbeaf1$748542f0$5d8fc8d0$@gmail.com> >> $ 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/. > > "Forbidden > > You don't have permission to access this resource." These worked for me: https://www.skeeve.com/X11/openmotif-2.3.0.tar.gz https://www.skeeve.com/X11/xvfc.tar.gz https://www.skeeve.com/X11/xview3.2.tar.gz From arnold at skeeve.com Wed Jul 2 21:30:30 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 02 Jul 2025 05:30:30 -0600 Subject: [TUHS] xview and open motif files In-Reply-To: <008401dbeaf1$748542f0$5d8fc8d0$@gmail.com> References: <202506302125.55ULPtCv148436@freefriends.org> <03813740-4884-edd3-32b9-ed40df49fbcd@riddermarkfarm.ca> <008401dbeaf1$748542f0$5d8fc8d0$@gmail.com> Message-ID: <202507021130.562BUUoV311185@freefriends.org> wrote: > >> $ 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/. > > > > "Forbidden > > > > You don't have permission to access this resource." > > These worked for me: > https://www.skeeve.com/X11/openmotif-2.3.0.tar.gz > https://www.skeeve.com/X11/xvfc.tar.gz > https://www.skeeve.com/X11/xview3.2.tar.gz > Yeah, apparently I need an index.html file in that directory, but you can just retrieve them directly. "Sorry about that, chief." Arnold From tuhs at tuhs.org Thu Jul 3 05:54:24 2025 From: tuhs at tuhs.org (Johan Helsingius via TUHS) Date: Wed, 2 Jul 2025 21:54:24 +0200 Subject: [TUHS] Old UNIX newsletters? In-Reply-To: References: Message-ID: On 29/06/2025 16:04, Jonathan Gray wrote: > as ukuug.org now links to casinos... Such a shame :( > EUUG Newsletter Vol 2, No 4 onwards scans at > https://datamuseum.dk/wiki/Bits:Keyword/PERIODICALS/EUUG-NEWSLETTER Thanks! I especially relish the copy of the EUUG Spring 1984 newsletter with the account of the Nijmegen meeting, where I submitted the membership application on behalf of the Finnish UNIX USers Group to join EUUG, and I first learned about the Blit/5620, Honey DanBer UUCP, and /proc, , as well as meeting Eric Allman, Kirk McKusick, Andy Hume, Jim McKie, Jaap Akkerhuis, Brian Redman, David Tilbrook, Andrew Hume, Nigel Martin, Mike Banahan, Teus Hagen and many more. Julf From arnold at skeeve.com Thu Jul 3 06:47:37 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 02 Jul 2025 14:47:37 -0600 Subject: [TUHS] Old UNIX newsletters? In-Reply-To: References: Message-ID: <202507022047.562KlbC6348331@freefriends.org> Johan Helsingius via TUHS wrote: > and /proc, , as well as meeting Eric Allman, Kirk McKusick, Andy Hume, > Jim McKie, Jaap Akkerhuis, Brian Redman, David Tilbrook, Andrew Hume, So which one of Andrew Hume and Andy Hume is the evil twin? :-) From dave at horsfall.org Thu Jul 3 08:31:38 2025 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 3 Jul 2025 08:31:38 +1000 (EST) Subject: [TUHS] Old UNIX newsletters? In-Reply-To: <202507022047.562KlbC6348331@freefriends.org> References: <202507022047.562KlbC6348331@freefriends.org> Message-ID: On Wed, 2 Jul 2025, arnold at skeeve.com wrote: > > Jim McKie, Jaap Akkerhuis, Brian Redman, David Tilbrook, Andrew Hume, > > So which one of Andrew Hume and Andy Hume is the evil twin? :-) I knew Andrew, but never heard him called Andy... -- Dave From andrew at humeweb.com Fri Jul 4 13:19:02 2025 From: andrew at humeweb.com (andrew at humeweb.com) Date: Thu, 3 Jul 2025 20:19:02 -0700 Subject: [TUHS] Old UNIX newsletters? In-Reply-To: <202507022047.562KlbC6348331@freefriends.org> References: <202507022047.562KlbC6348331@freefriends.org> Message-ID: both!! > On Jul 2, 2025, at 1:47 PM, arnold at skeeve.com wrote: > > Johan Helsingius via TUHS wrote: > >> and /proc, , as well as meeting Eric Allman, Kirk McKusick, Andy Hume, >> Jim McKie, Jaap Akkerhuis, Brian Redman, David Tilbrook, Andrew Hume, > > So which one of Andrew Hume and Andy Hume is the evil twin? :-) > From andrew at humeweb.com Fri Jul 4 13:21:22 2025 From: andrew at humeweb.com (andrew at humeweb.com) Date: Thu, 3 Jul 2025 20:21:22 -0700 Subject: [TUHS] Old UNIX newsletters? In-Reply-To: References: <202507022047.562KlbC6348331@freefriends.org> Message-ID: <81A43C60-9E6C-4812-9FCF-6E4DF1F6137E@humeweb.com> i had an uncle who went by “Andy”, so that may be why my parents called me andrew. i always asked to be called andrew, with only one failure: a 65 yr scottish english teacher in high school. i had enough sense to recognise i could not change him, so i lived with that for a year. > On Jul 2, 2025, at 3:31 PM, Dave Horsfall wrote: > > On Wed, 2 Jul 2025, arnold at skeeve.com wrote: > >>> Jim McKie, Jaap Akkerhuis, Brian Redman, David Tilbrook, Andrew Hume, >> >> So which one of Andrew Hume and Andy Hume is the evil twin? :-) > > I knew Andrew, but never heard him called Andy... > > -- Dave From fariborz.t at gmail.com Thu Jul 10 04:06:09 2025 From: fariborz.t at gmail.com (Skip Tavakkolian) Date: Wed, 9 Jul 2025 11:06:09 -0700 Subject: [TUHS] Other implementations of Alef? Message-ID: In the 2nd Edition Plan 9, in the Alef Language Reference Manual by Phil Winterbottom, the title of section 7 is "The Plan 9 Implementation". Were there other implementations? From crossd at gmail.com Thu Jul 10 11:01:16 2025 From: crossd at gmail.com (Dan Cross) Date: Wed, 9 Jul 2025 21:01:16 -0400 Subject: [TUHS] Other implementations of Alef? In-Reply-To: References: Message-ID: On Wed, Jul 9, 2025, 8:42 PM Skip Tavakkolian wrote: > In the 2nd Edition Plan 9, in the Alef Language Reference Manual by > Phil Winterbottom, the title of section 7 is "The Plan 9 > Implementation". Were there other implementations? > According to the Alef User's Guide, there was (at least) an implementation for Irix. https://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Jul 10 11:36:16 2025 From: robpike at gmail.com (Rob Pike) Date: Thu, 10 Jul 2025 11:36:16 +1000 Subject: [TUHS] Other implementations of Alef? In-Reply-To: References: Message-ID: Not at the time. -rob On Thu, Jul 10, 2025 at 5:02 AM Skip Tavakkolian wrote: > In the 2nd Edition Plan 9, in the Alef Language Reference Manual by > Phil Winterbottom, the title of section 7 is "The Plan 9 > Implementation". Were there other implementations? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Jul 11 00:40:32 2025 From: crossd at gmail.com (Dan Cross) Date: Thu, 10 Jul 2025 10:40:32 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) Message-ID: Folks, For those of you who were unable to attend, I took this photo yesterday, at the end of the closing remarks for ATC'25 in Boston: https://photos.app.goo.gl/tcaAFQgjGPn5s8Dh7 As most of you know, USENIX has sunsetted the conference, and this was the last time ATC will be run, though of course other USENIX conferences will continue in its place. But I wanted to be in the room as it ended, and I snapped this as everything was winding down, and am now sharing it with our community. For those of you who were able to attend, it was wonderful to see a number of familiar faces, and also meet some folks I've known of and interacted with here and elsewhere, face-to-face. USENIX also turned 50 this year, and the organization made sure to create space for reflection on its history; remembrances were shared by Clem Cole, Bill Cheswick, Doug McIlroy, Andrew Hume, Peter Honeyman, Tom Lyon, and others. On a personal note, I found this very meaningful: I was once told, "never meet your heroes." However, in the Unix community, by and large my heroes are wonderfully pleasant, generous, and kind people in real life, all of whom have either indirectly or directly had a profound influence on the course of my career and life. Thank you for that; it was an honor to share space with you. While ATC is ending, it is also clear that there is a vibrant research community flourishing, building on the legacy of work created by the USENIX community and shared through this conference. Many of you nurtured that community, laying its framework, shepherding and guiding its work, cultivating new generations of researchers while providing the basic tools we all depend on, and thus creating the fertile ground on which it now grows. What greater professional accomplishment could one hope for? Perhaps it is best not to think of this as an end, but an epoch marking the transition from one stage of the community's evolution to the next. - Dan C. From lm at mcvoy.com Fri Jul 11 02:19:43 2025 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 10 Jul 2025 09:19:43 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: Message-ID: <20250710161943.GM14377@mcvoy.com> Nice note, Dan. On Thu, Jul 10, 2025 at 10:40:32AM -0400, Dan Cross wrote: > On a personal note, I found this very meaningful: I was once told, > "never meet your heroes." However, in the Unix community, by and large > my heroes are wonderfully pleasant, generous, and kind people in real > life, all of whom have either indirectly or directly had a profound > influence on the course of my career and life. Thank you for that; it > was an honor to share space with you. I couldn't agree more. Starting with Dennis, everyone has been willing to share knowledge. I have a memory of Dennis having "handlers" at Usenix so one person wouldn't eat up all of his time. Much thanks to all those shoulders that lifted us up. --lm From clemc at ccc.com Fri Jul 11 05:47:38 2025 From: clemc at ccc.com (Clem Cole) Date: Thu, 10 Jul 2025 15:47:38 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250710161943.GM14377@mcvoy.com> References: <20250710161943.GM14377@mcvoy.com> Message-ID: On Thu, Jul 10, 2025 at 12:19 PM Larry McVoy wrote: > > I couldn't agree more. Starting with Dennis, everyone has been willing > to share knowledge. I have a memory of Dennis having "handlers" at > Usenix so one person wouldn't eat up all of his time. > That was not true, as much as the community might have intervened if we thought somebody was a little out of line.* i.e.*, we might have been protective of him. Dennis was really too nice to have said anything. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Fri Jul 11 06:04:54 2025 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Thu, 10 Jul 2025 15:04:54 -0500 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> Message-ID: On 7/10/2025 2:47 PM, Clem Cole wrote: > > > On Thu, Jul 10, 2025 at 12:19 PM Larry McVoy > wrote: > > > I couldn't agree more.  Starting with Dennis, everyone has been willing > to share knowledge.  I have a memory of Dennis having "handlers" at > Usenix so one person wouldn't eat up all of his time. > > That was not true, as much as the community might have intervened if we > thought somebody was a little out of line./i.e./, we might have been > protective of him. Dennis was really too nice to have said anything. The one time I spoke to Dennis, I went up to the lectern after he spoke somewhere, probably a USENIX Technical Conference, to shake his hand and thank him. As I recall, neither of us said much, no one else was nearby. -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From lm at mcvoy.com Fri Jul 11 06:12:46 2025 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 10 Jul 2025 13:12:46 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> Message-ID: <20250710201246.GN14377@mcvoy.com> On Thu, Jul 10, 2025 at 03:47:38PM -0400, Clem Cole wrote: > On Thu, Jul 10, 2025 at 12:19???PM Larry McVoy wrote: > > > > > I couldn't agree more. Starting with Dennis, everyone has been willing > > to share knowledge. I have a memory of Dennis having "handlers" at > > Usenix so one person wouldn't eat up all of his time. > > > That was not true, as much as the community might have intervened if we > thought somebody was a little out of line.* i.e.*, we might have been > protective of him. Dennis was really too nice to have said anything. Don't know what to say, Clem, we normally agree on everything. But I'm not making it up, I was there, waiting to talk to Dennis, someone else was talking to him and at some point someone intervened and moved the guy on. Maybe it was a one time thing, I dunno? Seemed like it wasn't the handler's first time doing that. Water under the bridge though. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From robpike at gmail.com Sat Jul 12 10:41:44 2025 From: robpike at gmail.com (Rob Pike) Date: Sat, 12 Jul 2025 10:41:44 +1000 Subject: [TUHS] Other implementations of Alef? In-Reply-To: References: Message-ID: I think that's the same implementation, just a port. We had SGI machines running Plan 9, and adjacent SGI machines running IRIX. -rob On Sat, Jul 12, 2025 at 9:17 AM Dan Cross wrote: > On Wed, Jul 9, 2025, 8:42 PM Skip Tavakkolian > wrote: > >> In the 2nd Edition Plan 9, in the Alef Language Reference Manual by >> Phil Winterbottom, the title of section 7 is "The Plan 9 >> Implementation". Were there other implementations? >> > > According to the Alef User's Guide, there was (at least) an implementation > for Irix. https://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ug > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sun Jul 13 04:37:28 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 12 Jul 2025 13:37:28 -0500 Subject: [TUHS] troff, Gremlin terminals, and the grn preprocessor Message-ID: <20250712183728.pnytio3rwl3hk7zg@illithid> Hi folks, I'm trying to clear up a historical matter. In reviewing groff's "LICENSES" file, I find myself stuck on the following paragraph. >grn, written by Barry Roitblat and David >Slattengren , was part of the Berkeley >troff distribution. The files contain no AT&T code >and are in the public domain. Historically, the original package could >be found at . I'm not sure about that reference to "Berkeley troff". I already deleted the modifier "device-independent" from that sentence because I've never seen even a whisper of evidence that the CSRG ever distributed Kernighan's device-independent troff; that was locked up behind AT&T's revenue-seeking aims. But also, I can't find evidence that "grn" was distributed by Berkeley at all. At Warren's "Unix Tree",[1] I see what looks superficially like evidence of support for Gremlin terminals in "libplot", but that's not the same thing. However there is evidence of support for grn, the troff preprocessor, in other unquestionable BSD artifacts, like Eric Allman's "me" package. Can someone clear up my misconceptions or suggest non-misleading alternative wording? Was the grn preprocessor one of these "USENIX tape" things, like nethack and jove? Regards, Branden [1] https://minnie.tuhs.org/cgi-bin/utree.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nobozo at gmail.com Sun Jul 13 05:14:05 2025 From: nobozo at gmail.com (Jon Forrest) Date: Sat, 12 Jul 2025 12:14:05 -0700 Subject: [TUHS] troff, Gremlin terminals, and the grn preprocessor In-Reply-To: <20250712183728.pnytio3rwl3hk7zg@illithid> References: <20250712183728.pnytio3rwl3hk7zg@illithid> Message-ID: <073fc2ae-2bf3-4dbc-8afd-264b9642930d@gmail.com> On 7/12/25 11:37 AM, G. Branden Robinson wrote: > I'm not sure about that reference to "Berkeley troff". Maybe Eric Allman can comment in detail. But, maybe it was part of the work that Prof. Mike Harrison and his research group in UCB CS did when they cracked the Adobe Postscript Type 1 format. This little-known fact was the first step in making Postscript Type 1 files an open format. Jon From ats at offog.org Sun Jul 13 09:28:30 2025 From: ats at offog.org (Adam Sampson) Date: Sun, 13 Jul 2025 00:28:30 +0100 Subject: [TUHS] Toronto's Numerical Turing compiler Message-ID: Hi TUHS, A poster on the Stardot Acorn forum asked whether the Numerical Turing compiler had survived. I figure this is probably the best place to ask. Numerical Turing was a mid-80s variant of the University of Toronto's Turing programme language that provided arbitrary-precision decimal float arithmetic, developed by Tom Hull and others. It's described in this paper: https://dl.acm.org/doi/abs/10.1145/1057947.1057949 It ran on Toronto's ai VAX under 4.2BSD. The paper mentions the compiler ntc and its man page, the demo program ntdemo.x, and the standard include directory /usr/include/nt. There are a few references to it in the utzoo Usenet archive but it looks like it was distributed upon request. Has anybody seen a surviving copy? Thanks, -- Adam Sampson From jsg at jsg.id.au Sun Jul 13 12:45:30 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 13 Jul 2025 12:45:30 +1000 Subject: [TUHS] troff, Gremlin terminals, and the grn preprocessor In-Reply-To: <20250712183728.pnytio3rwl3hk7zg@illithid> References: <20250712183728.pnytio3rwl3hk7zg@illithid> Message-ID: On Sat, Jul 12, 2025 at 01:37:28PM -0500, G. Branden Robinson wrote: > Hi folks, > > I'm trying to clear up a historical matter. > > In reviewing groff's "LICENSES" file, I find myself stuck on the > following paragraph. > > >grn, written by Barry Roitblat and David > >Slattengren , was part of the Berkeley > >troff distribution. The files contain no AT&T code > >and are in the public domain. Historically, the original package could > >be found at . > > I'm not sure about that reference to "Berkeley troff". I already > deleted the modifier "device-independent" from that sentence because > I've never seen even a whisper of evidence that the CSRG ever > distributed Kernighan's device-independent troff; that was locked up > behind AT&T's revenue-seeking aims. from the Berkeley manual: grn - ditroff preprocessor for gremlin files more on the Berkeley ditroff distribution below > > But also, I can't find evidence that "grn" was distributed by Berkeley > at all. At Warren's "Unix Tree",[1] I see what looks superficially like > evidence of support for Gremlin terminals in "libplot", but that's not > the same thing. > > However there is evidence of support for grn, the troff preprocessor, in > other unquestionable BSD artifacts, like Eric Allman's "me" package. > > Can someone clear up my misconceptions or suggest non-misleading > alternative wording? grn(1) can be found in CD 4 of the CSRG archives. Along with various .grn files. from tuhs Documentation/CSRG_CDs/csrg_ls.gz: -r--r--r-- 1 root root 5757 May 9 1984 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/docs/grn.1 -r--r--r-- 1 root root 356 Jul 5 1995 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/.MAP -r--r--r-- 1 root root 468 Dec 27 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/Makefile -r--r--r-- 1 root root 235 Jul 5 1995 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/.MAP -r--r--r-- 1 root root 2037 Oct 8 1984 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/s.gprint.h -r--r--r-- 1 root root 9899 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/s.hdb.c -r--r--r-- 1 root root 19497 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/s.hgraph.c -r--r--r-- 1 root root 1028 Oct 8 1984 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/s.hpoint.c -r--r--r-- 1 root root 40419 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/s.main.c -r--r--r-- 1 root root 1228 Nov 11 1985 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/dev.h -r--r--r-- 1 root root 1904 Dec 7 1984 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/gprint.h -r--r--r-- 1 root root 5677 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/hdb.c -r--r--r-- 1 root root 10982 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/hgraph.c -r--r--r-- 1 root root 895 Dec 7 1984 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/hpoint.c -r--r--r-- 1 root root 22630 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/main.c -r--r--r-- 1 root root 5757 May 9 1984 CSRG/disk4/local/ditroff/ditroff.old.van/docs/grn.1 -r--r--r-- 1 root root 314 Jul 5 1995 CSRG/disk4/local/ditroff/ditroff.old.van/grn/.MAP -r--r--r-- 1 root root 468 Dec 27 1986 CSRG/disk4/local/ditroff/ditroff.old.van/grn/Makefile -r--r--r-- 1 root root 1228 Nov 11 1985 CSRG/disk4/local/ditroff/ditroff.old.van/grn/dev.h -r--r--r-- 1 root root 1904 Dec 7 1984 CSRG/disk4/local/ditroff/ditroff.old.van/grn/gprint.h -r--r--r-- 1 root root 5677 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.van/grn/hdb.c -r--r--r-- 1 root root 10982 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.van/grn/hgraph.c -r--r--r-- 1 root root 895 Dec 7 1984 CSRG/disk4/local/ditroff/ditroff.old.van/grn/hpoint.c -r--r--r-- 1 root root 22630 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.van/grn/main.c -r--r--r-- 1 root root 5757 Oct 10 1986 CSRG/disk4/local/man/man1/grn.1 The SCCS logs start in 1983, authored by slatteng. The troff preprocessor is also mentioned in Mark Opperman, Jim Thompson, Yih-Farn Chen A Gremlin Tutorial for the SUN Workstation UCB/CSD 322 https://www2.eecs.berkeley.edu/Pubs/TechRpts/1987/CSD-87-322.pdf "1.1 GREMLIN History GREMLIN's legacy encompasses more than five years and a half-dozen Berkeley graduate students. It all started in 1981 when Barry Roitblat built the first version of GREMLIN for his Master's project. That version ran only on AED color displays, and its output could be printed only on Versatec printers. In order to include figures in typeset documents, they had to be cut-and-pasted. In 1983, Dave Slattengren (another graduate student at UCB) acquired from AT&T the sources to Brian Kernighan's new DITROFF program. In addition to making the program work under 4.2 BSD and building drivers for several printers, he wrote GRN, which reads files in GREMLIN format and generates DITROFF commands to print the pictures in-inline in documents. ... 1.2 Distribution of GREMLIN GREMLIN is distributed free of charge by the University of California, Berkeley, along with a modified version of the DITROFF typesetting system which allows GREMLIN pictures to be printed in-line in documents. To find out more about the GREMLIN/DITROFF distribution, including the AT&T licenses required to receive it, write to:" From g.branden.robinson at gmail.com Sun Jul 13 13:01:47 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 12 Jul 2025 22:01:47 -0500 Subject: [TUHS] troff, Gremlin terminals, and the grn preprocessor In-Reply-To: References: <20250712183728.pnytio3rwl3hk7zg@illithid> Message-ID: <20250713030147.nngb2u75pnrz55hi@illithid> Hi Jonathan, At 2025-07-13T12:45:30+1000, Jonathan Gray wrote: > > I'm not sure about that reference to "Berkeley troff". I already > > deleted the modifier "device-independent" from that sentence because > > I've never seen even a whisper of evidence that the CSRG ever > > distributed Kernighan's device-independent troff; that was locked up > > behind AT&T's revenue-seeking aims. > > from the Berkeley manual: ...which one? Is the one you're referencing archived at minnie? Or do you mean the man page listed below as "grn.1"? > grn - ditroff preprocessor for gremlin files > > more on the Berkeley ditroff distribution below Indeed! I knew about vtroff but not about a Berkeley fork of Kernighan troff. This is significant news to me, and adds a whole new branch onto the troff family tree in my head. > grn(1) can be found in CD 4 of the CSRG archives. > Along with various .grn files. > > from tuhs Documentation/CSRG_CDs/csrg_ls.gz: > > -r--r--r-- 1 root root 5757 May 9 1984 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/docs/grn.1 > -r--r--r-- 1 root root 356 Jul 5 1995 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/.MAP > -r--r--r-- 1 root root 468 Dec 27 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/Makefile > -r--r--r-- 1 root root 235 Jul 5 1995 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/.MAP > -r--r--r-- 1 root root 2037 Oct 8 1984 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/s.gprint.h > -r--r--r-- 1 root root 9899 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/s.hdb.c > -r--r--r-- 1 root root 19497 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/s.hgraph.c > -r--r--r-- 1 root root 1028 Oct 8 1984 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/s.hpoint.c > -r--r--r-- 1 root root 40419 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/SCCS/s.main.c > -r--r--r-- 1 root root 1228 Nov 11 1985 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/dev.h > -r--r--r-- 1 root root 1904 Dec 7 1984 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/gprint.h > -r--r--r-- 1 root root 5677 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/hdb.c > -r--r--r-- 1 root root 10982 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/hgraph.c > -r--r--r-- 1 root root 895 Dec 7 1984 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/hpoint.c > -r--r--r-- 1 root root 22630 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.okeeffe/grn/main.c > -r--r--r-- 1 root root 5757 May 9 1984 CSRG/disk4/local/ditroff/ditroff.old.van/docs/grn.1 > -r--r--r-- 1 root root 314 Jul 5 1995 CSRG/disk4/local/ditroff/ditroff.old.van/grn/.MAP > -r--r--r-- 1 root root 468 Dec 27 1986 CSRG/disk4/local/ditroff/ditroff.old.van/grn/Makefile > -r--r--r-- 1 root root 1228 Nov 11 1985 CSRG/disk4/local/ditroff/ditroff.old.van/grn/dev.h > -r--r--r-- 1 root root 1904 Dec 7 1984 CSRG/disk4/local/ditroff/ditroff.old.van/grn/gprint.h > -r--r--r-- 1 root root 5677 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.van/grn/hdb.c > -r--r--r-- 1 root root 10982 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.van/grn/hgraph.c > -r--r--r-- 1 root root 895 Dec 7 1984 CSRG/disk4/local/ditroff/ditroff.old.van/grn/hpoint.c > -r--r--r-- 1 root root 22630 Apr 14 1986 CSRG/disk4/local/ditroff/ditroff.old.van/grn/main.c > -r--r--r-- 1 root root 5757 Oct 10 1986 CSRG/disk4/local/man/man1/grn.1 I didn't think to look there. > The SCCS logs start in 1983, authored by slatteng. > > The troff preprocessor is also mentioned in > > Mark Opperman, Jim Thompson, Yih-Farn Chen > A Gremlin Tutorial for the SUN Workstation > UCB/CSD 322 > https://www2.eecs.berkeley.edu/Pubs/TechRpts/1987/CSD-87-322.pdf > > "1.1 GREMLIN History > GREMLIN's legacy encompasses more than five years and a half-dozen > Berkeley graduate students. It all started in 1981 when Barry Roitblat > built the first version of GREMLIN for his Master's project. That > version ran only on AED color displays, and its output could be printed > only on Versatec printers. In order to include figures in typeset > documents, they had to be cut-and-pasted. In 1983, Dave Slattengren > (another graduate student at UCB) acquired from AT&T the sources to > Brian Kernighan's new DITROFF program. In addition to making the > program work under 4.2 BSD and building drivers for several printers, > he wrote GRN, which reads files in GREMLIN format and generates > DITROFF commands to print the pictures in-inline in documents. > ... > 1.2 Distribution of GREMLIN > GREMLIN is distributed free of charge by the University of California, > Berkeley, along with a modified version of the DITROFF typesetting > system which allows GREMLIN pictures to be printed in-line in documents. > To find out more about the GREMLIN/DITROFF distribution, including the > AT&T licenses required to receive it, write to:" This sheds a lot of light. Thanks! Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jsg at jsg.id.au Sun Jul 13 14:55:56 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 13 Jul 2025 14:55:56 +1000 Subject: [TUHS] troff, Gremlin terminals, and the grn preprocessor In-Reply-To: <20250713030147.nngb2u75pnrz55hi@illithid> References: <20250712183728.pnytio3rwl3hk7zg@illithid> <20250713030147.nngb2u75pnrz55hi@illithid> Message-ID: On Sat, Jul 12, 2025 at 10:01:47PM -0500, G. Branden Robinson wrote: > Hi Jonathan, > > At 2025-07-13T12:45:30+1000, Jonathan Gray wrote: > > > I'm not sure about that reference to "Berkeley troff". I already > > > deleted the modifier "device-independent" from that sentence because > > > I've never seen even a whisper of evidence that the CSRG ever > > > distributed Kernighan's device-independent troff; that was locked up > > > behind AT&T's revenue-seeking aims. > > > > from the Berkeley manual: > > ...which one? Is the one you're referencing archived at minnie? > > Or do you mean the man page listed below as "grn.1"? CD4 local/man/man1/grn.1 seems to be the same text as http://man.bsd.lv/4.4BSD-Lite2/grn.1 (it is not part of 4.4BSD-Lite2) > > > grn - ditroff preprocessor for gremlin files > > > > more on the Berkeley ditroff distribution below > > Indeed! I knew about vtroff but not about a Berkeley fork of Kernighan > troff. This is significant news to me, and adds a whole new branch onto > the troff family tree in my head. James Clark referred to it as BSD ditroff and goes on to comment on how groff didn't use some of the BSD extensions in a Sep 30, 1991 post to comp.text: https://groups.google.com/g/comp.text/c/OBd9K9hEPSE/m/adTHd_3O434J A Dec 12, 1984 post to net.text called it ditroff gremlin: https://groups.google.com/g/net.text/c/nVeNpNAHxP0/m/Ea2bLUJEnjkJ John Ousterhout, the UCB contact mentioned, led the research group that did Sprite. grn(1) was also included in Sprite. From tuhs at tuhs.org Wed Jul 16 05:10:36 2025 From: tuhs at tuhs.org (Johan Helsingius via TUHS) Date: Tue, 15 Jul 2025 21:10:36 +0200 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> Message-ID: On 10/07/2025 21:47, Clem Cole wrote: > That was not true, as much as the community might have intervened if we > thought somebody was a little out of line./i.e./, we might have been > protective of him. Dennis was really too nice to have said anything. I remember one of the EUUG conferences long, long ago, where a bunch of us stood talking. One of us was wearing a T-shirt with the famous "You are not expected to understand this" V6 code on it. A young (Austrian, if I remember correctly) academic guy came up to us and said "I understand what it does - do you?". Dennis, who was wearing the shirt, just said "Yes, I wrote it" with a light smile and the warm, friendly tone he so often had. Julf From ggm at algebras.org Wed Jul 16 09:39:49 2025 From: ggm at algebras.org (George Michaelson) Date: Wed, 16 Jul 2025 09:39:49 +1000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> Message-ID: I've reached the stage of incompetency where if I can remember what a logarithm IS, It's a good day, and if I can remember why you use them it's a stellar day. I'd put it on a tee shirt but I have to work out which is the skinside and which is the outside first. Used to be the seams and fruit-of-the-loom/union-made label told you but now people wear seams as a badge of pride and labels are outré -G -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther.johnson at makerlisp.com Wed Jul 16 10:01:15 2025 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Tue, 15 Jul 2025 17:01:15 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> Message-ID: <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> I just noticed that algorithm and logarithm just have a couple of letters transposed from each other. So that's the kind of rabbit hole I get lost in most days. On 07/15/2025 04:39 PM, George Michaelson wrote: > I've reached the stage of incompetency where if I can remember what a > logarithm IS, It's a good day, and if I can remember why you use them > it's a stellar day. I'd put it on a tee shirt but I have to work out > which is the skinside and which is the outside first. Used to be the > seams and fruit-of-the-loom/union-made label told you but now people > wear seams as a badge of pride and labels are outré > > -G From tuhs at tuhs.org Wed Jul 16 21:13:24 2025 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 16 Jul 2025 11:13:24 +0000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> Message-ID: Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around a month ago and no sign of me finding my way back out any time soon. I got obsessed with getting ed running on every device I have including my phones and then the big rabbit hole off that first one was learning how to use it properly and to the fullest of its abilities. That'll take a while. My library of ed related publications is getting so big its likely what's blocking the exit to the rabbit hole. On the plus side it has sharpened my typing skills, improved my patience and I I've learned to work out for myself what I've done to cause ed to say ?, instead of just typing h+Enter. As rabbit holes go, it's been stimulating so far and I could be stuck in worse places. Have a safe one! Cameron -------- Original Message -------- On 16/07/2025 01:01, Luther Johnson wrote: > I just noticed that algorithm and logarithm just have a couple of > letters transposed from each other. So that's the kind of rabbit hole I > get lost in most days. > From norman at oclsc.org Wed Jul 16 21:54:09 2025 From: norman at oclsc.org (Norman Wilson) Date: Wed, 16 Jul 2025 07:54:09 -0400 (EDT) Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) Message-ID: Cameron_M????e??l_Tyre_via_TUHS: I got obsessed with getting ed running on every device I have including my phones and then the big rabbit hole off that first one was learning how to use it properly and to the fullest of its abilities. == Of course. ed(1) is the standard editor. Norman Wilson Toronto ON From arnold at skeeve.com Wed Jul 16 22:09:00 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 16 Jul 2025 06:09:00 -0600 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> Message-ID: <202507161209.56GC90Iu580454@freefriends.org> IMHO, the best tutorials on ed are the chapters in "Software Tools" and "Software Tools in Pascal" where Kernighan and Plauger write a basic version of it. I recommend both books highly, despite their age. "Software Tools" literally changed my life. :-) Arnold Cameron Míċeál Tyre via TUHS wrote: > Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around > a month ago and no sign of me finding my way back out any time soon. > > I got obsessed with getting ed running on every device I have including my > phones and then the big rabbit hole off that first one was learning how to > use it properly and to the fullest of its abilities. That'll take a while. > > My library of ed related publications is getting so big its likely > what's blocking the exit to the rabbit hole. On the plus side it has > sharpened my typing skills, improved my patience and I I've learned to > work out for myself what I've done to cause ed to say ?, instead of just > typing h+Enter. > > As rabbit holes go, it's been stimulating so far and I could be stuck > in worse places. > > Have a safe one! > > Cameron > > > -------- Original Message -------- > On 16/07/2025 01:01, Luther Johnson wrote: > > > I just noticed that algorithm and logarithm just have a couple of > > letters transposed from each other. So that's the kind of rabbit hole I > > get lost in most days. > > > From brantley at coraid.com Wed Jul 16 22:53:26 2025 From: brantley at coraid.com (Brantley Coile) Date: Wed, 16 Jul 2025 12:53:26 +0000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <202507161209.56GC90Iu580454@freefriends.org> References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <202507161209.56GC90Iu580454@freefriends.org> Message-ID: <22F48CBE-C882-4C2A-ABD5-A095D61F8490@coraid.com> Behind the glass wall in the basement of the University of Georgia graduate studies building, was the wide floor of the computer center and behind that was the office of one of my mentors, Bob Stearms. As he typed PL/1 into his 3278 terminal--channel connected no less--I spied a plain white book sitting on a shelf in his book case with an orange title "SOFTWARE TOOLS." I picked it up and flipped through it. It was 1980, the first year of my marriage. "What's this?", I asked as I pick up the volume and started flipping through it. "It's from the Unix guys. They wrote a pre-processor for FORTRAN and called it Ratfor. Then they wrote a bunch of the Unix programs in it." "Can I borrow it?" "Sure." I changed my life. I still use what I learned from it forty-five years later. And still very happily married to the bride of my youth. After Bob passed away, Frieda gave me that volume. It's one of my prized possessions. Forget Unix and C. The biggest research achievement to come out of 1127 was a clear understanding of how to program. Brantley > On Jul 16, 2025, at 8:09 AM, arnold at skeeve.com wrote: > > IMHO, the best tutorials on ed are the chapters in "Software Tools" > and "Software Tools in Pascal" where Kernighan and Plauger write > a basic version of it. I recommend both books highly, despite > their age. > > "Software Tools" literally changed my life. :-) > > Arnold > > Cameron Míċeál Tyre via TUHS wrote: > >> Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around >> a month ago and no sign of me finding my way back out any time soon. >> >> I got obsessed with getting ed running on every device I have including my >> phones and then the big rabbit hole off that first one was learning how to >> use it properly and to the fullest of its abilities. That'll take a while. >> >> My library of ed related publications is getting so big its likely >> what's blocking the exit to the rabbit hole. On the plus side it has >> sharpened my typing skills, improved my patience and I I've learned to >> work out for myself what I've done to cause ed to say ?, instead of just >> typing h+Enter. >> >> As rabbit holes go, it's been stimulating so far and I could be stuck >> in worse places. >> >> Have a safe one! >> >> Cameron >> >> >> -------- Original Message -------- >> On 16/07/2025 01:01, Luther Johnson wrote: >> >>> I just noticed that algorithm and logarithm just have a couple of >>> letters transposed from each other. So that's the kind of rabbit hole I >>> get lost in most days. >>> >> From tuhs at tuhs.org Thu Jul 17 03:45:12 2025 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 16 Jul 2025 17:45:12 +0000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <202507161209.56GC90Iu580454@freefriends.org> References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <202507161209.56GC90Iu580454@freefriends.org> Message-ID: Hello Arnold, Thank you, sir. I have "Software Tools In Pascal" and am hopeful that I will soon get asked if I have anything I want for my upcoming birthday. "Software Tools" will be my answer. Your commment about the age of these books is something I concur with. I find them easier to read and understand than many modern publications. The one modern publication that I have found to be both fun and easy to read is Michael W. Lucas's "Ed Mastery" which has been written with a sense of humor not present in many software books. Best regards, Cameron On Wednesday, July 16th, 2025 at 1:09 PM, arnold at skeeve.com wrote: > > > IMHO, the best tutorials on ed are the chapters in "Software Tools" > and "Software Tools in Pascal" where Kernighan and Plauger write > a basic version of it. I recommend both books highly, despite > their age. > > "Software Tools" literally changed my life. :-) > > Arnold From tuhs at tuhs.org Thu Jul 17 04:11:32 2025 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 16 Jul 2025 18:11:32 +0000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <22F48CBE-C882-4C2A-ABD5-A095D61F8490@coraid.com> References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <202507161209.56GC90Iu580454@freefriends.org> <22F48CBE-C882-4C2A-ABD5-A095D61F8490@coraid.com> Message-ID: <6Zg2Iv44D-qUyeeooCweK3CeR3NzZ9wpnTogTh1geKF0C2JdlBOJoiYao7NC9k6uPwHe3eroMkttI304Z1X0Ub4l8_U6LW1tfz3QOsLMBVE=@protonmail.ch> Hello Brantley, Really enjoyed reading your recollections, thank you! I guess, if no-one asks me if there's anything I want for my upcoming birthday, I will get hold of a copy of "Software Tools" myself. I found a list of former members of 1127 which includes where many of them went to afterward: http://spinroot.com/gerard/1127_alumni.html It makes interesting reading, at least for a newcomer like me. Best regards, Cameron On Wednesday, July 16th, 2025 at 1:53 PM, Brantley Coile wrote: > > > Behind the glass wall in the basement of the University of Georgia graduate studies building, was the wide floor of the computer center and behind that was the office of one of my mentors, Bob Stearms. As he typed PL/1 into his 3278 terminal--channel connected no less--I spied a plain white book sitting on a shelf in his book case with an orange title "SOFTWARE TOOLS." I picked it up and flipped through it. It was 1980, the first year of my marriage. > > "What's this?", I asked as I pick up the volume and started flipping through it. > > "It's from the Unix guys. They wrote a pre-processor for FORTRAN and called it Ratfor. Then they wrote a bunch of the Unix programs in it." > > "Can I borrow it?" > > "Sure." > > I changed my life. I still use what I learned from it forty-five years later. And still very happily married to the bride of my youth. > > After Bob passed away, Frieda gave me that volume. It's one of my prized possessions. > > Forget Unix and C. The biggest research achievement to come out of 1127 was a clear understanding of how to program. > > Brantley From clemc at ccc.com Thu Jul 17 04:15:46 2025 From: clemc at ccc.com (Clem Cole) Date: Wed, 16 Jul 2025 14:15:46 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <202507161209.56GC90Iu580454@freefriends.org> Message-ID: On Wed, Jul 16, 2025 at 1:45 PM Cameron Míċeál Tyre via TUHS wrote: > Hello Arnold, > > Thank you, sir. I have "Software Tools In Pascal" and am hopeful that I > will > soon get asked if I have anything I want for my upcoming birthday. > "Software > Tools" will be my answer. Note I have both editions in print, but for those that want to just read them, PDF's of both are available in the wild: - https://www.crystallabs.io/unix-books-papers-videos/Software-Tools.pdf - https://seriouscomputerist.atariverse.com/media/pdf/book/Software%20Tools%20in%20Pascal.pdf Your commment about the age of these books is > something I concur with. I find them easier to read and understand than > many > modern publications. > Indeed -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Jul 17 04:24:11 2025 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Wed, 16 Jul 2025 18:24:11 +0000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <202507161209.56GC90Iu580454@freefriends.org> Message-ID: Hello Clem, Thank you for those URLs. PDF versions are a great back-up if the printed version goes missing or you need to refer to a book but don't have it with you. Best regards, Cameron On Wednesday, July 16th, 2025 at 7:16 PM, Clem Cole wrote, in part: > > > Note I have both editions in print, but for those that want to just read them, PDF's of both are available in the wild: > > - https://www.crystallabs.io/unix-books-papers-videos/Software-Tools.pdf > - https://seriouscomputerist.atariverse.com/media/pdf/book/Software%20Tools%20in%20Pascal.pdf From noel.hunt at gmail.com Thu Jul 17 07:59:38 2025 From: noel.hunt at gmail.com (Noel Hunt) Date: Thu, 17 Jul 2025 07:59:38 +1000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <22F48CBE-C882-4C2A-ABD5-A095D61F8490@coraid.com> References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <202507161209.56GC90Iu580454@freefriends.org> <22F48CBE-C882-4C2A-ABD5-A095D61F8490@coraid.com> Message-ID: Seventh Edition Unix came with a program 'learn', written by Brian Kernighan, which was a front-end to a group of tutorials on 'ed', 'tbl', 'troff' etc. The 'ed' tutorial was a wonderful introduction to the editor, and a model of clarity, as indeed they all were, but that was typical of everything written by researchers who were at 1127. On Wed, 16 Jul 2025 at 22:53, Brantley Coile wrote: > Behind the glass wall in the basement of the University of Georgia > graduate studies building, was the wide floor of the computer center and > behind that was the office of one of my mentors, Bob Stearms. As he typed > PL/1 into his 3278 terminal--channel connected no less--I spied a plain > white book sitting on a shelf in his book case with an orange title > "SOFTWARE TOOLS." I picked it up and flipped through it. It was 1980, the > first year of my marriage. > > "What's this?", I asked as I pick up the volume and started flipping > through it. > > "It's from the Unix guys. They wrote a pre-processor for FORTRAN and > called it Ratfor. Then they wrote a bunch of the Unix programs in it." > > "Can I borrow it?" > > "Sure." > > I changed my life. I still use what I learned from it forty-five years > later. And still very happily married to the bride of my youth. > > After Bob passed away, Frieda gave me that volume. It's one of my prized > possessions. > > Forget Unix and C. The biggest research achievement to come out of 1127 > was a clear understanding of how to program. > > Brantley > > > On Jul 16, 2025, at 8:09 AM, arnold at skeeve.com wrote: > > > > IMHO, the best tutorials on ed are the chapters in "Software Tools" > > and "Software Tools in Pascal" where Kernighan and Plauger write > > a basic version of it. I recommend both books highly, despite > > their age. > > > > "Software Tools" literally changed my life. :-) > > > > Arnold > > > > Cameron Míċeál Tyre via TUHS wrote: > > > >> Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole > around > >> a month ago and no sign of me finding my way back out any time soon. > >> > >> I got obsessed with getting ed running on every device I have including > my > >> phones and then the big rabbit hole off that first one was learning how > to > >> use it properly and to the fullest of its abilities. That'll take a > while. > >> > >> My library of ed related publications is getting so big its likely > >> what's blocking the exit to the rabbit hole. On the plus side it has > >> sharpened my typing skills, improved my patience and I I've learned to > >> work out for myself what I've done to cause ed to say ?, instead of just > >> typing h+Enter. > >> > >> As rabbit holes go, it's been stimulating so far and I could be stuck > >> in worse places. > >> > >> Have a safe one! > >> > >> Cameron > >> > >> > >> -------- Original Message -------- > >> On 16/07/2025 01:01, Luther Johnson > wrote: > >> > >>> I just noticed that algorithm and logarithm just have a couple of > >>> letters transposed from each other. So that's the kind of rabbit hole I > >>> get lost in most days. > >>> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jul 17 09:57:54 2025 From: clemc at ccc.com (Clem Cole) Date: Wed, 16 Jul 2025 19:57:54 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <202507161209.56GC90Iu580454@freefriends.org> <22F48CBE-C882-4C2A-ABD5-A095D61F8490@coraid.com> Message-ID: On Wed, Jul 16, 2025 at 6:00 PM Noel Hunt wrote: > Seventh Edition Unix came with a program 'learn', written by > Brian Kernighan, which was a front-end to a group of tutorials > on 'ed', 'tbl', 'troff' etc. > It's also been on bwk's web site. https://web.archive.org/web/20080921164132/http://cm.bell-labs.com/cm/cs/who/bwk/ Scroll down for "learn" -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Jul 17 19:58:43 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 17 Jul 2025 03:58:43 -0600 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <202507161209.56GC90Iu580454@freefriends.org> Message-ID: <202507170958.56H9wiDp678796@freefriends.org> You're welcome. I was unaware of the Lucas book. There seem to be two editions on Amazon. Cameron Míċeál Tyre via TUHS wrote: > Hello Arnold, > > Thank you, sir. I have "Software Tools In Pascal" and am hopeful that I will > soon get asked if I have anything I want for my upcoming birthday. "Software > Tools" will be my answer. Your commment about the age of these books is > something I concur with. I find them easier to read and understand than many > modern publications. The one modern publication that I have found to be both > fun and easy to read is Michael W. Lucas's "Ed Mastery" which has been written > with a sense of humor not present in many software books. > > Best regards, > > Cameron > > > On Wednesday, July 16th, 2025 at 1:09 PM, arnold at skeeve.com wrote: > > > > > > > IMHO, the best tutorials on ed are the chapters in "Software Tools" > > and "Software Tools in Pascal" where Kernighan and Plauger write > > a basic version of it. I recommend both books highly, despite > > their age. > > > > "Software Tools" literally changed my life. :-) > > > > Arnold From arnold at skeeve.com Thu Jul 17 20:01:55 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 17 Jul 2025 04:01:55 -0600 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <202507161209.56GC90Iu580454@freefriends.org> Message-ID: <202507171001.56HA1trJ679016@freefriends.org> Technically speaking, the PDFs are bootleg, illegal copies. Bear that in mind if you download them. Arnold Clem Cole wrote: > On Wed, Jul 16, 2025 at 1:45 PM Cameron Míċeál Tyre via TUHS > wrote: > > > Hello Arnold, > > > > Thank you, sir. I have "Software Tools In Pascal" and am hopeful that I > > will > > soon get asked if I have anything I want for my upcoming birthday. > > "Software > > Tools" will be my answer. > > > Note I have both editions in print, but for those that want to just read > them, PDF's of both are available in the wild: > > - https://www.crystallabs.io/unix-books-papers-videos/Software-Tools.pdf > - > https://seriouscomputerist.atariverse.com/media/pdf/book/Software%20Tools%20in%20Pascal.pdf > > Your commment about the age of these books is > > something I concur with. I find them easier to read and understand than > > many > > modern publications. > > > Indeed From clemc at ccc.com Fri Jul 18 00:03:26 2025 From: clemc at ccc.com (Clem Cole) Date: Thu, 17 Jul 2025 10:03:26 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <202507171001.56HA1trJ679016@freefriends.org> References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <202507161209.56GC90Iu580454@freefriends.org> <202507171001.56HA1trJ679016@freefriends.org> Message-ID: On Thu, Jul 17, 2025 at 6:01 AM wrote: > Technically speaking, the PDFs are bootleg, > Most anything you find on the internet through a search engine may often be of hazy provenance. That said, I am under the impression from a couple of the authors that both books were released as PDFs, along with several other books in the PH library from that series. I was given a number of them as PDFs by their editors at PH, although I have never shared the ones I received, as I was never told that I could. That said, I did an Internet search for these URLs, and Arnold offers wise counsel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Jul 18 03:06:03 2025 From: will.senn at gmail.com (Will Senn) Date: Thu, 17 Jul 2025 12:06:03 -0500 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> Message-ID: <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> I heart ed and it's cousin, vi. After poring through the v6 manual and tutorial, I started loving ed. I ditched vim a while back and embraced nvi (berkeley's modern basic vi/ex). Very simple, very basic, extremely powerful, none of the bloat - basically heirloom with a few refinements. Will On 7/16/25 06:13, Cameron Míċeál Tyre via TUHS wrote: > Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around a month ago and no sign of me finding my way back out any time soon. > > I got obsessed with getting ed running on every device I have including my phones and then the big rabbit hole off that first one was learning how to use it properly and to the fullest of its abilities. That'll take a while. > > My library of ed related publications is getting so big its likely what's blocking the exit to the rabbit hole. On the plus side it has sharpened my typing skills, improved my patience and I I've learned to work out for myself what I've done to cause ed to say ?, instead of just typing h+Enter. > > As rabbit holes go, it's been stimulating so far and I could be stuck in worse places. > > Have a safe one! > > Cameron > > > -------- Original Message -------- > On 16/07/2025 01:01, Luther Johnson wrote: > >> I just noticed that algorithm and logarithm just have a couple of >> letters transposed from each other. So that's the kind of rabbit hole I >> get lost in most days. >> From will.senn at gmail.com Fri Jul 18 03:08:07 2025 From: will.senn at gmail.com (Will Senn) Date: Thu, 17 Jul 2025 12:08:07 -0500 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <202507161209.56GC90Iu580454@freefriends.org> <22F48CBE-C882-4C2A-ABD5-A095D61F8490@coraid.com> Message-ID: <896431e2-c7b8-494e-9c38-947bbfb9f43b@gmail.com> Learn's great and it's "easy" to get working in SimH. I included it in my tutorial: https://decuser.github.io/unix/research-unix/v7/2024/05/23/research-unix-v7-3.2.html Will On 7/16/25 16:59, Noel Hunt wrote: > Seventh Edition Unix came with a program 'learn', written by > Brian Kernighan, which was a front-end to a group of tutorials > on 'ed', 'tbl', 'troff' etc. > > The 'ed' tutorial was a wonderful introduction to the editor, > and a model of clarity, as indeed they all were, but that was > typical of everything written by researchers who were at 1127. > > On Wed, 16 Jul 2025 at 22:53, Brantley Coile wrote: > > Behind the glass wall in the basement of the University of Georgia > graduate studies building, was the wide floor of the computer > center and behind that was the office of one of my mentors, Bob > Stearms. As he typed PL/1 into his 3278 terminal--channel > connected no less--I spied a plain white book sitting on a shelf > in his book case with an orange title "SOFTWARE TOOLS." I picked > it up and flipped through it. It was 1980, the first year of my > marriage. > > "What's this?", I asked as I pick up the volume and started > flipping through it. > > "It's from the Unix guys. They wrote a pre-processor for FORTRAN > and called it Ratfor. Then they wrote a bunch of the Unix programs > in it." > > "Can I borrow it?" > > "Sure." > > I changed my life. I still use what I learned from it forty-five > years later. And still very happily married to the bride of my youth. > > After Bob passed away, Frieda gave me that volume. It's one of my > prized possessions. > > Forget Unix and C. The biggest research achievement to come out of > 1127 was a clear understanding of how to program. > > Brantley > > > On Jul 16, 2025, at 8:09 AM, arnold at skeeve.com wrote: > > > > IMHO, the best tutorials on ed are the chapters in "Software Tools" > > and "Software Tools in Pascal" where Kernighan and Plauger write > > a basic version of it.  I recommend both books highly, despite > > their age. > > > > "Software Tools" literally changed my life. :-) > > > > Arnold > > > > Cameron Míċeál Tyre via TUHS wrote: > > > >> Ah, rabbit holes. Dangerous things. I went down the ed rabbit > hole around > >> a month ago and no sign of me finding my way back out any time > soon. > >> > >> I got obsessed with getting ed running on every device I have > including my > >> phones and then the big rabbit hole off that first one was > learning how to > >> use it properly and to the fullest of its abilities. That'll > take a while. > >> > >> My library of ed related publications is getting so big its likely > >> what's blocking the exit to the rabbit hole. On the plus side > it has > >> sharpened my typing skills, improved my patience and I I've > learned to > >> work out for myself what I've done to cause ed to say ?, > instead of just > >> typing h+Enter. > >> > >> As rabbit holes go, it's been stimulating so far and I could be > stuck > >> in worse places. > >> > >> Have a safe one! > >> > >> Cameron > >> > >> > >> -------- Original Message -------- > >> On 16/07/2025 01:01, Luther Johnson > wrote: > >> > >>> I just noticed that algorithm and logarithm just have a couple of > >>> letters transposed from each other. So that's the kind of > rabbit hole I > >>> get lost in most days. > >>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Jul 18 06:03:32 2025 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 17 Jul 2025 13:03:32 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> Message-ID: <20250717200332.GH27987@mcvoy.com> :sp[lit] is enough to keep me in vim. That's a killer feature. On Thu, Jul 17, 2025 at 12:06:03PM -0500, Will Senn wrote: > I heart ed and it's cousin, vi. After poring through the v6 manual and > tutorial, I started loving ed. I ditched vim a while back and embraced nvi > (berkeley's modern basic vi/ex). Very simple, very basic, extremely > powerful, none of the bloat - basically heirloom with a few refinements. > > > Will > > On 7/16/25 06:13, Cameron M????e??l Tyre via TUHS wrote: > >Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around a month ago and no sign of me finding my way back out any time soon. > > > >I got obsessed with getting ed running on every device I have including my phones and then the big rabbit hole off that first one was learning how to use it properly and to the fullest of its abilities. That'll take a while. > > > >My library of ed related publications is getting so big its likely what's blocking the exit to the rabbit hole. On the plus side it has sharpened my typing skills, improved my patience and I I've learned to work out for myself what I've done to cause ed to say ?, instead of just typing h+Enter. > > > >As rabbit holes go, it's been stimulating so far and I could be stuck in worse places. > > > >Have a safe one! > > > >Cameron > > > > > >-------- Original Message -------- > >On 16/07/2025 01:01, Luther Johnson wrote: > > > >> I just noticed that algorithm and logarithm just have a couple of > >> letters transposed from each other. So that's the kind of rabbit hole I > >> get lost in most days. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Fri Jul 18 10:33:35 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Thu, 17 Jul 2025 17:33:35 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250717200332.GH27987@mcvoy.com> References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> Message-ID: :E [filename] in nvi does the same (or similar; I rarely use vim). Though IMHO the Rand Editor did a better job of multiple windows. > On Jul 17, 2025, at 1:03 PM, Larry McVoy wrote: > > :sp[lit] > > is enough to keep me in vim. That's a killer feature. > > On Thu, Jul 17, 2025 at 12:06:03PM -0500, Will Senn wrote: >> I heart ed and it's cousin, vi. After poring through the v6 manual and >> tutorial, I started loving ed. I ditched vim a while back and embraced nvi >> (berkeley's modern basic vi/ex). Very simple, very basic, extremely >> powerful, none of the bloat - basically heirloom with a few refinements. >> >> >> Will >> >> On 7/16/25 06:13, Cameron M????e??l Tyre via TUHS wrote: >>> Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around a month ago and no sign of me finding my way back out any time soon. >>> >>> I got obsessed with getting ed running on every device I have including my phones and then the big rabbit hole off that first one was learning how to use it properly and to the fullest of its abilities. That'll take a while. >>> >>> My library of ed related publications is getting so big its likely what's blocking the exit to the rabbit hole. On the plus side it has sharpened my typing skills, improved my patience and I I've learned to work out for myself what I've done to cause ed to say ?, instead of just typing h+Enter. >>> >>> As rabbit holes go, it's been stimulating so far and I could be stuck in worse places. >>> >>> Have a safe one! >>> >>> Cameron >>> >>> >>> -------- Original Message -------- >>> On 16/07/2025 01:01, Luther Johnson wrote: >>> >>>> I just noticed that algorithm and logarithm just have a couple of >>>> letters transposed from each other. So that's the kind of rabbit hole I >>>> get lost in most days. > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Fri Jul 18 11:09:29 2025 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 17 Jul 2025 18:09:29 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> Message-ID: <20250718010929.GG30582@mcvoy.com> Not really the same. :sp splits your window in half and puts you in two different windows on the same file. Each window, in vim, is full on vi, you can do :e fillename and now that window is on that file. But that is far less useful than having two windows into the same file where the mods to each window go to the same file. Think looking at code that has the structs at the top of the file and you need to wack a struck and wack the code that uses that struct. Quite pleasant. I'm not sure but maybe xvi is where I saw this first and I only saw because I wacked xvi to use \0 and \n as end of line because that way I could change it to mmap the input file and it didn't have to parse it into internal malloced lines. Which was a huge win on 4MB Suns, I could xvi a "huge" (for then) log file. I was a performance guy, I've xvi-ed a lot of big log files. But I think xvi could split. And once I could do that I never looked back, all the emacs people were like "can you have multiple windows" and I was "yup" and it is still simple, still vi. Says the person who forced himself to live in emacs for a year and still hated it. Not trying to start an editor war, more saying, my brain works well with vi, doesn't work well with emacs, emacs is fine for people who's brain works that way. Same with nvi vs vim. My brain works pretty well with vim, I don't use 90 to 99% of what it does past basic vi, but the parts I do use I really like. I do delete the system .vimrc or whatever it is that does color highlighting, I hate that crap. I like the split windows, I like that I can tell my kid to do vim file :sp :help and he figures it out from there. I also like that I've been carrying around this .exrc for close to 40 years and it just works: map # :.,$ map @ :1,. map , !}fmt map g  map!   set redraw ai aw terse set sections=uhshSHNH set paragraphs=PSPETSTEFSFEKSKECSCERSREDSDEIPNPLPPPTLABAIAELIB1B2HH set ts=8 sw=4 set shell=/bin/sh set showmode set textwidth=1000 set vb I think the # and @ came from the BDS C editor, "," came from watching Udi Manber do that and I went WTF? ^A is because I set sw to 4, a lot of the rest is troff. 40 years later, it still works, credit to vim for maintaining backwards compat while moving the vi editor forward. No offense to Keith but nvi didn't really move vi forward much, that I know of, it made it sort of bug for bug compat with Joys vi. Which I never understood, was Joys vi not open sourced? I always wondered why Keith did all that work and then left it in the 1980s. On Thu, Jul 17, 2025 at 05:33:35PM -0700, Bakul Shah wrote: > :E [filename] in nvi does the same (or similar; I rarely use vim). > Though IMHO the Rand Editor did a better job of multiple windows. > > > > On Jul 17, 2025, at 1:03???PM, Larry McVoy wrote: > > > > :sp[lit] > > > > is enough to keep me in vim. That's a killer feature. > > > > On Thu, Jul 17, 2025 at 12:06:03PM -0500, Will Senn wrote: > >> I heart ed and it's cousin, vi. After poring through the v6 manual and > >> tutorial, I started loving ed. I ditched vim a while back and embraced nvi > >> (berkeley's modern basic vi/ex). Very simple, very basic, extremely > >> powerful, none of the bloat - basically heirloom with a few refinements. > >> > >> > >> Will > >> > >> On 7/16/25 06:13, Cameron M????e??l Tyre via TUHS wrote: > >>> Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around a month ago and no sign of me finding my way back out any time soon. > >>> > >>> I got obsessed with getting ed running on every device I have including my phones and then the big rabbit hole off that first one was learning how to use it properly and to the fullest of its abilities. That'll take a while. > >>> > >>> My library of ed related publications is getting so big its likely what's blocking the exit to the rabbit hole. On the plus side it has sharpened my typing skills, improved my patience and I I've learned to work out for myself what I've done to cause ed to say ?, instead of just typing h+Enter. > >>> > >>> As rabbit holes go, it's been stimulating so far and I could be stuck in worse places. > >>> > >>> Have a safe one! > >>> > >>> Cameron > >>> > >>> > >>> -------- Original Message -------- > >>> On 16/07/2025 01:01, Luther Johnson wrote: > >>> > >>>> I just noticed that algorithm and logarithm just have a couple of > >>>> letters transposed from each other. So that's the kind of rabbit hole I > >>>> get lost in most days. > > > > -- > > --- > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Fri Jul 18 11:19:03 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Thu, 17 Jul 2025 18:19:03 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718010929.GG30582@mcvoy.com> References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> Message-ID: <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> If you just do ":E" it will put both windows on the current file, exactly the same as vim. But both do it wrong (IMHO) as the second window starts at the same place (e.g top of the file). In the Rand Editor if the split is at line N, the bottom window shows lines N+1. Exact same behavior for vertical split (the left and right side windows show the same portions as before). > On Jul 17, 2025, at 6:09 PM, Larry McVoy wrote: > > Not really the same. :sp splits your window in half and puts you in > two different windows on the same file. Each window, in vim, is full > on vi, you can do :e fillename and now that window is on that file. From douglas.mcilroy at dartmouth.edu Fri Jul 18 12:02:57 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 17 Jul 2025 22:02:57 -0400 Subject: [TUHS] upwards from ed (was: End of an era: the last ATC) Message-ID: I always recoiled from vi's plethora of commands. Then came sam, and I haven't looked back since. It handles multiple windows with barely more commands than ed, real regular expressions, good mouse support, and great global editing capability. It can even run by script without a screen. Doug From tuhs at tuhs.org Fri Jul 18 12:52:16 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 18 Jul 2025 02:52:16 +0000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> References: <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> Message-ID: <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> > If you just do ":E" it will put both windows on the current file, > exactly the same as vim. But both do it wrong (IMHO) as the second > window starts at the same place (e.g top of the file). In the Rand > Editor if the split is at line N, the bottom window shows lines N+1. > Exact same behavior for vertical split (the left and right side > windows show the same portions as before). > > > On Jul 17, 2025, at 6:09 PM, Larry McVoy lm at mcvoy.com wrote: > > > > Not really the same. :sp splits your window in half and puts you in > > two different windows on the same file. Each window, in vim, is full > > on vi, you can do :e fillename and now that window is on that file. Not historic but as of present I shunt windowing off to GNU screen and just have separate nvi sessions in each. This may speak to ignorance on my part regarding advantages of opening multiple files in the same session in any given vi. I keep vim around for when I need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your window configuration tightly coupled, but I also frequently have vi in one pane and am using the others for od output and build/test cycle for disassembly projects. - Matt G. From tuhs at tuhs.org Fri Jul 18 13:29:21 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Thu, 17 Jul 2025 20:29:21 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> References: <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> Message-ID: On Jul 17, 2025, at 7:52 PM, segaloco via TUHS wrote: > >> If you just do ":E" it will put both windows on the current file, >> exactly the same as vim. But both do it wrong (IMHO) as the second >> window starts at the same place (e.g top of the file). In the Rand >> Editor if the split is at line N, the bottom window shows lines N+1. >> Exact same behavior for vertical split (the left and right side >> windows show the same portions as before). >> >>> On Jul 17, 2025, at 6:09 PM, Larry McVoy lm at mcvoy.com wrote: >>> >>> Not really the same. :sp splits your window in half and puts you in >>> two different windows on the same file. Each window, in vim, is full >>> on vi, you can do :e fillename and now that window is on that file. > > Not historic but as of present I shunt windowing off to GNU screen and just have separate nvi sessions in each. This may speak to ignorance on my part regarding advantages of opening multiple files in the same session in any given vi. I keep vim around for when I need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your window configuration tightly coupled, but I also frequently have vi in one pane and am using the others for od output and build/test cycle for disassembly projects. Going via screen(1) can be more painful. If you want to copy some lines from one file to another, you have to either create a temp file or use the window systems's cut/paste buffer/clipboard. The latter can actually works worse (if you have autoindent turned on for example). Also the modal nature of vi/vim can wreak havoc (copied text can be mistakenly interpreted as commands). In vi you can yank lines in file1, paste in file2. And can share options, tags etc. In the rand editor you can scroll two windows in unison (handy if one shows column headings and the other some rows). See acme for an example of a well designed multi window editor. From noel.hunt at gmail.com Fri Jul 18 15:04:18 2025 From: noel.hunt at gmail.com (Noel Hunt) Date: Fri, 18 Jul 2025 15:04:18 +1000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718010929.GG30582@mcvoy.com> References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> Message-ID: > > But that is far less useful than having two windows into the same > file where the mods to each window go to the same file. Think > looking at code that has the structs at the top of the file and you > need to wack a struck and wack the code that uses that struct. > Quite pleasant. You will find that this is exactly what 'Zerox' in acme does. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Jul 18 15:07:02 2025 From: robpike at gmail.com (Rob Pike) Date: Fri, 18 Jul 2025 15:07:02 +1000 Subject: [TUHS] upwards from ed (was: End of an era: the last ATC) In-Reply-To: References: Message-ID: I often think about the old ad from Symbolics touting EMACS's "over 400 easy to use commands." -ro On Fri, Jul 18, 2025 at 12:27 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > I always recoiled from vi's plethora of commands. Then came sam, and I > haven't looked back since. It handles multiple windows with barely > more commands than ed, real regular expressions, good mouse support, > and great global editing capability. It can even run by script without > a screen. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Jul 18 15:44:18 2025 From: robpike at gmail.com (Rob Pike) Date: Fri, 18 Jul 2025 15:44:18 +1000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250710161943.GM14377@mcvoy.com> <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> Message-ID: Sam had it, acme took it (and much else) from Sam. -rob On Fri, Jul 18, 2025 at 3:22 PM Noel Hunt wrote: > But that is far less useful than having two windows into the same >> file where the mods to each window go to the same file. Think >> looking at code that has the structs at the top of the file and you >> need to wack a struck and wack the code that uses that struct. >> Quite pleasant. > > > You will find that this is exactly what 'Zerox' in acme does. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jul 18 16:40:10 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 18 Jul 2025 06:40:10 +0000 Subject: [TUHS] Sam and Late BTL Work (was End of an era: the last ATC (USENIX Annual Technical Conference)) Message-ID: On Thursday, July 17th, 2025 at 10:44 PM, Rob Pike wrote: > Sam had it, acme took it (and much else) from Sam. > > -rob > > > On Fri, Jul 18, 2025 at 3:22 PM Noel Hunt wrote: > > > > But that is far less useful than having two windows into the same > > > file where the mods to each window go to the same file. Think > > > looking at code that has the structs at the top of the file and you > > > need to wack a struck and wack the code that uses that struct. > > > Quite pleasant. > > > > > > You will find that this is exactly what 'Zerox' in acme does. Sam is indeed nice but I have not quite gotten to the point of using it daily. For my hobby projects I rarely launch an X session, opting to simply work from the framebuffer console instead. I don't have a graphical editor of choice these days though so Sam is certainly on the docket whenever I start using a windowing environment heavily outside of web browsing again. End of the day though I like being able to do the bulk of what I do sitting at any given computer from the console. I have a VT100 that I've finally restored to perfect health I plan on setting up in my bedroom as a true terminal (routed through my Dataphone modems down to my office machine). To hopefully inspire some interesting discussion, was Sam ever formally supported by AT&T as an editor in System V, either OpenLook or X environments? Or did it never escape Plan 9 as far as AT&T's commercial UNIX offerings go? In a more general sense I find the later genetic flow from BTL et. al. to USL intriguing since the Labs were already onto things so far ahead of what System V was in the commercial scene. - Matt G. From jsg at jsg.id.au Fri Jul 18 19:18:11 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 18 Jul 2025 19:18:11 +1000 Subject: [TUHS] Sam and Late BTL Work (was End of an era: the last ATC (USENIX Annual Technical Conference)) In-Reply-To: References: Message-ID: On Fri, Jul 18, 2025 at 06:40:10AM +0000, segaloco via TUHS wrote: > On Thursday, July 17th, 2025 at 10:44 PM, Rob Pike wrote: > > > Sam had it, acme took it (and much else) from Sam. > > > > -rob > > > > > > On Fri, Jul 18, 2025 at 3:22 PM Noel Hunt wrote: > > > > > > But that is far less useful than having two windows into the same > > > > file where the mods to each window go to the same file. Think > > > > looking at code that has the structs at the top of the file and you > > > > need to wack a struck and wack the code that uses that struct. > > > > Quite pleasant. > > > > > > > > > You will find that this is exactly what 'Zerox' in acme does. > > Sam is indeed nice but I have not quite gotten to the point of using it daily. For my hobby projects I rarely launch an X session, opting to simply work from the framebuffer console instead. I don't have a graphical editor of choice these days though so Sam is certainly on the docket whenever I start using a windowing environment heavily outside of web browsing again. End of the day though I like being able to do the bulk of what I do sitting at any given computer from the console. I have a VT100 that I've finally restored to perfect health I plan on setting up in my bedroom as a true terminal (routed through my Dataphone modems down to my office machine). > > To hopefully inspire some interesting discussion, was Sam ever formally supported by AT&T as an editor in System V, either OpenLook or X environments? Or did it never escape Plan 9 as far as AT&T's commercial UNIX offerings go? In a more general sense I find the later genetic flow from BTL et. al. to USL intriguing since the Labs were already onto things so far ahead of what System V was in the commercial scene. > > - Matt G. "This is the ad for sam, which is going in the toolchest imminently. ... Sam is available for several systems, including System V, 9th Edition, 4.[23]BSD and SUNOS, with terminal support for 5620s, 630s, SUNWindows and X11." Rob Pike in comp.unix.questions Jul 15, 1988 https://groups.google.com/g/comp.unix.questions/c/lG7x8T2EDjo/m/JhteY7eDVN8J toolchest referring to the paid AT&T UNIX System Toolchest service. By 1992, Sam for Unix could be downloaded with anonymous FTP. announced by Rob Pike in comp.os.research Nov 5, 1992 https://groups.google.com/g/comp.os.research/c/fvfHNv_t_Dw/m/UYDRogQ1ePEJ From lm at mcvoy.com Fri Jul 18 20:09:02 2025 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 18 Jul 2025 03:09:02 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> Message-ID: <20250718100902.GI30582@mcvoy.com> On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote: > On Jul 17, 2025, at 7:52???PM, segaloco via TUHS wrote: > > > >> If you just do ":E" it will put both windows on the current file, > >> exactly the same as vim. But both do it wrong (IMHO) as the second > >> window starts at the same place (e.g top of the file). In the Rand > >> Editor if the split is at line N, the bottom window shows lines N+1. > >> Exact same behavior for vertical split (the left and right side > >> windows show the same portions as before). > >> > >>> On Jul 17, 2025, at 6:09???PM, Larry McVoy lm at mcvoy.com wrote: > >>> > >>> Not really the same. :sp splits your window in half and puts you in > >>> two different windows on the same file. Each window, in vim, is full > >>> on vi, you can do :e fillename and now that window is on that file. > > > > Not historic but as of present I shunt windowing off to GNU screen and just have separate nvi sessions in each. This may speak to ignorance on my part regarding advantages of opening multiple files in the same session in any given vi. I keep vim around for when I need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your window configuration tightly coupled, but I also frequently have vi in one pane and am using the others for od output and build/test cycle for disassembly projects. > > Going via screen(1) can be more painful. If you want to copy some lines > from one file to another, you have to either create a temp file or > use the window systems's cut/paste buffer/clipboard. The latter can > actually works worse (if you have autoindent turned on for example). > Also the modal nature of vi/vim can wreak havoc (copied text can be > mistakenly interpreted as commands). > > In vi you can yank lines in file1, paste in file2. And can share > options, tags etc. In the rand editor you can scroll two windows in > unison (handy if one shows column headings and the other some rows). > See acme for an example of a well designed multi window editor. I was going to respond to the screen stuff but Bakul beat me to it. In vim, you just have a split view of the same file. Changes in either window will show up in the other window. For example vim foo.c # foo.c exists and has a 100 lines :sp now you have both windows looking at the same file start changing something and it is done in both windows. Screen is nowhere near that and using it to claim that nvi is fine is missing the point by a country mile. And I don't understand the dislike of vim. Sure, it's got a pile of stuff that old time Unix people would dislike "cat came back from BSD wagging it's tail" (or something that Rob said) but you don't have to use any of that. For me, vim is a finger compat vi clone that has some really really useful extensions, I use :split all the time. Saying you prefer nvi in the face of that is something that makes no sense to me. I've used nvi, I get that it is compat with Joys vi, but so what? vim is more useful and it is also compat. Time marches on, perhaps march with it? --lm From douglas.mcilroy at dartmouth.edu Fri Jul 18 20:46:24 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 18 Jul 2025 06:46:24 -0400 Subject: [TUHS] upwards from ed (was: End of an era: the last ATC) In-Reply-To: References: Message-ID: Once when I saw the Lisp machine EMACS help list scroll by, replete with a "call elevator" command, I innocently asked how many commands there were. I expected a prompt answer akin to help|wc. It actually took two experts several minutes to come up with a way to count those lines. Doug On Fri, Jul 18, 2025 at 1:07 AM Rob Pike wrote: > > I often think about the old ad from Symbolics touting EMACS's "over 400 easy to use commands." > > -ro > > On Fri, Jul 18, 2025 at 12:27 PM Douglas McIlroy wrote: >> >> I always recoiled from vi's plethora of commands. Then came sam, and I >> haven't looked back since. It handles multiple windows with barely >> more commands than ed, real regular expressions, good mouse support, >> and great global editing capability. It can even run by script without >> a screen. >> >> Doug From will.senn at gmail.com Fri Jul 18 22:24:46 2025 From: will.senn at gmail.com (Will Senn) Date: Fri, 18 Jul 2025 07:24:46 -0500 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718100902.GI30582@mcvoy.com> References: <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> Message-ID: <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> nvi does everything i need it to, it's help fits on a couple of screens, and it's easy to remember it all. maybe if I hit a wall with it, I'll reinstall vim, but for the screen stuff, don't need it. I don't live in my editor, or even the command line, I just use it when it's convenient - which admittedly is a lot of the time. But, it's the terminal that's most useful, not vi. So, if I want more screen, I just open a terminal window. My monitor has room for a dozen or so :) not including guake, workspaces, etc... in the modern era, of course! Will On 7/18/25 05:09, Larry McVoy wrote: > On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote: >> On Jul 17, 2025, at 7:52???PM, segaloco via TUHS wrote: >>>> If you just do ":E" it will put both windows on the current file, >>>> exactly the same as vim. But both do it wrong (IMHO) as the second >>>> window starts at the same place (e.g top of the file). In the Rand >>>> Editor if the split is at line N, the bottom window shows lines N+1. >>>> Exact same behavior for vertical split (the left and right side >>>> windows show the same portions as before). >>>> >>>>> On Jul 17, 2025, at 6:09???PM, Larry McVoy lm at mcvoy.com wrote: >>>>> >>>>> Not really the same. :sp splits your window in half and puts you in >>>>> two different windows on the same file. Each window, in vim, is full >>>>> on vi, you can do :e fillename and now that window is on that file. >>> Not historic but as of present I shunt windowing off to GNU screen and just have separate nvi sessions in each. This may speak to ignorance on my part regarding advantages of opening multiple files in the same session in any given vi. I keep vim around for when I need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your window configuration tightly coupled, but I also frequently have vi in one pane and am using the others for od output and build/test cycle for disassembly projects. >> Going via screen(1) can be more painful. If you want to copy some lines >> from one file to another, you have to either create a temp file or >> use the window systems's cut/paste buffer/clipboard. The latter can >> actually works worse (if you have autoindent turned on for example). >> Also the modal nature of vi/vim can wreak havoc (copied text can be >> mistakenly interpreted as commands). >> >> In vi you can yank lines in file1, paste in file2. And can share >> options, tags etc. In the rand editor you can scroll two windows in >> unison (handy if one shows column headings and the other some rows). >> See acme for an example of a well designed multi window editor. > I was going to respond to the screen stuff but Bakul beat me to it. > In vim, you just have a split view of the same file. Changes in > either window will show up in the other window. For example > > vim foo.c # foo.c exists and has a 100 lines > :sp > > now you have both windows looking at the same file > > start changing something and it is done in both windows. > > Screen is nowhere near that and using it to claim that nvi is fine > is missing the point by a country mile. > > And I don't understand the dislike of vim. Sure, it's got a pile > of stuff that old time Unix people would dislike "cat came back > from BSD wagging it's tail" (or something that Rob said) but you > don't have to use any of that. For me, vim is a finger compat > vi clone that has some really really useful extensions, I use > :split > all the time. Saying you prefer nvi in the face of that is > something that makes no sense to me. I've used nvi, I get that > it is compat with Joys vi, but so what? vim is more useful and > it is also compat. > > Time marches on, perhaps march with it? > > --lm From lm at mcvoy.com Fri Jul 18 22:52:10 2025 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 18 Jul 2025 05:52:10 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> References: <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> Message-ID: <20250718125210.GL30582@mcvoy.com> That's fine, if it works for you it works for you. For me, vim is compat enough (and it has a way to make it more compat if you care I believe) and has some functionality that makes me shake my head at the nvi people. To me, nvi is sort of like v7. Yeah, it's like the original Unix but would you want to live there just because it is "pure"? No networking, no top, it's just a basic Unix. Cool because of how small it is but pretty painful to live there. On Fri, Jul 18, 2025 at 07:24:46AM -0500, Will Senn wrote: > nvi does everything i need it to, it's help fits on a couple of screens, and > it's easy to remember it all. maybe if I hit a wall with it, I'll reinstall > vim, but for the screen stuff, don't need it. I don't live in my editor, or > even the command line, I just use it when it's convenient - which admittedly > is a lot of the time. But, it's the terminal that's most useful, not vi. So, > if I want more screen, I just open a terminal window. My monitor has room > for a dozen or so :) not including guake, workspaces, etc... in the modern > era, of course! > > Will > > On 7/18/25 05:09, Larry McVoy wrote: > >On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote: > >>On Jul 17, 2025, at 7:52???PM, segaloco via TUHS wrote: > >>>>If you just do ":E" it will put both windows on the current file, > >>>>exactly the same as vim. But both do it wrong (IMHO) as the second > >>>>window starts at the same place (e.g top of the file). In the Rand > >>>>Editor if the split is at line N, the bottom window shows lines N+1. > >>>>Exact same behavior for vertical split (the left and right side > >>>>windows show the same portions as before). > >>>> > >>>>>On Jul 17, 2025, at 6:09???PM, Larry McVoy lm at mcvoy.com wrote: > >>>>> > >>>>>Not really the same. :sp splits your window in half and puts you in > >>>>>two different windows on the same file. Each window, in vim, is full > >>>>>on vi, you can do :e fillename and now that window is on that file. > >>>Not historic but as of present I shunt windowing off to GNU screen and just have separate nvi sessions in each. This may speak to ignorance on my part regarding advantages of opening multiple files in the same session in any given vi. I keep vim around for when I need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your window configuration tightly coupled, but I also frequently have vi in one pane and am using the others for od output and build/test cycle for disassembly projects. > >>Going via screen(1) can be more painful. If you want to copy some lines > >>from one file to another, you have to either create a temp file or > >>use the window systems's cut/paste buffer/clipboard. The latter can > >>actually works worse (if you have autoindent turned on for example). > >>Also the modal nature of vi/vim can wreak havoc (copied text can be > >>mistakenly interpreted as commands). > >> > >>In vi you can yank lines in file1, paste in file2. And can share > >>options, tags etc. In the rand editor you can scroll two windows in > >>unison (handy if one shows column headings and the other some rows). > >>See acme for an example of a well designed multi window editor. > >I was going to respond to the screen stuff but Bakul beat me to it. > >In vim, you just have a split view of the same file. Changes in > >either window will show up in the other window. For example > > > >vim foo.c # foo.c exists and has a 100 lines > >:sp > > > >now you have both windows looking at the same file > > > >start changing something and it is done in both windows. > > > >Screen is nowhere near that and using it to claim that nvi is fine > >is missing the point by a country mile. > > > >And I don't understand the dislike of vim. Sure, it's got a pile > >of stuff that old time Unix people would dislike "cat came back > >from BSD wagging it's tail" (or something that Rob said) but you > >don't have to use any of that. For me, vim is a finger compat > >vi clone that has some really really useful extensions, I use > >:split > >all the time. Saying you prefer nvi in the face of that is > >something that makes no sense to me. I've used nvi, I get that > >it is compat with Joys vi, but so what? vim is more useful and > >it is also compat. > > > >Time marches on, perhaps march with it? > > > >--lm -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From brantley at coraid.com Sat Jul 19 00:25:21 2025 From: brantley at coraid.com (Brantley Coile) Date: Fri, 18 Jul 2025 14:25:21 +0000 Subject: [TUHS] Sam and Late BTL Work (was End of an era: the last ATC (USENIX Annual Technical Conference)) In-Reply-To: References: Message-ID: I use sam daily. I first used it from the tool chest on a 630 (which I still have). I went to Acme for a while, then back to sam. I also still use Plan 9 for all our products and development. Brantley > On Jul 18, 2025, at 5:18 AM, Jonathan Gray wrote: > > On Fri, Jul 18, 2025 at 06:40:10AM +0000, segaloco via TUHS wrote: >> On Thursday, July 17th, 2025 at 10:44 PM, Rob Pike wrote: >> >>> Sam had it, acme took it (and much else) from Sam. >>> >>> -rob >>> >>> >>> On Fri, Jul 18, 2025 at 3:22 PM Noel Hunt wrote: >>> >>>>> But that is far less useful than having two windows into the same >>>>> file where the mods to each window go to the same file. Think >>>>> looking at code that has the structs at the top of the file and you >>>>> need to wack a struck and wack the code that uses that struct. >>>>> Quite pleasant. >>>> >>>> >>>> You will find that this is exactly what 'Zerox' in acme does. >> >> Sam is indeed nice but I have not quite gotten to the point of using it daily. For my hobby projects I rarely launch an X session, opting to simply work from the framebuffer console instead. I don't have a graphical editor of choice these days though so Sam is certainly on the docket whenever I start using a windowing environment heavily outside of web browsing again. End of the day though I like being able to do the bulk of what I do sitting at any given computer from the console. I have a VT100 that I've finally restored to perfect health I plan on setting up in my bedroom as a true terminal (routed through my Dataphone modems down to my office machine). >> >> To hopefully inspire some interesting discussion, was Sam ever formally supported by AT&T as an editor in System V, either OpenLook or X environments? Or did it never escape Plan 9 as far as AT&T's commercial UNIX offerings go? In a more general sense I find the later genetic flow from BTL et. al. to USL intriguing since the Labs were already onto things so far ahead of what System V was in the commercial scene. >> >> - Matt G. > > "This is the ad for sam, which is going in the toolchest imminently. > ... > Sam is available for several systems, including System V, 9th Edition, > 4.[23]BSD and SUNOS, with terminal support for 5620s, 630s, SUNWindows > and X11." > Rob Pike in comp.unix.questions Jul 15, 1988 > https://groups.google.com/g/comp.unix.questions/c/lG7x8T2EDjo/m/JhteY7eDVN8J > > toolchest referring to the paid AT&T UNIX System Toolchest service. > > By 1992, Sam for Unix could be downloaded with anonymous FTP. > announced by Rob Pike in comp.os.research Nov 5, 1992 > https://groups.google.com/g/comp.os.research/c/fvfHNv_t_Dw/m/UYDRogQ1ePEJ From will.senn at gmail.com Sat Jul 19 04:28:54 2025 From: will.senn at gmail.com (Will Senn) Date: Fri, 18 Jul 2025 13:28:54 -0500 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718125210.GL30582@mcvoy.com> References: <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> Message-ID: <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> Ha Larry. I'm not hidebound, but I do like to understand the software I use and I'm more of the if it ain't broke persuasion. The vim manual is maybe 5000 pages now (https://nathangrigg.com/vimhelp/vimhelp.pdf), only about 100x the nvi manual.... but yeah, different strokes for different folks. Seems like we're in the weeds though, almost COFF worthy. I do wonder about vi though and when it became prevalent. In v6, it's supposedly possible to get it working, but I've never seen it in virtual environs (oh how I've tried). In v7, it's more possible, but again, I've not seen it really working in SIMH (tried that too). BSD 2.11 gets the nod, but was it delivered as part of any system prior to 2.11 or was 2.11 really the first post v7 unix with vi with wider adoption? Later, Will On 7/18/25 07:52, Larry McVoy wrote: > That's fine, if it works for you it works for you. For me, vim is > compat enough (and it has a way to make it more compat if you care > I believe) and has some functionality that makes me shake my head > at the nvi people. > > To me, nvi is sort of like v7. Yeah, it's like the original Unix > but would you want to live there just because it is "pure"? No > networking, no top, it's just a basic Unix. Cool because of how > small it is but pretty painful to live there. > > On Fri, Jul 18, 2025 at 07:24:46AM -0500, Will Senn wrote: >> nvi does everything i need it to, it's help fits on a couple of screens, and >> it's easy to remember it all. maybe if I hit a wall with it, I'll reinstall >> vim, but for the screen stuff, don't need it. I don't live in my editor, or >> even the command line, I just use it when it's convenient - which admittedly >> is a lot of the time. But, it's the terminal that's most useful, not vi. So, >> if I want more screen, I just open a terminal window. My monitor has room >> for a dozen or so :) not including guake, workspaces, etc... in the modern >> era, of course! >> >> Will >> >> On 7/18/25 05:09, Larry McVoy wrote: >>> On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote: >>>> On Jul 17, 2025, at 7:52???PM, segaloco via TUHS wrote: >>>>>> If you just do ":E" it will put both windows on the current file, >>>>>> exactly the same as vim. But both do it wrong (IMHO) as the second >>>>>> window starts at the same place (e.g top of the file). In the Rand >>>>>> Editor if the split is at line N, the bottom window shows lines N+1. >>>>>> Exact same behavior for vertical split (the left and right side >>>>>> windows show the same portions as before). >>>>>> >>>>>>> On Jul 17, 2025, at 6:09???PM, Larry McVoy lm at mcvoy.com wrote: >>>>>>> >>>>>>> Not really the same. :sp splits your window in half and puts you in >>>>>>> two different windows on the same file. Each window, in vim, is full >>>>>>> on vi, you can do :e fillename and now that window is on that file. >>>>> Not historic but as of present I shunt windowing off to GNU screen and just have separate nvi sessions in each. This may speak to ignorance on my part regarding advantages of opening multiple files in the same session in any given vi. I keep vim around for when I need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your window configuration tightly coupled, but I also frequently have vi in one pane and am using the others for od output and build/test cycle for disassembly projects. >>>> Going via screen(1) can be more painful. If you want to copy some lines >>> >from one file to another, you have to either create a temp file or >>>> use the window systems's cut/paste buffer/clipboard. The latter can >>>> actually works worse (if you have autoindent turned on for example). >>>> Also the modal nature of vi/vim can wreak havoc (copied text can be >>>> mistakenly interpreted as commands). >>>> >>>> In vi you can yank lines in file1, paste in file2. And can share >>>> options, tags etc. In the rand editor you can scroll two windows in >>>> unison (handy if one shows column headings and the other some rows). >>>> See acme for an example of a well designed multi window editor. >>> I was going to respond to the screen stuff but Bakul beat me to it. >>> In vim, you just have a split view of the same file. Changes in >>> either window will show up in the other window. For example >>> >>> vim foo.c # foo.c exists and has a 100 lines >>> :sp >>> >>> now you have both windows looking at the same file >>> >>> start changing something and it is done in both windows. >>> >>> Screen is nowhere near that and using it to claim that nvi is fine >>> is missing the point by a country mile. >>> >>> And I don't understand the dislike of vim. Sure, it's got a pile >>> of stuff that old time Unix people would dislike "cat came back >> >from BSD wagging it's tail" (or something that Rob said) but you >>> don't have to use any of that. For me, vim is a finger compat >>> vi clone that has some really really useful extensions, I use >>> :split >>> all the time. Saying you prefer nvi in the face of that is >>> something that makes no sense to me. I've used nvi, I get that >>> it is compat with Joys vi, but so what? vim is more useful and >>> it is also compat. >>> >>> Time marches on, perhaps march with it? >>> >>> --lm From royce at techsolvency.com Sat Jul 19 05:42:48 2025 From: royce at techsolvency.com (Royce Williams) Date: Fri, 18 Jul 2025 11:42:48 -0800 Subject: [TUHS] primary sources for the 1966 Multics ASCII cutover as the first "Flag Day"? Message-ID: I see the Wikipedia "Flag day (computing)" [1] article references two semi-different ESR sources [2,3] to support the claim: > This systems terminology originates from a major change in the Multics operating system's definition of ASCII, which was scheduled for the United States holiday, Flag Day, on June 14, 1966. I don't doubt the validity, but I'm looking for other "citation worthy" sources that supplement this claim --- ideally that predate the ESR ones, so that they are unambiguously independent. 1. https://en.wikipedia.org/wiki/Flag_day_(computing) 2. http://www.catb.org/jargon/html/F/flag-day.html 3. *The New Hacker's Dictionary* pp. 192– -- Royce Williams Tech Solvency -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jul 19 05:43:49 2025 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 18 Jul 2025 12:43:49 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> References: <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> Message-ID: <20250718194349.GG8625@mcvoy.com> Last post on this topic because life is too short. Will, you can do whatever you want. If you worked for me, this would be a much shorter conversation and you'd be using vim. Modern tools are more complicated because they do more stuff. Taking your position to the extreme would have you using a pipeline piped to ed, would it not? vi is a BSDism, so it isn't "pure", nvi is a rewrite of Joys vi (why? Anyone?) I get the desire to have simple tools, I'm that way too, but switching from vi, nvi to vim was seamless. I've never looked at their documentation other than :help to find how to manipulate their windows. Everything else just worked. Have fun with nvi. On Fri, Jul 18, 2025 at 01:28:54PM -0500, Will Senn wrote: > Ha Larry. I'm not hidebound, but I do like to understand the software I use > and I'm more of the if it ain't broke persuasion. The vim manual is maybe > 5000 pages now (https://nathangrigg.com/vimhelp/vimhelp.pdf), only about > 100x the nvi manual.... but yeah, different strokes for different folks. > > Seems like we're in the weeds though, almost COFF worthy. > > I do wonder about vi though and when it became prevalent. In v6, it's > supposedly possible to get it working, but I've never seen it in virtual > environs (oh how I've tried). In v7, it's more possible, but again, I've not > seen it really working in SIMH (tried that too). BSD 2.11 gets the nod, but > was it delivered as part of any system prior to 2.11 or was 2.11 really the > first post v7 unix with vi with wider adoption? > > Later, > > Will > > > > On 7/18/25 07:52, Larry McVoy wrote: > >That's fine, if it works for you it works for you. For me, vim is > >compat enough (and it has a way to make it more compat if you care > >I believe) and has some functionality that makes me shake my head > >at the nvi people. > > > >To me, nvi is sort of like v7. Yeah, it's like the original Unix > >but would you want to live there just because it is "pure"? No > >networking, no top, it's just a basic Unix. Cool because of how > >small it is but pretty painful to live there. > > > >On Fri, Jul 18, 2025 at 07:24:46AM -0500, Will Senn wrote: > >>nvi does everything i need it to, it's help fits on a couple of screens, and > >>it's easy to remember it all. maybe if I hit a wall with it, I'll reinstall > >>vim, but for the screen stuff, don't need it. I don't live in my editor, or > >>even the command line, I just use it when it's convenient - which admittedly > >>is a lot of the time. But, it's the terminal that's most useful, not vi. So, > >>if I want more screen, I just open a terminal window. My monitor has room > >>for a dozen or so :) not including guake, workspaces, etc... in the modern > >>era, of course! > >> > >>Will > >> > >>On 7/18/25 05:09, Larry McVoy wrote: > >>>On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote: > >>>>On Jul 17, 2025, at 7:52???PM, segaloco via TUHS wrote: > >>>>>>If you just do ":E" it will put both windows on the current file, > >>>>>>exactly the same as vim. But both do it wrong (IMHO) as the second > >>>>>>window starts at the same place (e.g top of the file). In the Rand > >>>>>>Editor if the split is at line N, the bottom window shows lines N+1. > >>>>>>Exact same behavior for vertical split (the left and right side > >>>>>>windows show the same portions as before). > >>>>>> > >>>>>>>On Jul 17, 2025, at 6:09???PM, Larry McVoy lm at mcvoy.com wrote: > >>>>>>> > >>>>>>>Not really the same. :sp splits your window in half and puts you in > >>>>>>>two different windows on the same file. Each window, in vim, is full > >>>>>>>on vi, you can do :e fillename and now that window is on that file. > >>>>>Not historic but as of present I shunt windowing off to GNU screen and just have separate nvi sessions in each. This may speak to ignorance on my part regarding advantages of opening multiple files in the same session in any given vi. I keep vim around for when I need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your window configuration tightly coupled, but I also frequently have vi in one pane and am using the others for od output and build/test cycle for disassembly projects. > >>>>Going via screen(1) can be more painful. If you want to copy some lines > >>>>from one file to another, you have to either create a temp file or > >>>>use the window systems's cut/paste buffer/clipboard. The latter can > >>>>actually works worse (if you have autoindent turned on for example). > >>>>Also the modal nature of vi/vim can wreak havoc (copied text can be > >>>>mistakenly interpreted as commands). > >>>> > >>>>In vi you can yank lines in file1, paste in file2. And can share > >>>>options, tags etc. In the rand editor you can scroll two windows in > >>>>unison (handy if one shows column headings and the other some rows). > >>>>See acme for an example of a well designed multi window editor. > >>>I was going to respond to the screen stuff but Bakul beat me to it. > >>>In vim, you just have a split view of the same file. Changes in > >>>either window will show up in the other window. For example > >>> > >>>vim foo.c # foo.c exists and has a 100 lines > >>>:sp > >>> > >>>now you have both windows looking at the same file > >>> > >>>start changing something and it is done in both windows. > >>> > >>>Screen is nowhere near that and using it to claim that nvi is fine > >>>is missing the point by a country mile. > >>> > >>>And I don't understand the dislike of vim. Sure, it's got a pile > >>>of stuff that old time Unix people would dislike "cat came back > >>>from BSD wagging it's tail" (or something that Rob said) but you > >>>don't have to use any of that. For me, vim is a finger compat > >>>vi clone that has some really really useful extensions, I use > >>>:split > >>>all the time. Saying you prefer nvi in the face of that is > >>>something that makes no sense to me. I've used nvi, I get that > >>>it is compat with Joys vi, but so what? vim is more useful and > >>>it is also compat. > >>> > >>>Time marches on, perhaps march with it? > >>> > >>>--lm -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From clemc at ccc.com Sat Jul 19 05:59:39 2025 From: clemc at ccc.com (Clem Cole) Date: Fri, 18 Jul 2025 15:59:39 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718194349.GG8625@mcvoy.com> References: <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> Message-ID: On Fri, Jul 18, 2025 at 3:43 PM Larry McVoy wrote: > nvi is a rewrite of Joys vi (why? Anyone?) > When Keith ensured that everything in what would lead to the NET2 release was free of any AT&T IP, since the vi command was added to ex, which had originated as ed on the Sixth Edition, it had to be replaced. FWIW: Your observation about modern tools doing more stuff cuts both ways. Sometimes that's nice. As much as I miss the simplicity of the Seventh Edition, I'd not want to trade my Mac for it. But as Rob once observed, cat -v is not necessary and many of the "stuff" you mention has little value. I suspect that every feature in vim is found to be helpful>>somebody<< but I >>suspect<< that few people need, much less use all the features, and as importantly, as with cat -v, there are often simpler solutions for many of these features. Just because it has them does not necessarily mean it matters. My take, the >>one<< feature Vim has for me is MacVIM, which is better integrated into my Mac, but other than that, my .exrc file, like yours, is 40+ years old, and most of how I use it, nvi would work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Sat Jul 19 06:08:33 2025 From: rich.salz at gmail.com (Rich Salz) Date: Fri, 18 Jul 2025 22:08:33 +0200 Subject: [TUHS] primary sources for the 1966 Multics ASCII cutover as the first "Flag Day"? In-Reply-To: References: Message-ID: Interestingly, that phrasing comes directly from morticians.org. Or rather, instead of implying something, I should say that the wording between the two is exactly the same You could ask over on that site, I think there's some kind of mailing list, if there's more info available. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jul 19 06:12:52 2025 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 18 Jul 2025 13:12:52 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> Message-ID: <20250718201252.GH8625@mcvoy.com> On Fri, Jul 18, 2025 at 03:59:39PM -0400, Clem Cole wrote: > On Fri, Jul 18, 2025 at 3:43???PM Larry McVoy wrote: > > > nvi is a rewrite of Joys vi (why? Anyone?) > > > When Keith ensured that everything in what would lead to the NET2 release > was free of any AT&T IP, since the vi command was added to ex, which had > originated as ed on the Sixth Edition, it had to be replaced. > > FWIW: Your observation about modern tools doing more stuff cuts both ways. > > Sometimes that's nice. As much as I miss the simplicity of the Seventh > Edition, I'd not want to trade my Mac for it. But as Rob once observed, cat > -v is not necessary and many of the "stuff" you mention has little value. > I suspect that every feature in vim is found to be helpful>>somebody<< but > I >>suspect<< that few people need, much less use all the features, and as > importantly, as with cat -v, there are often simpler solutions for many of > these features. Just because it has them does not necessarily mean it > matters. > > My take, the >>one<< feature Vim has for me is MacVIM, which is better > integrated into my Mac, but other than that, my .exrc file, like yours, is > 40+ years old, and most of how I use it, nvi would work. Sigh, my entire points were: A) my 40 year old .exrc works perfectly with vim and has for more than 20 years. B) the killer feature, not present in nvi, is :split Beyond that, I don't care how much extra crap there is in vim, all I care about is vi compat and :split Why that is controversial is beyond me. Lets move on. Use whatever you like. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From rminnich at gmail.com Sat Jul 19 06:47:18 2025 From: rminnich at gmail.com (ron minnich) Date: Fri, 18 Jul 2025 13:47:18 -0700 Subject: [TUHS] Your Most Prized UNIX Artifacts? In-Reply-To: References: <202506091611.559GBKZJ397819@freefriends.org> <4-qJVuQM7Jgik3HG9UukaN3NXJSFwGeqyP5ChnzKLRP-k3pCVD5kLjsrxl8kGGF9pnrovp91wleJFXKLrc-XK3Wv9tk0g4Pz7YfeTCqTKJw=@protonmail.ch> Message-ID: I was admiring this list of cool artifacts, thinking I had none, then remembered in the corner I have a 64K PDP11 core plane, which, when it failed, had a V6 kernel image in it. Now, that was 50 years ago, so magnetic donuts or no, that image is long gone, but it's still fun to think about. Also, I have a DECTape from the late Jim McKie, somewhere, but I forget what was on it. I still have my "documents for use with ..." book, and the BSTJ, but so do many of you ;-) Finally, somewhere, I also have a budget page from a document I found in a dumpster at Murray Hill. This would have been 2007, or so, when lots of people were leaving and lots of offices were being "dumpster lobotomized"; I saw the doc in a dumpster and ripped out that page. It seemed of interest. On Fri, Jun 13, 2025 at 7:27 PM Daria Phoebe Brashear wrote: > > > On Wed, Jun 11, 2025 at 18:35 Greg A. Woods wrote: > >> At Tue, 10 Jun 2025 12:10:28 +1000, Rob Pike wrote: >> Subject: [TUHS] Re: Your Most Prized UNIX Artifacts? >> > >> > An original, hand-wire-wrapped Jerq board, later renamed Blit because of >> > marketing. Also the original mouse, made by Prof Nicoud's lab and >> signed by >> > him on the bottom. >> >> The mice that came with the DMD-5620s, the Dépraz Mouse, "Made in >> Switzerland" (one of mine says "Type D 85 / P") looks very similar. I >> have one in an original AT&T package too. >> > > Ah yes. Mice. I still have two new-in-their-boxes DEC Hawley puck mice. > VSXXX-AA, with two rollers. > > They kept tracking reliably whereas the ball variant always got gunked up > and skipped, but our DEC mice tended to succumb to Nettrek disease, where > the left button would get clicked to death, and the replacements were > inevitably the ball version. > > I never managed to source a wheel version at the time to just carry with > me. Got two years later, planning to give one to a friend a few months > older than me for his collection. Cancer intervened and he is several years > gone now, alas. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trnsz at pobox.com Sat Jul 19 06:53:24 2025 From: trnsz at pobox.com (Jeff Johnson) Date: Fri, 18 Jul 2025 16:53:24 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718201252.GH8625@mcvoy.com> References: <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <20250718201252.GH8625@mcvoy.com> Message-ID: <16fa9c17-47d1-487a-aadd-c62632bcb971@app.fastmail.com> Just to make sure we are talking about the right editors in OpenVi (https://github.com/johnsonjh/OpenVi, that I maintain) and nvi2 (https://github.com/lichray/nvi2) have many extra features, but the split windows do derive from the original nvi which is currently homed at https://repo.or.cz/nvi.git now. It's just not `:split` but `:E` (capital E). ^W switches the active window, and you can continue to split the screen as many times as you like. If you're married typing split, set an abbrev. like `:ab split E`. The missing feature in the nvi series of editors here is the ability to split windows vertically rather than horizontally (i.e. `:vsplit`). ... but I'll no longer beat the dead horse! -- Jeffrey H. Johnson trnsz at pobox.com > Sigh, my entire points were: > > A) my 40 year old .exrc works perfectly with vim and has for more than 20 years. > B) the killer feature, not present in nvi, is :split > > Beyond that, I don't care how much extra crap there is in vim, all I care > about is vi compat and :split > > Why that is controversial is beyond me. Lets move on. Use whatever you like. From tuhs at tuhs.org Sat Jul 19 06:58:12 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 18 Jul 2025 13:58:12 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718100902.GI30582@mcvoy.com> References: <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> Message-ID: On Jul 18, 2025, at 3:09 AM, Larry McVoy wrote: > In vim, you just have a split view of the same file. Changes in > either window will show up in the other window. For example > > vim foo.c # foo.c exists and has a 100 lines > :sp In nvi :E > now you have both windows looking at the same file Ditto > start changing something and it is done in both windows. In nvi changes don't show up right away in the other window but show up once you switch to it. So not as good as vim but in practice it doesn't matter much since usually you show *different* parts in two windows pointing at the same file. > Screen is nowhere near that and using it to claim that nvi is fine > is missing the point by a country mile. > > And I don't understand the dislike of vim. It is more that some of us *prefer* nvi to vim. [I might've used vim when it was first posted on Usenet but Braam refused to make at least provide an option to make multiple undo/redo behavior compatible to nvi. So it goes!] I don't care what tools my team members use as long as they are pulling their weight. Usually the best programmers already have a set of tools they are comfortable with. I wouldn't want to mess with that. [I have worked in teams where people were using nvi, vim, acme, sam, emacs, ee, IDEs etc.] From jon at fourwinds.com Sat Jul 19 07:03:53 2025 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 18 Jul 2025 14:03:53 -0700 Subject: [TUHS] Your Most Prized UNIX Artifacts? Message-ID: <202507182103.56IL3rQA1096987@darkstar.fourwinds.com> It's not exactly a UNIX artifact but in the late 60s - early 70s when we wanted a break at night we'd go down to the second floor of building 2 which had a PDP-15/GRIN-2 and play space war. It sticks in my memory because there was an Etch-A-Sketch hanging on the side of one of the equipment racks with a sign under it that said "In case of fire, throw in". Anyway, I have a hunk of DEC fan-fold paper tape with double-sun space war on it; the boot address is written on the leader in my teen-age handwriting. Somewhere I have a paper tape reader. When I have some spare cycles I plan to read that tape in and try to get it running as folks have VMs for that architecture. Probably will have to build a button box to go with it - I recall that there was an 8 button box, 4 for each player - turn left, turn right, accelerate, and shoot. And it also read the front panel console switches to change the game settings such as limited/unlimited ammo, limited/unlimited fuel, tumble-mode, etc. Another non-UNIX artifact that I came across is a 1974 BTL directory. The departmental index is fascinating - gives a view of what a real research lab looked like. Jon From lm at mcvoy.com Sat Jul 19 07:32:21 2025 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 18 Jul 2025 14:32:21 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> Message-ID: <20250718213221.GJ8625@mcvoy.com> On Fri, Jul 18, 2025 at 01:58:12PM -0700, Bakul Shah wrote: > On Jul 18, 2025, at 3:09???AM, Larry McVoy wrote: > > In vim, you just have a split view of the same file. Changes in > > either window will show up in the other window. For example > > > > vim foo.c # foo.c exists and has a 100 lines > > :sp > > In nvi > :E > > > now you have both windows looking at the same file > > Ditto > > > start changing something and it is done in both windows. > > In nvi changes don't show up right away in the other window > but show up once you switch to it. So not as good as vim but > in practice it doesn't matter much since usually you show > *different* parts in two windows pointing at the same file. Hmm, when I tried nvi I don't think it had :E or I missed it. I read release notes so it's strange I didn't catch it. Or maybe it was added later because Keith was pretty focussed on 100% vi compat and I never saw :E in vi either. Whatever, you are happy with nvi, I'm happy with vim, so be it. Though I'm teaching my kid vim because I strongly suspect vim is much more widely used. This is starting to feel like a BSD vs Linux argument and we know how that turned out. From tuhs at tuhs.org Sat Jul 19 08:39:47 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 18 Jul 2025 15:39:47 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718213221.GJ8625@mcvoy.com> References: <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <20250718213221.GJ8625@mcvoy.com> Message-ID: On Jul 18, 2025, at 2:32 PM, Larry McVoy wrote: > > Hmm, when I tried nvi I don't think it had :E or I missed it. I read > release notes so it's strange I didn't catch it. Or maybe it was added > later because Keith was pretty focussed on 100% vi compat and I never > saw :E in vi either. vi didn't have this feature (or multiple undo/redo). Looking at nvi logs, split windows were added on April 5, 1993 by Bostic. [Doesn't seem that long ago :-(] From crossd at gmail.com Sat Jul 19 08:50:01 2025 From: crossd at gmail.com (Dan Cross) Date: Fri, 18 Jul 2025 18:50:01 -0400 Subject: [TUHS] primary sources for the 1966 Multics ASCII cutover as the first "Flag Day"? In-Reply-To: References: Message-ID: On Fri, Jul 18, 2025 at 5:02 PM Rich Salz wrote: > Interestingly, that phrasing comes directly from morticians.org. People are dying to find out what's on that site.... (Ok, sorry; clearly Rich typo'ed "multicians.org" here, but I couldn't resist.) >Or rather, instead of implying something, I should say that the wording between the two is exactly the same > > You could ask over on that site, I think there's some kind of mailing list, if there's more info available. There is. The multicians mailing list is very informative and friendly, but much lower traffic than TUHS. - Dan C. From trnsz at pobox.com Sat Jul 19 08:53:02 2025 From: trnsz at pobox.com (Jeff Johnson) Date: Fri, 18 Jul 2025 18:53:02 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718213221.GJ8625@mcvoy.com> References: <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <20250718213221.GJ8625@mcvoy.com> Message-ID: <39c4d84d-cd83-48e1-83ce-c5d1b6a9bc8d@app.fastmail.com> Yes, the editors can be very much a religious thing. There are actually three major actively maintained versions of nvi in current use: - Nvi1 - https://repo.or.cz/nvi.git - Nvi2 - https://github.com/lichray/nvi2 - OpenVi - https://github.com/johnsonjh/OpenVi Not directly related to Nvi, but Elvis (https://github.com/mbert/elvis) and Xvi (https://github.com/martinwguy/xvi) are also still maintained and have die-hard users. I actually know of several people who use Andy Valencia's Vim fork known as "Vim57" (https://sources.vsta.org:7100/vim57/tree) which forked from, you guessed it, Vim 5.7. His fork consists of simplifying the code and mostly removing things, for those that like Vim but prefer speed and minimalism. I use OpenVi quite a bit, and if you took away everything else from me, I'd be able to get along just fine, but I'm certainly a Vim user, and I spend most of my day driving NeoVim now. Teach your kid Vim! You can't go wrong knowing Vim, and that knowledge makes it easy drive the other editors in the Vi family (Vile, etc.) if he wants to. -- Jeffrey H. Johnson trnsz at pobox.com > Though I'm teaching my kid vim because I strongly suspect vim is much > more widely used. This is starting to feel like a BSD vs Linux argument > and we know how that turned out. From imp at bsdimp.com Sat Jul 19 08:55:10 2025 From: imp at bsdimp.com (Warner Losh) Date: Fri, 18 Jul 2025 16:55:10 -0600 Subject: [TUHS] primary sources for the 1966 Multics ASCII cutover as the first "Flag Day"? In-Reply-To: References: Message-ID: On Fri, Jul 18, 2025 at 4:50 PM Dan Cross wrote: > > On Fri, Jul 18, 2025 at 5:02 PM Rich Salz wrote: > > Interestingly, that phrasing comes directly from morticians.org. > > People are dying to find out what's on that site.... > > (Ok, sorry; clearly Rich typo'ed "multicians.org" here, but I couldn't resist.) I thought it was a purposeful choice to go from multicians to morticians after Multics had been retired for long enough :) With technical people, you never know... Warner From trnsz at pobox.com Sat Jul 19 08:57:03 2025 From: trnsz at pobox.com (Jeff Johnson) Date: Fri, 18 Jul 2025 18:57:03 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <39c4d84d-cd83-48e1-83ce-c5d1b6a9bc8d@app.fastmail.com> References: <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <20250718213221.GJ8625@mcvoy.com> <39c4d84d-cd83-48e1-83ce-c5d1b6a9bc8d@app.fastmail.com> Message-ID: <216ff802-fc49-4f45-825a-b6ddea1dc8f5@app.fastmail.com> Actually, Xvi is now maintained at https://codeberg.org/martinwguy/xvi. I'll bow out of the editor discussion now, since I think we're pretty far from the original topic. -- Jeffrey H. Johnson trnsz at pobox.com From chopps at chopps.org Sat Jul 19 09:45:24 2025 From: chopps at chopps.org (Christian Hopps) Date: Sat, 19 Jul 2025 01:45:24 +0200 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <47b5a6f8-8956-69fa-991a-39a80042faba@makerlisp.com> <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> Message-ID: <3F63CCF4-3053-4184-87A2-F709FD2C75CC@chopps.org> > On Jul 18, 2025, at 22:58, Bakul Shah via TUHS wrote: > >> And I don't understand the dislike of vim. > > It is more that some of us *prefer* nvi to vim. [I might've used > vim when it was first posted on Usenet but Braam refused to make > at least provide an option to make multiple undo/redo behavior > compatible to nvi. So it goes!] Agreed! nvi `u` undo/redo with the `.` repeat cmd is what nvi got very right and vim got wrong by comparison IMO. That feature alone had me preferring nvi forever (they both supported split windows :) I eventually gave up and just started using vim though b/c it was installed by default on Linux systems, which is what the vast majority of customers/companies want to use now. Thanks, Chris. P.S. Actually I had a soft spot in my heart for vim even when I preferred nvi b/c there was a native Amiga OS version, but that’s a topic for some other mailing list. :) From lm at mcvoy.com Sat Jul 19 09:46:05 2025 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 18 Jul 2025 16:46:05 -0700 Subject: [TUHS] xvi In-Reply-To: <216ff802-fc49-4f45-825a-b6ddea1dc8f5@app.fastmail.com> References: <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <20250718213221.GJ8625@mcvoy.com> <39c4d84d-cd83-48e1-83ce-c5d1b6a9bc8d@app.fastmail.com> <216ff802-fc49-4f45-825a-b6ddea1dc8f5@app.fastmail.com> Message-ID: <20250718234605.GK8625@mcvoy.com> On Fri, Jul 18, 2025 at 06:57:03PM -0400, Jeff Johnson wrote: > Actually, Xvi is now maintained at https://codeberg.org/martinwguy/xvi. > > I'll bow out of the editor discussion now, since I think we're pretty > far from the original topic. I can pull it back to something potentially useful. As I mentioned, years and years ago, on small memory machines, I used to vi $BIG_ASS_LOGFILE and because editors tend to malloc each line, the vi session got really slow (started swapping) when the file was bigger than roughly 1/2 of mem. My changes were to teach the string library, and whatever else operated on a line of the file, to treat \n the same way you would treat \0. Then you change the code that read in the file to just mmap() it. I don't think I went so far as to make changes to the file work, not sure, it may have just worked but I was looking at log files, I don't think I modified them. I'm pretty sure the answer is no, the laptop I'm typing on has 64GB and I suspect everyone else is the same. But can anyone imagine a use case where having a vi that could read really large files (and quickly, no parsing/mallocing each line) would be useful? I'm pretty done with programming but if someone said "here is an important use case where that would help" I'd go find those changes and see if I can port them forward. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Sat Jul 19 09:59:27 2025 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 18 Jul 2025 16:59:27 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <3F63CCF4-3053-4184-87A2-F709FD2C75CC@chopps.org> References: <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <3F63CCF4-3053-4184-87A2-F709FD2C75CC@chopps.org> Message-ID: <20250718235927.GA15357@mcvoy.com> On Sat, Jul 19, 2025 at 01:45:24AM +0200, Christian Hopps wrote: > > > > On Jul 18, 2025, at 22:58, Bakul Shah via TUHS wrote: > > > >> And I don't understand the dislike of vim. > > > > It is more that some of us *prefer* nvi to vim. [I might've used > > vim when it was first posted on Usenet but Braam refused to make > > at least provide an option to make multiple undo/redo behavior > > compatible to nvi. So it goes!] > > Agreed! nvi `u` undo/redo with the `.` repeat cmd is what nvi got very right and vim got wrong by comparison IMO. That feature alone had me preferring nvi forever (they both supported split windows :) Huh, I had to go play with how vim does it. vim, you hold down "u" to undo everything you've done (screen flashes when there is nothing left to undo) and you can go forward with ^R to replay your changes if you went too far. I sort of get "." to repeat the undo but does nvi have a way to redo the changes you originally did? I've used that to try and track down what change I did that caused things to break, being able to go back and forth is useful in a long debugging session. Another thing I like about vim is when you put stuff in a buffer, I don't know how it does this, but it remembers what you stored in a buffer across vim sessions. I have a giant .procmailrc where I filter every sales droid or whatever that spams me. I have yanked into a buffer an entry that I put back and change with the latest, I like that obscure feature. From tuhs at tuhs.org Sat Jul 19 11:05:37 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 18 Jul 2025 18:05:37 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718235927.GA15357@mcvoy.com> References: <11f46800-2fa5-4321-a45b-0473242e2510@gmail.com> <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <3F63CCF4-3053-4184-87A2-F709FD2C75CC@chopps.org> <20250718235927.GA15357@mcvoy.com> Message-ID: On Jul 18, 2025, at 4:59 PM, Larry McVoy wrote: > > I sort of get "." to repeat the undo but does nvi have a way to redo the > changes you originally did? I've used that to try and track down what > change I did that caused things to break, being able to go back and forth > is useful in a long debugging session. Let us say you want do undo last 4 changes. You type u... Now you want to redo 3 of them. You type u.. Basically the second u undoes the undo, and . means repeat! IIRC, in vi you could only undo one change. To redo you use u again. vim broke that. nvi extended it compatibly. [This may be a Europe/USA thing. In US a "toggle" button seems quite acceptable but perhaps the EU bought into "human factors design" which says to *not* use the same control for /opposite/ functions as it can likely increase confusion. Note: I may be completely wrong here but this was my guess!] From lm at mcvoy.com Sat Jul 19 11:13:00 2025 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 18 Jul 2025 18:13:00 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <3F63CCF4-3053-4184-87A2-F709FD2C75CC@chopps.org> <20250718235927.GA15357@mcvoy.com> Message-ID: <20250719011300.GD15357@mcvoy.com> On Fri, Jul 18, 2025 at 06:05:37PM -0700, Bakul Shah wrote: > On Jul 18, 2025, at 4:59???PM, Larry McVoy wrote: > > > > I sort of get "." to repeat the undo but does nvi have a way to redo the > > changes you originally did? I've used that to try and track down what > > change I did that caused things to break, being able to go back and forth > > is useful in a long debugging session. > > Let us say you want do undo last 4 changes. You type u... > Now you want to redo 3 of them. You type u.. > > Basically the second u undoes the undo, and . means repeat! Hmm, I might be dense but I like vims way of "u" means undo, ^R means put it back. I do like nvi's u...., I like the . but having "u" mean undo and redo seems weird. You say tomato I say tomato :) -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Sat Jul 19 11:40:02 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 19 Jul 2025 01:40:02 +0000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250719011300.GD15357@mcvoy.com> References: <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <3F63CCF4-3053-4184-87A2-F709FD2C75CC@chopps.org> <20250718235927.GA15357@mcvoy.com> <20250719011300.GD15357@mcvoy.com> Message-ID: On Friday, July 18th, 2025 at 6:13 PM, Larry McVoy wrote: > On Fri, Jul 18, 2025 at 06:05:37PM -0700, Bakul Shah wrote: > > > On Jul 18, 2025, at 4:59???PM, Larry McVoy lm at mcvoy.com wrote: > > > > > I sort of get "." to repeat the undo but does nvi have a way to redo the > > > changes you originally did? I've used that to try and track down what > > > change I did that caused things to break, being able to go back and forth > > > is useful in a long debugging session. > > > > Let us say you want do undo last 4 changes. You type u... > > Now you want to redo 3 of them. You type u.. > > > > Basically the second u undoes the undo, and . means repeat! > > > Hmm, I might be dense but I like vims way of "u" means undo, ^R means > put it back. I do like nvi's u...., I like the . but having "u" mean > undo and redo seems weird. > > You say tomato I say tomato :) > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat This undo behavior is one of the things that catches me off guard when I wind up in vim instead of nvi. Not to say which is better or worse I'm just wired for the nvi approach so when I hit 'u' again and it does another undo instead of undoing the undo, it throws me for a second. - Matt G. From tom.perrine+tuhs at gmail.com Sat Jul 19 12:44:12 2025 From: tom.perrine+tuhs at gmail.com (Tom Perrine) Date: Fri, 18 Jul 2025 19:44:12 -0700 Subject: [TUHS] primary sources for the 1966 Multics ASCII cutover as the first "Flag Day"? In-Reply-To: References: Message-ID: There are still a few Multics sites running - and semi-active community development. Courtesy of an old fork of SIMH that became a very full fledged DPS8/6800 simulator. I was running MR11 something on a Pi for a while, and then in GCP. Brought back old times - my second computer - after GCOS. *sigh* I think there may also be a reference to Flag Day in the original printed Hacker's Dictionary, and I think in the Jargon file from which it was derived? I don't have any old copies of either around to check --tep On Fri, Jul 18, 2025 at 4:02 PM Warner Losh wrote: > On Fri, Jul 18, 2025 at 4:50 PM Dan Cross wrote: > > > > On Fri, Jul 18, 2025 at 5:02 PM Rich Salz wrote: > > > Interestingly, that phrasing comes directly from morticians.org. > > > > People are dying to find out what's on that site.... > > > > (Ok, sorry; clearly Rich typo'ed "multicians.org" here, but I couldn't > resist.) > > I thought it was a purposeful choice to go from multicians to > morticians after Multics had been retired for long enough :) With > technical people, you never know... > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Sat Jul 19 13:02:25 2025 From: davida at pobox.com (David Arnold) Date: Sat, 19 Jul 2025 13:02:25 +1000 Subject: [TUHS] primary sources for the 1966 Multics ASCII cutover as the first "Flag Day"? In-Reply-To: References: Message-ID: <1420C1B1-923A-4ECE-A1EE-36CF542E7645@pobox.com> > On 19 Jul 2025, at 12:44, Tom Perrine wrote: <…> > I think there may also be a reference to Flag Day in the original printed Hacker's Dictionary, and I think in the Jargon file from which it was derived? I don't have any old copies of either around to check It’s in the “New Hackers Dicrionary” from 1991: https://www.dropbox.com/scl/fi/rwgb1ajk4n3sfkb2ejbd6/Photo-19-7-2025-12-54-49.jpg?rlkey=h7oujitglxgjo81ha1hfwhrg8&st=21m4tev8&dl=0 https://www.dropbox.com/scl/fi/v1h4myystwj0pirgcaa1z/Photo-19-7-2025-12-55-21.jpg?rlkey=klpksras27cstpsva6rce7mkl&st=e5hme9oi&dl=0 https://www.dropbox.com/scl/fi/jp4tlisj2j33ldzdt4n99/Photo-19-7-2025-12-56-27.jpg?rlkey=t0ry8hxzg9rj4xhwyi48ua6c2&st=knz9ujuk&dl=0 d -------------- next part -------------- An HTML attachment was scrubbed... URL: From trnsz at pobox.com Sat Jul 19 13:06:35 2025 From: trnsz at pobox.com (Jeff Johnson) Date: Fri, 18 Jul 2025 23:06:35 -0400 Subject: [TUHS] primary sources for the 1966 Multics ASCII cutover as the first "Flag Day"? In-Reply-To: References: Message-ID: Don't want to stray too off-topic but ... DPS8M development is quite active, see https://dps8m.gitlab.io/ - a new point release is coming soon, and other projects are in active development, like an FPGA implementation of the DN6678 (and eventually the DPS8/M CPU). A lot of the work is going into developer tooling for those projects, which isn't that interesting to the "general public", but the community is very busy. The guys working on it just spend more time hacking that posting updates about the work! (but we do have a blog at https://dps8m.gitlab.io/blog/). Since you mentioned GCOS, you should know that a lot of effort was recently spent to get the GCOS environment up and working. Note this is GCOS being emulated in Multics, not GCOS on the metal (yet - we need tapes). A better write-up is actually in progress, but for now you can check the Wiki page: https://multics-wiki.swenson.org/index.php/GCOS (And yes, the simulator was originally a fork of SIMH to start, but at this point it's barely related and future versions will have even less SIMH code. This isn't to knock that project at all, just that DPS8M simulator development has moved in a different direction.) As the Flag Day, the only reference that I know to it is the one on the multicians.org website. I could ask on the multicians list, or send an inquiry to Tom Van Vleck. -- Jeffrey H. Johnson trnsz at pobox.com On Fri, Jul 18, 2025, at 10:44 PM, Tom Perrine wrote: > There are still a few Multics sites running - and semi-active community development. > > Courtesy of an old fork of SIMH that became a very full fledged DPS8/6800 simulator. I was running MR11 something on a Pi for a while, and then in GCP. > > Brought back old times - my second computer - after GCOS. > > *sigh* > > I think there may also be a reference to Flag Day in the original printed Hacker's Dictionary, and I think in the Jargon file from which it was derived? I don't have any old copies of either around to check > > --tep -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Jul 19 13:11:21 2025 From: imp at bsdimp.com (Warner Losh) Date: Fri, 18 Jul 2025 21:11:21 -0600 Subject: [TUHS] primary sources for the 1966 Multics ASCII cutover as the first "Flag Day"? In-Reply-To: <1420C1B1-923A-4ECE-A1EE-36CF542E7645@pobox.com> References: <1420C1B1-923A-4ECE-A1EE-36CF542E7645@pobox.com> Message-ID: On Fri, Jul 18, 2025, 9:02 PM David Arnold wrote: > On 19 Jul 2025, at 12:44, Tom Perrine wrote: > > > <…> > > I think there may also be a reference to Flag Day in the original printed > Hacker's Dictionary, and I think in the Jargon file from which it was > derived? I don't have any old copies of either around to check > > > It’s in the “New Hackers Dicrionary” from 1991: > > > https://www.dropbox.com/scl/fi/rwgb1ajk4n3sfkb2ejbd6/Photo-19-7-2025-12-54-49.jpg?rlkey=h7oujitglxgjo81ha1hfwhrg8&st=21m4tev8&dl=0 > > > https://www.dropbox.com/scl/fi/v1h4myystwj0pirgcaa1z/Photo-19-7-2025-12-55-21.jpg?rlkey=klpksras27cstpsva6rce7mkl&st=e5hme9oi&dl=0 > > > https://www.dropbox.com/scl/fi/jp4tlisj2j33ldzdt4n99/Photo-19-7-2025-12-56-27.jpg?rlkey=t0ry8hxzg9rj4xhwyi48ua6c2&st=knz9ujuk&dl=0 > RFC 801 documents the NCP to TCP flag day of Jan 1, 1982. But doesn’t use that term despite latter day documents using that term. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sat Jul 19 14:39:50 2025 From: cowan at ccil.org (John Cowan) Date: Sat, 19 Jul 2025 00:39:50 -0400 Subject: [TUHS] xvi In-Reply-To: <20250718234605.GK8625@mcvoy.com> References: <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <20250718213221.GJ8625@mcvoy.com> <39c4d84d-cd83-48e1-83ce-c5d1b6a9bc8d@app.fastmail.com> <216ff802-fc49-4f45-825a-b6ddea1dc8f5@app.fastmail.com> <20250718234605.GK8625@mcvoy.com> Message-ID: I was involved in some work about five years ago where I had to keep a small number of files (about 5) open all the time for examination as needed. Each was 100-500 GB. I opened them all in vim instances running in the background at login time, and then I read email until they were all loaded. I then put the process with the file I needed into the foreground, examined it, and returned to the shell with :stop (which all command line editors should have) when I was done. Worked like a charm. On Fri, Jul 18, 2025, 7:46 PM Larry McVoy wrote: > On Fri, Jul 18, 2025 at 06:57:03PM -0400, Jeff Johnson wrote: > > Actually, Xvi is now maintained at https://codeberg.org/martinwguy/xvi. > > > > I'll bow out of the editor discussion now, since I think we're pretty > > far from the original topic. > > I can pull it back to something potentially useful. As I mentioned, years > and years ago, on small memory machines, I used to vi $BIG_ASS_LOGFILE > and because editors tend to malloc each line, the vi session got really > slow (started swapping) when the file was bigger than roughly 1/2 of mem. > My changes were to teach the string library, and whatever else operated > on a line of the file, to treat \n the same way you would treat \0. > Then you change the code that read in the file to just mmap() it. > > I don't think I went so far as to make changes to the file work, not > sure, it may have just worked but I was looking at log files, I don't > think I modified them. > > I'm pretty sure the answer is no, the laptop I'm typing on has 64GB and > I suspect everyone else is the same. But can anyone imagine a use case > where having a vi that could read really large files (and quickly, no > parsing/mallocing each line) would be useful? > > I'm pretty done with programming but if someone said "here is an important > use case where that would help" I'd go find those changes and see if I can > port them forward. > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bear at typewritten.org Sat Jul 19 18:43:03 2025 From: bear at typewritten.org (r.stricklin) Date: Sat, 19 Jul 2025 01:43:03 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718194349.GG8625@mcvoy.com> References: <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> Message-ID: > On Jul 18, 2025, at 12:43 PM, Larry McVoy wrote: > > Modern tools are more > complicated because they do more stuff. Taking your position to the extreme > would have you using a pipeline piped to ed, would it not? preface: none of this is to contradict your position. I was a little confused about the implications of your apparently contradictory statements, that if someone worked for you you’d force them to use vim, but also that people should be free to use what they like, but I don’t feel like I’m owed an explanation for it, so that isn’t why I’m replying. I never bothered to develop a complicated .exrc and I don’t do much of my programming in vi-like editors, so for the most part I’m not super invested in the feature differences between vi, nvi, vim, etc. I do prefer vi-alikes to other unix editors, but I can cope with ed when I need to. I probably wouldn’t choose to use Emacs unless I had no other choice, but I easily understand why some people do. The vast majority of my editor use is for systems-type tasks, so I don’t imagine it’s difficult to understand why I got here. When I do use vi for programming, it’s primarily to update existing code, but I could reasonably live with vi alone, if that was all I had. I am often surprised at my professional colleagues who insist they need vim in particular, and complain loudly when a vi-like editor that isn’t vim is all that is available. Almost without fail, these are the same guys I see get thrown when their terminal emulator isn’t letting them use the arrow keys to position the cursor, who only ever move the cursor around one row or column at a time, who only ever i or o, never I or O or A or c or C or $ or 10G or u or w or y or anything, who don’t know how to use any of the ex commands, read text in from files or commands, or use any number of other features more advanced than what you got in Windows notepad, and who insist, for some reason, that they need vim to “copy and paste”. Their incuriousness really serves to give me a reflexive (and as this thread reveals, admittedly sometimes also unfair) disdain toward someone who claims to “need” vim. That’s just an opinon, though, and as such, it’s worth a half pitcher of spit. I try not to get too hung up about it. Everybody needs a hobby. If it’s pounding ‘k’ and ‘l’ a hundred and seventy times in a row, then… boogie on down. Anyway. So it also turns out there are other reasons to prefer classic vi. One of the larger software projects I maintain (mostly using bbedit) is a network booted embedded linux system which hosts a ruby-based configuration management system, for doing standalone policy based configuration control of datacenter hardware resources (e.g. RAID configuration, firmware versions, BIOS settings, defect detection and reporting, etc.) It’s a relatively complex system solving a relatively complex problem, and the complex problem is what I want to stay focused on. So that makes limiting the number of external dependencies an important consideration for the project. Every external dependency becomes something that has to be downloaded at runtime, something that takes space in the ramdisk, and a set of binary artifacts that have to be tracked, integrated, and their lifecycle managed. It’s also important to be able to use the embedded linux system to investigate defects in the configuration management system, when they crop up, and although we get nano “for free” as a byproduct of having based the nucleus of the system around the Debian installer, there are a long list of reasons why nano is too obnoxious to live with. It was worth adding a vi-based editor to the system for such occasions. But the standard ‘vim’ has a relatively long list of external dependencies that we would be forced to carry along with it, and subsequently, to maintain in perpetuity. Even ‘vim-tiny’ and ‘nvi’ had longer lists of dependencies than I was happy with. I ended up adding ‘elvis-tiny’ to it, which is pretty much entirely self-contained. Entirely adequate for purpose, perfect on maintainability requirements. This is part of the calculus when folks say they find the feature bloat distasteful. It isn’t always about end-user experience (though sometimes… what the heck is going on with Jira these days?!? don’t answer that.) Which reminds me, tangentially: I often get tripped up by “helpful” vim features (I can’t tell you how many times I have accidentally opened an unwanted Help panel), but I categorize those as minor annoyances that I try not to get too hung up on. This time, though, I was using 'vim' on a remote system in an xterm, and wanted to copy and paste something into a different window. ‘vim’ took all the mouse events for itself and it wasn’t obvious (in the moment) how to make it stop. I can’t think of a time I ever wanted to use a mouse to directly control a vi session. That one made me rage a bit, although it was simple enough to fix (TERM=vt220, try again). I got over it. Obviously there is an entirely different set of tradeoffs if you’re installing an editor on a programmer’s workstation. But I wanted to be very concrete about why I don’t favor the idea that “vim is a 100% replacement for vi in every possible circumstance”. At least by the Debian maintainer standards, nvi depends on Berkeley DB. vim depends on SELinux, libacl, libsodium, gpm, and others. Why? (…he asked, rhetorically) ok bear. From bear at typewritten.org Sat Jul 19 19:20:58 2025 From: bear at typewritten.org (r.stricklin) Date: Sat, 19 Jul 2025 02:20:58 -0700 Subject: [TUHS] Your Most Prized UNIX Artifacts? In-Reply-To: <202507182103.56IL3rQA1096987@darkstar.fourwinds.com> References: <202507182103.56IL3rQA1096987@darkstar.fourwinds.com> Message-ID: In terms of unequivocally prized, I’d say the following: * HP 9050 * IBM 6152 Academic System * SGI Engineering Sample #3 - multibus CPU & framebuffer - these are early SUN boards from VLSI Systems who, as I understand it, were trying to commercialize the Stanford system separately from Sun. Clear genetic link with the Sun-1 CPU and bwone, but not identical to them. Nor to the 68000 CPU that ultimately shipped with the IRIS 1000/1200 terminals. * SGI IRIS 1200 * Sun 100U * Sun 150U In terms of wanting to mention because rarely seen, missing critical parts, and selfishly hoping to maybe shake something loose someday: * Ardent Titan - missing its console and primary graphics board * Dupont Pixel Systems MacBlitz - missing all the software, both for the Macintosh host and the Clipper C300 UNIX system itself * IBM 9377 Model 90 - actually not missing anything, but I’d quite like to hear that anything related to IX/370 or AIX/370 survived somewhere * mips RS4230 - The requisite RISC/os v5.01 media did turn up somewhat recently, thanks to everyone involved in that effort. Now I’m just hoping to eventually stumble over a new enough version of RISCwindows that will support the console framebuffer (v4.11 IIRC) * Pixar Image Computer - missing host interface board (SGI, Sun, anything) and pretty much all the software (Chap-C, etc.) * Sritek VersaCard - missing the MC68000 Xenix and PC interface software. * Sun FDDI/DX (VME) - missing the SunOS driver tape * Sun GT - busted, missing much in the way of hope tracking down the fault, never mind repairing * Sun TAAC-1 - missing the software A goodly measure of IBM RT AOS/4.3 software has been recovered and archived in the last couple years. Some of it from my own efforts. There are enough of the 6152-specific pieces that exist in situ to make a usable 6152 system, but they're not complete. It’d be nice to turn up some of the official distribution media for that. There’d have been a QIC tape adding the 6152-specific kernel pieces, maybe a floppy or two with the DOS and/or OS/2 host components (if they weren’t also on the tape). ok bear. From douglas.mcilroy at dartmouth.edu Sat Jul 19 20:55:28 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 19 Jul 2025 06:55:28 -0400 Subject: [TUHS] xvi Message-ID: > I opened them all in vim instances running in the background at login time, > and then I read email until they were all loaded. I then put the process > with the file I needed into the foreground, examined it, and returned to > the shell with :stop (which all command line editors should have) when I > was done. Worked like a charm. A curious mix of present and past tenses. Haven't window systems made foreground/background distinctions irrelevant to most applications, including editors? To my mind :stop is none of an editor's business. Doug From marzhall.o at gmail.com Sat Jul 19 22:24:20 2025 From: marzhall.o at gmail.com (Marshall Conover) Date: Sat, 19 Jul 2025 08:24:20 -0400 Subject: [TUHS] xvi In-Reply-To: References: Message-ID: In my experience, for the sake of mental organization and not sending the wrong command to the wrong place, there's a case to be made for "namespacing" all activity around a certain task/environment in a singular shell, which makes job handling with fore- and backgrounding relevant. For example, I'll be iterating on a script targeting a new deployment environment that requires certain env vars and a history of related commands, then running it to see if it works, and reflexively I'm more likely to open & edit the script, then ctrl+z the editor and run the script than to open the editor in a separate window in my experience. That said, I certainly have sometimes thought "you know, you could just edit the script in another window." I did only just learn about ":stop" with this message, though. For me, the surprising thing is implementing in vim what users can do by hitting ctrl+z (and which I do daily in vim with ctrl+z). Even before getting to the window system, the shell's already got this covered by giving you the ability to background the application: why add lines of code to your application to do it again? But perhaps there is a scripting utility to having it within vim itself. Cheers, Marshall On Sat, Jul 19, 2025 at 7:02 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > I opened them all in vim instances running in the background at login > time, > > and then I read email until they were all loaded. I then put the process > > with the file I needed into the foreground, examined it, and returned to > > the shell with :stop (which all command line editors should have) when I > > was done. Worked like a charm. > > A curious mix of present and past tenses. Haven't window systems made > foreground/background distinctions irrelevant to most applications, > including editors? To my mind :stop is none of an editor's business. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethgoodwin56 at gmail.com Sat Jul 19 22:25:56 2025 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Sat, 19 Jul 2025 08:25:56 -0400 Subject: [TUHS] Your Most Prized UNIX Artifacts? In-Reply-To: References: <202506091611.559GBKZJ397819@freefriends.org> <4-qJVuQM7Jgik3HG9UukaN3NXJSFwGeqyP5ChnzKLRP-k3pCVD5kLjsrxl8kGGF9pnrovp91wleJFXKLrc-XK3Wv9tk0g4Pz7YfeTCqTKJw=@protonmail.ch> Message-ID: Regarding It's still fun to think about. . On the lighter side of life Perspectives in eternity The Ghost in the Machine What happens to core images when they finally fade away? Do they go to some binary form of heaven ? Do their bits roam free on some ethereal plane of existence 🤔? According to the laws of physics, nothing gets created or destroyed. It merely changes state. Would a V6 image be reincarnated as itself or would it come back as a new Linux variant? What happens to the electrons and magnetic fields that composed its essence when it was "alive" flowing through copper channels and silicon valleys? Time to journey up the mountain and contemplate the existential nature of silicon based "life forms" (Geek humor for a Saturday morning 🌄) On Fri, Jul 18, 2025, 6:42 PM ron minnich wrote: > I was admiring this list of cool artifacts, thinking I had none, then > remembered in the corner I have a 64K PDP11 core plane, which, when it > failed, had a V6 kernel image in it. > > Now, that was 50 years ago, so magnetic donuts or no, that image is long > gone, but it's still fun to think about. > > Also, I have a DECTape from the late Jim McKie, somewhere, but I forget > what was on it. > > I still have my "documents for use with ..." book, and the BSTJ, but so do > many of you ;-) > > Finally, somewhere, I also have a budget page from a document I found in a > dumpster at Murray Hill. This would have been 2007, or so, when lots of > people were leaving and lots of offices were being "dumpster lobotomized"; > I saw the doc in a dumpster and ripped out that page. It seemed of interest. > > > On Fri, Jun 13, 2025 at 7:27 PM Daria Phoebe Brashear > wrote: > >> >> >> On Wed, Jun 11, 2025 at 18:35 Greg A. Woods wrote: >> >>> At Tue, 10 Jun 2025 12:10:28 +1000, Rob Pike wrote: >>> Subject: [TUHS] Re: Your Most Prized UNIX Artifacts? >>> > >>> > An original, hand-wire-wrapped Jerq board, later renamed Blit because >>> of >>> > marketing. Also the original mouse, made by Prof Nicoud's lab and >>> signed by >>> > him on the bottom. >>> >>> The mice that came with the DMD-5620s, the Dépraz Mouse, "Made in >>> Switzerland" (one of mine says "Type D 85 / P") looks very similar. I >>> have one in an original AT&T package too. >>> >> >> Ah yes. Mice. I still have two new-in-their-boxes DEC Hawley puck mice. >> VSXXX-AA, with two rollers. >> >> They kept tracking reliably whereas the ball variant always got gunked up >> and skipped, but our DEC mice tended to succumb to Nettrek disease, where >> the left button would get clicked to death, and the replacements were >> inevitably the ball version. >> >> I never managed to source a wheel version at the time to just carry with >> me. Got two years later, planning to give one to a friend a few months >> older than me for his collection. Cancer intervened and he is several years >> gone now, alas. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cloos at jhcloos.com Sun Jul 20 00:17:39 2025 From: cloos at jhcloos.com (James Cloos) Date: Sat, 19 Jul 2025 10:17:39 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> Message-ID: >>>>> "rs" == r stricklin writes: rs> I ended up adding ‘elvis-tiny’ to rs> it, which is pretty much entirely self-contained. Entirely adequate rs> for purpose, perfect on maintainability requirements. busybox vi is also a good choice for tight systems. especially when using bb for other applications, of course. i often keep a `ln -s busybox /bin/vi` around when i want something small and quick. (and vimdiff for gentoo's etc-update.) (but emacs for most editing. :) -JimC -- James Cloos OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc From clemc at ccc.com Sun Jul 20 00:46:18 2025 From: clemc at ccc.com (Clem Cole) Date: Sat, 19 Jul 2025 10:46:18 -0400 Subject: [TUHS] foreground/background vs. Windowing In-Reply-To: References: Message-ID: On Sat, Jul 19, 2025 at 6:55 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > Haven't window systems made foreground/background distinctions irrelevant > to most applications, including editors? > An interesting observation. It's true that I have not used ^Z or :stop, since I've had a window system. I keep lots of terminal windows open and switch back and forth. One of the "features" of MacVIM is that when I type: vi to the command prompt, it's forked in its own (separate) window from the terminal/shell window, so the desire/need of something like ^Z for the editor that I used to need to do in my 4.XBSD days are unnecessary. That said, if you are running on a windowless system, I can see its value. For instance, when I'm ssh'ed into a Linux box like my PiDPs, I might need to do. That said, I run VNC and a window manager on them, so needing to fall back to an ssh session is not a usual manner that I access them. FWIW: I have nvi as the editor on my Linux boxes, as it's all I need there. But as I said, I do run MacVIM because of the integration with the Apple Windowing system. As I also like to point out, one of my favorite features of UNIX is >>not<< being pushed into one way of doing things. UNIX often offers multiple solutions to a problem, and unlike the MSFT and, too often, the Apple world, does not try to dictate how I must do something. As always, the editor you use is a personal choice, and I understand and accept that. It's all about what you do most effectively to do your job. What is "best" for you might not be "best" for me, and I like having a choice. But I do think that Doug is correct, that for >>this<< particular feature, it's not clear whether it's solved in a better manner if you have a window system; but if that's how you work, go for it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Jul 20 01:24:08 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Sat, 19 Jul 2025 08:24:08 -0700 Subject: [TUHS] xvi In-Reply-To: References: Message-ID: <0766533D-0675-4FF1-AED8-310588488E9E@iitbombay.org> On Jul 19, 2025, at 3:55 AM, Douglas McIlroy wrote: > >> I opened them all in vim instances running in the background at login time, >> and then I read email until they were all loaded. I then put the process >> with the file I needed into the foreground, examined it, and returned to >> the shell with :stop (which all command line editors should have) when I >> was done. Worked like a charm. > > A curious mix of present and past tenses. Haven't window systems made > foreground/background distinctions irrelevant to most applications, > including editors? To my mind :stop is none of an editor's business. If an editor is stopped, it needs to at least pay heed to the SIGCONT so as to restore its terminal state. It need not have a command to stop itself. But I think you are asking why not just use a different window. I do a lot of work logged in via ssh and have remote screen(1) sessions that persist for a long time. Remote X window apps that open on my laptop disconnect if I put the lid down on my macbookpro. Most of my work is in remote text windows and I end up using ^Z a lot. Ideally I want all my computers (& VMs) to collaborate and present a single virtual computer (VC) and all the 2D windows be truly /windows/ on that VC, where I can interact with the same programs from any window. Apple sort of does a bit of this with their apps (e.g. you can pickup a call on your laptop, watch, etc. Access photos, music, browser windows etc.) but ideally one should not have to rely on a third party shared storage such as iCloud for one's own data. plan9 style cpu commands don't quite meet that ideal (not to mention plan9 itself never took off). But this is quite a tangent so I will stop now :-) From imp at bsdimp.com Sun Jul 20 01:32:08 2025 From: imp at bsdimp.com (Warner Losh) Date: Sat, 19 Jul 2025 09:32:08 -0600 Subject: [TUHS] Your Most Prized UNIX Artifacts? In-Reply-To: References: <202507182103.56IL3rQA1096987@darkstar.fourwinds.com> Message-ID: On Sat, Jul 19, 2025 at 3:22 AM r.stricklin wrote: > * mips RS4230 - The requisite RISC/os v5.01 media did turn up somewhat recently, thanks to everyone involved in that effort. Now I’m just hoping to eventually stumble over a new enough version of RISCwindows that will support the console framebuffer (v4.11 IIRC) Hmmm, I have the following QIC-150 tapes o MIPS RISC/os Version 4.52 Binary Software Tape 1 of 2 Part Number 06-00147-002 o MIPS RISC/os Version 4.5.2 Binary Software Tape 2 of 2 Part Number 06-00147-002 o MIPS RISCwindows Version 4.00 Binary Software Tape 1 of 1 Part Number 01-00167 Plus all of it on a hard disk I took out of my MIPS RS4230 that I still have... It had a color frame buffer and a big honkin monitor. I don't know if I still have the color card or not. I don't have the monitor... Don't know if the tapes would work, but it looks like http://www.bitsavers.org/bits/MIPS/ already has all this... Including the sources.... HMMM... Warner From ats at offog.org Sun Jul 20 01:34:32 2025 From: ats at offog.org (Adam Sampson) Date: Sat, 19 Jul 2025 16:34:32 +0100 Subject: [TUHS] primary sources for the 1966 Multics ASCII cutover as the first "Flag Day"? In-Reply-To: (Royce Williams's message of "Fri, 18 Jul 2025 11:42:48 -0800") References: Message-ID: Royce Williams writes: > I don't doubt the validity, but I'm looking for other "citation > worthy" sources that supplement this claim --- ideally that predate > the ESR ones, so that they are unambiguously independent. You can see the early history of the Jargon File through the SAIL copy, which is AIWORD.RF in this directory: https://www.saildart.org/[UP,DOC]/ The FLAG DAY entry was added between 1977-02-01 and 1977-03-11, and initially read: | FLAG DAY [from a bit of Multics history involving a change in the | ASCII character set originally scheduled for June 14, 1966] | n. A software change which is neither forward nor backward | compatible, and which is costly to make and costly to revert. | "Can we install that without causing a flag day for all users?" That appears to be the earliest instance of the term in the public SAILDART files. The next I could see is in a mail message from Mark Crispin on 1977-10-01. (He must have liked the term; in the utzoo Usenet archive, quite a lot of the early examples are from him too!) -- Adam Sampson From clemc at ccc.com Sun Jul 20 01:46:21 2025 From: clemc at ccc.com (Clem Cole) Date: Sat, 19 Jul 2025 11:46:21 -0400 Subject: [TUHS] primary sources for the 1966 Multics ASCII cutover as the first "Flag Day"? In-Reply-To: References: Message-ID: On Sat, Jul 19, 2025 at 11:34 AM Adam Sampson wrote: > > The FLAG DAY entry was added between 1977-02-01 and 1977-03-11 > This matches my memory. BTW: 1975 it was in day-to-day lingo in the ARPANET community, such as I was in at CMU, so I suspect it was from much earlier, such as the Multics reference. At some point - which looks like early 1977, someone added it to the Jargon file, but it was hardly a new term by then. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Jul 20 02:29:09 2025 From: tuhs at tuhs.org (Harald Arnesen via TUHS) Date: Sat, 19 Jul 2025 18:29:09 +0200 Subject: [TUHS] foreground/background vs. Windowing In-Reply-To: References: Message-ID: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Clem Cole [2025-07-19 16:46:18]: > On Sat, Jul 19, 2025 at 6:55 AM Douglas McIlroy > > > wrote: > > Haven't window systems madeforeground/background distinctions > irrelevant to most applications,including editors? > > An interesting observation.  It's true that I have not used > ^Zor :stop,since I've had a window system.  I keep lots of terminal > windows open and switch back and forth.  One of the "features" of MacVIM > is that when I type: vito the command prompt, it's forked in its own > (separate) window from the terminal/shell window, so the desire/need of > something like ^Z for the editor that I used to need to do in my > 4.XBSD days are unnecessary. I still like to use ^Z to suspend a running program, even when I use X11. That's really the reason I haven't changed my login shell to rc, because it lacks job control. -- Hilsen Harald From imp at bsdimp.com Sun Jul 20 02:42:31 2025 From: imp at bsdimp.com (Warner Losh) Date: Sat, 19 Jul 2025 10:42:31 -0600 Subject: [TUHS] foreground/background vs. Windowing In-Reply-To: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: On Sat, Jul 19, 2025 at 10:29 AM Harald Arnesen via TUHS wrote: > > Clem Cole [2025-07-19 16:46:18]: > > > On Sat, Jul 19, 2025 at 6:55 AM Douglas McIlroy > > > > > wrote: > > > > Haven't window systems madeforeground/background distinctions > > irrelevant to most applications,including editors? > > > > An interesting observation. It's true that I have not used > > ^Zor :stop,since I've had a window system. I keep lots of terminal > > windows open and switch back and forth. One of the "features" of MacVIM > > is that when I type: vito the command prompt, it's forked in its own > > (separate) window from the terminal/shell window, so the desire/need of > > something like ^Z for the editor that I used to need to do in my > > 4.XBSD days are unnecessary. > > I still like to use ^Z to suspend a running program, even when I use > X11. That's really the reason I haven't changed my login shell to rc, > because it lacks job control. Yea, I use both. It all depends on what I'm doing. But my brain is tainted by emacs, so that could be the answer :) There have been no good gui adaptations of emacs that make me want to use. Warner From pugs78 at gmail.com Sun Jul 20 03:02:12 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Sat, 19 Jul 2025 10:02:12 -0700 Subject: [TUHS] Your Most Prized UNIX Artifacts? In-Reply-To: References: <202507182103.56IL3rQA1096987@darkstar.fourwinds.com> Message-ID: FWIW, "VLSI Systems" was Andy Bechtolsheim's company that licensed the Stanford Sun designs to many companies. When Sun was started, VLSI Systems was rolled into Sun. Sun's first revenue products were 3Mb Ethernet cards which still said VLSI Systems on them. BTW, if anyone actually has one of these 3Mb board, Robert Garner would love to get his hands on one. He's working on a detailed history of Ethernet. Robert's probably not on this list, but I can connect folks to him. On Sat, Jul 19, 2025 at 2:22 AM r.stricklin wrote: > In terms of unequivocally prized, I’d say the following: > > * HP 9050 > * IBM 6152 Academic System > * SGI Engineering Sample #3 - multibus CPU & framebuffer - these are early > SUN boards from VLSI Systems who, as I understand it, were trying to > commercialize the Stanford system separately from Sun. Clear genetic link > with the Sun-1 CPU and bwone, but not identical to them. Nor to the 68000 > CPU that ultimately shipped with the IRIS 1000/1200 terminals. > * SGI IRIS 1200 > * Sun 100U > * Sun 150U > > In terms of wanting to mention because rarely seen, missing critical > parts, and selfishly hoping to maybe shake something loose someday: > > * Ardent Titan - missing its console and primary graphics board > * Dupont Pixel Systems MacBlitz - missing all the software, both for the > Macintosh host and the Clipper C300 UNIX system itself > * IBM 9377 Model 90 - actually not missing anything, but I’d quite like to > hear that anything related to IX/370 or AIX/370 survived somewhere > * mips RS4230 - The requisite RISC/os v5.01 media did turn up somewhat > recently, thanks to everyone involved in that effort. Now I’m just hoping > to eventually stumble over a new enough version of RISCwindows that will > support the console framebuffer (v4.11 IIRC) > * Pixar Image Computer - missing host interface board (SGI, Sun, anything) > and pretty much all the software (Chap-C, etc.) > * Sritek VersaCard - missing the MC68000 Xenix and PC interface software. > * Sun FDDI/DX (VME) - missing the SunOS driver tape > * Sun GT - busted, missing much in the way of hope tracking down the > fault, never mind repairing > * Sun TAAC-1 - missing the software > > A goodly measure of IBM RT AOS/4.3 software has been recovered and > archived in the last couple years. Some of it from my own efforts. There > are enough of the 6152-specific pieces that exist in situ to make a usable > 6152 system, but they're not complete. It’d be nice to turn up some of the > official distribution media for that. There’d have been a QIC tape adding > the 6152-specific kernel pieces, maybe a floppy or two with the DOS and/or > OS/2 host components (if they weren’t also on the tape). > > > ok > bear. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Jul 20 03:53:10 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 19 Jul 2025 10:53:10 -0700 Subject: [TUHS] Was artifacts, now ethernet In-Reply-To: References: <202507182103.56IL3rQA1096987@darkstar.fourwinds.com> Message-ID: <20250719175310.GF15357@mcvoy.com> I'd like to talk to Robert because I'm willing to bet how 100Mb ethernet came to be is not well known. Feel free to forward this to him. Somewhere in the early middle-ish 90s, I was working for Ken Okin in the server hardware division, building Sun's first cluster. It was just a bunch of small servers behind a modified kalpana ethernet switch (the mods were my version of VLANs, I didn't know VLANs existed at that time). The Kalpana switch opened my eyes to what ethernet could do and could evolve to in the future if we made ethernet faster. So I wandered over to Sun's networking hardware and asked if they could build 100Mb ethernet over copper. I was too stupid to realize that they thought I was asking them to signal at 100Mb the same way they signaled at 10Mb. Which doesn't work because of crosstalk issues (which I didn't know about at the time, I'm more software than hardware). So they told it couldn't be done and I went back to SMCC with my tail between my legs. It's worth noting that I was sitting one office away from avb and we had past history. I got him to redesign some memory interconnect because I had actual memory latency results from all the current hardware (everyone's not just Suns) and I had a pretty good idea of all the roadmaps because the processor architects talked to me because they loved the micro benchmarks in LMbench because they were tiny and ran fast on their simulators. The design he had was gonna suck and make us look bad so he stopped the project and designed a lower latency one. That's a long way of saying that avb had some respect for me. One day, a company called Crescendo Communications showed up to pitch me CDDI which was FDDI over copper. That signaled at 100Mb. As soon as I got it, I asked them to wait, went and told avb he needed to hear this. Pulled him into the conference room, told them this is Sun employee #1, can you do the pitch again. It's worth noting they did not ask us to sign an NDA. We're walking back to our offices and avb sort of grins and says something like "Are you thinking what I'm thinking?" I said "yup, 100Mb ethernet, nobody wants FDDI packets if they could have ethernet packets". Here is why it is unlikely that anyone knows about this. Andy did something very smart, he said this couldn't be a Sun project, it would die if it were. Sun had done mmap, vnodes, NFS, RPC, etc, and the rest of the industry was sick and tired of chasing Sun. The whole OSF thing was basically "everyone but Sun". Andy said here is what we're gonna do (I did some but it was mostly him at this point): we're getting in our cars and we're calling on every networking company in the value, we're looking for a high up engineer or their lead architect. And all we're gonna say is "did you know that you can signal over copper at 100Mb like this? Wouldn't it be nice if we got 100Mb ethernet?" And it worked. It wasn't a Sun project, noone remembered that I had anything to do with it, Andy kept a very low profile, and I believe we got 100Mb "ethernet" cards trickling out in about 6 months. In quotes because it wasn't a standard yet. The funny thing is I've done a lot of other stuff that people know about, but I'm more proud of the fact that I pushed for 100Mb and it actually happened, that's a far bigger deal than anything else I've done (and I know, I didn't do 100Mb ethernet but I saw it before anyone else did and pushed for it and Andy, and to some extent, I made it happen). I also did a back of the paper napkin design of the ethernet switch that Granite built, Andy found me in a bar in San Francisco (or somewhere up there) and asked me if I could have a perfect ethernet switch what would it look like. But that's a different story and probably not for here. On Sat, Jul 19, 2025 at 10:02:12AM -0700, Tom Lyon wrote: > FWIW, "VLSI Systems" was Andy Bechtolsheim's company that licensed the > Stanford Sun designs to many companies. When Sun was started, VLSI Systems > was rolled into Sun. > > Sun's first revenue products were 3Mb Ethernet cards which still said VLSI > Systems on them. > BTW, if anyone actually has one of these 3Mb board, Robert Garner would > love to get his hands on one. He's working on a detailed history of > Ethernet. Robert's probably not on this list, but I can connect folks to > him. > > On Sat, Jul 19, 2025 at 2:22???AM r.stricklin wrote: > > > In terms of unequivocally prized, I???d say the following: > > > > * HP 9050 > > * IBM 6152 Academic System > > * SGI Engineering Sample #3 - multibus CPU & framebuffer - these are early > > SUN boards from VLSI Systems who, as I understand it, were trying to > > commercialize the Stanford system separately from Sun. Clear genetic link > > with the Sun-1 CPU and bwone, but not identical to them. Nor to the 68000 > > CPU that ultimately shipped with the IRIS 1000/1200 terminals. > > * SGI IRIS 1200 > > * Sun 100U > > * Sun 150U > > > > In terms of wanting to mention because rarely seen, missing critical > > parts, and selfishly hoping to maybe shake something loose someday: > > > > * Ardent Titan - missing its console and primary graphics board > > * Dupont Pixel Systems MacBlitz - missing all the software, both for the > > Macintosh host and the Clipper C300 UNIX system itself > > * IBM 9377 Model 90 - actually not missing anything, but I???d quite like to > > hear that anything related to IX/370 or AIX/370 survived somewhere > > * mips RS4230 - The requisite RISC/os v5.01 media did turn up somewhat > > recently, thanks to everyone involved in that effort. Now I???m just hoping > > to eventually stumble over a new enough version of RISCwindows that will > > support the console framebuffer (v4.11 IIRC) > > * Pixar Image Computer - missing host interface board (SGI, Sun, anything) > > and pretty much all the software (Chap-C, etc.) > > * Sritek VersaCard - missing the MC68000 Xenix and PC interface software. > > * Sun FDDI/DX (VME) - missing the SunOS driver tape > > * Sun GT - busted, missing much in the way of hope tracking down the > > fault, never mind repairing > > * Sun TAAC-1 - missing the software > > > > A goodly measure of IBM RT AOS/4.3 software has been recovered and > > archived in the last couple years. Some of it from my own efforts. There > > are enough of the 6152-specific pieces that exist in situ to make a usable > > 6152 system, but they're not complete. It???d be nice to turn up some of the > > official distribution media for that. There???d have been a QIC tape adding > > the 6152-specific kernel pieces, maybe a floppy or two with the DOS and/or > > OS/2 host components (if they weren???t also on the tape). > > > > > > ok > > bear. > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Sun Jul 20 04:07:22 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 19 Jul 2025 11:07:22 -0700 Subject: [TUHS] Was artifacts, now ethernet In-Reply-To: <20250719175310.GF15357@mcvoy.com> References: <202507182103.56IL3rQA1096987@darkstar.fourwinds.com> <20250719175310.GF15357@mcvoy.com> Message-ID: <20250719180722.GG15357@mcvoy.com> On Sat, Jul 19, 2025 at 10:53:10AM -0700, Larry McVoy wrote: > Andy said here is what we're gonna do (I did some but it was mostly him > at this point): we're getting in our cars and we're calling on every > networking company in the value, we're looking for a high up engineer s/value/valley/ Sigh. From steffen at sdaoden.eu Sun Jul 20 03:53:23 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 19 Jul 2025 19:53:23 +0200 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> Message-ID: <20250719175323._4__CMQ_@steffen%sdaoden.eu> r.stricklin wrote in : set mouse= " No mouse!! --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From steffen at sdaoden.eu Sun Jul 20 04:07:07 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 19 Jul 2025 20:07:07 +0200 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> Message-ID: <20250719180707.UKGSO3oA@steffen%sdaoden.eu> James Cloos wrote in : |>>>>> "rs" == r stricklin writes: | |rs> I ended up adding ‘elvis-tiny’ to |rs> it, which is pretty much entirely self-contained. Entirely adequate |rs> for purpose, perfect on maintainability requirements. | |busybox vi is also a good choice for tight systems. especially when |using bb for other applications, of course. it is (too, for me) super-tight. |i often keep a `ln -s busybox /bin/vi` around when i want something |small and quick. | |(and vimdiff for gentoo's etc-update.) | |(but emacs for most editing. :) For years and years i want to go to Thomas Dickey's vile, but just cannot get there. "Problem with" nvi and nvi2 is they do not compile out of the box of their repository, and nvi2 does not go at all here because it does not include the Berkeley DBv1, and Linux does not have it, nvi just includes the few kilobyte. (Btw OpenBSD has the usr.bin/mg, an emacs-style thing, but pretty small. I do not know wether someone somewhere has the small make compatibility shim to make it a portable thing.) --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From trnsz at pobox.com Sun Jul 20 04:21:04 2025 From: trnsz at pobox.com (Jeff Johnson) Date: Sat, 19 Jul 2025 14:21:04 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250719180707.UKGSO3oA@steffen%sdaoden.eu> References: <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <20250719180707.UKGSO3oA@steffen%sdaoden.eu> Message-ID: <393d865b-00db-4064-a84a-3adca8d9554f@app.fastmail.com> You should try OpenVi - which is easy to build and includes the OpenBSD’s db and regex dependencies in the tree - https://github.com/johnsonjh/OpenVi -- Jeffrey H. Johnson trnsz at pobox.com > For years and years i want to go to Thomas Dickey's vile, but just > cannot get there. > > "Problem with" nvi and nvi2 is they do not compile out of the box > of their repository, and nvi2 does not go at all here because it > does not include the Berkeley DBv1, and Linux does not have it, > nvi just includes the few kilobyte. > > (Btw OpenBSD has the usr.bin/mg, an emacs-style thing, but pretty > small. I do not know wether someone somewhere has the small make > compatibility shim to make it a portable thing.) > > --steffen From pugs78 at gmail.com Sun Jul 20 04:53:20 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Sat, 19 Jul 2025 11:53:20 -0700 Subject: [TUHS] Was artifacts, now ethernet In-Reply-To: <20250719175310.GF15357@mcvoy.com> References: <202507182103.56IL3rQA1096987@darkstar.fourwinds.com> <20250719175310.GF15357@mcvoy.com> Message-ID: The other bit of this story that I've heard from Andy is that there was some kind of gentlemen's agreement between the IEEE 802 and ANSI/FDDI committees - to have Ethernet stick to 10Mb and let FDDI do 100Mb. Seems, at least in retrospect, to be incredibly stupid. And then there was HP with 100Base-VG (iirc). Sigh. You and Andy understood that faster Ethernet was all that was needed. On Sat, Jul 19, 2025 at 11:17 AM Larry McVoy wrote: > I'd like to talk to Robert because I'm willing to bet how 100Mb ethernet > came to be is not well known. Feel free to forward this to him. > > Somewhere in the early middle-ish 90s, I was working for Ken Okin in the > server hardware division, building Sun's first cluster. It was just a > bunch of small servers behind a modified kalpana ethernet switch (the > mods were my version of VLANs, I didn't know VLANs existed at that time). > The Kalpana switch opened my eyes to what ethernet could do and could > evolve to in the future if we made ethernet faster. > > So I wandered over to Sun's networking hardware and asked if they could > build 100Mb ethernet over copper. I was too stupid to realize that they > thought I was asking them to signal at 100Mb the same way they signaled > at 10Mb. Which doesn't work because of crosstalk issues (which I didn't > know about at the time, I'm more software than hardware). So they told > it couldn't be done and I went back to SMCC with my tail between my legs. > > It's worth noting that I was sitting one office away from avb and we had > past history. I got him to redesign some memory interconnect because > I had actual memory latency results from all the current hardware > (everyone's not just Suns) and I had a pretty good idea of all the > roadmaps because the processor architects talked to me because they > loved the micro benchmarks in LMbench because they were tiny and ran > fast on their simulators. The design he had was gonna suck and make > us look bad so he stopped the project and designed a lower latency one. > > That's a long way of saying that avb had some respect for me. > > One day, a company called Crescendo Communications showed up to pitch me > CDDI which was FDDI over copper. That signaled at 100Mb. As soon as I > got it, I asked them to wait, went and told avb he needed to hear this. > Pulled him into the conference room, told them this is Sun employee #1, > can you do the pitch again. > > It's worth noting they did not ask us to sign an NDA. > > We're walking back to our offices and avb sort of grins and says something > like "Are you thinking what I'm thinking?" I said "yup, 100Mb ethernet, > nobody wants FDDI packets if they could have ethernet packets". > > Here is why it is unlikely that anyone knows about this. Andy did > something very smart, he said this couldn't be a Sun project, it would > die if it were. Sun had done mmap, vnodes, NFS, RPC, etc, and the rest > of the industry was sick and tired of chasing Sun. The whole OSF thing > was basically "everyone but Sun". > > Andy said here is what we're gonna do (I did some but it was mostly him > at this point): we're getting in our cars and we're calling on every > networking company in the value, we're looking for a high up engineer > or their lead architect. And all we're gonna say is "did you know that > you can signal over copper at 100Mb like this? Wouldn't it be nice if > we got 100Mb ethernet?" > > And it worked. It wasn't a Sun project, noone remembered that I had > anything to do with it, Andy kept a very low profile, and I believe we > got 100Mb "ethernet" cards trickling out in about 6 months. In quotes > because it wasn't a standard yet. > > The funny thing is I've done a lot of other stuff that people know about, > but I'm more proud of the fact that I pushed for 100Mb and it actually > happened, that's a far bigger deal than anything else I've done (and I > know, I didn't do 100Mb ethernet but I saw it before anyone else did > and pushed for it and Andy, and to some extent, I made it happen). > > I also did a back of the paper napkin design of the ethernet switch that > Granite built, Andy found me in a bar in San Francisco (or somewhere up > there) and asked me if I could have a perfect ethernet switch what would > it look like. But that's a different story and probably not for here. > > On Sat, Jul 19, 2025 at 10:02:12AM -0700, Tom Lyon wrote: > > FWIW, "VLSI Systems" was Andy Bechtolsheim's company that licensed the > > Stanford Sun designs to many companies. When Sun was started, VLSI > Systems > > was rolled into Sun. > > > > Sun's first revenue products were 3Mb Ethernet cards which still said > VLSI > > Systems on them. > > BTW, if anyone actually has one of these 3Mb board, Robert Garner would > > love to get his hands on one. He's working on a detailed history of > > Ethernet. Robert's probably not on this list, but I can connect folks to > > him. > > > > On Sat, Jul 19, 2025 at 2:22???AM r.stricklin > wrote: > > > > > In terms of unequivocally prized, I???d say the following: > > > > > > * HP 9050 > > > * IBM 6152 Academic System > > > * SGI Engineering Sample #3 - multibus CPU & framebuffer - these are > early > > > SUN boards from VLSI Systems who, as I understand it, were trying to > > > commercialize the Stanford system separately from Sun. Clear genetic > link > > > with the Sun-1 CPU and bwone, but not identical to them. Nor to the > 68000 > > > CPU that ultimately shipped with the IRIS 1000/1200 terminals. > > > * SGI IRIS 1200 > > > * Sun 100U > > > * Sun 150U > > > > > > In terms of wanting to mention because rarely seen, missing critical > > > parts, and selfishly hoping to maybe shake something loose someday: > > > > > > * Ardent Titan - missing its console and primary graphics board > > > * Dupont Pixel Systems MacBlitz - missing all the software, both for > the > > > Macintosh host and the Clipper C300 UNIX system itself > > > * IBM 9377 Model 90 - actually not missing anything, but I???d quite > like to > > > hear that anything related to IX/370 or AIX/370 survived somewhere > > > * mips RS4230 - The requisite RISC/os v5.01 media did turn up somewhat > > > recently, thanks to everyone involved in that effort. Now I???m just > hoping > > > to eventually stumble over a new enough version of RISCwindows that > will > > > support the console framebuffer (v4.11 IIRC) > > > * Pixar Image Computer - missing host interface board (SGI, Sun, > anything) > > > and pretty much all the software (Chap-C, etc.) > > > * Sritek VersaCard - missing the MC68000 Xenix and PC interface > software. > > > * Sun FDDI/DX (VME) - missing the SunOS driver tape > > > * Sun GT - busted, missing much in the way of hope tracking down the > > > fault, never mind repairing > > > * Sun TAAC-1 - missing the software > > > > > > A goodly measure of IBM RT AOS/4.3 software has been recovered and > > > archived in the last couple years. Some of it from my own efforts. > There > > > are enough of the 6152-specific pieces that exist in situ to make a > usable > > > 6152 system, but they're not complete. It???d be nice to turn up some > of the > > > official distribution media for that. There???d have been a QIC tape > adding > > > the 6152-specific kernel pieces, maybe a floppy or two with the DOS > and/or > > > OS/2 host components (if they weren???t also on the tape). > > > > > > > > > ok > > > bear. > > > > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sun Jul 20 04:55:48 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 19 Jul 2025 20:55:48 +0200 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <393d865b-00db-4064-a84a-3adca8d9554f@app.fastmail.com> References: <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <20250719180707.UKGSO3oA@steffen%sdaoden.eu> <393d865b-00db-4064-a84a-3adca8d9554f@app.fastmail.com> Message-ID: <20250719185548.1vFPdnhW@steffen%sdaoden.eu> Jeff Johnson wrote in <393d865b-00db-4064-a84a-3adca8d9554f at app.fastmail.com>: |You should try OpenVi - which is easy to build and includes the OpenBSD’s \ |db and regex dependencies in the tree - https://github.com/johnsonjh/OpenVi Compiles etc just fine and fast, but has no split/close (i do use that), and also no UTF-8/Unicode (i am German) -- multibyte in \x notation is .. too hard. It is actually larger than vim (as here): # ll /bin/vi -rwxr-xr-x 1 root root 1763568 Jun 8 00:23 /bin/vi* # ll /tmp/x/OpenVi/bin/vi -rwxr-x--- 1 steffen steffen 2248288 Jul 19 20:50 /tmp/x/OpenVi/bin/vi* # ldd /tmp/x/OpenVi/bin/vi linux-vdso.so.1 (0x00007ffdf89e4000) libncursesw.so.6 => /lib/libncursesw.so.6 (0x00007fd6111fb000) libc.so.6 => /lib/libc.so.6 (0x00007fd61100b000) /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fd6112d2000) # ldd /bin/vi linux-vdso.so.1 (0x00007ffe8dfa6000) libm.so.6 => /lib/libm.so.6 (0x00007f87feab2000) libncursesw.so.6 => /lib/libncursesw.so.6 (0x00007f87fea3b000) libacl.so.1 => /lib/libacl.so.1 (0x00007f87fea30000) libc.so.6 => /lib/libc.so.6 (0x00007f87fe840000) /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f87fed4d000) libattr.so.1 => /lib/libattr.so.1 (0x00007f87fe838000) This is vim as CRUX-Linux builds it, out-of-the-box: ./configure \ --prefix=/usr \ --with-vim-name=vim \ --with-compiledby="$(crux | awk '{ print $1, $3 }')" \ --enable-multibyte \ --enable-cscope \ --enable-perlinterp=dynamic \ --enable-python3interp=dynamic \ --without-x \ --disable-gui \ --disable-gpm \ --disable-canberra \ --disable-nls --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From steffen at sdaoden.eu Sun Jul 20 05:10:31 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 19 Jul 2025 21:10:31 +0200 Subject: [TUHS] xvi In-Reply-To: References: Message-ID: <20250719191031.2fJu6sbQ@steffen%sdaoden.eu> Marshall Conover wrote in : |In my experience, for the sake of mental organization and not sending the |wrong command to the wrong place, there's a case to be made for |"namespacing" all activity around a certain task/environment in a singular |shell, which makes job handling with fore- and backgrounding relevant. For |example, I'll be iterating on a script targeting a new deployment |environment that requires certain env vars and a history of related |commands, then running it to see if it works, and reflexively I'm more |likely to open & edit the script, then ctrl+z the editor and run the script |than to open the editor in a separate window in my experience. That said, I |certainly have sometimes thought "you know, you could just edit the script |in another window." | |I did only just learn about ":stop" with this message, though. For me, the |surprising thing is implementing in vim what users can do by hitting ctrl+z |(and which I do daily in vim with ctrl+z). Even before getting to the |window system, the shell's already got this covered by giving you the |ability to background the application: why add lines of code to your |application to do it again? But perhaps there is a scripting utility to |having it within vim itself. You may have the desire to strip termios/ISIG at times due to whatever reasons (raw input mode), but still want the functionality to happen upon a certain (configurable) keypress. If you then have the function, why not also offer it to users. (Having said that, the MUA i maintain, for example, has ‘\cZ’ raise(3)∞ ‘SIGTSTP’ (mle-raise-tstp). which then does exactly that, after restoring normal termios; but that is just how it came.) --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From lm at mcvoy.com Sun Jul 20 05:11:33 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 19 Jul 2025 12:11:33 -0700 Subject: [TUHS] Was artifacts, now ethernet In-Reply-To: References: <202507182103.56IL3rQA1096987@darkstar.fourwinds.com> <20250719175310.GF15357@mcvoy.com> Message-ID: <20250719191133.GI15357@mcvoy.com> On Sat, Jul 19, 2025 at 11:53:20AM -0700, Tom Lyon wrote: > The other bit of this story that I've heard from Andy is that there was > some kind of gentlemen's agreement between the IEEE 802 and ANSI/FDDI > committees - to have Ethernet stick to 10Mb and let FDDI do 100Mb. Seems, > at least in retrospect, to be incredibly stupid. Huh, that's the first I've heard of that. My personal experience was that the issue was signaling at 100Mbit had cross talk issues. Until it didn't. > And then there was HP with 100Base-VG (iirc). Sigh. > > You and Andy understood that faster Ethernet was all that was needed. What I wanted was ethernet packets. I'd seen switch technology and realized that you don't really need to store and forward (unless the outgoing port is busy) so people were starting to talk about sending the first bits out the outgoing port before the last bits came in the incoming port. The nay sayers were mumbling about forwarding corrupt packets but that got shut down because (A) the final destination of the packet will catch that it is corrupt and (B) corrupt packets are vanishingly rare so making all the switches slow for something that doesn't happen often is stupid. The other thing I realized is that ethernet packets are sized just fine. I used to want jumbo packets (8K + space for headers) so you could do SGI's page flip / copy on write. But infinitely large packets means infinitely large buffers, SGI's numa interconnect educated me on that. From trnsz at pobox.com Sun Jul 20 05:33:21 2025 From: trnsz at pobox.com (Jeff Johnson) Date: Sat, 19 Jul 2025 15:33:21 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250719185548.1vFPdnhW@steffen%sdaoden.eu> References: <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <20250719180707.UKGSO3oA@steffen%sdaoden.eu> <393d865b-00db-4064-a84a-3adca8d9554f@app.fastmail.com> <20250719185548.1vFPdnhW@steffen%sdaoden.eu> Message-ID: <4d7ab3f8-8c3e-4589-a6f1-5108fac2507a@app.fastmail.com> It’s only 142KB here - did you strip the binary? For split, use :E. The lack of multibyte is unfortunately something that can not be resolved easily without breaking compatibility with the OpenBSD upstream - changes changes needed would be too extensive. There is nvi2 for that that, but it might not be as easy build on Linux. -- Jeffrey H. Johnson trnsz at pobox.com On Sat, Jul 19, 2025, at 2:55 PM, Steffen Nurpmeso wrote: > Jeff Johnson wrote in > <393d865b-00db-4064-a84a-3adca8d9554f at app.fastmail.com>: > |You should try OpenVi - which is easy to build and includes the OpenBSD’s \ > |db and regex dependencies in the tree - https://github.com/johnsonjh/OpenVi > > Compiles etc just fine and fast, but has no split/close (i do use > that), and also no UTF-8/Unicode (i am German) -- multibyte in \x > notation is .. too hard. > It is actually larger than vim (as here): > > # ll /bin/vi > -rwxr-xr-x 1 root root 1763568 Jun 8 00:23 /bin/vi* > # ll /tmp/x/OpenVi/bin/vi > -rwxr-x--- 1 steffen steffen 2248288 Jul 19 20:50 > /tmp/x/OpenVi/bin/vi* > # ldd /tmp/x/OpenVi/bin/vi > linux-vdso.so.1 (0x00007ffdf89e4000) > libncursesw.so.6 => /lib/libncursesw.so.6 (0x00007fd6111fb000) > libc.so.6 => /lib/libc.so.6 (0x00007fd61100b000) > /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 > (0x00007fd6112d2000) > # ldd /bin/vi > linux-vdso.so.1 (0x00007ffe8dfa6000) > libm.so.6 => /lib/libm.so.6 (0x00007f87feab2000) > libncursesw.so.6 => /lib/libncursesw.so.6 (0x00007f87fea3b000) > libacl.so.1 => /lib/libacl.so.1 (0x00007f87fea30000) > libc.so.6 => /lib/libc.so.6 (0x00007f87fe840000) > /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 > (0x00007f87fed4d000) > libattr.so.1 => /lib/libattr.so.1 (0x00007f87fe838000) > > This is vim as CRUX-Linux builds it, out-of-the-box: > > ./configure \ > --prefix=/usr \ > --with-vim-name=vim \ > --with-compiledby="$(crux | awk '{ print $1, $3 }')" \ > --enable-multibyte \ > --enable-cscope \ > --enable-perlinterp=dynamic \ > --enable-python3interp=dynamic \ > --without-x \ > --disable-gui \ > --disable-gpm \ > --disable-canberra \ > --disable-nls > > --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) > | > |During summer's humble, here's David Leonard's grumble > | > |The black bear, The black bear, > |blithely holds his own holds himself at leisure > |beating it, up and down tossing over his ups and downs with pleasure > | > |Farewell, dear collar bear From steffen at sdaoden.eu Sun Jul 20 05:47:13 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 19 Jul 2025 21:47:13 +0200 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <4d7ab3f8-8c3e-4589-a6f1-5108fac2507a@app.fastmail.com> References: <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <20250719180707.UKGSO3oA@steffen%sdaoden.eu> <393d865b-00db-4064-a84a-3adca8d9554f@app.fastmail.com> <20250719185548.1vFPdnhW@steffen%sdaoden.eu> <4d7ab3f8-8c3e-4589-a6f1-5108fac2507a@app.fastmail.com> Message-ID: <20250719194713.Njd0D533@steffen%sdaoden.eu> Jeff Johnson wrote in <4d7ab3f8-8c3e-4589-a6f1-5108fac2507a at app.fastmail.com>: |It’s only 142KB here - did you strip the binary? No, did not strip; yes, vim is stripped; did not think about that, i also only strip(1) on "make install", so.. bogus head. |For split, use :E. The lack of multibyte is unfortunately something \ Ah, also. Ok. |that can not be resolved easily without breaking compatibility with \ |the OpenBSD upstream - changes changes needed would be too extensive. I see. But nice and easy compilation, out of the box! |There is nvi2 for that that, but it might not be as easy build on Linux. At least not from the repository checkout. |-- |Jeffrey H. Johnson |trnsz at pobox.com --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From noel.hunt at gmail.com Sun Jul 20 09:03:34 2025 From: noel.hunt at gmail.com (Noel Hunt) Date: Sun, 20 Jul 2025 09:03:34 +1000 Subject: [TUHS] foreground/background vs. Windowing In-Reply-To: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: > I still like to use ^Z to suspend a running program, even when I use > X11. Since it would appear that that is totally unnecessary in a window system, as Doug pointed out, one has to ask why? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Jul 20 09:06:51 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Sat, 19 Jul 2025 19:06:51 -0400 Subject: [TUHS] Your Most Prized UNIX Artifacts? In-Reply-To: References: <202507182103.56IL3rQA1096987@darkstar.fourwinds.com> Message-ID: On 7/19/25 5:20 AM, r.stricklin wrote: > A goodly measure of IBM RT AOS/4.3 software has been recovered and archived in the last couple years. I don't have distribution media, but I sent a complete AOS/4.3 source tree to Warren last year. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From trnsz at pobox.com Sun Jul 20 09:11:40 2025 From: trnsz at pobox.com (Jeff Johnson) Date: Sat, 19 Jul 2025 19:11:40 -0400 Subject: [TUHS] foreground/background vs. Windowing In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: <897cd4d1-c81f-418d-a987-cabd3a0e5467@app.fastmail.com> Personally, I will often suspend and background a task, since it’s faster to use type the short commands (usually ^Z and fg when done) all in the terminal, rather than require use of the mouse (or possibly using other different keyboard commands) to open a new terminal window, do your task, and close the window. I will still sometimes reflexively use ^Z/fg even when working in tmux, especially if what I need to do is a prerequisite to the backgrounded task getting done - “jobs” output becomes my working “stack”. -- Jeffrey H. Johnson trnsz at pobox.com On Sat, Jul 19, 2025, at 7:03 PM, Noel Hunt wrote: > > > I still like to use ^Z to suspend a running program, even when I use > > X11. > > Since it would appear that that is totally unnecessary in a > window system, as Doug pointed out, one has to ask why? -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sun Jul 20 09:33:35 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sun, 20 Jul 2025 01:33:35 +0200 Subject: [TUHS] foreground/background vs. Windowing In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: <20250719233335.lPhweMnt@steffen%sdaoden.eu> Noel Hunt wrote in : |> I still like to use ^Z to suspend a running program, even when I use |> X11. | |Since it would appear that that is totally unnecessary in a |window system, as Doug pointed out, one has to ask why? And another question would be why i have a need to add pkill -CONT tmux to my dmenu.sh, aka command PKILL_TMUX "pkill -CONT tmux" to my (currently unused) ~/.cwmrc. Ie, why use that ^Z TSTP mess when there are so many race conditions that the signal goes to the wrong program. (This is most often from within less(1)<-bash(1)<-tmux(1)<-st(1), then; and it is on Linux.) --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From imp at bsdimp.com Sun Jul 20 09:37:34 2025 From: imp at bsdimp.com (Warner Losh) Date: Sat, 19 Jul 2025 17:37:34 -0600 Subject: [TUHS] foreground/background vs. Windowing In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: On Sat, Jul 19, 2025, 5:04 PM Noel Hunt wrote: > > > I still like to use ^Z to suspend a running program, even when I use > > X11. > > Since it would appear that that is totally unnecessary in a > window system, as Doug pointed out, one has to ask why? > To put the job in the background. I don't understand why you'd want to start a whole new window that has a new history. I hit ^Z in emacs to build or run tests... New sessions start fast enough, but shell history gets weird. Also, there are no GUI emacs versions I like.. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Sun Jul 20 10:36:09 2025 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 20 Jul 2025 10:36:09 +1000 Subject: [TUHS] Not really Emacs wars (was: foreground/background vs. Windowing) In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: [Somewhat off-topic for TUHS; please follow up at COFF] On Saturday, 19 July 2025 at 17:37:34 -0600, Warner Losh wrote: > > Also, there are no GUI emacs versions I like.. You have me curious. How many do you know? And what don't you like about them, when you clearly use Emacs? Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From will.senn at gmail.com Sun Jul 20 11:16:33 2025 From: will.senn at gmail.com (Will Senn) Date: Sat, 19 Jul 2025 20:16:33 -0500 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250718194349.GG8625@mcvoy.com> References: <20250717200332.GH27987@mcvoy.com> <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> Message-ID: <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> Hi Larry, I've thought about the "if you worked for me", dig and it kind of stung. As a former global tech guy, I never told my architects, engineers, developers, qa analysts, bus analysts or even executive assistants what to use to get their job done. I argued my position on various technical directions, but I gave in when the argument had merit. Yes, I insisted on some decisions, but these were high level architectural decisions where I had budgetary responsibility as well as technical. On smaller matters of personal productivity, I pretty much ceded that territory to the individual. When monetary cost was involved, that brought in its own approval threshold, but by and large, if the individual wanted to use qedit, q, emacs (why?), ultraedit, etc. So long as it wasn't burdensome in some way, I could care less. Probably the smartest and most productive engineer I ever worked with was in love with Borland Brief... I could edit circles around him with vi, but... he was a masterful engineer... he got his brief and he seemed happy with it, we got excellence and quality systems from him... These days, I'm in academia and enjoy the freedom to use whatever I like both for work, and for pleasure and I like vi... and xed... and ed... and, and, and... anything but emacsen, heck even the editors from RTS are more understandable than emacs, as for vi-alikes, I thought I was a big fan of nvi (I really am), but now I've seen the clean code for openvi, its lack of dependencies (other than a c toolchain), and I'm over on that train now. Really, I have no loyalty. Your argument about modernity is certainly well trod, particularly in the halls of the c-suite. Personally, I have seen hundreds of modernizations over my career and all of them promised improved ease of use, reduced cost, better integration, yada, yada... Very few, less than I can count on one hand delivered on the promise. Oh, certainly some things improved, but overall, pretty much the same activity, but more complicated, costlier, with more new points to integrate, etc. In my view, and it could be just mine, vim is one of those modernization projects. One of these days, some young genius is gonna rise up and delve into the living system that is Bram's vim, rip its heart out, and rebuild a spectacular compact editor... at least one can hope. Thanks, Will On 7/18/25 14:43, Larry McVoy wrote: > Last post on this topic because life is too short. > > Will, you can do whatever you want. If you worked for me, this would be a > much shorter conversation and you'd be using vim. Modern tools are more > complicated because they do more stuff. Taking your position to the extreme > would have you using a pipeline piped to ed, would it not? vi is a BSDism, > so it isn't "pure", nvi is a rewrite of Joys vi (why? Anyone?) > > I get the desire to have simple tools, I'm that way too, but switching > from vi, nvi to vim was seamless. I've never looked at their documentation > other than :help to find how to manipulate their windows. Everything else > just worked. > > Have fun with nvi. > > On Fri, Jul 18, 2025 at 01:28:54PM -0500, Will Senn wrote: >> Ha Larry. I'm not hidebound, but I do like to understand the software I use >> and I'm more of the if it ain't broke persuasion. The vim manual is maybe >> 5000 pages now (https://nathangrigg.com/vimhelp/vimhelp.pdf), only about >> 100x the nvi manual.... but yeah, different strokes for different folks. >> >> Seems like we're in the weeds though, almost COFF worthy. >> >> I do wonder about vi though and when it became prevalent. In v6, it's >> supposedly possible to get it working, but I've never seen it in virtual >> environs (oh how I've tried). In v7, it's more possible, but again, I've not >> seen it really working in SIMH (tried that too). BSD 2.11 gets the nod, but >> was it delivered as part of any system prior to 2.11 or was 2.11 really the >> first post v7 unix with vi with wider adoption? >> >> Later, >> >> Will >> >> >> >> On 7/18/25 07:52, Larry McVoy wrote: >>> That's fine, if it works for you it works for you. For me, vim is >>> compat enough (and it has a way to make it more compat if you care >>> I believe) and has some functionality that makes me shake my head >>> at the nvi people. >>> >>> To me, nvi is sort of like v7. Yeah, it's like the original Unix >>> but would you want to live there just because it is "pure"? No >>> networking, no top, it's just a basic Unix. Cool because of how >>> small it is but pretty painful to live there. >>> >>> On Fri, Jul 18, 2025 at 07:24:46AM -0500, Will Senn wrote: >>>> nvi does everything i need it to, it's help fits on a couple of screens, and >>>> it's easy to remember it all. maybe if I hit a wall with it, I'll reinstall >>>> vim, but for the screen stuff, don't need it. I don't live in my editor, or >>>> even the command line, I just use it when it's convenient - which admittedly >>>> is a lot of the time. But, it's the terminal that's most useful, not vi. So, >>>> if I want more screen, I just open a terminal window. My monitor has room >>>> for a dozen or so :) not including guake, workspaces, etc... in the modern >>>> era, of course! >>>> >>>> Will >>>> >>>> On 7/18/25 05:09, Larry McVoy wrote: >>>>> On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote: >>>>>> On Jul 17, 2025, at 7:52???PM, segaloco via TUHS wrote: >>>>>>>> If you just do ":E" it will put both windows on the current file, >>>>>>>> exactly the same as vim. But both do it wrong (IMHO) as the second >>>>>>>> window starts at the same place (e.g top of the file). In the Rand >>>>>>>> Editor if the split is at line N, the bottom window shows lines N+1. >>>>>>>> Exact same behavior for vertical split (the left and right side >>>>>>>> windows show the same portions as before). >>>>>>>> >>>>>>>>> On Jul 17, 2025, at 6:09???PM, Larry McVoy lm at mcvoy.com wrote: >>>>>>>>> >>>>>>>>> Not really the same. :sp splits your window in half and puts you in >>>>>>>>> two different windows on the same file. Each window, in vim, is full >>>>>>>>> on vi, you can do :e fillename and now that window is on that file. >>>>>>> Not historic but as of present I shunt windowing off to GNU screen and just have separate nvi sessions in each. This may speak to ignorance on my part regarding advantages of opening multiple files in the same session in any given vi. I keep vim around for when I need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your window configuration tightly coupled, but I also frequently have vi in one pane and am using the others for od output and build/test cycle for disassembly projects. >>>>>> Going via screen(1) can be more painful. If you want to copy some lines >>>>> >from one file to another, you have to either create a temp file or >>>>>> use the window systems's cut/paste buffer/clipboard. The latter can >>>>>> actually works worse (if you have autoindent turned on for example). >>>>>> Also the modal nature of vi/vim can wreak havoc (copied text can be >>>>>> mistakenly interpreted as commands). >>>>>> >>>>>> In vi you can yank lines in file1, paste in file2. And can share >>>>>> options, tags etc. In the rand editor you can scroll two windows in >>>>>> unison (handy if one shows column headings and the other some rows). >>>>>> See acme for an example of a well designed multi window editor. >>>>> I was going to respond to the screen stuff but Bakul beat me to it. >>>>> In vim, you just have a split view of the same file. Changes in >>>>> either window will show up in the other window. For example >>>>> >>>>> vim foo.c # foo.c exists and has a 100 lines >>>>> :sp >>>>> >>>>> now you have both windows looking at the same file >>>>> >>>>> start changing something and it is done in both windows. >>>>> >>>>> Screen is nowhere near that and using it to claim that nvi is fine >>>>> is missing the point by a country mile. >>>>> >>>>> And I don't understand the dislike of vim. Sure, it's got a pile >>>>> of stuff that old time Unix people would dislike "cat came back >>>> >from BSD wagging it's tail" (or something that Rob said) but you >>>>> don't have to use any of that. For me, vim is a finger compat >>>>> vi clone that has some really really useful extensions, I use >>>>> :split >>>>> all the time. Saying you prefer nvi in the face of that is >>>>> something that makes no sense to me. I've used nvi, I get that >>>>> it is compat with Joys vi, but so what? vim is more useful and >>>>> it is also compat. >>>>> >>>>> Time marches on, perhaps march with it? >>>>> >>>>> --lm From imp at bsdimp.com Sun Jul 20 11:27:40 2025 From: imp at bsdimp.com (Warner Losh) Date: Sat, 19 Jul 2025 19:27:40 -0600 Subject: [TUHS] Not really Emacs wars (was: foreground/background vs. Windowing) In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: On Sat, Jul 19, 2025 at 6:36 PM Greg 'groggy' Lehey wrote: > > [Somewhat off-topic for TUHS; please follow up at COFF] > > On Saturday, 19 July 2025 at 17:37:34 -0600, Warner Losh wrote: > > > > Also, there are no GUI emacs versions I like.. > > You have me curious. How many do you know? And what don't you like > about them, when you clearly use Emacs? Most of the emacs GUI adaptations assume that it's THE instance of the editor. With multiple terminals, I can have multiple editors with different contexts. With the GUI, it all gets dumped together. It may just be an odd quirk of when I grew up and always having job control and just always using that all the way back to the 4.2BSD Vax 11/750 days. Warner > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php From g.branden.robinson at gmail.com Sun Jul 20 17:59:08 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 20 Jul 2025 02:59:08 -0500 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> References: <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> Message-ID: <20250720075908.w6tetlcb3zhowbby@illithid> At 2025-07-19T20:16:33-0500, Will Senn wrote: > I've thought about the "if you worked for me", dig and it kind of > stung. Manure often does. Larry came up in the soil from which grew tech bro culture. A preoccupation with managing the preferences of others, as with Steve Jobs's "thought leadership", is consistent with the authoritarian style he advocates. In contrast I think questions of engineering are more important than those of fashion. But fashion is easier, and apparently more profitable to write about, so people who like to see their names trafficked by journalists follow the path of less resistance. I admit that a lot more people have heard of Condé Nast than Isambard Brunel or Oliver Heaviside. > As a former global tech guy, I never told my architects, engineers, > developers, qa analysts, bus analysts or even executive assistants > what to use to get their job done. I argued my position on various > technical directions, but I gave in when the argument had merit. Yes, > I insisted on some decisions, but these were high level architectural > decisions where I had budgetary responsibility as well as technical. > On smaller matters of personal productivity, I pretty much ceded that > territory to the individual. When monetary cost was involved, that > brought in its own approval threshold, but by and large, if the > individual wanted to use qedit, q, emacs (why?), ultraedit, etc. So > long as it wasn't burdensome in some way, I could care less. Probably > the smartest and most productive engineer I ever worked with was in > love with Borland Brief... I could edit circles around him with vi, > but... he was a masterful engineer... he got his brief and he seemed > happy with it, we got excellence and quality systems from him... I was taught "if it ain't broke, and we don't expect it to break, don't fix it" as a principle of sound engineering. I'd say it applies to personnel management as well. Larry may not. On the milder topic of editor preferences, I'm a vi(m) user but employ Emacs bindings in readline applications and maintained my own fork of mg (microemacs) for a while, to see how the other half lived. I discovered that a much bigger chunk of Emacs advocacy is predicated on its "finger-feel"[1] and some other built-in features than upon Lisp scriptability. In other words, far more Emacs advocates trumpeted the value of its customizability via Lisp than actually developed competence in writing Lisp for themselves. (On the bright side, Atom/Electron and VSCode could well have drawn away people of this mentality from younger generations, such that anyone choosing an Emacs today is more serious about developing Lisp expertise. Good for them.) While Vim has also been Turing-equivalently programmable for decades now, via peculiar extensions to the ex language,[1] but also Perl, Python, and Tcl, its community has seemed less brash about that fact. I think that's because unsophisticated Emacs users were attempting to ride on Lisp's coattails as an early and innovative yet satisfyingly esoteric development in the history of programming languages. Again, we encounter people more concerned with superficial matters of fashion than with overcoming problems of engineering. I did once have loyalty to nvi, and did have a conversion experience, and I remember exactly what it was. It was visual mode. I was practiced at writing ed-style commands applying to address ranges to get stuff done at the colon prompt. That frequently meant having to think up the shortest possible regex that would capture the range I wanted, or having to count lines on the screen--both tedious--or make a crude and thus frequently inaccurate guess. Visual mode, where I use line mode "V" 10 times more often than character mode "v" and character mode 10 times more often than rectangle mode "Control+V", killed off that problem for me completely. Nowadays, I only ever write ed/ex-style addresses when composing sed scripts, which suits me just fine, because I only write a sed script when I need a repeatable procedure or operation in the first place, maybe in a Makefile. In those scenarios, the extra brain cycles given to regex construction or perfectly reliable line-counting pays off. Like others in this thread, but later in my personal history, I came to find vertical splits (and vimdiff(1)) extremely useful. For composing emails, though, but for one factor[3] I could probably be thrown into nvi and not miss any Vim features. Maybe I should start submitting "textwidth" patches to the various nvi descendants and see if anyone will accept them. For years I nursed the thought that a wonderful joke to play on RMS's tedious Emacs partisanship would have been to add Guile to Vim's list of extension languages. But I guess no one enjoys schadenfreude _that_ much. Regards, Branden [1] which I suspect is objectively worse than vi's by keystroke count, but I am unwilling to write a grant proposal to research the matter properly ;-) [2] recently given a major overhaul with "vim9script", which seems like a worthwhile cleanup but of which I've not reached an informed opinion [3] The "textwidth" option is a killer Vim feature because vi's "wrapmargin" was ill-conceived. It arose from Teletype/punched-card thinking, poorly anticipating varying terminal display widths. I'll piss off Larry some more by punking on Bill Joy and claim that "wrapmargin" solved the wrong problem. Unless you're composing for paper, which was expressly _not_ the point of *VI*, you don't _care_ how wide the right margin is in character cells. You care about how wide the line of text is. (You might also care about an indent.) _nroff_ had already gotten this right in 1972, even on paper output, with `.ll` and `.in`. There was no configuration knob for a right margin or indent. I'm sorry, Bill--I think you missed it. So saith the GBR 9000, foolproof and incapable of error. ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lm at mcvoy.com Sun Jul 20 21:38:02 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 20 Jul 2025 04:38:02 -0700 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250720075908.w6tetlcb3zhowbby@illithid> References: <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> Message-ID: <20250720113802.GP15357@mcvoy.com> On Sun, Jul 20, 2025 at 02:59:08AM -0500, G. Branden Robinson wrote: > At 2025-07-19T20:16:33-0500, Will Senn wrote: > > I've thought about the "if you worked for me", dig and it kind of > > stung. > > Manure often does. > > Larry came up in the soil from which grew tech bro culture. > > A preoccupation with managing the preferences of others, as with Steve > Jobs's "thought leadership", is consistent with the authoritarian style > he advocates. Huh, you won't be surprised I have a different perspective. Allow me to tell you how I describe managing engineers. Suppose we were artists, there were 4 of us. Someone brought us a photograph and said "I want a painting of that". OK, split it into quarters and go do it. What do we get back? Well, artist #1 likes oil paints so that's what s/he did. Artist #2 likes charcoal so that's what they did. Artist #3 likes pen and ink. Artist #4 likes water color. Is that a painting? Maybe if you like a mish mash of stuff that doesn't go together. Most people would call it garbage and refuse to pay. My so called "authoritarian style" is nothing more than I was the leader, I had to pick one style. And, yes, it means if you have N people working you usually have N-1 pissed off people because they weren't getting to do things their way. Letting them do things their way means there is no overall picture you are driving towards. And I'm not above being overridden. I personally hate GNU make for all the similar reasons you are advocating for a smaller vi. But my team convinced me it was less work to move to that than maintain all the scripts we were using to use a simple make. But yeah, when people work for me, I lead. I set the tone. It wasn't tech bro nonsense, it was about herding people towards the same picture. I wasn't trying to tell Will he can't use whatever editor he wants, I was trying to tell Will I wouldn't tolerate this much back and forth about his personal preferences distracting us from shipping product. My team had emacs people and vi people, nobody cared so long as you got your job done. What we didn't have is editor arguments clogging up our thinking. From rich.salz at gmail.com Sun Jul 20 21:57:43 2025 From: rich.salz at gmail.com (Rich Salz) Date: Sun, 20 Jul 2025 13:57:43 +0200 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250720113802.GP15357@mcvoy.com> References: <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <20250720113802.GP15357@mcvoy.com> Message-ID: > > What we didn't have is editor arguments clogging up our thinking. > Unlike here and now, sadly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chopps at chopps.org Sun Jul 20 22:24:41 2025 From: chopps at chopps.org (Christian Hopps) Date: Sun, 20 Jul 2025 14:24:41 +0200 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250720113802.GP15357@mcvoy.com> (Larry McVoy's message of "Sun, 20 Jul 2025 04:38:02 -0700") References: <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <20250720113802.GP15357@mcvoy.com> Message-ID: Larry McVoy writes: > > I wasn't trying to tell Will he can't use whatever editor he wants, I was > trying to tell Will I wouldn't tolerate this much back and forth about his > personal preferences distracting us from shipping product. My team had > emacs people and vi people, nobody cared so long as you got your job done. > > What we didn't have is editor arguments clogging up our thinking. To jump in here before everyone poo poos this thread too much. I agree with this sentiment when it's time to get work done. That said, I've enjoyed this thread b/c I like getting other peoples perspectives, especially from folks that I think have some clue. Sometimes I learn something new or a new perspective and I end up adapting new tools or practices b/c of it -- even now that my beard/hair is grey. I find these are actually fun conversations to have occasionally -- maybe in a cafe/bar or even on a mailing list. Maybe not everyday or all the time, but sometimes. :) FWIW for coding/email/organizing/scheduling I now use some franken-setup project called "spacemacs" which is emacs, but the UI of vi, launching much faster, that uses a meta-configuration that makes it simple to enable all those features (and yes I still write lisp when needed but that's almost never to get what I want anymore). For quick editing I still just type `vi` and use ^Z, even though I also use tmux and long running disconnected remote sessions. Thanks, Chris. From trnsz at pobox.com Sun Jul 20 22:25:58 2025 From: trnsz at pobox.com (Jeff Johnson) Date: Sun, 20 Jul 2025 08:25:58 -0400 Subject: [TUHS] Editors (was: Re: End of an era: the last ATC (USENIX Annual Technical Conference)) In-Reply-To: <20250720075908.w6tetlcb3zhowbby@illithid> References: <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> Message-ID: I’ll throw in that Lugaru Software (which as been around forever) still maintains their venerable Epsilon editor - which is a great product - and although it is roughly considered to be an “Emacs” by key bindings and default behaviors, underneath it’s all in the ELL language instead of Lisp. And EEL is essentially C. If you prefer C to Lisp (oh, the cries and gnashing of teeth!) like many people do, it’s a very interesting product. -- Jeffrey H. Johnson trnsz at pobox.com On Sun, Jul 20, 2025, at 3:59 AM, G. Branden Robinson wrote: > > On the milder topic of editor preferences, I'm a vi(m) user but employ > Emacs bindings in readline applications and maintained my own fork of mg > (microemacs) for a while, to see how the other half lived. I discovered > that a much bigger chunk of Emacs advocacy is predicated on its > "finger-feel"[1] and some other built-in features than upon Lisp > scriptability. From tuhs at tuhs.org Sun Jul 20 22:26:59 2025 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Sun, 20 Jul 2025 12:26:59 +0000 Subject: [TUHS] ed, and all the other editors - a summary Message-ID: Folks, It has been great to read about everyone's preferences, uses and recollections for and of editors. In my ignorance, until just a few days ago I knew of perhaps only ed, vi, vim, nano and emacs so it has been a bonus to learn of all the others and their variants. In a somewhat related thread that seemed to end up on COFF and on here, Warner said, in part, "It may just be an odd quirk of when I grew up...", and I think that and other factors leads each of us to use the different tools we use. My earliest hands on computer experiences involved machines with monochrome display capabilities, no GUI and very little little memory to work with and those are some of the influences that led me, now, to ed. One of my favorite parts is opening a file or writing an edited file. ed somefile 438 w 672 So simple and, for me, relatable. In the sample file above, the enlarged file would just about fit in my first computer, a Sinclair ZX81 which came with 1KB of RAM. In short, everyone needs to wear the shoe that best fits them. What I've found, with ed, is that it helps me focus more intently on what I'm typing, regardless of whether it's code or a magazine article. Always at the back of mind when I use ed, especially if I run into a problem with my operation of it, is the thought, "Operating systems and languages were created on this.". That humbles me every time. Best regards, Cameron -------- Original Message -------- On 20/07/2025 02:28, Warner Losh wrote, in part: > It may just be an odd quirk of when I grew up > > Warner From tuhs at tuhs.org Sun Jul 20 22:58:07 2025 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Sun, 20 Jul 2025 12:58:07 +0000 Subject: [TUHS] And, finally... Message-ID: About a week ago, I designed a sticker for ed users. Hands up, I kind of half stole the tagline, but they're not-for-profit and I only did it because I couldn't find ed stickers by anyone else: https://i.postimg.cc/hjS5Wt6Z/esgag-fin3f.png As an homage to both teleprinters and monochrome monitors, the lettering is in a typewriter font and a representation of monitor green. The actual stickers have rounded corners and are 2-inches wide so ideal for laptops, desktop monitors or even teleprinters! If anyone on this list wants one, please contact me off-list and I will mail it to you, wherever in the world you live. These stickers are free/gratis and it will be my pleasure to post one to you. I haven't received them yet, they should arrive tomorrow, but I've had stickers made by the same company before and they were decent quality. Best regards, Cameron From g.branden.robinson at gmail.com Sun Jul 20 23:47:54 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 20 Jul 2025 08:47:54 -0500 Subject: [TUHS] how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference)) In-Reply-To: <20250720113802.GP15357@mcvoy.com> References: <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <20250720113802.GP15357@mcvoy.com> Message-ID: <20250720134754.3hiy6crrcqzw5qip@illithid> Hi Larry, At 2025-07-20T04:38:02-0700, Larry McVoy wrote: > On Sun, Jul 20, 2025 at 02:59:08AM -0500, G. Branden Robinson wrote: > > At 2025-07-19T20:16:33-0500, Will Senn wrote: > > > I've thought about the "if you worked for me", dig and it kind of > > > stung. > > > > Manure often does. > > > > Larry came up in the soil from which grew tech bro culture. > > > > A preoccupation with managing the preferences of others, as with > > Steve Jobs's "thought leadership", is consistent with the > > authoritarian style he advocates. > > Huh, you won't be surprised I have a different perspective. Indeed not. :) > Allow me to tell you how I describe managing engineers. Suppose we > were artists, there were 4 of us. Someone brought us a photograph and > said "I want a painting of that". OK, split it into quarters and go > do it. What do we get back? > > Well, artist #1 likes oil paints so that's what s/he did. Artist #2 > likes charcoal so that's what they did. Artist #3 likes pen and ink. > Artist #4 likes water color. > > Is that a painting? Maybe if you like a mish mash of stuff that > doesn't go together. Most people would call it garbage and refuse to > pay. Yeah. I think your analogy is facile and superficial and therefore characteristic of of Silicon Valley executive culture. Here's why. First, text editors don't leave traces of themselves in the work product.[1] Second, _especially_ in a leadership position (although this is more specifically the role of "architect" if someone has it), you have to be conscious of the boundaries of your software modules. A software project of sufficient complexity to be worth commissioning on a professional basis is, despite its contractual representation at the executive level, not a unitary object like an individual painting or photograph or 2½-minute folk song. Such things are not (formally) complex, but "elemental": if you decompose them, they stop being what they are. Often, a first-order decomposition of a software system leaves you with...a collection of other software systems, plus, ideally, some ancillary documentation and/or an integration test suite. > My so called "authoritarian style" is nothing more than I was the > leader, I had to pick one style. Right. To hear you tell it, you preoccupied yourself with matters of style and let others worry about the harder problems of architecture and interfacing. Maybe that was the right choice given your skill set and those of your staff. If that characterization cuts, there is a remedy: share a leadership anecdote where you made (or mediated) a hard decision on a non-stylistic matter. Maybe two algorithms of the same order in big-O notation were pitched for a certain software module, but one was preferable on some non-obvious basis. You've spoken before of the high value of SCCS's "weave" to BitKeeper. Was there anything the weave made hard or was bad at? Were you ever on the verge of reconsidering it? If so, what, on an _engineering_ basis rather than one of style or personal admiration, mandated its retention? If you have stories like that, those would, to me, constitute examples of technical leadership. And, if all "stakeholders" (your client[s] _and_ your staff) were happy with the outcome, then they could be examples of _good_ technical leadership, too. > And, yes, it means if you have N people working you usually have N-1 > pissed off people because they weren't getting to do things their way. I suspect you accurately perceived the presence of frustration. I also bet you assumed its cause rather than undertaking an earnest exploration thereof. A confounding factor here is that a project can have so many problems that the individual contributors themselves have trouble accurately identifying an "overall" problem or a single "worst" one that they have. Further, if they are experiencing deadline pressure, whether imposed by themselves or by leadership and are asked to identify "blockers", they're likely to name the obstacles that are easiest to articulate[2] or that they most recently struggled with.[3] One generally can't calendar the removal of as-yet-unarticulated problems. If the engineers have the same blocker day after day, then management is failing to remove them. If the engineers have NEW blockers every day or every week, and you have confidence in your recruitment/hiring, then the staff is not sandbagging you--the project has deep problems. My personal experience is that underspecification and otherwise unarticulated expectations are the root causes of nearly every problem that cause anguish among staff. And behind that problem is the worse one that managers climb into contractual beds with their counterparties without having done their necessary homework first. The client never wants to admit that they haven't really though through what it is they're asking for. They've already made promises to a director, VP, or someone in the C suite. So they yell at you and you yell at your staff. The manure, as it were, rolls downhill. > Letting them do things their way means there is no overall picture you > are driving towards. In engineering, we do not implement an "overall picture", but to a detailed specification. If you lack a detailed specification to implement, what you are doing is not (solely) engineering. That's not necessarily a bad thing; you are engaged in design and possibly in research. Charge more. Develop your staff by helping them get conference papers out of the work. > And I'm not above being overridden. I personally hate GNU make for > all the similar reasons you are advocating for a smaller vi. That wasn't me, but I'll freely admit that Vim has many features I don't use. I have found that time spent seeking mastery of one tool is good practice in judging the "right-sizing" of another. If nothing else, it helps one learn which hills aren't worth dying on. ;-) Regarding make(1), POSIX 2024 has made it _much_ better. I still think the BSDs' snarling adherence to old-style suffix rules, which are inflexible and ambiguous, and restrictions on $< are counterproductive, but a lot of stuff that used to not be portable, is portable now. > But my team convinced me it was less work to move to that than > maintain all the scripts we were using to use a simple make. > > But yeah, when people work for me, I lead. I set the tone. It wasn't > tech bro nonsense, it was about herding people towards the same > picture. I have a slender hope that I can persuade you that these things are actually the same in every way that matters. As implied above, this doesn't make you a tech bro yourself, necessarily, it might mean you're emphasizing the wrong elements of your experience for an audience of salty old engineers, contrast with venture capitalists. In martial arts training, there are "degrees" of black belt. Only the first few degrees have anything to do with one's own ability or perfection of form. After that, your advancement is determined by how many black belts you _train_. To become a master, you must train many black belts. To become a grand master, you must train many masters. While I'm sure there are perverse incentives in martial arts instruction (hello, capitalism), this approach of making your own advancement beyond a certain point dependent on the development of people no longer accountable to you strikes me as a worthwhile corrective to the narcissistic orientation of leadership in software development. Being a good example is a different phenomenon than being an object of emulation. One phenomenon is deep, the other shallow. Steve Jobs was good at producing a lot of fawning emulators with black turtlenecks and glib proclamations about the future of technology. Steve Wozniak has in substantial measure dedicated himself to producing more good engineers. > I wasn't trying to tell Will he can't use whatever editor he wants, I > was trying to tell Will I wouldn't tolerate this much back and forth > about his personal preferences distracting us from shipping product. That's not how I read what you said, but fine. I agree that bickering over tool choice can be a distraction from satisfying the contract and getting the final payment. But the sword of opportunity cost cuts both ways. You can't always be sure that the most readily available substitute good for an editor argument is a laser-focused coding session[4] on implementing an element of a deliverable. If your engineers are motivated, you will find that they don't distract themselves with nonsense _when they have a better alternative_. A good engineering manager deeply understands the XKCD concept of "nerd sniping" and knows how to adapt it to the benefit of the individual contributor, their team, the client, and consequently themselves.[5] > My team had emacs people and vi people, nobody cared so long as you > got your job done. That's a salutary attitude. But engineers also need time and vehicles for decompression, and one of the things they can use their downtime for is playful practice at evaluating tradeoffs between competing designs or systems. If you have an engineer who's going around harassing their peers for choosing the "wrong" editor, the problem is not their choice of editor, which might be "correct" in your opinion. The problem is that they're interfering unjustifiably with the work of their colleagues. Addressing that problem "sets the tone" much better than expressing, let alone mandating, your own preferences. It's what _I_ expect of a manager, at any rate. > What we didn't have is editor arguments clogging up our thinking. Done well--and this might happen only in a minority of cases--editor arguments can _enhance_ people's thinking; see "playful practice" above. And even if they don't, if they're no more destructive than a dispute over whether the coach of the local sportsball team was an idiot for benching player X in the Big Game last weekend, or than knocking off 30 minutes early for beers together at the end of a frustrating day, then good leadership can mean leaving some rough spots unsanded. Regards, Branden [1] _Programmers_ might so do, with vi "modelines" or Emacs "local variables" in text constitutive of a comment in the program source code. Different matter. [2] another instance of our old friend the "streetlight effect" https://en.wikipedia.org/wiki/Streetlight_effect [3] https://en.wikipedia.org/wiki/Recency_bias [4] or automated test construction, or documentation revision--wait, why is everybody laughing? [5] https://xkcd.com/356/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lm at mcvoy.com Mon Jul 21 00:38:06 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 20 Jul 2025 07:38:06 -0700 Subject: [TUHS] how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference)) In-Reply-To: <20250720134754.3hiy6crrcqzw5qip@illithid> References: <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <20250720113802.GP15357@mcvoy.com> <20250720134754.3hiy6crrcqzw5qip@illithid> Message-ID: <20250720143806.GQ15357@mcvoy.com> On Sun, Jul 20, 2025 at 08:47:54AM -0500, G. Branden Robinson wrote: > > Allow me to tell you how I describe managing engineers. Suppose we > > were artists, there were 4 of us. Someone brought us a photograph and > > said "I want a painting of that". OK, split it into quarters and go > > do it. What do we get back? > > > > Well, artist #1 likes oil paints so that's what s/he did. Artist #2 > > likes charcoal so that's what they did. Artist #3 likes pen and ink. > > Artist #4 likes water color. > > > > Is that a painting? Maybe if you like a mish mash of stuff that > > doesn't go together. Most people would call it garbage and refuse to > > pay. > > Yeah. I think your analogy is facile and superficial and therefore > characteristic of of Silicon Valley executive culture. Here's why. I really doubt you know the first thing about how actual Silicon Valley execs, good ones, work. Have you been one? I doubt it. Have you worked closely with any good ones? I doubt it. You looked down your nose at Steve Jobs, and while I agree he wasn't a nice person, he knew what people wanted before people knew what they wanted. That's a rare talent. I read the rest of your rant and nothing in it gave me any hope that you understand what a good exec does. You are foccused on the fluff pieces that talk about crappy executives. You appear to have no knowledge about how running a company works, your comments about specifications nicely highlight that. Classic engineer blinders. I got paid to argue with Suns execs for 6 months. Didn't win the argument. But I learned how they worked and it is NOTHING like how an engineer works. You want your specifications, everything carefully thought through, fully researched, not a flaw to be found. You move forward when you are sure you have the right answer, there is no way anyone will find fault with your reasoning. Real execs don't have that luxury. While you move forward when you are 100% sure you are correct, you've done the work to be sure, they can't afford that. What I learned, in my brief but long enough stint with execs, is they have to, over and over again, make a decision with about 10% of the info that you, Brandon, would be comfortable with. Why? Because all of their competition is doing the same thing. Any CEO who waits long enough to know that they have the right answer has missed their market, someone else guessed earlier and beat them to it. I found it pretty horrifying and a miserable way to make a living. You, Brandon, sitting here and passing judgement on people making those calls is insulting. You don't have that experience, you don't know how shitty it is to be forced to guess, and guess correctly, with not enough information. From lm at mcvoy.com Mon Jul 21 00:42:44 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 20 Jul 2025 07:42:44 -0700 Subject: [TUHS] how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference)) In-Reply-To: <20250720134754.3hiy6crrcqzw5qip@illithid> References: <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <20250720113802.GP15357@mcvoy.com> <20250720134754.3hiy6crrcqzw5qip@illithid> Message-ID: <20250720144244.GR15357@mcvoy.com> On Sun, Jul 20, 2025 at 08:47:54AM -0500, G. Branden Robinson wrote: > > My so called "authoritarian style" is nothing more than I was the > > leader, I had to pick one style. > > Right. To hear you tell it, you preoccupied yourself with matters of > style and let others worry about the harder problems of architecture and > interfacing. Maybe that was the right choice given your skill set and > those of your staff. My code is open source, if you read it and understand it, you'd see that you couldn't be more wrong. I'll let my code and accomplishments speak for themselves, I'm retired, Brandon. I'm no longer in the business of trying to change minds, thank god. I'm reminded of the look of horror on the face of one of my fishing buddies, when another buddy asked him if he didn't want to keep his finger in the game, mentor some people, sit on some boards, etc. He replied with something like "I managed people for decades, the last thing I want from retirement is more of that". Indeed. Amen. From douglas.mcilroy at dartmouth.edu Mon Jul 21 01:06:42 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 20 Jul 2025 11:06:42 -0400 Subject: [TUHS] how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference)) In-Reply-To: <20250720144244.GR15357@mcvoy.com> References: <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <20250720113802.GP15357@mcvoy.com> <20250720134754.3hiy6crrcqzw5qip@illithid> <20250720144244.GR15357@mcvoy.com> Message-ID: Enough, already. Doug On Sun, Jul 20, 2025 at 10:42 AM Larry McVoy wrote: > > On Sun, Jul 20, 2025 at 08:47:54AM -0500, G. Branden Robinson wrote: > > > My so called "authoritarian style" is nothing more than I was the > > > leader, I had to pick one style. > > > > Right. To hear you tell it, you preoccupied yourself with matters of > > style and let others worry about the harder problems of architecture and > > interfacing. Maybe that was the right choice given your skill set and > > those of your staff. > > My code is open source, if you read it and understand it, you'd see that > you couldn't be more wrong. > > I'll let my code and accomplishments speak for themselves, I'm retired, > Brandon. I'm no longer in the business of trying to change minds, thank > god. > > I'm reminded of the look of horror on the face of one of my fishing buddies, > when another buddy asked him if he didn't want to keep his finger in the > game, mentor some people, sit on some boards, etc. He replied with something > like "I managed people for decades, the last thing I want from retirement > is more of that". Indeed. Amen. From crossd at gmail.com Mon Jul 21 06:26:52 2025 From: crossd at gmail.com (Dan Cross) Date: Sun, 20 Jul 2025 16:26:52 -0400 Subject: [TUHS] Personal Preference vs Group Productivity (was Re: Re: End of an era: the last ATC (USENIX Annual Technical Conference)) In-Reply-To: References: <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <20250720113802.GP15357@mcvoy.com> Message-ID: [TUHS to Bcc; Cc'ed to COFF to redirect for follow-ups] On Sun, Jul 20, 2025 at 8:24 AM Christian Hopps wrote: > Larry McVoy writes: > > I wasn't trying to tell Will he can't use whatever editor he wants, I was > > trying to tell Will I wouldn't tolerate this much back and forth about his > > personal preferences distracting us from shipping product. My team had > > emacs people and vi people, nobody cared so long as you got your job done. > > > > What we didn't have is editor arguments clogging up our thinking. > > To jump in here before everyone poo poos this thread too much. I agree with this sentiment when it's time to get work done. > > That said, I've enjoyed this thread b/c I like getting other peoples perspectives, especially from folks that I think have some clue. Sometimes I learn something new or a new perspective and I end up adapting new tools or practices b/c of it -- even now that my beard/hair is grey. > > I find these are actually fun conversations to have occasionally -- maybe in a cafe/bar or even on a mailing list. Maybe not everyday or all the time, but sometimes. :) I think some folks may have interpreted Larry's statements as stating that, if you worked for him, you used the tools he mandated. But I don't think that's what he meant (at least not about text editors), and I think that your interpretation is correct: use whatever works for you, but don't waste a bunch of other people's time pushing the virtunes of your preferred tools on those who already have things that work for them. I think that's fair. That said, there is a qualitative difference between the sort of banter people may bat around over lunch, and someone seriously trying to get everyone else to use their preferred editor (editors are just one example, though interesting in this regard because choosing them seems to be such a deeply personal thing). I think the discussions on these mailing lists are closer to the former than the latter, and as long as it remains friendly, I really don't see any harm in that. But this got me thinking that surely there are decisions made on a project basis, where individual preference by itself is not, and cannot be, the deciding factor for use. Perhaps the most obvious is code-formatting styles, but others may be choice of build tool, revision control system, implementation language, and so on. Where does one draw the line between the tools an individual chooses for their own use, and those mandated by the group? I suspect there is no one, good, universal answer. Take implementation language as an example: "I'll write my part in C, you write yours in FORTRAN..." sounds highly suspect at first, but _might_ make sense if "I'm" tasked with writing the IO part and "you're" taking on the numerical bits and have to interface with a numerical library written in Fortran. Indeed, I've found that when people try to define some kind of general rule for deciding this or that, they tend to be trying to simplify really complex things in a very superficial way that's not reflective of actual practice. But maybe there is some utility in thinking about this generally. Perhaps a reasonable first-order approximation for finding a dividing line might be taken from the answer to the question, "is this something that really only impacts me, or is it going to have an impact on my peers, as well?" Editors sort of make sense here; by and large, as long as I can use the tools effectively, my peers aren't going to be impacted if I use tool A to enter text versus tool B. Similarly with whether I prefer light text on a darker background, or dark text on a lighter background, what font I use, type size, what window manager I use, and so on. But on the other hand, if I demanded that I be able to use My preferred code formatting style regardless of what the rest of the code used, then that _does_ have an impact on those around me, so deserves more thought. And _that's_ the kind of thing that people can argue about endlessly until finally someone just makes a decision. I've said this before, but Google's style guides were a great case in point here. To be honest, I didn't like them and thought that the resulting code was ugly. But after a few weeks, I just stopped noticing that, and I had to admit that they were a great aid in being able to approach a codebase with billions of LOC in it. When `clang-format` came along and took out a lot of the tedium of making your code conform to the style guide, it really freed up a lot of mental capacity to start thinking about real problems, design, and so on, and not just where the braces went. But that was all predicated on someone just Making a Decision. > FWIW for coding/email/organizing/scheduling I now use some franken-setup project called "spacemacs" which is emacs, but the UI of vi, launching much faster, that uses a meta-configuration that makes it simple to enable all those features (and yes I still write lisp when needed but that's almost never to get what I want anymore). > > For quick editing I still just type `vi` and use ^Z, even though I also use tmux and long running disconnected remote sessions. Personally, I've found it very helpful to maintain some level of proficiency in a variety of different text editors, using different tools for different things. Part of this is the whole, "when in Rome, do as Romans do..." sort of thing: I'm not looking for `vi` on VMS or Multics or VM/CMS or something, but I'll also happily use emacs to write Lisp, and on plan 9, I'll use sam or acme for C or troff or whatever. On my Mac, Zed or VSCode work pretty well. On remote Unix machines, a lot of the kids are hip on this "Helix" thing these days. Speaking of plan 9.... One nice thing about a system that embraces true resource sharing is that, when one can construct an environment that contains the set of all the resources one needs to work with and then one can bring one's local toolset to bear on those resources. Plan 9, where resources are represented by files in mutable namespaces, really exemplifies this, which is distinct from a more "remote access" model, where I use something like ssh or mosh or telnet to login to a remote system. In the remote access model, I'm constrained by whatever tools are available on a remote system. So if I'm logging into some remote server over SSH or something, it's handy to know whatever editor may be on the distant end. It's a shame more systems aren't like plan 9 in this way, but they aren't, and for better or worse, I've still got to use them, and it's so much less personally aggravating to care deeply about what tools are available in that context. - Dan C. From tuhs at tuhs.org Mon Jul 21 07:18:51 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 21 Jul 2025 07:18:51 +1000 Subject: [TUHS] how (not) to manage engineers In-Reply-To: References: <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <20250720113802.GP15357@mcvoy.com> <20250720134754.3hiy6crrcqzw5qip@illithid> <20250720144244.GR15357@mcvoy.com> Message-ID: On Sun, Jul 20, 2025 at 11:06:42AM -0400, Douglas McIlroy wrote: > Enough, already. > Doug Thanks Doug. Yes please, I think the conversation is descending below what I'd like to see here in TUHS/COFF and everybody has already made their point. Cheers, Warren From mrochkind at gmail.com Mon Jul 21 09:40:12 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Sun, 20 Jul 2025 17:40:12 -0600 Subject: [TUHS] how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference)) In-Reply-To: <20250720134754.3hiy6crrcqzw5qip@illithid> References: <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <20250720113802.GP15357@mcvoy.com> <20250720134754.3hiy6crrcqzw5qip@illithid> Message-ID: Maybe Doug's comment was too succinct. This back-and-forth personal argument, laced with insults and disrespect, seems wildly inappropriate for TUHS. Marc Rochkind On Sun, Jul 20, 2025 at 4:22 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > Hi Larry, > > At 2025-07-20T04:38:02-0700, Larry McVoy wrote: > > On Sun, Jul 20, 2025 at 02:59:08AM -0500, G. Branden Robinson wrote: > > > At 2025-07-19T20:16:33-0500, Will Senn wrote: > > > > I've thought about the "if you worked for me", dig and it kind of > > > > stung. > > > > > > Manure often does. > > > > > > Larry came up in the soil from which grew tech bro culture. > > > > > > A preoccupation with managing the preferences of others, as with > > > Steve Jobs's "thought leadership", is consistent with the > > > authoritarian style he advocates. > > > > Huh, you won't be surprised I have a different perspective. > > Indeed not. :) > > > Allow me to tell you how I describe managing engineers. Suppose we > > were artists, there were 4 of us. Someone brought us a photograph and > > said "I want a painting of that". OK, split it into quarters and go > > do it. What do we get back? > > > > Well, artist #1 likes oil paints so that's what s/he did. Artist #2 > > likes charcoal so that's what they did. Artist #3 likes pen and ink. > > Artist #4 likes water color. > > > > Is that a painting? Maybe if you like a mish mash of stuff that > > doesn't go together. Most people would call it garbage and refuse to > > pay. > > Yeah. I think your analogy is facile and superficial and therefore > characteristic of of Silicon Valley executive culture. Here's why. > > First, text editors don't leave traces of themselves in the work > product.[1] > > Second, _especially_ in a leadership position (although this is more > specifically the role of "architect" if someone has it), you have to be > conscious of the boundaries of your software modules. > > A software project of sufficient complexity to be worth commissioning on > a professional basis is, despite its contractual representation at the > executive level, not a unitary object like an individual painting or > photograph or 2½-minute folk song. Such things are not (formally) > complex, but "elemental": if you decompose them, they stop being what > they are. > > Often, a first-order decomposition of a software system leaves you > with...a collection of other software systems, plus, ideally, some > ancillary documentation and/or an integration test suite. > > > My so called "authoritarian style" is nothing more than I was the > > leader, I had to pick one style. > > Right. To hear you tell it, you preoccupied yourself with matters of > style and let others worry about the harder problems of architecture and > interfacing. Maybe that was the right choice given your skill set and > those of your staff. > > If that characterization cuts, there is a remedy: share a leadership > anecdote where you made (or mediated) a hard decision on a non-stylistic > matter. Maybe two algorithms of the same order in big-O notation were > pitched for a certain software module, but one was preferable on some > non-obvious basis. You've spoken before of the high value of SCCS's > "weave" to BitKeeper. Was there anything the weave made hard or was bad > at? Were you ever on the verge of reconsidering it? If so, what, on an > _engineering_ basis rather than one of style or personal admiration, > mandated its retention? > > If you have stories like that, those would, to me, constitute examples > of technical leadership. And, if all "stakeholders" (your client[s] > _and_ your staff) were happy with the outcome, then they could be > examples of _good_ technical leadership, too. > > > And, yes, it means if you have N people working you usually have N-1 > > pissed off people because they weren't getting to do things their way. > > I suspect you accurately perceived the presence of frustration. I also > bet you assumed its cause rather than undertaking an earnest exploration > thereof. A confounding factor here is that a project can have so many > problems that the individual contributors themselves have trouble > accurately identifying an "overall" problem or a single "worst" one that > they have. Further, if they are experiencing deadline pressure, whether > imposed by themselves or by leadership and are asked to identify > "blockers", they're likely to name the obstacles that are easiest to > articulate[2] or that they most recently struggled with.[3] One > generally can't calendar the removal of as-yet-unarticulated problems. > If the engineers have the same blocker day after day, then management is > failing to remove them. If the engineers have NEW blockers every day or > every week, and you have confidence in your recruitment/hiring, then > the staff is not sandbagging you--the project has deep problems. > > My personal experience is that underspecification and otherwise > unarticulated expectations are the root causes of nearly every problem > that cause anguish among staff. And behind that problem is the worse > one that managers climb into contractual beds with their counterparties > without having done their necessary homework first. The client never > wants to admit that they haven't really though through what it is > they're asking for. They've already made promises to a director, VP, or > someone in the C suite. So they yell at you and you yell at your staff. > > The manure, as it were, rolls downhill. > > > Letting them do things their way means there is no overall picture you > > are driving towards. > > In engineering, we do not implement an "overall picture", but to a > detailed specification. > > If you lack a detailed specification to implement, what you are doing is > not (solely) engineering. That's not necessarily a bad thing; you are > engaged in design and possibly in research. Charge more. Develop your > staff by helping them get conference papers out of the work. > > > And I'm not above being overridden. I personally hate GNU make for > > all the similar reasons you are advocating for a smaller vi. > > That wasn't me, but I'll freely admit that Vim has many features I don't > use. I have found that time spent seeking mastery of one tool is good > practice in judging the "right-sizing" of another. If nothing else, it > helps one learn which hills aren't worth dying on. ;-) > > Regarding make(1), POSIX 2024 has made it _much_ better. I still think > the BSDs' snarling adherence to old-style suffix rules, which are > inflexible and ambiguous, and restrictions on $< are counterproductive, > but a lot of stuff that used to not be portable, is portable now. > > > But my team convinced me it was less work to move to that than > > maintain all the scripts we were using to use a simple make. > > > > But yeah, when people work for me, I lead. I set the tone. It wasn't > > tech bro nonsense, it was about herding people towards the same > > picture. > > I have a slender hope that I can persuade you that these things are > actually the same in every way that matters. As implied above, this > doesn't make you a tech bro yourself, necessarily, it might mean you're > emphasizing the wrong elements of your experience for an audience of > salty old engineers, contrast with venture capitalists. > > In martial arts training, there are "degrees" of black belt. Only the > first few degrees have anything to do with one's own ability or > perfection of form. After that, your advancement is determined by how > many black belts you _train_. To become a master, you must train many > black belts. To become a grand master, you must train many masters. > While I'm sure there are perverse incentives in martial arts instruction > (hello, capitalism), this approach of making your own advancement beyond > a certain point dependent on the development of people no longer > accountable to you strikes me as a worthwhile corrective to the > narcissistic orientation of leadership in software development. > > Being a good example is a different phenomenon than being an object of > emulation. One phenomenon is deep, the other shallow. Steve Jobs was > good at producing a lot of fawning emulators with black turtlenecks and > glib proclamations about the future of technology. Steve Wozniak has in > substantial measure dedicated himself to producing more good engineers. > > > I wasn't trying to tell Will he can't use whatever editor he wants, I > > was trying to tell Will I wouldn't tolerate this much back and forth > > about his personal preferences distracting us from shipping product. > > That's not how I read what you said, but fine. I agree that bickering > over tool choice can be a distraction from satisfying the contract and > getting the final payment. But the sword of opportunity cost cuts both > ways. You can't always be sure that the most readily available > substitute good for an editor argument is a laser-focused coding > session[4] on implementing an element of a deliverable. > > If your engineers are motivated, you will find that they don't distract > themselves with nonsense _when they have a better alternative_. A good > engineering manager deeply understands the XKCD concept of "nerd > sniping" and knows how to adapt it to the benefit of the individual > contributor, their team, the client, and consequently themselves.[5] > > > My team had emacs people and vi people, nobody cared so long as you > > got your job done. > > That's a salutary attitude. But engineers also need time and vehicles > for decompression, and one of the things they can use their downtime for > is playful practice at evaluating tradeoffs between competing designs or > systems. > > If you have an engineer who's going around harassing their peers for > choosing the "wrong" editor, the problem is not their choice of editor, > which might be "correct" in your opinion. The problem is that they're > interfering unjustifiably with the work of their colleagues. Addressing > that problem "sets the tone" much better than expressing, let alone > mandating, your own preferences. It's what _I_ expect of a manager, at > any rate. > > > What we didn't have is editor arguments clogging up our thinking. > > Done well--and this might happen only in a minority of cases--editor > arguments can _enhance_ people's thinking; see "playful practice" above. > > And even if they don't, if they're no more destructive than a dispute > over whether the coach of the local sportsball team was an idiot for > benching player X in the Big Game last weekend, or than knocking off 30 > minutes early for beers together at the end of a frustrating day, then > good leadership can mean leaving some rough spots unsanded. > > Regards, > Branden > > [1] _Programmers_ might so do, with vi "modelines" or Emacs "local > variables" in text constitutive of a comment in the program source > code. Different matter. > > [2] another instance of our old friend the "streetlight effect" > https://en.wikipedia.org/wiki/Streetlight_effect > > [3] https://en.wikipedia.org/wiki/Recency_bias > > [4] or automated test construction, or documentation revision--wait, why > is everybody laughing? > > [5] https://xkcd.com/356/ > -- Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Jul 21 11:20:05 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 20 Jul 2025 18:20:05 -0700 Subject: [TUHS] how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference)) In-Reply-To: References: <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <20250720113802.GP15357@mcvoy.com> <20250720134754.3hiy6crrcqzw5qip@illithid> Message-ID: <20250721012005.GW15357@mcvoy.com> As I said to Warren, that is partially on me. I have a bad habit of letting myself get drawn into discussions where I should just let it go. I apologize for the noise, added Brandon to my procmailrc so I'll not see his emails. Not sure what I did to draw his ire but I'll not feed the fire in the future. For the record, I was shaken up about this exchange as well, came pretty close to unsubscribing so I wouldn't cause problems down the line. I'm retired, I love going down memory lane as much as the next guy, but having a fight? At my age? Please, no. On Sun, Jul 20, 2025 at 05:40:12PM -0600, Marc Rochkind wrote: > Maybe Doug's comment was too succinct. > > This back-and-forth personal argument, laced with insults and disrespect, > seems wildly inappropriate for TUHS. > > Marc Rochkind > > On Sun, Jul 20, 2025 at 4:22???PM G. Branden Robinson < > g.branden.robinson at gmail.com> wrote: > > > Hi Larry, > > > > At 2025-07-20T04:38:02-0700, Larry McVoy wrote: > > > On Sun, Jul 20, 2025 at 02:59:08AM -0500, G. Branden Robinson wrote: > > > > At 2025-07-19T20:16:33-0500, Will Senn wrote: > > > > > I've thought about the "if you worked for me", dig and it kind of > > > > > stung. > > > > > > > > Manure often does. > > > > > > > > Larry came up in the soil from which grew tech bro culture. > > > > > > > > A preoccupation with managing the preferences of others, as with > > > > Steve Jobs's "thought leadership", is consistent with the > > > > authoritarian style he advocates. > > > > > > Huh, you won't be surprised I have a different perspective. > > > > Indeed not. :) > > > > > Allow me to tell you how I describe managing engineers. Suppose we > > > were artists, there were 4 of us. Someone brought us a photograph and > > > said "I want a painting of that". OK, split it into quarters and go > > > do it. What do we get back? > > > > > > Well, artist #1 likes oil paints so that's what s/he did. Artist #2 > > > likes charcoal so that's what they did. Artist #3 likes pen and ink. > > > Artist #4 likes water color. > > > > > > Is that a painting? Maybe if you like a mish mash of stuff that > > > doesn't go together. Most people would call it garbage and refuse to > > > pay. > > > > Yeah. I think your analogy is facile and superficial and therefore > > characteristic of of Silicon Valley executive culture. Here's why. > > > > First, text editors don't leave traces of themselves in the work > > product.[1] > > > > Second, _especially_ in a leadership position (although this is more > > specifically the role of "architect" if someone has it), you have to be > > conscious of the boundaries of your software modules. > > > > A software project of sufficient complexity to be worth commissioning on > > a professional basis is, despite its contractual representation at the > > executive level, not a unitary object like an individual painting or > > photograph or 2??-minute folk song. Such things are not (formally) > > complex, but "elemental": if you decompose them, they stop being what > > they are. > > > > Often, a first-order decomposition of a software system leaves you > > with...a collection of other software systems, plus, ideally, some > > ancillary documentation and/or an integration test suite. > > > > > My so called "authoritarian style" is nothing more than I was the > > > leader, I had to pick one style. > > > > Right. To hear you tell it, you preoccupied yourself with matters of > > style and let others worry about the harder problems of architecture and > > interfacing. Maybe that was the right choice given your skill set and > > those of your staff. > > > > If that characterization cuts, there is a remedy: share a leadership > > anecdote where you made (or mediated) a hard decision on a non-stylistic > > matter. Maybe two algorithms of the same order in big-O notation were > > pitched for a certain software module, but one was preferable on some > > non-obvious basis. You've spoken before of the high value of SCCS's > > "weave" to BitKeeper. Was there anything the weave made hard or was bad > > at? Were you ever on the verge of reconsidering it? If so, what, on an > > _engineering_ basis rather than one of style or personal admiration, > > mandated its retention? > > > > If you have stories like that, those would, to me, constitute examples > > of technical leadership. And, if all "stakeholders" (your client[s] > > _and_ your staff) were happy with the outcome, then they could be > > examples of _good_ technical leadership, too. > > > > > And, yes, it means if you have N people working you usually have N-1 > > > pissed off people because they weren't getting to do things their way. > > > > I suspect you accurately perceived the presence of frustration. I also > > bet you assumed its cause rather than undertaking an earnest exploration > > thereof. A confounding factor here is that a project can have so many > > problems that the individual contributors themselves have trouble > > accurately identifying an "overall" problem or a single "worst" one that > > they have. Further, if they are experiencing deadline pressure, whether > > imposed by themselves or by leadership and are asked to identify > > "blockers", they're likely to name the obstacles that are easiest to > > articulate[2] or that they most recently struggled with.[3] One > > generally can't calendar the removal of as-yet-unarticulated problems. > > If the engineers have the same blocker day after day, then management is > > failing to remove them. If the engineers have NEW blockers every day or > > every week, and you have confidence in your recruitment/hiring, then > > the staff is not sandbagging you--the project has deep problems. > > > > My personal experience is that underspecification and otherwise > > unarticulated expectations are the root causes of nearly every problem > > that cause anguish among staff. And behind that problem is the worse > > one that managers climb into contractual beds with their counterparties > > without having done their necessary homework first. The client never > > wants to admit that they haven't really though through what it is > > they're asking for. They've already made promises to a director, VP, or > > someone in the C suite. So they yell at you and you yell at your staff. > > > > The manure, as it were, rolls downhill. > > > > > Letting them do things their way means there is no overall picture you > > > are driving towards. > > > > In engineering, we do not implement an "overall picture", but to a > > detailed specification. > > > > If you lack a detailed specification to implement, what you are doing is > > not (solely) engineering. That's not necessarily a bad thing; you are > > engaged in design and possibly in research. Charge more. Develop your > > staff by helping them get conference papers out of the work. > > > > > And I'm not above being overridden. I personally hate GNU make for > > > all the similar reasons you are advocating for a smaller vi. > > > > That wasn't me, but I'll freely admit that Vim has many features I don't > > use. I have found that time spent seeking mastery of one tool is good > > practice in judging the "right-sizing" of another. If nothing else, it > > helps one learn which hills aren't worth dying on. ;-) > > > > Regarding make(1), POSIX 2024 has made it _much_ better. I still think > > the BSDs' snarling adherence to old-style suffix rules, which are > > inflexible and ambiguous, and restrictions on $< are counterproductive, > > but a lot of stuff that used to not be portable, is portable now. > > > > > But my team convinced me it was less work to move to that than > > > maintain all the scripts we were using to use a simple make. > > > > > > But yeah, when people work for me, I lead. I set the tone. It wasn't > > > tech bro nonsense, it was about herding people towards the same > > > picture. > > > > I have a slender hope that I can persuade you that these things are > > actually the same in every way that matters. As implied above, this > > doesn't make you a tech bro yourself, necessarily, it might mean you're > > emphasizing the wrong elements of your experience for an audience of > > salty old engineers, contrast with venture capitalists. > > > > In martial arts training, there are "degrees" of black belt. Only the > > first few degrees have anything to do with one's own ability or > > perfection of form. After that, your advancement is determined by how > > many black belts you _train_. To become a master, you must train many > > black belts. To become a grand master, you must train many masters. > > While I'm sure there are perverse incentives in martial arts instruction > > (hello, capitalism), this approach of making your own advancement beyond > > a certain point dependent on the development of people no longer > > accountable to you strikes me as a worthwhile corrective to the > > narcissistic orientation of leadership in software development. > > > > Being a good example is a different phenomenon than being an object of > > emulation. One phenomenon is deep, the other shallow. Steve Jobs was > > good at producing a lot of fawning emulators with black turtlenecks and > > glib proclamations about the future of technology. Steve Wozniak has in > > substantial measure dedicated himself to producing more good engineers. > > > > > I wasn't trying to tell Will he can't use whatever editor he wants, I > > > was trying to tell Will I wouldn't tolerate this much back and forth > > > about his personal preferences distracting us from shipping product. > > > > That's not how I read what you said, but fine. I agree that bickering > > over tool choice can be a distraction from satisfying the contract and > > getting the final payment. But the sword of opportunity cost cuts both > > ways. You can't always be sure that the most readily available > > substitute good for an editor argument is a laser-focused coding > > session[4] on implementing an element of a deliverable. > > > > If your engineers are motivated, you will find that they don't distract > > themselves with nonsense _when they have a better alternative_. A good > > engineering manager deeply understands the XKCD concept of "nerd > > sniping" and knows how to adapt it to the benefit of the individual > > contributor, their team, the client, and consequently themselves.[5] > > > > > My team had emacs people and vi people, nobody cared so long as you > > > got your job done. > > > > That's a salutary attitude. But engineers also need time and vehicles > > for decompression, and one of the things they can use their downtime for > > is playful practice at evaluating tradeoffs between competing designs or > > systems. > > > > If you have an engineer who's going around harassing their peers for > > choosing the "wrong" editor, the problem is not their choice of editor, > > which might be "correct" in your opinion. The problem is that they're > > interfering unjustifiably with the work of their colleagues. Addressing > > that problem "sets the tone" much better than expressing, let alone > > mandating, your own preferences. It's what _I_ expect of a manager, at > > any rate. > > > > > What we didn't have is editor arguments clogging up our thinking. > > > > Done well--and this might happen only in a minority of cases--editor > > arguments can _enhance_ people's thinking; see "playful practice" above. > > > > And even if they don't, if they're no more destructive than a dispute > > over whether the coach of the local sportsball team was an idiot for > > benching player X in the Big Game last weekend, or than knocking off 30 > > minutes early for beers together at the end of a frustrating day, then > > good leadership can mean leaving some rough spots unsanded. > > > > Regards, > > Branden > > > > [1] _Programmers_ might so do, with vi "modelines" or Emacs "local > > variables" in text constitutive of a comment in the program source > > code. Different matter. > > > > [2] another instance of our old friend the "streetlight effect" > > https://en.wikipedia.org/wiki/Streetlight_effect > > > > [3] https://en.wikipedia.org/wiki/Recency_bias > > > > [4] or automated test construction, or documentation revision--wait, why > > is everybody laughing? > > > > [5] https://xkcd.com/356/ > > > > > -- > Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Mon Jul 21 11:44:26 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 21 Jul 2025 01:44:26 +0000 Subject: [TUHS] Teletypes used for early Unix Message-ID: Hello all, What teleprinter models were used at Bell Labs, particularly by the Unix groups? Judging by troff escape sequences, it expected a Teletype Model 37, and early all-caps support implies Model 33 usage. But I don’t have a sense of what users and the core developers used. I am working on building a Teletype Model 37 ASR emulator for my PiDP-11 with the goal of replicating the early Unix experience as accurately as possible without physical hardware. As I get deeper into research, I’ve learned of a variety of configuration options beyond what the operator could configure with buttons, e.g., sub-models which come with different components, optional components which can be installed later, and features that can be configured by a craftsman. Here are some examples: - Two-color was optional - The shift-out character set was configurable - An ASR could come without a tape reader/puncher - Half-line forward and reverse was optional - Character sizes varied, e.g., 72 chars per line at 10 chars per inch, adjustable up to 80 per line; or 86 per line at 12 per inch - The paper could be roll paper (friction feed)or flat-folded, form-feed paper with marginal perforations (sprocket feed) - Paper sizes varied, e.g., 3 to 8-1/2 wide or, for sprocket feed, up to 11 inches long and 9-1/2 wide - Some printed control characters; most didn’t - Holding a key could be configured to repeat the character - They could operate half-duplex (transmitted data is copied by the sender) or full-duplex (only received data is copied) - They could receive and transmit at various speeds That’s a lot of options and it’s not exhaustive. The Model 37 product catalog[0] has tables of many configurations and their catalog numbers. Is there a list of the teleprinters purchased by Bell Labs? With that, I could possibly narrow it down like how Warner Losh identified the PDP-7 model used for Unix V0. Thanks! Thalia Archibald [0]: https://ia800702.us.archive.org/32/items/TNM_Model_37_terminal_product_catalog_-_Teletype__20170923_0036/TNM_Model_37_terminal_product_catalog_-_Teletype__20170923_0036.pdf [1]: https://bsdimp.blogspot.com/2019/07/the-pdp-7-where-unix-began.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Jul 21 13:18:51 2025 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 21 Jul 2025 13:18:51 +1000 (EST) Subject: [TUHS] Teletypes used for early Unix In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025, Thalia Archibald via TUHS wrote: [...] > I am working on building a Teletype Model 37 ASR emulator for my PiDP-11 > with the goal of replicating the early Unix experience as accurately as > possible without physical hardware. The fount of all wisdom and knowledge on Teletypes would be the "Greenkeys" mailing list, over at List-Id: "Discussion of older radio teletype (RTTY) gear "" It's RTTY (Radio Teletype) related i.e. "ham" radio, but there's a lot of knowledge over there. -- Dave From grog at lemis.com Mon Jul 21 14:03:38 2025 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 21 Jul 2025 14:03:38 +1000 Subject: [TUHS] Not really Emacs wars (was: foreground/background vs. Windowing) In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: On Saturday, 19 July 2025 at 19:27:40 -0600, Warner Losh wrote: > On Sat, Jul 19, 2025 at 6:36 PM Greg 'groggy' Lehey wrote: >> >> [Somewhat off-topic for TUHS; please follow up at COFF] >> >> On Saturday, 19 July 2025 at 17:37:34 -0600, Warner Losh wrote: >>> >>> Also, there are no GUI emacs versions I like.. >> >> You have me curious. How many do you know? And what don't you like >> about them, when you clearly use Emacs? > > Most of the emacs GUI adaptations assume that it's THE instance of the > editor. You don't say which. I only know GNU Emacs. Looking at the FreeBSD Ports Collection, not even xemacs seems to have survived. > With multiple terminals, I can have multiple editors with different > contexts. With the GUI, it all gets dumped together. Not in my experience (GNU Emacs 29.4 (build 1, amd64-portbld-freebsd13.3, GTK+ Version 3.24.43, cairo version 1.17.4). I have four displays on my server 0, and also 4 instances of Emacs: one on :0.1 and three on :0.2. You need to start them individually, of course, but that's what shells are for. Each Emacs can open windows on other displays, and that's useful if they're on other machines, but it's not the only way. Can it be that your negative experience was with another version that has since died? What you describe sounds like my pain with web browsers. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From noel.hunt at gmail.com Mon Jul 21 17:53:52 2025 From: noel.hunt at gmail.com (Noel Hunt) Date: Mon, 21 Jul 2025 17:53:52 +1000 Subject: [TUHS] upwards from ed (was: End of an era: the last ATC) In-Reply-To: References: Message-ID: I couldn't agree more. After I was exposed to 'sam' in 1987, there was no other editor. I was, however, heavily involved in the porting of 'pads' and 'pi' to Solaris and Linux, and 'pads' has a 'move' operation, distinct from 'resize/reshape'. I had sometimes felt the need of such an operation when I had a large samterm open with lots of open files, so, with no pretensions to originality, I took the code from 'pads' and put it into 'samterm', and it was trivial to add. For which I should perhaps apologize to the author of 'sam'. On Fri, 18 Jul 2025 at 12:12, Douglas McIlroy wrote: > I always recoiled from vi's plethora of commands. Then came sam, and I > haven't looked back since. It handles multiple windows with barely > more commands than ed, real regular expressions, good mouse support, > and great global editing capability. It can even run by script without > a screen. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hauke at Espresso.Rhein-Neckar.DE Mon Jul 21 18:03:08 2025 From: hauke at Espresso.Rhein-Neckar.DE (Hauke Fath) Date: Mon, 21 Jul 2025 10:03:08 +0200 Subject: [TUHS] Not really Emacs wars (was: foreground/background vs. Windowing) In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: <20250721100308061059.819cdc08@Espresso.Rhein-Neckar.DE> On Mon, 21 Jul 2025 14:03:38 +1000, "Greg 'groggy' Lehey" wrote: >> >> Most of the emacs GUI adaptations assume that it's THE instance of the >> editor. > > You don't say which. I only know GNU Emacs. Looking at the FreeBSD > Ports Collection, not even xemacs seems to have survived. That would be more a problem of the FreeBSD ports collection than of xemacs, if I may say so as the pkgsrc xemacs* package maintainer. Some Linuxen ship xemacs packages, too - Gentoo, Debian come to mind. You can always - dare I say it? - build from source. XEmacs is actively maintained, I don't know how SXEmacs is doing these days. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany From arnold at skeeve.com Mon Jul 21 21:04:40 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 21 Jul 2025 05:04:40 -0600 Subject: [TUHS] formatting 1981 troff today? Message-ID: <202507211104.56LB4eZn016130@freefriends.org> Hi All. As a back burner project, I have the sources for a book, given to me by the author, from around 1981. It was originally formatted using the device independent troff suite. It used the -ms macros plus an additional set of custom macros. I have the additional macros. The book used tbl and pic. A quick grep does not find any instances of .EQ, so it looks like eqn isn't needed. I would like to be able to format the book and generate PDF. What's the best way to go about this? Using groff in compatibility mode? Or the Heirloom troff suite? If the latter, what's the canonical location for it? I will be working on Linux, Ubuntu 24.04. Any and all advice will be welcome. Thanks, Arnold From ralph at inputplus.co.uk Mon Jul 21 21:39:45 2025 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 21 Jul 2025 12:39:45 +0100 Subject: [TUHS] formatting 1981 troff today? In-Reply-To: <202507211104.56LB4eZn016130@freefriends.org> References: <202507211104.56LB4eZn016130@freefriends.org> Message-ID: <20250721113945.95EBB22010@orac.inputplus.co.uk> Hi Arnold, > Or the Heirloom troff suite? If the latter, what's the canonical > location for it? I think it's https://n-t-roff.github.io/heirloom/doctools.html Could you use a late-edition Unix as an alternative? -- Cheers, Ralph. From arnold at skeeve.com Mon Jul 21 21:52:16 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 21 Jul 2025 05:52:16 -0600 Subject: [TUHS] formatting 1981 troff today? In-Reply-To: <20250721113945.95EBB22010@orac.inputplus.co.uk> References: <202507211104.56LB4eZn016130@freefriends.org> <20250721113945.95EBB22010@orac.inputplus.co.uk> Message-ID: <202507211152.56LBqGD2019247@freefriends.org> Ralph Corderoy wrote: > Hi Arnold, > > > Or the Heirloom troff suite? If the latter, what's the canonical > > location for it? > > I think it's https://n-t-roff.github.io/heirloom/doctools.html Much thanks. I will try to give this a spin. My round tuits are on the way from Amazon and should arrive in about two weeks. > Could you use a late-edition Unix as an alternative? No, I don't have any kind of SimH setup and that's overkill. In particular I want to be able to use Git so that I can make changes if necessary. Thanks! Arnold From tytso at mit.edu Mon Jul 21 21:52:32 2025 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 21 Jul 2025 07:52:32 -0400 Subject: [TUHS] [COFF] Re: Re: Not really Emacs wars (was: foreground/background vs. Windowing) In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: <20250721115232.GC231115@mit.edu> On Mon, Jul 21, 2025 at 02:03:38PM +1000, Greg 'groggy' Lehey wrote: > > With multiple terminals, I can have multiple editors with different > > contexts. With the GUI, it all gets dumped together. > > Not in my experience (GNU Emacs 29.4 (build 1, > amd64-portbld-freebsd13.3, GTK+ Version 3.24.43, cairo version > 1.17.4). I have four displays on my server 0, and also 4 instances of > Emacs: one on :0.1 and three on :0.2. Yeah, it doesn't work that way for me using GNU emacs on Debian either. Many decades ago I did force the behaviour that you describe; it involved setting EDITOR to emacsclient, and then running (server-start) in my ~/.emacs.el. This was a feature back when I was running emacs on BSD 4.3 with a Vaxstation II/RC with 2 MiB of memory (Digital had put epoxy into the backplane so you couldn't add more memory to their memory-starved inexpensive model), but now that I buy my own desktops with 64 GiB of memory, I really don't care that emacs is "eight megabytes and constantly swapping" (well, not swapping; I don't configure swap any more :-) and emacsclient is more annoying than it's worth. - Ted From ralph at inputplus.co.uk Mon Jul 21 22:15:30 2025 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 21 Jul 2025 13:15:30 +0100 Subject: [TUHS] formatting 1981 troff today? In-Reply-To: <202507211152.56LBqGD2019247@freefriends.org> References: <202507211104.56LB4eZn016130@freefriends.org> <20250721113945.95EBB22010@orac.inputplus.co.uk> <202507211152.56LBqGD2019247@freefriends.org> Message-ID: <20250721121530.2894F21F15@orac.inputplus.co.uk> Hi Arnold, > > Could you use a late-edition Unix as an alternative? > > No, I don't have any kind of SimH setup and that's overkill. > In particular I want to be able to use Git so that I can make changes > if necessary. I was thinking the native makefile would update a disk image, then have the simulated system mount that ‘disk’, run the hosted make, and unmount. Or any other means to sync the native files to the old system just for the build step. But I agree that could be a faff if you just want to get the book built. Heirloom's a good starting place. -- Cheers, Ralph. From lm at mcvoy.com Mon Jul 21 23:16:29 2025 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 21 Jul 2025 06:16:29 -0700 Subject: [TUHS] formatting 1981 troff today? In-Reply-To: <20250721121530.2894F21F15@orac.inputplus.co.uk> References: <202507211104.56LB4eZn016130@freefriends.org> <20250721113945.95EBB22010@orac.inputplus.co.uk> <202507211152.56LBqGD2019247@freefriends.org> <20250721121530.2894F21F15@orac.inputplus.co.uk> Message-ID: <20250721131629.GC15357@mcvoy.com> On Mon, Jul 21, 2025 at 01:15:30PM +0100, Ralph Corderoy wrote: > Hi Arnold, > > > > Could you use a late-edition Unix as an alternative? > > > > No, I don't have any kind of SimH setup and that's overkill. > > In particular I want to be able to use Git so that I can make changes > > if necessary. > > I was thinking the native makefile would update a disk image, then have > the simulated system mount that ???disk???, run the hosted make, and > unmount. Or any other means to sync the native files to the old system > just for the build step. > > But I agree that could be a faff if you just want to get the book built. > Heirloom's a good starting place. Have you just tried groff? I'm guessing you have, it produced something, but you are not sure it is correct? For me, groff tends to just work. From aap at papnet.eu Mon Jul 21 23:44:09 2025 From: aap at papnet.eu (Angelo Papenhoff) Date: Mon, 21 Jul 2025 15:44:09 +0200 Subject: [TUHS] formatting 1981 troff today? In-Reply-To: <202507211104.56LB4eZn016130@freefriends.org> References: <202507211104.56LB4eZn016130@freefriends.org> Message-ID: Maybe plan 9 troff? aap On 21/07/25, arnold at skeeve.com wrote: > Hi All. > > As a back burner project, I have the sources for a book, given to me > by the author, from around 1981. It was originally formatted using > the device independent troff suite. It used the -ms macros plus an > additional set of custom macros. I have the additional macros. > > The book used tbl and pic. A quick grep does not find any instances > of .EQ, so it looks like eqn isn't needed. > > I would like to be able to format the book and generate PDF. > > What's the best way to go about this? Using groff in compatibility > mode? Or the Heirloom troff suite? If the latter, what's the > canonical location for it? > > I will be working on Linux, Ubuntu 24.04. > > Any and all advice will be welcome. > > Thanks, > > Arnold From tuhs at tuhs.org Mon Jul 21 23:56:49 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Mon, 21 Jul 2025 09:56:49 -0400 Subject: [TUHS] foreground/background vs. Windowing In-Reply-To: References: <73b781b8-f804-4116-8dfe-2b0af7f67506@skogtun.org> Message-ID: <1756ef3e-6616-42d4-89ab-44ecf4e1e0cf@case.edu> On 7/19/25 7:03 PM, Noel Hunt wrote: > >> I still like to use ^Z to suspend a running program, even when I use >> X11. > > Since it would appear that that is totally unnecessary in a > window system, as Doug pointed out, one has to ask why? Because it's often quicker, easier, preserves session context, and is integrated into personal workflows. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From clemc at ccc.com Tue Jul 22 00:10:10 2025 From: clemc at ccc.com (Clem Cole) Date: Mon, 21 Jul 2025 10:10:10 -0400 Subject: [TUHS] formatting 1981 troff today? In-Reply-To: <202507211104.56LB4eZn016130@freefriends.org> References: <202507211104.56LB4eZn016130@freefriends.org> Message-ID: On Mon, Jul 21, 2025 at 7:04 AM wrote: > I will be working on Linux, Ubuntu 24.04. > Can't speak for Linux, but the original ditroff kit from AT&T troff toolchest and the original Adobe transcript just compiled on macOS the last time I tried. That said, I have mostly switched to groff as Larry mentioned, but I have a couple of things that I don't want to introduce artifacts, and when I did that, I always used the real thing. One thing to be careful of is that if you are creating PS (or later PDF), you might want to consider transcript, although later versions of ditroff, AT&T included dpost(1troff). Depending when the book was built, the original AT&T ditroff tables only supported the Meganthaler, the APS5 and /C/A/T and you needed to purchase Transcript from Adobe to get the psdit() command and the tables [At Masscomp to cut down on support at the time, we ate the binary redistribution for both and just included them both as our standard troff kit]. Groff added -Tpdf, which is lacking in Transcript, but PS was de rigre in those days, particularly with Display PostScript, so systems like macOS's "preview" could open them directly [not so today]. You need Acrobat or a replacement to convert [again today, I use ps2pdf from Ghostscript, but again for things that I want as close to the original as possible, I leave them as -Tps from ditroff and psdit. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Jul 22 00:12:27 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Mon, 21 Jul 2025 10:12:27 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <20250720075908.w6tetlcb3zhowbby@illithid> References: <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> Message-ID: <7a6615a5-ddda-469e-9323-a1159a25475c@case.edu> On 7/20/25 3:59 AM, G. Branden Robinson wrote: > On the milder topic of editor preferences, I'm a vi(m) user but employ > Emacs bindings in readline applications and maintained my own fork of mg > (microemacs) for a while, to see how the other half lived. I discovered > that a much bigger chunk of Emacs advocacy is predicated on its > "finger-feel"[1] I think, as I said in another message, that familiarity has a lot to do with the comfort that people feel. Muscle memory is important. I would also note that emacs-style key bindings are pervasive -- even on macOS, where the system's text objects (e.g., what you use in TextEdit) all have emacs-style key bindings by default, down to things like the browsers' address bar and search field. Even the Spotlight search bar uses emacs key bindings. This was all inherited from NeXTOS. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From arnold at skeeve.com Tue Jul 22 01:10:47 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 21 Jul 2025 09:10:47 -0600 Subject: [TUHS] formatting 1981 troff today? In-Reply-To: <20250721131629.GC15357@mcvoy.com> References: <202507211104.56LB4eZn016130@freefriends.org> <20250721113945.95EBB22010@orac.inputplus.co.uk> <202507211152.56LBqGD2019247@freefriends.org> <20250721121530.2894F21F15@orac.inputplus.co.uk> <20250721131629.GC15357@mcvoy.com> Message-ID: <202507211510.56LFAlie033840@freefriends.org> Larry McVoy wrote: > On Mon, Jul 21, 2025 at 01:15:30PM +0100, Ralph Corderoy wrote: > > Hi Arnold, > > > > > > Could you use a late-edition Unix as an alternative? > > > > > > No, I don't have any kind of SimH setup and that's overkill. > > > In particular I want to be able to use Git so that I can make changes > > > if necessary. > > > > I was thinking the native makefile would update a disk image, then have > > the simulated system mount that ???disk???, run the hosted make, and > > unmount. Or any other means to sync the native files to the old system > > just for the build step. > > > > But I agree that could be a faff if you just want to get the book built. > > Heirloom's a good starting place. > > Have you just tried groff? I'm guessing you have, it produced something, > but you are not sure it is correct? > > For me, groff tends to just work. For me too. I haven't tried anything yet. My gut feel is that using original troff will be the fastest path, but I may try groff. As to Plan 9 troff, I don't have a Plan 9 system, and don't want to spend the time right now to climb that learning curve. Thanks everyone, Arnold From ralph at inputplus.co.uk Tue Jul 22 02:39:52 2025 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 21 Jul 2025 17:39:52 +0100 Subject: [TUHS] formatting 1981 troff today? In-Reply-To: <202507211510.56LFAlie033840@freefriends.org> References: <202507211104.56LB4eZn016130@freefriends.org> <20250721113945.95EBB22010@orac.inputplus.co.uk> <202507211152.56LBqGD2019247@freefriends.org> <20250721121530.2894F21F15@orac.inputplus.co.uk> <20250721131629.GC15357@mcvoy.com> <202507211510.56LFAlie033840@freefriends.org> Message-ID: <20250721163952.A845321EFD@orac.inputplus.co.uk> Hi Arnold, > My gut feel is that using original troff will be the fastest path Mine too; less discrepencies to first notice, and then resolve. > As to Plan 9 troff, I don't have a Plan 9 system Russ Cox's Plan 9 from User Space? It includes troff and friends. https://9fans.github.io/plan9port/ -- Cheers, Ralph. From crossd at gmail.com Tue Jul 22 02:41:53 2025 From: crossd at gmail.com (Dan Cross) Date: Mon, 21 Jul 2025 12:41:53 -0400 Subject: [TUHS] formatting 1981 troff today? In-Reply-To: <202507211510.56LFAlie033840@freefriends.org> References: <202507211104.56LB4eZn016130@freefriends.org> <20250721113945.95EBB22010@orac.inputplus.co.uk> <202507211152.56LBqGD2019247@freefriends.org> <20250721121530.2894F21F15@orac.inputplus.co.uk> <20250721131629.GC15357@mcvoy.com> <202507211510.56LFAlie033840@freefriends.org> Message-ID: On Mon, Jul 21, 2025 at 11:17 AM wrote: > For me too. I haven't tried anything yet. My gut feel is that using > original troff will be the fastest path, but I may try groff. Heirloom is certainly a viable way to go to start. > As to Plan 9 troff, I don't have a Plan 9 system, and don't want to > spend the time right now to climb that learning curve. I can appreciate that, but just a quick reminder about and a small plug for "Plan 9 from Userspace", where most of the libraries and tools have been ported to Unix-y style systems, including troff and the associated pieces: https://github.com/9fans/plan9port/ - Dan C. From douglas.mcilroy at dartmouth.edu Tue Jul 22 03:23:44 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 21 Jul 2025 13:23:44 -0400 Subject: [TUHS] [COFF] Code/comment Ratios Style In-Reply-To: <20250721132852.GD15357@mcvoy.com> References: <20250721020638.GA15357@mcvoy.com> <20250721021843.GB15357@mcvoy.com> <20250721132852.GD15357@mcvoy.com> Message-ID: Larry McVoy wrote > Well, we had begin and end blocks. And other than that, the whole thing > is a wad that is called per line. That was definitely awk inspired. The way I have used m4, a program is executed just once from top to bottom. There is no input file. Another way to describe it is that the program is the input file, which happens to have some program elements interspersed. But m4 never acts as awk does, running the whole "wad" on each line of a separate input file. Of course, one often puts definitions in one file, and "data" in another and catenates them. Then, however, it is only convention--not language design--that keeps the program and data separate. In awk, the separation is absolute. > I'm surprised you see lisp and haskell. The language came from me > and I've never touched haskell and I tried to like lisp, I really > did, but it never grew on me. Care to explain why you saw that? The parenthesized decomposition of a list comes straight out of Lisp, with car-cdr terminology (referring to parts of an IBM 700-series word) modernized to Haskell's more intuitive head and tail. The functional style of programming imitates Haskell within the confines of m4 syntax, but of course. Lisp founded the functional tradition. The word "atom" is borrowed from Lisp, "foldl", "foldr", and "zip" come from Haskell. Doug On Mon, Jul 21, 2025 at 9:28 AM Larry McVoy wrote: > > Well, we had begin and end blocks. And other than that, the whole thing > is a wad that is called per line. That was definitely awk inspired. > > I'm surprised you see lisp and haskell. The language came from me > and I've never touched haskell and I tried to like lisp, I really > did, but it never grew on me. Care to explain why you saw that? > > For what it is worth, nobody cares because all that code is dead, but > I'm proud of that little language, it's miles and miles beyound what > SCCS could do. I whipped up that json dspec pretty quickly and my > memory is it just worked, we didn't have to go back and fix anything. > > And it is fast. It used to be lex/yacc but that was too slow so Rob > rewrote it as a recursive-descent parser that was boatloads faster. > We actually used that language quite a bit. > > On Mon, Jul 21, 2025 at 07:19:00AM -0400, Douglas McIlroy wrote: > No awk > at all. Much imitation of Lisp and Haskell > > On Sunday, July 20, 2025, > Larry McVoy wrote: > > > On Sun, Jul 20, 2025 at 07:06:38PM > -0700, Larry McVoy wrote: > > > On Sun, Jul 20, 2025 at 08:30:45PM -0400, > Douglas McIlroy wrote: > > > > I just posted the most heavily commented > code I have ever written. > > > > It's a radical (mis?)application of m4, > which is about as inscrutable > > > > as any language short of APL. The > ratio of comments to code is more > > > > than 3:1. > > > > It's at > www.cs.dartmouth.edu/~doug/barem4.m4. 3:1 may be > > > > overkill, but > I think 2:1 would not be unreasonable. > > > > > > > > Doug > > > > > > > Whenever I see something like this, it reminds me of one of my engineers > > > > who said you couldn't make BK produce json out put. > > > > > > Hold > my beer. > > > > > > http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt > > > > > > > It's a lot less miserable than the m4 (and I'm a fan of m4). > > > > > It's pretty awk inspired. > > -- > > --- > > Larry McVoy > Retired to fishing > > http://www.mcvoy.com/lm/boat > > > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From crossd at gmail.com Tue Jul 22 04:37:04 2025 From: crossd at gmail.com (Dan Cross) Date: Mon, 21 Jul 2025 14:37:04 -0400 Subject: [TUHS] [COFF] Code/comment Ratios Style In-Reply-To: References: <20250721020638.GA15357@mcvoy.com> <20250721021843.GB15357@mcvoy.com> <20250721132852.GD15357@mcvoy.com> Message-ID: On Mon, Jul 21, 2025 at 1:32 PM Douglas McIlroy wrote: > Larry McVoy wrote > > Well, we had begin and end blocks. And other than that, the whole thing > > is a wad that is called per line. That was definitely awk inspired. > > The way I have used m4, a program is executed just once from top to bottom. > [snip] I do not believe Larry is referring (directly) to M4 with this comment, but rather, referring to the language he used for the example he posted earlier, at: http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt That language is, if I understand correctly, an invention of Larry's, that drew inspiration from awk, and that he saw as an improvement over M4 for the purpose of making bitkeeper emit JSON. - Dan C. From lm at mcvoy.com Tue Jul 22 05:40:15 2025 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 21 Jul 2025 12:40:15 -0700 Subject: [TUHS] [COFF] Code/comment Ratios Style In-Reply-To: References: <20250721020638.GA15357@mcvoy.com> <20250721021843.GB15357@mcvoy.com> <20250721132852.GD15357@mcvoy.com> Message-ID: <20250721194015.GK15357@mcvoy.com> Dan is spot on, almost, see below. On Mon, Jul 21, 2025 at 02:37:04PM -0400, Dan Cross wrote: > On Mon, Jul 21, 2025 at 1:32???PM Douglas McIlroy > wrote: > > Larry McVoy wrote > > > Well, we had begin and end blocks. And other than that, the whole thing > > > is a wad that is called per line. That was definitely awk inspired. > > > > The way I have used m4, a program is executed just once from top to bottom. > > [snip] > > I do not believe Larry is referring (directly) to M4 with this > comment, but rather, referring to the language he used for the example > he posted earlier, at: > http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt > > That language is, if I understand correctly, an invention of Larry's, > that drew inspiration from awk, and that he saw as an improvement over > M4 for the purpose of making bitkeeper emit JSON. It's a general purpose output language for stuff contained in BitKeeper. :WHATEVER: digs the current graph nodes n->whatever. The json dspec is an example of that language being told to emit JSON, but you can write dspecs for anything. Think git log --dspec-file=/path/to/dspec and now you can have any output format you like. I sort of mislead people when I said it was like awk, it sort of is, but each awk line is a revision in the graph you are looking at. So the dspec runs on each revsision. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From arnold at skeeve.com Tue Jul 22 17:21:01 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 22 Jul 2025 01:21:01 -0600 Subject: [TUHS] formatting 1981 troff today? In-Reply-To: <20250721163952.A845321EFD@orac.inputplus.co.uk> References: <202507211104.56LB4eZn016130@freefriends.org> <20250721113945.95EBB22010@orac.inputplus.co.uk> <202507211152.56LBqGD2019247@freefriends.org> <20250721121530.2894F21F15@orac.inputplus.co.uk> <20250721131629.GC15357@mcvoy.com> <202507211510.56LFAlie033840@freefriends.org> <20250721163952.A845321EFD@orac.inputplus.co.uk> Message-ID: <202507220721.56M7L1tn005178@freefriends.org> Ralph Corderoy wrote: > > As to Plan 9 troff, I don't have a Plan 9 system > > Russ Cox's Plan 9 from User Space? It includes troff and friends. > https://9fans.github.io/plan9port/ Thanks Ralph (and Dan C.). I'd forgotten about that. Arnold From steve at quintile.net Tue Jul 22 20:16:04 2025 From: steve at quintile.net (Steve Simon) Date: Tue, 22 Jul 2025 11:16:04 +0100 Subject: [TUHS] upwards from ed (was: End of an era: the last ATC) Message-ID: <84746CFA-FD18-4C98-B8B1-F77B83FE83EC@quintile.net> sam was my only editor from 92 when i discovered it until last year. under continual peer pressure i moved to zed on a mac which does many clever things i don’t need and even occasionally gets in the way, but (for me) it had one killer feature: i write go these days and use dozens of third party libraries. zed allows me to ask “what methods are available on this variable?” i would love to go back to sam but i fear adding treesitter and the rest needed to support this feature would kill one of us for sure. -Steve From crossd at gmail.com Tue Jul 22 22:22:23 2025 From: crossd at gmail.com (Dan Cross) Date: Tue, 22 Jul 2025 08:22:23 -0400 Subject: [TUHS] upwards from ed (was: End of an era: the last ATC) In-Reply-To: <84746CFA-FD18-4C98-B8B1-F77B83FE83EC@quintile.net> References: <84746CFA-FD18-4C98-B8B1-F77B83FE83EC@quintile.net> Message-ID: On Tue, Jul 22, 2025 at 6:27 AM Steve Simon wrote: > sam was my only editor from 92 when i discovered it until last year. > [snip] > i would love to go back to sam but i fear adding treesitter and the rest needed to support this feature would kill one of us for sure. Sam has a neat feature that many people who are not familiar with it may be unaware of: remote editing. In some ways, this is a bit of an historical accident, given the way that sam was developed. The editor is actually split into two programs: there is sam, the editor itself, and samterm, which is the graphical user interface to the editor. On research Unix, `samterm` was meant to be downloaded into the memory of, and run directly on, the Blit terminal (or one of its successors), while it communicated with the actual editor running on the VAX the terminal was connected to. The sam paper goes into some detail describing the protocol between the two, and how they synchronize state. Originally, the two were connected over a serial line, but that was an implementation detail, and really, any reliable byte-stream connection will do. The fundamental mechanism this has been preserved into the modern era, and with recent versions of sam, one can still run `sam -r remote.machine.name`; `samterm` will run locally, but behind the scenes, it connects to a remote machine (e.g., via SSH) and communicates with the actual editor. This is something that I wish more editors knew how to do; emacs can kinda sorta do this with TRAMP, and VSCode and Zed can both do something similar, but require very heavy-weight server components on the distant end (and in the case of VSCode, the remote editing component is closed-source, and only runs on a few platforms). Sam is much simpler and far more portable and served as an example for decades, but for whatever reason, the idea is not common, and most editors seem stuck in the "local machine" paradigm. - Dan C. From noel.hunt at gmail.com Wed Jul 23 07:58:31 2025 From: noel.hunt at gmail.com (Noel Hunt) Date: Wed, 23 Jul 2025 07:58:31 +1000 Subject: [TUHS] upwards from ed (was: End of an era: the last ATC) In-Reply-To: <84746CFA-FD18-4C98-B8B1-F77B83FE83EC@quintile.net> References: <84746CFA-FD18-4C98-B8B1-F77B83FE83EC@quintile.net> Message-ID: > i write go these days and use dozens of third party libraries. > zed allows me to ask “what methods are available on this variable?” Interestingly, 'samuel' has a feature not unlike the above, called 'advisor'. You can select a string in a file window, and look up its definition. The manual has Advisor Advisor is a C advisor service. It will look-up the selected library routine name or C Language keyword (while, for, if, etc.) and return (in the command window) information about the routine's calling sequence or use. The inclusion of C language keywords may have been influenced by the fact that 'samuel' also had an interface to 'cin', the C interpreter. The 'database' file has a simple format, e.g., Jrect Bitmap Jrect={0, 0, XMAX, YMAX}; Point struct{ short x; short y; }Point; add Point add(p, q) Point p, q; add two points and the distributions I have seen have come with such files for 630 routines, X11 and C library functions. The 'advisor' was a separate program, not built in to 'samuel', and I daresay this functionality could be added to 'acme', via 'libacme'. On Tue, 22 Jul 2025 at 20:16, Steve Simon wrote: > sam was my only editor from 92 when i discovered it until last year. > > under continual peer pressure i moved to zed on a mac which does many > clever things i don’t need and even occasionally gets in the way, but (for > me) it had one killer feature: > > i write go these days and use dozens of third party libraries. zed allows > me to ask “what methods are available on this variable?” > > i would love to go back to sam but i fear adding treesitter and the rest > needed to support this feature would kill one of us for sure. > > -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Jul 24 12:02:33 2025 From: robpike at gmail.com (Rob Pike) Date: Thu, 24 Jul 2025 12:02:33 +1000 Subject: [TUHS] upwards from ed (was: End of an era: the last ATC) In-Reply-To: References: <84746CFA-FD18-4C98-B8B1-F77B83FE83EC@quintile.net> Message-ID: Sam -r was a boon when living in Sydney but working in California. Compared to the people around me using SSH to log in remotely and then using vi or EMACS, the UI latency difference was more than noticeable. Round trip for each keystroke was the better part of a second, except for me. Local echo for the win. -rob On Thu, Jul 24, 2025 at 1:27 AM Dan Cross wrote: > On Tue, Jul 22, 2025 at 6:27 AM Steve Simon wrote: > > sam was my only editor from 92 when i discovered it until last year. > > [snip] > > i would love to go back to sam but i fear adding treesitter and the rest > needed to support this feature would kill one of us for sure. > > Sam has a neat feature that many people who are not familiar with it > may be unaware of: remote editing. > > In some ways, this is a bit of an historical accident, given the way > that sam was developed. The editor is actually split into two > programs: there is sam, the editor itself, and samterm, which is the > graphical user interface to the editor. On research Unix, `samterm` > was meant to be downloaded into the memory of, and run directly on, > the Blit terminal (or one of its successors), while it communicated > with the actual editor running on the VAX the terminal was connected > to. The sam paper goes into some detail describing the protocol > between the two, and how they synchronize state. > > Originally, the two were connected over a serial line, but that was an > implementation detail, and really, any reliable byte-stream connection > will do. The fundamental mechanism this has been preserved into the > modern era, and with recent versions of sam, one can still run `sam -r > remote.machine.name`; `samterm` will run locally, but behind the > scenes, it connects to a remote machine (e.g., via SSH) and > communicates with the actual editor. > > This is something that I wish more editors knew how to do; emacs can > kinda sorta do this with TRAMP, and VSCode and Zed can both do > something similar, but require very heavy-weight server components on > the distant end (and in the case of VSCode, the remote editing > component is closed-source, and only runs on a few platforms). Sam is > much simpler and far more portable and served as an example for > decades, but for whatever reason, the idea is not common, and most > editors seem stuck in the "local machine" paradigm. > > - Dan C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sat Jul 26 05:46:12 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 25 Jul 2025 21:46:12 +0200 Subject: [TUHS] upwards from ed (was: End of an era: the last ATC) In-Reply-To: References: <84746CFA-FD18-4C98-B8B1-F77B83FE83EC@quintile.net> Message-ID: <20250725194612.Sw3l3VYc@steffen%sdaoden.eu> Rob Pike wrote in : |Sam -r was a boon when living in Sydney but working in California. Compared |to the people around me using SSH to log in remotely and then using vi or |EMACS, the UI latency difference was more than noticeable. Round trip for |each keystroke was the better part of a second, except for me. Local echo |for the win. A bit off-topic for minimized editor bandwidth, but fine with "End of an Era". The "Timing Analysis of Keystrokes and Timing Attacks on SSH" [1] attack on OpenSSH (that lead to ObscureKeystrokeTiming ssh_config(5) option, aka "obscure inter-keystroke timings from passive observers of network traffic") was one of my deepest "boah!"s/take a deep breath of the last years. Compared to when i discovered Linux, but then FreeBSD with all the documentation and papers, and all that, and reading code, of course, over 26 years ago, it lost its, well, innocence. By then, at my programming level at least, you disabled Nagle's algorithm, and at worse used SSL, to mischieviously rub your hands and be fine with it. [1] https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf |-rob | | |On Thu, Jul 24, 2025 at 1:27 AM Dan Cross wrote: | |> On Tue, Jul 22, 2025 at 6:27 AM Steve Simon wrote: |>> sam was my only editor from 92 when i discovered it until last year. |>> [snip] |>> i would love to go back to sam but i fear adding treesitter and the rest |> needed to support this feature would kill one of us for sure. |> |> Sam has a neat feature that many people who are not familiar with it |> may be unaware of: remote editing. |> |> In some ways, this is a bit of an historical accident, given the way |> that sam was developed. The editor is actually split into two |> programs: there is sam, the editor itself, and samterm, which is the |> graphical user interface to the editor. On research Unix, `samterm` |> was meant to be downloaded into the memory of, and run directly on, |> the Blit terminal (or one of its successors), while it communicated |> with the actual editor running on the VAX the terminal was connected |> to. The sam paper goes into some detail describing the protocol |> between the two, and how they synchronize state. |> |> Originally, the two were connected over a serial line, but that was an |> implementation detail, and really, any reliable byte-stream connection |> will do. The fundamental mechanism this has been preserved into the |> modern era, and with recent versions of sam, one can still run `sam -r |> remote.machine.name`; `samterm` will run locally, but behind the |> scenes, it connects to a remote machine (e.g., via SSH) and |> communicates with the actual editor. |> |> This is something that I wish more editors knew how to do; emacs can |> kinda sorta do this with TRAMP, and VSCode and Zed can both do |> something similar, but require very heavy-weight server components on |> the distant end (and in the case of VSCode, the remote editing |> component is closed-source, and only runs on a few platforms). Sam is |> much simpler and far more portable and served as an example for |> decades, but for whatever reason, the idea is not common, and most |> editors seem stuck in the "local machine" paradigm. |> |> - Dan C. |> |Sam -r was a boon when living in Sydney but working in California. \ |Compared to the people around me using SSH to log in remotely and then \ |using vi or EMACS, the UI latency difference |was more than noticeable. Round trip for each keystroke was the better \ |part of a second, except for me. Local echo for the win. | |-rob | |On Thu, Jul 24, 2025 at 1:27 AM Dan Cross <[1]crossd at gmail.com[/1]> wrote: | | [1] mailto:crossd at gmail.com | ||On Tue, Jul 22, 2025 at 6:27 AM Steve Simon <[2]steve at quintile.net[/2]> \ ||wrote: ||> sam was my only editor from 92 when i discovered it until last year. ||> [snip] ||> i would love to go back to sam but i fear adding treesitter and \ ||> the rest needed to support this feature would kill one of us for sure. | ||Sam has a neat feature that many people who are not familiar with it ||may be unaware of: remote editing. | ||In some ways, this is a bit of an historical accident, given the way ||that sam was developed. The editor is actually split into two ||programs: there is sam, the editor itself, and samterm, which is the ||graphical user interface to the editor. On research Unix, `samterm` ||was meant to be downloaded into the memory of, and run directly on, ||the Blit terminal (or one of its successors), while it communicated ||with the actual editor running on the VAX the terminal was connected ||to. The sam paper goes into some detail describing the protocol ||between the two, and how they synchronize state. | ||Originally, the two were connected over a serial line, but that was an ||implementation detail, and really, any reliable byte-stream connection ||will do. The fundamental mechanism this has been preserved into the ||modern era, and with recent versions of sam, one can still run `sam -r ||[3]remote.machine.name[/3]`; `samterm` will run locally, but behind the ||scenes, it connects to a remote machine (e.g., via SSH) and ||communicates with the actual editor. | ||This is something that I wish more editors knew how to do; emacs can ||kinda sorta do this with TRAMP, and VSCode and Zed can both do ||something similar, but require very heavy-weight server components on ||the distant end (and in the case of VSCode, the remote editing ||component is closed-source, and only runs on a few platforms). Sam is ||much simpler and far more portable and served as an example for ||decades, but for whatever reason, the idea is not common, and most ||editors seem stuck in the "local machine" paradigm. | | [2] mailto:steve at quintile.net | [3] http://remote.machine.name | ||        - Dan C. --End of --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From cowan at ccil.org Sat Jul 26 13:34:41 2025 From: cowan at ccil.org (John Cowan) Date: Fri, 25 Jul 2025 23:34:41 -0400 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: <7a6615a5-ddda-469e-9323-a1159a25475c@case.edu> References: <20250718010929.GG30582@mcvoy.com> <878B2F53-F2DE-42FC-99F9-A317EA11FBED@iitbombay.org> <5wCXba6s3vZTN7uVsyRthHTn0yeKK0Cil7AUnz8USPWK2g_-qmyqwcgVM0NBhrltwTXcTlCagaCw91kqBruNyKOgFeMrTbXGNcBSPNj7OgY=@protonmail.com> <20250718100902.GI30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <7a6615a5-ddda-469e-9323-a1159a25475c@case.edu> Message-ID: Muscle memory is 100% of why I continue to edit in ex. On Mon, Jul 21, 2025, 10:12 AM Chet Ramey via TUHS wrote: > On 7/20/25 3:59 AM, G. Branden Robinson wrote: > > > On the milder topic of editor preferences, I'm a vi(m) user but employ > > Emacs bindings in readline applications and maintained my own fork of mg > > (microemacs) for a while, to see how the other half lived. I discovered > > that a much bigger chunk of Emacs advocacy is predicated on its > > "finger-feel"[1] > > I think, as I said in another message, that familiarity has a lot to do > with the comfort that people feel. Muscle memory is important. > > I would also note that emacs-style key bindings are pervasive -- even on > macOS, where the system's text objects (e.g., what you use in TextEdit) > all have emacs-style key bindings by default, down to things like the > browsers' address bar and search field. Even the Spotlight search bar > uses emacs key bindings. This was all inherited from NeXTOS. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Jul 26 20:20:20 2025 From: tuhs at tuhs.org (=?utf-8?q?Cameron_M=C3=AD=C4=8Be=C3=A1l_Tyre_via_TUHS?=) Date: Sat, 26 Jul 2025 10:20:20 +0000 Subject: [TUHS] End of an era: the last ATC (USENIX Annual Technical Conference) In-Reply-To: References: <20250718010929.GG30582@mcvoy.com> <9b4bd127-5c12-40bc-81b2-f535ece830ac@gmail.com> <20250718125210.GL30582@mcvoy.com> <4c86e5b1-d694-48ef-b4ed-b0a182ba98d4@gmail.com> <20250718194349.GG8625@mcvoy.com> <6c1b72c2-97cc-480d-bf56-fcb1e1e5f726@gmail.com> <20250720075908.w6tetlcb3zhowbby@illithid> <7a6615a5-ddda-469e-9323-a1159a25475c@case.edu> Message-ID: <5chl8xDJ1XdqwuWlaeCg_XpHAPvTfZZv3Zd3QjyytGl2Qi-h2XqeAH6DDjmkQpl8DtPljRGntRybB6tJWqGljsJBfiURqrTMF4w8LlhihwU=@protonmail.ch> If I can just get . into my muscle memory bank, then I'd stop having... w q ...at the end of most of my documents! Have a great weekend, everyone! -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake1024 at gmail.com Sun Jul 27 02:06:54 2025 From: blake1024 at gmail.com (Blake McBride) Date: Sat, 26 Jul 2025 11:06:54 -0500 Subject: [TUHS] upwards from ed (was: End of an era: the last ATC) In-Reply-To: <20250725194612.Sw3l3VYc@steffen%sdaoden.eu> References: <84746CFA-FD18-4C98-B8B1-F77B83FE83EC@quintile.net> <20250725194612.Sw3l3VYc@steffen%sdaoden.eu> Message-ID: Having a long interest in editors for more than 40 years, I've made serious use of vi, emacs, and jove. I've also played with about a dozen others, including sam. I now use IntelliJ. It is a very poor editor but has a number of modern features that I can't work without. After all this experience, there is one editor that stands out as the most interesting to me, and that is ACME! I like the i3/sway desktop because it maximizes screen utilization and doesn't hide anything. It is, in my opinion, the most productive use of screen real estate. ACME has the same philosophy. Unfortunately, ACME has a very small following, poor availability, poor support, and poor portability. There are also many great features that could be added. I'd love to see it take off. I'd do it myself if I had the time. Just a random opinion. Blake McBride blakemcbride.us On Fri, Jul 25, 2025 at 3:57 PM Steffen Nurpmeso wrote: > Rob Pike wrote in > : > |Sam -r was a boon when living in Sydney but working in California. > Compared > |to the people around me using SSH to log in remotely and then using vi or > |EMACS, the UI latency difference was more than noticeable. Round trip for > |each keystroke was the better part of a second, except for me. Local echo > |for the win. > > A bit off-topic for minimized editor bandwidth, but fine with "End > of an Era". > > The "Timing Analysis of Keystrokes and Timing Attacks on SSH" > [1] attack on OpenSSH (that lead to ObscureKeystrokeTiming > ssh_config(5) option, aka "obscure inter-keystroke timings from > passive observers of network traffic") was one of my deepest > "boah!"s/take a deep breath of the last years. > > Compared to when i discovered Linux, but then FreeBSD with all the > documentation and papers, and all that, and reading code, of > course, over 26 years ago, it lost its, well, innocence. > By then, at my programming level at least, you disabled Nagle's > algorithm, and at worse used SSL, to mischieviously rub your hands > and be fine with it. > > [1] https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf > > |-rob > | > | > |On Thu, Jul 24, 2025 at 1:27 AM Dan Cross wrote: > | > |> On Tue, Jul 22, 2025 at 6:27 AM Steve Simon > wrote: > |>> sam was my only editor from 92 when i discovered it until last year. > |>> [snip] > |>> i would love to go back to sam but i fear adding treesitter and the > rest > |> needed to support this feature would kill one of us for sure. > |> > |> Sam has a neat feature that many people who are not familiar with it > |> may be unaware of: remote editing. > |> > |> In some ways, this is a bit of an historical accident, given the way > |> that sam was developed. The editor is actually split into two > |> programs: there is sam, the editor itself, and samterm, which is the > |> graphical user interface to the editor. On research Unix, `samterm` > |> was meant to be downloaded into the memory of, and run directly on, > |> the Blit terminal (or one of its successors), while it communicated > |> with the actual editor running on the VAX the terminal was connected > |> to. The sam paper goes into some detail describing the protocol > |> between the two, and how they synchronize state. > |> > |> Originally, the two were connected over a serial line, but that was an > |> implementation detail, and really, any reliable byte-stream connection > |> will do. The fundamental mechanism this has been preserved into the > |> modern era, and with recent versions of sam, one can still run `sam -r > |> remote.machine.name`; `samterm` will run locally, but behind the > |> scenes, it connects to a remote machine (e.g., via SSH) and > |> communicates with the actual editor. > |> > |> This is something that I wish more editors knew how to do; emacs can > |> kinda sorta do this with TRAMP, and VSCode and Zed can both do > |> something similar, but require very heavy-weight server components on > |> the distant end (and in the case of VSCode, the remote editing > |> component is closed-source, and only runs on a few platforms). Sam is > |> much simpler and far more portable and served as an example for > |> decades, but for whatever reason, the idea is not common, and most > |> editors seem stuck in the "local machine" paradigm. > |> > |> - Dan C. > |> > > > |Sam -r was a boon when living in Sydney but working in California. \ > |Compared to the people around me using SSH to log in remotely and then \ > |using vi or EMACS, the UI latency difference > |was more than noticeable. Round trip for each keystroke was the better \ > |part of a second, except for me. Local echo for the win. > | > |-rob > | > |On Thu, Jul 24, 2025 at 1:27 AM Dan Cross <[1]crossd at gmail.com[/1]> > wrote: > | > | [1] mailto:crossd at gmail.com > | > ||On Tue, Jul 22, 2025 at 6:27 AM Steve Simon <[2]steve at quintile.net[/2]> > \ > ||wrote: > ||> sam was my only editor from 92 when i discovered it until last year. > ||> [snip] > ||> i would love to go back to sam but i fear adding treesitter and \ > ||> the rest needed to support this feature would kill one of us for sure. > | > ||Sam has a neat feature that many people who are not familiar with it > ||may be unaware of: remote editing. > | > ||In some ways, this is a bit of an historical accident, given the way > ||that sam was developed. The editor is actually split into two > ||programs: there is sam, the editor itself, and samterm, which is the > ||graphical user interface to the editor. On research Unix, `samterm` > ||was meant to be downloaded into the memory of, and run directly on, > ||the Blit terminal (or one of its successors), while it communicated > ||with the actual editor running on the VAX the terminal was connected > ||to. The sam paper goes into some detail describing the protocol > ||between the two, and how they synchronize state. > | > ||Originally, the two were connected over a serial line, but that was an > ||implementation detail, and really, any reliable byte-stream connection > ||will do. The fundamental mechanism this has been preserved into the > ||modern era, and with recent versions of sam, one can still run `sam -r > ||[3]remote.machine.name[/3]`; `samterm` will run locally, but behind the > ||scenes, it connects to a remote machine (e.g., via SSH) and > ||communicates with the actual editor. > | > ||This is something that I wish more editors knew how to do; emacs can > ||kinda sorta do this with TRAMP, and VSCode and Zed can both do > ||something similar, but require very heavy-weight server components on > ||the distant end (and in the case of VSCode, the remote editing > ||component is closed-source, and only runs on a few platforms). Sam is > ||much simpler and far more portable and served as an example for > ||decades, but for whatever reason, the idea is not common, and most > ||editors seem stuck in the "local machine" paradigm. > | > | [2] mailto:steve at quintile.net > | [3] http://remote.machine.name > | > || - Dan C. > --End of .com> > > --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) > | > |During summer's humble, here's David Leonard's grumble > | > |The black bear, The black bear, > |blithely holds his own holds himself at leisure > |beating it, up and down tossing over his ups and downs with pleasure > | > |Farewell, dear collar bear > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Wed Jul 30 00:11:58 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Wed, 30 Jul 2025 00:11:58 +1000 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: References: Message-ID: On Mon, Jul 21, 2025 at 01:44:26AM +0000, Thalia Archibald via TUHS wrote: > > The Model 37 product catalog[0] has tables of many configurations and their catalog numbers. Is there a list of the teleprinters purchased by Bell Labs? With that, I could possibly narrow it down like how Warner Losh identified the PDP-7 model used for Unix V0. Not quite what you are asking, Dennis Ritchie provided a list of terminals he used at home. >From alt.folklore.computers Jan 13, 1993 https://groups.google.com/g/alt.folklore.computers/c/qwI7XHPBu-s/m/NgGcn_SibNQJ "for the sake of history, here is the sequence of terminals I have used at home, all paid for by my employer. Dates are approximate. 1968: IBM 1050 (14.5 cps) 1970: Teletype 37 (15 cps) 1975: GE Terminet 300 (30 cps) 1978: HP 2621 (120 cps) 1983: Jerq (Blit) (120, later 960 cps) 1990: Gnot (Plan 9) (960 cps) 1992: Gnot (Plan 9) (8192 cps ISDN)" When John Lions was at Bell Labs on sabbatical: "Up till now I have been using a tty 43 (this listing) ... there is a noticeable preponderance of hard copy and lack of CRT terminals." John Lions, 15 August 1978 AUUGN Vol 1, No 1, p 21 from Dennis Ritchie in alt.folklore.computers Feb 12, 2011 https://groups.google.com/g/alt.folklore.computers/c/TbnWa4H0qS0/m/RUFInaTmgIwJ "Unix in 1969 was mostly written on a TTY33. Our PDP-7 also had a full-ASCII keyboard that was part of the locally-built Graphics-II processor attached to the PDP-7, used for Space Travel, for example, and also for development once Unix was self-supporting." Dennis mentions an ASR33 for the initial PDP-11 in: https://www.tuhs.org/pipermail/tuhs/2002-September/002162.html https://www.tuhs.org/pipermail/tuhs/2002-September/002181.html More terminal discussions from alt.folklore.computers: Oct 31, 2001 https://groups.google.com/g/alt.folklore.computers/c/2hIR4udbSD0/m/peXf7MB75IMJ May 10, 2005 https://groups.google.com/g/alt.folklore.computers/c/yUlJLKto-LQ/m/0la-n5KCxdMJ on the IBM 2741 as used with CTSS and Multics From sjenkin at canb.auug.org.au Wed Jul 30 02:16:13 2025 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Wed, 30 Jul 2025 02:16:13 +1000 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: References: Message-ID: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> Explaining John’s comment. I requested some reports from UNSW Archives in 2021. This one, by Keith Titmus in 2000, was a short history of Prof Murray Allen, who'd hired John Lions and Ken Robinson in 1972. 08_224_01 MW Allen_Keith-Titmus_2000 There were some Decwriters at UNSW, but mainly ’Serge’ Terminals in 1978. Designed and built by the local staff (Serge P). They were in use for 12 years. The paint wore off the cabinets, but they’d bought expensive ‘hall effect’ keyboards for them and they kept on and on… Elsewhere: In 1976, "UNSW, by end of year, boasted 200 registered users" on their Unix system. > On 30 Jul 2025, at 00:11, Jonathan Gray wrote: > > When John Lions was at Bell Labs on sabbatical: > > "Up till now I have been using a tty 43 (this listing) > ... > there is a noticeable preponderance of hard copy and lack of CRT terminals." > John Lions, 15 August 1978 > AUUGN Vol 1, No 1, p 21 =============== In 1972, Murray was involved with the design of VISICOM, an ME thesis by Serge Poplavsky. In 1976 Murray directed the building of 50 terminals for the newly created computing facilities. The first terminal laboratories were the forerunner of the computer laboratories that are now existent. The initial batch of terminals were a hard wired construction, while the next batch of 25 used an early version of microprocessor - the Motorola MC6802, and the third terminal version used the Motorola MC6809. The terminals were in use until the first workstations, the Apollo using the Motorola MC68020 microprocessor, began replacing them in 1988. =============== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Jul 30 04:06:14 2025 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 29 Jul 2025 18:06:14 +0000 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> Message-ID: At Hopkins we had a KSR37 which had the big ol’ NEWLINE key and did stuff with the ESC 8 and 9 stuff that nroff spewed directly. It even had a greek box that was well integrated into eqn. It largely got supplanted with the faster and nicer printing diablo and even that fell to the versatec troff emulators and eventually to things like the Imagen laser printers. I procured my own Model 37 from the Rocky Flats Nuclear Site surplus department. It had a big sidecar paper tape punch reader. -Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Wed Jul 30 04:34:52 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 29 Jul 2025 14:34:52 -0400 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> Message-ID: An extant memento of my home TTY 37 is a stack of fanfold paper that accommodated artwork by children and grandchildren. About 1/4".remains for potential great-grandchildren. Doug On Tue, Jul 29, 2025 at 2:06 PM Ron Natalie wrote: > > At Hopkins we had a KSR37 which had the big ol’ NEWLINE key and did stuff with the ESC 8 and 9 stuff that nroff spewed directly. It even had a greek box that was well integrated into eqn. > > It largely got supplanted with the faster and nicer printing diablo and even that fell to the versatec troff emulators and eventually to things like the Imagen laser printers. > > I procured my own Model 37 from the Rocky Flats Nuclear Site surplus department. It had a big sidecar paper tape punch reader. > > -Ron From jsg at jsg.id.au Wed Jul 30 10:27:23 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Wed, 30 Jul 2025 10:27:23 +1000 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> Message-ID: UNSW terminals mentioned briefly by John in: Experiences with the UNIX Time-sharing System Software-Practice & Experience, Vol. 9, No. 9, pp. 701-709, Sep 1979 "The remote-batch load absorbs about 5 per cent of the 11/70 and its residual capacity is used to serve nearly 50 interactive terminals. (Most of these are CRTs running at 2400 baud, that have been built in-house to our own design; each incorporates a high-quality CRT display and keyboard, and supports full ASCII 96 character set, and a graphics mode)." A photo with one? UNSW UNIKEN, 10 Sep 1982 https://nla.gov.au/nla.obj-257305977/view?sectionId=nla.obj-261273025 "Computer Science students using computer terminals under the supervision of Associate Professor John Lions. There are some 70 terminals in the School's student labs, most of which have been designed and built there." A cropped colour version of this photo is used on the wikipedia page for John Lions, but the unsw.edu.au source of it was removed. A non-cropped colour version also appears on the cover of the 1979 UNSW Annual Report: https://digitalcollections.library.unsw.edu.au/nodes/view/171706 References to a serge terminal can be found in: TUHS Distributions/UNSW/92/ (UNIX Level 7 Source 25/3/81) src/cmd/tbs/tbs.c cmd/s.getty.c On Wed, Jul 30, 2025 at 02:16:13AM +1000, sjenkin at canb.auug.org.au wrote: > Explaining John’s comment. > > I requested some reports from UNSW Archives in 2021. > This one, by Keith Titmus in 2000, was a short history of Prof Murray Allen, > who'd hired John Lions and Ken Robinson in 1972. > > 08_224_01 MW Allen_Keith-Titmus_2000 > > There were some Decwriters at UNSW, but mainly ’Serge’ Terminals in 1978. > Designed and built by the local staff (Serge P). > > They were in use for 12 years. > The paint wore off the cabinets, > but they’d bought expensive ‘hall effect’ keyboards for them and they kept on and on… > > Elsewhere: > In 1976, "UNSW, by end of year, boasted 200 registered users" on their Unix system. > > > On 30 Jul 2025, at 00:11, Jonathan Gray wrote: > > > > When John Lions was at Bell Labs on sabbatical: > > > > "Up till now I have been using a tty 43 (this listing) > > ... > > there is a noticeable preponderance of hard copy and lack of CRT terminals." > > John Lions, 15 August 1978 > > AUUGN Vol 1, No 1, p 21 > > > =============== > > In 1972, Murray was involved with the design of VISICOM, an ME thesis by Serge Poplavsky. > > In 1976 Murray directed the building of 50 terminals for the newly created computing facilities. > The first terminal laboratories were the forerunner of the computer laboratories that are now existent. > The initial batch of terminals were a hard wired construction, > while the next batch of 25 used an early version of microprocessor - the Motorola MC6802, > and the third terminal version used the Motorola MC6809. > > The terminals were in use until the first workstations, > the Apollo using the Motorola MC68020 microprocessor, > began replacing them in 1988. > > =============== > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin > From dave at horsfall.org Wed Jul 30 10:56:10 2025 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 30 Jul 2025 10:56:10 +1000 (EST) Subject: [TUHS] Teletypes used for early Unix In-Reply-To: References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> Message-ID: On Wed, 30 Jul 2025, Jonathan Gray wrote: > "The remote-batch load absorbs about 5 per cent of the 11/70 and its > residual capacity is used to serve nearly 50 interactive terminals. > (Most of these are CRTs running at 2400 baud, that have been built > in-house to our own design; each incorporates a high-quality CRT display > and keyboard, and supports full ASCII 96 character set, and a graphics > mode)." The Serge terminal was quite nice (heaps better than the Aussie "Transdata" ones that we also used at the time); they had a switch on the front which took it offline (by dropping CD?), and it made for a handy scroll-lock, and so likely used hardware flow control? -- Dave From lm at mcvoy.com Wed Jul 30 11:15:37 2025 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 29 Jul 2025 18:15:37 -0700 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> Message-ID: <20250730011537.GG1150@mcvoy.com> On Wed, Jul 30, 2025 at 10:27:23AM +1000, Jonathan Gray wrote: > "The remote-batch load absorbs about 5 per cent of the 11/70 and its > residual capacity is used to serve nearly 50 interactive terminals. I still remember, fondly (sort of) being in a terminal room with 50+ other students all hooked up to a 4MB VAX 780. The fondness was the sort of bonding we all had from pulling all nighters to get stuff to work (this was at UW-Madison, back then it was a hard core hacking school, lots of Sun's kernel group came from Madison, including Rusty (NFS) and Mojo (he wrote the 4.x VM system) and a bunch of others). The not so fond part was hit ^T over and over again (it gave you a one line PS like output showing load) while your compiled seemed swapped out forever. The not fondness made me take out one of the very few loans I have had, in 1985ish I borrowed $2000 to buy a Okidata CPM machine, it was a lot slower than the VAX, but all the cycles were mine. I wrote a lot of code on that machine. Including assembler versions of cp, rm, ls, etc, each of which fit in 512 bytes because that was one sector on a floppy disk, I didn't want to wait for more than one sector to load. Fun times. Now my phone is like 10,000x faster and has easily that much more memory. --lm From jsg at jsg.id.au Wed Jul 30 13:29:11 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Wed, 30 Jul 2025 13:29:11 +1000 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> Message-ID: On Wed, Jul 30, 2025 at 02:16:13AM +1000, sjenkin at canb.auug.org.au wrote: > Explaining John’s comment. > > I requested some reports from UNSW Archives in 2021. > This one, by Keith Titmus in 2000, was a short history of Prof Murray Allen, > who'd hired John Lions and Ken Robinson in 1972. > > 08_224_01 MW Allen_Keith-Titmus_2000 > > There were some Decwriters at UNSW, but mainly ’Serge’ Terminals in 1978. > Designed and built by the local staff (Serge P). Before that, there was the INTERGRAPHIC, used with an IBM 360/50. Malcolm Macaulay A low cost computer graphic terminal https://dl.acm.org/doi/10.1145/1476589.1476688 "INTERGRAPHIC system built at the UNSW between 1964 and 1966 by G. A. Rose under M. W. Allen. The design team included P. D. Jones, T. Pearcey, R. B. Stanton and M. Macaulay" https://www.austehc.unimelb.edu.au/tia/595.html Pearcey of CSIR Mk1/CSIRAC fame. An oral history of Murray Allen goes into Unix and Intergraphic. Murray Allen interviewed by David Demant in the History of ICT in Australia oral history project https://trove.nla.gov.au/work/178430368 From arnold at skeeve.com Wed Jul 30 16:02:10 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 30 Jul 2025 00:02:10 -0600 Subject: [TUHS] greenbar fanfold paper - anyone else miss it? In-Reply-To: References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> Message-ID: <202507300602.56U62AOq008260@freefriends.org> Douglas McIlroy wrote: > An extant memento of my home TTY 37 is a stack of fanfold paper that > accommodated artwork by children and grandchildren. About 1/4".remains > for potential great-grandchildren. > > Doug I really miss 11" x 17" greenbar fanfold paper. It was wonderful for printing out program listings and reviewing code. One could make notes on the side of the code, flip back and forth between different files to see how different data structures were used, and so on. It was great. That's how I first learned the gawk code (MUCH smaller at the time). I printed out the whole thing and read through it, making notes. Sigh. The good old days. Arnold P.S. Some years ago I went through the binders on my bookshelves to get rid of things. From that I have a stack about 4 feet high of letter paper printed one-sided on a laser printer, waiting for use by future grandchildren. Sadly, not one of my kids is married. (These days my laser printer does duplex; anything I don't need goes into recycling.) Whatever. We now return you to our regularly scheduled reminiscing. From sburjak at systech.com.au Wed Jul 30 16:12:51 2025 From: sburjak at systech.com.au (Serge Burjak) Date: Wed, 30 Jul 2025 16:12:51 +1000 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> Message-ID: Hi Team, First time contributor, long time reader. I am a different Serge to the one in this thread. Been active in computing in AUS since the early 70s. Used Teletype KSR/ASR 33 from about 1973 to 1981. Many other CRTS, terminals as well. These are my recollections. They may be flawed. KSR 33 did NOT have a paper tape reader/punch. The Paper Tape punch and reader were on the ASR33 model exclusively. These devices were mechanical, ran at 110 Baud serial, typically in a 20 ma current loop for signalling. Used ASCII. I do not know of any way to change the interface speed, only ever saw 110. I have seen in magazines of the time, built in modems, but none seem to have made it to Australia. The paper was typically a friction fed via a platen. The interlock to stop multiple keys was done mechanically. Fairly noisy. Wiki is not bad, https://en.wikipedia.org/wiki/Teletype_Model_33 ASR/KSR 33 was a standard for all terminals in that era that used serial ASCII. The paper tape reader was used to bootstrap the OS to most minicomputers of the era. There was a limit as to how much paper tape could be fed by the internal feed mechanism and would often fail with a CRC check for larger punched tape rolls. The reader and punch could be controlled by a key sequence sent from the computer. Tape also ran at 110 Baud. Used a cross section of mini computers, most DEC devices, right through to PDP10 timesharing. DECWriters were very versatile and reliable across a broad range of devices, more CRTS, and computers than I can remember. Not sure if it helps. On Wed, 30 Jul 2025 at 13:29, Jonathan Gray wrote: > On Wed, Jul 30, 2025 at 02:16:13AM +1000, sjenkin at canb.auug.org.au wrote: > > Explaining John’s comment. > > > > I requested some reports from UNSW Archives in 2021. > > This one, by Keith Titmus in 2000, was a short history of Prof Murray > Allen, > > who'd hired John Lions and Ken Robinson in 1972. > > > > 08_224_01 MW Allen_Keith-Titmus_2000 > > > > There were some Decwriters at UNSW, but mainly ’Serge’ Terminals in 1978. > > Designed and built by the local staff (Serge P). > > Before that, there was the INTERGRAPHIC, used with an IBM 360/50. > Malcolm Macaulay > A low cost computer graphic terminal > https://dl.acm.org/doi/10.1145/1476589.1476688 > > "INTERGRAPHIC system built at the UNSW between 1964 and 1966 by > G. A. Rose under M. W. Allen. The design team included P. D. Jones, > T. Pearcey, R. B. Stanton and M. Macaulay" > https://www.austehc.unimelb.edu.au/tia/595.html > > Pearcey of CSIR Mk1/CSIRAC fame. > > An oral history of Murray Allen goes into Unix and Intergraphic. > > Murray Allen interviewed by David Demant in the History of ICT in > Australia oral history project > https://trove.nla.gov.au/work/178430368 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Wed Jul 30 16:20:48 2025 From: sjenkin at canb.auug.org.au (Steve Jenkin) Date: Wed, 30 Jul 2025 16:20:48 +1000 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> Message-ID: <90B95F74-21FC-4E0D-A66C-967130116B58@canb.auug.org.au> Great rabbit hole, searching the UNSW archives. Thanks for finding the 1979 Report. The photo below would’ve been taken in the IBM 360 machine room after its removal. On Elec Eng, 4th floor? The raised flooring was for the IBM. =============== PDP 11/70 Computer in the Department of Computer Science The new PDP 11/70 computer in the Department of Computer Science, including: Peter Ivanov (seated), Ian Johnstone. =============== > On 30 Jul 2025, at 10:27, Jonathan Gray wrote: > > A cropped colour version of this photo is used on the wikipedia page > for John Lions, but the unsw.edu.au source of it was removed. > A non-cropped colour version also appears on the cover of the > 1979 UNSW Annual Report: > https://digitalcollections.library.unsw.edu.au/nodes/view/171706 -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Jul 30 17:18:07 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 30 Jul 2025 07:18:07 +0000 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: <20250730011537.GG1150@mcvoy.com> References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> <20250730011537.GG1150@mcvoy.com> Message-ID: On Tuesday, July 29th, 2025 at 6:15 PM, Larry McVoy wrote: > On Wed, Jul 30, 2025 at 10:27:23AM +1000, Jonathan Gray wrote: > > > "The remote-batch load absorbs about 5 per cent of the 11/70 and its > > residual capacity is used to serve nearly 50 interactive terminals. > > > I still remember, fondly (sort of) being in a terminal room with 50+ > other students all hooked up to a 4MB VAX 780. The fondness was the > sort of bonding we all had from pulling all nighters to get stuff to > work (this was at UW-Madison, back then it was a hard core hacking > school, lots of Sun's kernel group came from Madison, including > Rusty (NFS) and Mojo (he wrote the 4.x VM system) and a bunch of > others). > > The not so fond part was hit ^T over and over again (it gave you > a one line PS like output showing load) while your compiled seemed > swapped out forever. > > The not fondness made me take out one of the very few loans I have had, > in 1985ish I borrowed $2000 to buy a Okidata CPM machine, it was a lot > slower than the VAX, but all the cycles were mine. I wrote a lot of > code on that machine. Including assembler versions of cp, rm, ls, > etc, each of which fit in 512 bytes because that was one sector on > a floppy disk, I didn't want to wait for more than one sector to > load. Fun times. Now my phone is like 10,000x faster and has > easily that much more memory. > > --lm Larry if you don't mind my curiosity, were these UNIX-y utilities sitting on top of and using CP/M services or chomping at the hardware a little more closely? Or something else? - Matt G. From tuhs at tuhs.org Wed Jul 30 17:27:59 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 30 Jul 2025 07:27:59 +0000 Subject: [TUHS] greenbar fanfold paper - anyone else miss it? In-Reply-To: <202507300602.56U62AOq008260@freefriends.org> References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> <202507300602.56U62AOq008260@freefriends.org> Message-ID: On Tuesday, July 29th, 2025 at 11:02 PM, arnold at skeeve.com wrote: > Douglas McIlroy douglas.mcilroy at dartmouth.edu wrote: > > > An extant memento of my home TTY 37 is a stack of fanfold paper that > > accommodated artwork by children and grandchildren. About 1/4".remains > > for potential great-grandchildren. > > > > Doug > > > I really miss 11" x 17" greenbar fanfold paper. It was wonderful > for printing out program listings and reviewing code. One could > make notes on the side of the code, flip back and forth between > different files to see how different data structures were used, > and so on. It was great. > > That's how I first learned the gawk code (MUCH smaller at the > time). I printed out the whole thing and read through it, making > notes. > > Sigh. The good old days. > > Arnold > > P.S. Some years ago I went through the binders on my bookshelves to > get rid of things. From that I have a stack about 4 feet high of letter > paper printed one-sided on a laser printer, waiting for use by future > grandchildren. Sadly, not one of my kids is married. (These days my > laser printer does duplex; anything I don't need goes into recycling.) > > Whatever. We now return you to our regularly scheduled reminiscing. Getting COFFy but TUHS bcc, I intend for an upcoming software analysis project to print paper copies and comb over things very finely with a pen. The project is a thorough Lions-esque analysis of Super Mario Bros. 3 for the Famicom/NES. I hope once I'm "done" with my disassembly of it to first print a full copy to sit at coffee shops with and annotate and then eventually produce something comparable to the Lions' publication but the SMB3 code and an accompanying commentary (typeset with troff of course). How grand it would be to have the printouts on true terminal fan-fold. Recently I did spot a Ti hardcopy terminal sitting in a junk pile at the university, I am forever kicking myself for not grabbing it...it did use some sort of continuous paper, but looked to have a reel rather than fan-fold uptake, I didn't make note of the model, only that it had a typical DB-25 (presumably RS-232) serial jack. Granted if I'm simply printing for analysis waiting for a terminal to print it is overkill... - Matt G. From arnold at skeeve.com Wed Jul 30 19:15:00 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 30 Jul 2025 03:15:00 -0600 Subject: [TUHS] off topic: StarTech.com parallel port printer server to give away Message-ID: <202507300915.56U9F0uZ027916@freefriends.org> Hi All. Cleaning up the basement, I found a parallel port printer ethernet server. It lets you put a parallel port printer onto your local network. It speaks the BSD lpr protocol. I used to use it on an HP LaserJet 6 printer. If anyone wants it for an old printer you might have laying around, please let me know, *privately*. It's yours for the cost of postage from Israel. Note, I no longer remember how I got it working with Linux, but I did... This was a llllooonnnngggg time agao. :-) Thanks, Arnold From tytso at mit.edu Wed Jul 30 22:04:23 2025 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 30 Jul 2025 08:04:23 -0400 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> Message-ID: <20250730120423.GC375453@mit.edu> On Wed, Jul 30, 2025 at 04:12:51PM +1000, Serge Burjak wrote: > KSR 33 did NOT have a paper tape reader/punch. The Paper Tape punch and > reader were on the ASR33 model exclusively. KSR == Keyboard Send and Receive ASR == Automatic Send and Receive The paper tape is much like the paper roll used for player pianos, where the paper roll "automatically" plays the piano without a human at the keyboard. The concept predates the computer era by quite some time. > The paper tape reader was used to bootstrap the OS to most minicomputers of > the era. There was a limit as to how much paper tape could be fed by the > internal feed mechanism and would often fail with a CRC check for larger > punched tape rolls. The reader and punch could be controlled by a key > sequence sent from the computer. Tape also ran at 110 Baud. The PDP-8 RIM bootstrap loader: 7756 6014 6011 5357 6016 7106 7006 7520 5357 7006 6011 5367 6016 7420 3776 3376 5357 0000 0000 7756 I got *really* good at toggling in the binary RIM loader into a PDP-8/i. (I still have it mostly memorized after all of these decades.) The RIM loader was less efficient (it used two characters for each 12-bit word), and had no checksums. This could be used to load the more sophisticated BIN loader that would use the full paper width and with checksums, and which could read from the high-speed paper tape reader, if you had that peripheral.... - Ted From lm at mcvoy.com Thu Jul 31 00:13:41 2025 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 30 Jul 2025 07:13:41 -0700 Subject: [TUHS] Teletypes used for early Unix In-Reply-To: References: <4A9909C2-4EA6-4D7E-9015-4CE70A62688E@canb.auug.org.au> <20250730011537.GG1150@mcvoy.com> Message-ID: <20250730141341.GA16702@mcvoy.com> On Wed, Jul 30, 2025 at 07:18:07AM +0000, segaloco via TUHS wrote: > On Tuesday, July 29th, 2025 at 6:15 PM, Larry McVoy wrote: > > > On Wed, Jul 30, 2025 at 10:27:23AM +1000, Jonathan Gray wrote: > > > > > "The remote-batch load absorbs about 5 per cent of the 11/70 and its > > > residual capacity is used to serve nearly 50 interactive terminals. > > > > > > I still remember, fondly (sort of) being in a terminal room with 50+ > > other students all hooked up to a 4MB VAX 780. The fondness was the > > sort of bonding we all had from pulling all nighters to get stuff to > > work (this was at UW-Madison, back then it was a hard core hacking > > school, lots of Sun's kernel group came from Madison, including > > Rusty (NFS) and Mojo (he wrote the 4.x VM system) and a bunch of > > others). > > > > The not so fond part was hit ^T over and over again (it gave you > > a one line PS like output showing load) while your compiled seemed > > swapped out forever. > > > > The not fondness made me take out one of the very few loans I have had, > > in 1985ish I borrowed $2000 to buy a Okidata CPM machine, it was a lot > > slower than the VAX, but all the cycles were mine. I wrote a lot of > > code on that machine. Including assembler versions of cp, rm, ls, > > etc, each of which fit in 512 bytes because that was one sector on > > a floppy disk, I didn't want to wait for more than one sector to > > load. Fun times. Now my phone is like 10,000x faster and has > > easily that much more memory. > > > > --lm > > Larry if you don't mind my curiosity, were these UNIX-y utilities sitting on top of and using CP/M services or chomping at the hardware a little more closely? Or something else? It's been a long time but I can't imagine I reimplemented the file system in 512 bytes. So I must have used something from CP/M. I didn't have the chops to redo the file system at that time. I was still learning OS stuff. The biggest thing I wrote on that machine was a dial in/terminal emulator/ file transfer tool I called quicknet. I kinda wish I still had that code, my memory is that it was very pleasant. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat