From imp at bsdimp.com Sun Sep 1 00:13:53 2024 From: imp at bsdimp.com (Warner Losh) Date: Sat, 31 Aug 2024 08:13:53 -0600 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> Message-ID: On Sat, Aug 31, 2024 at 12:38 AM Greg 'groggy' Lehey wrote: > On Saturday, 31 August 2024 at 0:12:16 -0400, Noel Chiappa wrote: > >> From: Kevin Bowling > > > >> https://gunkies.org/wiki/BSD/386 and the parent page on seem to suggest > >> it originated off Net/2 directly. > > > > I wouldn't be putting too much weight on what that page says; most of the > > *BSD pages were done by people I don't know well, and who might have > gotten > > details wrong > > FWIW, my understanding is also that it came from Net/2. But it's been > a few years now, and I wasn't directly involved. I just can't think > of anything else from which it could have been derived. > > > (So confusing that '386BSD' is something different from > > 'BSD/386'. Was there ever actually a '386/BSD'?) > > Not to my knowledge. > > > Someone who knows the early history of all the *BSD systems (as in, > > you lived through all that) is welcome, nay invited, to fix any > > errors therein. > > I wouldn't exactly call it early history, but my first exposure to > (any kind of) BSD was in March 1992, when I installed BSDI's BSD/386 > (something like Beta 0.3.1). You can read more than you want at > http://www.lemis.com/grog/diary-mar1992.php > > I subsequently (August 1992) visited Rob Kolstad, who was running the > show at the time, and he filled me in. With his help, what I recall > is: > > - Some time in or before 1991, a company called Berkeley Software > Design Inc (BSDI) was formed with the intention of completing and > marketing a BSD variant. The system was released as BSD/386 in > 1992. > > - BSDI had a number of prominent BSD people, including Bill Jolitz. > Bill was not in agreement that they should charge money for it, and > as Rob tells me, in December 1991 Bill left the company after > significant altercations, destroying all his work. He later > released his version, 386BSD. > Yes. They started with net/2. Other accounts have Bill Jolitz bringing some preliminary 386 porting work to BSDi and then leaving in a huff over charging for it. He released 386BSD based on that work (or a redo of that work, I've seen both accounts, not sure which one to believe). He released them to the world, and then had no ability to manage the project he created leading to the patch kit which without a leader fissioned into NetBSD and FreeBSD, each with different aims. > - At some later date BSDI released a SPARC port, at which point the > name BSD/386 seemed inappropriate, so they changed it to BSD/OS. I > have a CD set of release 2.0 labeled BSD/OS. > > - The last CD set I have is undated, version 3.0, labeled BSDI > Internet Server. I think it was still called BSD/OS, but I can't be > sure. > > Round this time I moved away from BSD/OS, since it cost money, and > FreeBSD seemed to be just as good. > > - In June 2000 we (FreeBSD) discussed merging the code bases of BSD/OS > and FreeBSD, specifically for SMP improvements. At the time the > BSD/OS release was 4.x, and we were looking at the 5.0 code. This > is also the first time where I saw the name written as BSDi; > previously, including all the CDs, it was always BSDI. > There were also a number of items that did get merged into FreeBSD at this time. We also looked at the PC Card stack moving over, but I didn't have the time to get it working on FreeBSD because significant SMPNG work made bringing over the code more difficult and a bigger project than I had time for. > On Friday, 30 August 2024 at 21:40:29 -0700, Kevin Bowling wrote: > > > > BSD/386 seems to be a first order derivative of net/2. Source: > > https://ia902809.us.archive.org/25/items/BSD3861.1CD/bsd1.1-manual.pdf. > > To what degree that it incorporated anything from 386bsd would > > probably rely on first hand accounts. > > As mentioned above, not at all. When the first flaky 386BSD betas > were released, BSD/386 was already up and running. > Yes. Jolitz code was in both, but BSDi's BSD/386 was first. There was a longer beta for it as well. That code circulated a bit before it was officially released. I think this was to attract VC funding for BSDi, but that detail is from a half-remembered conversation with Mike Karls and Kirk McKusick over beers far too many years ago. > > I don't have much to go on for BSD/OS 2.x but it seems like it was > > about rebasing on 4.4-lite if we look at the family tree > > http://www.netbsd.org/about/history.html > > Yes, this would have been one of the results of the AT&T lawsuit. > FreeBSD 2.0 was also rebased on 4.4BSD-Lite. > As did NetBSD for 1.0, though they took a different tact: FreeBSD did a fresh import into a fresh repo, while NetBSD removed bits incrementally until it was clean, but then had issues making their repo public due to the settlement with AT&T. Everybody had to rebase. Nobody could continue to use NET/2 that was using it when the lawsuit started. After 4.4-lite came out, there was no real reason for others to start with net/2, so I'm not aware of anybody else using that code for a full kernel. > > Luckily for BSD/OS 4.x we get some release notes: > > * > > > https://ia600908.us.archive.org/view_archive.php?archive=/22/items/bsdos-4.01/bsdos-4.01-binary.iso&file=RELEASENOTES.pdf > > Yes, that looks good. It also narrows the time frame for when BSDI > became BSDi, some time between July 1998 and June 2000. > > > For 5.x I again don't have much to go on but we can take an indirect > > approach from some FreeBSD SMPng reports where BSDi donated source > > code that was not used wholesale but instead had to be reintegrated or > > rewritten: > > * http://www.lemis.com/grog/Daemons-advocate/unix-way-c.html > > Heh. I had forgotten about that. > Yes. By the time SMPNG had started, the divergence made lots of the kernel code not a drop in. But lots of code was integrated into SMPNG, in addition to lots being written / modified. > > I would be pretty confident in saying BSD/OS is _not_ a FreeBSD > > derivative but a first order derivative of net/2 > > Yes, I think so. I can't think of anything else that could have been > in between. > BSDi came from net/2. FreeBSD came from net/2. They shared code back and forth in the FreeBSD 3.x, 4.x, 5.x and 6.x time period. > > ... that eventually wound up looking a little bit like FreeBSD in > > its later years. > > Hmm. You haven't discussed how FreeBSD evolved, which was from > 386BSD. And my understanding is that 386BSD, like BSD/386, was also > derived from Net/2. I used both BSD/OS and FreeBSD side by side for a > number of years without noticing significant differences. It wasn't > until I started porting the SMP code from BSD/OS 5.0 to FreBSD > (coincidentally also 5.0) that I realized how different the kernel had > become. > Yes. net/2 -> BSD/386 -> BSD/OS and net/2 -> 386bsd -> patch kit -> FreeBSD. But after the BSD/386, BSDi added SMP work (ASMP) and some vm improvements. They did a lot of driver work, including supporting PC Cards and a few other things. They also wrote 'witness' to debug their locking work that would wind up later in FreeBSD. FreeBSD also added VM improvement from John Dyson in 3.x and 4.x as well as ASMP support in 4.x from Steve Passe. CAM was added between 3 and 4 as well, so we lost a bunch of drivers because CAM was a steep learning curve compared to the Julian Elischer scsi code that had come before (though in the end not that different from it, the different world view was hard to approach). FreeBSD also got a new device model in 3.2 by Doug Rabson (to this day called Newbus, despite being over 25 years on from whatever oldbus was). During this time, small bits of code flowed back and forth. You can still find commits that mention the committer got the code from BSDi, though sometimes that's spelled 'from Mike Karls' :). So BSD/386 was 1992 and FreeBSD 1.0 was late 1993. SMP/ng work started in 2001 or so, almost a full decade of evolution where both groups were heavily innovating core parts of the kernel. These changes made it hard to drop in code. > > According to grog in > > (www.lemis.com/grog/Daemons-advocate/unix-way-c.html) there was an > > attempt by BSDi to rebase to FreeBSD but it was abandoned. > > My recollection was that the intention was to merge rather than > rebase. What we did do (the SMP code) was definitely from BSD/OS to > FreeBSD. The rest of the merge idea didn't get very far, and I can't > recall any significant attempts to push it forward. > That's what I recall as well. I do recall that FreeBSD had to significantly rework much of the code we got from BSD/OS due to the evolution in both the kernel, and some of Steve Passe's work had to be unwound before we could move forward. And it took years to get done. We'd originally hoped to do a release in like 2001, and then did a tech preview of 5.0 in 2003 a full release in 5.2 in 2004 that was useable, but it wasn't really until maybe 2007 or so that SMP was solid. > > I've found scant detail on what WindRiver did with 5.0 and 5.1 so I > > am unsure, but in playing around with 5.1 it does have FreeBSD's CAM > > layer but does not look like i.e. FreeBSD 5.x in a variety of > > material ways. > > It's worth considering what things were like at the time. You, as > potential user, have the choice: BSD/OS for $1000 or FreeBSD for free. > What advantage do you get from BSD/OS? Yes, there were some, but they > weren't really enough to keep BSD/OS viable. That's why I had made > the change a few years earlier, and I don't think that WindRiver's > heart was really in it. So the SMP code was really something like a > swan song. > Yes. BSDi's business model hadn't expected the rise of Open Source being serious competitors. And the pressures from Linux also helped to slow sales around the time the rebase / merge / whatever had been contemplated. Plus the sale to WindRiver was supposed to be this wonderful thing, but in the end turned out to be not so great. I've not studied the BSDi CAM. I'll have to do that. I have studied the Ultrix/OSF/1 CAM and it is quite different than the FreeBSD CAM (which has evolved significantly since 3.x days). The notion of source code compatibility for all SCSI drivers was an interesting thing, but even between the Ultrix and FreeBSD CAMs, there's huge differences in headers and function blocks that don't seem to be described by the standard and that need slightly different code as well... I've also not been able to find source to the original MacOS CAM nor the early DOS CAM frameworks, though references to them litter the early literature from the mid 90s. Both of them moved on from CAM after the first generation of SCSI devices. 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodrigosloop at gmail.com Sun Sep 1 02:26:02 2024 From: rodrigosloop at gmail.com (=?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?=) Date: Sat, 31 Aug 2024 18:26:02 +0200 Subject: [TUHS] the Y window system In-Reply-To: References: Message-ID: maybe it was developed outside of the labs then. -rodri On Sat, Aug 31, 2024 at 12:56 PM Rob Pike wrote: > > I've never heard of it. > > -rob > > > On Sat, Aug 31, 2024 at 8:16 PM Rodrigo G. López wrote: >> >> hello everyone, >> >> i recently came across a little window manager, written in Alef, that >> i've had in my /tmp folder >> for the last five years. it's called Y (probably as a response to X), >> and i grabbed it from >> 9gridchan's public griddisk; run by the late mycroftiv until 2022. >> >> i think it must've been an experimental project by Pike, Rosenthal or >> Tom Duff, but i can't find >> any documentation about it anywhere. i'd love to know if any of you >> remembers this, and if so, >> would you share the story behind it? >> >> i uploaded the source code here: http://antares-labs.eu/isometric/Y.tgz >> >> and it runs on 2nd ed plan 9 without issue (see the attached screenshot.) >> >> >> cheers! >> >> -rodri From ama at ugr.es Sun Sep 1 04:09:55 2024 From: ama at ugr.es (Angel M Alganza) Date: Sat, 31 Aug 2024 20:09:55 +0200 Subject: [TUHS] the Y window system In-Reply-To: References: Message-ID: On 2024-08-31 11:59, Rodrigo G. López wrote: > i'd love to know if any of you remembers this, and if so, would you > share the story behind it? I think Y was included in PicoBSD, the one 1.44MB 3.5" floppy version of FreeBSD. I must have a couple of floppies with it on them somewhere. Need to look for them now and give them a try. :-) Cheers, Ángel From jaapna at xs4all.nl Sun Sep 1 04:15:43 2024 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Sat, 31 Aug 2024 20:15:43 +0200 Subject: [TUHS] the Y window system In-Reply-To: References: Message-ID: <61EA47E5-C45F-4DA6-902F-70BF9BD10729@xs4all.nl> > On 31 Aug 2024, at 20:09, Angel M Alganza wrote: > > On 2024-08-31 11:59, Rodrigo G. López wrote: > >> i'd love to know if any of you remembers this, and if so, would you share the story behind it? Google tells me: https://www.y-windows.org/ jaap > > I think Y was included in PicoBSD, the one 1.44MB 3.5" floppy version of FreeBSD. I must have a couple of floppies with it on them somewhere. Need to look for them now and give them a try. :-) > > Cheers, > Ángel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Sep 1 04:28:50 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Sat, 31 Aug 2024 14:28:50 -0400 Subject: [TUHS] BSD/OS In-Reply-To: <20240831021035.88DDA92D1442@ary.qy> References: <20240831021035.88DDA92D1442@ary.qy> Message-ID: <47cf7cb8-a2e6-45ca-af58-6608538260e5@case.edu> On 8/30/24 10:10 PM, John Levine wrote: > I contacted BSDI and, in one of those things that would be too strange > to be fiction, we found that the guy at Cornell who'd written the open > source routing daemon now worked for BSDI and lived about 10 minutes > from me. I called him up, he sent me some patches, and everything > worked. I could not have asked for better software support. Wasn't that Jeff Honig and gated? IIRC, he did some of the work I incorporated into the custom 4.3 BSD I ran on my IBM RT during the mid-90s. -- ``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 tuhs at tuhs.org Sun Sep 1 04:49:07 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Sat, 31 Aug 2024 14:49:07 -0400 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> Message-ID: <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> On 8/31/24 12:40 AM, Kevin Bowling wrote: > BSD/386 seems to be a first order derivative of net/2. Source: > https://ia902809.us.archive.org/25/items/BSD3861.1CD/bsd1.1-manual.pdf. > To what degree that it incorporated anything from 386bsd would > probably rely on first hand accounts. We ran all of these at CWRU for many years. The mail system, DNS, and other services all ran on BSD/OS machines. Nice, clean distribution will full source code and excellent support. > I don't have much to go on for BSD/OS 2.x but it seems like it was > about rebasing on 4.4-lite if we look at the family tree > http://www.netbsd.org/about/history.html This is about where we got seriously into the game. I probably still have the source for it somewhere. I did a bunch of development on that version. > Not much sourcing to go on for BSD/OS 3.x. Probably have the source for this, too. > > Luckily for BSD/OS 4.x we get some release notes: > * https://ia600908.us.archive.org/view_archive.php?archive=/22/items/bsdos-4.01/bsdos-4.01-binary.iso&file=RELEASENOTES.pdf > * https://ia800900.us.archive.org/view_archive.php?archive=/21/items/bsdos-4.1/bsdos-4.1-binary.iso&file=RELEASENOTES.pdf We definitely used these versions heavily, up through the mid-aughts. > For 5.x I again don't have much to go on I think I have a box with this distribution in my office. That was after I got out of the server game. > > And what I was initially after, a comparative report on how BSD/OS > related to others: > https://www.usenix.org/legacy/events/usenix99/full_papers/metz/metz.pdf > (page 6) > > I would be pretty confident in saying BSD/OS is _not_ a FreeBSD > derivative but a first order derivative of net/2 that eventually wound > up looking a little bit like FreeBSD in its later years. Yep. BSDI employed a bunch of BSD heavy hitters. Mike Karels Keith Bostic Donn Seeley Chris Torek Rob Kolstad (President) Jeff Honig Bill Jolitz Kirk McKusick (one of the founders) They were a pleasure to work with. Chet -- ``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 kevin.bowling at kev009.com Sun Sep 1 04:49:24 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 31 Aug 2024 11:49:24 -0700 Subject: [TUHS] HP-UX Message-ID: Larry, I'll bite. Tell us about HP-UX :) My observations.. Up til 9.x it was a BSD-alike. In 10 and especially 11 it became much more SysV-alike. VUE desktop was nice for the time, CDE took on its visual style. 11.x becomes bloated like later Solaris releases. Technology transfer is hard. There are some nice internals docs: 6: https://bitsavers.org/pdf/hp/9000_hpux/training/SE390_Series_300_HP-UX_Internals_1988.pdf 9: https://bitsavers.org/pdf/hp/9000_hpux/training/SE390_Series_300_HP-UX_Internals_Apr93.pdf 11i: https://www.filibeto.org/unix/hp-ux/lib/kernel/inside-hp-ux-os.pdf 11i: ISBN 0130328618 hp-ux 11i internals book (the above doc is a lot more in depth) I wonder if we should collect resources like this on a wiki page or something? I really like this inside the factory stuff. Regards, Kevin From tuhs at tuhs.org Sun Sep 1 04:56:10 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Sat, 31 Aug 2024 14:56:10 -0400 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> Message-ID: On 8/31/24 10:13 AM, Warner Losh wrote: > Yes. They started with net/2. Other accounts have Bill Jolitz bringing some > preliminary 386 porting work to BSDi and then leaving in a huff over > charging for it. Yep. I remember the BSD BOF at one Usenix (1992 maybe?) where Bill got up from his seat and started yelling at Kirk/Mike/Keith, asking how they could live with themselves. Good times. -- ``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 lm at mcvoy.com Sun Sep 1 05:30:11 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 31 Aug 2024 12:30:11 -0700 Subject: [TUHS] HP-UX In-Reply-To: References: Message-ID: <20240831193011.GX11259@mcvoy.com> On Sat, Aug 31, 2024 at 11:49:24AM -0700, Kevin Bowling wrote: > Larry, I'll bite. Tell us about HP-UX :) They didn't understand mmap() semantics at all. The page cache and the buffer cache both existed, there were races on the coherency and they didn't share data. So the whole point of mmap(), a window into the cache, didn't work. If you looked at a file read only with mmap() and read(), you used 2x the memory you should have because there were two non-shared caches. And it was just clunky, I came from SunOS, the bar was pretty high. Define clunky, you ask? Making stuff work on HP-UX was way harder than SunOS. Most open source things, you could just type "make" and it worked. Not so much on hockey pucks. --lm From lm at mcvoy.com Sun Sep 1 05:31:19 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 31 Aug 2024 12:31:19 -0700 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> Message-ID: <20240831193119.GY11259@mcvoy.com> On Sat, Aug 31, 2024 at 02:56:10PM -0400, Chet Ramey via TUHS wrote: > On 8/31/24 10:13 AM, Warner Losh wrote: > > >Yes. They started with net/2. Other accounts have Bill Jolitz bringing some > >preliminary 386 porting work to BSDi and then leaving in a huff over > >charging for it. > > Yep. I remember the BSD BOF at one Usenix (1992 maybe?) where Bill got up > from his seat and started yelling at Kirk/Mike/Keith, asking how they could > live with themselves. Good times. I actually hired Bill because I knew about that drama and he really got the short end of the stick. Unfairly, in my opinion. It's sad. So I gave him a job for a while. --lm From rodrigosloop at gmail.com Sun Sep 1 05:31:36 2024 From: rodrigosloop at gmail.com (=?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?=) Date: Sat, 31 Aug 2024 21:31:36 +0200 Subject: [TUHS] the Y window system In-Reply-To: <61EA47E5-C45F-4DA6-902F-70BF9BD10729@xs4all.nl> References: <61EA47E5-C45F-4DA6-902F-70BF9BD10729@xs4all.nl> Message-ID: > Google tells me: https://www.y-windows.org/ > judging from the screenshots and the code, that one has nothing to do with this. -rodri On Sat, Aug 31, 2024 at 8:16 PM Jaap Akkerhuis wrote: > > On 31 Aug 2024, at 20:09, Angel M Alganza wrote: > > On 2024-08-31 11:59, Rodrigo G. López wrote: > > i'd love to know if any of you remembers this, and if so, would you share the story behind it? > > > Google tells me: https://www.y-windows.org/ > > jaap > > > I think Y was included in PicoBSD, the one 1.44MB 3.5" floppy version of FreeBSD. I must have a couple of floppies with it on them somewhere. Need to look for them now and give them a try. :-) > > Cheers, > Ángel > > From rodrigosloop at gmail.com Sun Sep 1 05:32:59 2024 From: rodrigosloop at gmail.com (=?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?=) Date: Sat, 31 Aug 2024 21:32:59 +0200 Subject: [TUHS] the Y window system In-Reply-To: References: Message-ID: > I think Y was included in PicoBSD, the one 1.44MB 3.5" floppy version of > FreeBSD. I must have a couple of floppies with it on them somewhere. > Need to look for them now and give them a try. :-) cool, that'd be great. thanks! -rodri On Sat, Aug 31, 2024 at 8:16 PM Angel M Alganza wrote: > > On 2024-08-31 11:59, Rodrigo G. López wrote: > > > i'd love to know if any of you remembers this, and if so, would you > > share the story behind it? > > I think Y was included in PicoBSD, the one 1.44MB 3.5" floppy version of > FreeBSD. I must have a couple of floppies with it on them somewhere. > Need to look for them now and give them a try. :-) > > Cheers, > Ángel From tuhs at tuhs.org Sun Sep 1 05:35:58 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Sat, 31 Aug 2024 12:35:58 -0700 Subject: [TUHS] the Y window system Message-ID: <4ADB991B-6CD2-4DD6-80BD-8090EB12D1F7@iitbombay.org>  On Aug 31, 2024, at 11:16 AM, Jaap Akkerhuis wrote: >  >> On 31 Aug 2024, at 20:09, Angel M Alganza wrote: >> >> On 2024-08-31 11:59, Rodrigo G. López wrote: >> >>> i'd love to know if any of you remembers this, and if so, would you share the story behind it? > > Google tells me: https://www.y-windows.org/ This is likely a different Y window sys than what Rodrigo found, which is written in Alef and runs on 2nd ed plan9. Rodrigo may want to trawl through 9fans mailing list/usenet group archives or ask there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodrigosloop at gmail.com Sun Sep 1 05:59:31 2024 From: rodrigosloop at gmail.com (=?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?=) Date: Sat, 31 Aug 2024 21:59:31 +0200 Subject: [TUHS] the Y window system In-Reply-To: <4ADB991B-6CD2-4DD6-80BD-8090EB12D1F7@iitbombay.org> References: <4ADB991B-6CD2-4DD6-80BD-8090EB12D1F7@iitbombay.org> Message-ID: I actually found a reference to it in the 9fans ml: https://marc.info/?l=9fans&m=111558693515179&w=2 turns out it's been in /sys/src/alef/test/Y on 2nd ed plan 9 all along. but i still wonder, who did this if not rob himself? thanks Bakul for mentioning the ml. that reminded me of the local archive i have, and i was able to sort through it quickly. -rodri On Sat, Aug 31, 2024 at 9:36 PM Bakul Shah via TUHS wrote: > >  > On Aug 31, 2024, at 11:16 AM, Jaap Akkerhuis wrote: > > >  > > On 31 Aug 2024, at 20:09, Angel M Alganza wrote: > > On 2024-08-31 11:59, Rodrigo G. López wrote: > > i'd love to know if any of you remembers this, and if so, would you share the story behind it? > > > Google tells me: https://www.y-windows.org/ > > > This is likely a different Y window sys than what Rodrigo found, > which is written in Alef and runs on 2nd ed plan9. Rodrigo may > want to trawl through 9fans mailing list/usenet group archives > or ask there. > > > From rik at rikfarrow.com Sun Sep 1 06:01:32 2024 From: rik at rikfarrow.com (Rik Farrow) Date: Sat, 31 Aug 2024 13:01:32 -0700 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> Message-ID: I was interested in BSDi initially because of the AT&T lawsuit against BSDi and the University of California Board of Regents. Dumb move, and relevant only that it suppressed the distribution and use of BSD-based Unix while Linux took off, while doing nothing good for AT&T. Rob Kolstad, the CEO of BSDi, told me that they were paying Jolitz to port the memory management to the 386 architecture, then Jolitz got upset over the BSD386 version costing money. Some companies needed a commercially supported BSD, including UUnet, who used BSD for their port concentrators (where they connected up the dozens of modems used for dial-in access to the Internet). Rick Adams (UUnet) was involved in the lawsuit because he wanted a BSD for his business, and supported BSDi financially AFAIK. Today, FreeBSD does this with support from donations to the FreeBSD Foundation. Rik On Sat, Aug 31, 2024 at 7:14 AM Warner Losh wrote: > > > On Sat, Aug 31, 2024 at 12:38 AM Greg 'groggy' Lehey > wrote: > >> On Saturday, 31 August 2024 at 0:12:16 -0400, Noel Chiappa wrote: >> >> From: Kevin Bowling >> > >> >> https://gunkies.org/wiki/BSD/386 and the parent page on seem to >> suggest >> >> it originated off Net/2 directly. >> > >> > I wouldn't be putting too much weight on what that page says; most of >> the >> > *BSD pages were done by people I don't know well, and who might have >> gotten >> > details wrong >> >> FWIW, my understanding is also that it came from Net/2. But it's been >> a few years now, and I wasn't directly involved. I just can't think >> of anything else from which it could have been derived. >> >> > (So confusing that '386BSD' is something different from >> > 'BSD/386'. Was there ever actually a '386/BSD'?) >> >> Not to my knowledge. >> >> > Someone who knows the early history of all the *BSD systems (as in, >> > you lived through all that) is welcome, nay invited, to fix any >> > errors therein. >> >> I wouldn't exactly call it early history, but my first exposure to >> (any kind of) BSD was in March 1992, when I installed BSDI's BSD/386 >> (something like Beta 0.3.1). You can read more than you want at >> http://www.lemis.com/grog/diary-mar1992.php >> >> I subsequently (August 1992) visited Rob Kolstad, who was running the >> show at the time, and he filled me in. With his help, what I recall >> is: >> >> - Some time in or before 1991, a company called Berkeley Software >> Design Inc (BSDI) was formed with the intention of completing and >> marketing a BSD variant. The system was released as BSD/386 in >> 1992. >> >> - BSDI had a number of prominent BSD people, including Bill Jolitz. >> Bill was not in agreement that they should charge money for it, and >> as Rob tells me, in December 1991 Bill left the company after >> significant altercations, destroying all his work. He later >> released his version, 386BSD. >> > > Yes. They started with net/2. Other accounts have Bill Jolitz bringing some > preliminary 386 porting work to BSDi and then leaving in a huff over > charging for it. He released 386BSD based on that work (or a redo of > that work, I've seen both accounts, not sure which one to believe). He > released > them to the world, and then had no ability to manage the project he created > leading to the patch kit which without a leader fissioned into NetBSD > and FreeBSD, each with different aims. > > >> - At some later date BSDI released a SPARC port, at which point the >> name BSD/386 seemed inappropriate, so they changed it to BSD/OS. I >> have a CD set of release 2.0 labeled BSD/OS. >> >> - The last CD set I have is undated, version 3.0, labeled BSDI >> Internet Server. I think it was still called BSD/OS, but I can't be >> sure. >> >> Round this time I moved away from BSD/OS, since it cost money, and >> FreeBSD seemed to be just as good. >> >> - In June 2000 we (FreeBSD) discussed merging the code bases of BSD/OS >> and FreeBSD, specifically for SMP improvements. At the time the >> BSD/OS release was 4.x, and we were looking at the 5.0 code. This >> is also the first time where I saw the name written as BSDi; >> previously, including all the CDs, it was always BSDI. >> > > There were also a number of items that did get merged into FreeBSD at > this time. We also looked at the PC Card stack moving over, but I didn't > have the time to get it working on FreeBSD because significant SMPNG > work made bringing over the code more difficult and a bigger project than > I had time for. > > >> On Friday, 30 August 2024 at 21:40:29 -0700, Kevin Bowling wrote: >> > >> > BSD/386 seems to be a first order derivative of net/2. Source: >> > https://ia902809.us.archive.org/25/items/BSD3861.1CD/bsd1.1-manual.pdf. >> > To what degree that it incorporated anything from 386bsd would >> > probably rely on first hand accounts. >> >> As mentioned above, not at all. When the first flaky 386BSD betas >> were released, BSD/386 was already up and running. >> > > Yes. Jolitz code was in both, but BSDi's BSD/386 was first. There was > a longer beta for it as well. That code circulated a bit before it was > officially released. I think this was to attract VC funding for BSDi, but > that detail is from a half-remembered conversation with Mike Karls and > Kirk McKusick over beers far too many years ago. > > >> > I don't have much to go on for BSD/OS 2.x but it seems like it was >> > about rebasing on 4.4-lite if we look at the family tree >> > http://www.netbsd.org/about/history.html >> >> Yes, this would have been one of the results of the AT&T lawsuit. >> FreeBSD 2.0 was also rebased on 4.4BSD-Lite. >> > > As did NetBSD for 1.0, though they took a different tact: FreeBSD did > a fresh import into a fresh repo, while NetBSD removed bits incrementally > until it was clean, but then had issues making their repo public due to the > settlement with AT&T. > > Everybody had to rebase. Nobody could continue to use NET/2 that was using > it when the lawsuit started. After 4.4-lite came out, there was no real > reason for > others to start with net/2, so I'm not aware of anybody else using that > code for > a full kernel. > > >> > Luckily for BSD/OS 4.x we get some release notes: >> > * >> > >> https://ia600908.us.archive.org/view_archive.php?archive=/22/items/bsdos-4.01/bsdos-4.01-binary.iso&file=RELEASENOTES.pdf >> >> Yes, that looks good. It also narrows the time frame for when BSDI >> became BSDi, some time between July 1998 and June 2000. >> >> > For 5.x I again don't have much to go on but we can take an indirect >> > approach from some FreeBSD SMPng reports where BSDi donated source >> > code that was not used wholesale but instead had to be reintegrated or >> > rewritten: >> > * http://www.lemis.com/grog/Daemons-advocate/unix-way-c.html >> >> Heh. I had forgotten about that. >> > > Yes. By the time SMPNG had started, the divergence made lots of the > kernel code not a drop in. But lots of code was integrated into SMPNG, > in addition to lots being written / modified. > > >> > I would be pretty confident in saying BSD/OS is _not_ a FreeBSD >> > derivative but a first order derivative of net/2 >> >> Yes, I think so. I can't think of anything else that could have been >> in between. >> > > BSDi came from net/2. FreeBSD came from net/2. They shared code > back and forth in the FreeBSD 3.x, 4.x, 5.x and 6.x time period. > > >> > ... that eventually wound up looking a little bit like FreeBSD in >> > its later years. >> >> Hmm. You haven't discussed how FreeBSD evolved, which was from >> 386BSD. And my understanding is that 386BSD, like BSD/386, was also >> derived from Net/2. I used both BSD/OS and FreeBSD side by side for a >> number of years without noticing significant differences. It wasn't >> until I started porting the SMP code from BSD/OS 5.0 to FreBSD >> (coincidentally also 5.0) that I realized how different the kernel had >> become. >> > > Yes. net/2 -> BSD/386 -> BSD/OS and net/2 -> 386bsd -> patch kit -> > FreeBSD. > > But after the BSD/386, BSDi added SMP work (ASMP) and some vm improvements. > They did a lot of driver work, including supporting PC Cards and a few > other things. > They also wrote 'witness' to debug their locking work that would wind up > later in FreeBSD. > > FreeBSD also added VM improvement from John Dyson in 3.x and 4.x as well as > ASMP support in 4.x from Steve Passe. CAM was added between 3 and 4 as > well, > so we lost a bunch of drivers because CAM was a steep learning curve > compared > to the Julian Elischer scsi code that had come before (though in the end > not > that different from it, the different world view was hard to approach). > FreeBSD also > got a new device model in 3.2 by Doug Rabson (to this day called Newbus, > despite > being over 25 years on from whatever oldbus was). > > During this time, small bits of code flowed back and forth. You can still > find commits > that mention the committer got the code from BSDi, though sometimes that's > spelled > 'from Mike Karls' :). > > So BSD/386 was 1992 and FreeBSD 1.0 was late 1993. SMP/ng work started in > 2001 > or so, almost a full decade of evolution where both groups were heavily > innovating > core parts of the kernel. These changes made it hard to drop in code. > > >> > According to grog in >> > (www.lemis.com/grog/Daemons-advocate/unix-way-c.html) there was an >> > attempt by BSDi to rebase to FreeBSD but it was abandoned. >> >> My recollection was that the intention was to merge rather than >> rebase. What we did do (the SMP code) was definitely from BSD/OS to >> FreeBSD. The rest of the merge idea didn't get very far, and I can't >> recall any significant attempts to push it forward. >> > > That's what I recall as well. I do recall that FreeBSD had to significantly > rework much of the code we got from BSD/OS due to the evolution > in both the kernel, and some of Steve Passe's work had to be unwound > before we could move forward. And it took years to get done. We'd > originally > hoped to do a release in like 2001, and then did a tech preview of 5.0 in > 2003 > a full release in 5.2 in 2004 that was useable, but it wasn't really until > maybe > 2007 or so that SMP was solid. > > >> > I've found scant detail on what WindRiver did with 5.0 and 5.1 so I >> > am unsure, but in playing around with 5.1 it does have FreeBSD's CAM >> > layer but does not look like i.e. FreeBSD 5.x in a variety of >> > material ways. >> >> It's worth considering what things were like at the time. You, as >> potential user, have the choice: BSD/OS for $1000 or FreeBSD for free. >> What advantage do you get from BSD/OS? Yes, there were some, but they >> weren't really enough to keep BSD/OS viable. That's why I had made >> the change a few years earlier, and I don't think that WindRiver's >> heart was really in it. So the SMP code was really something like a >> swan song. >> > > Yes. BSDi's business model hadn't expected the rise of Open Source being > serious competitors. And the pressures from Linux also helped to slow sales > around the time the rebase / merge / whatever had been contemplated. Plus > the sale to WindRiver was supposed to be this wonderful thing, but in the > end turned out to be not so great. > > I've not studied the BSDi CAM. I'll have to do that. I have studied the > Ultrix/OSF/1 > CAM and it is quite different than the FreeBSD CAM (which has evolved > significantly > since 3.x days). The notion of source code compatibility for all SCSI > drivers was an > interesting thing, but even between the Ultrix and FreeBSD CAMs, there's > huge differences > in headers and function blocks that don't seem to be described by the > standard and > that need slightly different code as well... I've also not been able to > find source to > the original MacOS CAM nor the early DOS CAM frameworks, though references > to > them litter the early literature from the mid 90s. Both of them moved on > from CAM > after the first generation of SCSI devices. > > 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Sun Sep 1 06:20:56 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 31 Aug 2024 13:20:56 -0700 Subject: [TUHS] HP-UX In-Reply-To: <20240831193011.GX11259@mcvoy.com> References: <20240831193011.GX11259@mcvoy.com> Message-ID: On Sat, Aug 31, 2024 at 12:30 PM Larry McVoy wrote: > > On Sat, Aug 31, 2024 at 11:49:24AM -0700, Kevin Bowling wrote: > > Larry, I'll bite. Tell us about HP-UX :) > > They didn't understand mmap() semantics at all. The page cache and the > buffer cache both existed, there were races on the coherency and they > didn't share data. So the whole point of mmap(), a window into the > cache, didn't work. If you looked at a file read only with mmap() > and read(), you used 2x the memory you should have because there > were two non-shared caches. >From what I can tell from the documents I linked, and some other references, they never ended up doing a UBC. > And it was just clunky, I came from SunOS, the bar was pretty high. > Define clunky, you ask? Making stuff work on HP-UX was way harder > than SunOS. Most open source things, you could just type "make" > and it worked. Not so much on hockey pucks. > > --lm > > From jnc at mercury.lcs.mit.edu Sun Sep 1 07:01:39 2024 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 31 Aug 2024 17:01:39 -0400 (EDT) Subject: [TUHS] the Y window system Message-ID: <20240831210139.2843D18C089@mercury.lcs.mit.edu> > From: Rodrigo Lopez >> Google tells me: https://www.y-windows.org/ > from .. the code, that one has nothing to do with this. It actually makes sense that there are two separate ones called 'Y'. The X Window System was a descendant of the W window system, so if someone wanted to do another one, 'Y' was the obvious namee to pick. All it needs now is two separate people who decide they want to do a window system... voila! Noel From jnc at mercury.lcs.mit.edu Sun Sep 1 07:44:42 2024 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 31 Aug 2024 17:44:42 -0400 (EDT) Subject: [TUHS] HP-UX Message-ID: <20240831214442.33D3E18C089@mercury.lcs.mit.edu> > From: Kevin Bowling > I wonder if we should collect resources like this on a wiki page or > something? My habit on the CHWiki is to have the articles on subjects where there is a lot of documentation online is to have the articles mostly be 'executive summeries', and corral the links to the stuff online to a section at the end, so that people who want to see the gory details can look at the original documentation. See, for example: https://gunkies.org/wiki/AN/FSQ-7 That works well, even for material that later goes 404, because with the URL, one can generally find it later in the Internet Archive (things like Google won't find things that are only there). Don't ask me to add them, though; I still haven't found time to add the links to the BSD/OS stuff you found! Noel From johnl at taugh.com Sun Sep 1 09:20:45 2024 From: johnl at taugh.com (John R Levine) Date: 31 Aug 2024 19:20:45 -0400 Subject: [TUHS] BSD/OS In-Reply-To: <47cf7cb8-a2e6-45ca-af58-6608538260e5@case.edu> References: <20240831021035.88DDA92D1442@ary.qy> <47cf7cb8-a2e6-45ca-af58-6608538260e5@case.edu> Message-ID: <0a559157-540e-2503-0deb-cf8dcbe5bb23@taugh.com> On Sat, 31 Aug 2024, Chet Ramey wrote: >> source routing daemon now worked for BSDI and lived about 10 minutes >> from me. I called him up, he sent me some patches, and everything >> worked. I could not have asked for better software support. > > Wasn't that Jeff Honig and gated? IIRC, he did some of the work I > incorporated into the custom 4.3 BSD I ran on my IBM RT during the > mid-90s. Yup. That's his TCP-IP license plate. Small world department: I did a lot of the architecture and some of the programming AIX, the Unix you did not run your RT. R's, John From reed at reedmedia.net Sun Sep 1 12:14:29 2024 From: reed at reedmedia.net (Jeremy C. Reed) Date: Sun, 1 Sep 2024 02:14:29 +0000 (UTC) Subject: [TUHS] BSD/OS In-Reply-To: <20240831130725.BCD3418C089@mercury.lcs.mit.edu> References: <20240831130725.BCD3418C089@mercury.lcs.mit.edu> Message-ID: On Sat, 31 Aug 2024, Noel Chiappa wrote: > and he refers to Jolitz's system as "386/BSD" (apparently incorrectly). (So > there's a lesson there; even people who '_were_ there' can occasionally get it > wrong - something that professional historians are well aware of. I have a > funny story of my learning that lesson, here: > > http://www.chiappa.net/~jnc/nontech/tmlotus.html > > in a totally different technical area.) > > I have yet to see a _scan_ of contemporary documentation (I believe nothing > that isn't a contemporary _physical artifact_) that confirms it was actually > named "386BSD", but that does seem to be the name as given in the Dr. Dobbs > series on it. That series confirms that it was based directly on the 'Net/2' > BSD release (although 'diff's on the sources are probably the most reliable > proof). Is this "apparently incorrectly" about the / slash? As for use (regardless of artifact) with / I only see in McKusick's histories and one use in the old 386bsd.faq (which uses without slash in all but once), Another mistake was use of "386/BSD" for BSDI's software in the Civil Action No.92-1667 AMICUS BRIEF (930107.amicus.txt) where all the other legal references were "BSD/386". Or is this about the 386BSD name itself (without the slash)? An early mention of it is from src/sys/i386/i386/locore.s from net.2 * @(#)locore.s 7.3 (Berkeley) 5/13/91 */ /* * locore.s: 4BSD machine support for the Intel 386 * Preliminary version * Written by William F. Jolitz, 386BSD Project and gdb/config/m-i386bsd.h change from him but I don't know of a physical artifact around then other than the CD that came with the magazine. Does anyone have the CD or print magazines? (Sadly I lost or threw mine away in the 1990s. I got the subscription as a Christmas present and didn't realize that "BSD" value until near a decade later.) Someday I need to finish my book where I did over 80 email, phone, or in-person interviews. t1:svn-bsd-history$ wc 386bsd* patchkit.tex lawsuit.tex bsdi* 43bsd-part2.tex 87 471 3319 386bsd-part3.tex 530 3264 23198 386bsd.tex 1258 7793 52650 patchkit.tex 3155 21517 137284 lawsuit.tex 929 5177 36451 bsdi-part2.tex 499 3477 22738 bsdi.tex 3879 28436 180396 43bsd-part2.tex 10337 70135 456036 total (which is less than a quarter of the story) From robpike at gmail.com Sun Sep 1 12:29:28 2024 From: robpike at gmail.com (Rob Pike) Date: Sun, 1 Sep 2024 12:29:28 +1000 Subject: [TUHS] the Y window system In-Reply-To: References: Message-ID: I looked at the source. I still have no memory of it existing, but stylistically it's almost certainly code written by Phil Winterbottom. -rob On Sun, Sep 1, 2024 at 2:26 AM Rodrigo G. López wrote: > maybe it was developed outside of the labs then. > > > -rodri > > On Sat, Aug 31, 2024 at 12:56 PM Rob Pike wrote: > > > > I've never heard of it. > > > > -rob > > > > > > On Sat, Aug 31, 2024 at 8:16 PM Rodrigo G. López > wrote: > >> > >> hello everyone, > >> > >> i recently came across a little window manager, written in Alef, that > >> i've had in my /tmp folder > >> for the last five years. it's called Y (probably as a response to X), > >> and i grabbed it from > >> 9gridchan's public griddisk; run by the late mycroftiv until 2022. > >> > >> i think it must've been an experimental project by Pike, Rosenthal or > >> Tom Duff, but i can't find > >> any documentation about it anywhere. i'd love to know if any of you > >> remembers this, and if so, > >> would you share the story behind it? > >> > >> i uploaded the source code here: http://antares-labs.eu/isometric/Y.tgz > >> > >> and it runs on 2nd ed plan 9 without issue (see the attached > screenshot.) > >> > >> > >> cheers! > >> > >> -rodri > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wobblygong at gmail.com Sun Sep 1 12:48:21 2024 From: wobblygong at gmail.com (Wesley Parish) Date: Sun, 1 Sep 2024 14:48:21 +1200 Subject: [TUHS] BSD/OS In-Reply-To: <20240831130725.BCD3418C089@mercury.lcs.mit.edu> References: <20240831130725.BCD3418C089@mercury.lcs.mit.edu> Message-ID: <7090ea52-98c6-4d1e-9a19-276ede992ace@gmail.com> Certainly, that was the impression I got from reading the 386BSD text/help files that came with the 386BSD CDROM Dr Dobbs were selling. The 386BSD was Net/2 ported to the 386. Wesley Parish On 1/09/24 01:07, Noel Chiappa wrote: > > From: Noel Chiappa > > > Was there ever actually a '386/BSD'? > > I decided (for not particular reason) to take a quick read through Marshall > Kirk McKusick's "Twenty Years of Berkeley Unix From AT&T-Owned to Freely > Redistributable": > > https://www.oreilly.com/openbook/opensources/book/kirkmck.html > > and he refers to Jolitz's system as "386/BSD" (apparently incorrectly). (So > there's a lesson there; even people who '_were_ there' can occasionally get it > wrong - something that professional historians are well aware of. I have a > funny story of my learning that lesson, here: > > http://www.chiappa.net/~jnc/nontech/tmlotus.html > > in a totally different technical area.) > > I have yet to see a _scan_ of contemporary documentation (I believe nothing > that isn't a contemporary _physical artifact_) that confirms it was actually > named "386BSD", but that does seem to be the name as given in the Dr. Dobbs > series on it. That series confirms that it was based directly on the 'Net/2' > BSD release (although 'diff's on the sources are probably the most reliable > proof). > > Noel From arnold at skeeve.com Sun Sep 1 15:50:19 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 31 Aug 2024 23:50:19 -0600 Subject: [TUHS] BSD/OS In-Reply-To: <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> Message-ID: <202409010550.4815oJk1080323@freefriends.org> Chet Ramey via TUHS wrote: > BSDI employed a bunch of BSD heavy hitters. > > Mike Karels > Keith Bostic > Donn Seeley > Chris Torek > Rob Kolstad (President) > Jeff Honig > Bill Jolitz > Kirk McKusick (one of the founders) What nobody has mentioned so far (at least as far as I've gotten in my email) is that they were the ones who woke the sleeping giant, by advertising their product as "UNIX" and with a phone number 1-800-ITS-UNIX. That started off all the lawsuits. At least, that is how I remember it. Arnold From kevin.bowling at kev009.com Sun Sep 1 17:32:48 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 1 Sep 2024 00:32:48 -0700 Subject: [TUHS] BSD/OS In-Reply-To: <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> Message-ID: On Sat, Aug 31, 2024 at 11:49 AM Chet Ramey wrote: > > On 8/31/24 12:40 AM, Kevin Bowling wrote: > > > BSD/386 seems to be a first order derivative of net/2. Source: > > https://ia902809.us.archive.org/25/items/BSD3861.1CD/bsd1.1-manual.pdf. > > To what degree that it incorporated anything from 386bsd would > > probably rely on first hand accounts. > > We ran all of these at CWRU for many years. The mail system, DNS, and > other services all ran on BSD/OS machines. Nice, clean distribution > will full source code and excellent support. > > > I don't have much to go on for BSD/OS 2.x but it seems like it was > > about rebasing on 4.4-lite if we look at the family tree > > http://www.netbsd.org/about/history.html > > This is about where we got seriously into the game. I probably still have > the source for it somewhere. > > I did a bunch of development on that version. > > > Not much sourcing to go on for BSD/OS 3.x. > > Probably have the source for this, too. By sourcing I was meaning finding primary documentation for my summary. I am only pointing this out to make a related point that is worth recording: BSD/OS always seemed to ship with the source code, and it was "easy" to build unlike some commercial UNIX where the source was provided ceremonially and had complicated build processes. In that respect, BSD/OS is a "source provided" commercial program and this seems to be making a reappearance lately as some companies are deciding whether or not they still like open source licenses or struggling to meet inflated expectations of their fundraising. Many of the BSD/OS versions have disc images on archive.org or osarchive.org where the 7.4GB rar file was helpful for getting a 5.1 contrib disc since the archive.org one is corrupt. So the binaries and source seem fairly well preserved for future explorers. > > > > Luckily for BSD/OS 4.x we get some release notes: > > * https://ia600908.us.archive.org/view_archive.php?archive=/22/items/bsdos-4.01/bsdos-4.01-binary.iso&file=RELEASENOTES.pdf > > * https://ia800900.us.archive.org/view_archive.php?archive=/21/items/bsdos-4.1/bsdos-4.1-binary.iso&file=RELEASENOTES.pdf > > We definitely used these versions heavily, up through the mid-aughts. > > > For 5.x I again don't have much to go on > > I think I have a box with this distribution in my office. That was > after I got out of the server game. > > > > > And what I was initially after, a comparative report on how BSD/OS > > related to others: > > https://www.usenix.org/legacy/events/usenix99/full_papers/metz/metz.pdf > > (page 6) > > > > I would be pretty confident in saying BSD/OS is _not_ a FreeBSD > > derivative but a first order derivative of net/2 that eventually wound > > up looking a little bit like FreeBSD in its later years. > > Yep. > > BSDI employed a bunch of BSD heavy hitters. > > Mike Karels > Keith Bostic > Donn Seeley > Chris Torek > Rob Kolstad (President) > Jeff Honig > Bill Jolitz > Kirk McKusick (one of the founders) > > They were a pleasure to work with. > > Chet > > -- > ``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/ From rodrigosloop at gmail.com Sun Sep 1 20:43:11 2024 From: rodrigosloop at gmail.com (=?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?=) Date: Sun, 1 Sep 2024 12:43:11 +0200 Subject: [TUHS] the Y window system In-Reply-To: References: Message-ID: thanks rob! i don't see him on the list, so i'll see if i can reach him through other media. -rodri On Sun, Sep 1, 2024 at 4:29 AM Rob Pike wrote: > > I looked at the source. I still have no memory of it existing, but stylistically it's almost certainly code written by Phil Winterbottom. > > -rob > > > On Sun, Sep 1, 2024 at 2:26 AM Rodrigo G. López wrote: >> >> maybe it was developed outside of the labs then. >> >> >> -rodri >> >> On Sat, Aug 31, 2024 at 12:56 PM Rob Pike wrote: >> > >> > I've never heard of it. >> > >> > -rob >> > >> > >> > On Sat, Aug 31, 2024 at 8:16 PM Rodrigo G. López wrote: >> >> >> >> hello everyone, >> >> >> >> i recently came across a little window manager, written in Alef, that >> >> i've had in my /tmp folder >> >> for the last five years. it's called Y (probably as a response to X), >> >> and i grabbed it from >> >> 9gridchan's public griddisk; run by the late mycroftiv until 2022. >> >> >> >> i think it must've been an experimental project by Pike, Rosenthal or >> >> Tom Duff, but i can't find >> >> any documentation about it anywhere. i'd love to know if any of you >> >> remembers this, and if so, >> >> would you share the story behind it? >> >> >> >> i uploaded the source code here: http://antares-labs.eu/isometric/Y.tgz >> >> >> >> and it runs on 2nd ed plan 9 without issue (see the attached screenshot.) >> >> >> >> >> >> cheers! >> >> >> >> -rodri From rich.salz at gmail.com Sun Sep 1 21:59:11 2024 From: rich.salz at gmail.com (Rich Salz) Date: Sun, 1 Sep 2024 07:59:11 -0400 Subject: [TUHS] BSD/OS In-Reply-To: <202409010550.4815oJk1080323@freefriends.org> References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> <202409010550.4815oJk1080323@freefriends.org> Message-ID: The phone number 1-800-ITS-UNIX, didn't help. But ATT sued the Regents of California first because of UCBs net releases. And while there were many of the same principles, the two lawsuits were different. At&t did not have much choice. Unix was protected by trade secret, and once it was available, the trade secret was gone. Rick Adams asked a lawyer if somebody posted it to Usenet by uploading it from a phone booth. Would happen, The lawyers gulped and said it's available now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Sep 2 00:49:51 2024 From: imp at bsdimp.com (Warner Losh) Date: Sun, 1 Sep 2024 08:49:51 -0600 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> <202409010550.4815oJk1080323@freefriends.org> Message-ID: On Sun, Sep 1, 2024 at 5:59 AM Rich Salz wrote: > The phone number 1-800-ITS-UNIX, didn't help. But ATT sued the Regents of > California first because of UCBs net releases. And while there were many of > the same principles, the two lawsuits were different. > > At&t did not have much choice. Unix was protected by trade secret, and > once it was available, the trade secret was gone. Rick Adams asked a lawyer > if somebody posted it to Usenet by uploading it from a phone booth. Would > happen, The lawyers gulped and said it's available now. > Trade Secret is one of the big reasons there was a preliminary ruling in the UCB/ATT lawsuit that 32V had lost its copyright protection. It had been distributed outside of AT&T to a large degree without the Trade Secret warning. It's why all the 4BSD releases are publicly available now. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Sep 2 09:12:08 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 2 Sep 2024 09:12:08 +1000 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> <202409010550.4815oJk1080323@freefriends.org> Message-ID: On 2/9/24 00:49, Warner Losh wrote: > > > Trade Secret is one of the big reasons there was a preliminary ruling > in the UCB/ATT lawsuit that 32V had lost its copyright protection. It > had been distributed outside of AT&T to a large degree without the > Trade Secret warning. It's why all the 4BSD releases are publicly > available now. > Absolutely true, but there was a bit more work needed than just the preliminary ruling. In parallel, the TUHS folk were petitioning old SCO (not TSG) to release the ancient Unixes under a BSD-style license: https://www.tuhs.org/PUPS/petition.html. Eventually old SCO agreed to a BSD-style hobbyist license which cost US$100: https://web.archive.org/web/20010603053221/http://www.sco.com/offers/ancient.html. Some details of the process are here: https://www.tuhs.org/PUPS/pstatus.html. Then a while later, Caldera (who had bought the Unix licensing from old SCO) offered their $0 license: https://www.tuhs.org/Archive/Caldera-license.pdf. I want to give a shout out to Dion Johnson who was the driving force at old SCO that finally got them to agree to putting the ancient Unixes under a BSD-style license. Cheers, Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Sep 2 09:14:01 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 2 Sep 2024 09:14:01 +1000 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> <202409010550.4815oJk1080323@freefriends.org> Message-ID: <2813ed05-de2b-4f2a-9428-1d680a745928@tuhs.org> On 1/9/24 21:59, Rich Salz wrote: > The phone number 1-800-ITS-UNIX, didn't help.  But ATT sued the > Regents of California first because of UCBs net releases. And while > there were many of the same principles, the two lawsuits were different. When Dennis Ritchie was still with us, he cached many of the legal documents from both lawsuits on his home page: https://www.bell-labs.com/usr/dmr/www/bsdi/bsdisuit.html Cheers, Warren From usotsuki at buric.co Mon Sep 2 09:24:03 2024 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 1 Sep 2024 19:24:03 -0400 (EDT) Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> <202409010550.4815oJk1080323@freefriends.org> Message-ID: On Mon, 2 Sep 2024, Warren Toomey via TUHS wrote: > Absolutely true, but there was a bit more work needed than just the > preliminary ruling. In parallel, the TUHS folk were petitioning old SCO (not > TSG) to release the ancient Unixes under a BSD-style license: > https://www.tuhs.org/PUPS/petition.html. Eventually old SCO agreed to a > BSD-style hobbyist license which cost US$100: > https://web.archive.org/web/20010603053221/http://www.sco.com/offers/ancient.html. > Some details of the process are here: https://www.tuhs.org/PUPS/pstatus.html. > > Then a while later, Caldera (who had bought the Unix licensing from old SCO) > offered their $0 license: https://www.tuhs.org/Archive/Caldera-license.pdf. > > I want to give a shout out to Dion Johnson who was the driving force at old > SCO that finally got them to agree to putting the ancient Unixes under a > BSD-style license. Am I confabulating an incident where TSG's people were trying to claim that "a group of hackers called Caldera International" were behind the license and that it never happened (despite reality) ? I could swear I recall that happening but I can't find any evidence. -uso. From tuhs at tuhs.org Mon Sep 2 09:36:13 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 2 Sep 2024 09:36:13 +1000 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> <202409010550.4815oJk1080323@freefriends.org> Message-ID: On 2/9/24 09:24, Steve Nickolas wrote: > > Am I confabulating an incident where TSG's people were trying to claim > that "a group of hackers called Caldera International" were behind the > license and that it never happened (despite reality) ? I could swear I > recall that happening but I can't find any evidence. > That I haven't heard of, but it is possible. The Caldera license is somewhat problematic. My take on the situation is that old SCO had the rights to issue source code and binary licenses, even though they didn't actually have the copyright to the code (at the time Novell did). Old SCO had the right to create the US$100 "Ancient UNIX" license. And when old SCO sold the licensing rights to Caldera, Caldera had the right to grant the free license at https://www.tuhs.org/Archive/Caldera-license.pdf. Cheers, Warren From usotsuki at buric.co Mon Sep 2 10:13:59 2024 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 1 Sep 2024 20:13:59 -0400 (EDT) Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> <202409010550.4815oJk1080323@freefriends.org> Message-ID: On Mon, 2 Sep 2024, Warren Toomey via TUHS wrote: > The Caldera license is somewhat problematic. My take on the situation is that > old SCO had the rights to issue source code and binary licenses, even though > they didn't actually have the copyright to the code (at the time Novell did). That's my take as well. Caldera would assumedly have inherited these rights when they bought old SCO. But as you said, they didn't have the copyright - and the copyright notice and the Third Clause on the Caldera license require a copyright attribution to them. My stance is: While we can't be 100% sure on 32V, it's probably the _safest_ place to start, if one were to pinch from pre-S3 Unix. If Xinuos or another claimant were to come at someone over it, it would put the "invalid copyright" theory to the test. Anyway, copyright on the actual AT&T code is a rat's nest and I actually started trying to come up with an analog so as to avoid getting finked over the code. -uso. From imp at bsdimp.com Mon Sep 2 13:32:52 2024 From: imp at bsdimp.com (Warner Losh) Date: Sun, 1 Sep 2024 21:32:52 -0600 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> <202409010550.4815oJk1080323@freefriends.org> Message-ID: On Sun, Sep 1, 2024 at 6:13 PM Steve Nickolas wrote: > On Mon, 2 Sep 2024, Warren Toomey via TUHS wrote: > > > The Caldera license is somewhat problematic. My take on the situation is > that > > old SCO had the rights to issue source code and binary licenses, even > though > > they didn't actually have the copyright to the code (at the time Novell > did). > > That's my take as well. > > Caldera would assumedly have inherited these rights when they bought old > SCO. But as you said, they didn't have the copyright - and the copyright > notice and the Third Clause on the Caldera license require a copyright > attribution to them. > Plus, Novell knew about these licenses, so the principle of latches would likely preclude any legal action as well... Or at least make it more difficult to do so. So even if the copyright didn't transfer, and the rights to sublicense were somehow exceeded their grant and someone wanted to make trouble, it would be a very tricky case. The Caldera license does include 32V as well as V7, so the 2BSD line, which is based heavily on V7 unix + bug fixes and big code flows from 4.2BSD, 4.3BSD and 4.4BSD, is also a bit in limbo. My stance is: While we can't be 100% sure on 32V, it's probably the > _safest_ place to start, if one were to pinch from pre-S3 Unix. If Xinuos > or another claimant were to come at someone over it, it would put the > "invalid copyright" theory to the test. > Yes. Xinuos showed up at a FreeBSD vendor summit some years ago when they launched their latest thing, based on FreeBSD. The story at the time was they were super keen on putting the past in the past. I'd say that either there's no copyright at all on 32V (since it was authored before the US was signatory to the Berne Convention, and since it relied on trade secret for its protection and since it was distributed without the proper notice for hat) or if there is, Caldera license covers it. And since the ruling was in 2010 and nobody has shown up to contest the Caldera license, it would be tricky to to show up now that the cat is substantailly out of the bag. One might speculate that the Caldera license might not be valid after that, the matter hasn't been litigated and IANAL, but since we can only speculate whether or not Caldera exceeded its rights in granting the license. I think that one relying on the Caldera license to govern their actions would have a good faith defense should the situation change, but I'm not sure how much that would mitigate the consequences. But if Xinuos don't own the copyright, then it's the residual of Novell, which according to Wikipedia: The company was an independent corporate entity until it was acquired as a wholly owned subsidiary by The Attachmate Group in 2011. Attachmate was subsequently acquired in 2014 by Micro Focus International which was acquired in turn by OpenText in 2023. Novell products and technologies are now integrated within various OpenText divisions. So maybe OpenText owns Unix. There were efforts to clear things up with MicroFocus before Covid, that last I heard had gone nowhere. There's also this post, which I ran into 3 or so years ago... https://community.microfocus.com/welcome_to_the_community/f/over-the-back-fence/168007/micro-focus-s-stance-on-ancient-unix-licensing But OpenText sold its AMC business to Rocket Software May 1, 2024, the press release in parts ays: "Closing the acquisition of the Application Modernization and Connectivity (AMC) business of OpenText, formerly part of Micro Focus, Rocket Software now offers customers" So maybe Rocket Software owns Unix now? Or maybe OpenText retaineed it. https://www.rocketsoftware.com/news/rocket-software-closes-2275b-acquisition-opentexts-application-modernization-and-connectivity So the plot thickens, eh? > Anyway, copyright on the actual AT&T code is a rat's nest and I actually > started trying to come up with an analog so as to avoid getting finked > over the code. Yes. At best, a researcher could get by with some kind of 'fair use' defense, and anybody not basing a System Vish product not on OpenIndian (and its kin) would be significantly exposed... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Sep 3 00:54:51 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 2 Sep 2024 10:54:51 -0400 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> <202409010550.4815oJk1080323@freefriends.org> Message-ID: On Sun, Sep 1, 2024 at 11:33 PM Warner Losh wrote: > Plus, Novell knew about these licenses, so the principle of latches would > likely preclude any legal action as well... Or at least make it more > difficult > to do so. So even if the copyright didn't transfer, and the rights to > sublicense > were somehow exceeded their grant and someone wanted to make trouble, > it would be a very tricky case. > > For the benefit of those of us who don't know legal jargon, "laches" is a legal principle whereby a court can deny relief to a claimant with an otherwise valid claim when the party bringing the claim unreasonably delayed asserting the claim to the detriment of the opposing party. In this case, Novell knew about the SCO and Caldera "archaic Unix" licenses being issued but did nothing at the time. Were they to try to sue years later to block use of those licenses, the party being sued could invoke the principle of laches and claim that Novell knew about the licenses, did nothing at the time, and it's now too late to bring the claim before the court. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuff at riddermarkfarm.ca Tue Sep 3 00:58:15 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Mon, 2 Sep 2024 10:58:15 -0400 Subject: [TUHS] HP-UX In-Reply-To: <20240831193011.GX11259@mcvoy.com> References: <20240831193011.GX11259@mcvoy.com> Message-ID: On 2024-08-31 15:30, Larry McVoy wrote (in part): > Not so much on hockey pucks. New term to me -- I had always heard it called "H-Pox". S. From brad at anduin.eldar.org Tue Sep 3 01:02:04 2024 From: brad at anduin.eldar.org (Brad Spencer) Date: Mon, 02 Sep 2024 11:02:04 -0400 Subject: [TUHS] HP-UX In-Reply-To: (message from Stuff Received on Mon, 2 Sep 2024 10:58:15 -0400) Message-ID: Stuff Received writes: > On 2024-08-31 15:30, Larry McVoy wrote (in part): >> Not so much on hockey pucks. > > New term to me -- I had always heard it called "H-Pox". > > S. Heavily Patched was what we called it at Lucent in the group I was in. -- Brad Spencer From ron at ronnatalie.com Tue Sep 3 01:45:43 2024 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 02 Sep 2024 15:45:43 +0000 Subject: [TUHS] HP-UX In-Reply-To: References: Message-ID: I worked with HP for years on joint development. Never heard it called anything other than H-Pucks. That was in contrast to HP’s other operating system, Mighty Poor Excuse. From ads at salewski.email Tue Sep 3 03:17:16 2024 From: ads at salewski.email (Alan D. Salewski) Date: Mon, 2 Sep 2024 13:17:16 -0400 Subject: [TUHS] HP-UX In-Reply-To: References: Message-ID: On 2024-09-02 11:02:04, Brad Spencer spake thus: >Stuff Received writes: > >> On 2024-08-31 15:30, Larry McVoy wrote (in part): >>> Not so much on hockey pucks. >> >> New term to me -- I had always heard it called "H-Pox". >> >> S. > >Heavily Patched was what we called it at Lucent in the group I was in. > >-- >Brad Spencer "Hourly Patches" is one of the names I heard in the small HP-UX shop in which I worked in the late 1990's. The system updates would arrive on physical CD-ROM media fairly frequently (or so it seemed at the time), and those would pile up until somebody applied them. FWIW, HP's HP-UX tech support at that time was really top-notch, in sharp contrast to most other tech support with whom I've dealt, before and since. -- a l a n d. s a l e w s k i ads at salewski.email salewski at att.net https://github.com/salewski From jon at fourwinds.com Tue Sep 3 03:44:34 2024 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 02 Sep 2024 10:44:34 -0700 Subject: [TUHS] HP-UX In-Reply-To: References: Message-ID: <202409021744.482HiYHt900322@darkstar.fourwinds.com> Alan D. Salewski writes: > On 2024-09-02 11:02:04, Brad Spencer spake thus: > >Stuff Received writes: > > > >> On 2024-08-31 15:30, Larry McVoy wrote (in part): > >>> Not so much on hockey pucks. > >> > >> New term to me -- I had always heard it called "H-Pox". > >> > >> S. > > > >Heavily Patched was what we called it at Lucent in the group I was in. > > > >-- > >Brad Spencer > > "Hourly Patches" is one of the names I heard in the small HP-UX shop My view of HP radically changed in the late 1980s as the result of bidding on a contract. I got a call from the marketing person with whom I was working who was laughing so hysterically that it took a while to get the story. It all comes down to the "HP Way". She went in to pitch our proposal to a room full of guys. A some point one of them started pounding his fist on the table saying "No no no no no. You just don't grasp the HP-ness of it." It was a testament to her skill that she managed to keep a straight face. That's what it's been to me ever since. The HP-ness. Jon From dave at horsfall.org Tue Sep 3 05:59:23 2024 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 3 Sep 2024 05:59:23 +1000 (AEST) Subject: [TUHS] HP-UX In-Reply-To: References: <20240831193011.GX11259@mcvoy.com> Message-ID: On Mon, 2 Sep 2024, Stuff Received wrote: > > Not so much on hockey pucks. > > New term to me -- I had always heard it called "H-Pox". Be glad that they didn't call themselves Packard-Hewlett... -- Dave From peter.martin.yardley at gmail.com Tue Sep 3 09:06:49 2024 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Tue, 3 Sep 2024 09:06:49 +1000 Subject: [TUHS] HP-UX In-Reply-To: References: <20240831193011.GX11259@mcvoy.com> Message-ID: <484E0283-635B-4755-BA9E-C19BF1FC325D@gmail.com> Hockey Pucks Aches and Pains Slowaris > On 3 Sep 2024, at 12:58 AM, Stuff Received wrote: > > On 2024-08-31 15:30, Larry McVoy wrote (in part): >> Not so much on hockey pucks. > > New term to me -- I had always heard it called "H-Pox". > > S. > .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From lm at mcvoy.com Tue Sep 3 09:13:44 2024 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 2 Sep 2024 16:13:44 -0700 Subject: [TUHS] HP-UX In-Reply-To: <484E0283-635B-4755-BA9E-C19BF1FC325D@gmail.com> References: <20240831193011.GX11259@mcvoy.com> <484E0283-635B-4755-BA9E-C19BF1FC325D@gmail.com> Message-ID: <20240902231344.GA4883@mcvoy.com> On Tue, Sep 03, 2024 at 09:06:49AM +1000, Peter Yardley wrote: > Hockey Pucks > Aches and Pains > Slowaris That last one hurts, I spent so much time making SunOS fast only to have it all thrown away. Sigh. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From peter.martin.yardley at gmail.com Tue Sep 3 09:41:13 2024 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Tue, 3 Sep 2024 09:41:13 +1000 Subject: [TUHS] HP-UX In-Reply-To: <202409021744.482HiYHt900322@darkstar.fourwinds.com> References: <202409021744.482HiYHt900322@darkstar.fourwinds.com> Message-ID: <4FF64DB4-B284-470B-9ED6-566DF0413AA3@gmail.com> This is a joke I remember about the HP way … https://www.cs.earlham.edu/~skylar/humor/Unix/hp.lunch.htm > On 3 Sep 2024, at 3:44 AM, Jon Steinhart wrote: > > Alan D. Salewski writes: >> On 2024-09-02 11:02:04, Brad Spencer spake thus: >>> Stuff Received writes: >>> >>>> On 2024-08-31 15:30, Larry McVoy wrote (in part): >>>>> Not so much on hockey pucks. >>>> >>>> New term to me -- I had always heard it called "H-Pox". >>>> >>>> S. >>> >>> Heavily Patched was what we called it at Lucent in the group I was in. >>> >>> -- >>> Brad Spencer >> >> "Hourly Patches" is one of the names I heard in the small HP-UX shop > > My view of HP radically changed in the late 1980s as the result of > bidding on a contract. I got a call from the marketing person with > whom I was working who was laughing so hysterically that it took a > while to get the story. > > It all comes down to the "HP Way". > > She went in to pitch our proposal to a room full of guys. A some > point one of them started pounding his fist on the table saying > "No no no no no. You just don't grasp the HP-ness of it." It was > a testament to her skill that she managed to keep a straight face. > > That's what it's been to me ever since. The HP-ness. > > Jon .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From ake.nordin at netia.se Tue Sep 3 09:45:43 2024 From: ake.nordin at netia.se (=?UTF-8?Q?=C3=85ke_Nordin?=) Date: Tue, 3 Sep 2024 01:45:43 +0200 Subject: [TUHS] HP-UX In-Reply-To: <484E0283-635B-4755-BA9E-C19BF1FC325D@gmail.com> References: <20240831193011.GX11259@mcvoy.com> <484E0283-635B-4755-BA9E-C19BF1FC325D@gmail.com> Message-ID: On 2024-09-03 01:06, Peter Yardley wrote: > Hockey Pucks > Aches and Pains I have absolutely no idea if anyone used "Hubris-Pachyderm" IRL, but J.D. Frazer (AKA "Illiad") used the slightly derogatory name in his webcomic, User Friendly. First use seems to have been Tuesday 2000-09-26: https://web.archive.org/web/20020713075556/http://ars.userfriendly.org/cartoons/?id=20000926&mode=classic -- Åke Nordin , resident Net/Lunix/telecom geek. Netia Data AB, Stockholm SWEDEN *46#7O466OI99# From lyndon at orthanc.ca Wed Sep 4 13:16:53 2024 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Tue, 03 Sep 2024 20:16:53 -0700 Subject: [TUHS] BSD/OS In-Reply-To: References: Message-ID: Greg 'groggy' Lehey writes: > > I would be pretty confident in saying BSD/OS is _not_ a FreeBSD > > derivative but a first order derivative of net/2 > > Yes, I think so. I can't think of anything else that could have been > in between. In the mid 90s I was at the U of Northern British Columbia. In late 1992 or early 93 we acqired a site licence for BSD/386 (with source) for the U. IIRC it was mosly Net/2 at the start, with some proprietary BSDi kernel (and other) enhancements. When the campus opened in 1994 we had it deployed on > 100 student PC workstations, running in a mostly "dataless" configuration (in Sun speak). It worked very well, exept for the X server, which regularly dumped core. I was more that a little surprised (and annoyed) to one day discover every one of those core dump was being emailed back to the mother ship. I forget who I takled to as BSDI about this, but they mentioned they were even more annoyed than us and had installed a custom sendmail rule to direct those messages into the bit bucket. I also recall taking my first run at FreeBSD in the fall of 1994. Release 1.05 sticks in my mind for some reason. After leaving the U, transitioning to FreeBSD was seamless. Towards the end of the 90s I was supporting a commercial IMAP server. I remember us entering into an agreement with BSDi to port and sell our code on their platform. Shortly after sealing that deal they were bought by Wind River, and their layers immediately got to work trying to undo that deal. Fuzzy memory says this was circa 2000. Apart from this, though, In 1993 I was still trying to figure out what UNIX (if any) we were going to run on the PCs in the student labs (the campus didn't open until 94). I had been eyeing up Sun's 386 offering, since I had a lot of experience with SunOS. I was at an Interop that year and tried pinning down one of the Sun sales rep's to talk about site licensing options. He could not have made it anymore more clear that anyone speaking of SunOS/Solaris on 386 should piss off! Immediately! Needless to say, BSDi won that deal. --lyndon From jim at deitygraveyard.com Wed Sep 4 18:49:47 2024 From: jim at deitygraveyard.com (Jim Carpenter) Date: Wed, 4 Sep 2024 04:49:47 -0400 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> Message-ID: On Sun, Sep 1, 2024 at 3:33 AM Kevin Bowling wrote: > Many of the BSD/OS versions have disc images on archive.org or > osarchive.org where the 7.4GB rar file was helpful for getting a 5.1 > contrib disc since the archive.org one is corrupt. So the binaries > and source seem fairly well preserved for future explorers. Check again. The contrib image in the 7.4GB rar has the same hash as the one on archive.org and elsewhere. I have no idea if the install image is 100% correct. Hell, it's possible every image in that archive and on archive.org is bad. I just don't know. So if anybody has any BSD/OS CDs please speak up. Jim From tuhs at tuhs.org Wed Sep 4 23:37:20 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Wed, 4 Sep 2024 09:37:20 -0400 Subject: [TUHS] BSD/OS In-Reply-To: <0a559157-540e-2503-0deb-cf8dcbe5bb23@taugh.com> References: <20240831021035.88DDA92D1442@ary.qy> <47cf7cb8-a2e6-45ca-af58-6608538260e5@case.edu> <0a559157-540e-2503-0deb-cf8dcbe5bb23@taugh.com> Message-ID: <5fe2e8eb-445d-41a9-9c86-e7b64b1dd54b@case.edu> On 8/31/24 7:20 PM, John R Levine wrote: > AIX, the Unix you did not run your RT. Oh, we tried. BSD just worked better for us. -- ``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 tuhs at tuhs.org Wed Sep 4 23:47:38 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Wed, 4 Sep 2024 09:47:38 -0400 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831130725.BCD3418C089@mercury.lcs.mit.edu> Message-ID: <6fb33904-2f1f-45f8-ba33-89387a60b3f0@case.edu> On 8/31/24 10:14 PM, Jeremy C. Reed wrote: > Someday I need to finish my book where I did over 80 email, phone, or > in-person interviews. I'd read that book. -- ``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 kevin.bowling at kev009.com Fri Sep 6 15:05:36 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 5 Sep 2024 22:05:36 -0700 Subject: [TUHS] HP-UX In-Reply-To: References: <20240831193011.GX11259@mcvoy.com> Message-ID: On Sat, Aug 31, 2024 at 1:20 PM Kevin Bowling wrote: > > On Sat, Aug 31, 2024 at 12:30 PM Larry McVoy wrote: > > > > On Sat, Aug 31, 2024 at 11:49:24AM -0700, Kevin Bowling wrote: > > > Larry, I'll bite. Tell us about HP-UX :) > > > > They didn't understand mmap() semantics at all. The page cache and the > > buffer cache both existed, there were races on the coherency and they > > didn't share data. So the whole point of mmap(), a window into the > > cache, didn't work. If you looked at a file read only with mmap() > > and read(), you used 2x the memory you should have because there > > were two non-shared caches. > > From what I can tell from the documents I linked, and some other > references, they never ended up doing a UBC. Coincidentally I just came across a worthwile paper on UBC that concurs https://www.usenix.org/legacy/publications/library/proceedings/usenix2000/freenix/full_papers/silvers/silvers_html/index.html Reading between the lines a little bit with the benefit of modern search capabilities, I can piece together a story in that they ignored it and then there was a strategic FS shift. In HP-UX 10.x, they introduce "JFS" (unfortunate name since IBM used it with AIX 3.2 in 1990) which is more accurately a licensed VxFS a.k.a Veritas File System on top of VxVM. VxFS is interesting in its heyday because it had many contemporary features like journaling, extents, resizing, expansion, online defrag, and advanced readahead algorithms and is supposedly reliable and scalable. It was also empirically very portable, but I might glean that it was not so delicately ported to each OS and I see direct evidence it has its own variant of buffer cache.. which mirrors the ZFS saga. So, after they made that design decision, it became even more futile and unattainable. It would be interesting to know if Veritas did a better job with Solaris, AIX, UnixWare or Windows NT.. a somewhat difficult question to answer given the sands of time but I will keep an eye on it during future experiments. > > And it was just clunky, I came from SunOS, the bar was pretty high. > > Define clunky, you ask? Making stuff work on HP-UX was way harder > > than SunOS. Most open source things, you could just type "make" > > and it worked. Not so much on hockey pucks. > > > > --lm > > > > From tuhs at tuhs.org Sat Sep 7 14:49:59 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 07 Sep 2024 04:49:59 +0000 Subject: [TUHS] Bell Laboratories COBOL Syntax Checker? Message-ID: So I was flipping through a System V software catalog from Fall 1984 and among the many AT&T Bell Laboratories items is the "COBOL Syntax Checker". >From the text: ---QUOTE--- The COBOL Syntax Checker allows programmers to edit and check the syntax of COBOL programs before they are transmitted to mainframes for compilation and execution. The software increases the chances of a 'clean' compilation and execution and reduces the chance of a program being rejected due to syntax and simple semantic errors. As a result, expensive mainframe CPU time is reduced. The COBOL Syntax Checker processes a COBOL source program and produces three listings: 1. a diagnostic listing, 2. a cross-reference listing, 3. a source listing. ---END QUOTE--- There are two distributions listed, a C binary distribution for SVR2 for the 3B20 for $2000 and a C source distribution for SVR2 for the VAX 11/780 for $7500, both listed as released 2Q84. Some quick Googling only offers up additional catalog and magazine mentions. To me this sounds like a linter with some extra bits. Does anyone have any recollections of this software or know if there's much likelihood of the software itself or any documentation surviving? Thanks for any insights! - Matt G. From marc.donner at gmail.com Sun Sep 8 01:14:23 2024 From: marc.donner at gmail.com (Marc Donner) Date: Sat, 7 Sep 2024 11:14:23 -0400 Subject: [TUHS] Bell Laboratories COBOL Syntax Checker? In-Reply-To: References: Message-ID: Aside: by 1982 there was a COBOL compiler for the PC from Microsoft: https://archive.org/details/ibmpccobol I bet it was cheaper than the COBOL "lint" you mention :-) ===== nygeek.net mindthegapdialogs.com/home On Sat, Sep 7, 2024 at 12:50 AM segaloco via TUHS wrote: > So I was flipping through a System V software catalog from Fall 1984 and > among > the many AT&T Bell Laboratories items is the "COBOL Syntax Checker". > > From the text: > > ---QUOTE--- > > The COBOL Syntax Checker allows programmers to edit and check the syntax > of COBOL > programs before they are transmitted to mainframes for compilation and > execution. > The software increases the chances of a 'clean' compilation and execution > and > reduces the chance of a program being rejected due to syntax and simple > semantic > errors. As a result, expensive mainframe CPU time is reduced. > > The COBOL Syntax Checker processes a COBOL source program and produces > three > listings: > > 1. a diagnostic listing, > > 2. a cross-reference listing, > > 3. a source listing. > > ---END QUOTE--- > > There are two distributions listed, a C binary distribution for SVR2 for > the > 3B20 for $2000 and a C source distribution for SVR2 for the VAX 11/780 for > $7500, > both listed as released 2Q84. > > Some quick Googling only offers up additional catalog and magazine > mentions. > To me this sounds like a linter with some extra bits. Does anyone have any > recollections of this software or know if there's much likelihood of the > software > itself or any documentation surviving? > > Thanks for any insights! > > - Matt G. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From als at thangorodrim.ch Sun Sep 8 05:56:51 2024 From: als at thangorodrim.ch (Alexander Schreiber) Date: Sat, 7 Sep 2024 21:56:51 +0200 Subject: [TUHS] HP-UX In-Reply-To: References: <20240831193011.GX11259@mcvoy.com> Message-ID: On Mon, Sep 02, 2024 at 10:58:15AM -0400, Stuff Received wrote: > On 2024-08-31 15:30, Larry McVoy wrote (in part): > > Not so much on hockey pucks. > > New term to me -- I had always heard it called "H-Pox". Standard pronounciation I heard was "HP-SUX". And I was HP-UX sysadmin for a living for a while .. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison From als at thangorodrim.ch Sun Sep 8 06:34:51 2024 From: als at thangorodrim.ch (Alexander Schreiber) Date: Sat, 7 Sep 2024 22:34:51 +0200 Subject: [TUHS] HP-UX In-Reply-To: <484E0283-635B-4755-BA9E-C19BF1FC325D@gmail.com> References: <20240831193011.GX11259@mcvoy.com> <484E0283-635B-4755-BA9E-C19BF1FC325D@gmail.com> Message-ID: On Tue, Sep 03, 2024 at 09:06:49AM +1000, Peter Yardley wrote: > Hockey Pucks > Aches and Pains > Slowaris aka Slowlartus (and before that, ScumOS) in certain circles. Having had to deal with commercial Unices _really_ opened my eyes to what a _blessing_ Open Source Unix (Linux and the BSDs) are. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison From als at thangorodrim.ch Sun Sep 8 06:30:24 2024 From: als at thangorodrim.ch (Alexander Schreiber) Date: Sat, 7 Sep 2024 22:30:24 +0200 Subject: [TUHS] HP-UX In-Reply-To: References: Message-ID: On Mon, Sep 02, 2024 at 01:17:16PM -0400, Alan D. Salewski wrote: > > FWIW, HP's HP-UX tech support at that time was really top-notch, in > sharp contrast to most other tech support with whom I've dealt, > before and since. "Was" being the operative term here. By the time I wrestled HP-UX for a living (early 2000s), it was ... not so great. We ran the MCOE (Mission Critical Operating Environment) package with MC/ServiceGuard clustering for HA services and paid for the support contract to go with it. Ran into an issue were something we were trying to do just didn't work and the kernel told us to take a hike (LVM fun). Fine, time to use that expensive contract. We had a few rounds of back-and-forth with HP support, even got IIRC two new versions of the LVM binaries, no dice. After some time (IIRC at least 4 weeks) they must have found someone who remembered where the kernel sources were stashed _and_ could read them. We finally got an answer that TLDRed down to: "What you are trying to do cannot work because you run into hard coded design limits of the kernel", ok, fair enough - but why did that have to take so long? The hardware support (we ran both PA-RISC and Itanium from HP) was an interesting mixed bag at the time. Our normal hardware support guy was "old HP" and _really_ good, friendly chap, very competent. So were the consultants we hired for MC/SG training. Then we got a tech for the tape library who as originally Compaq and that was just ... bad[0], to the point where the aforementioned consultants were visibly embarassed and took over[2]. And from reading between the lines, there seemed to be no love lost between the two sides at HP at the time ("old HP" and "Compaq acquisition"). Kind regards, Alex. [0] Showing up to a (known to the company that sent you) pure HP-UX environment and demanding that the LTO library be wired to a Windows server[1] instead because you need to do a firmware update gets you results that start at loud laughter and move on to unprintable language. [1] Aside from us going "WTF?!", that wouldn't have worked anyway since the Windows servers the other departments had didn't have Fibre Channel interfaces ... [2] turns out, one could do the firmware updates from HP-UX if one knew their stuff -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison From grog at lemis.com Sun Sep 8 08:53:03 2024 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 8 Sep 2024 08:53:03 +1000 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> Message-ID: On Wednesday, 4 September 2024 at 4:49:47 -0400, Jim Carpenter wrote: > On Sun, Sep 1, 2024 at 3:33 AM Kevin Bowling wrote: >> Many of the BSD/OS versions have disc images on archive.org or >> osarchive.org where the 7.4GB rar file was helpful for getting a 5.1 >> contrib disc since the archive.org one is corrupt. So the binaries >> and source seem fairly well preserved for future explorers. > > Check again. The contrib image in the 7.4GB rar has the same hash as > the one on archive.org and elsewhere. I have no idea if the install > image is 100% correct. Hell, it's possible every image in that archive > and on archive.org is bad. I just don't know. > > So if anybody has any BSD/OS CDs please speak up. I have CDs of 2.0, 2.1 and 3.0. I had 1.x, but I can't put my hands on them right now. Maybe they were on QIC tape, in which case they're probably unrecoverable. I also have source trees for 4.0, 4.1 and the development version of 5.0 which I used to write the code for FreeBSD. What's the legal situation about distributing them? 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 imp at bsdimp.com Sun Sep 8 09:52:29 2024 From: imp at bsdimp.com (Warner Losh) Date: Sat, 7 Sep 2024 17:52:29 -0600 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> Message-ID: On Sat, Sep 7, 2024, 4:53 PM Greg 'groggy' Lehey wrote: > On Wednesday, 4 September 2024 at 4:49:47 -0400, Jim Carpenter wrote: > > On Sun, Sep 1, 2024 at 3:33 AM Kevin Bowling > wrote: > >> Many of the BSD/OS versions have disc images on archive.org or > >> osarchive.org where the 7.4GB rar file was helpful for getting a 5.1 > >> contrib disc since the archive.org one is corrupt. So the binaries > >> and source seem fairly well preserved for future explorers. > > > > Check again. The contrib image in the 7.4GB rar has the same hash as > > the one on archive.org and elsewhere. I have no idea if the install > > image is 100% correct. Hell, it's possible every image in that archive > > and on archive.org is bad. I just don't know. > > > > So if anybody has any BSD/OS CDs please speak up. > > I have CDs of 2.0, 2.1 and 3.0. I had 1.x, but I can't put my hands > on them right now. Maybe they were on QIC tape, in which case they're > probably unrecoverable. I also have source trees for 4.0, 4.1 and the > development version of 5.0 which I used to write the code for FreeBSD. > > What's the legal situation about distributing them? > No one is left to go after you for diing so. Wind river left bsdi support behind years ago.... But that's a slippery slope that depends on how you feel about ancient abandonware... 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sun Sep 8 10:07:49 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 7 Sep 2024 19:07:49 -0500 Subject: [TUHS] HP-UX In-Reply-To: References: Message-ID: <20240908000749.4264w7hbqdcaapnf@illithid> At 2024-09-07T22:30:24+0200, Alexander Schreiber wrote: > And from reading between the lines, there seemed to be no love lost > between the two sides at HP at the time ("old HP" and "Compaq > acquisition"). Yeah, but Carly Fiorina was _impactful_, man, and that's the most important thing you can be in this business. When it's a bad idea and you do it anyway and tons of people complain, that just means you're capable of making the Hard Choices(tm). Upon such things are multiple presidential campaigns launched. https://fortune.com/article/why-carlys-big-bet-is-failing-fortune-classics-2005/ 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 tuhs at tuhs.org Sun Sep 8 10:19:16 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 08 Sep 2024 00:19:16 +0000 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> Message-ID: On Saturday, September 7th, 2024 at 4:52 PM, Warner Losh wrote: > > > On Sat, Sep 7, 2024, 4:53 PM Greg 'groggy' Lehey wrote: > > > On Wednesday, 4 September 2024 at 4:49:47 -0400, Jim Carpenter wrote: > > > On Sun, Sep 1, 2024 at 3:33 AM Kevin Bowling wrote: > > >> Many of the BSD/OS versions have disc images on archive.org or > > >> osarchive.org where the 7.4GB rar file was helpful for getting a 5.1 > > >> contrib disc since the archive.org one is corrupt. So the binaries > > >> and source seem fairly well preserved for future explorers. > > > > > > Check again. The contrib image in the 7.4GB rar has the same hash as > > > the one on archive.org and elsewhere. I have no idea if the install > > > image is 100% correct. Hell, it's possible every image in that archive > > > and on archive.org is bad. I just don't know. > > > > > > So if anybody has any BSD/OS CDs please speak up. > > > > I have CDs of 2.0, 2.1 and 3.0. I had 1.x, but I can't put my hands > > on them right now. Maybe they were on QIC tape, in which case they're > > probably unrecoverable. I also have source trees for 4.0, 4.1 and the > > development version of 5.0 which I used to write the code for FreeBSD. > > > > What's the legal situation about distributing them? > > > No one is left to go after you for diing so. Wind river left bsdi support behind years ago.... > > But that's a slippery slope that depends on how you feel about ancient abandonware... > > 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 IANAL but a tiny bit of CYA can be added to the process by drafting a clear disclaimer that the materials are of currently-unknown copyright last known to be held by and that all questions of license to *use* the code for anything you cannot affirmatively answer. For instance with the disassemblies of old console games I produce, which I've found no EULA stating disassembly is verboten, I usually add something to the effect of: I am not in a position to provide licensing terms on this material I have preserved. I myself will not lay restrictions on what you can and can't do but I also do not have the authority to make any affirmative claims on the matter. Additionally making it clear in your distribution you are receptive to claims by proven copyright holders to C and D actions related to distribution shows good faith, if someone *does* take issue, hopefully they'll see that and contact you realizing you are interested in balancing preservation with respect to copyrights. I repeat though, I've not once set foot in the soul crushing environment that is the legal profession, so if you want to play an air tight game, consider retaining legal counsel. - Matt G. From tuhs at tuhs.org Sun Sep 8 11:30:54 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Sat, 7 Sep 2024 21:30:54 -0400 Subject: [TUHS] HP-UX In-Reply-To: <20240908000749.4264w7hbqdcaapnf@illithid> References: <20240908000749.4264w7hbqdcaapnf@illithid> Message-ID: On 9/7/24 8:07 PM, G. Branden Robinson wrote: > Yeah, but Carly Fiorina was _impactful_, man, Aye, Carly. -- ``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 lm at mcvoy.com Sun Sep 8 12:19:32 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 7 Sep 2024 19:19:32 -0700 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> Message-ID: <20240908021932.GC12369@mcvoy.com> On Sat, Sep 07, 2024 at 05:52:29PM -0600, Warner Losh wrote: > On Sat, Sep 7, 2024, 4:53???PM Greg 'groggy' Lehey wrote: > > > On Wednesday, 4 September 2024 at 4:49:47 -0400, Jim Carpenter wrote: > > > On Sun, Sep 1, 2024 at 3:33???AM Kevin Bowling > > wrote: > > >> Many of the BSD/OS versions have disc images on archive.org or > > >> osarchive.org where the 7.4GB rar file was helpful for getting a 5.1 > > >> contrib disc since the archive.org one is corrupt. So the binaries > > >> and source seem fairly well preserved for future explorers. > > > > > > Check again. The contrib image in the 7.4GB rar has the same hash as > > > the one on archive.org and elsewhere. I have no idea if the install > > > image is 100% correct. Hell, it's possible every image in that archive > > > and on archive.org is bad. I just don't know. > > > > > > So if anybody has any BSD/OS CDs please speak up. > > > > I have CDs of 2.0, 2.1 and 3.0. I had 1.x, but I can't put my hands > > on them right now. Maybe they were on QIC tape, in which case they're > > probably unrecoverable. I also have source trees for 4.0, 4.1 and the > > development version of 5.0 which I used to write the code for FreeBSD. > > > > What's the legal situation about distributing them? > > > > No one is left to go after you for diing so. Wind river left bsdi support > behind years ago.... My personal opinion on these old operating systems is don't set up a store and try make money from it and you are golden. Don't set up a website and say "Get Unix for free here". It's sort of like dirt where I live. Technically, you can't move more than 5 yards without a permit. Yet people do it all the time, they just don't advertise it. And no offense to the ancient Unix versions but I'm not sure anyone really wants them for anything other than history. Nor should they. I'm a SunOS guy, huge fan, it's where I learned how to be a kernel guy. Would I want to run that rather than Linux today? Oh, hell, no. Everything works on Linux, graphics, sound, video, email attachments, so much of that was a mess on SunOS and a bigger mess on other systems, including peers of SunOS. If there was value in BSD/OS the lawyers would come after you but there is no value other than history. From wobblygong at gmail.com Sun Sep 8 16:08:05 2024 From: wobblygong at gmail.com (Wesley Parish) Date: Sun, 8 Sep 2024 18:08:05 +1200 Subject: [TUHS] BSD/OS In-Reply-To: <20240908021932.GC12369@mcvoy.com> References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> <20240908021932.GC12369@mcvoy.com> Message-ID: <8aeaead8-7f79-4d5f-b132-1bd7753399dc@gmail.com> On 8/09/24 14:19, Larry McVoy wrote: > On Sat, Sep 07, 2024 at 05:52:29PM -0600, Warner Losh wrote: >> On Sat, Sep 7, 2024, 4:53???PM Greg 'groggy' Lehey wrote: >> >>> On Wednesday, 4 September 2024 at 4:49:47 -0400, Jim Carpenter wrote: >>>> On Sun, Sep 1, 2024 at 3:33???AM Kevin Bowling >>> wrote: >>>>> Many of the BSD/OS versions have disc images on archive.org or >>>>> osarchive.org where the 7.4GB rar file was helpful for getting a 5.1 >>>>> contrib disc since the archive.org one is corrupt. So the binaries >>>>> and source seem fairly well preserved for future explorers. >>>> Check again. The contrib image in the 7.4GB rar has the same hash as >>>> the one on archive.org and elsewhere. I have no idea if the install >>>> image is 100% correct. Hell, it's possible every image in that archive >>>> and on archive.org is bad. I just don't know. >>>> >>>> So if anybody has any BSD/OS CDs please speak up. >>> I have CDs of 2.0, 2.1 and 3.0. I had 1.x, but I can't put my hands >>> on them right now. Maybe they were on QIC tape, in which case they're >>> probably unrecoverable. I also have source trees for 4.0, 4.1 and the >>> development version of 5.0 which I used to write the code for FreeBSD. >>> >>> What's the legal situation about distributing them? >>> >> No one is left to go after you for diing so. Wind river left bsdi support >> behind years ago.... > My personal opinion on these old operating systems is don't set up a store > and try make money from it and you are golden. Don't set up a website and > say "Get Unix for free here". > > It's sort of like dirt where I live. Technically, you can't move more than > 5 yards without a permit. Yet people do it all the time, they just don't > advertise it. > > And no offense to the ancient Unix versions but I'm not sure anyone really > wants them for anything other than history. Nor should they. I'm a SunOS > guy, huge fan, it's where I learned how to be a kernel guy. Would I want > to run that rather than Linux today? Oh, hell, no. Everything works on > Linux, graphics, sound, video, email attachments, so much of that was a > mess on SunOS and a bigger mess on other systems, including peers of > SunOS. > > If there was value in BSD/OS the lawyers would come after you but there is > no value other than history. I wish there was some way we could get the remnants of the Unix(tm) companies together for long enough to sign something along the lines of the "Statement Regarding Research Unix Editions 8, 9, and 10" https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/ "Statement Regarding Research Unix Editions 8, 9, and 10 Alcatel-Lucent USA Inc. (“ALU-USA”), on behalf of itself and Nokia Bell Laboratories agrees, to the extent of its ability to do so, that it will not assert its copyright rights with respect to any non-commercial copying, distribution, performance, display or creation of derivative works of Research Unix®1 Editions 8, 9, and 10. The foregoing does not (i) transfer ownership of, or relinquish any, intellectual property rights (including patent rights) of Nokia Corporation, ALU-USA or any of their affiliates, (ii) grant a license to any patent, patent application, or trademark of Nokia Corporation, ALU-USA. or any of their affiliates, (iii) grant any third-party rights or licenses, or (iv) grant any rights for commercial purposes. Neither ALU-USA. nor Nokia Bell Laboratories will furnish or provided support for Research Unix Editions 8, 9, and 10, and make no warranties or representations hereunder, including but not limited to any warranty or representation that Research Unix Editions 8, 9, and 10 does not infringe any third party intellectual property rights or that Research Unix Editions 8, 9, and 10 is fit for any particular purpose." for their various versions of Unix that are no longer in development but still have historical interest for the rest of us. Wesley Parish From tom.perrine+tuhs at gmail.com Mon Sep 9 03:30:37 2024 From: tom.perrine+tuhs at gmail.com (Tom Perrine) Date: Sun, 8 Sep 2024 10:30:37 -0700 Subject: [TUHS] Bell Laboratories COBOL Syntax Checker? In-Reply-To: References: Message-ID: IIRC, this was related to the use of UNIX to prepare code for the GECOS (laterGCOS) mainframe that was also in use. After all that's where there was a GECOS field in the password file, to carry job/user related info as part of the batch submission. I wasn't at Bell, but I was at Honeywell in the late 70s/early 80s as a student intern. Strangely enough, one of the things I used was the COBOL68 (and later COBOL74) compiler for a student project for the Boy Scouts., Did you know that in the first release of the GCOS COBOL74 compiler - if you mis-spelled ENVIRONMENT in the ENVIRONMENT DIVISION statement, that the compiler would crash and coredump? It's the only reason I know how to spell "environment" to this very day. --tep On Sat, Sep 7, 2024 at 8:14 AM Marc Donner wrote: > Aside: by 1982 there was a COBOL compiler for the PC from Microsoft: > https://archive.org/details/ibmpccobol > > I bet it was cheaper than the COBOL "lint" you mention :-) > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Sat, Sep 7, 2024 at 12:50 AM segaloco via TUHS wrote: > >> So I was flipping through a System V software catalog from Fall 1984 and >> among >> the many AT&T Bell Laboratories items is the "COBOL Syntax Checker". >> >> From the text: >> >> ---QUOTE--- >> >> The COBOL Syntax Checker allows programmers to edit and check the syntax >> of COBOL >> programs before they are transmitted to mainframes for compilation and >> execution. >> The software increases the chances of a 'clean' compilation and execution >> and >> reduces the chance of a program being rejected due to syntax and simple >> semantic >> errors. As a result, expensive mainframe CPU time is reduced. >> >> The COBOL Syntax Checker processes a COBOL source program and produces >> three >> listings: >> >> 1. a diagnostic listing, >> >> 2. a cross-reference listing, >> >> 3. a source listing. >> >> ---END QUOTE--- >> >> There are two distributions listed, a C binary distribution for SVR2 for >> the >> 3B20 for $2000 and a C source distribution for SVR2 for the VAX 11/780 >> for $7500, >> both listed as released 2Q84. >> >> Some quick Googling only offers up additional catalog and magazine >> mentions. >> To me this sounds like a linter with some extra bits. Does anyone have >> any >> recollections of this software or know if there's much likelihood of the >> software >> itself or any documentation surviving? >> >> Thanks for any insights! >> >> - Matt G. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From als at thangorodrim.ch Mon Sep 9 05:02:29 2024 From: als at thangorodrim.ch (Alexander Schreiber) Date: Sun, 8 Sep 2024 21:02:29 +0200 Subject: [TUHS] HP-UX In-Reply-To: <20240908000749.4264w7hbqdcaapnf@illithid> References: <20240908000749.4264w7hbqdcaapnf@illithid> Message-ID: On Sat, Sep 07, 2024 at 07:07:49PM -0500, G. Branden Robinson wrote: > At 2024-09-07T22:30:24+0200, Alexander Schreiber wrote: > > And from reading between the lines, there seemed to be no love lost > > between the two sides at HP at the time ("old HP" and "Compaq > > acquisition"). > > Yeah, but Carly Fiorina was _impactful_, man, and that's the most > important thing you can be in this business. When it's a bad idea and > you do it anyway and tons of people complain, that just means you're > capable of making the Hard Choices(tm). Hard Choices (TM), impactful ... whatever, if in the end ones decisions as CEO aren't profitable for the company, what is one even paid the big bucks for? Any fool can run a company into the ground. I was herding HP-UX when Carly Fiorina was evicted from HP and we had the HP consultants (and our friendly HP field tech) on site at that time. They told us that the folks back in the HP offices were apparently literally dancing on the tables and singing "The witch is dead, the witch is dead!". Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison From ches at cheswick.com Mon Sep 9 06:14:54 2024 From: ches at cheswick.com (William Cheswick) Date: Sun, 8 Sep 2024 16:14:54 -0400 Subject: [TUHS] Bell Laboratories COBOL Syntax Checker? In-Reply-To: References: Message-ID: I only ran into COBOL once at the Labs. They called me in to do a security sanity check on the new WorldNet service. They had decided to transmit account data (I think) via FTP implemented in COBOL. I was stunned. But they had already made the decision and implemented it. I guess they got the syntax right. ches From jim at deitygraveyard.com Mon Sep 9 22:32:13 2024 From: jim at deitygraveyard.com (Jim Carpenter) Date: Mon, 9 Sep 2024 08:32:13 -0400 Subject: [TUHS] BSD/OS In-Reply-To: References: <20240831041216.2970318C089@mercury.lcs.mit.edu> <7d4f7119-c62b-4488-bc9a-60b51876056d@case.edu> Message-ID: On Sat, Sep 7, 2024 at 6:53 PM Greg 'groggy' Lehey wrote: > I have CDs of 2.0, 2.1 and 3.0. I had 1.x, but I can't put my hands > on them right now. Maybe they were on QIC tape, in which case they're > probably unrecoverable. I also have source trees for 4.0, 4.1 and the > development version of 5.0 which I used to write the code for FreeBSD. That's a good collection there. A generous list member has shared 1.0 with me. I have looked at the 5.1 Contrib CD. The "PACKAGES" directory has had its first block overwritten with a directory(?) block from HFS(?). Some sort of memory corruption happened. However, I've recovered every file. They are either short, readable text or gzipped tarballs with MD5 files. Everything checks out fine. I'll be creating a new iso and making it available. But assuming that most of the other BSD/OS images are from the same source, we can't trust that any are okay. :( > What's the legal situation about distributing them? Only some lawyer somewhere might someday be able to answer that to some extent. I'd be surprised if whoever the current IP owner is knows that they are. Jim From tuhs at tuhs.org Thu Sep 12 08:37:56 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 12 Sep 2024 08:37:56 +1000 Subject: [TUHS] Fwd: History tract during the next IWMP9 in Paris next May Message-ID: Hi all, Edouard asked me to pass this e-mail on to both TUHS and COFF lists. Cheers, Warren ----- Forwarded message from Edouard Klein ----- Subject: History tract during the next IWMP9 in Paris next May Date: Thu, 29 Aug 2024 22:46:30 +0200 (1 week, 4 days, 19 hours ago) Dear Unix history enthusiasts, The 11th International Workshop on Plan 9 will be held in Paris on May 22-24 2025. One of the focus area this year will be Plan 9's history and its influence on later computer science and industry trends. The history team at the CNAM (where the conference will be held) has agreed to help us prepare for the event and stands ready to record oral histories, or any other format that would make the participants happy. They had organized in 2017 a "colloque" at which Clem spoke (and I listened somewhere in the audience) on UNIX: https://technique-societe.cnam.fr/colloque-international-unix-en-europe-entre-innovation-diffusion-et-heritage-913008.kjsp I will keep the list posted as our efforts pan out, but I thought I'd get the word out as soon as possible. I you have historical resources on Plan 9 or Inferno, or are reminded of any interesting tidbits, you can also share them here, as this list is already recognized by historians as a legitimate source. The program committee members, many (if not all) of whom roam this very list, would welcome any proposal or contributions in this area :) The CfP is at: http://iwp9.org/ Looking forward to read what you care to share, or to seeing you in person in Paris, Cheers, Edouard. ----- End forwarded message ----- From lgrant at nevacross.com Thu Sep 12 09:40:22 2024 From: lgrant at nevacross.com (Lynn Grant) Date: Wed, 11 Sep 2024 17:40:22 -0600 Subject: [TUHS] Markdown Unix precursor Message-ID: Long before there was Markdown, there was a similar Unix tool. I remember reading about it before the Internet was popular, probably mid-to-late 1980s. I may have read about it in “Communications of the ACM”. It was designed to let secretaries compose memos, without learning the dot commands of troff or nroff. If you indented a space or two, it started a new paragraph. If you indented several spaces, it centered the line; very similar to Markdown in concept. It generated a file that could be fed into troff. I was thinking it might have been part of the System V Documentors Workbench, but I read through the doc for it and could not find anything like that. Does anyone remember this? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Sep 12 10:11:26 2024 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 11 Sep 2024 17:11:26 -0700 Subject: [TUHS] Markdown Unix precursor In-Reply-To: References: Message-ID: <20240912001126.GD12369@mcvoy.com> There was "more" on the Mac. Not sure if that is what you are talking about. I loved it, made a clone for making slide decks. On Wed, Sep 11, 2024 at 05:40:22PM -0600, Lynn Grant wrote: > Long before there was Markdown, there was a similar Unix tool. I remember > reading about it before the Internet was popular, probably mid-to-late > 1980s. I may have read about it in ???Communications of the ACM???. > > It was designed to let secretaries compose memos, without learning the dot > commands of troff or nroff. If you indented a space or two, it started a > new paragraph. If you indented several spaces, it centered the line; very > similar to Markdown in concept. It generated a file that could be fed into > troff. > > I was thinking it might have been part of the System V Documentors > Workbench, but I read through the doc for it and could not find anything > like that. > > Does anyone remember this? > > Thanks! -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From douglas.mcilroy at dartmouth.edu Fri Sep 13 10:26:03 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 12 Sep 2024 20:26:03 -0400 Subject: [TUHS] On computerese Message-ID: >> I've despaired over the term ever since it wormed its way into >> computer folks' vocabulary. How does a "use case" differ from a "use"? > > Clarity as to whether one is employing a noun or a verb. Both "use" and > "case" can be either (he said, casing the joint for tomorrow's heist), > but juxtaposing them thus unambiguously makes a noun phrase. Usually context makes the nominal use of "use" clear : "many uses", "the use", "some uses". I'm not persuaded that "use case" disambiguates any more reliably. How do supermarkets display their wares? For some use cases they use cases. Metacomment. While the "use" in "nominal use" above must be a noun, "nominal" isn't compelled to have the intended meaning of "being a noun". It's a game of whac-a-mot. Kill one ambiguity and spawn another. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther.johnson at makerlisp.com Fri Sep 13 11:01:14 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Thu, 12 Sep 2024 18:01:14 -0700 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: "use case" is a case of the use of both of the words "use" and "case", compounding (confounding ?) them, they specify the use of "case" to identify (and emphasize) a specific "use" (or set of uses), as distinct from other cases in which so much attention has not been paid to which uses they serve. I'm having fun with words here but, like test cases can be used to isolate (or mix) certain behaviors, use cases might be crafted as examples, for the purpose of distilling from them, clearer requirements. I think the requirements people were trying to borrow the style of language from the test people. But many times it's probably just jargon-y technical sounding buzz-wordery meant to make things seem more important than they are. On 09/12/2024 05:26 PM, Douglas McIlroy wrote: > >> I've despaired over the term ever since it wormed its way into > >> computer folks' vocabulary. How does a "use case" differ from a "use"? > > > > Clarity as to whether one is employing a noun or a verb. Both "use" and > > "case" can be either (he said, casing the joint for tomorrow's heist), > > but juxtaposing them thus unambiguously makes a noun phrase. > > Usually context makes the nominal use of "use" clear : "many uses", > "the use", > "some uses". I'm not persuaded that "use case" disambiguates any more > reliably. > > How do supermarkets display their wares? > For some use cases they use cases. > > Metacomment. While the "use" in "nominal use" above must be a noun, > "nominal" isn't compelled to have the intended meaning of "being a > noun". It's a game of whac-a-mot. Kill one ambiguity and spawn another. > > Doug From douglas.mcilroy at dartmouth.edu Fri Sep 13 12:16:32 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 12 Sep 2024 22:16:32 -0400 Subject: [TUHS] History tract during the next IWMP9 in Paris next May Message-ID: Two remarks about Plan 9, one about an antecedent and the other about the limits of its influence. "Communication files" in the Dartmouth Time Sharing System have been cited as a predecesssor of Unix pipes, although we at Bell Labs were unaware of the DTSS feature when pipes were first implemented. In fact, communication files more directly foreshadow Plan 9 than they do Unix. Unlike Unix processes, which need not be aware that they are talking to pipes, the process at one end of a communication file, designated as "master", must be aware that it is a communication file. The master end controls the semantics of reads, writes and seeks(!) issued at the other end. Because of this asymmetry, a communication file cannnot serve as a pipe between pairs of unprepared processes. A pipe could be simulated in DTSS by a master process that relays flow between communications files connected to arbitrary end processes, but that seems never to have been done. Communication files are a closer antecedent to Plan 9. A master process's controls correspond to the part of Plan 9's foundational 9P protocol that handles open files. Though I don't think there's an actual ancestral connection, this likeness strengthens DTSS's claim to fame and extends their lead to nearly a quarter century. Linux has adopted surface features of Plan 9 like union directories, append-only files and system data access via file interfaces. Meanwhile Plan 9's revolutionary realization of what Vic Vyssotsky called distributable computing has not caught on. In distributable computing, the physical location of processes does not affect their logical interaction. In today's distributed computing, though, there is a world of difference between how processes interact remotely and locally. When will the crevasse between the possible and the normal be bridged? Doug Having recently read about the playful literary consortium, Oulipo, I am reminded of their term for little-known antecedents of their revolutionary works: "anticipatory plagiarism". -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Sep 13 12:20:05 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 13 Sep 2024 02:20:05 +0000 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: <2SDilGVoKam0EoQYggA4JCn-YOlTpkgF9n-lntYGfFr5-PD3mm4k61SgKOPoOxfC03HZ-Pq8FAy-qw8qzkb1P9N1DVrElPXaDMRqbtd1uYI=@protonmail.com> On Thursday, September 12th, 2024 at 6:01 PM, Luther Johnson wrote: > "use case" is a case of the use of both of the words "use" and "case", > compounding (confounding ?) them, they specify the use of "case" to > identify (and emphasize) a specific "use" (or set of uses), as distinct > from other cases in which so much attention has not been paid to which > uses they serve. I'm having fun with words here but, like test cases can > be used to isolate (or mix) certain behaviors, use cases might be > crafted as examples, for the purpose of distilling from them, clearer > requirements. I think the requirements people were trying to borrow the > style of language from the test people. But many times it's probably > just jargon-y technical sounding buzz-wordery meant to make things seem > more important than they are. > > On 09/12/2024 05:26 PM, Douglas McIlroy wrote: > > > > > I've despaired over the term ever since it wormed its way into > > > > computer folks' vocabulary. How does a "use case" differ from a "use"? > > > > > > Clarity as to whether one is employing a noun or a verb. Both "use" and > > > "case" can be either (he said, casing the joint for tomorrow's heist), > > > but juxtaposing them thus unambiguously makes a noun phrase. > > > > Usually context makes the nominal use of "use" clear : "many uses", > > "the use", > > "some uses". I'm not persuaded that "use case" disambiguates any more > > reliably. > > > > How do supermarkets display their wares? > > For some use cases they use cases. > > > > Metacomment. While the "use" in "nominal use" above must be a noun, > > "nominal" isn't compelled to have the intended meaning of "being a > > noun". It's a game of whac-a-mot. Kill one ambiguity and spawn another. > > > > Doug I always assumed this was some old crusty project management term that predated modern technology but the Wikipedia sphere says it was coined in the late 80s by Ivar Jacobson of Ericsson in the context of requirements analysis. Apparently the original Swedish term is "användningsfall". I've got a coworker that likes to share "fun facts" every Friday...I might have to supplement that bit of our call tomorrow :) - Matt G. From tuhs at tuhs.org Fri Sep 13 14:03:34 2024 From: tuhs at tuhs.org (Eric E. Bowles via TUHS) Date: Fri, 13 Sep 2024 13:03:34 +0900 Subject: [TUHS] On computerese In-Reply-To: <2SDilGVoKam0EoQYggA4JCn-YOlTpkgF9n-lntYGfFr5-PD3mm4k61SgKOPoOxfC03HZ-Pq8FAy-qw8qzkb1P9N1DVrElPXaDMRqbtd1uYI=@protonmail.com> References: <2SDilGVoKam0EoQYggA4JCn-YOlTpkgF9n-lntYGfFr5-PD3mm4k61SgKOPoOxfC03HZ-Pq8FAy-qw8qzkb1P9N1DVrElPXaDMRqbtd1uYI=@protonmail.com> Message-ID: > I always assumed this was some old crusty project management term that predated modern technology but the Wikipedia sphere says it was coined in the late 80s by Ivar Jacobson of Ericsson in the context of requirements analysis. Apparently the original Swedish term is "användningsfall". I've got a coworker that likes to share "fun facts" every Friday...I might have to supplement that bit of our call tomorrow :) > > - Matt G. For reference, here's the relevant (and lengthy) Wikipedia entry: https://en.wikipedia.org/wiki/Use_case --eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Fri Sep 13 17:13:05 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 13 Sep 2024 02:13:05 -0500 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: <20240913071305.tx7ieyfcd7btduvf@illithid> At 2024-09-12T20:26:03-0400, Douglas McIlroy wrote: > >> I've despaired over the term ever since it wormed its way into > >> computer folks' vocabulary. How does a "use case" differ from a > >> "use"? For TUHS readers curious about the start of this thread, it's here: https://lists.gnu.org/archive/html/groff/2024-09/msg00040.html 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 will.senn at gmail.com Fri Sep 13 23:57:10 2024 From: will.senn at gmail.com (Will Senn) Date: Fri, 13 Sep 2024 08:57:10 -0500 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: <30be769e-cf1c-46c5-b2a2-ae6b0b730da1@gmail.com> On 9/12/24, Douglas McIlroy wrote: > There it festered, right in the middle of Branden's otherwise high > literary > style: "use cases". I've despaired over the term ever since it wormed its > way into computer folks' vocabulary. How does a "use case" differ from a > "use"? Or, what's the use of "use case"? > > And while I'm despairing, "concatenate" rolls on, undeterred by Research's > campaign for concision. We determinedly excised the word from the seventh > edition. The man page header for cat(1) read "catenate and print". Posix > added content on both ends, making "concatenate and print files". Gnu > puffed it up further to "concatenate files and print on the standard > output". > >  It's not as if the seventh edition was storming the gates of English. > According to the OED, "catenate" and "concatenate" are synonyms of long > standing that entered the language almost simultaneously. Why pick the > flabby one over its brisk--and more mnemonic--rival? > > Doug > Just gotta say, I completely agree with this sentiment as regards catenate. Also, I've never been sold on use-case, either. If I remember, it was Jacobson who popularized the term. Maybe use-case was contrived to provide some further distinction from the uses connection... as in the use-case: Validate Password uses Enter Password... Personally, I think a use is fine and it doesn't matter much that in a use, an actor uses a function...but hey, technical fields are well known and loved for using language in perfectly unreasonable ways. Technical language is used, ostensibly, to disambiguate, but more often than not it obscures and alienates. In my classes, I spend a lot of effort breaking things down into simple terms while pointing out the use of jargon and the importance of nailing it for the chosen profession - likening it to a cult of technicality. Big fan of KISS here :). Terms should mean what they say so professionals can say what they mean... clearly and with as little ambiguity as is reasonable, that is, language affords a great deal of redundancy and we should not be afraid to leverage this tool as well - leave the hunt for perfect disambiguation to the mathematicians. - will From ake.nordin at netia.se Sat Sep 14 02:05:45 2024 From: ake.nordin at netia.se (=?UTF-8?Q?=C3=85ke_Nordin?=) Date: Fri, 13 Sep 2024 18:05:45 +0200 Subject: [TUHS] On computerese In-Reply-To: References: <2SDilGVoKam0EoQYggA4JCn-YOlTpkgF9n-lntYGfFr5-PD3mm4k61SgKOPoOxfC03HZ-Pq8FAy-qw8qzkb1P9N1DVrElPXaDMRqbtd1uYI=@protonmail.com> Message-ID: <204ab462-9ad1-4e46-a971-e7be2f8239ad@netia.se> On 2024-09-13 06:03, Eric E. Bowles via TUHS wrote: >> I always assumed this was some old crusty project management term that predated modern technology but the Wikipedia sphere says it was coined in the late 80s by Ivar Jacobson of Ericsson in the context of requirements analysis.  Apparently the original Swedish term is "användningsfall".  I've got a coworker that likes to share "fun facts" every Friday...I might have to supplement that bit of our call tomorrow :) >> - Matt G. > For reference, here's the relevant (and lengthy) Wikipedia entry: > https://en.wikipedia.org/wiki/Use_case Ericsson corrupting the use of English words is not news to me, as I've had some exposure to various Ericsson operations at that time (and onwards). It can be noted that they were deep into the process of replacing Swedish with English everywhere, in documentation and (internal as well as external) communication. To this end, and to alleviate the pains of most senior execs (many of who were of a generation where German, not English, was the first foreign language studied in primary schools), Ericsson invented some rather Pidginesque internal variety of English that actually was branded "Ericsson English." It wouldn't surprise me if "Användningsfall" (which is a term in Ericsson "PROPS" process management methodology) was translated to "use case" there already before Jacobson used it in his documentation. It's no surprise that "Ericsson English" basically was Swedish with word-for-word replacements. This abomination was surprisingly usable, probably because they're both Germanic languages who were mutually intelligible until maybe 1000 years ago. MfG, -- Åke Nordin , resident Net/Lunix/telecom geek. Netia Data AB, Stockholm SWEDEN *46#7O466OI99# From athornton at gmail.com Sat Sep 14 02:12:40 2024 From: athornton at gmail.com (Adam Thornton) Date: Fri, 13 Sep 2024 09:12:40 -0700 Subject: [TUHS] On computerese In-Reply-To: <30be769e-cf1c-46c5-b2a2-ae6b0b730da1@gmail.com> References: <30be769e-cf1c-46c5-b2a2-ae6b0b730da1@gmail.com> Message-ID: On Fri, Sep 13, 2024 at 7:06 AM Will Senn wrote: > Big fan of KISS here > Yeah, _Destroyer_ is a great album. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sat Sep 14 08:56:04 2024 From: will.senn at gmail.com (Will Senn) Date: Fri, 13 Sep 2024 17:56:04 -0500 Subject: [TUHS] On computerese In-Reply-To: References: <30be769e-cf1c-46c5-b2a2-ae6b0b730da1@gmail.com> Message-ID: Nice. KISS is underrated :). On 9/13/24 11:12, Adam Thornton wrote: > > > On Fri, Sep 13, 2024 at 7:06 AM Will Senn wrote: > > Big fan of KISS here > > > Yeah, _Destroyer_ is a great album. > > Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Sun Sep 15 08:09:00 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 14 Sep 2024 18:09:00 -0400 Subject: [TUHS] Edison Design Group C Front End In-Reply-To: References: <994174b0-0d1e-4620-2c01-0a78a3f0f61f@makerlisp.com> Message-ID: On Tue, 13 Aug 2024 at 17:11, Luther Johnson wrote: > ... of course it is serialized, there has to be some convention on > writing a tree out in some order to a file ... well anyway I'm sure they > can tell you what that product is and does. > Just wanted to follow up to provide what I've learned, in case it will be helpful for someone else at some point. I contacted EDG and the impression I got is that they don't have readily available documentation for products so old. They were able to provide me with the manual for the current C++ front end as a starting point for my investigation. Most of what I've learned has come from a combination of intuition and knowledge from other utilities, combined with a healthy dose of brute force. EDG were not able to provide any insight on their relationship with SGI specifically, which I suppose is not unexpected given the amount of time that has passed and the vagaries of corporate agreements, though they did indicate that in some areas EDG and SGI were competitors in that time frame (early '90s). That's why I found SGI's inclusion of the tool so fascinating. It's just an odd historical artifact, especially as it is not useful for reasonably complex code. Here's the boring part, what I've been able to gather of the command options to /usr/lib/ecfe. Any single character not listed is not a valid option: -d[1-5] : debug, level, this can be extremely verbose even at low levels -i(file): not sure, wants a file as input but isn't a single-file include -n: don't actually do anything? Doesn't produce an output file that I can see, no output to stdout/stderr -r: "remarks?" does create output file but is no different than without for hello.c -s: forces signed chars -u: forces unsigned chars -v does what you would think, prints version info -w does what you would think, suppresses warnings -A: ANSI C extensions of some nature -C: not sure, possibly C dialect related -D(name): does what you would expect from a preprocessor, define -E: output to stdout, like a preprocessor, doesn't actually apply any transformations? -H: outputs what headers are being included -I(path): does what you would expect from a preprocessor -K: K&R, does not define __STDC__ which it looks like we are defining normally -L(file): "raw output listing", interesting output format with first column meaning something -M: makefile dependencies like you would expect, to stdout -P: "preprocessing only", not sure how this is different from -E -S(file): no idea, produces a blank file -U: does what you would expect from a preprocessor, undef -X: ??? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Sun Sep 15 12:06:48 2024 From: ggm at algebras.org (George Michaelson) Date: Sun, 15 Sep 2024 12:06:48 +1000 Subject: [TUHS] Working at Bell Labs: photos by Larry Luckham, 1967 Message-ID: Forgive me if these predate the glory days, found them interesting https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Sun Sep 15 12:33:22 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 14 Sep 2024 22:33:22 -0400 Subject: [TUHS] Working at Bell Labs: photos by Larry Luckham, 1967 In-Reply-To: References: Message-ID: On Sat, 14 Sept 2024 at 22:16, George Michaelson wrote: > Forgive me if these predate the glory days, found them interesting > > https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs > I grew up as the son of a Bell Labs employee and knew several other adults who worked there, so I find these sorts of things really fun to see. I wonder which location this was - I did a little bit of clicking around but the author doesn't seem to specify that anywhere. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.martin.yardley at gmail.com Sun Sep 15 12:33:31 2024 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Sun, 15 Sep 2024 12:33:31 +1000 Subject: [TUHS] Working at Bell Labs: photos by Larry Luckham, 1967 In-Reply-To: References: Message-ID: <735B26C9-C93E-46DB-9A38-3E2CE9E296E0@gmail.com> Where I used to work we had a few of those oscilloscopes, picture right side middle. On those trolleys too. I remember that they were Tektronix, I looked them up and I think they were a model 547 (which rings a bell) https://w140.com/tekwiki/wiki/547. > On 15 Sep 2024, at 12:06 PM, George Michaelson wrote: > > Forgive me if these predate the glory days, found them interesting > > https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From athornton at gmail.com Sun Sep 15 12:34:45 2024 From: athornton at gmail.com (Adam Thornton) Date: Sat, 14 Sep 2024 19:34:45 -0700 Subject: [TUHS] Working at Bell Labs: photos by Larry Luckham, 1967 In-Reply-To: References: Message-ID: Man, that one dude's hair and sideburns...unless he's trying to do Planet Of The Apes cosplay... On Sat, Sep 14, 2024 at 7:16 PM George Michaelson wrote: > Forgive me if these predate the glory days, found them interesting > > https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sun Sep 15 12:38:42 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 14 Sep 2024 22:38:42 -0400 Subject: [TUHS] Working at Bell Labs: photos by Larry Luckham, 1967 Message-ID: > https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs Luckham's introductory remark that all the programmers were men contrasts with the situation 10 years before, when most of the programmers were women. Women got shoved aside when it became apparent that programming was an honorable and challenging engineering profession, not mere routine translation of conceptual designd into machine language. It took almost 10 more years for the Labs to recognize that women programmers were engineers, too. Yet de jure recognition of women programmers has not yet become de facto. Here at Dartmouth, as at many schools, women form a far smaller fraction of computer science than they do of the engineering school. In engineering the proportion of women reflects that in the general population. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Sun Sep 15 12:48:06 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 14 Sep 2024 22:48:06 -0400 Subject: [TUHS] Working at Bell Labs: photos by Larry Luckham, 1967 In-Reply-To: <735B26C9-C93E-46DB-9A38-3E2CE9E296E0@gmail.com> References: <735B26C9-C93E-46DB-9A38-3E2CE9E296E0@gmail.com> Message-ID: On Sat, 14 Sept 2024 at 22:41, Peter Yardley wrote: > Where I used to work we had a few of those oscilloscopes, picture right > side middle. On those trolleys too. I remember that they were Tektronix, I > looked them up and I think they were a model 547 (which rings a bell) > https://w140.com/tekwiki/wiki/547. > One time as a fairly young child I was sick and for some reason my mother couldn't stay home with me, so I was sent to work with my father at the Labs. Not really knowing how else to entertain a small child in that workplace, I was placed in front of a cart with an oscilloscope and a function generator, which provided hours of entertainment. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Sun Sep 15 12:59:13 2024 From: pugs78 at gmail.com (Tom Lyon) Date: Sat, 14 Sep 2024 19:59:13 -0700 Subject: [TUHS] Working at Bell Labs: photos by Larry Luckham, 1967 In-Reply-To: References: Message-ID: I'm guessing this was Holmdel - they were deep into IBM stuff. There's these 1973 videos about the Holmdel IBM computing center. https://www.youtube.com/watch?v=HMYiktO0D64&t=6s https://www.youtube.com/watch?v=V9aVOIuKVUc&t=231s In summer of 1973, I was a high school snot attending an NSF program at Stevens Institute, but my brother Dick was a summer intern at Holmdel. I visited him and made a trek across all 6 floors of all 4 buildings and counted about 100 PDP-11 systems! (based on peeking in the always-open lab doors and looking for purple and red) I knew nothing about UNIX at the time, so no idea how many UNIces there were. On Sat, Sep 14, 2024 at 7:33 PM Henry Bent wrote: > On Sat, 14 Sept 2024 at 22:16, George Michaelson wrote: > >> Forgive me if these predate the glory days, found them interesting >> >> https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs >> > > I grew up as the son of a Bell Labs employee and knew several other adults > who worked there, so I find these sorts of things really fun to see. I > wonder which location this was - I did a little bit of clicking around but > the author doesn't seem to specify that anywhere. > > -Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Sun Sep 15 14:14:56 2024 From: ggm at algebras.org (George Michaelson) Date: Sun, 15 Sep 2024 14:14:56 +1000 Subject: [TUHS] Working at Bell Labs: photos by Larry Luckham, 1967 In-Reply-To: References: Message-ID: True, and distressingly so. I moved from a tech role into comms and its more equitable. I didn't foresee the imbalance, and I had hoped it was passing through but it feels like either not, or not within my working lifetime. G -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Mon Sep 16 00:37:29 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 15 Sep 2024 10:37:29 -0400 Subject: [TUHS] On computerese Message-ID: > Who created the "cat" command and did they have the > word "catenate" or "concatenate" in their heads? Ken Thompson wrote "cat" for the PDP-7, with "concatenate" in mind. The cat(1) page in the v1 manual is titled, "concatenate (or print) files". Only later did someone in Research--I don't know who--remark on the existence of the shorter synonym. It was deliberately adopted in v7, perhaps because it better mirrored the command name. But brevity is the defensible argument for "catenate", while familiarity boosts "concatenate". It stll takes some conscious effort for me to use the former, However, I sense sinister vibes in "concatenate", driven by the phrase "concatenation of events", which often is used to explain misfortune. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From rik at rikfarrow.com Mon Sep 16 05:21:18 2024 From: rik at rikfarrow.com (Rik Farrow) Date: Sun, 15 Sep 2024 12:21:18 -0700 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: Was the brevity typical of Unix command names a function of the tiny disk and memory available? Or more a function of having a Teletype 33 for input? Of course, it could simply be that 'cat' is more convenient than 'catenate'... Rik On Sun, Sep 15, 2024 at 7:38 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > Who created the "cat" command and did they have the > > word "catenate" or "concatenate" in their heads? > > Ken Thompson wrote "cat" for the PDP-7, with "concatenate" in > mind. The cat(1) page in the v1 manual is titled, "concatenate (or > print) files". Only later did someone in Research--I don't know > who--remark on the existence of the shorter synonym. It was > deliberately adopted in v7, perhaps because it better mirrored > the command name. > > But brevity is the defensible argument for "catenate", while > familiarity boosts "concatenate". It stll takes some conscious > effort for me to use the former, However, I sense sinister > vibes in "concatenate", driven by the phrase "concatenation > of events", which often is used to explain misfortune. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Sep 16 05:25:38 2024 From: tuhs at tuhs.org (John Dow via TUHS) Date: Sun, 15 Sep 2024 20:25:38 +0100 Subject: [TUHS] On computerese Message-ID: <463666F9-62FF-4D3F-8F06-24F836F7D311@me.com>  > On 15 Sep 2024, at 20:21, Rik Farrow wrote: >  > Was the brevity typical of Unix command names a function of the tiny disk and memory available? Or more a function of having a Teletype 33 for input? Of course, it could simply be that 'cat' is more convenient than 'catenate'... Hangover from assembly mnemonics, perhaps. J — John Dow Written by a human. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Mon Sep 16 05:36:19 2024 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 15 Sep 2024 19:36:19 +0000 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: Before I got hooked on UNIX in 1977, I used a Univac Exec8 system. You “cataloged” (created) a file with the @CAT command. Other, file operations were done by the File Utility Routine/Program Utility Routine: FURPUR (sort of like pip on steroids). I decided that if I ever got a CAT, it would be named FURPUR. That happened when I was working for Rutgers. Not having any UNIVACs around, the name escaped notice until the EE department hired a guy from the University of Maryland who says “You have a cat named FURPUR?” -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Mon Sep 16 05:52:13 2024 From: halbert at halwitz.org (Dan Halbert) Date: Sun, 15 Sep 2024 15:52:13 -0400 Subject: [TUHS] On computerese In-Reply-To: <463666F9-62FF-4D3F-8F06-24F836F7D311@me.com> References: <463666F9-62FF-4D3F-8F06-24F836F7D311@me.com> Message-ID: <9c07cf6f-7df0-4d18-bdf8-1a8b991ead29@halwitz.org> On 9/15/24 15:25, John Dow via TUHS wrote: >  >> On 15 Sep 2024, at 20:21, Rik Farrow wrote: >> >>  >> Was the brevity typical of Unix command names a function of the tiny >> disk and memory available? Or more a function of having a Teletype 33 >> for input? Of course, it could simply be that 'cat' is more >> convenient than 'catenate'... >> > > Hangover from assembly mnemonics, perhaps. > Multics had long names and short names for many commands. `ls` was the short name for `list`, for instance. See "additional names" in https://multicians.org/mga.html. Dan H (original author of the `more` command`, considered to be a long name by some and short by others! https://danhalbert.org/more.html) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Mon Sep 16 06:43:08 2024 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Mon, 16 Sep 2024 06:43:08 +1000 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: Early on, here in Faraway Land, I was told Unix command naming rules were these: however can’t recall seeing it written: 2-7 chars - ie. short + reserved single chars for personal use lower case non-dictionary words - allowing 3rd party software a clear run Of course, “sort” fails those rules :) BSD didn’t use those rules (backup & restore). For non touch typists, shorter commands & keywords are helpful. > On 16 Sep 2024, at 05:21, Rik Farrow wrote: > > Was the brevity typical of Unix command names a function of the tiny disk and memory available? Or more a function of having a Teletype 33 for input? Of course, it could simply be that 'cat' is more convenient than 'catenate'... > > Rik > -- 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 dave at horsfall.org Mon Sep 16 06:48:49 2024 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 16 Sep 2024 06:48:49 +1000 (AEST) Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024, sjenkin at canb.auug.org.au wrote: > BSD didn’t use those rules (backup & restore). dump/restor (no "e"), as I recall? -- Dave From marc.donner at gmail.com Mon Sep 16 07:08:36 2024 From: marc.donner at gmail.com (Marc Donner) Date: Sun, 15 Sep 2024 17:08:36 -0400 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: eh? On Sun, Sep 15, 2024, 16:48 Dave Horsfall wrote: > On Mon, 16 Sep 2024, sjenkin at canb.auug.org.au wrote: > > > BSD didn’t use those rules (backup & restore). > > dump/restor (no "e"), as I recall? > > -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Sep 16 07:41:14 2024 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 16 Sep 2024 07:41:14 +1000 (AEST) Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: <7014aed3-3b78-1465-9edb-8cff83c7eb9d@horsfall.org> [ Undoing top-posting ] On Sun, 15 Sep 2024, Marc Donner wrote: > > BSD didn’t use those rules (backup & restore). > > dump/restor (no "e"), as I recall? > > eh? What needs to be clarified? -- Dave From jnc at mercury.lcs.mit.edu Mon Sep 16 07:48:47 2024 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 15 Sep 2024 17:48:47 -0400 (EDT) Subject: [TUHS] On computerese Message-ID: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> > From: Rik Farrow > Was the brevity typical of Unix command names a function of the tiny > disk and memory available? Or more a function of having a Teletype 33 > for input? I'm not sure the answer was ever written down (e.g. in a memo); we will probably have to rely on memory - and memories that far back are now fairly thin on the ground by now. Perhaps Mr. McIlroy (or Mr. Thompson, if we're _really_ lucky) will humor us? :-) I have the impression that some of the names are _possibly_ inherited from Multics (which the early Unicians all used before Unix existed) - but maybe not. The command to list a directory, on Multics, is 'ls' (but see below) - but the Multics qcommand to remove a file is 'del' (not 'rm'); and change working directory is 'cwd'. So maybe ls' is just chance? Multics had a 'feature' where a segment (file) could have additional names (to the main name), and this is used to add short aliases to many commands, so the 'base name'' for the directory list command is 'list'; 'ls' is a short alias. A list of Multics commands (with short forms) is available here: https://www.multicians.org/multics-commands.html I'm not sure how early that alias mechanism came in, though; my copy of "Introduction to Multics" (February, 1974) doesn't have short names (or, at least, it doesn't use them). It won't have anything to do with disk and memory. Having used a Teletype, it would take noticeably longer to type in a longer name! It's also more effort and time. I would expect those are the reasons for the short names. Noel From tuhs at tuhs.org Mon Sep 16 08:01:38 2024 From: tuhs at tuhs.org (=?utf-8?b?UGV0ZXIgV2VpbmJlcmdlciAo5rip5Y2a5qC8KSB2aWEgVFVIUw==?=) Date: Sun, 15 Sep 2024 18:01:38 -0400 Subject: [TUHS] On computerese In-Reply-To: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> Message-ID: i doubt there is a fully satisfactory answer. dd was a jab at IBM JCL. Several later commands were derived from earlier ones, like sed and tar. And awk ... I think the one that needs more explaining is grep. If brevity were the sole criterion, it could have been shorter. On Sun, Sep 15, 2024 at 5:49 PM Noel Chiappa wrote: > > > From: Rik Farrow > > > Was the brevity typical of Unix command names a function of the tiny > > disk and memory available? Or more a function of having a Teletype 33 > > for input? > > I'm not sure the answer was ever written down (e.g. in a memo); we will > probably have to rely on memory - and memories that far back are now fairly > thin on the ground by now. Perhaps Mr. McIlroy (or Mr. Thompson, if we're > _really_ lucky) will humor us? :-) > > > I have the impression that some of the names are _possibly_ inherited from > Multics (which the early Unicians all used before Unix existed) - but maybe > not. The command to list a directory, on Multics, is 'ls' (but see below) - > but the Multics qcommand to remove a file is 'del' (not 'rm'); and change working > directory is 'cwd'. So maybe ls' is just chance? > > Multics had a 'feature' where a segment (file) could have additional names (to > the main name), and this is used to add short aliases to many commands, so the > 'base name'' for the directory list command is 'list'; 'ls' is a short > alias. A list of Multics commands (with short forms) is available here: > > https://www.multicians.org/multics-commands.html > > I'm not sure how early that alias mechanism came in, though; my copy of > "Introduction to Multics" (February, 1974) doesn't have short names (or, at > least, it doesn't use them). > > > It won't have anything to do with disk and memory. Having used a Teletype, it > would take noticeably longer to type in a longer name! It's also more effort > and time. I would expect those are the reasons for the short names. > > Noel From robpike at gmail.com Mon Sep 16 08:15:34 2024 From: robpike at gmail.com (Rob Pike) Date: Mon, 16 Sep 2024 08:15:34 +1000 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> Message-ID: For me the fascinating thing about dd is that people tended to use the JCL notation for its arguments even after the Unix style was made available. That is, people prefer "dd if=foo" rather than "dd -if foo" or even the obviously easiest "dd wrote: > i doubt there is a fully satisfactory answer. dd was a jab at IBM JCL. > Several later commands were derived from earlier ones, like sed and > tar. And awk ... > > I think the one that needs more explaining is grep. If brevity were > the sole criterion, it could have been shorter. > > On Sun, Sep 15, 2024 at 5:49 PM Noel Chiappa > wrote: > > > > > From: Rik Farrow > > > > > Was the brevity typical of Unix command names a function of the > tiny > > > disk and memory available? Or more a function of having a Teletype > 33 > > > for input? > > > > I'm not sure the answer was ever written down (e.g. in a memo); we will > > probably have to rely on memory - and memories that far back are now > fairly > > thin on the ground by now. Perhaps Mr. McIlroy (or Mr. Thompson, if we're > > _really_ lucky) will humor us? :-) > > > > > > I have the impression that some of the names are _possibly_ inherited > from > > Multics (which the early Unicians all used before Unix existed) - but > maybe > > not. The command to list a directory, on Multics, is 'ls' (but see > below) - > > but the Multics qcommand to remove a file is 'del' (not 'rm'); and > change working > > directory is 'cwd'. So maybe ls' is just chance? > > > > Multics had a 'feature' where a segment (file) could have additional > names (to > > the main name), and this is used to add short aliases to many commands, > so the > > 'base name'' for the directory list command is 'list'; 'ls' is a short > > alias. A list of Multics commands (with short forms) is available here: > > > > https://www.multicians.org/multics-commands.html > > > > I'm not sure how early that alias mechanism came in, though; my copy of > > "Introduction to Multics" (February, 1974) doesn't have short names (or, > at > > least, it doesn't use them). > > > > > > It won't have anything to do with disk and memory. Having used a > Teletype, it > > would take noticeably longer to type in a longer name! It's also more > effort > > and time. I would expect those are the reasons for the short names. > > > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Sep 16 08:29:21 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 15 Sep 2024 15:29:21 -0700 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> Message-ID: <20240915222921.GM29162@mcvoy.com> On Mon, Sep 16, 2024 at 08:15:34AM +1000, Rob Pike wrote: > For me the fascinating thing about dd is that people tended to use the JCL > notation for its arguments even after the Unix style was made available. > That is, people prefer "dd if=foo" rather than "dd -if foo" or even the > obviously easiest "dd References: <7014aed3-3b78-1465-9edb-8cff83c7eb9d@horsfall.org> Message-ID: Sorry, my 'eh?' was an ironic reference to the cryptic error messages from ed. ===== nygeek.net mindthegapdialogs.com/home On Sun, Sep 15, 2024 at 5:41 PM Dave Horsfall wrote: > [ Undoing top-posting ] > > On Sun, 15 Sep 2024, Marc Donner wrote: > > > > BSD didn’t use those rules (backup & restore). > > > > dump/restor (no "e"), as I recall? > > > > eh? > > What needs to be clarified? > > -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Sep 16 13:02:50 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 15 Sep 2024 21:02:50 -0600 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> Message-ID: <202409160302.48G32o9G073841@freefriends.org> Peter Weinberger (温博格) via TUHS wrote: > I think the one that needs more explaining is grep. If brevity were > the sole criterion, it could have been shorter. First, it was mnemonic for the ed(1) syntax g/re/p, and second have a vowel in it (instead of calling it grp) made it easily pronounceable. I also suspect that at this point we're overthinking it. :-) Arnold From arnold at skeeve.com Mon Sep 16 13:10:26 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 15 Sep 2024 21:10:26 -0600 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: <202409160310.48G3AQb5074340@freefriends.org> Douglas McIlroy wrote: > But brevity is the defensible argument for "catenate", while > familiarity boosts "concatenate". I suspect that only "highly educated east-coasters" are familiar with "catenate." My education was pretty good, but catenate, for all it's advantages of brevity and similar age to "concatenate" is simply never used in modern-day American English. I'd never heard it until, like just about all the rest of us, I came across it in the Unix manual. My $.02, Arnold From ggm at algebras.org Mon Sep 16 13:30:06 2024 From: ggm at algebras.org (George Michaelson) Date: Mon, 16 Sep 2024 13:30:06 +1000 Subject: [TUHS] On computerese In-Reply-To: <202409160310.48G3AQb5074340@freefriends.org> References: <202409160310.48G3AQb5074340@freefriends.org> Message-ID: cat is capable of endless discussion. cat thing | cat otherthing doesn't do what (some) people think. cat thing | cat otherthing /dev/stdin does, but there's an ordering point to be made. cat thing | cat < otherthing /dev/stdin makes the ordering point. and the number of lines seen. the role of the shell in marshalling the IO and determining what is opened, when, truncated is another pitfall that seems to escape people. "I thought the commands ran left to right" when your first command < something and your final command > something like others, my use of cat is reflexive. I know perfectly well I could solve the whole problem in awk or sed, I still construct sequences to use sed to edit the lines, and awk to extract the fields in LSWP denoted counts. we're speaking english and say "comme ci comme ca" and nobody blinks, it's the same in shell. codeswitching! From athornton at gmail.com Mon Sep 16 13:55:39 2024 From: athornton at gmail.com (Adam Thornton) Date: Sun, 15 Sep 2024 20:55:39 -0700 Subject: [TUHS] On computerese In-Reply-To: <20240915222921.GM29162@mcvoy.com> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <20240915222921.GM29162@mcvoy.com> Message-ID: You know, this is a place that might actually be able to provide a definitive answer to me. A brief web search found me asking the same question in 1995. When I were a wee lad, I was told `dd` was short for `do DEBE`, which, while obviously referencing a well-known movie about a Northern Texas sports team and their most enthusiastic fan, also referred to the mainframe software whose name was an acronym for `Does Everything But Eat` and whose function was to copy data across sources with very different blocking and representation conventions...which is kinda what `dd` does. Can anyone here confirm or deny that origin for the utility's name? Adam On Sun, Sep 15, 2024 at 3:36 PM Larry McVoy wrote: > On Mon, Sep 16, 2024 at 08:15:34AM +1000, Rob Pike wrote: > > For me the fascinating thing about dd is that people tended to use the > JCL > > notation for its arguments even after the Unix style was made available. > > That is, people prefer "dd if=foo" rather than "dd -if foo" or even the > > obviously easiest "dd > Muscle memory. dd is weird but you sort of get used to it and then just > do it how you always have. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Mon Sep 16 14:17:08 2024 From: robpike at gmail.com (Rob Pike) Date: Mon, 16 Sep 2024 14:17:08 +1000 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <20240915222921.GM29162@mcvoy.com> Message-ID: I was told it's IBMese: Define Dataset. -rob On Mon, Sep 16, 2024 at 2:01 PM Adam Thornton wrote: > You know, this is a place that might actually be able to provide a > definitive answer to me. A brief web search found me asking the same > question in 1995. > > When I were a wee lad, I was told `dd` was short for `do DEBE`, which, > while obviously referencing a well-known movie about a Northern Texas > sports team and their most enthusiastic fan, also referred to the mainframe > software whose name was an acronym for `Does Everything But Eat` and whose > function was to copy data across sources with very different blocking and > representation conventions...which is kinda what `dd` does. > > Can anyone here confirm or deny that origin for the utility's name? > > Adam > > On Sun, Sep 15, 2024 at 3:36 PM Larry McVoy wrote: > >> On Mon, Sep 16, 2024 at 08:15:34AM +1000, Rob Pike wrote: >> > For me the fascinating thing about dd is that people tended to use the >> JCL >> > notation for its arguments even after the Unix style was made available. >> > That is, people prefer "dd if=foo" rather than "dd -if foo" or even the >> > obviously easiest "dd > >> Muscle memory. dd is weird but you sort of get used to it and then just >> do it how you always have. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Mon Sep 16 15:06:29 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 16 Sep 2024 01:06:29 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <20240915222921.GM29162@mcvoy.com> Message-ID: On Mon, 16 Sept 2024 at 00:11, Adam Thornton wrote: > You know, this is a place that might actually be able to provide a > definitive answer to me. A brief web search found me asking the same > question in 1995. > > When I were a wee lad, I was told `dd` was short for `do DEBE`, which, > while obviously referencing a well-known movie about a Northern Texas > sports team and their most enthusiastic fan, also referred to the mainframe > software whose name was an acronym for `Does Everything But Eat` and whose > function was to copy data across sources with very different blocking and > representation conventions...which is kinda what `dd` does. > > Can anyone here confirm or deny that origin for the utility's name? > > I looked through a broad swath of dd source files and man pages from v5 to System III and SVR4, the BSD SCCS tree, various commercial UNIXes, modern BSDs, and modern Linux but none of them have any sort of explanation of the name. I figured I'd at least find something! It is the case that many places refer to the command's function as "convert and copy," so I wonder if it's some sort of play on the fact that the expected name of the command might be "cc". -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Sep 16 15:15:46 2024 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 16 Sep 2024 15:15:46 +1000 (AEST) Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <20240915222921.GM29162@mcvoy.com> Message-ID: <8cd8fbf2-5529-966f-19d1-64e1d4fd9555@horsfall.org> On Mon, 16 Sep 2024, Rob Pike wrote: [ The origin of the "dd" command ] > I was told it's IBMese: Define Dataset. Straight from IBM's JCL (Job Control Language); heck, I still remember obscure things like "DISP=(,KEEP)" etc... -- Dave From pugs78 at gmail.com Mon Sep 16 15:26:44 2024 From: pugs78 at gmail.com (Tom Lyon) Date: Sun, 15 Sep 2024 22:26:44 -0700 Subject: [TUHS] On computerese In-Reply-To: <8cd8fbf2-5529-966f-19d1-64e1d4fd9555@horsfall.org> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <20240915222921.GM29162@mcvoy.com> <8cd8fbf2-5529-966f-19d1-64e1d4fd9555@horsfall.org> Message-ID: According to GC28-6704-1, IBM System/360 Operating System: Job Control Language Reference, DD means "Data Definition". Bitsavers knows all. On Sun, Sep 15, 2024 at 10:15 PM Dave Horsfall wrote: > On Mon, 16 Sep 2024, Rob Pike wrote: > > [ The origin of the "dd" command ] > > > I was told it's IBMese: Define Dataset. > > Straight from IBM's JCL (Job Control Language); heck, I still remember > obscure things like "DISP=(,KEEP)" etc... > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wobblygong at gmail.com Mon Sep 16 15:36:30 2024 From: wobblygong at gmail.com (Wesley Parish) Date: Mon, 16 Sep 2024 17:36:30 +1200 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: <0befb0a6-1d1b-4c91-8e24-4faba1a2bd94@gmail.com> Every computer geek knows his/her cat is the Computer Purry Furr-all ... don't say you weren't warned! :) Wesley Parish On 16/09/24 07:36, Ron Natalie wrote: > Before I got hooked on UNIX in 1977, I used a Univac Exec8 system. > You “cataloged” (created) a file with the @CAT command. > Other, file operations were done by the File Utility Routine/Program > Utility Routine:  FURPUR > (sort of like pip on steroids). > > I decided that if I ever got a CAT, it would be named FURPUR.   That > happened when I was working for Rutgers.   Not having any UNIVACs > around, the name escaped notice until the EE department hired a guy > from the University of Maryland who says “You have a cat named FURPUR?” > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Mon Sep 16 16:11:03 2024 From: robpike at gmail.com (Rob Pike) Date: Mon, 16 Sep 2024 16:11:03 +1000 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <20240915222921.GM29162@mcvoy.com> Message-ID: James Gosling used this idiomatic JCL command (see loop body) in something or other, and Brian and I borrowed it (with attribution) for the bundle command in our book. % cat /usr/local/plan9/bin/bundle #!/bin/sh echo '# To unbundle, run this file' for i do echo "echo $i" echo "sed 's/.//' >$i <<'//GO.SYSIN DD $i'" sed "s/^/-/" $i echo "//GO.SYSIN DD $i" done % -rob On Mon, Sep 16, 2024 at 3:31 PM Henry Bent wrote: > On Mon, 16 Sept 2024 at 00:11, Adam Thornton wrote: > >> You know, this is a place that might actually be able to provide a >> definitive answer to me. A brief web search found me asking the same >> question in 1995. >> >> When I were a wee lad, I was told `dd` was short for `do DEBE`, which, >> while obviously referencing a well-known movie about a Northern Texas >> sports team and their most enthusiastic fan, also referred to the mainframe >> software whose name was an acronym for `Does Everything But Eat` and whose >> function was to copy data across sources with very different blocking and >> representation conventions...which is kinda what `dd` does. >> >> Can anyone here confirm or deny that origin for the utility's name? >> >> > I looked through a broad swath of dd source files and man pages from v5 to > System III and SVR4, the BSD SCCS tree, various commercial UNIXes, modern > BSDs, and modern Linux but none of them have any sort of explanation of the > name. I figured I'd at least find something! > > It is the case that many places refer to the command's function as > "convert and copy," so I wonder if it's some sort of play on the fact that > the expected name of the command might be "cc". > > -Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Mon Sep 16 20:30:34 2024 From: robpike at gmail.com (Rob Pike) Date: Mon, 16 Sep 2024 20:30:34 +1000 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <20240915222921.GM29162@mcvoy.com> <8cd8fbf2-5529-966f-19d1-64e1d4fd9555@horsfall.org> Message-ID: One man's "data definition" is another's "define dataset" remembered faintly from 50 years ago. -rob On Mon, Sep 16, 2024 at 6:11 PM Tom Lyon wrote: > According to GC28-6704-1, IBM System/360 Operating System: Job Control > Language Reference, > DD means "Data Definition". Bitsavers knows all. > > On Sun, Sep 15, 2024 at 10:15 PM Dave Horsfall wrote: > >> On Mon, 16 Sep 2024, Rob Pike wrote: >> >> [ The origin of the "dd" command ] >> >> > I was told it's IBMese: Define Dataset. >> >> Straight from IBM's JCL (Job Control Language); heck, I still remember >> obscure things like "DISP=(,KEEP)" etc... >> >> -- Dave >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Mon Sep 16 20:41:25 2024 From: akosela at andykosela.com (Andy Kosela) Date: Mon, 16 Sep 2024 12:41:25 +0200 Subject: [TUHS] On computerese In-Reply-To: References: <202409160310.48G3AQb5074340@freefriends.org> Message-ID: On Monday, September 16, 2024, George Michaelson wrote: > cat is capable of endless discussion. > > cat thing | cat otherthing doesn't do what (some) people think. > cat thing | cat otherthing /dev/stdin does, but there's an ordering > point to be made. > cat thing | cat < otherthing /dev/stdin makes the ordering point. and > the number of lines seen. > > the role of the shell in marshalling the IO and determining what is > opened, when, truncated is another pitfall that seems to escape > people. "I thought the commands ran left to right" when your first > command < something and your final command > something > > like others, my use of cat is reflexive. I know perfectly well I could > solve the whole problem in awk or sed, I still construct sequences to > use sed to edit the lines, and awk to extract the fields in LSWP > denoted counts. we're speaking english and say "comme ci comme ca" and > nobody blinks, it's the same in shell. codeswitching! > I have always admired one letter commands in ed(1) and during the years constructed my own personal perfect Unix dictionary with most often used commands as one letter abbreviations. For cat(1) I have always used 'c' (cee) which also denotes one of its main functions. Grep(1) is 'g', vi(1) is 'v', etc. It makes typing a little faster, at least for me. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From edouardklein at gmail.com Mon Sep 16 20:59:01 2024 From: edouardklein at gmail.com (Edouard Klein) Date: Mon, 16 Sep 2024 12:59:01 +0200 Subject: [TUHS] On computerese In-Reply-To: References: <202409160310.48G3AQb5074340@freefriends.org> Message-ID: <8734lz6dym.fsf@gmail.com> George Michaelson writes: > cat is capable of endless discussion. > > cat thing | cat otherthing doesn't do what (some) people think. > cat thing | cat otherthing /dev/stdin does, but there's an ordering > point to be made. > cat thing | cat < otherthing /dev/stdin makes the ordering point. and > the number of lines seen. > I'm not sure of the point you are making with your last example, which gave me pause. I had to run it to see what it does. I correctly guessed that only one of thing or otherthing would be printed, but I was not able to guess if the | or the < would take precedence. Is there a simple reason why the < has priority over | for the stdin ? If the < precedence was your point, why did you specify /dev/stdin ? cat thing | cat < otherthing makes the point. Is there a finer point I am missing ? Sorry for being dense. I'm happy, after more that 20 years of Unixing, to see something new even with such supposedly basic commands. Thank you for your brain twister. From douglas.mcilroy at dartmouth.edu Mon Sep 16 22:07:10 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 16 Sep 2024 08:07:10 -0400 Subject: [TUHS] On computerese Message-ID: The florid syntax of IBM's DD was rivaled by that of GE's file utility. I always wondered whether it was named FUTIL unwarily or with tongue in cheek. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Sep 17 00:36:41 2024 From: clemc at ccc.com (Clem Cole) Date: Mon, 16 Sep 2024 10:36:41 -0400 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: Well, Doug, I'm not sure what it says about me now or them, but I remember that my 18-year-old self thought that was a funny name in those days. Over 50 years later, I find that it still makes me smile. Clem ᐧ On Mon, Sep 16, 2024 at 8:07 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > The florid syntax of IBM's DD was rivaled by that of GE's file utility. I > always wondered whether it was named FUTIL unwarily or with tongue in cheek. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Sep 17 00:37:58 2024 From: crossd at gmail.com (Dan Cross) Date: Mon, 16 Sep 2024 10:37:58 -0400 Subject: [TUHS] Working at Bell Labs: photos by Larry Luckham, 1967 In-Reply-To: References: Message-ID: On Sat, Sep 14, 2024 at 10:16 PM George Michaelson wrote: > Forgive me if these predate the glory days, found them interesting > > https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs These came up a few years ago, in the halcyon pre-COVID "before" days (aka, March 2019), and there was some discussion at the time. This facility was in northern California (Oakland, I believe) and was part of an experiment in making directory assistance both faster and less resource intensive. Ralph Corderoy wrote to Larry Luckham and got some more detail about the experiment; John Linderman subsequently chimed in with some of the business and vision failures that led to the overall effort being scuttled, as one of his early projects built on the results of the experiment. Links: https://tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/thread/32BDNXR2TD7P6MTLS5HBHROGFCUKPCFV/ https://tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/thread/RNDFGAXB3LPLAWO46YZKXB5BWLN6GGYN/#RNDFGAXB3LPLAWO46YZKXB5BWLN6GGYN - Dan C. From jpl.jpl at gmail.com Tue Sep 17 02:46:03 2024 From: jpl.jpl at gmail.com (John P. Linderman) Date: Mon, 16 Sep 2024 12:46:03 -0400 Subject: [TUHS] Working at Bell Labs: photos by Larry Luckham, 1967 In-Reply-To: References: Message-ID: On Mon, Sep 16, 2024 at 11:17 AM Dan Cross wrote: > On Sat, Sep 14, 2024 at 10:16 PM George Michaelson > wrote: > > Forgive me if these predate the glory days, found them interesting > > > > https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs > > These came up a few years ago, in the halcyon pre-COVID "before" days > (aka, March 2019), and there was some discussion at the time. > > This facility was in northern California (Oakland, I believe) and was > part of an experiment in making directory assistance both faster and > less resource intensive. Ralph Corderoy wrote to Larry Luckham and got > some more detail about the experiment; John Linderman subsequently > chimed in with some of the business and vision failures that led to > the overall effort being scuttled, as one of his early projects built > on the results of the experiment. > > Links: > > https://tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/thread/32BDNXR2TD7P6MTLS5HBHROGFCUKPCFV/ > > https://tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/thread/RNDFGAXB3LPLAWO46YZKXB5BWLN6GGYN/#RNDFGAXB3LPLAWO46YZKXB5BWLN6GGYN > > - Dan C. > I didn't participate in the California testing. I recall it ran on IBM equipment, but I have lost all contact with my then-supervisor, who did participate. It's hard for me to understand why they set up a fairly elaborate operation just to investigate directory assistance, why it would have been in California, and why it took years to conduct (and then abort) the test. It seems more likely to me that the center already existed, and the directory assistance test just took advantage of it having some spare cycles. But that's just sheer speculation on my part. -- jpl -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Sep 17 06:55:08 2024 From: crossd at gmail.com (Dan Cross) Date: Mon, 16 Sep 2024 16:55:08 -0400 Subject: [TUHS] On computerese In-Reply-To: <8734lz6dym.fsf@gmail.com> References: <202409160310.48G3AQb5074340@freefriends.org> <8734lz6dym.fsf@gmail.com> Message-ID: On Mon, Sep 16, 2024 at 7:31 AM Edouard Klein wrote: > George Michaelson writes: > > cat is capable of endless discussion. > > > > cat thing | cat otherthing doesn't do what (some) people think. > > cat thing | cat otherthing /dev/stdin does, but there's an ordering > > point to be made. > > cat thing | cat < otherthing /dev/stdin makes the ordering point. and > > the number of lines seen. > > I'm not sure of the point you are making with your last example, which > gave me pause. I had to run it to see what it does. > > I correctly guessed that only one of thing or otherthing would be printed, > but I was not able to guess if the | or the < would take precedence. > > Is there a simple reason why the < has priority over | for the stdin ? I suppose this depends entirely on the shell; perhaps that is the point. Arguably, being the target of a pipe _and_ having a redirect on stdin should be some kind of an error, but regardless, something that is true is that is that the second `cat` command will only see whatever is on `stdin` as it reads from `/dev/stdin`, but what is _on_ stdin can be confusing. - Dan C. > If the < precedence was your point, why did you specify /dev/stdin ? > cat thing | cat < otherthing > makes the point. > > Is there a finer point I am missing ? > > Sorry for being dense. I'm happy, after more that 20 years of Unixing, > to see something new even with such supposedly basic commands. Thank you > for your brain twister. From tuhs at tuhs.org Tue Sep 17 07:05:09 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Mon, 16 Sep 2024 17:05:09 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <202409160310.48G3AQb5074340@freefriends.org> <8734lz6dym.fsf@gmail.com> Message-ID: <34e968d4-b82c-4506-a185-7016316ef4a6@case.edu> On 9/16/24 4:55 PM, Dan Cross wrote: >> I correctly guessed that only one of thing or otherthing would be printed, >> but I was not able to guess if the | or the < would take precedence. >> >> Is there a simple reason why the < has priority over | for the stdin ? > > I suppose this depends entirely on the shell; perhaps that is the > point. POSIX actually speaks on this: "The standard input, standard output, or both of a command shall be considered to be assigned by the pipeline before any redirection specified by redirection operators that are part of the command" https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_09_02 In the general case, this is how things like program 2>&1 | collect_stdout_and_stderr can work (file descriptor 1 is associated with the pipe before fd 2 is redirected to it). -- ``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 lyndon at orthanc.ca Tue Sep 17 08:50:10 2024 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Mon, 16 Sep 2024 15:50:10 -0700 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> Message-ID: Rob Pike writes: > For me the fascinating thing about dd is that people tended to use the JCL > notation for its arguments even after the Unix style was made available. > That is, people prefer "dd if=3Dfoo" rather than "dd -if foo" or even the > obviously easiest "dd References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> Message-ID: <3F5A0F3E-EEE9-4878-8E6A-22E0D8C4ED9B@iitbombay.org> > On Sep 16, 2024, at 3:50 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > Rob Pike writes: > >> For me the fascinating thing about dd is that people tended to use the JCL >> notation for its arguments even after the Unix style was made available. >> That is, people prefer "dd if=3Dfoo" rather than "dd -if foo" or even the >> obviously easiest "dd > Oh come on Rob, you should know that for anyone over the age of 50, > the moment you see 'dd' your brain automatically switches to JCL > mode. It has to be DD, not dd! > And don't tell me you have never put a copy of dd in the root > directory just so you could tell someone to > > /dd if=... :-) That won't work. The data definition JCL statement format is more like this: // DD optionally continued by one or more of // DD ... :-) From dave at horsfall.org Tue Sep 17 09:16:17 2024 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 17 Sep 2024 09:16:17 +1000 (AEST) Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> Message-ID: <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> On Mon, 16 Sep 2024, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > Oh come on Rob, you should know that for anyone over the age of 50, the > moment you see 'dd' your brain automatically switches to JCL mode. Indeed, but no "dd" I know has "-if" etc; is that a Penguin thing? > And don't tell me you have never put a copy of dd in the root directory > just so you could tell someone to > > /dd if=... :-) Better still: //dd ... -- Dave From lm at mcvoy.com Tue Sep 17 09:24:57 2024 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 16 Sep 2024 16:24:57 -0700 Subject: [TUHS] On computerese In-Reply-To: <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> Message-ID: <20240916232457.GS29162@mcvoy.com> On Tue, Sep 17, 2024 at 09:16:17AM +1000, Dave Horsfall wrote: > On Mon, 16 Sep 2024, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > > Oh come on Rob, you should know that for anyone over the age of 50, the > > moment you see 'dd' your brain automatically switches to JCL mode. > > Indeed, but no "dd" I know has "-if" etc; is that a Penguin thing? Not a penguin thing on current xubuntu. From tuhs at tuhs.org Tue Sep 17 10:00:02 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 17 Sep 2024 00:00:02 +0000 Subject: [TUHS] On computerese In-Reply-To: <20240916232457.GS29162@mcvoy.com> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> Message-ID: On Monday, September 16th, 2024 at 4:24 PM, Larry McVoy wrote: > On Tue, Sep 17, 2024 at 09:16:17AM +1000, Dave Horsfall wrote: > > > On Mon, 16 Sep 2024, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > > > > Oh come on Rob, you should know that for anyone over the age of 50, the > > > moment you see 'dd' your brain automatically switches to JCL mode. > > > > Indeed, but no "dd" I know has "-if" etc; is that a Penguin thing? > > > Not a penguin thing on current xubuntu. Never seen that either, POSIX doesn't suggest any support for that either, with this in the RATIONALE section: ---QUOTE--- The OPTIONS section is listed as "None" because there are no options recognized by historical dd utilities. Certainly, many of the operands could have been designed to use the Utility Syntax Guidelines, which would have resulted in the classic hyphenated option letters. In this version of this volume of POSIX.1-2024, dd retains its curious JCL-like syntax due to the large number of applications that depend on the historical implementation. ---END QUOTE--- - Matt G. From robpike at gmail.com Tue Sep 17 10:17:16 2024 From: robpike at gmail.com (Rob Pike) Date: Tue, 17 Sep 2024 10:17:16 +1000 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> Message-ID: I don't remember whether late Research Unix had -if, but Plan 9 certainly did. -rob On Tue, Sep 17, 2024 at 10:06 AM segaloco via TUHS wrote: > On Monday, September 16th, 2024 at 4:24 PM, Larry McVoy > wrote: > > > On Tue, Sep 17, 2024 at 09:16:17AM +1000, Dave Horsfall wrote: > > > > > On Mon, 16 Sep 2024, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > > > > > > Oh come on Rob, you should know that for anyone over the age of 50, > the > > > > moment you see 'dd' your brain automatically switches to JCL mode. > > > > > > Indeed, but no "dd" I know has "-if" etc; is that a Penguin thing? > > > > > > Not a penguin thing on current xubuntu. > > Never seen that either, POSIX doesn't suggest any support for that either, > with this in the RATIONALE section: > > ---QUOTE--- > > The OPTIONS section is listed as "None" because there are no options > recognized by historical dd utilities. Certainly, many of the operands > could have been designed to use the Utility Syntax Guidelines, which would > have resulted in the classic hyphenated option letters. In this version of > this volume of POSIX.1-2024, dd retains its curious JCL-like syntax due to > the large number of applications that depend on the historical > implementation. > > ---END QUOTE--- > > - Matt G. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Tue Sep 17 11:17:39 2024 From: norman at oclsc.org (Norman Wilson) Date: Mon, 16 Sep 2024 21:17:39 -0400 (EDT) Subject: [TUHS] On computerese Message-ID: Rob Pike: I don't remember whether late Research Unix [dd] had -if, but Plan 9 certainly did. === I don't have a live 10/e system at the moment, but I have the 10/e source tree handy. Classic parody-IBM syntax only. Aside: I'm curious: does anyone else have 8/e, 9/e, or 10/e running these days? Norman Wilson Toronto ON From norman at oclsc.org Tue Sep 17 11:27:57 2024 From: norman at oclsc.org (Norman Wilson) Date: Mon, 16 Sep 2024 21:27:57 -0400 (EDT) Subject: [TUHS] On computerese Message-ID: <37343E70957BE5EDB2876B8198CB34E1.for-standards-violators@oclsc.org> Lyndon Nerenberg (VE7TFX/VE6BBM): Oh come on Rob, you should know that for anyone over the age of 50, the moment you see 'dd' your brain automatically switches to JCL mode. === Rob doubtless got IBM out of his system back in the late 1970s, when I think he was one of the authors of a shell that brought the TSO experience to Unix. Norman Wilson Toronto ON From henry.r.bent at gmail.com Tue Sep 17 11:28:49 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 16 Sep 2024 21:28:49 -0400 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: On Mon, Sep 16, 2024, 21:17 Norman Wilson wrote: > Rob Pike: > > I don't remember whether late Research Unix [dd] had -if, but Plan 9 > certainly did. > > === > > I don't have a live 10/e system at the moment, but I have > the 10/e source tree handy. Classic parody-IBM syntax > only. > > Aside: I'm curious: does anyone else have 8/e, 9/e, or > 10/e running these days? > > Norman Wilson > Toronto ON > I have v8 on the VAX (SIMH) running but as it doesn't have TCP/IP it fell into my pile of "I'll try some porting later" and never got picked back up. I also have v9 on a Sun in TME and now that the NME project has resurrected and enhanced that, shall we say, very particular emulator I should fire it back up and see what I can get running. I'd love to have v10 on a VAX but my preliminary efforts to get v10 going from source on v8 were not very successful; I suspect that it's just too big of a leap. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Tue Sep 17 11:29:27 2024 From: robpike at gmail.com (Rob Pike) Date: Tue, 17 Sep 2024 11:29:27 +1000 Subject: [TUHS] On computerese In-Reply-To: <37343E70957BE5EDB2876B8198CB34E1.for-standards-violators@oclsc.org> References: <37343E70957BE5EDB2876B8198CB34E1.for-standards-violators@oclsc.org> Message-ID: THAT WAS MOSTLY TOM DUFF, BUT YES. -ROB On Tue, Sep 17, 2024 at 11:28 AM Norman Wilson wrote: > Lyndon Nerenberg (VE7TFX/VE6BBM): > > Oh come on Rob, you should know that for anyone over the age of 50, > the moment you see 'dd' your brain automatically switches to JCL > mode. > > === > > Rob doubtless got IBM out of his system back in the > late 1970s, when I think he was one of the authors > of a shell that brought the TSO experience to Unix. > > Norman Wilson > Toronto ON > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Tue Sep 17 12:19:17 2024 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Mon, 16 Sep 2024 19:19:17 -0700 Subject: [TUHS] On computerese In-Reply-To: <3F5A0F3E-EEE9-4878-8E6A-22E0D8C4ED9B@iitbombay.org> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <3F5A0F3E-EEE9-4878-8E6A-22E0D8C4ED9B@iitbombay.org> Message-ID: Bakul Shah writes: > > /dd if=... :-) > > That won't work. The data definition JCL statement format > is more like this: > > // DD Yeah, I know. But you can get away with '//dd if= ...' which was more than enough to give some old timers whiplash the first time they saw that on a UNIX box :-) --lyndon From tuhs at tuhs.org Tue Sep 17 12:24:08 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 17 Sep 2024 02:24:08 +0000 Subject: [TUHS] V9 Bits (was On computerese) Message-ID: On Monday, September 16th, 2024 at 6:28 PM, Henry Bent wrote: > ... > I also have v9 on a Sun in TME > ... > > -Henry > V9 you say...does your setup happen to have the on-line manpages by any chance? I don't think a surviving copy is in the TUHS archive. V9 is a tad bit fragmentary in the archive at present from what I can tell, it may be worth seeing if anything you have fills in blanks. - Matt G. From henry.r.bent at gmail.com Tue Sep 17 12:59:45 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 16 Sep 2024 22:59:45 -0400 Subject: [TUHS] V9 Bits (was On computerese) In-Reply-To: References: Message-ID: On Mon, 16 Sept 2024 at 22:42, segaloco via TUHS wrote: > On Monday, September 16th, 2024 at 6:28 PM, Henry Bent < > henry.r.bent at gmail.com> wrote: > > > ... > > I also have v9 on a Sun in TME > > ... > > > > -Henry > > > > V9 you say...does your setup happen to have the on-line manpages by any > chance? I don't think a surviving copy is in the TUHS archive. V9 is a > tad bit fragmentary in the archive at present from what I can tell, it may > be worth seeing if anything you have fills in blanks. > > Just fired it up. The reason I put it aside was that the ie driver was set to hard panic every time it received a packet larger than 1500 bytes, and the workaround appeared straightforward but as someone from a BSD background it was not at all clear to me how to rebuild a kernel. I have some time now that I can set aside to teach myself how that build system works, so I'm planning to revisit it soon. Anyhow.... it does not appear to have any manpages. My recollection is that the distribution was just source, and the manpages were not a part of that source. It required a bootstrap from SunOS to get a working system; I don't think I have anything that is not in the TUHS archives. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Tue Sep 17 13:44:24 2024 From: athornton at gmail.com (Adam Thornton) Date: Mon, 16 Sep 2024 20:44:24 -0700 Subject: [TUHS] On computerese In-Reply-To: References: <37343E70957BE5EDB2876B8198CB34E1.for-standards-violators@oclsc.org> Message-ID: I feel like I would somehow be remiss if I did not point out that the formidable Rick Troth just put XFL, which is more-or-less a port of CMS/TSO Pipelines to POSIX, up on GitHub. https://github.com/trothtech/xfl I will confess to thinking CMS Pipelines are pretty cool. On Mon, Sep 16, 2024 at 6:36 PM Rob Pike wrote: > THAT WAS MOSTLY TOM DUFF, BUT YES. > >> Rob doubtless got IBM out of his system back in the >> late 1970s, when I think he was one of the authors >> of a shell that brought the TSO experience to Unix. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Sep 17 15:54:39 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 16 Sep 2024 23:54:39 -0600 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> Message-ID: <202409170554.48H5sduP148200@freefriends.org> I think it was only Plan 9. The change was motivated by the rc shell, which treated x=y anywhere on the command line (not just at the beginning of a command) as a variable assignment. (For a while I used Byron's rc. I was used to typing echo =============== to generate separator lines. rc threw a syntax error at me. :-) Arnold Rob Pike wrote: > I don't remember whether late Research Unix had -if, but Plan 9 certainly > did. > > -rob > > > On Tue, Sep 17, 2024 at 10:06 AM segaloco via TUHS wrote: > > > On Monday, September 16th, 2024 at 4:24 PM, Larry McVoy > > wrote: > > > > > On Tue, Sep 17, 2024 at 09:16:17AM +1000, Dave Horsfall wrote: > > > > > > > On Mon, 16 Sep 2024, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > > > > > > > > Oh come on Rob, you should know that for anyone over the age of 50, > > the > > > > > moment you see 'dd' your brain automatically switches to JCL mode. > > > > > > > > Indeed, but no "dd" I know has "-if" etc; is that a Penguin thing? > > > > > > > > > Not a penguin thing on current xubuntu. > > > > Never seen that either, POSIX doesn't suggest any support for that either, > > with this in the RATIONALE section: > > > > ---QUOTE--- > > > > The OPTIONS section is listed as "None" because there are no options > > recognized by historical dd utilities. Certainly, many of the operands > > could have been designed to use the Utility Syntax Guidelines, which would > > have resulted in the classic hyphenated option letters. In this version of > > this volume of POSIX.1-2024, dd retains its curious JCL-like syntax due to > > the large number of applications that depend on the historical > > implementation. > > > > ---END QUOTE--- > > > > - Matt G. > > From arnold at skeeve.com Tue Sep 17 16:00:18 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 17 Sep 2024 00:00:18 -0600 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> Message-ID: <202409170600.48H60IID148580@freefriends.org> "Lyndon Nerenberg (VE7TFX/VE6BBM)" wrote: > Oh come on Rob, you should know that for anyone over the age of 50, > the moment you see 'dd' your brain automatically switches to JCL > mode. I am (considerably) over 50, but was fortunate enough to never have to have used JCL. After a two year hiatus for religious studies, I returned to my university for my senior year and encountered Unix (IS/1 on a PDP-11/70), C, and Software Tools. It was sooooo far ahead of everything else that I knew then that's where I wanted to spend my career. Arnold From arnold at skeeve.com Tue Sep 17 16:04:43 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 17 Sep 2024 00:04:43 -0600 Subject: [TUHS] V9 Bits (was On computerese) In-Reply-To: References: Message-ID: <202409170604.48H64hvu150052@freefriends.org> segaloco via TUHS wrote: > V9 you say...does your setup happen to have the on-line manpages by > any chance? I don't think a surviving copy is in the TUHS archive. > V9 is a tad bit fragmentary in the archive at present from what I can > tell, it may be worth seeing if anything you have fills in blanks. I have real Bell Labs V8 and V9 manuals. The former is comb-bound like the System III manual, and was a gift obtained via BWK. I paid $50 for the latter; I remember exhchanging email with Doug about getting it. He said something like "I have to check if we can sell one to you." :-) This was circa 1993, I don't remember exactly. The V9 manual is perfect bound. I'd offer it for scanning, except that that would mean destroying the binding, which I'm very loath to do. Arnold From henry.r.bent at gmail.com Tue Sep 17 16:25:42 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 17 Sep 2024 02:25:42 -0400 Subject: [TUHS] On computerese In-Reply-To: <202409170600.48H60IID148580@freefriends.org> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <202409170600.48H60IID148580@freefriends.org> Message-ID: On Tue, 17 Sept 2024 at 02:00, wrote: > "Lyndon Nerenberg (VE7TFX/VE6BBM)" wrote: > > > Oh come on Rob, you should know that for anyone over the age of 50, > > the moment you see 'dd' your brain automatically switches to JCL > > mode. > > I am (considerably) over 50, but was fortunate enough to never have > to have used JCL. After a two year hiatus for religious studies, > I returned to my university for my senior year and encountered > Unix (IS/1 on a PDP-11/70), C, and Software Tools. It was sooooo far > ahead of everything else that I knew then that's where I wanted > to spend my career. > In the liberal arts world where my background is, IBMs were not a sure thing. My alma mater was a DEC shop top to bottom starting in the early '70s. The psychology department had a PDP-12, I believe the natural and computer sciences had a few 8s and 11s (and CS later an 11/750), and I know that the "computing center" (mostly administrativa) got an 11/780 pretty much as soon as they could. When I got there everything was still all DEC, VMS for the computing center (a 6620 clustered with some smaller boxes, also serving email and news) and mostly Ultrix on MIPS for the sciences. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Tue Sep 17 16:33:08 2024 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 17 Sep 2024 02:33:08 -0400 (EDT) Subject: [TUHS] V9 Bits (was On computerese) In-Reply-To: <202409170604.48H64hvu150052@freefriends.org> References: <202409170604.48H64hvu150052@freefriends.org> Message-ID: On Tue, 17 Sep 2024, arnold at skeeve.com wrote: > segaloco via TUHS wrote: > >> V9 you say...does your setup happen to have the on-line manpages by >> any chance? I don't think a surviving copy is in the TUHS archive. >> V9 is a tad bit fragmentary in the archive at present from what I can >> tell, it may be worth seeing if anything you have fills in blanks. > > I have real Bell Labs V8 and V9 manuals. The former is comb-bound like > the System III manual, and was a gift obtained via BWK. I paid $50 > for the latter; I remember exhchanging email with Doug about getting > it. He said something like "I have to check if we can sell one to you." :-) > This was circa 1993, I don't remember exactly. > > The V9 manual is perfect bound. I'd offer it for scanning, except > that that would mean destroying the binding, which I'm very loath > to do. > > Arnold A big reason why I hate perfect-bound books. Most of the books, though, I have that _aren't_ perfect-bound are religious in nature. -uso. From crossd at gmail.com Tue Sep 17 22:08:27 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 17 Sep 2024 08:08:27 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <37343E70957BE5EDB2876B8198CB34E1.for-standards-violators@oclsc.org> Message-ID: On Mon, Sep 16, 2024 at 9:36 PM Rob Pike wrote: > THAT WAS MOSTLY TOM DUFF, BUT YES. THIS POST INTENTIONALLY LEFT BLANK. From crossd at gmail.com Tue Sep 17 22:16:31 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 17 Sep 2024 08:16:31 -0400 Subject: [TUHS] Working at Bell Labs: photos by Larry Luckham, 1967 In-Reply-To: References: Message-ID: On Mon, Sep 16, 2024 at 12:46 PM John P. Linderman wrote: > On Mon, Sep 16, 2024 at 11:17 AM Dan Cross wrote: >> On Sat, Sep 14, 2024 at 10:16 PM George Michaelson wrote: >> > Forgive me if these predate the glory days, found them interesting >> > >> > https://retronaut.com/retronaut-capsules/1967-life-at-bell-labs >> >> These came up a few years ago, in the halcyon pre-COVID "before" days >> (aka, March 2019), and there was some discussion at the time. >> >> This facility was in northern California (Oakland, I believe) and was >> part of an experiment in making directory assistance both faster and >> less resource intensive. Ralph Corderoy wrote to Larry Luckham and got >> some more detail about the experiment; John Linderman subsequently >> chimed in with some of the business and vision failures that led to >> the overall effort being scuttled, as one of his early projects built >> on the results of the experiment. >> >> Links: >> https://tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/thread/32BDNXR2TD7P6MTLS5HBHROGFCUKPCFV/ >> https://tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/thread/RNDFGAXB3LPLAWO46YZKXB5BWLN6GGYN/#RNDFGAXB3LPLAWO46YZKXB5BWLN6GGYN > > I didn't participate in the California testing. I recall it ran on IBM equipment, > but I have lost all contact with my then-supervisor, who did participate. Right; what I had understood back in 2019 was that the project you got roped into used some of the results of that experiment, but that you were not directly involved. Apologies if that was unclear in my recent message. > It's hard for me to understand why they set up a fairly elaborate operation > just to investigate directory assistance, why it would have been in > California, and why it took years to conduct (and then abort) the test. > It seems more likely to me that the center already existed, and the > directory assistance test just took advantage of it having some spare cycles. > But that's just sheer speculation on my part. -- jpl Ralph Corderoy's repost of Larry Luckham's email to him went into some detail here: https://tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/message/OEVIAPKUO4Q6UA5UN6F5AOTXSISWLFNV/ The gist of it is that the bay area was chosen as a representative market for a large urban area, and CCA was contracted to do the programming. Why IBM hardware? Unclear on my most recent reading. Apparently PacBell provided some of the space. - Dan C. From als at thangorodrim.ch Wed Sep 18 06:25:04 2024 From: als at thangorodrim.ch (Alexander Schreiber) Date: Tue, 17 Sep 2024 22:25:04 +0200 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> Message-ID: On Mon, Sep 16, 2024 at 08:15:34AM +1000, Rob Pike wrote: > For me the fascinating thing about dd is that people tended to use the JCL > notation for its arguments even after the Unix style was made available. > That is, people prefer "dd if=foo" rather than "dd -if foo" or even the > obviously easiest "dd References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> Message-ID: <20240917205042.GC13296@mcvoy.com> On Tue, Sep 17, 2024 at 10:25:04PM +0200, Alexander Schreiber wrote: > On Mon, Sep 16, 2024 at 08:15:34AM +1000, Rob Pike wrote: > > For me the fascinating thing about dd is that people tended to use the JCL > > notation for its arguments even after the Unix style was made available. > > That is, people prefer "dd if=foo" rather than "dd -if foo" or even the > > obviously easiest "dd > Wait, when did that happen? And more importantly, _where_? > > The GNU Coreutils version (according to both --help and the man page) > only appears to support the JCL convention and in fact complains and > aborts when fed Unix style arguments. The NetBSD version behaves the > same way. Plan 9. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From dave at horsfall.org Wed Sep 18 11:40:48 2024 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 18 Sep 2024 11:40:48 +1000 (AEST) Subject: [TUHS] On computerese In-Reply-To: <202409170554.48H5sduP148200@freefriends.org> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> <202409170554.48H5sduP148200@freefriends.org> Message-ID: <10c842a2-1db5-3aa7-e5cc-8cf43203768c@horsfall.org> [ Of "dd -if" ] On Mon, 16 Sep 2024, arnold at skeeve.com wrote: > I think it was only Plan 9. The change was motivated by the rc shell, > which treated x=y anywhere on the command line (not just at the > beginning of a command) as a variable assignment. That is plain broken, but I can see how it could/would work; something like "A=B blah A=C blah"? > (For a while I used Byron's rc. I was used to typing > > echo =============== > > to generate separator lines. rc threw a syntax error at me. :-) Which is why I've always quoted anything not strictly alphanumeric; you never know what the current shell will do (especially if it's CSH[*]). [*] At a client's office I espied a book on CSH, and said something like "If there's any book that deserves to be burned, it's one on CSH programming"; pretty much everyone laughed :-) -- Dave From rich.salz at gmail.com Wed Sep 18 12:04:09 2024 From: rich.salz at gmail.com (Rich Salz) Date: Tue, 17 Sep 2024 22:04:09 -0400 Subject: [TUHS] On computerese In-Reply-To: <10c842a2-1db5-3aa7-e5cc-8cf43203768c@horsfall.org> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> <202409170554.48H5sduP148200@freefriends.org> <10c842a2-1db5-3aa7-e5cc-8cf43203768c@horsfall.org> Message-ID: > > > which treated x=y anywhere on the command line (not just at the > > beginning of a command) as a variable assignment. > > That is plain broken > No. The shell is NOT like sh, bash, etc., that you are used to. Go read the paper or, better yet, play with a version of it at https://github.com/rakitzis/rc -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Sep 18 15:09:35 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 17 Sep 2024 23:09:35 -0600 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> <202409170554.48H5sduP148200@freefriends.org> <10c842a2-1db5-3aa7-e5cc-8cf43203768c@horsfall.org> Message-ID: <202409180509.48I59Zu3231790@freefriends.org> Rich Salz wrote: > > > > > which treated x=y anywhere on the command line (not just at the > > > beginning of a command) as a variable assignment. > > > > That is plain broken > > > > No. The shell is NOT like sh, bash, etc., that you are used to. Go read > the paper or, better yet, play with a version of it at > https://github.com/rakitzis/rc There is also https://github.com/benavento/rc ; I didn't know that Byron had made rc available directly. Arnold From arnold at skeeve.com Wed Sep 18 15:12:48 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 17 Sep 2024 23:12:48 -0600 Subject: [TUHS] On computerese In-Reply-To: <202409180509.48I59Zu3231790@freefriends.org> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> <202409170554.48H5sduP148200@freefriends.org> <10c842a2-1db5-3aa7-e5cc-8cf43203768c@horsfall.org> <202409180509.48I59Zu3231790@freefriends.org> Message-ID: <202409180512.48I5Cm9x231991@freefriends.org> Taking a closer look: https://github.com/benavento/rc --- This is a standalone port of Tom Duff's original to *nix. https://github.com/rakitzis/rc --- This is Byron's reimplementation. Arnold From tuhs at tuhs.org Wed Sep 18 23:08:08 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Wed, 18 Sep 2024 09:08:08 -0400 Subject: [TUHS] On computerese In-Reply-To: <10c842a2-1db5-3aa7-e5cc-8cf43203768c@horsfall.org> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> <202409170554.48H5sduP148200@freefriends.org> <10c842a2-1db5-3aa7-e5cc-8cf43203768c@horsfall.org> Message-ID: On 9/17/24 9:40 PM, Dave Horsfall wrote: >> The change was motivated by the rc shell, >> which treated x=y anywhere on the command line (not just at the >> beginning of a command) as a variable assignment. > > That is plain broken, Unfamiliar, maybe, but even the Bourne shell had `set -k'. -- ``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/ From rminnich at gmail.com Wed Sep 18 23:46:55 2024 From: rminnich at gmail.com (ron minnich) Date: Wed, 18 Sep 2024 06:46:55 -0700 Subject: [TUHS] kernel boots kernel in 1977 Message-ID: I noticed there are kexec talks this year at Linux Plumbers. Kexec, kernel boots kernel, has had a 25 year gestation in Linux, but it looks like it's finally coming together, driven by need. Thereby hangs a tale. in 1977, I was working at udel with Ed Szurkowski, the first sysadmin of the Unix systems we got in 1976 (first machine was an 11/70). Ed was a gifted engineer and did all kinds of neat work on v6. He later went to the Labs once he got his PhD and I lost track of him. Ed got tired of watching the bootstrap slowness, and wrote a system call that did the following: 1. load kernel in memory from system call argument 2. put special signature in low memory telling bootstrap "look in memory" 3. reboot via reset. Now, this works, because back then, ROM boot code did not zero memory. Memory was unchanged across reset. So the bootstrap could find the magic bits and start the kernel. I've lost the code, I carried the listings for decades but finally dumped them. A shame. But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or was there something before? -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Sep 18 23:59:58 2024 From: imp at bsdimp.com (Warner Losh) Date: Wed, 18 Sep 2024 14:59:58 +0100 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: Message-ID: On Wed, Sep 18, 2024, 2:47 PM ron minnich wrote: > I noticed there are kexec talks this year at Linux Plumbers. Kexec, kernel > boots kernel, has had a 25 year gestation in Linux, but it looks like it's > finally coming together, driven by need. > Yes. LinuxBoot is fun... trick can be to slim the kernel + inird down enough to fit in the NOR flash so it can be the second stage payload rather than UEFI... i hacked FreeBSD's boot loader to be a Linux binary and use kexec. Thereby hangs a tale. > > in 1977, I was working at udel with Ed Szurkowski, the first sysadmin of > the Unix systems we got in 1976 (first machine was an 11/70). Ed was a > gifted engineer and did all kinds of neat work on v6. He later went to the > Labs once he got his PhD and I lost track of him. > > Ed got tired of watching the bootstrap slowness, and wrote a system call > that did the following: > 1. load kernel in memory from system call argument > 2. put special signature in low memory telling bootstrap "look in memory" > 3. reboot via reset. > > Now, this works, because back then, ROM boot code did not zero memory. > Memory was unchanged across reset. So the bootstrap could find the magic > bits and start the kernel. > > I've lost the code, I carried the listings for decades but finally dumped > them. A shame. > I saw similar code that would jump to location 0 to do the reset... it formed the basis of an interview question i used for two decades.. But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or > was there something before? > I've seen references to older mainframe systems doing that, but my quick searches can't find a references to this, apart from the Chain command in BASIC. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Thu Sep 19 01:34:24 2024 From: phil at ultimate.com (Phil Budne) Date: Wed, 18 Sep 2024 11:34:24 -0400 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: Message-ID: <202409181534.48IFYO1T094534@ultimate.com> ron minnich wrote: > But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or > was there something before? There was! The PDP-7 UNIX listings contain a program trysys.s https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s that reboots the system by reading a.out into user memory (in the high 4K of core), then copies it to low memory and jumping to the entry point. The name suggests its original intended use was to test a new system (kernel). P.S. Normal bootable system images seem to have been stored in reserved tracks of the (fixed head) disk (that are inacessible via system calls): https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s reads a.out and uses I/O instructions to write it out. P.P.S. Accordingly, I put together a "paper tape" for booting the system: https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s P.P.P.S. The system (kernel) is 3K words, the last 1K of low memory used for the character table for the vector graphics controller. The definitions for the table are compiled by https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s from definition file https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in (after, ISTR, figuring out the ordering of the listing pages!) I don't think we ever figured out how the initial character table is loaded into core. One thing that was missing from the table was the dispatch array, which I recreated: https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s The system (kernel) could be built for a "cold start", reloading the disk (prone to head crashes?) from paper tape? But I don't think anyone ever reconstructed the procedure for rebuilding a disk that way. The disk was two sided, and the running system only used one side: https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s appear to be programs to save and restore the filesystem from the "other" side of the disk. From rminnich at gmail.com Thu Sep 19 02:12:09 2024 From: rminnich at gmail.com (ron minnich) Date: Wed, 18 Sep 2024 09:12:09 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: <202409181534.48IFYO1T094534@ultimate.com> References: <202409181534.48IFYO1T094534@ultimate.com> Message-ID: Phil, that's really cool, thanks for it! On Wed, Sep 18, 2024 at 8:34 AM Phil Budne wrote: > ron minnich wrote: > > But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" > or > > was there something before? > > There was! The PDP-7 UNIX listings contain a program trysys.s > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s > that reboots the system by reading a.out into user memory (in the high > 4K of core), then copies it to low memory and jumping to the entry > point. The name suggests its original intended use was to test a new > system (kernel). > > P.S. > Normal bootable system images seem to have been stored in reserved > tracks of the (fixed head) disk (that are inacessible via system calls): > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s > reads a.out and uses I/O instructions to write it out. > > P.P.S. > Accordingly, I put together a "paper tape" for booting the system: > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s > > P.P.P.S. > The system (kernel) is 3K words, the last 1K of low memory > used for the character table for the vector graphics controller. > > The definitions for the table are compiled by > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s > from definition file > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in > (after, ISTR, figuring out the ordering of the listing pages!) > > I don't think we ever figured out how the initial character table > is loaded into core. One thing that was missing from the table > was the dispatch array, which I recreated: > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s > > The system (kernel) could be built for a "cold start", reloading the > disk (prone to head crashes?) from paper tape? But I don't think > anyone ever reconstructed the procedure for rebuilding a disk that way. > > The disk was two sided, and the running system only used one side: > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s > appear to be programs to save and restore the filesystem from the > "other" side of the disk. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Sep 19 07:09:25 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 18 Sep 2024 17:09:25 -0400 Subject: [TUHS] Maximum Array Sizes in 16 bit C Message-ID: Hello all, I know that this isn't strictly a "UNIX history" question, but as I am working with historic UNIX and this list contains a great number of people who were instrumental in its development, I figured it would be appropriate to ask here. If there's a better place for these sorts of questions, please let me know. I'm trying to figure out how the array size limits are set in the 2.11BSD pcc compiler. I've looked through quite a bit of documentation but I don't see anything that describes this. In theory on a 16 bit system I would think that the maximum array size would be 64K, but the actual limit that I found through trial and error is (2^15)-1. Declaring an array that is too large results in an error of "Constant required", which is being produced by c01.c in conexp(). https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/src/lib/ccom/c01.c I did quite a bit of searching through the source but I was not able to determine where this limit is being set. This is where my usual tools fall apart. Normally since I have the source I would compile the program I want with debugging turned on, and then do a backtrace so that I could see how we got to conexp(). But as far as I can tell I can't get a backtrace, since there is no option for debugging information in pcc; adb can only tell me where a process stopped. I would appreciate any enlightenment or pointers to other documentation. Thanks in advance! -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From chopps at chopps.org Thu Sep 19 07:13:17 2024 From: chopps at chopps.org (Christian Hopps) Date: Wed, 18 Sep 2024 17:13:17 -0400 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: <202409181534.48IFYO1T094534@ultimate.com> References: <202409181534.48IFYO1T094534@ultimate.com> Message-ID: We had/have this functionality in the Amiga port of NetBSD. It is implemented as `/dev/reload` device and you copy a kernel image to it. In locore.s there's code that copies the kernel image over top of the running kernel and then restarts. I believe for it to work nothing below the copy code in locore.s can change :) Thanks, Chris. Phil Budne writes: > ron minnich wrote: >> But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or >> was there something before? > > There was! The PDP-7 UNIX listings contain a program trysys.s > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s > that reboots the system by reading a.out into user memory (in the high > 4K of core), then copies it to low memory and jumping to the entry > point. The name suggests its original intended use was to test a new > system (kernel). > > P.S. > Normal bootable system images seem to have been stored in reserved > tracks of the (fixed head) disk (that are inacessible via system calls): > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s > reads a.out and uses I/O instructions to write it out. > > P.P.S. > Accordingly, I put together a "paper tape" for booting the system: > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s > > P.P.P.S. > The system (kernel) is 3K words, the last 1K of low memory > used for the character table for the vector graphics controller. > > The definitions for the table are compiled by > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s > from definition file > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in > (after, ISTR, figuring out the ordering of the listing pages!) > > I don't think we ever figured out how the initial character table > is loaded into core. One thing that was missing from the table > was the dispatch array, which I recreated: > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s > > The system (kernel) could be built for a "cold start", reloading the > disk (prone to head crashes?) from paper tape? But I don't think > anyone ever reconstructed the procedure for rebuilding a disk that way. > > The disk was two sided, and the running system only used one side: > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s > appear to be programs to save and restore the filesystem from the > "other" side of the disk. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 857 bytes Desc: not available URL: From rminnich at gmail.com Thu Sep 19 08:38:27 2024 From: rminnich at gmail.com (ron minnich) Date: Wed, 18 Sep 2024 15:38:27 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> Message-ID: Interesting about the amiga. I'm assuming their firmware zeros memory on reset, so you have to do handoff from kernel to kernel, not via a reset and so on? What was particularly nice about the V6/PDP-11 case: we were able to yank reset, which let us cleanly reset/disable devices, because everything was in memory when we got back. I miss the simplicity of the old machines. On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps wrote: > > We had/have this functionality in the Amiga port of NetBSD. > > It is implemented as `/dev/reload` device and you copy a kernel image to > it. In locore.s there's code that copies the kernel image over top of the > running kernel and then restarts. I believe for it to work nothing below > the copy code in locore.s can change :) > > Thanks, > Chris. > > Phil Budne writes: > > > ron minnich wrote: > >> But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" > or > >> was there something before? > > > > There was! The PDP-7 UNIX listings contain a program trysys.s > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s > > that reboots the system by reading a.out into user memory (in the high > > 4K of core), then copies it to low memory and jumping to the entry > > point. The name suggests its original intended use was to test a new > > system (kernel). > > > > P.S. > > Normal bootable system images seem to have been stored in reserved > > tracks of the (fixed head) disk (that are inacessible via system calls): > > > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s > > reads a.out and uses I/O instructions to write it out. > > > > P.P.S. > > Accordingly, I put together a "paper tape" for booting the system: > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s > > > > P.P.P.S. > > The system (kernel) is 3K words, the last 1K of low memory > > used for the character table for the vector graphics controller. > > > > The definitions for the table are compiled by > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s > > from definition file > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in > > (after, ISTR, figuring out the ordering of the listing pages!) > > > > I don't think we ever figured out how the initial character table > > is loaded into core. One thing that was missing from the table > > was the dispatch array, which I recreated: > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s > > > > The system (kernel) could be built for a "cold start", reloading the > > disk (prone to head crashes?) from paper tape? But I don't think > > anyone ever reconstructed the procedure for rebuilding a disk that way. > > > > The disk was two sided, and the running system only used one side: > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s > > appear to be programs to save and restore the filesystem from the > > "other" side of the disk. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther.johnson at makerlisp.com Thu Sep 19 08:52:47 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Wed, 18 Sep 2024 15:52:47 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> Message-ID: <84d31046-5b70-c5e2-7b16-5bfc21ceca27@makerlisp.com> Even better were DG Novas with core memory, just turn the machine off, come back in the morning, turn on the machine, pick up where you left off :) On 09/18/2024 03:38 PM, ron minnich wrote: > Interesting about the amiga. I'm assuming their firmware zeros memory > on reset, so you have to do handoff from kernel to kernel, not via a > reset and so on? > > What was particularly nice about the V6/PDP-11 case: we were able to > yank reset, which let us cleanly reset/disable devices, because > everything was in memory when we got back. I miss the simplicity of > the old machines. > > On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps > wrote: > > > We had/have this functionality in the Amiga port of NetBSD. > > It is implemented as `/dev/reload` device and you copy a kernel > image to it. In locore.s there's code that copies the kernel image > over top of the running kernel and then restarts. I believe for it > to work nothing below the copy code in locore.s can change :) > > Thanks, > Chris. > > Phil Budne > writes: > > > ron minnich wrote: > >> But I'm wondering: is Ed's work in 1977 the first "kernel boots > kernel" or > >> was there something before? > > > > There was! The PDP-7 UNIX listings contain a program trysys.s > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s > > that reboots the system by reading a.out into user memory (in > the high > > 4K of core), then copies it to low memory and jumping to the entry > > point. The name suggests its original intended use was to test > a new > > system (kernel). > > > > P.S. > > Normal bootable system images seem to have been stored in reserved > > tracks of the (fixed head) disk (that are inacessible via system > calls): > > > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s > > reads a.out and uses I/O instructions to write it out. > > > > P.P.S. > > Accordingly, I put together a "paper tape" for booting the system: > > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s > > > > P.P.P.S. > > The system (kernel) is 3K words, the last 1K of low memory > > used for the character table for the vector graphics controller. > > > > The definitions for the table are compiled by > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s > > from definition file > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in > > (after, ISTR, figuring out the ordering of the listing pages!) > > > > I don't think we ever figured out how the initial character table > > is loaded into core. One thing that was missing from the table > > was the dispatch array, which I recreated: > > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s > > > > The system (kernel) could be built for a "cold start", reloading the > > disk (prone to head crashes?) from paper tape? But I don't think > > anyone ever reconstructed the procedure for rebuilding a disk > that way. > > > > The disk was two sided, and the running system only used one side: > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s > > appear to be programs to save and restore the filesystem from the > > "other" side of the disk. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.martin.yardley at gmail.com Thu Sep 19 09:20:04 2024 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Thu, 19 Sep 2024 09:20:04 +1000 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: <84d31046-5b70-c5e2-7b16-5bfc21ceca27@makerlisp.com> References: <202409181534.48IFYO1T094534@ultimate.com> <84d31046-5b70-c5e2-7b16-5bfc21ceca27@makerlisp.com> Message-ID: <172A4544-FEDE-4D91-B3D7-FA95B3BB2C3A@gmail.com> I have memories of my colleague repairing that core memory with a large magnifier and a fine soldering iron. > On 19 Sep 2024, at 8:52 AM, Luther Johnson wrote: > > Even better were DG Novas with core memory, just turn the machine off, come back in the morning, turn on the machine, pick up where you left off :) > On 09/18/2024 03:38 PM, ron minnich wrote: >> Interesting about the amiga. I'm assuming their firmware zeros memory on reset, so you have to do handoff from kernel to kernel, not via a reset and so on? >> >> What was particularly nice about the V6/PDP-11 case: we were able to yank reset, which let us cleanly reset/disable devices, because everything was in memory when we got back. I miss the simplicity of the old machines. >> >> On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps wrote: >> >> We had/have this functionality in the Amiga port of NetBSD. >> >> It is implemented as `/dev/reload` device and you copy a kernel image to it. In locore.s there's code that copies the kernel image over top of the running kernel and then restarts. I believe for it to work nothing below the copy code in locore.s can change :) >> >> Thanks, >> Chris. >> >> Phil Budne writes: >> >> > ron minnich wrote: >> >> But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or >> >> was there something before? >> > >> > There was! The PDP-7 UNIX listings contain a program trysys.s >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s >> > that reboots the system by reading a.out into user memory (in the high >> > 4K of core), then copies it to low memory and jumping to the entry >> > point. The name suggests its original intended use was to test a new >> > system (kernel). >> > >> > P.S. >> > Normal bootable system images seem to have been stored in reserved >> > tracks of the (fixed head) disk (that are inacessible via system calls): >> > >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s >> > reads a.out and uses I/O instructions to write it out. >> > >> > P.P.S. >> > Accordingly, I put together a "paper tape" for booting the system: >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s >> > >> > P.P.P.S. >> > The system (kernel) is 3K words, the last 1K of low memory >> > used for the character table for the vector graphics controller. >> > >> > The definitions for the table are compiled by >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s >> > from definition file >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in >> > (after, ISTR, figuring out the ordering of the listing pages!) >> > >> > I don't think we ever figured out how the initial character table >> > is loaded into core. One thing that was missing from the table >> > was the dispatch array, which I recreated: >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s >> > >> > The system (kernel) could be built for a "cold start", reloading the >> > disk (prone to head crashes?) from paper tape? But I don't think >> > anyone ever reconstructed the procedure for rebuilding a disk that way. >> > >> > The disk was two sided, and the running system only used one side: >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s >> > appear to be programs to save and restore the filesystem from the >> > "other" side of the disk. >> > .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From tuhs at tuhs.org Thu Sep 19 09:38:18 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Wed, 18 Sep 2024 16:38:18 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> Message-ID: <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> I would prefer old kernel to new kernel handoff if it can be made to work reliably. Nowadays there are a lot of things that run before the kernel gets control. > On Sep 18, 2024, at 3:38 PM, ron minnich wrote: > > Interesting about the amiga. I'm assuming their firmware zeros memory on reset, so you have to do handoff from kernel to kernel, not via a reset and so on? > > What was particularly nice about the V6/PDP-11 case: we were able to yank reset, which let us cleanly reset/disable devices, because everything was in memory when we got back. I miss the simplicity of the old machines. > > On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps > wrote: >> >> We had/have this functionality in the Amiga port of NetBSD. >> >> It is implemented as `/dev/reload` device and you copy a kernel image to it. In locore.s there's code that copies the kernel image over top of the running kernel and then restarts. I believe for it to work nothing below the copy code in locore.s can change :) >> >> Thanks, >> Chris. >> >> Phil Budne > writes: >> >> > ron minnich wrote: >> >> But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or >> >> was there something before? >> > >> > There was! The PDP-7 UNIX listings contain a program trysys.s >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s >> > that reboots the system by reading a.out into user memory (in the high >> > 4K of core), then copies it to low memory and jumping to the entry >> > point. The name suggests its original intended use was to test a new >> > system (kernel). >> > >> > P.S. >> > Normal bootable system images seem to have been stored in reserved >> > tracks of the (fixed head) disk (that are inacessible via system calls): >> > >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s >> > reads a.out and uses I/O instructions to write it out. >> > >> > P.P.S. >> > Accordingly, I put together a "paper tape" for booting the system: >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s >> > >> > P.P.P.S. >> > The system (kernel) is 3K words, the last 1K of low memory >> > used for the character table for the vector graphics controller. >> > >> > The definitions for the table are compiled by >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s >> > from definition file >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in >> > (after, ISTR, figuring out the ordering of the listing pages!) >> > >> > I don't think we ever figured out how the initial character table >> > is loaded into core. One thing that was missing from the table >> > was the dispatch array, which I recreated: >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s >> > >> > The system (kernel) could be built for a "cold start", reloading the >> > disk (prone to head crashes?) from paper tape? But I don't think >> > anyone ever reconstructed the procedure for rebuilding a disk that way. >> > >> > The disk was two sided, and the running system only used one side: >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s >> > appear to be programs to save and restore the filesystem from the >> > "other" side of the disk. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu Sep 19 09:51:14 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 18 Sep 2024 19:51:14 -0400 Subject: [TUHS] Maximum Array Sizes in 16 bit C Message-ID: > The array size} limit that I found through trial and error is (2^15)-1. > Declaring an array that is [larger] results in an error of "Constant required", On its face, it states that anything bigger cannot be an integer constant, which is reasonable because that's the largest (signed) integer value. Does that version of C support unsigned constants? Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Sep 19 09:57:06 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 18 Sep 2024 19:57:06 -0400 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: References: Message-ID: On Wed, 18 Sept 2024 at 19:51, Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > The array size} limit that I found through trial and error is (2^15)-1. > > Declaring an array that is [larger] results in an error of "Constant > required", > > On its face, it states that anything bigger cannot be an integer constant, > which is reasonable because that's the largest (signed) integer value. Does > that version of C support unsigned constants? > I believe that it does support (16 bit) unsigned int, but I don't think that it supports (32 bit) unsigned long, only signed long. That's a great suggestion of a place to start. Following Nelson's suggestion, if there need to be negative references in array accesses (which certainly makes sense to me, on its face), it seems reasonable to have whatever intermediate variable be signed. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Thu Sep 19 09:58:20 2024 From: rminnich at gmail.com (ron minnich) Date: Wed, 18 Sep 2024 16:58:20 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> Message-ID: well, yes, on many systems, there's a lot that runs before the kernel. But if you have a risc-v system with oreboot, you own the system. The problem is that on most of these systems a reset will stop the dram clock for a little bit, or glitch clock enable, or dram power, or whatever. New systems are not designed to allow this. Ideally, we could force a reset of everything save memory, but modern systems are not designed in this way. Most annoying. On Wed, Sep 18, 2024 at 4:38 PM Bakul Shah wrote: > I would prefer old kernel to new kernel handoff if it can be made to work > reliably. Nowadays there are a lot of things that run before the kernel > gets control. > > On Sep 18, 2024, at 3:38 PM, ron minnich wrote: > > Interesting about the amiga. I'm assuming their firmware zeros memory on > reset, so you have to do handoff from kernel to kernel, not via a reset and > so on? > > What was particularly nice about the V6/PDP-11 case: we were able to yank > reset, which let us cleanly reset/disable devices, because everything was > in memory when we got back. I miss the simplicity of the old machines. > > On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps wrote: > >> >> We had/have this functionality in the Amiga port of NetBSD. >> >> It is implemented as `/dev/reload` device and you copy a kernel image to >> it. In locore.s there's code that copies the kernel image over top of the >> running kernel and then restarts. I believe for it to work nothing below >> the copy code in locore.s can change :) >> >> Thanks, >> Chris. >> >> Phil Budne writes: >> >> > ron minnich wrote: >> >> But I'm wondering: is Ed's work in 1977 the first "kernel boots >> kernel" or >> >> was there something before? >> > >> > There was! The PDP-7 UNIX listings contain a program trysys.s >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s >> > that reboots the system by reading a.out into user memory (in the high >> > 4K of core), then copies it to low memory and jumping to the entry >> > point. The name suggests its original intended use was to test a new >> > system (kernel). >> > >> > P.S. >> > Normal bootable system images seem to have been stored in reserved >> > tracks of the (fixed head) disk (that are inacessible via system calls): >> > >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s >> > reads a.out and uses I/O instructions to write it out. >> > >> > P.P.S. >> > Accordingly, I put together a "paper tape" for booting the system: >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s >> > >> > P.P.P.S. >> > The system (kernel) is 3K words, the last 1K of low memory >> > used for the character table for the vector graphics controller. >> > >> > The definitions for the table are compiled by >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s >> > from definition file >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in >> > (after, ISTR, figuring out the ordering of the listing pages!) >> > >> > I don't think we ever figured out how the initial character table >> > is loaded into core. One thing that was missing from the table >> > was the dispatch array, which I recreated: >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s >> > >> > The system (kernel) could be built for a "cold start", reloading the >> > disk (prone to head crashes?) from paper tape? But I don't think >> > anyone ever reconstructed the procedure for rebuilding a disk that way. >> > >> > The disk was two sided, and the running system only used one side: >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s >> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s >> > appear to be programs to save and restore the filesystem from the >> > "other" side of the disk. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Thu Sep 19 10:04:16 2024 From: ggm at algebras.org (George Michaelson) Date: Thu, 19 Sep 2024 10:04:16 +1000 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> Message-ID: Not to be "that guy" some of this can be read as "the whole ring/protection model is a myth" because doing a boot into a new executive demands "writing" state into parts of the system which people believe by a phenomenal act of faith are "protected" against that. Virtualisation makes much of this latent "protection rings are a bit of a myth" concrete. Maybe I misunderstand some of this. I can believe that UNIX-like things try to work irrespective of what chip designers do underneath to construct things like TPM, and talk to it in the limited ways necessary. -G From tuhs at tuhs.org Thu Sep 19 10:04:49 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Wed, 18 Sep 2024 17:04:49 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> Message-ID: <4CED8564-2BD7-4F56-A8C3-1A10061E8B61@iitbombay.org> Can you not avoid resetting the machine? This can be treated almost as sleep in the old kernel, wakeup in the new one! You do have to reset devices individually (which may not always work if it requires assistance from some undocumented firmware). > On Sep 18, 2024, at 4:58 PM, ron minnich wrote: > > well, yes, on many systems, there's a lot that runs before the kernel. But if you have a risc-v system with oreboot, you own the system. The problem is that on most of these systems a reset will stop the dram clock for a little bit, or glitch clock enable, or dram power, or whatever. New systems are not designed to allow this. > > Ideally, we could force a reset of everything save memory, but modern systems are not designed in this way. Most annoying. > > On Wed, Sep 18, 2024 at 4:38 PM Bakul Shah > wrote: >> I would prefer old kernel to new kernel handoff if it can be made to work reliably. Nowadays there are a lot of things that run before the kernel gets control. >> >>> On Sep 18, 2024, at 3:38 PM, ron minnich > wrote: >>> >>> Interesting about the amiga. I'm assuming their firmware zeros memory on reset, so you have to do handoff from kernel to kernel, not via a reset and so on? >>> >>> What was particularly nice about the V6/PDP-11 case: we were able to yank reset, which let us cleanly reset/disable devices, because everything was in memory when we got back. I miss the simplicity of the old machines. >>> >>> On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps > wrote: >>>> >>>> We had/have this functionality in the Amiga port of NetBSD. >>>> >>>> It is implemented as `/dev/reload` device and you copy a kernel image to it. In locore.s there's code that copies the kernel image over top of the running kernel and then restarts. I believe for it to work nothing below the copy code in locore.s can change :) >>>> >>>> Thanks, >>>> Chris. >>>> >>>> Phil Budne > writes: >>>> >>>> > ron minnich wrote: >>>> >> But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or >>>> >> was there something before? >>>> > >>>> > There was! The PDP-7 UNIX listings contain a program trysys.s >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s >>>> > that reboots the system by reading a.out into user memory (in the high >>>> > 4K of core), then copies it to low memory and jumping to the entry >>>> > point. The name suggests its original intended use was to test a new >>>> > system (kernel). >>>> > >>>> > P.S. >>>> > Normal bootable system images seem to have been stored in reserved >>>> > tracks of the (fixed head) disk (that are inacessible via system calls): >>>> > >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s >>>> > reads a.out and uses I/O instructions to write it out. >>>> > >>>> > P.P.S. >>>> > Accordingly, I put together a "paper tape" for booting the system: >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s >>>> > >>>> > P.P.P.S. >>>> > The system (kernel) is 3K words, the last 1K of low memory >>>> > used for the character table for the vector graphics controller. >>>> > >>>> > The definitions for the table are compiled by >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s >>>> > from definition file >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in >>>> > (after, ISTR, figuring out the ordering of the listing pages!) >>>> > >>>> > I don't think we ever figured out how the initial character table >>>> > is loaded into core. One thing that was missing from the table >>>> > was the dispatch array, which I recreated: >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s >>>> > >>>> > The system (kernel) could be built for a "cold start", reloading the >>>> > disk (prone to head crashes?) from paper tape? But I don't think >>>> > anyone ever reconstructed the procedure for rebuilding a disk that way. >>>> > >>>> > The disk was two sided, and the running system only used one side: >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s >>>> > appear to be programs to save and restore the filesystem from the >>>> > "other" side of the disk. >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Sep 19 10:23:16 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 18 Sep 2024 20:23:16 -0400 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> Message-ID: On Wed, Sep 18, 2024 at 8:11 PM George Michaelson wrote: > Not to be "that guy" some of this can be read as "the whole > ring/protection model is a myth" because doing a boot into a new > executive demands "writing" state into parts of the system which > people believe by a phenomenal act of faith are "protected" against > that. I'm not sure that I completely buy that. The act of replacing the kernel is, of course, a privileged operation. In some abstract sense, this is little different than triggering a reboot via a system call: in both cases, the system as we know it goes away and is replaced by something else. Similarly, even in the cold-boot case, very early on in the machine's lifecycle the kernel image is found and loaded into memory for execution. What's the difference if it's a bootloader that does that, or the kernel itself? Indeed, from the perspective of the newly booted kernel, the prior execution of the machine can be regarded as a single, perhaps exceptionally long, boot loading phase. > Virtualisation makes much of this latent "protection rings are a bit > of a myth" concrete. How so? Virtualization doesn't all of a sudden mean that (guest) userspace can scribble all over (guest) kernel memory, let alone the host. The deluge of recent speculation bugs notwithstanding, the separation between user and executive is still very much intrinsic to the proper operation of modern computers. > Maybe I misunderstand some of this. I can believe that UNIX-like > things try to work irrespective of what chip designers do underneath > to construct things like TPM, and talk to it in the limited ways > necessary. Yeah, we have seams between the host OS and the actual computer mediated by firmware, but given the state of that firmware, the present situation is borderline untenable. That's not to say that interfaces are bad, or that they're not useful, but the interfaces that we presently have are not good. E.g., https://www.usenix.org/conference/osdi21/presentation/fri-keynote At work, we've taken this to heart; the first x86 instruction when our CPUs come out of reset is actually sitting in code we wrote, and we boot directly into the operating system. https://vimeo.com/756050840, https://github.com/oxidecomputer/phbl, and https://rfd.shared.oxide.computer/rfd/0284 are interesting references. - Dan C. From ggm at algebras.org Thu Sep 19 10:32:03 2024 From: ggm at algebras.org (George Michaelson) Date: Thu, 19 Sep 2024 10:32:03 +1000 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> Message-ID: I think I misunderstand a lot of this Dan, so I won't try to prosecute my case. I felt your answer went to the ring model separating user space from kernel space, but not the ring model embedded in the CPU, down in the chip register set and instructions. "trusted" computing was the idea across boot you get to initialise some state and then set a flag, a bit, which forces the kernel to live within the constraint set encoded from that transition. Loading a new kernel imples writing into things which I believe(d) you had been constrained not to do. The chip level rings are meant to be absolutes. Warm boot vs Cold Boot vs .. I dunno, a manual transition through GPT and BIOS states to change things? I don't do this for a living. I stress I very probably completely mis-understand what is a pledge to good faith and what is actually meant to be enforced by hardware. -G From crossd at gmail.com Thu Sep 19 10:53:02 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 18 Sep 2024 20:53:02 -0400 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: <4CED8564-2BD7-4F56-A8C3-1A10061E8B61@iitbombay.org> References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> <4CED8564-2BD7-4F56-A8C3-1A10061E8B61@iitbombay.org> Message-ID: On Wed, Sep 18, 2024 at 8:05 PM Bakul Shah via TUHS wrote: > Can you not avoid resetting the machine? This can be treated almost as sleep in the old kernel, wakeup in the new one! You do have to reset devices individually (which may not always work if it requires assistance from some undocumented firmware). Perhaps this is what you mean when you mention assistance from firmware, Bakul, but it may be useful to consider that _many_ devices are touched by e.g. a BIOS or UEFI or whatever well before the OS is even loaded. If one steps back and considers the utility of a BIOS/UEFI (and I often lump these into the same category), there are three principal reasons for it: 1) back in the bad old days, we could offload common IO functions into code stored on a ROM, freeing up precious RAM for programs. 2) firmware provides a layer of indirection between the system and the host software, allowing both to vary while continuing to work with newer versions of the other. And finally 3) firmware facilitates bootstrapping the system by providing the host some way to access devices and locate and load an OS image, er, before the OS image is loaded. SOMETHING has to get enough code loaded from somewhere to start the system; often times that's firmware. Anyway, the last two suggest that device state can be arbitrarily munged before the OS takes over, and an actual reset at the device level might wipe out some state the OS depends on. Consider, for example, programming PCI BARs; on a "modern" x86-64 system with UEFI, this is done by firmware in the PEI layer, and the OS may expect that to already be set up by the time it is probing buses. An actual honest-to-goodness reset will probably wipe the BARs, requiring the host OS to program them (ironically, many OSes are already equipped to do so, as they have to handle these cases for e.g. PCI hotplug events, though many don't do it in the "ordinary" discovery and initialization phase of boot). I suppose the point is that a reset is great because it really does wipe out state, but it may also be a bummer because, well, it really does wipe out state. :-) - Dan C. > On Sep 18, 2024, at 4:58 PM, ron minnich wrote: > > well, yes, on many systems, there's a lot that runs before the kernel. But if you have a risc-v system with oreboot, you own the system. The problem is that on most of these systems a reset will stop the dram clock for a little bit, or glitch clock enable, or dram power, or whatever. New systems are not designed to allow this. > > Ideally, we could force a reset of everything save memory, but modern systems are not designed in this way. Most annoying. > > On Wed, Sep 18, 2024 at 4:38 PM Bakul Shah wrote: >> >> I would prefer old kernel to new kernel handoff if it can be made to work reliably. Nowadays there are a lot of things that run before the kernel gets control. >> >> On Sep 18, 2024, at 3:38 PM, ron minnich wrote: >> >> Interesting about the amiga. I'm assuming their firmware zeros memory on reset, so you have to do handoff from kernel to kernel, not via a reset and so on? >> >> What was particularly nice about the V6/PDP-11 case: we were able to yank reset, which let us cleanly reset/disable devices, because everything was in memory when we got back. I miss the simplicity of the old machines. >> >> On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps wrote: >>> >>> >>> We had/have this functionality in the Amiga port of NetBSD. >>> >>> It is implemented as `/dev/reload` device and you copy a kernel image to it. In locore.s there's code that copies the kernel image over top of the running kernel and then restarts. I believe for it to work nothing below the copy code in locore.s can change :) >>> >>> Thanks, >>> Chris. >>> >>> Phil Budne writes: >>> >>> > ron minnich wrote: >>> >> But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or >>> >> was there something before? >>> > >>> > There was! The PDP-7 UNIX listings contain a program trysys.s >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s >>> > that reboots the system by reading a.out into user memory (in the high >>> > 4K of core), then copies it to low memory and jumping to the entry >>> > point. The name suggests its original intended use was to test a new >>> > system (kernel). >>> > >>> > P.S. >>> > Normal bootable system images seem to have been stored in reserved >>> > tracks of the (fixed head) disk (that are inacessible via system calls): >>> > >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s >>> > reads a.out and uses I/O instructions to write it out. >>> > >>> > P.P.S. >>> > Accordingly, I put together a "paper tape" for booting the system: >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s >>> > >>> > P.P.P.S. >>> > The system (kernel) is 3K words, the last 1K of low memory >>> > used for the character table for the vector graphics controller. >>> > >>> > The definitions for the table are compiled by >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s >>> > from definition file >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in >>> > (after, ISTR, figuring out the ordering of the listing pages!) >>> > >>> > I don't think we ever figured out how the initial character table >>> > is loaded into core. One thing that was missing from the table >>> > was the dispatch array, which I recreated: >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s >>> > >>> > The system (kernel) could be built for a "cold start", reloading the >>> > disk (prone to head crashes?) from paper tape? But I don't think >>> > anyone ever reconstructed the procedure for rebuilding a disk that way. >>> > >>> > The disk was two sided, and the running system only used one side: >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s >>> > appear to be programs to save and restore the filesystem from the >>> > "other" side of the disk. >>> >> > From tuhs at tuhs.org Thu Sep 19 11:00:35 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Wed, 18 Sep 2024 18:00:35 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> Message-ID: <3B4CF41C-3D88-471D-B5E7-6F06C772F5E7@iitbombay.org> Forget "rings". Unix needs only two states from hardware. Forget virtualization for now as well. The kernel runs in the supervisor state, the user code in the unprivileged state where it can't execute or see certain instructions or processor state or peripherals and must make system calls for controlled access to the same. In addition Unix has the "root" user that can access much more but it too must go through the system call interface. A "warm reboot" system call would simply arrange things so that the new kernel image is copied in the right place and control will eventually pass to it. It is not so simple these days as the hardware is much more complex and often requires vendor provided firmware assist to properly initialize the system before control gets passed to an OS kernel but no change in the protection model is required for a kernel to kernel handoff. > On Sep 18, 2024, at 5:04 PM, George Michaelson wrote: > > Not to be "that guy" some of this can be read as "the whole > ring/protection model is a myth" because doing a boot into a new > executive demands "writing" state into parts of the system which > people believe by a phenomenal act of faith are "protected" against > that. > > Virtualisation makes much of this latent "protection rings are a bit > of a myth" concrete. > > Maybe I misunderstand some of this. I can believe that UNIX-like > things try to work irrespective of what chip designers do underneath > to construct things like TPM, and talk to it in the limited ways > necessary. > > -G From crossd at gmail.com Thu Sep 19 11:17:21 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 18 Sep 2024 21:17:21 -0400 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> Message-ID: On Wed, Sep 18, 2024 at 8:32 PM George Michaelson wrote: > I think I misunderstand a lot of this Dan, so I won't try to prosecute > my case. I felt your answer went to the ring model separating user > space from kernel space, but not the ring model embedded in the CPU, > down in the chip register set and instructions. Perhaps I don't understand what you mean, then. How are those things different? Or, put another way, one requires the other: the thing that separates userspace and kernel space _is_ the CPU's model of protection domains, but these have different names on different CPUs. Sure, they're numbered rings on x86 (0 being "kernel" mode, and 3 "user", with the rarely used 1 and 2 all but ignored outside of, I think, OS/2 2.x), but the analogous concept is called "access modes" of execution on VAX; RISC-V and ARM retain the "mode" nomenclature, as do most RISC architectures (MIPS, Alpha, SPARC, etc), but "kernel mode" (ring 0) is variously called "supervisor", "kernel", "executive" or "privileged" mode in different places (the VAX, of course, had 4 modes: kernel, executive, supervisor, and user; and the GE 645 had 9). > "trusted" computing was the idea across boot you get to initialise > some state and then set a flag, a bit, which forces the kernel to live > within the constraint set encoded from that transition. Do you mean something like ARM's trustzone? That's different, and usually involves a "trusted executive" outside of the control of the OS. But that doesn't a priori mean that the OS can't do funky things like replace itself. > Loading a new > kernel imples writing into things which I believe(d) you had been > constrained not to do. > > The chip level rings are meant to be absolutes. Not really. What would that mean? How would loadable kernel modules work in such a scenario? What about self-modifying code (when Linux boots up, it will examine what machine it's running on and quite possibly binary patch some hot execution paths to avoid branches)? If one can't move between processor access modes in some controlled way, how would IO or system calls work? As for trust-zone-y type stuff, consider that part of the overall security posture of a system may be to measure whatever is presented to the kexec mechanism and verify that it's properly signed; if it is, it's ok to boot it; if not, the operation fails. If the intent is merely to prevent untrusted code from running in kernel mode, such a mechanism (with a lot of details omitted) will more or less or that, provided the lowest-level trusted bootstrap code made sure that the first OS loaded was properly signed. This seems like a reasonable design that shouldn't be prohibited. > Warm boot vs Cold Boot vs .. I dunno, a manual transition through GPT > and BIOS states to change things? This is something people forget: the BIOS is just code. There's nothing magical about it. If you're talking about something like Trustzone to ensure that the _BIOS_ is properly trusted, then that's a separate matter, but mostly orthogonal to the kexec thing. > I don't do this for a living. I stress I very probably completely > mis-understand what is a pledge to good faith and what is actually > meant to be enforced by hardware. Hey, no problem: the goal of this list is to explore the history and (one hopes) learn from it as well. These are subtle topics and I'm sure we all, myself very much included, have much to learn here. I think we're all approaching this with the same collegial spirit of inquiry! - Dan C. From tuhs at tuhs.org Thu Sep 19 11:54:11 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Wed, 18 Sep 2024 18:54:11 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> <4CED8564-2BD7-4F56-A8C3-1A10061E8B61@iitbombay.org> Message-ID: <873C9A3E-2467-415A-ADC7-CD67ADCA22D1@iitbombay.org> > On Sep 18, 2024, at 5:53 PM, Dan Cross wrote: > > On Wed, Sep 18, 2024 at 8:05 PM Bakul Shah via TUHS wrote: >> Can you not avoid resetting the machine? This can be treated almost as sleep in the old kernel, wakeup in the new one! You do have to reset devices individually (which may not always work if it requires assistance from some undocumented firmware). > > Perhaps this is what you mean when you mention assistance from > firmware, Bakul, but it may be useful to consider that _many_ devices > are touched by e.g. a BIOS or UEFI or whatever well before the OS is > even loaded. Right but presumably the old kernel leaves them in a good enough state. > If one steps back and considers the utility of a BIOS/UEFI (and I > often lump these into the same category), there are three principal > reasons for it: 1) back in the bad old days, we could offload common > IO functions into code stored on a ROM, freeing up precious RAM for > programs. 2) firmware provides a layer of indirection between the > system and the host software, allowing both to vary while continuing > to work with newer versions of the other. And finally 3) firmware > facilitates bootstrapping the system by providing the host some way to > access devices and locate and load an OS image, er, before the OS > image is loaded. SOMETHING has to get enough code loaded from > somewhere to start the system; often times that's firmware. The new OS image is already in memory but may need to be copied to the right place. The devices were already working (but may need to have their interrupts disabled and any DMA stopped etc.). > Anyway, the last two suggest that device state can be arbitrarily > munged before the OS takes over, and an actual reset at the device > level might wipe out some state the OS depends on. Consider, for > example, programming PCI BARs; on a "modern" x86-64 system with UEFI, > this is done by firmware in the PEI layer, and the OS may expect that > to already be set up by the time it is probing buses. An actual > honest-to-goodness reset will probably wipe the BARs, requiring the > host OS to program them (ironically, many OSes are already equipped to > do so, as they have to handle these cases for e.g. PCI hotplug events, > though many don't do it in the "ordinary" discovery and initialization > phase of boot). All that is done on powerup. > > I suppose the point is that a reset is great because it really does > wipe out state, but it may also be a bummer because, well, it really > does wipe out state. :-) :-) I was speculating that kernel to kernel warmboot should be doable. > > - Dan C. > >> On Sep 18, 2024, at 4:58 PM, ron minnich wrote: >> >> well, yes, on many systems, there's a lot that runs before the kernel. But if you have a risc-v system with oreboot, you own the system. The problem is that on most of these systems a reset will stop the dram clock for a little bit, or glitch clock enable, or dram power, or whatever. New systems are not designed to allow this. >> >> Ideally, we could force a reset of everything save memory, but modern systems are not designed in this way. Most annoying. >> >> On Wed, Sep 18, 2024 at 4:38 PM Bakul Shah wrote: >>> >>> I would prefer old kernel to new kernel handoff if it can be made to work reliably. Nowadays there are a lot of things that run before the kernel gets control. >>> >>> On Sep 18, 2024, at 3:38 PM, ron minnich wrote: >>> >>> Interesting about the amiga. I'm assuming their firmware zeros memory on reset, so you have to do handoff from kernel to kernel, not via a reset and so on? >>> >>> What was particularly nice about the V6/PDP-11 case: we were able to yank reset, which let us cleanly reset/disable devices, because everything was in memory when we got back. I miss the simplicity of the old machines. >>> >>> On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps wrote: >>>> >>>> >>>> We had/have this functionality in the Amiga port of NetBSD. >>>> >>>> It is implemented as `/dev/reload` device and you copy a kernel image to it. In locore.s there's code that copies the kernel image over top of the running kernel and then restarts. I believe for it to work nothing below the copy code in locore.s can change :) >>>> >>>> Thanks, >>>> Chris. >>>> >>>> Phil Budne writes: >>>> >>>>> ron minnich wrote: >>>>>> But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or >>>>>> was there something before? >>>>> >>>>> There was! The PDP-7 UNIX listings contain a program trysys.s >>>>> https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s >>>>> that reboots the system by reading a.out into user memory (in the high >>>>> 4K of core), then copies it to low memory and jumping to the entry >>>>> point. The name suggests its original intended use was to test a new >>>>> system (kernel). >>>>> >>>>> P.S. >>>>> Normal bootable system images seem to have been stored in reserved >>>>> tracks of the (fixed head) disk (that are inacessible via system calls): >>>>> >>>>> https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s >>>>> reads a.out and uses I/O instructions to write it out. >>>>> >>>>> P.P.S. >>>>> Accordingly, I put together a "paper tape" for booting the system: >>>>> https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s >>>>> >>>>> P.P.P.S. >>>>> The system (kernel) is 3K words, the last 1K of low memory >>>>> used for the character table for the vector graphics controller. >>>>> >>>>> The definitions for the table are compiled by >>>>> https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s >>>>> from definition file >>>>> https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in >>>>> (after, ISTR, figuring out the ordering of the listing pages!) >>>>> >>>>> I don't think we ever figured out how the initial character table >>>>> is loaded into core. One thing that was missing from the table >>>>> was the dispatch array, which I recreated: >>>>> https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s >>>>> >>>>> The system (kernel) could be built for a "cold start", reloading the >>>>> disk (prone to head crashes?) from paper tape? But I don't think >>>>> anyone ever reconstructed the procedure for rebuilding a disk that way. >>>>> >>>>> The disk was two sided, and the running system only used one side: >>>>> https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s >>>>> https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s >>>>> appear to be programs to save and restore the filesystem from the >>>>> "other" side of the disk. >>>> >>> >> From imp at bsdimp.com Thu Sep 19 17:13:27 2024 From: imp at bsdimp.com (Warner Losh) Date: Thu, 19 Sep 2024 08:13:27 +0100 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: <4CED8564-2BD7-4F56-A8C3-1A10061E8B61@iitbombay.org> References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> <4CED8564-2BD7-4F56-A8C3-1A10061E8B61@iitbombay.org> Message-ID: On Thu, Sep 19, 2024, 1:05 AM Bakul Shah via TUHS wrote: > Can you not avoid resetting the machine? This can be treated almost as > sleep in the old kernel, wakeup in the new one! You do have to reset > devices individually (which may not always work if it requires assistance > from some undocumented firmware). > Kexec does just this. The new kernel boots without going through the reset vector. The old kernel keeps a tiny bit of code around that tears down all the protections, etc and hands off to the new kernel a mostly reset machine.. but it doesn't go through the firmware to do it... it was the original reason for it in linux: fast reboot times. Warner On Sep 18, 2024, at 4:58 PM, ron minnich wrote: > > well, yes, on many systems, there's a lot that runs before the kernel. But > if you have a risc-v system with oreboot, you own the system. The problem > is that on most of these systems a reset will stop the dram clock for a > little bit, or glitch clock enable, or dram power, or whatever. New systems > are not designed to allow this. > > Ideally, we could force a reset of everything save memory, but modern > systems are not designed in this way. Most annoying. > > On Wed, Sep 18, 2024 at 4:38 PM Bakul Shah wrote: > >> I would prefer old kernel to new kernel handoff if it can be made to work >> reliably. Nowadays there are a lot of things that run before the kernel >> gets control. >> >> On Sep 18, 2024, at 3:38 PM, ron minnich wrote: >> >> Interesting about the amiga. I'm assuming their firmware zeros memory on >> reset, so you have to do handoff from kernel to kernel, not via a reset and >> so on? >> >> What was particularly nice about the V6/PDP-11 case: we were able to yank >> reset, which let us cleanly reset/disable devices, because everything was >> in memory when we got back. I miss the simplicity of the old machines. >> >> On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps >> wrote: >> >>> >>> We had/have this functionality in the Amiga port of NetBSD. >>> >>> It is implemented as `/dev/reload` device and you copy a kernel image to >>> it. In locore.s there's code that copies the kernel image over top of the >>> running kernel and then restarts. I believe for it to work nothing below >>> the copy code in locore.s can change :) >>> >>> Thanks, >>> Chris. >>> >>> Phil Budne writes: >>> >>> > ron minnich wrote: >>> >> But I'm wondering: is Ed's work in 1977 the first "kernel boots >>> kernel" or >>> >> was there something before? >>> > >>> > There was! The PDP-7 UNIX listings contain a program trysys.s >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s >>> > that reboots the system by reading a.out into user memory (in the high >>> > 4K of core), then copies it to low memory and jumping to the entry >>> > point. The name suggests its original intended use was to test a new >>> > system (kernel). >>> > >>> > P.S. >>> > Normal bootable system images seem to have been stored in reserved >>> > tracks of the (fixed head) disk (that are inacessible via system >>> calls): >>> > >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s >>> > reads a.out and uses I/O instructions to write it out. >>> > >>> > P.P.S. >>> > Accordingly, I put together a "paper tape" for booting the system: >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s >>> > >>> > P.P.P.S. >>> > The system (kernel) is 3K words, the last 1K of low memory >>> > used for the character table for the vector graphics controller. >>> > >>> > The definitions for the table are compiled by >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s >>> > from definition file >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in >>> > (after, ISTR, figuring out the ordering of the listing pages!) >>> > >>> > I don't think we ever figured out how the initial character table >>> > is loaded into core. One thing that was missing from the table >>> > was the dispatch array, which I recreated: >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s >>> > >>> > The system (kernel) could be built for a "cold start", reloading the >>> > disk (prone to head crashes?) from paper tape? But I don't think >>> > anyone ever reconstructed the procedure for rebuilding a disk that way. >>> > >>> > The disk was two sided, and the running system only used one side: >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s >>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s >>> > appear to be programs to save and restore the filesystem from the >>> > "other" side of the disk. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Thu Sep 19 23:13:11 2024 From: rich.salz at gmail.com (Rich Salz) Date: Thu, 19 Sep 2024 09:13:11 -0400 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: References: Message-ID: > > if there need to be negative references in array accesses (which certainly > makes sense to me, on its face), it seems reasonable to have whatever > intermediate variable be signed. > In my first C programming job I saw the source to V7 grep which had a "foo[-2]" construct. It was a moment of enlightenment and another bit of K&R fell into place. ( https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/grep.c; search for "[-") -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Fri Sep 20 00:51:14 2024 From: rminnich at gmail.com (ron minnich) Date: Thu, 19 Sep 2024 07:51:14 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> <4CED8564-2BD7-4F56-A8C3-1A10061E8B61@iitbombay.org> Message-ID: to reiterate: you can avoid resetting the machine, and for all the x million systems in data centers around the world, we do avoid resetting the machine. But that comes with its own set of issues, including kernel version x not being able to boot kernel version y (very common with linux, no problem on plan 9); and hardware not behaving well, since few people write drivers that properly reset hardware; or the hardware can't be cleaned up absent a reset (most common problem areas are NICs and graphics). Very few linux drivers can properly shut down hardware for a kexec. The IOMMU and MSIx added a whole new world of fun. Sometimes it feels like it works by accident. Also recall that side channels across a kexec are an issue that has to be considered. At Google we've considered them by, e.g., turning on "zero on free" and "zero on alloc" in the kernel that will kexec, only using a small amount of memory in the first kernel (32GiB is small! Ha!), among other things. But since DRAM SPD and Voltage regulator module FLASH provide places to hide things, it's getting messy. So it's not as simple as "reset bad, not reset good". Hardware is poorly designed, or the drivers are poorly written, and absent a reset, the kexec'ed kernel may fail to boot -- lockup is common, panic is common. That said, no system I know of implements kexec with a reset in the middle. Short history: in the Linux world, kernel boots kernel was done, in 1999, by LOBOS (me) and Eric Hendriks (Two Kernel Monte), and Alpha Power (DBLX). Werner Almesberger did his own thing ca. 2000 called (iirc) bootimg. Eric Biederman looked at LOBOS, did not like it, and wrote kexec, I believe around 2001. Plan 9 got kernel boots kernel around that time. As usual, the Plan 9 implementation was the most compact and cleanest. This paper https://ieeexplore.ieee.org/document/1392643 compares them. The AlphaPower DBLX code was lost when the company went under. They made a heroic effort to get it to sourceforge but things happened too fast. DBLX means "direct boot linux" -- the acronym reads better. The first kexec was a very general interface, with a Himalayan learning curve. At some point an Intel engineer found kexec confusing and wrote an entirely new type of kexec, with a different API, that many people found easier. so kexec has been around for 20 years, and we're still getting the hang of it, and there are still people who claim that it will never fully work. Anyway, we're far afield of the original question, but it was very interesting to read how far back the idea goes! PDP-7, who knew? p.s. as to an unrelated discussion: kernels have been self modifying code since at least module loaders became a thing -- that's almost 40 years. Today, especially for risc-v, Linux is aggressively self-modifying; there's no option for some risc-v SoC if you want them to work correctly. Linux rewrites the entire kernel text in early boot stages. You can consider the last stage linker optimization occurs in Linux early boot code. On Thu, Sep 19, 2024 at 12:13 AM Warner Losh wrote: > > > On Thu, Sep 19, 2024, 1:05 AM Bakul Shah via TUHS wrote: > >> Can you not avoid resetting the machine? This can be treated almost as >> sleep in the old kernel, wakeup in the new one! You do have to reset >> devices individually (which may not always work if it requires assistance >> from some undocumented firmware). >> > > Kexec does just this. The new kernel boots without going through the reset > vector. The old kernel keeps a tiny bit of code around that tears down all > the protections, etc and hands off to the new kernel a mostly reset > machine.. but it doesn't go through the firmware to do it... it was the > original reason for it in linux: fast reboot times. > > Warner > > On Sep 18, 2024, at 4:58 PM, ron minnich wrote: >> >> well, yes, on many systems, there's a lot that runs before the kernel. >> But if you have a risc-v system with oreboot, you own the system. The >> problem is that on most of these systems a reset will stop the dram clock >> for a little bit, or glitch clock enable, or dram power, or whatever. New >> systems are not designed to allow this. >> >> Ideally, we could force a reset of everything save memory, but modern >> systems are not designed in this way. Most annoying. >> >> On Wed, Sep 18, 2024 at 4:38 PM Bakul Shah wrote: >> >>> I would prefer old kernel to new kernel handoff if it can be made to >>> work reliably. Nowadays there are a lot of things that run before the >>> kernel gets control. >>> >>> On Sep 18, 2024, at 3:38 PM, ron minnich wrote: >>> >>> Interesting about the amiga. I'm assuming their firmware zeros memory on >>> reset, so you have to do handoff from kernel to kernel, not via a reset and >>> so on? >>> >>> What was particularly nice about the V6/PDP-11 case: we were able to >>> yank reset, which let us cleanly reset/disable devices, because everything >>> was in memory when we got back. I miss the simplicity of the old machines. >>> >>> On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps >>> wrote: >>> >>>> >>>> We had/have this functionality in the Amiga port of NetBSD. >>>> >>>> It is implemented as `/dev/reload` device and you copy a kernel image >>>> to it. In locore.s there's code that copies the kernel image over top of >>>> the running kernel and then restarts. I believe for it to work nothing >>>> below the copy code in locore.s can change :) >>>> >>>> Thanks, >>>> Chris. >>>> >>>> Phil Budne writes: >>>> >>>> > ron minnich wrote: >>>> >> But I'm wondering: is Ed's work in 1977 the first "kernel boots >>>> kernel" or >>>> >> was there something before? >>>> > >>>> > There was! The PDP-7 UNIX listings contain a program trysys.s >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s >>>> > that reboots the system by reading a.out into user memory (in the high >>>> > 4K of core), then copies it to low memory and jumping to the entry >>>> > point. The name suggests its original intended use was to test a new >>>> > system (kernel). >>>> > >>>> > P.S. >>>> > Normal bootable system images seem to have been stored in reserved >>>> > tracks of the (fixed head) disk (that are inacessible via system >>>> calls): >>>> > >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s >>>> > reads a.out and uses I/O instructions to write it out. >>>> > >>>> > P.P.S. >>>> > Accordingly, I put together a "paper tape" for booting the system: >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s >>>> > >>>> > P.P.P.S. >>>> > The system (kernel) is 3K words, the last 1K of low memory >>>> > used for the character table for the vector graphics controller. >>>> > >>>> > The definitions for the table are compiled by >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s >>>> > from definition file >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in >>>> > (after, ISTR, figuring out the ordering of the listing pages!) >>>> > >>>> > I don't think we ever figured out how the initial character table >>>> > is loaded into core. One thing that was missing from the table >>>> > was the dispatch array, which I recreated: >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s >>>> > >>>> > The system (kernel) could be built for a "cold start", reloading the >>>> > disk (prone to head crashes?) from paper tape? But I don't think >>>> > anyone ever reconstructed the procedure for rebuilding a disk that >>>> way. >>>> > >>>> > The disk was two sided, and the running system only used one side: >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s >>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s >>>> > appear to be programs to save and restore the filesystem from the >>>> > "other" side of the disk. >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Sep 20 01:39:59 2024 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Thu, 19 Sep 2024 08:39:59 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> <4CED8564-2BD7-4F56-A8C3-1A10061E8B61@iitbombay.org> Message-ID: On 9/19/24 00:13, Warner Losh wrote: > Kexec does just this. The new kernel boots without going through the reset > vector. The old kernel keeps a tiny bit of code around that tears down all the > protections, etc and hands off to the new kernel a mostly reset machine.. but it > doesn't go through the firmware to do it... it was the original reason for it in > linux: fast reboot times. Indeed - when Sun implemented the equivalent in Solaris, the feature was literally named "Fast Reboot": https://illumos.org/opensolaris/ARChive/PSARC/2008/382/final.materials/fastboot.txt It will refuse to run and require a trip through the firmware if any active drivers don't support or can't complete a "quiesce" routine to finish off any in-progress operations and reset the the hardware to the state expected for a fresh boot: https://illumos.org/opensolaris/ARChive/PSARC/2008/382/final.materials/quiesce.man.txt -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From imp at bsdimp.com Fri Sep 20 02:47:24 2024 From: imp at bsdimp.com (Warner Losh) Date: Thu, 19 Sep 2024 17:47:24 +0100 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> <4CED8564-2BD7-4F56-A8C3-1A10061E8B61@iitbombay.org> Message-ID: On Thu, Sep 19, 2024, 3:51 PM ron minnich wrote: > to reiterate: you can avoid resetting the machine, and for all the x > million systems in data centers around the world, we do avoid resetting the > machine. > > But that comes with its own set of issues, including kernel version x not > being able to boot kernel version y (very common with linux, no problem on > plan 9); and hardware not behaving well, since few people write drivers > that properly reset hardware; or the hardware can't be cleaned up absent a > reset (most common problem areas are NICs and graphics). Very few linux > drivers can properly shut down hardware for a kexec. The IOMMU and MSIx > added a whole new world of fun. Sometimes it feels like it works by > accident. > > Also recall that side channels across a kexec are an issue that has to be > considered. At Google we've considered them by, e.g., turning on "zero on > free" and "zero on alloc" in the kernel that will kexec, only using a small > amount of memory in the first kernel (32GiB is small! Ha!), among other > things. But since DRAM SPD and Voltage regulator module FLASH provide > places to hide things, it's getting messy. > > So it's not as simple as "reset bad, not reset good". Hardware is poorly > designed, or the drivers are poorly written, and absent a reset, the > kexec'ed kernel may fail to boot -- lockup is common, panic is common. That > said, no system I know of implements kexec with a reset in the middle. > > Short history: in the Linux world, kernel boots kernel was done, in 1999, > by LOBOS (me) and Eric Hendriks (Two Kernel Monte), and Alpha Power > (DBLX). Werner Almesberger did his own thing ca. 2000 called (iirc) > bootimg. Eric Biederman looked at LOBOS, did not like it, and wrote kexec, > I believe around 2001. Plan 9 got kernel boots kernel around that time. As > usual, the Plan 9 implementation was the most compact and cleanest. This > paper https://ieeexplore.ieee.org/document/1392643 compares them. > > The AlphaPower DBLX code was lost when the company went under. They made a > heroic effort to get it to sourceforge but things happened too fast. DBLX > means "direct boot linux" -- the acronym reads better. > > The first kexec was a very general interface, with a Himalayan learning > curve. At some point an Intel engineer found kexec confusing and wrote an > entirely new type of kexec, with a different API, that many people found > easier. > The kexec I'm ising is like that. "Load the memory you want and give us a start address." is all the instructions you get. God speed. Best of luck. Have fun storming the castle. I had to read a ton of code to find the details. Then I needed to set it up like FreeBSD's regular loaders do. And once I guessed wrong about 200 times, i was up and limping. I'd definitely wouldn't call kexec easy to learn or code to... And it was a blast... Warner so kexec has been around for 20 years, and we're still getting the hang of > it, and there are still people who claim that it will never fully work. > > Anyway, we're far afield of the original question, but it was very > interesting to read how far back the idea goes! PDP-7, who knew? > > p.s. as to an unrelated discussion: kernels have been self modifying code > since at least module loaders became a thing -- that's almost 40 years. > Today, especially for risc-v, Linux is aggressively self-modifying; there's > no option for some risc-v SoC if you want them to work correctly. Linux > rewrites the entire kernel text in early boot stages. You can consider the > last stage linker optimization occurs in Linux early boot code. > > On Thu, Sep 19, 2024 at 12:13 AM Warner Losh wrote: > >> >> >> On Thu, Sep 19, 2024, 1:05 AM Bakul Shah via TUHS wrote: >> >>> Can you not avoid resetting the machine? This can be treated almost as >>> sleep in the old kernel, wakeup in the new one! You do have to reset >>> devices individually (which may not always work if it requires assistance >>> from some undocumented firmware). >>> >> >> Kexec does just this. The new kernel boots without going through the >> reset vector. The old kernel keeps a tiny bit of code around that tears >> down all the protections, etc and hands off to the new kernel a mostly >> reset machine.. but it doesn't go through the firmware to do it... it was >> the original reason for it in linux: fast reboot times. >> >> Warner >> >> On Sep 18, 2024, at 4:58 PM, ron minnich wrote: >>> >>> well, yes, on many systems, there's a lot that runs before the kernel. >>> But if you have a risc-v system with oreboot, you own the system. The >>> problem is that on most of these systems a reset will stop the dram clock >>> for a little bit, or glitch clock enable, or dram power, or whatever. New >>> systems are not designed to allow this. >>> >>> Ideally, we could force a reset of everything save memory, but modern >>> systems are not designed in this way. Most annoying. >>> >>> On Wed, Sep 18, 2024 at 4:38 PM Bakul Shah wrote: >>> >>>> I would prefer old kernel to new kernel handoff if it can be made to >>>> work reliably. Nowadays there are a lot of things that run before the >>>> kernel gets control. >>>> >>>> On Sep 18, 2024, at 3:38 PM, ron minnich wrote: >>>> >>>> Interesting about the amiga. I'm assuming their firmware zeros memory >>>> on reset, so you have to do handoff from kernel to kernel, not via a reset >>>> and so on? >>>> >>>> What was particularly nice about the V6/PDP-11 case: we were able to >>>> yank reset, which let us cleanly reset/disable devices, because everything >>>> was in memory when we got back. I miss the simplicity of the old machines. >>>> >>>> On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps >>>> wrote: >>>> >>>>> >>>>> We had/have this functionality in the Amiga port of NetBSD. >>>>> >>>>> It is implemented as `/dev/reload` device and you copy a kernel image >>>>> to it. In locore.s there's code that copies the kernel image over top of >>>>> the running kernel and then restarts. I believe for it to work nothing >>>>> below the copy code in locore.s can change :) >>>>> >>>>> Thanks, >>>>> Chris. >>>>> >>>>> Phil Budne writes: >>>>> >>>>> > ron minnich wrote: >>>>> >> But I'm wondering: is Ed's work in 1977 the first "kernel boots >>>>> kernel" or >>>>> >> was there something before? >>>>> > >>>>> > There was! The PDP-7 UNIX listings contain a program trysys.s >>>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s >>>>> > that reboots the system by reading a.out into user memory (in the >>>>> high >>>>> > 4K of core), then copies it to low memory and jumping to the entry >>>>> > point. The name suggests its original intended use was to test a new >>>>> > system (kernel). >>>>> > >>>>> > P.S. >>>>> > Normal bootable system images seem to have been stored in reserved >>>>> > tracks of the (fixed head) disk (that are inacessible via system >>>>> calls): >>>>> > >>>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s >>>>> > reads a.out and uses I/O instructions to write it out. >>>>> > >>>>> > P.P.S. >>>>> > Accordingly, I put together a "paper tape" for booting the system: >>>>> > >>>>> https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s >>>>> > >>>>> > P.P.P.S. >>>>> > The system (kernel) is 3K words, the last 1K of low memory >>>>> > used for the character table for the vector graphics controller. >>>>> > >>>>> > The definitions for the table are compiled by >>>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s >>>>> > from definition file >>>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in >>>>> > (after, ISTR, figuring out the ordering of the listing pages!) >>>>> > >>>>> > I don't think we ever figured out how the initial character table >>>>> > is loaded into core. One thing that was missing from the table >>>>> > was the dispatch array, which I recreated: >>>>> > >>>>> https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s >>>>> > >>>>> > The system (kernel) could be built for a "cold start", reloading the >>>>> > disk (prone to head crashes?) from paper tape? But I don't think >>>>> > anyone ever reconstructed the procedure for rebuilding a disk that >>>>> way. >>>>> > >>>>> > The disk was two sided, and the running system only used one side: >>>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s >>>>> > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s >>>>> > appear to be programs to save and restore the filesystem from the >>>>> > "other" side of the disk. >>>>> >>>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Sep 20 03:19:46 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 19 Sep 2024 13:19:46 -0400 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: <873C9A3E-2467-415A-ADC7-CD67ADCA22D1@iitbombay.org> References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> <4CED8564-2BD7-4F56-A8C3-1A10061E8B61@iitbombay.org> <873C9A3E-2467-415A-ADC7-CD67ADCA22D1@iitbombay.org> Message-ID: On Wed, Sep 18, 2024 at 9:54 PM Bakul Shah wrote: > > On Sep 18, 2024, at 5:53 PM, Dan Cross wrote: > > On Wed, Sep 18, 2024 at 8:05 PM Bakul Shah via TUHS wrote: > >> Can you not avoid resetting the machine? This can be treated almost as sleep in the old kernel, wakeup in the new one! You do have to reset devices individually (which may not always work if it requires assistance from some undocumented firmware). > > > > Perhaps this is what you mean when you mention assistance from > > firmware, Bakul, but it may be useful to consider that _many_ devices > > are touched by e.g. a BIOS or UEFI or whatever well before the OS is > > even loaded. > > Right but presumably the old kernel leaves them in a good enough state. I suspect this is one of the thornier parts of the whole problem. In some sense, kexec is similar to live migration of a VM: it's certainly possible to do, but in particular devices have to be quiesced and in a state where they are ready to migrate; outstanding IOs may cause problems with synchronization between the source and destination. Similarly, if the outgoing kernel in a kexec cannot adequately ensure that device state is going to be (at a minimum) discoverable in the incoming kernel, you're going to have a bad time. If there's an outstanding DMA request? Well, good luck, but you're likely going to have a bad day.... > > If one steps back and considers the utility of a BIOS/UEFI (and I > > often lump these into the same category), there are three principal > > reasons for it: 1) back in the bad old days, we could offload common > > IO functions into code stored on a ROM, freeing up precious RAM for > > programs. 2) firmware provides a layer of indirection between the > > system and the host software, allowing both to vary while continuing > > to work with newer versions of the other. And finally 3) firmware > > facilitates bootstrapping the system by providing the host some way to > > access devices and locate and load an OS image, er, before the OS > > image is loaded. SOMETHING has to get enough code loaded from > > somewhere to start the system; often times that's firmware. > > The new OS image is already in memory but may need to be copied to > the right place. The devices were already working (but may need to > have their interrupts disabled and any DMA stopped etc.). Yes, sorry, I was trying to explain why firmware is in the loop for those who may not be familiar. > > Anyway, the last two suggest that device state can be arbitrarily > > munged before the OS takes over, and an actual reset at the device > > level might wipe out some state the OS depends on. Consider, for > > example, programming PCI BARs; on a "modern" x86-64 system with UEFI, > > this is done by firmware in the PEI layer, and the OS may expect that > > to already be set up by the time it is probing buses. An actual > > honest-to-goodness reset will probably wipe the BARs, requiring the > > host OS to program them (ironically, many OSes are already equipped to > > do so, as they have to handle these cases for e.g. PCI hotplug events, > > though many don't do it in the "ordinary" discovery and initialization > > phase of boot). > > All that is done on powerup. That's true, but it's non-trivial, and done by opaque firmware that one has no control over; in particular, it's hard to get the firmware to cooperate in the kexec protocol. > > I suppose the point is that a reset is great because it really does > > wipe out state, but it may also be a bummer because, well, it really > > does wipe out state. :-) > > :-) I was speculating that kernel to kernel warmboot should be doable. Oh sorry; I think I misunderstood that and thought you were asking, "why can't you reset the machine?" Apologies there; my bad. I absolutely agree that it is doable, and that we have several existence proofs showing just that. - Dan C. From jnc at mercury.lcs.mit.edu Fri Sep 20 05:10:44 2024 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 19 Sep 2024 15:10:44 -0400 (EDT) Subject: [TUHS] kernel boots kernel in 1977 Message-ID: <20240919191044.E539318C08D@mercury.lcs.mit.edu> > From: Ron Minnich > Ed got tired of watching the bootstrap slowness This may be a dumb question (in which case, my apologies), but which part of booting a PDP-11 UNIX was slow? And thus, which parts did he bypass in a 'quick reboot'? (I'm having a bit of a hard time working it out.) I can think of the following stages as potentially being 'slow': 1 - reading in the kernel image from disk 2 - sizing/clearing main memory 3 - loading running /etc/init 3A - creating all the 'loqin's 3B - starting all the daemons/etc with /etc/rc (There's obviously a conflict between 2 and 3*; one can't avoid 3* if one does 2.) Which ones did he want to avoid? Avoiding 3* puts some limitations on the system, obviously, because it means one has to keep running processes around; the process table has to have the same format (and be in the same location - or it has to be moved before the new system is started). (Technically, I guess one would have to save the inode and file tables, too; there isn't enough saved data in the kernel to re-open files, plus there are file read/write ocation pointers, etc.) One could sort of do 2 also, if one were prepared to 1) swap all processes out to secondary storage before 'rebooting', and ii) saving the process table. > But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" > or was there something before? Are you talking about for UNIX, or across all operating systems? I don't have that broad a memory any more, to know - did TWENEX have something like that? Noel From rminnich at gmail.com Fri Sep 20 05:42:45 2024 From: rminnich at gmail.com (ron minnich) Date: Thu, 19 Sep 2024 12:42:45 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: <20240919191044.E539318C08D@mercury.lcs.mit.edu> References: <20240919191044.E539318C08D@mercury.lcs.mit.edu> Message-ID: It's been too long. Plus, for all I know, it may have been a "wouldn't this be cool" project that did not work out. I don't recall that we ended up using it much. But that was almost 50 years ago, so your guess is as good as mine. It was for sure a cute hack. On Thu, Sep 19, 2024 at 12:10 PM Noel Chiappa wrote: > > From: Ron Minnich > > > Ed got tired of watching the bootstrap slowness > > This may be a dumb question (in which case, my apologies), but which part > of > booting a PDP-11 UNIX was slow? And thus, which parts did he bypass in a > 'quick reboot'? (I'm having a bit of a hard time working it out.) I can > think > of the following stages as potentially being 'slow': > > 1 - reading in the kernel image from disk > 2 - sizing/clearing main memory > 3 - loading running /etc/init > 3A - creating all the 'loqin's > 3B - starting all the daemons/etc with /etc/rc > > (There's obviously a conflict between 2 and 3*; one can't avoid 3* if one > does 2.) > > Which ones did he want to avoid? > > Avoiding 3* puts some limitations on the system, obviously, because it > means > one has to keep running processes around; the process table has to have the > same format (and be in the same location - or it has to be moved before the > new system is started). (Technically, I guess one would have to save the > inode and file tables, too; there isn't enough saved data in the kernel to > re-open files, plus there are file read/write ocation pointers, etc.) > > One could sort of do 2 also, if one were prepared to 1) swap all processes > out to secondary storage before 'rebooting', and ii) saving the process > table. > > > But I'm wondering: is Ed's work in 1977 the first "kernel boots > kernel" > > or was there something before? > > Are you talking about for UNIX, or across all operating systems? I don't > have > that broad a memory any more, to know - did TWENEX have something like > that? > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Sep 20 10:20:08 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 20 Sep 2024 02:20:08 +0200 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: <3B4CF41C-3D88-471D-B5E7-6F06C772F5E7@iitbombay.org> References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> <3B4CF41C-3D88-471D-B5E7-6F06C772F5E7@iitbombay.org> Message-ID: <20240920002008.GNa8hQD7@steffen%sdaoden.eu> Bakul Shah via TUHS wrote in <3B4CF41C-3D88-471D-B5E7-6F06C772F5E7 at iitbombay.org>: |Forget "rings". Unix needs only two states from hardware. |Forget virtualization for now as well. | |The kernel runs in the supervisor state, the user code in the |unprivileged state where it can't execute or see certain |instructions or processor state or peripherals and must make |system calls for controlled access to the same. | |In addition Unix has the "root" user that can access much more |but it too must go through the system call interface. | |A "warm reboot" system call would simply arrange things so that |the new kernel image is copied in the right place and control |will eventually pass to it. | |It is not so simple these days as the hardware is much more |complex and often requires vendor provided firmware assist |to properly initialize the system before control gets passed |to an OS kernel but no change in the protection model is |required for a kernel to kernel handoff. It seems to me it is worse. The Linux driver of my WLAN chip would (i have forgotten the condition, but anyhow) leave the chip in some false state, and it could not be overcome except by booting into the (minimzed as much as possible: 31.4G) by-default installed Windows, up to the login screen, by then it would have been fixed. This was with the RTW88 driver, it was ok iirc in 4.19, which had another one. Somewhere i have found someone saying one has to pass an argument, i asked for documentation i think even via bugzilla, but nothing ever happened. But it worked (and the driver became better, and i think firmware also, both "a bit"), and now it is luckily stable again for some years. I do not know whether the flag is still needed... KEXEC_ARGS="--append=\"rtw88_pci.disable_aspm=1 rc.hostname=kent\"" --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) From tuhs at tuhs.org Fri Sep 20 12:25:22 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Thu, 19 Sep 2024 19:25:22 -0700 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: <20240920002008.GNa8hQD7@steffen%sdaoden.eu> References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> <3B4CF41C-3D88-471D-B5E7-6F06C772F5E7@iitbombay.org> <20240920002008.GNa8hQD7@steffen%sdaoden.eu> Message-ID: > On Sep 19, 2024, at 5:20 PM, Steffen Nurpmeso wrote: > > Bakul Shah via TUHS wrote in > <3B4CF41C-3D88-471D-B5E7-6F06C772F5E7 at iitbombay.org>: > |Forget "rings". Unix needs only two states from hardware. > |Forget virtualization for now as well. > | > |The kernel runs in the supervisor state, the user code in the > |unprivileged state where it can't execute or see certain > |instructions or processor state or peripherals and must make > |system calls for controlled access to the same. > | > |In addition Unix has the "root" user that can access much more > |but it too must go through the system call interface. > | > |A "warm reboot" system call would simply arrange things so that > |the new kernel image is copied in the right place and control > |will eventually pass to it. > | > |It is not so simple these days as the hardware is much more > |complex and often requires vendor provided firmware assist > |to properly initialize the system before control gets passed > |to an OS kernel but no change in the protection model is > |required for a kernel to kernel handoff. > > It seems to me it is worse. The Linux driver of my WLAN chip > would (i have forgotten the condition, but anyhow) leave the chip > in some false state, and it could not be overcome except by > booting into the (minimzed as much as possible: 31.4G) by-default > installed Windows, up to the login screen, by then it would have > been fixed. This was with the RTW88 driver, it was ok iirc in > 4.19, which had another one. Somewhere i have found someone > saying one has to pass an argument, i asked for documentation > i think even via bugzilla, but nothing ever happened. But it > worked (and the driver became better, and i think firmware also, > both "a bit"), and now it is luckily stable again for some years. > I do not know whether the flag is still needed... > > KEXEC_ARGS="--append=\"rtw88_pci.disable_aspm=1 rc.hostname=kent\"" I don't see how "it is worse". From paul.winalski at gmail.com Fri Sep 20 23:33:32 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 20 Sep 2024 09:33:32 -0400 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: References: Message-ID: On Thu, Sep 19, 2024 at 7:52 PM Rich Salz wrote: > > In my first C programming job I saw the source to V7 grep which had a > "foo[-2]" construct. > That sort of thing is very dangerous with modern compilers. Does K&R C require that variables be allocated in the order that they are declared? If not, you're playing with fire. To get decent performance out of modern processors, the compiler must perform data placement to maximize cache efficiency, and that practically guarantees that you can't rely on out-of-bounds array references. Unless "foo" were a pointer that the programmer explicitly pointed to the inside of a larger data structure. In that case you could guarantee that the construct would work reliably. But by pointing into the middle of another data structure you've created a data aliasing situation, and that complicates compiler data flow analysis and can block important optimizations. Things were much simpler when V7 was written. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Sep 21 01:07:11 2024 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 21 Sep 2024 01:07:11 +1000 (AEST) Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: References: Message-ID: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> On Fri, 20 Sep 2024, Paul Winalski wrote: > On Thu, Sep 19, 2024 at 7:52 PM Rich Salz wrote: > > In my first C programming job I saw the source to V7 grep which > had a "foo[-2]" construct. > > That sort of thing is very dangerous with modern compilers.  Does K&R C > require that variables be allocated in the order that they are declared?  If > not, you're playing with fire.  To get decent performance out of modern > processors, the compiler must perform data placement to maximize cache > efficiency, and that practically guarantees that you can't rely on > out-of-bounds array references. [...] Unless I'm mistaken (quite possible at my age), the OP was referring to that in C, pointers and arrays are pretty much the same thing i.e. "foo[-2]" means "take the pointer 'foo' and go back two things" (whatever a "thing" is). C is just a high level assembly language; there is no such object as a "string" for example: it's just an "array of char" with the last element being "\0" (viz: "strlen" vs. "sizeof". What's the length of "abc" vs. how many bytes are needed to store it? > Things were much simpler when V7 was written. Giggle... In a device driver I wrote for V6, I used the expression "0123"[n] and the two programmers whom I thought were better than me had to ask me what it did... -- Dave, brought up on PDP-11 Unix[*] [*] I still remember the days of BOS/PICK/etc, and I staked my career on Unix. From douglas.mcilroy at dartmouth.edu Sat Sep 21 01:24:16 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 20 Sep 2024 11:24:16 -0400 Subject: [TUHS] Maximum Array Sizes in 16 bit C Message-ID: Apropos of the virtue of negative subscripts. > by pointing into the middle of another data structure you've created a data aliasing situation Not if all references are relative to the offset pointer. The following example is silly, but I recently used exactly this trick to simplify calculations on a first-quadrant (x,y) grid by supplying "out-of-bounds" zeroes at (x,-2), (x,-1) and (-1,y). It was much cleaner to access the zeroes like ordinary elements than to provide special code to handle the boundary conditions. /* Fill an N-element array with Fibonacci numbers, f(i), where 0<=i From rich.salz at gmail.com Sat Sep 21 01:26:46 2024 From: rich.salz at gmail.com (Rich Salz) Date: Fri, 20 Sep 2024 11:26:46 -0400 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: References: Message-ID: > > Unless "foo" were a pointer that the programmer explicitly pointed to the > inside of a larger data structure. > It was that. Go look at the source (I included the link) if you want. This was in the context of a sub-thread about array indices, after all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Sep 21 01:30:44 2024 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 20 Sep 2024 08:30:44 -0700 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> References: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> Message-ID: <20240920153044.GE8905@mcvoy.com> On Sat, Sep 21, 2024 at 01:07:11AM +1000, Dave Horsfall wrote: > On Fri, 20 Sep 2024, Paul Winalski wrote: > > > On Thu, Sep 19, 2024 at 7:52???PM Rich Salz wrote: > > > > In my first C programming job I saw the source to V7 grep which > > had a "foo[-2]" construct. > > > > That sort of thing is very dangerous with modern compilers.?? Does K&R C > > require that variables be allocated in the order that they are declared??? If > > not, you're playing with fire.?? To get decent performance out of modern > > processors, the compiler must perform data placement to maximize cache > > efficiency, and that practically guarantees that you can't rely on > > out-of-bounds array references. > > [...] > > Unless I'm mistaken (quite possible at my age), the OP was referring to > that in C, pointers and arrays are pretty much the same thing i.e. > "foo[-2]" means "take the pointer 'foo' and go back two things" (whatever > a "thing" is). Yes, but that was a stack variable. Let me see if I can say it more clearly. foo() { int a = 1, b = 2; int alias[5]; alias[-2] = 0; // try and set a to 0. } In v7 days, the stack would look like [stuff] [2 bytes for a] [2 bytes for b] [2 bytes for the alias address, which I think points forward] [10 bytes for alias contents] I'm hazy on how the space for alias[] is allocated, so I made that up. It's probably something like I said but Paul (or someone) will correct me. When using a negative index for alias[], the coder is assuming that the stack variables are placed in the order they were declared. Paul tried to explain that _might_ be true but is not always true. Modern compilers will look see which variables are used the most in the function, and place them next to each other so that if you have the cache line for one heavily used variable, the other one is right there next to it. Like so: int heavy1 = 1; int rarely1 = 2; int spacer[10]; int heavy2 = 3; int rarel2 = 4; The compiler might figure out that heavy{1,2} are used a lot and lay out the stack like so: [2 bytes (or 4 or 8 these days) for heavy1] [bytes for heavy2] [bytes for rarely1] [bytes for spacer[10]] [bytes for rarely2] Paul was saying that using a negative index in the array creates an alias, or another name, for the scalar integer on the stack (his description made me understand, for the first time in decades, why compiler writers hate aliases and I get it now). Aliases mess hard with optimizers. Optimizers may reorder the stack for better cache line usage and what you think array[-2] means doesn't work any more unless the optimizer catches that you made an alias and preserves it. Paul, how did I do? I'm not a compiler guy, just had to learn enough to walk the stack when the kernel panics. From stuff at riddermarkfarm.ca Sat Sep 21 01:56:16 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Fri, 20 Sep 2024 11:56:16 -0400 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> References: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> Message-ID: Moved to COFF. On 2024-09-20 11:07, Dave Horsfall wrote (in part): > > Giggle... In a device driver I wrote for V6, I used the expression > > "0123"[n] > > and the two programmers whom I thought were better than me had to ask me > what it did... > > -- Dave, brought up on PDP-11 Unix[*] > > [*] > I still remember the days of BOS/PICK/etc, and I staked my career on Unix. Working on embedded systems, we often used constructs such as a[-4] to either read or modify stuff on the stack (for that particular compiler+processor only). S. From crossd at gmail.com Sat Sep 21 02:14:07 2024 From: crossd at gmail.com (Dan Cross) Date: Fri, 20 Sep 2024 12:14:07 -0400 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> References: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> Message-ID: On Fri, Sep 20, 2024 at 11:17 AM Dave Horsfall wrote: > On Fri, 20 Sep 2024, Paul Winalski wrote: > > On Thu, Sep 19, 2024 at 7:52 PM Rich Salz wrote: > > In my first C programming job I saw the source to V7 grep which > > had a "foo[-2]" construct. > > > > That sort of thing is very dangerous with modern compilers. Does K&R C > > require that variables be allocated in the order that they are declared? If > > not, you're playing with fire. To get decent performance out of modern > > processors, the compiler must perform data placement to maximize cache > > efficiency, and that practically guarantees that you can't rely on > > out-of-bounds array references. > > [...] > > Unless I'm mistaken (quite possible at my age), the OP was referring to > that in C, pointers and arrays are pretty much the same thing i.e. > "foo[-2]" means "take the pointer 'foo' and go back two things" (whatever > a "thing" is). Where I've usually seen this idiom is in things like: char foo[10]; char *p = foo + 5; p[-2] = 'a'; /* set foo[3] to 'a' */ But as Paul pointed out, a) this relies on aliasing the bytes in `foo`, and b) is UB if the (negative) index falls below the beginning of the underlying object (e.g., the array `foo`). > C is just a high level assembly language; there is no such object as a > "string" for example: it's just an "array of char" with the last element > being "\0" (viz: "strlen" vs. "sizeof". Sadly, this hasn't been true for a few decades; arguably since optimizing compilers for C started to become common in the 70s. Trying to treat C as a high-level macro assembler is dangerous, as Paul pointed out, even though a lot of us feel like we can "see" the assembly that a line of C code will likely emit. While in many cases we are probably right (or close to it), C _compiler writers_ don't think in those terms, but rather think in terms of operations targeting the abstract virtual machine loosely described by the language standard. Caveat emptor, there be dragons. > What's the length of "abc" vs. how many bytes are needed to store it? > > > Things were much simpler when V7 was written. > > Giggle... In a device driver I wrote for V6, I used the expression > > "0123"[n] > > and the two programmers whom I thought were better than me had to ask me > what it did... Fortunately, this is still legal. :-) - Dan C. From g.branden.robinson at gmail.com Sat Sep 21 03:11:26 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 20 Sep 2024 12:11:26 -0500 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> References: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> Message-ID: <20240920171126.vgtl23xwj37kardb@illithid> At 2024-09-21T01:07:11+1000, Dave Horsfall wrote: > Unless I'm mistaken (quite possible at my age), the OP was referring > to that in C, pointers and arrays are pretty much the same thing i.e. > "foo[-2]" means "take the pointer 'foo' and go back two things" > (whatever a "thing" is). "in C, pointers and arrays are pretty much the same thing" is a common utterance but misleading, and in my opinion, better replaced with a different one. We should instead say something more like: In C, pointers and arrays have compatible dereference syntaxes. They do _not_ have compatible _declaration_ syntaxes. Chapter 4 of van der Linden's _Expert C Programming_: Deep C Secrets_ (1994) tackles this issue head-on and at length. Here's the salient point. "Consider the case of an external declaration `extern char *p;` but a definition of `char p[10];`. When we retrieve the contents of `p[i]` using the extern, we get characters, but we treat it as a pointer. Interpreting ASCII characters as an address is garbage, and if you're lucky the program will coredump at that point. If you're not lucky it will corrupt something in your address space, causing a mysterious failure at some point later in the program." > C is just a high level assembly language; I disagree with this common claim too. Assembly languages correspond to well-defined machine models.[1] Those machine models have memory models. C has no memory model--deliberately, because that would have gotten in the way of performance. (In practice, C's machine model was and remains the PDP-11,[2] with aspects thereof progressively sanded off over the years in repeated efforts to salvage the language's reputation for portability.) > there is no such object as a "string" for example: it's just an "array > of char" with the last element being "\0" (viz: "strlen" vs. "sizeof". Yeah, it turns out we need a well-defined string type much more powerfully than, it seems, anyone at the Bell Labs CSRC appreciated. string.h was tacked on (by Nils-Peter Nelson, as I understand it) at the end of the 1970s and C aficionados have defended the language's purported perfection with such vigor that they annexed the haphazardly assembled standard library into the territory that they defend with much rhetorical violence and overstatement. From useless or redundant return values to const-carelessness to Schlemiel the Painter algorithms in implementations, it seems we've collectively made every mistake that could be made with Nelson's original, minimal API, and taught those mistakes as best practices in tutorials and classrooms. A sorry affair. So deep was this disdain for the string as a well-defined data type, and moreover one conceptually distinct from an array (or vector) of integral types that Stroustrup initially repeated the mistake in C++. People can easily roll their own, he seemed to have thought. Eventually he thought again, but C++ took so long to get standardized that by then, damage was done. "A string is just an array of `char`s, and a `char` is just a byte"--another hasty equivalence that surrendered a priceless hostage to fortune. This is the sort of fallacy indulged by people excessively wedded to machine language programming and who apply its perspective to every problem statement uncritically. Again and again, with signed vs. unsigned bytes, "wide" vs. "narrow" characters, and "base" vs. "combining" characters, the champions of the "portable assembly" paradigm charged like Lord Cardigan into the pike and musket lines of the character type as one might envision it in a machine register. (This insistence on visualizing register-level representations has prompted numerous other stupidities, like the use of an integral zero at the _language level_ to represent empty, null, or false literals for as many different data types as possible. "If it ends up as a zero in a register," the thinking appears to have gone, "it should look like a zero in the source code." Generations of code--and language--cowboys have screwed us all over repeatedly with this hasty equivalence. Type theorists have known better for decades. But type theory is (1) hard (it certainly is, to cowboys) and (2) has never enjoyed a trendy day in the sun (for which we may be grateful), which means that is seldom on the path one anticipates to a comfortable retirement from a Silicon Valley tech company (or several) on a private yacht. Why do I rant so splenetically about these issues? Because the result of such confusion is _bugs in programs_. You want something concrete? There it is. Data types protect you from screwing up. And the better your data types are, the more care you give to specifying what sorts of objects your program manipulates, the more thought you give to the invariants that must be maintained for your program to remain in a well-defined state, the fewer bugs you will have. But, nah, better to slap together a prototype, ship it, talk it up to the moon as your latest triumph while interviewing with a rival of the company you just delivered that prototype to, and look on in amusement when your brilliant achievement either proves disastrous in deployment or soaks up the waking hours of an entire team of your former colleagues cleaning up the steaming pile you voided from your rock star bowels. We've paid a heavy price for C's slow and seemingly deeply grudging embrace of the type concept. (The lack of controlled scope for enumeration constants is one example; the horrifyingly ill-conceived choice of "typedef" as a keyword indicating _type aliasing_ is another.) Kernighan did not help by trashing Pascal so hard in about 1980. He was dead right that Pascal needed, essentially, polymorphic subprograms in array types. Wirth not speccing the language to accommodate that back in 1973 or so was a sad mistake. But Pascal got a lot of other stuff right--stuff that the partisanship of C advocates refused to countenance such that they ended up celebrating C's flaws as features. No amount of Jonestown tea could quench their thirst. I suspect the truth was more that they didn't want to bother having to learn any other languages. (Or if they did, not any language that anyone else on their team at work had any facility with.) A rock star plays only one instrument, no? People didn't like it when Eddie Van Halen played keyboards instead of guitar on stage, so he stopped doing that. The less your coworkers understand your work, the more of a genius you must be. Now, where was I? > What's the length of "abc" vs. how many bytes are needed to store it? Even what is meant by "length" has several different correct answers! Quantity of code points in the sequence? Number of "grapheme clusters" a.k.a. "user-perceived characters" as Unicode puts it? Width as represented on the output device? On an ASCII device these usually had the same answer (control characters excepted). But even at the Bell Labs CSRC in the 1970s, thanks to troff, the staff knew that they didn't necessarily have to. (How wide is an em dash? How many bytes represent it, in the formatting language and in the output language?) > Giggle... In a device driver I wrote for V6, I used the expression > > "0123"[n] > > and the two programmers whom I thought were better than me had to ask > me what it did... > > -- Dave, brought up on PDP-11 Unix[*] I enjoy this application of that technique, courtesy of Alan Cox. fsck-fuzix: blow 90 bytes on a progress indicator static void progress(void) { static uint8_t progct; progct++; progct&=3; printf("%c\010", "-\\|/"[progct]); fflush(stdout); } > I still remember the days of BOS/PICK/etc, and I staked my career on > Unix. Not a bad choice. Your exposure to and recollection of other ways of doing things, I suspect, made you a more valuable contributor than those who mazed themselves with thoughts of "the Unix way" to the point that they never seriously considered any other. It's fine to prefer "the C way" or "the Unix way", if you can intelligibly define what that means as applied to the issue in dispute, and coherently defend it. Demonstrating an understanding of the alternatives, and being able to credibly explain why they are inferior approaches, is how to do advocacy correctly. But it is not the cowboy way. The rock star way. Regards, Branden [1] Unfortunately I must concede that this claim is less true than it used to be thanks to the relentless pursuit of trade-secret means of optimizing hardware performance. Assembly languages now correspond, particularly on x86, to a sort of macro language that imperfectly masks a massive amount of microarchitectural state that the implementors themselves don't completely understand, at least not in time to get the product to market. Hence the field day of speculative execution attacks and similar. It would not be fair to say that CPUs of old had _no_ microarchitectural state--the Z80, for example, had the not-completely-official `W` and `Z` registers--but they did have much less of it, and correspondingly less attack surface for screwing your programs. I do miss the days of deterministic cycle counts for instruction execution. But I know I'd be sad if all the caches on my workaday machine switched off. [2] https://queue.acm.org/detail.cfm?id=3212479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From leah at vuxu.org Sat Sep 21 05:40:10 2024 From: leah at vuxu.org (Leah Neukirchen) Date: Fri, 20 Sep 2024 21:40:10 +0200 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: (Rich Salz's message of "Thu, 19 Sep 2024 09:13:11 -0400") References: Message-ID: <871q1e5d2d.fsf@vuxu.org> Rich Salz writes: >> >> if there need to be negative references in array accesses (which certainly >> makes sense to me, on its face), it seems reasonable to have whatever >> intermediate variable be signed. >> > > In my first C programming job I saw the source to V7 grep which had a > "foo[-2]" construct. It was a moment of enlightenment and another bit of > K&R fell into place. ( > https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/grep.c; search > for "[-") Now this thread already derailed into C undefined behavior semantics, but nobody bothered to look at the actual code, which is perfectly fine: if ((c = *sp++) != '*') lastep = ep; switch (c) { ... case '[': ... neg = 0; if((c = *sp++) == '^') { neg = 1; c = *sp++; } cstart = sp; do { ... if (c=='-' && sp>cstart && *sp!=']') { for (c = sp[-2]; c<*sp; c++) ep[c>>3] |= bittab[c&07]; sp++; } ep[c>>3] |= bittab[c&07]; } while((c = *sp++) != ']'); Since sp has been incremented twice already, accessing sp[-2] is fine in any case, but it's also guarded by cstart, so the regexp range "[-z]" doesn't expand to [[-z]. -- Leah Neukirchen https://leahneukirchen.org/ From tuhs at cuzuco.com Sat Sep 21 05:47:26 2024 From: tuhs at cuzuco.com (Brian Walden) Date: Fri, 20 Sep 2024 15:47:26 -0400 (EDT) Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: Message-ID: <202409201947.48KJlQdk025684@cuzuco.com> I can see an immedaite advantage in 1 - reading in the kernel image from disk As late as August of 1983, as that's the last time I had to do it, there were still systems in operation that you had to manually input the boot loader by hand using front panel switches. See https://gunkies.org/wiki/PDP-11_Bootstrap_Loader -Brian > ron minnich rminnich at gmail.com > Fri Sep 20 05:42:45 AEST 2024 > > > It's been too long. Plus, for all I know, it may have been a "wouldn't this > be cool" project that did not work out. I don't recall that we ended up > using it much. But that was almost 50 years ago, so your guess is as good > as mine. > > It was for sure a cute hack. > > On Thu, Sep 19, 2024 at 12:10b/PM Noel Chiappa > wrote: > > > > From: Ron Minnich > > > > > Ed got tired of watching the bootstrap slowness > > > > This may be a dumb question (in which case, my apologies), but which part > > of > > booting a PDP-11 UNIX was slow? And thus, which parts did he bypass in a > > 'quick reboot'? (I'm having a bit of a hard time working it out.) I can > > think > > of the following stages as potentially being 'slow': > > > > 1 - reading in the kernel image from disk > > 2 - sizing/clearing main memory > > 3 - loading running /etc/init > > 3A - creating all the 'loqin's > > 3B - starting all the daemons/etc with /etc/rc > > > > (There's obviously a conflict between 2 and 3*; one can't avoid 3* if one > > does 2.) > > > > Which ones did he want to avoid? > > > > Avoiding 3* puts some limitations on the system, obviously, because it > > means > > one has to keep running processes around; the process table has to have the > > same format (and be in the same location - or it has to be moved before the > > new system is started). (Technically, I guess one would have to save the > > inode and file tables, too; there isn't enough saved data in the kernel to > > re-open files, plus there are file read/write ocation pointers, etc.) > > > > One could sort of do 2 also, if one were prepared to 1) swap all processes > > out to secondary storage before 'rebooting', and ii) saving the process > > table. > > > > > But I'm wondering: is Ed's work in 1977 the first "kernel boots > > kernel" > > > or was there something before? > > > > Are you talking about for UNIX, or across all operating systems? I don't > > have > > that broad a memory any more, to know - did TWENEX have something like > > that? > > > > Noel From tuhs at tuhs.org Sat Sep 21 06:03:27 2024 From: tuhs at tuhs.org (John Floren via TUHS) Date: Fri, 20 Sep 2024 13:03:27 -0700 Subject: [TUHS] Free computing books in SF area Message-ID: <87wmj65bl3.fsf@thufir.floren.lan> It's a bit off-topic but Warren OK'd it: I'm trying to tidy the absolute dragon's hoard I call an office, so I'm looking to give away some books I haven't touched in years. These are free for the taking for anybody who wants to drive to SF and get them. I'd really prefer for somebody to take them all at once, of course. - DEC PDP11/70 Processor Handbook - DEC VAX11 Architecture Handbook - DEC PDP11 Peripherals and Interfacing Handbook - DEC Introduction to Programming (PDP-8) - Programming Languages: History and Fundamentals (Sammet) - Computer Networks, 1st ed (Tanenbaum) - Modern Operating Systems, 2nd ed (Tanenbaum) - Operating Systems Design and Implementation, 1st ed (Tanenbaum) - Advanced Programming in the UNIX Environment (Stevens) - Computer Architecture and Organization, 2nd ed (Hayes) - Compilers: Principles, Techniques, and Tools (Aho, Sethi, Ullman) - The Undocumented PC, 2nd ed (van Gilluwe) - Cybernetics (Wiener) If you want these, please email me *off-list* to set it up. John From tuhs at tuhs.org Sat Sep 21 06:16:24 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 20 Sep 2024 13:16:24 -0700 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: <20240920171126.vgtl23xwj37kardb@illithid> References: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> <20240920171126.vgtl23xwj37kardb@illithid> Message-ID: <69643008-F7FE-4AC7-8519-B45E4C1CEA66@iitbombay.org> You are a bit late with your screed. You will find posts with similar sentiments starting back in 1980s in Usenet groups such as comp.lang.{c,misc,pascal}. Perhaps a more interesting (but likely pointless) question is what is the *least* that can be done to fix C's major problems. Compilers can easily add bounds checking for the array[index] construct but ptr[index] can not be checked, unless we make a ptr a heavy weight object such as (address, start, limit). One can see how code can be generated for code such as this: Foo x[count]; Foo* p = x + n; // or &x[n] Code such as "Foo *p = malloc(size);" would require the compiler to know how malloc behaves to be able to compute the limit. But for a user to write a similar function will require some language extension. [Of course, if we did that, adding proper support for multidimensional slices would be far easier. But that is an exploration for another day!] Converting enums to behave like Pascal scalars would likely break things. The question is, can such breakage be fixed automatically (by source code conversion)? C's union type is used in two different ways: 1: similar to a sum type, which can be done type safely and 2: to cheat. The compiler should produce a warning when it can't verify a typesafe use -- one can add "unsafe" or some such to let the user absolve the compiler of such check. [May be naively] I tend to think one can evolve C this way and fix a lot of code &/or make a lot of bugs more explicit. > On Sep 20, 2024, at 10:11 AM, G. Branden Robinson wrote: > > At 2024-09-21T01:07:11+1000, Dave Horsfall wrote: >> Unless I'm mistaken (quite possible at my age), the OP was referring >> to that in C, pointers and arrays are pretty much the same thing i.e. >> "foo[-2]" means "take the pointer 'foo' and go back two things" >> (whatever a "thing" is). > > "in C, pointers and arrays are pretty much the same thing" is a common > utterance but misleading, and in my opinion, better replaced with a > different one. > > We should instead say something more like: > > In C, pointers and arrays have compatible dereference syntaxes. > > They do _not_ have compatible _declaration_ syntaxes. > > Chapter 4 of van der Linden's _Expert C Programming_: Deep C Secrets_ > (1994) tackles this issue head-on and at length. > > Here's the salient point. > > "Consider the case of an external declaration `extern char *p;` but a > definition of `char p[10];`. When we retrieve the contents of `p[i]` > using the extern, we get characters, but we treat it as a pointer. > Interpreting ASCII characters as an address is garbage, and if you're > lucky the program will coredump at that point. If you're not lucky it > will corrupt something in your address space, causing a mysterious > failure at some point later in the program." > >> C is just a high level assembly language; > > I disagree with this common claim too. Assembly languages correspond to > well-defined machine models.[1] Those machine models have memory > models. C has no memory model--deliberately, because that would have > gotten in the way of performance. (In practice, C's machine model was > and remains the PDP-11,[2] with aspects thereof progressively sanded off > over the years in repeated efforts to salvage the language's reputation > for portability.) > >> there is no such object as a "string" for example: it's just an "array >> of char" with the last element being "\0" (viz: "strlen" vs. "sizeof". > > Yeah, it turns out we need a well-defined string type much more > powerfully than, it seems, anyone at the Bell Labs CSRC appreciated. > string.h was tacked on (by Nils-Peter Nelson, as I understand it) at the > end of the 1970s and C aficionados have defended the language's > purported perfection with such vigor that they annexed the haphazardly > assembled standard library into the territory that they defend with much > rhetorical violence and overstatement. From useless or redundant return > values to const-carelessness to Schlemiel the Painter algorithms in > implementations, it seems we've collectively made every mistake that > could be made with Nelson's original, minimal API, and taught those > mistakes as best practices in tutorials and classrooms. A sorry affair. > > So deep was this disdain for the string as a well-defined data type, and > moreover one conceptually distinct from an array (or vector) of integral > types that Stroustrup initially repeated the mistake in C++. People can > easily roll their own, he seemed to have thought. Eventually he thought > again, but C++ took so long to get standardized that by then, damage was > done. > > "A string is just an array of `char`s, and a `char` is just a > byte"--another hasty equivalence that surrendered a priceless hostage to > fortune. This is the sort of fallacy indulged by people excessively > wedded to machine language programming and who apply its perspective to > every problem statement uncritically. > > Again and again, with signed vs. unsigned bytes, "wide" vs. "narrow" > characters, and "base" vs. "combining" characters, the champions of the > "portable assembly" paradigm charged like Lord Cardigan into the pike > and musket lines of the character type as one might envision it in a > machine register. (This insistence on visualizing register-level > representations has prompted numerous other stupidities, like the use of > an integral zero at the _language level_ to represent empty, null, or > false literals for as many different data types as possible. "If it > ends up as a zero in a register," the thinking appears to have gone, "it > should look like a zero in the source code." Generations of code--and > language--cowboys have screwed us all over repeatedly with this hasty > equivalence. > > Type theorists have known better for decades. But type theory is (1) > hard (it certainly is, to cowboys) and (2) has never enjoyed a trendy > day in the sun (for which we may be grateful), which means that is > seldom on the path one anticipates to a comfortable retirement from a > Silicon Valley tech company (or several) on a private yacht. > > Why do I rant so splenetically about these issues? Because the result > of such confusion is _bugs in programs_. You want something concrete? > There it is. Data types protect you from screwing up. And the better > your data types are, the more care you give to specifying what sorts of > objects your program manipulates, the more thought you give to the > invariants that must be maintained for your program to remain in a > well-defined state, the fewer bugs you will have. > > But, nah, better to slap together a prototype, ship it, talk it up to > the moon as your latest triumph while interviewing with a rival of the > company you just delivered that prototype to, and look on in amusement > when your brilliant achievement either proves disastrous in deployment > or soaks up the waking hours of an entire team of your former colleagues > cleaning up the steaming pile you voided from your rock star bowels. > > We've paid a heavy price for C's slow and seemingly deeply grudging > embrace of the type concept. (The lack of controlled scope for > enumeration constants is one example; the horrifyingly ill-conceived > choice of "typedef" as a keyword indicating _type aliasing_ is another.) > Kernighan did not help by trashing Pascal so hard in about 1980. He was > dead right that Pascal needed, essentially, polymorphic subprograms in > array types. Wirth not speccing the language to accommodate that back > in 1973 or so was a sad mistake. But Pascal got a lot of other stuff > right--stuff that the partisanship of C advocates refused to countenance > such that they ended up celebrating C's flaws as features. No amount of > Jonestown tea could quench their thirst. I suspect the truth was more > that they didn't want to bother having to learn any other languages. > (Or if they did, not any language that anyone else on their team at work > had any facility with.) A rock star plays only one instrument, no? > People didn't like it when Eddie Van Halen played keyboards instead of > guitar on stage, so he stopped doing that. The less your coworkers > understand your work, the more of a genius you must be. > > Now, where was I? > >> What's the length of "abc" vs. how many bytes are needed to store it? > > Even what is meant by "length" has several different correct answers! > Quantity of code points in the sequence? Number of "grapheme clusters" > a.k.a. "user-perceived characters" as Unicode puts it? Width as > represented on the output device? On an ASCII device these usually had > the same answer (control characters excepted). But even at the Bell > Labs CSRC in the 1970s, thanks to troff, the staff knew that they didn't > necessarily have to. (How wide is an em dash? How many bytes represent > it, in the formatting language and in the output language?) > >> Giggle... In a device driver I wrote for V6, I used the expression >> >> "0123"[n] >> >> and the two programmers whom I thought were better than me had to ask >> me what it did... >> >> -- Dave, brought up on PDP-11 Unix[*] > > I enjoy this application of that technique, courtesy of Alan Cox. > > fsck-fuzix: blow 90 bytes on a progress indicator > > static void progress(void) > { > static uint8_t progct; > progct++; > progct&=3; > printf("%c\010", "-\\|/"[progct]); > fflush(stdout); > } > >> I still remember the days of BOS/PICK/etc, and I staked my career on >> Unix. > > Not a bad choice. Your exposure to and recollection of other ways of > doing things, I suspect, made you a more valuable contributor than those > who mazed themselves with thoughts of "the Unix way" to the point that > they never seriously considered any other. > > It's fine to prefer "the C way" or "the Unix way", if you can > intelligibly define what that means as applied to the issue in dispute, > and coherently defend it. Demonstrating an understanding of the > alternatives, and being able to credibly explain why they are inferior > approaches, is how to do advocacy correctly. > > But it is not the cowboy way. The rock star way. > > Regards, > Branden > > [1] Unfortunately I must concede that this claim is less true than it > used to be thanks to the relentless pursuit of trade-secret means of > optimizing hardware performance. Assembly languages now correspond, > particularly on x86, to a sort of macro language that imperfectly > masks a massive amount of microarchitectural state that the > implementors themselves don't completely understand, at least not in > time to get the product to market. Hence the field day of > speculative execution attacks and similar. It would not be fair to > say that CPUs of old had _no_ microarchitectural state--the Z80, for > example, had the not-completely-official `W` and `Z` registers--but > they did have much less of it, and correspondingly less attack > surface for screwing your programs. I do miss the days of > deterministic cycle counts for instruction execution. But I know > I'd be sad if all the caches on my workaday machine switched off. > > [2] https://queue.acm.org/detail.cfm?id=3212479 From imp at bsdimp.com Sat Sep 21 06:58:26 2024 From: imp at bsdimp.com (Warner Losh) Date: Fri, 20 Sep 2024 21:58:26 +0100 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: <69643008-F7FE-4AC7-8519-B45E4C1CEA66@iitbombay.org> References: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> <20240920171126.vgtl23xwj37kardb@illithid> <69643008-F7FE-4AC7-8519-B45E4C1CEA66@iitbombay.org> Message-ID: On Fri, Sep 20, 2024 at 9:16 PM Bakul Shah via TUHS wrote: > You are a bit late with your screed. You will find posts > with similar sentiments starting back in 1980s in Usenet > groups such as comp.lang.{c,misc,pascal}. > > Perhaps a more interesting (but likely pointless) question > is what is the *least* that can be done to fix C's major > problems. > > Compilers can easily add bounds checking for the array[index] > construct but ptr[index] can not be checked, unless we make > a ptr a heavy weight object such as (address, start, limit). > One can see how code can be generated for code such as this: > > Foo x[count]; > Foo* p = x + n; // or &x[n] > > Code such as "Foo *p = malloc(size);" would require the > compiler to know how malloc behaves to be able to compute > the limit. But for a user to write a similar function will > require some language extension. > > [Of course, if we did that, adding proper support for > multidimensional slices would be far easier. But that > is an exploration for another day!] > The CHERI architecture extensions do this. It pushes this info into hardware where all pointers point to a region (gross simplification) that also grant you rights the area (including read/write/execute). It's really cool, but it does come at a cost in performance. Each pointer is a pointer, and a capacity that's basically a cryptographically signed bit of data that's the bounds and access permissions associated with the pointer. There's more details on their web site: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ CHERI-BSD is a FreeBSD variant that runs on both CHERI variants (aarch64 and riscv64) and where most of the research has been done. There's also a Linux variant as well. Members of this project know way too many of the corner cases of the C language from porting most popular software to the CHERI... And have gone on screeds of their own. The only one I can easily find is https://people.freebsd.org/~brooks/talks/asiabsdcon2017-helloworld/helloworld.pdf Warner > Converting enums to behave like Pascal scalars would > likely break things. The question is, can such breakage > be fixed automatically (by source code conversion)? > > C's union type is used in two different ways: 1: similar > to a sum type, which can be done type safely and 2: to > cheat. The compiler should produce a warning when it can't > verify a typesafe use -- one can add "unsafe" or some such > to let the user absolve the compiler of such check. > > [May be naively] I tend to think one can evolve C this way > and fix a lot of code &/or make a lot of bugs more explicit. > > > On Sep 20, 2024, at 10:11 AM, G. Branden Robinson < > g.branden.robinson at gmail.com> wrote: > > > > At 2024-09-21T01:07:11+1000, Dave Horsfall wrote: > >> Unless I'm mistaken (quite possible at my age), the OP was referring > >> to that in C, pointers and arrays are pretty much the same thing i.e. > >> "foo[-2]" means "take the pointer 'foo' and go back two things" > >> (whatever a "thing" is). > > > > "in C, pointers and arrays are pretty much the same thing" is a common > > utterance but misleading, and in my opinion, better replaced with a > > different one. > > > > We should instead say something more like: > > > > In C, pointers and arrays have compatible dereference syntaxes. > > > > They do _not_ have compatible _declaration_ syntaxes. > > > > Chapter 4 of van der Linden's _Expert C Programming_: Deep C Secrets_ > > (1994) tackles this issue head-on and at length. > > > > Here's the salient point. > > > > "Consider the case of an external declaration `extern char *p;` but a > > definition of `char p[10];`. When we retrieve the contents of `p[i]` > > using the extern, we get characters, but we treat it as a pointer. > > Interpreting ASCII characters as an address is garbage, and if you're > > lucky the program will coredump at that point. If you're not lucky it > > will corrupt something in your address space, causing a mysterious > > failure at some point later in the program." > > > >> C is just a high level assembly language; > > > > I disagree with this common claim too. Assembly languages correspond to > > well-defined machine models.[1] Those machine models have memory > > models. C has no memory model--deliberately, because that would have > > gotten in the way of performance. (In practice, C's machine model was > > and remains the PDP-11,[2] with aspects thereof progressively sanded off > > over the years in repeated efforts to salvage the language's reputation > > for portability.) > > > >> there is no such object as a "string" for example: it's just an "array > >> of char" with the last element being "\0" (viz: "strlen" vs. "sizeof". > > > > Yeah, it turns out we need a well-defined string type much more > > powerfully than, it seems, anyone at the Bell Labs CSRC appreciated. > > string.h was tacked on (by Nils-Peter Nelson, as I understand it) at the > > end of the 1970s and C aficionados have defended the language's > > purported perfection with such vigor that they annexed the haphazardly > > assembled standard library into the territory that they defend with much > > rhetorical violence and overstatement. From useless or redundant return > > values to const-carelessness to Schlemiel the Painter algorithms in > > implementations, it seems we've collectively made every mistake that > > could be made with Nelson's original, minimal API, and taught those > > mistakes as best practices in tutorials and classrooms. A sorry affair. > > > > So deep was this disdain for the string as a well-defined data type, and > > moreover one conceptually distinct from an array (or vector) of integral > > types that Stroustrup initially repeated the mistake in C++. People can > > easily roll their own, he seemed to have thought. Eventually he thought > > again, but C++ took so long to get standardized that by then, damage was > > done. > > > > "A string is just an array of `char`s, and a `char` is just a > > byte"--another hasty equivalence that surrendered a priceless hostage to > > fortune. This is the sort of fallacy indulged by people excessively > > wedded to machine language programming and who apply its perspective to > > every problem statement uncritically. > > > > Again and again, with signed vs. unsigned bytes, "wide" vs. "narrow" > > characters, and "base" vs. "combining" characters, the champions of the > > "portable assembly" paradigm charged like Lord Cardigan into the pike > > and musket lines of the character type as one might envision it in a > > machine register. (This insistence on visualizing register-level > > representations has prompted numerous other stupidities, like the use of > > an integral zero at the _language level_ to represent empty, null, or > > false literals for as many different data types as possible. "If it > > ends up as a zero in a register," the thinking appears to have gone, "it > > should look like a zero in the source code." Generations of code--and > > language--cowboys have screwed us all over repeatedly with this hasty > > equivalence. > > > > Type theorists have known better for decades. But type theory is (1) > > hard (it certainly is, to cowboys) and (2) has never enjoyed a trendy > > day in the sun (for which we may be grateful), which means that is > > seldom on the path one anticipates to a comfortable retirement from a > > Silicon Valley tech company (or several) on a private yacht. > > > > Why do I rant so splenetically about these issues? Because the result > > of such confusion is _bugs in programs_. You want something concrete? > > There it is. Data types protect you from screwing up. And the better > > your data types are, the more care you give to specifying what sorts of > > objects your program manipulates, the more thought you give to the > > invariants that must be maintained for your program to remain in a > > well-defined state, the fewer bugs you will have. > > > > But, nah, better to slap together a prototype, ship it, talk it up to > > the moon as your latest triumph while interviewing with a rival of the > > company you just delivered that prototype to, and look on in amusement > > when your brilliant achievement either proves disastrous in deployment > > or soaks up the waking hours of an entire team of your former colleagues > > cleaning up the steaming pile you voided from your rock star bowels. > > > > We've paid a heavy price for C's slow and seemingly deeply grudging > > embrace of the type concept. (The lack of controlled scope for > > enumeration constants is one example; the horrifyingly ill-conceived > > choice of "typedef" as a keyword indicating _type aliasing_ is another.) > > Kernighan did not help by trashing Pascal so hard in about 1980. He was > > dead right that Pascal needed, essentially, polymorphic subprograms in > > array types. Wirth not speccing the language to accommodate that back > > in 1973 or so was a sad mistake. But Pascal got a lot of other stuff > > right--stuff that the partisanship of C advocates refused to countenance > > such that they ended up celebrating C's flaws as features. No amount of > > Jonestown tea could quench their thirst. I suspect the truth was more > > that they didn't want to bother having to learn any other languages. > > (Or if they did, not any language that anyone else on their team at work > > had any facility with.) A rock star plays only one instrument, no? > > People didn't like it when Eddie Van Halen played keyboards instead of > > guitar on stage, so he stopped doing that. The less your coworkers > > understand your work, the more of a genius you must be. > > > > Now, where was I? > > > >> What's the length of "abc" vs. how many bytes are needed to store it? > > > > Even what is meant by "length" has several different correct answers! > > Quantity of code points in the sequence? Number of "grapheme clusters" > > a.k.a. "user-perceived characters" as Unicode puts it? Width as > > represented on the output device? On an ASCII device these usually had > > the same answer (control characters excepted). But even at the Bell > > Labs CSRC in the 1970s, thanks to troff, the staff knew that they didn't > > necessarily have to. (How wide is an em dash? How many bytes represent > > it, in the formatting language and in the output language?) > > > >> Giggle... In a device driver I wrote for V6, I used the expression > >> > >> "0123"[n] > >> > >> and the two programmers whom I thought were better than me had to ask > >> me what it did... > >> > >> -- Dave, brought up on PDP-11 Unix[*] > > > > I enjoy this application of that technique, courtesy of Alan Cox. > > > > fsck-fuzix: blow 90 bytes on a progress indicator > > > > static void progress(void) > > { > > static uint8_t progct; > > progct++; > > progct&=3; > > printf("%c\010", "-\\|/"[progct]); > > fflush(stdout); > > } > > > >> I still remember the days of BOS/PICK/etc, and I staked my career on > >> Unix. > > > > Not a bad choice. Your exposure to and recollection of other ways of > > doing things, I suspect, made you a more valuable contributor than those > > who mazed themselves with thoughts of "the Unix way" to the point that > > they never seriously considered any other. > > > > It's fine to prefer "the C way" or "the Unix way", if you can > > intelligibly define what that means as applied to the issue in dispute, > > and coherently defend it. Demonstrating an understanding of the > > alternatives, and being able to credibly explain why they are inferior > > approaches, is how to do advocacy correctly. > > > > But it is not the cowboy way. The rock star way. > > > > Regards, > > Branden > > > > [1] Unfortunately I must concede that this claim is less true than it > > used to be thanks to the relentless pursuit of trade-secret means of > > optimizing hardware performance. Assembly languages now correspond, > > particularly on x86, to a sort of macro language that imperfectly > > masks a massive amount of microarchitectural state that the > > implementors themselves don't completely understand, at least not in > > time to get the product to market. Hence the field day of > > speculative execution attacks and similar. It would not be fair to > > say that CPUs of old had _no_ microarchitectural state--the Z80, for > > example, had the not-completely-official `W` and `Z` registers--but > > they did have much less of it, and correspondingly less attack > > surface for screwing your programs. I do miss the days of > > deterministic cycle counts for instruction execution. But I know > > I'd be sad if all the caches on my workaday machine switched off. > > > > [2] https://queue.acm.org/detail.cfm?id=3212479 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sat Sep 21 07:18:28 2024 From: robpike at gmail.com (Rob Pike) Date: Sat, 21 Sep 2024 07:18:28 +1000 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: References: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> <20240920171126.vgtl23xwj37kardb@illithid> <69643008-F7FE-4AC7-8519-B45E4C1CEA66@iitbombay.org> Message-ID: Here is some code from typo. int table[2]; /*keep these four cards in order*/ int tab1[26]; int tab2[730]; char tab3[19684]; ... er = read(salt,table,21200); Note the use of the word 'card'. The past is a different country. -rob On Sat, Sep 21, 2024 at 7:07 AM Warner Losh wrote: > > > On Fri, Sep 20, 2024 at 9:16 PM Bakul Shah via TUHS wrote: > >> You are a bit late with your screed. You will find posts >> with similar sentiments starting back in 1980s in Usenet >> groups such as comp.lang.{c,misc,pascal}. >> >> Perhaps a more interesting (but likely pointless) question >> is what is the *least* that can be done to fix C's major >> problems. >> >> Compilers can easily add bounds checking for the array[index] >> construct but ptr[index] can not be checked, unless we make >> a ptr a heavy weight object such as (address, start, limit). >> One can see how code can be generated for code such as this: >> >> Foo x[count]; >> Foo* p = x + n; // or &x[n] >> >> Code such as "Foo *p = malloc(size);" would require the >> compiler to know how malloc behaves to be able to compute >> the limit. But for a user to write a similar function will >> require some language extension. >> >> [Of course, if we did that, adding proper support for >> multidimensional slices would be far easier. But that >> is an exploration for another day!] >> > > The CHERI architecture extensions do this. It pushes this info into > hardware > where all pointers point to a region (gross simplification) that also > grant you > rights the area (including read/write/execute). It's really cool, but it > does come > at a cost in performance. Each pointer is a pointer, and a capacity that's > basically > a cryptographically signed bit of data that's the bounds and access > permissions > associated with the pointer. There's more details on their web site: > https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ > > CHERI-BSD is a FreeBSD variant that runs on both CHERI variants (aarch64 > and > riscv64) and where most of the research has been done. There's also a > Linux > variant as well. > > Members of this project know way too many of the corner cases of the C > language > from porting most popular software to the CHERI... And have gone on > screeds of > their own. The only one I can easily find is > > https://people.freebsd.org/~brooks/talks/asiabsdcon2017-helloworld/helloworld.pdf > > Warner > > >> Converting enums to behave like Pascal scalars would >> likely break things. The question is, can such breakage >> be fixed automatically (by source code conversion)? >> >> C's union type is used in two different ways: 1: similar >> to a sum type, which can be done type safely and 2: to >> cheat. The compiler should produce a warning when it can't >> verify a typesafe use -- one can add "unsafe" or some such >> to let the user absolve the compiler of such check. >> >> [May be naively] I tend to think one can evolve C this way >> and fix a lot of code &/or make a lot of bugs more explicit. >> >> > On Sep 20, 2024, at 10:11 AM, G. Branden Robinson < >> g.branden.robinson at gmail.com> wrote: >> > >> > At 2024-09-21T01:07:11+1000, Dave Horsfall wrote: >> >> Unless I'm mistaken (quite possible at my age), the OP was referring >> >> to that in C, pointers and arrays are pretty much the same thing i.e. >> >> "foo[-2]" means "take the pointer 'foo' and go back two things" >> >> (whatever a "thing" is). >> > >> > "in C, pointers and arrays are pretty much the same thing" is a common >> > utterance but misleading, and in my opinion, better replaced with a >> > different one. >> > >> > We should instead say something more like: >> > >> > In C, pointers and arrays have compatible dereference syntaxes. >> > >> > They do _not_ have compatible _declaration_ syntaxes. >> > >> > Chapter 4 of van der Linden's _Expert C Programming_: Deep C Secrets_ >> > (1994) tackles this issue head-on and at length. >> > >> > Here's the salient point. >> > >> > "Consider the case of an external declaration `extern char *p;` but a >> > definition of `char p[10];`. When we retrieve the contents of `p[i]` >> > using the extern, we get characters, but we treat it as a pointer. >> > Interpreting ASCII characters as an address is garbage, and if you're >> > lucky the program will coredump at that point. If you're not lucky it >> > will corrupt something in your address space, causing a mysterious >> > failure at some point later in the program." >> > >> >> C is just a high level assembly language; >> > >> > I disagree with this common claim too. Assembly languages correspond to >> > well-defined machine models.[1] Those machine models have memory >> > models. C has no memory model--deliberately, because that would have >> > gotten in the way of performance. (In practice, C's machine model was >> > and remains the PDP-11,[2] with aspects thereof progressively sanded off >> > over the years in repeated efforts to salvage the language's reputation >> > for portability.) >> > >> >> there is no such object as a "string" for example: it's just an "array >> >> of char" with the last element being "\0" (viz: "strlen" vs. "sizeof". >> > >> > Yeah, it turns out we need a well-defined string type much more >> > powerfully than, it seems, anyone at the Bell Labs CSRC appreciated. >> > string.h was tacked on (by Nils-Peter Nelson, as I understand it) at the >> > end of the 1970s and C aficionados have defended the language's >> > purported perfection with such vigor that they annexed the haphazardly >> > assembled standard library into the territory that they defend with much >> > rhetorical violence and overstatement. From useless or redundant return >> > values to const-carelessness to Schlemiel the Painter algorithms in >> > implementations, it seems we've collectively made every mistake that >> > could be made with Nelson's original, minimal API, and taught those >> > mistakes as best practices in tutorials and classrooms. A sorry affair. >> > >> > So deep was this disdain for the string as a well-defined data type, and >> > moreover one conceptually distinct from an array (or vector) of integral >> > types that Stroustrup initially repeated the mistake in C++. People can >> > easily roll their own, he seemed to have thought. Eventually he thought >> > again, but C++ took so long to get standardized that by then, damage was >> > done. >> > >> > "A string is just an array of `char`s, and a `char` is just a >> > byte"--another hasty equivalence that surrendered a priceless hostage to >> > fortune. This is the sort of fallacy indulged by people excessively >> > wedded to machine language programming and who apply its perspective to >> > every problem statement uncritically. >> > >> > Again and again, with signed vs. unsigned bytes, "wide" vs. "narrow" >> > characters, and "base" vs. "combining" characters, the champions of the >> > "portable assembly" paradigm charged like Lord Cardigan into the pike >> > and musket lines of the character type as one might envision it in a >> > machine register. (This insistence on visualizing register-level >> > representations has prompted numerous other stupidities, like the use of >> > an integral zero at the _language level_ to represent empty, null, or >> > false literals for as many different data types as possible. "If it >> > ends up as a zero in a register," the thinking appears to have gone, "it >> > should look like a zero in the source code." Generations of code--and >> > language--cowboys have screwed us all over repeatedly with this hasty >> > equivalence. >> > >> > Type theorists have known better for decades. But type theory is (1) >> > hard (it certainly is, to cowboys) and (2) has never enjoyed a trendy >> > day in the sun (for which we may be grateful), which means that is >> > seldom on the path one anticipates to a comfortable retirement from a >> > Silicon Valley tech company (or several) on a private yacht. >> > >> > Why do I rant so splenetically about these issues? Because the result >> > of such confusion is _bugs in programs_. You want something concrete? >> > There it is. Data types protect you from screwing up. And the better >> > your data types are, the more care you give to specifying what sorts of >> > objects your program manipulates, the more thought you give to the >> > invariants that must be maintained for your program to remain in a >> > well-defined state, the fewer bugs you will have. >> > >> > But, nah, better to slap together a prototype, ship it, talk it up to >> > the moon as your latest triumph while interviewing with a rival of the >> > company you just delivered that prototype to, and look on in amusement >> > when your brilliant achievement either proves disastrous in deployment >> > or soaks up the waking hours of an entire team of your former colleagues >> > cleaning up the steaming pile you voided from your rock star bowels. >> > >> > We've paid a heavy price for C's slow and seemingly deeply grudging >> > embrace of the type concept. (The lack of controlled scope for >> > enumeration constants is one example; the horrifyingly ill-conceived >> > choice of "typedef" as a keyword indicating _type aliasing_ is another.) >> > Kernighan did not help by trashing Pascal so hard in about 1980. He was >> > dead right that Pascal needed, essentially, polymorphic subprograms in >> > array types. Wirth not speccing the language to accommodate that back >> > in 1973 or so was a sad mistake. But Pascal got a lot of other stuff >> > right--stuff that the partisanship of C advocates refused to countenance >> > such that they ended up celebrating C's flaws as features. No amount of >> > Jonestown tea could quench their thirst. I suspect the truth was more >> > that they didn't want to bother having to learn any other languages. >> > (Or if they did, not any language that anyone else on their team at work >> > had any facility with.) A rock star plays only one instrument, no? >> > People didn't like it when Eddie Van Halen played keyboards instead of >> > guitar on stage, so he stopped doing that. The less your coworkers >> > understand your work, the more of a genius you must be. >> > >> > Now, where was I? >> > >> >> What's the length of "abc" vs. how many bytes are needed to store it? >> > >> > Even what is meant by "length" has several different correct answers! >> > Quantity of code points in the sequence? Number of "grapheme clusters" >> > a.k.a. "user-perceived characters" as Unicode puts it? Width as >> > represented on the output device? On an ASCII device these usually had >> > the same answer (control characters excepted). But even at the Bell >> > Labs CSRC in the 1970s, thanks to troff, the staff knew that they didn't >> > necessarily have to. (How wide is an em dash? How many bytes represent >> > it, in the formatting language and in the output language?) >> > >> >> Giggle... In a device driver I wrote for V6, I used the expression >> >> >> >> "0123"[n] >> >> >> >> and the two programmers whom I thought were better than me had to ask >> >> me what it did... >> >> >> >> -- Dave, brought up on PDP-11 Unix[*] >> > >> > I enjoy this application of that technique, courtesy of Alan Cox. >> > >> > fsck-fuzix: blow 90 bytes on a progress indicator >> > >> > static void progress(void) >> > { >> > static uint8_t progct; >> > progct++; >> > progct&=3; >> > printf("%c\010", "-\\|/"[progct]); >> > fflush(stdout); >> > } >> > >> >> I still remember the days of BOS/PICK/etc, and I staked my career on >> >> Unix. >> > >> > Not a bad choice. Your exposure to and recollection of other ways of >> > doing things, I suspect, made you a more valuable contributor than those >> > who mazed themselves with thoughts of "the Unix way" to the point that >> > they never seriously considered any other. >> > >> > It's fine to prefer "the C way" or "the Unix way", if you can >> > intelligibly define what that means as applied to the issue in dispute, >> > and coherently defend it. Demonstrating an understanding of the >> > alternatives, and being able to credibly explain why they are inferior >> > approaches, is how to do advocacy correctly. >> > >> > But it is not the cowboy way. The rock star way. >> > >> > Regards, >> > Branden >> > >> > [1] Unfortunately I must concede that this claim is less true than it >> > used to be thanks to the relentless pursuit of trade-secret means of >> > optimizing hardware performance. Assembly languages now correspond, >> > particularly on x86, to a sort of macro language that imperfectly >> > masks a massive amount of microarchitectural state that the >> > implementors themselves don't completely understand, at least not in >> > time to get the product to market. Hence the field day of >> > speculative execution attacks and similar. It would not be fair to >> > say that CPUs of old had _no_ microarchitectural state--the Z80, for >> > example, had the not-completely-official `W` and `Z` registers--but >> > they did have much less of it, and correspondingly less attack >> > surface for screwing your programs. I do miss the days of >> > deterministic cycle counts for instruction execution. But I know >> > I'd be sad if all the caches on my workaday machine switched off. >> > >> > [2] https://queue.acm.org/detail.cfm?id=3212479 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Sep 21 08:04:12 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 20 Sep 2024 15:04:12 -0700 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: References: <11d46ab4-b90c-83fe-131a-ee399eebf342@horsfall.org> <20240920171126.vgtl23xwj37kardb@illithid> <69643008-F7FE-4AC7-8519-B45E4C1CEA66@iitbombay.org> Message-ID: <0B54746F-504A-40E0-AFFD-4486167FBAD5@iitbombay.org> > On Sep 20, 2024, at 1:58 PM, Warner Losh wrote: > > > > On Fri, Sep 20, 2024 at 9:16 PM Bakul Shah via TUHS > wrote: >> You are a bit late with your screed. You will find posts >> with similar sentiments starting back in 1980s in Usenet >> groups such as comp.lang.{c,misc,pascal}. >> >> Perhaps a more interesting (but likely pointless) question >> is what is the *least* that can be done to fix C's major >> problems. >> >> Compilers can easily add bounds checking for the array[index] >> construct but ptr[index] can not be checked, unless we make >> a ptr a heavy weight object such as (address, start, limit). >> One can see how code can be generated for code such as this: >> >> Foo x[count]; >> Foo* p = x + n; // or &x[n] >> >> Code such as "Foo *p = malloc(size);" would require the >> compiler to know how malloc behaves to be able to compute >> the limit. But for a user to write a similar function will >> require some language extension. >> >> [Of course, if we did that, adding proper support for >> multidimensional slices would be far easier. But that >> is an exploration for another day!] > > The CHERI architecture extensions do this. It pushes this info into hardware > where all pointers point to a region (gross simplification) that also grant you > rights the area (including read/write/execute). It's really cool, but it does come > at a cost in performance. Each pointer is a pointer, and a capacity that's basically > a cryptographically signed bit of data that's the bounds and access permissions > associated with the pointer. There's more details on their web site: > https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ Capabilities are heavier weight and perhaps an overkill to use as pointers. And that doesn't help programs on normal processors. I view a capability architecture better suited for microkernels -- a cap call would be akin to a syscall + upcall to a server running in user code. For example "read(file-cap, buffer-cap, size)" would need to be delivered to a fileserver process etc. Basically a cap. is ptr *across* a protection domain. We want type safe (including bound checking) within a protection domain (a process). A compiler can often elide bounds checks or push them out of a loop. Similarly for other smaller changes. The idea is to try to "fix" C with as little rewriting as possible. Nobody is going to fund writing rewirtng all 10M lines of kernel code in C (& more in user code) into Rust (not to mention such from scratch rewrites usually result in incompatibilities). But we still seem to want maximum performance and maximum security without paying for it (and if pushed, we live with bugs but not lower performance even if processors are orders of magniture faster now). > > CHERI-BSD is a FreeBSD variant that runs on both CHERI variants (aarch64 and > riscv64) and where most of the research has been done. There's also a Linux > variant as well. > > Members of this project know way too many of the corner cases of the C language > from porting most popular software to the CHERI... And have gone on screeds of > their own. The only one I can easily find is > https://people.freebsd.org/~brooks/talks/asiabsdcon2017-helloworld/helloworld.pdf > > Warner > >> Converting enums to behave like Pascal scalars would >> likely break things. The question is, can such breakage >> be fixed automatically (by source code conversion)? >> >> C's union type is used in two different ways: 1: similar >> to a sum type, which can be done type safely and 2: to >> cheat. The compiler should produce a warning when it can't >> verify a typesafe use -- one can add "unsafe" or some such >> to let the user absolve the compiler of such check. >> >> [May be naively] I tend to think one can evolve C this way >> and fix a lot of code &/or make a lot of bugs more explicit. >> >> > On Sep 20, 2024, at 10:11 AM, G. Branden Robinson > wrote: >> > >> > At 2024-09-21T01:07:11+1000, Dave Horsfall wrote: >> >> Unless I'm mistaken (quite possible at my age), the OP was referring >> >> to that in C, pointers and arrays are pretty much the same thing i.e. >> >> "foo[-2]" means "take the pointer 'foo' and go back two things" >> >> (whatever a "thing" is). >> > >> > "in C, pointers and arrays are pretty much the same thing" is a common >> > utterance but misleading, and in my opinion, better replaced with a >> > different one. >> > >> > We should instead say something more like: >> > >> > In C, pointers and arrays have compatible dereference syntaxes. >> > >> > They do _not_ have compatible _declaration_ syntaxes. >> > >> > Chapter 4 of van der Linden's _Expert C Programming_: Deep C Secrets_ >> > (1994) tackles this issue head-on and at length. >> > >> > Here's the salient point. >> > >> > "Consider the case of an external declaration `extern char *p;` but a >> > definition of `char p[10];`. When we retrieve the contents of `p[i]` >> > using the extern, we get characters, but we treat it as a pointer. >> > Interpreting ASCII characters as an address is garbage, and if you're >> > lucky the program will coredump at that point. If you're not lucky it >> > will corrupt something in your address space, causing a mysterious >> > failure at some point later in the program." >> > >> >> C is just a high level assembly language; >> > >> > I disagree with this common claim too. Assembly languages correspond to >> > well-defined machine models.[1] Those machine models have memory >> > models. C has no memory model--deliberately, because that would have >> > gotten in the way of performance. (In practice, C's machine model was >> > and remains the PDP-11,[2] with aspects thereof progressively sanded off >> > over the years in repeated efforts to salvage the language's reputation >> > for portability.) >> > >> >> there is no such object as a "string" for example: it's just an "array >> >> of char" with the last element being "\0" (viz: "strlen" vs. "sizeof". >> > >> > Yeah, it turns out we need a well-defined string type much more >> > powerfully than, it seems, anyone at the Bell Labs CSRC appreciated. >> > string.h was tacked on (by Nils-Peter Nelson, as I understand it) at the >> > end of the 1970s and C aficionados have defended the language's >> > purported perfection with such vigor that they annexed the haphazardly >> > assembled standard library into the territory that they defend with much >> > rhetorical violence and overstatement. From useless or redundant return >> > values to const-carelessness to Schlemiel the Painter algorithms in >> > implementations, it seems we've collectively made every mistake that >> > could be made with Nelson's original, minimal API, and taught those >> > mistakes as best practices in tutorials and classrooms. A sorry affair. >> > >> > So deep was this disdain for the string as a well-defined data type, and >> > moreover one conceptually distinct from an array (or vector) of integral >> > types that Stroustrup initially repeated the mistake in C++. People can >> > easily roll their own, he seemed to have thought. Eventually he thought >> > again, but C++ took so long to get standardized that by then, damage was >> > done. >> > >> > "A string is just an array of `char`s, and a `char` is just a >> > byte"--another hasty equivalence that surrendered a priceless hostage to >> > fortune. This is the sort of fallacy indulged by people excessively >> > wedded to machine language programming and who apply its perspective to >> > every problem statement uncritically. >> > >> > Again and again, with signed vs. unsigned bytes, "wide" vs. "narrow" >> > characters, and "base" vs. "combining" characters, the champions of the >> > "portable assembly" paradigm charged like Lord Cardigan into the pike >> > and musket lines of the character type as one might envision it in a >> > machine register. (This insistence on visualizing register-level >> > representations has prompted numerous other stupidities, like the use of >> > an integral zero at the _language level_ to represent empty, null, or >> > false literals for as many different data types as possible. "If it >> > ends up as a zero in a register," the thinking appears to have gone, "it >> > should look like a zero in the source code." Generations of code--and >> > language--cowboys have screwed us all over repeatedly with this hasty >> > equivalence. >> > >> > Type theorists have known better for decades. But type theory is (1) >> > hard (it certainly is, to cowboys) and (2) has never enjoyed a trendy >> > day in the sun (for which we may be grateful), which means that is >> > seldom on the path one anticipates to a comfortable retirement from a >> > Silicon Valley tech company (or several) on a private yacht. >> > >> > Why do I rant so splenetically about these issues? Because the result >> > of such confusion is _bugs in programs_. You want something concrete? >> > There it is. Data types protect you from screwing up. And the better >> > your data types are, the more care you give to specifying what sorts of >> > objects your program manipulates, the more thought you give to the >> > invariants that must be maintained for your program to remain in a >> > well-defined state, the fewer bugs you will have. >> > >> > But, nah, better to slap together a prototype, ship it, talk it up to >> > the moon as your latest triumph while interviewing with a rival of the >> > company you just delivered that prototype to, and look on in amusement >> > when your brilliant achievement either proves disastrous in deployment >> > or soaks up the waking hours of an entire team of your former colleagues >> > cleaning up the steaming pile you voided from your rock star bowels. >> > >> > We've paid a heavy price for C's slow and seemingly deeply grudging >> > embrace of the type concept. (The lack of controlled scope for >> > enumeration constants is one example; the horrifyingly ill-conceived >> > choice of "typedef" as a keyword indicating _type aliasing_ is another.) >> > Kernighan did not help by trashing Pascal so hard in about 1980. He was >> > dead right that Pascal needed, essentially, polymorphic subprograms in >> > array types. Wirth not speccing the language to accommodate that back >> > in 1973 or so was a sad mistake. But Pascal got a lot of other stuff >> > right--stuff that the partisanship of C advocates refused to countenance >> > such that they ended up celebrating C's flaws as features. No amount of >> > Jonestown tea could quench their thirst. I suspect the truth was more >> > that they didn't want to bother having to learn any other languages. >> > (Or if they did, not any language that anyone else on their team at work >> > had any facility with.) A rock star plays only one instrument, no? >> > People didn't like it when Eddie Van Halen played keyboards instead of >> > guitar on stage, so he stopped doing that. The less your coworkers >> > understand your work, the more of a genius you must be. >> > >> > Now, where was I? >> > >> >> What's the length of "abc" vs. how many bytes are needed to store it? >> > >> > Even what is meant by "length" has several different correct answers! >> > Quantity of code points in the sequence? Number of "grapheme clusters" >> > a.k.a. "user-perceived characters" as Unicode puts it? Width as >> > represented on the output device? On an ASCII device these usually had >> > the same answer (control characters excepted). But even at the Bell >> > Labs CSRC in the 1970s, thanks to troff, the staff knew that they didn't >> > necessarily have to. (How wide is an em dash? How many bytes represent >> > it, in the formatting language and in the output language?) >> > >> >> Giggle... In a device driver I wrote for V6, I used the expression >> >> >> >> "0123"[n] >> >> >> >> and the two programmers whom I thought were better than me had to ask >> >> me what it did... >> >> >> >> -- Dave, brought up on PDP-11 Unix[*] >> > >> > I enjoy this application of that technique, courtesy of Alan Cox. >> > >> > fsck-fuzix: blow 90 bytes on a progress indicator >> > >> > static void progress(void) >> > { >> > static uint8_t progct; >> > progct++; >> > progct&=3; >> > printf("%c\010", "-\\|/"[progct]); >> > fflush(stdout); >> > } >> > >> >> I still remember the days of BOS/PICK/etc, and I staked my career on >> >> Unix. >> > >> > Not a bad choice. Your exposure to and recollection of other ways of >> > doing things, I suspect, made you a more valuable contributor than those >> > who mazed themselves with thoughts of "the Unix way" to the point that >> > they never seriously considered any other. >> > >> > It's fine to prefer "the C way" or "the Unix way", if you can >> > intelligibly define what that means as applied to the issue in dispute, >> > and coherently defend it. Demonstrating an understanding of the >> > alternatives, and being able to credibly explain why they are inferior >> > approaches, is how to do advocacy correctly. >> > >> > But it is not the cowboy way. The rock star way. >> > >> > Regards, >> > Branden >> > >> > [1] Unfortunately I must concede that this claim is less true than it >> > used to be thanks to the relentless pursuit of trade-secret means of >> > optimizing hardware performance. Assembly languages now correspond, >> > particularly on x86, to a sort of macro language that imperfectly >> > masks a massive amount of microarchitectural state that the >> > implementors themselves don't completely understand, at least not in >> > time to get the product to market. Hence the field day of >> > speculative execution attacks and similar. It would not be fair to >> > say that CPUs of old had _no_ microarchitectural state--the Z80, for >> > example, had the not-completely-official `W` and `Z` registers--but >> > they did have much less of it, and correspondingly less attack >> > surface for screwing your programs. I do miss the days of >> > deterministic cycle counts for instruction execution. But I know >> > I'd be sad if all the caches on my workaday machine switched off. >> > >> > [2] https://queue.acm.org/detail.cfm?id=3212479 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sat Sep 21 08:19:12 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 20 Sep 2024 17:19:12 -0500 Subject: [TUHS] Maximum Array Sizes in 16 bit C In-Reply-To: <69643008-F7FE-4AC7-8519-B45E4C1CEA66@iitbombay.org> Message-ID: <20240920221912.o7uuxfnonrr2jbht@illithid> Hi Bakul & Warner, At 2024-09-20T13:16:24-0700, Bakul Shah wrote: > You are a bit late with your screed. ...I had hoped that my awareness of that was made evident by my citation of a 30-year-old book. ;-) > You will find posts with similar sentiments starting back in 1980s in > Usenet groups such as comp.lang.{c,misc,pascal}. Before my time, but I don't doubt it. The sad thing is that not enough people took such posts seriously. I spend a fair amount of time dealing with "legacy" code. Stuff that hasn't been touched in a long time. One thing I'm convinced of: bad idioms are forever. And that means people will keep learning and copying them. Of course no one wants to pay for the cleanup of such technical debt, not in spite of but _because_ it will expose bugs. You can't justify to any manager that we need to set up this one cost center so that we can expand another one. Not unless the manager cares about downside risk. And tech culture absolutely does not. Let the planes fall out of the sky and the reactors melt down. You can justify it all in the name of "ethical altruism", or whatever the trendy label for sociopathic anarcho- capitalism is these days. (I'm kidding, of course. Serious tech bros understand the essential function of government in maintaining structures for the allocation of economic rents [copyrights and patents] and the utility of employment law, police, and if it comes to it, the National Guard in the suppression of organized labor. Fortunately for management, software engineers think so highly of themselves that they identify with the billionaire CEO's economic class instead of their own.) > Perhaps a more interesting (but likely pointless) question is what is > the *least* that can be done to fix C's major problems. Not pointless. If we ask ourselves that question after every revision of the language standard, the language _will_ advance. C23 has a `nullptr` constant. K&R-style function declarations are gone, and good riddance. I did notice that some national bodies fought like hell to keep trigraphs, though. :-| > Compilers can easily add bounds checking for the array[index] Pascal expected this. One of Kernighan's complaints in his CSTR #100 paper (the one I mentioned) is that he feared precious machine cycles would be lost validating expressions that pointed within valid bounds. So why not a compiler switch, jeez louise? Develop in paranoid/slow mode and ship in sloppy/fast mode. If you must. It seems that static analysis was in its infancy back then. Compiler writers screeched like banshees at the forms of validation the Ada language spec required them to do, and complained so vociferously that they helped trash the language's reputation. A few years went by and, gosh, folks realized that you sure could prevent a lot of bugs by wiring such checks into compilers for other languages--in the places where the semantics would permit it, a count that was invariably lower than Ada's because, shock, Ada was actually thought out and went through several revisions _before_ being put into production. Did anyone ever repent of their loathsome shrieking? Doubt it. Static analysis became cool and they accepted whatever plaudits fell upon them. > construct but ptr[index] can not be checked, unless we make > a ptr a heavy weight object such as (address, start, limit). Base and bounds registers are an old idea. Older than C. But the PDP-11 didn't have them,[1] so C expected to do without and the rest is lamentable history. We would do well to learn from C++'s multiple attempts at "smart pointers". I guess they've got it right in C++11, at last? Not sure. C++'s aggressive promiscuity has not done C a favor, but rather conditioned the latter into reflexive, instead of reasoned, conservatism. > One can see how code can be generated for code such as this: > > Foo x[count]; > Foo* p = x + n; // or &x[n] > > Code such as "Foo *p = malloc(size);" would require the compiler to > know how malloc behaves to be able to compute the limit. C's refusal to specify dynamic memory allocation in the language runtime (as opposed to, eventually, the standard library) was a painful oversight. There was a strange tension between that and code idioms among C's own earliest practitioners to assume dynamically sized storage. I remember when novice C programmers managing strings would get ridiculed by their seniors for setting up and writing to static buffers. Why did they do that? Because it was easy--the language supported it well. Going to `malloc()` was like aiming a gun at your own face. The routine practice of memory overcommit in C on Unix systems led to a sort of perverse synergy. Programmers were actively conditioned _against_ performing algorithmic analysis of their _space_ requirements. (By contrast, seeing how far you could bro down your code's _time_ complexity was where you really showed your mettle. If you spent all of the time you saved waiting on I/O, hey man, that's not YOUR problem.) > But for a user to write a similar function will require some language > extension. > > [Of course, if we did that, adding proper support for multidimensional > slices would be far easier. But that is an exploration for another > day!] When I read about Fortran 90/95/2003's facilities for array reshaping, I rocked back on my heels. > Converting enums to behave like Pascal scalars would likely break > things. The question is, can such breakage be fixed automatically (by > source code conversion)? I don't assert that C needs to ape _Pascal_ scalars in particular. Better Ada's. :P Or, equivalently, C++11's "enum class". As with many things in C++, the syntax is an ugly graft, but the idea is as sound as they come. One of the proposals that didn't make it for C23 was similarly ugly: "return break;". But the _idea_ was to mark tail recursion so that the compiler would know it's happening. That saves stack. _That's_ worth having. I worry that it didn't make it just because the syntax was so cringey. But the alternatives, like yet another new keyword, or overloading punctuation some more, seemed worse. C++ indulges both vices amply with every revision. > C's union type is used in two different ways: 1: similar to a sum > type, which can be done type safely and 2: to cheat. The compiler > should produce a warning when it can't verify a typesafe use -- one > can add "unsafe" or some such to let the user absolve the compiler of > such check. Agreed. C++'s family of typecasting operators is, once again, an ugly feature syntactically, but the benefits in terms of saying what you mean, and _only_ what you mean, are valuable. Casts in C are too often an express ticket to UB. > [May be naively] I tend to think one can evolve C this way and fix a > lot of code &/or make a lot of bugs more explicit. If that be naïveté, let's have more of it. At 2024-09-20T21:58:26+0100, Warner Losh wrote: > The CHERI architecture extensions do this. It pushes this info into > hardware where all pointers point to a region (gross simplification) > that also grant you rights the area (including read/write/execute). > It's really cool, but it does come at a cost in performance. Each > pointer is a pointer, and a capacity that's basically a > cryptographically signed bit of data that's the bounds and access > permissions associated with the pointer. There's more details on their > web site: > https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ CHERI is absolutely cool and even if it doesn't conquer the world, I feel sure that there is a lot we can learn from it. > CHERI-BSD is a FreeBSD variant that runs on both CHERI variants > (aarch64 and riscv64) and where most of the research has been done. > There's also a Linux variant as well. > > Members of this project know way too many of the corner cases of the C > language from porting most popular software to the CHERI... And have > gone on screeds of their own. The only one I can easily find is > https://people.freebsd.org/~brooks/talks/asiabsdcon2017-helloworld/helloworld.pdf Oh yes. I remember they presented at the LF's Open Source Summit one year (maybe the last year in was in downtown San Francisco, before the LF moved the conference to wine country to scrape off all the engineers and other tedious techy types who might point out what's wrong with somebody's grandiose sales pitch--conferences are for getting deals done [too many vice cops in SF?], not advancing the state of the art). It was a questionnaire along the lines of "what do you _really_ know about C?" and it opened my eyes wide for sure. Apparently it turns out that the Dunning-Kruger effect isn't what we think it is. https://www.scientificamerican.com/article/the-dunning-kruger-effect-isnt-what-you-think-it-is/ Maybe D&K's findings were so rapidly assimilated into the cultural zeitgeist because far too many people are acquainted with highly confident C programmers. While preparing this message, I ran across this: https://csrc.nist.gov/files/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc-1998/final/docs/early-cs-papers/schi75.pdf "The Design and Specification of a Security Kernel for the PDP-11/45", by Schiller (1975). I'll try to read and absorb its 117 pages before burdening this list with any more of my yammerings. Happy weekend! Regards, Branden [1] I think. The PDP-11/20 infamously didn't have memory protection of any sort, and the CSRC wisely ran away from that as fast as they could once they could afford to. (See the preface to the Third Edition Programmer's Manual.) And it was reasonable to not expect support for such things if one wanted portability to embedded systems, but it's not clear to me how seriously the portability of C itself was considered until the first ports were actually _done_, and these were not to embedded systems, but to machines broadly comparable to PDP-11s. London and Reiser's paper on Unix/32V opened my eyes with respect to just how late some portability- impacting changes to "K&R C" were actually made. They sounded many cautionary notes that the community--or maybe it was just compiler writers (banshees again?)--seemed slow to acknowledge. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From steffen at sdaoden.eu Sat Sep 21 08:54:08 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 21 Sep 2024 00:54:08 +0200 Subject: [TUHS] kernel boots kernel in 1977 In-Reply-To: References: <202409181534.48IFYO1T094534@ultimate.com> <1D2077D8-6E4D-42AB-A2D2-963CD35338A0@iitbombay.org> <3B4CF41C-3D88-471D-B5E7-6F06C772F5E7@iitbombay.org> <20240920002008.GNa8hQD7@steffen%sdaoden.eu> Message-ID: <20240920225408.DyuGZ7b6@steffen%sdaoden.eu> Bakul Shah wrote in : |> On Sep 19, 2024, at 5:20 PM, Steffen Nurpmeso wrote: |> Bakul Shah via TUHS wrote in |> <3B4CF41C-3D88-471D-B5E7-6F06C772F5E7 at iitbombay.org>: ... |>|It is not so simple these days as the hardware is much more |>|complex and often requires vendor provided firmware assist |>|to properly initialize the system before control gets passed |>|to an OS kernel but no change in the protection model is |>|required for a kernel to kernel handoff. |> |> It seems to me it is worse. The Linux driver of my WLAN chip |> would (i have forgotten the condition, but anyhow) leave the chip |> in some false state, and it could not be overcome except by ... |> I do not know whether the flag is still needed... |> |> KEXEC_ARGS="--append=\"rtw88_pci.disable_aspm=1 rc.hostname=kent\"" | |I don't see how "it is worse". Ok, yes, binary blobs of some firmware may make the pager out of you, which is definetely worse than having "free" drivers on top of them which fail to perform proper initialization. (..i am not a kernel hacker, but the fix could have been 44492e70adc8086c42d3745d21d591657a427f04, (rtw88: pci: Power cycle device during shutdown, 2020-09-29), "platform firmware may not properly power manage the device during shutdown[.] putting the device to D3 can workaround the issue". + pci_set_power_state(pdev, PCI_D3hot); And so many quirks, everywhere.) --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) From tuhs at tuhs.org Wed Sep 25 09:38:10 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 24 Sep 2024 23:38:10 +0000 Subject: [TUHS] Any Surviving BELLMAC-8 Development Tools? Message-ID: Hello everyone, I've found myself in the exceptionally fortunate circumstance of securing ownership of a MAC-TUTOR BELLMAC-8 SBC unit. It is still in shipment so I can't assess its operation yet, but I was wondering if anyone is aware of any surviving assemblers, linkers, etc. for this architecture? If not, I'm prepared to roll my own based on available documentation, but figured I'd ask to see if there's anything I can start with. From what I can tell, the main development environment was PWB, specifically the Bell System internal varieties, with the BTL edition of Release 5.0 literature describing things like m8as(1), m8cc(1), etc. as Division 452 Computer Center standard commands. There is a bit of information here as well: http://ferretronix.com/march/sbc/mactutor/ Thanks for any tips! Regardless of how much I can manage to do with it, I'll be sure to get some good pictures and take some notes on what I am able to figure out with the thing. I presume the Gunkies wiki would be a good place to document that sort of thing? - Matt G. P.S. Pardon if this belongs on COFF, I figured since UNIX was the canonical development system and it is also a Bell Labs thing, I'd ask here first. From arnold at skeeve.com Fri Sep 27 18:56:03 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 27 Sep 2024 02:56:03 -0600 Subject: [TUHS] Classic FoxTrot cartoon Message-ID: <202409270856.48R8u3kL1130174@freefriends.org> https://www.gocomics.com/foxtrotclassics/2024/09/27 IIRC correctly the original version left out the \n. I was told he got some many comments that he later published a strip that was just: \n Arnold From clemc at ccc.com Sat Sep 28 02:26:27 2024 From: clemc at ccc.com (Clem Cole) Date: Fri, 27 Sep 2024 12:26:27 -0400 Subject: [TUHS] Classic FoxTrot cartoon In-Reply-To: <202409270856.48R8u3kL1130174@freefriends.org> References: <202409270856.48R8u3kL1130174@freefriends.org> Message-ID: Interesting -- 'Jason' had always been a Pascal hacker when the strip was first created. As I recall, Berkeley Breathed had Wendell (his hacker character) comment on that during the time of Pascal/C Wars. ᐧ On Fri, Sep 27, 2024 at 4:56 AM wrote: > https://www.gocomics.com/foxtrotclassics/2024/09/27 > > IIRC correctly the original version left out the \n. I was told he > got some many comments that he later published a strip that was just: > > \n > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Sat Sep 28 03:42:54 2024 From: norman at oclsc.org (Norman Wilson) Date: Fri, 27 Sep 2024 13:42:54 -0400 (EDT) Subject: [TUHS] Classic FoxTrot cartoon Message-ID: Clem Cole: Interesting -- 'Jason' had always been a Pascal hacker when the strip was first created. As I recall, Berkeley Breathed had Wendell (his hacker character) comment on that during the time of Pascal/C Wars. ==== But Jason later was revealed to be wearing Unix underpants: https://www.gocomics.com/foxtrot/2002/02/25 Norman Wilson Toronto ON From clemc at ccc.com Sat Sep 28 05:46:32 2024 From: clemc at ccc.com (Clem Cole) Date: Fri, 27 Sep 2024 15:46:32 -0400 Subject: [TUHS] Classic FoxTrot cartoon In-Reply-To: References: Message-ID: This is an example of the essential historical notes that can be learned from the TUHS mailing list. Should we add these to the documentation section of the archive so future generations don't forget them? ᐧ On Fri, Sep 27, 2024 at 1:43 PM Norman Wilson wrote: > Clem Cole: > > Interesting -- 'Jason' had always been a Pascal hacker when the strip was > first created. As I recall, Berkeley Breathed had Wendell (his hacker > character) comment on that during the time of Pascal/C Wars. > > ==== > > But Jason later was revealed to be wearing Unix underpants: > > https://www.gocomics.com/foxtrot/2002/02/25 > > Norman Wilson > Toronto ON > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sat Sep 28 23:34:14 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 28 Sep 2024 09:34:14 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) Message-ID: > C's refusal to specify dynamic memory allocation in the language runtime > (as opposed to, eventually, the standard library) This complaint overlooks one tenet of C: every operation in what you call "language runtime" takes O(1) time. Dynamic memory allocation is not such an operation. Your hobbyhorse awakened one of mine. malloc was in v7, before the C standard was written. The standard spinelessly buckled to allow malloc(0) to return 0, as some implementations gratuitously did. I can't imagine that any program ever actually wanted the feature. Now it's one more undefined behavior that lurks in thousands of programs. There are two arguments for malloc(0), Most importantly, it caters for a limiting case for aggregates generated at runtime--an instance of Kernighan's Law, "Do nothing gracefully". It also provides a way to create a distinctive pointer to impart some meta-information, e.g. "TBD" or "end of subgroup", distinct from the null pointer, which merely denotes absence. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sun Sep 29 02:58:12 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 28 Sep 2024 11:58:12 -0500 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: Message-ID: <20240928165812.4uyturluj4dsuwef@illithid> At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: > > C's refusal to specify dynamic memory allocation in the language > > runtime (as opposed to, eventually, the standard library) > > This complaint overlooks one tenet of C: every operation in what you > call "language runtime" takes O(1) time. Dynamic memory allocation > is not such an operation. A fair point. Let me argue about it anyway. ;-) I'd make three observations. First, K&R did _not_ tout this in their book presenting ANSI C. I went back and checked the prefaces, introduction, and the section presenting a simple malloc()/free() implementation. The tenet you claim for the language is not explicitly articulated and, if I squint really hard, I can only barely perceive (imagine?) it deeply between the lines in some of the prefatory material to which K&R mostly confine their efforts to promote the language. In my view, a "tenet" is something more overt: the sort of thing U.S. politicians try to get hung on the walls of every public school classroom, like Henry Spencer's Ten Commandments of C[1] (which itself does not mention this "core language has only O(1) features" principle). Second, in reviewing K&R I was reminded that structure copying is part of the language. ("There are no operations that manipulate an entire array or string, although structures may be copied as a unit."[2]) Doesn't that break the tenet right there? Third, and following on from the foregoing, your point reminded me of my youth programming non-pipelined machines with no caches. You could set your watch by (just about) any instruction in the set--and often did, because we penurious microcomputer guys often lacked hardware real-time clocks, too. That is to say, for a while, every instruction has an exactly predictable and constant cycle count. (The _value_ of that constant might depend on the addressing mode, because that would have consequences on memory fetches, but the principle stood.) When the Z80 extended the 8080's instruction set, they ate from Tree of Knowledge with block-copy instructions like LDIR and LDDR, and all of a sudden you had instructions with O(n) cycle counts. But as a rule, programmers seemed to welcome this instead of recognizing it as knowing sin, because you generally knew worst-case how many bytes you'd be copying and take that into account. (The worst worst case was a mere 64kB!) Further, Z80 home computers in low-end configurations (that is, no disk drives) often did a shocking thing: they ran with all interrupts masked. All the time. The one non-maskable interrupt was RESET, after which you weren't going to be resuming execution of your program anyway. Not from the same instruction, at least. As I recall the TRS-80 Model I/III/4 didn't even have logic on the motherboard to decode the Z80's "interrupt mode 2", which was vectored, I think. Even in the "high-end" configurations of these tiny machines, you got a whopping ONE interrupt to play with ("IM 1"). Later, when the Hitachi 6309 smuggled similar block-transfer decadence into its extensions to the Motorola 6809 (to the excitement of we semi-consciously Unix-adjacent OS-9 users) they faced a starker problem, because the 6809 didn't wall off interrupts in the same way the 8080 and Z80. They therefore presented the programmer with the novelty of the restartable instruction, and a new generation of programmers became acquainted with the hard lessons time-sharing minicomputer people were familiar with. My point in this digression is that, in my opinion, it's tough to hold fast to the O(1) tenet you claim for C's core language and to another at the same time: the language's identity as a "portable assembly language". Unless every programmer has control over the compiler--and they don't--you can't predict when the compiler will emit an O(n) block transfer instruction. You'll just have to look at the disassembly. _Maybe_ you can retain purity by...never copying structs. I don't think lint or any other tool ever checked for this. Your advocacy of this tenet is the first time I've heard it presented. If you were to suggest to me that most of the time I've spent in my life arguing with C advocates was with rotten exemplars of the species and therefore was time wasted, I would concede the point. There's just so danged _many_ of them... > Your hobbyhorse awakened one of mine. > > malloc was in v7, before the C standard was written. The standard > spinelessly buckled to allow malloc(0) to return 0, as some > implementations gratuitously did. What was the alternative? There was no such thing as an exception, and if a pointer was an int and an int was as wide as a machine address, there'd be no way to indicate failure in-band, either. If the choice was that or another instance of atoi()'s wincingly awful "does this 0 represent an error or successful conversion of a zero input?" land mine, ANSI might have made the right choice. > I can't imagine that any program ever actually wanted the feature. Now > it's one more undefined behavior that lurks in thousands of programs. Hoare admitted to only one billion-dollar mistake. No one dares count how many to write in C's ledger. This was predicted, wasn't it? Everyone loved C because it was fast: it was performant, because it never met a runtime check it didn't eschew--recall again Kernighan punking Pascal on this exact point--and it was quick for the programmer to write because it never met a _compile_-time check it didn't eschew. C was born as a language for wizards who never made mistakes. The problem is that, like James Madison's fictive government of angels, such entities don't exist. The staff of the CSRC itself may have been overwhelmingly populated with frank, modest, and self-deprecating people--and I'll emphasize here that I'm aware of no accounts that this is anything but true--but C unfortunately played a part in stoking a culture of pretension among software developers. "C is a language in which wizards program. I program in C. Therefore I'm a wizard." is how the syllogism (spot the fallacy) went. I don't know who does more damage--the people who believe their own BS, or the ones who know they're scamming their colleagues. > There are two arguments for malloc(0), Most importantly, it caters for > a limiting case for aggregates generated at runtime--an instance of > Kernighan's Law, "Do nothing gracefully". It also provides a way to > create a distinctive pointer to impart some meta-information, e.g. > "TBD" or "end of subgroup", distinct from the null pointer, which > merely denotes absence. I think I might be confused now. I've frequently seen arrays of structs initialized from lists of literals ending in a series of "NULL" structure members, in code that antedates or ignores C99's wonderful feature of designated initializers for aggregate types.[3] How does malloc(0) get this job done and what benefit does it bring? Last time I posted to TUHS I mentioned a proposal for explicit tail-call elimination in C. I got the syntax wrong. The proposal was "return goto;". The WG14 document number is N2920 and it's by Alex Gilding. Good stuff.[4] I hope we see it in C2y. Predictably, I must confess that I didn't make much headway on Schiller's 1975 "secure kernel" paper. Maybe next time. Regards, Branden [1] https://web.cs.dal.ca/~jamie/UWO/C/the10fromHenryS.html I can easily imagine that the tenet held at _some_ point in the C's history. It's _got_ to be the reason that the language relegates memset() and memcpy() to the standard library (or to the programmer's own devise)! :-O [2] Kernighan & Ritchie, _The C Programming Language_, 2nd edition, p. 2 Having thus admitted the camel's nose to the tent, K&R would have done the world a major service by making memset(), or at least bzero(), a language feature, the latter perhaps by having "= 0" validly apply to an lvalue of non-primitive type. Okay, _potentially_ a major service. You'd still need the self-regarding wizard programmers to bother coding it, which they wouldn't in many cases "because speed". Move fast, break stuff. C++ screwed this up too, and stubbornly stuck by it for a long time. https://cplusplus.github.io/CWG/issues/178.html [3] https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html [4] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2920.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From luther.johnson at makerlisp.com Sun Sep 29 03:47:44 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Sat, 28 Sep 2024 10:47:44 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928165812.4uyturluj4dsuwef@illithid> References: <20240928165812.4uyturluj4dsuwef@illithid> Message-ID: <1cc8e27d-6534-0002-b9a4-66e34420f413@makerlisp.com> I don't know that structure copying breaks any complexity or bounds on execution time rules. Many compilers may be different, but in the generated code I've seen, when you pass in a structure to a function, the receiving function copies it to the stack. In the portable C compiler, when you return a structure as a result, it is first copied to a static area, a pointer to that area is returned, then the caller copies that out to wherever it's meant to go, either a variable that's being assigned (which could be on the stack or elsewhere), or to a place on the stack that was reserved for it because that result will now be an argument to another function to be called. So there's some copying, but that's proportional to the size of the structure, it's linear, and there's no dynamic memory allocation going on. On 09/28/2024 09:58 AM, G. Branden Robinson wrote: > At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: >>> C's refusal to specify dynamic memory allocation in the language >>> runtime (as opposed to, eventually, the standard library) >> This complaint overlooks one tenet of C: every operation in what you >> call "language runtime" takes O(1) time. Dynamic memory allocation >> is not such an operation. > A fair point. Let me argue about it anyway. ;-) > > I'd make three observations. First, K&R did _not_ tout this in their > book presenting ANSI C. I went back and checked the prefaces, > introduction, and the section presenting a simple malloc()/free() > implementation. The tenet you claim for the language is not explicitly > articulated and, if I squint really hard, I can only barely perceive > (imagine?) it deeply between the lines in some of the prefatory material > to which K&R mostly confine their efforts to promote the language. In > my view, a "tenet" is something more overt: the sort of thing U.S. > politicians try to get hung on the walls of every public school > classroom, like Henry Spencer's Ten Commandments of C[1] (which itself > does not mention this "core language has only O(1) features" principle). > > Second, in reviewing K&R I was reminded that structure copying is part > of the language. ("There are no operations that manipulate an entire > array or string, although structures may be copied as a unit."[2]) > Doesn't that break the tenet right there? > > Third, and following on from the foregoing, your point reminded me of my > youth programming non-pipelined machines with no caches. You could set > your watch by (just about) any instruction in the set--and often did, > because we penurious microcomputer guys often lacked hardware real-time > clocks, too. That is to say, for a while, every instruction has an > exactly predictable and constant cycle count. (The _value_ of that > constant might depend on the addressing mode, because that would have > consequences on memory fetches, but the principle stood.) When the Z80 > extended the 8080's instruction set, they ate from Tree of Knowledge > with block-copy instructions like LDIR and LDDR, and all of a sudden you > had instructions with O(n) cycle counts. But as a rule, programmers > seemed to welcome this instead of recognizing it as knowing sin, because > you generally knew worst-case how many bytes you'd be copying and take > that into account. (The worst worst case was a mere 64kB!) > > Further, Z80 home computers in low-end configurations (that is, no disk > drives) often did a shocking thing: they ran with all interrupts masked. > All the time. The one non-maskable interrupt was RESET, after which you > weren't going to be resuming execution of your program anyway. Not from > the same instruction, at least. As I recall the TRS-80 Model I/III/4 > didn't even have logic on the motherboard to decode the Z80's "interrupt > mode 2", which was vectored, I think. Even in the "high-end" > configurations of these tiny machines, you got a whopping ONE interrupt > to play with ("IM 1"). > > Later, when the Hitachi 6309 smuggled similar block-transfer decadence > into its extensions to the Motorola 6809 (to the excitement of we > semi-consciously Unix-adjacent OS-9 users) they faced a starker problem, > because the 6809 didn't wall off interrupts in the same way the 8080 and > Z80. They therefore presented the programmer with the novelty of the > restartable instruction, and a new generation of programmers became > acquainted with the hard lessons time-sharing minicomputer people were > familiar with. > > My point in this digression is that, in my opinion, it's tough to hold > fast to the O(1) tenet you claim for C's core language and to another at > the same time: the language's identity as a "portable assembly > language". Unless every programmer has control over the compiler--and > they don't--you can't predict when the compiler will emit an O(n) block > transfer instruction. You'll just have to look at the disassembly. > > _Maybe_ you can retain purity by...never copying structs. I don't think > lint or any other tool ever checked for this. Your advocacy of this > tenet is the first time I've heard it presented. > > If you were to suggest to me that most of the time I've spent in my life > arguing with C advocates was with rotten exemplars of the species and > therefore was time wasted, I would concede the point. > > There's just so danged _many_ of them... > >> Your hobbyhorse awakened one of mine. >> >> malloc was in v7, before the C standard was written. The standard >> spinelessly buckled to allow malloc(0) to return 0, as some >> implementations gratuitously did. > What was the alternative? There was no such thing as an exception, and > if a pointer was an int and an int was as wide as a machine address, > there'd be no way to indicate failure in-band, either. > > If the choice was that or another instance of atoi()'s wincingly awful > "does this 0 represent an error or successful conversion of a zero > input?" land mine, ANSI might have made the right choice. > >> I can't imagine that any program ever actually wanted the feature. Now >> it's one more undefined behavior that lurks in thousands of programs. > Hoare admitted to only one billion-dollar mistake. No one dares count > how many to write in C's ledger. This was predicted, wasn't it? > Everyone loved C because it was fast: it was performant, because it > never met a runtime check it didn't eschew--recall again Kernighan > punking Pascal on this exact point--and it was quick for the programmer > to write because it never met a _compile_-time check it didn't eschew. > C was born as a language for wizards who never made mistakes. > > The problem is that, like James Madison's fictive government of angels, > such entities don't exist. The staff of the CSRC itself may have been > overwhelmingly populated with frank, modest, and self-deprecating > people--and I'll emphasize here that I'm aware of no accounts that this > is anything but true--but C unfortunately played a part in stoking a > culture of pretension among software developers. "C is a language in > which wizards program. I program in C. Therefore I'm a wizard." is how > the syllogism (spot the fallacy) went. I don't know who does more > damage--the people who believe their own BS, or the ones who know > they're scamming their colleagues. > >> There are two arguments for malloc(0), Most importantly, it caters for >> a limiting case for aggregates generated at runtime--an instance of >> Kernighan's Law, "Do nothing gracefully". It also provides a way to >> create a distinctive pointer to impart some meta-information, e.g. >> "TBD" or "end of subgroup", distinct from the null pointer, which >> merely denotes absence. > I think I might be confused now. I've frequently seen arrays of structs > initialized from lists of literals ending in a series of "NULL" > structure members, in code that antedates or ignores C99's wonderful > feature of designated initializers for aggregate types.[3] How does > malloc(0) get this job done and what benefit does it bring? > > Last time I posted to TUHS I mentioned a proposal for explicit tail-call > elimination in C. I got the syntax wrong. The proposal was "return > goto;". The WG14 document number is N2920 and it's by Alex Gilding. > Good stuff.[4] I hope we see it in C2y. > > Predictably, I must confess that I didn't make much headway on > Schiller's 1975 "secure kernel" paper. Maybe next time. > > Regards, > Branden > > [1] https://web.cs.dal.ca/~jamie/UWO/C/the10fromHenryS.html > > I can easily imagine that the tenet held at _some_ point in the > C's history. It's _got_ to be the reason that the language > relegates memset() and memcpy() to the standard library (or to the > programmer's own devise)! :-O > > [2] Kernighan & Ritchie, _The C Programming Language_, 2nd edition, p. 2 > > Having thus admitted the camel's nose to the tent, K&R would have > done the world a major service by making memset(), or at least > bzero(), a language feature, the latter perhaps by having "= 0" > validly apply to an lvalue of non-primitive type. Okay, > _potentially_ a major service. You'd still need the self-regarding > wizard programmers to bother coding it, which they wouldn't in many > cases "because speed". Move fast, break stuff. > > C++ screwed this up too, and stubbornly stuck by it for a long time. > > https://cplusplus.github.io/CWG/issues/178.html > > [3] https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html > [4] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2920.pdf From luther.johnson at makerlisp.com Sun Sep 29 03:52:16 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Sat, 28 Sep 2024 10:52:16 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <1cc8e27d-6534-0002-b9a4-66e34420f413@makerlisp.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <1cc8e27d-6534-0002-b9a4-66e34420f413@makerlisp.com> Message-ID: In the compilers I'm talking about, you pass a structure by passing a pointer to it - but the receiving function knows the argument is a structure, and not a pointer to a structure, so it knows it needs to use the pointer to copy to its own local version. On 09/28/2024 10:47 AM, Luther Johnson wrote: > I don't know that structure copying breaks any complexity or bounds on > execution time rules. Many compilers may be different, but in the > generated code I've seen, when you pass in a structure to a function, > the receiving function copies it to the stack. In the portable C > compiler, when you return a structure as a result, it is first copied > to a static area, a pointer to that area is returned, then the caller > copies that out to wherever it's meant to go, either a variable that's > being assigned (which could be on the stack or elsewhere), or to a place > on the stack that was reserved for it because that result will now be an > argument to another function to be called. So there's some copying, but > that's proportional to the size of the structure, it's linear, and > there's no dynamic memory allocation going on. > > On 09/28/2024 09:58 AM, G. Branden Robinson wrote: >> At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: >>>> C's refusal to specify dynamic memory allocation in the language >>>> runtime (as opposed to, eventually, the standard library) >>> This complaint overlooks one tenet of C: every operation in what you >>> call "language runtime" takes O(1) time. Dynamic memory allocation >>> is not such an operation. >> A fair point. Let me argue about it anyway. ;-) >> >> I'd make three observations. First, K&R did _not_ tout this in their >> book presenting ANSI C. I went back and checked the prefaces, >> introduction, and the section presenting a simple malloc()/free() >> implementation. The tenet you claim for the language is not explicitly >> articulated and, if I squint really hard, I can only barely perceive >> (imagine?) it deeply between the lines in some of the prefatory material >> to which K&R mostly confine their efforts to promote the language. In >> my view, a "tenet" is something more overt: the sort of thing U.S. >> politicians try to get hung on the walls of every public school >> classroom, like Henry Spencer's Ten Commandments of C[1] (which itself >> does not mention this "core language has only O(1) features" principle). >> >> Second, in reviewing K&R I was reminded that structure copying is part >> of the language. ("There are no operations that manipulate an entire >> array or string, although structures may be copied as a unit."[2]) >> Doesn't that break the tenet right there? >> >> Third, and following on from the foregoing, your point reminded me of my >> youth programming non-pipelined machines with no caches. You could set >> your watch by (just about) any instruction in the set--and often did, >> because we penurious microcomputer guys often lacked hardware real-time >> clocks, too. That is to say, for a while, every instruction has an >> exactly predictable and constant cycle count. (The _value_ of that >> constant might depend on the addressing mode, because that would have >> consequences on memory fetches, but the principle stood.) When the Z80 >> extended the 8080's instruction set, they ate from Tree of Knowledge >> with block-copy instructions like LDIR and LDDR, and all of a sudden you >> had instructions with O(n) cycle counts. But as a rule, programmers >> seemed to welcome this instead of recognizing it as knowing sin, because >> you generally knew worst-case how many bytes you'd be copying and take >> that into account. (The worst worst case was a mere 64kB!) >> >> Further, Z80 home computers in low-end configurations (that is, no disk >> drives) often did a shocking thing: they ran with all interrupts masked. >> All the time. The one non-maskable interrupt was RESET, after which you >> weren't going to be resuming execution of your program anyway. Not from >> the same instruction, at least. As I recall the TRS-80 Model I/III/4 >> didn't even have logic on the motherboard to decode the Z80's "interrupt >> mode 2", which was vectored, I think. Even in the "high-end" >> configurations of these tiny machines, you got a whopping ONE interrupt >> to play with ("IM 1"). >> >> Later, when the Hitachi 6309 smuggled similar block-transfer decadence >> into its extensions to the Motorola 6809 (to the excitement of we >> semi-consciously Unix-adjacent OS-9 users) they faced a starker problem, >> because the 6809 didn't wall off interrupts in the same way the 8080 and >> Z80. They therefore presented the programmer with the novelty of the >> restartable instruction, and a new generation of programmers became >> acquainted with the hard lessons time-sharing minicomputer people were >> familiar with. >> >> My point in this digression is that, in my opinion, it's tough to hold >> fast to the O(1) tenet you claim for C's core language and to another at >> the same time: the language's identity as a "portable assembly >> language". Unless every programmer has control over the compiler--and >> they don't--you can't predict when the compiler will emit an O(n) block >> transfer instruction. You'll just have to look at the disassembly. >> >> _Maybe_ you can retain purity by...never copying structs. I don't think >> lint or any other tool ever checked for this. Your advocacy of this >> tenet is the first time I've heard it presented. >> >> If you were to suggest to me that most of the time I've spent in my life >> arguing with C advocates was with rotten exemplars of the species and >> therefore was time wasted, I would concede the point. >> >> There's just so danged _many_ of them... >> >>> Your hobbyhorse awakened one of mine. >>> >>> malloc was in v7, before the C standard was written. The standard >>> spinelessly buckled to allow malloc(0) to return 0, as some >>> implementations gratuitously did. >> What was the alternative? There was no such thing as an exception, and >> if a pointer was an int and an int was as wide as a machine address, >> there'd be no way to indicate failure in-band, either. >> >> If the choice was that or another instance of atoi()'s wincingly awful >> "does this 0 represent an error or successful conversion of a zero >> input?" land mine, ANSI might have made the right choice. >> >>> I can't imagine that any program ever actually wanted the feature. Now >>> it's one more undefined behavior that lurks in thousands of programs. >> Hoare admitted to only one billion-dollar mistake. No one dares count >> how many to write in C's ledger. This was predicted, wasn't it? >> Everyone loved C because it was fast: it was performant, because it >> never met a runtime check it didn't eschew--recall again Kernighan >> punking Pascal on this exact point--and it was quick for the programmer >> to write because it never met a _compile_-time check it didn't eschew. >> C was born as a language for wizards who never made mistakes. >> >> The problem is that, like James Madison's fictive government of angels, >> such entities don't exist. The staff of the CSRC itself may have been >> overwhelmingly populated with frank, modest, and self-deprecating >> people--and I'll emphasize here that I'm aware of no accounts that this >> is anything but true--but C unfortunately played a part in stoking a >> culture of pretension among software developers. "C is a language in >> which wizards program. I program in C. Therefore I'm a wizard." is how >> the syllogism (spot the fallacy) went. I don't know who does more >> damage--the people who believe their own BS, or the ones who know >> they're scamming their colleagues. >> >>> There are two arguments for malloc(0), Most importantly, it caters for >>> a limiting case for aggregates generated at runtime--an instance of >>> Kernighan's Law, "Do nothing gracefully". It also provides a way to >>> create a distinctive pointer to impart some meta-information, e.g. >>> "TBD" or "end of subgroup", distinct from the null pointer, which >>> merely denotes absence. >> I think I might be confused now. I've frequently seen arrays of structs >> initialized from lists of literals ending in a series of "NULL" >> structure members, in code that antedates or ignores C99's wonderful >> feature of designated initializers for aggregate types.[3] How does >> malloc(0) get this job done and what benefit does it bring? >> >> Last time I posted to TUHS I mentioned a proposal for explicit tail-call >> elimination in C. I got the syntax wrong. The proposal was "return >> goto;". The WG14 document number is N2920 and it's by Alex Gilding. >> Good stuff.[4] I hope we see it in C2y. >> >> Predictably, I must confess that I didn't make much headway on >> Schiller's 1975 "secure kernel" paper. Maybe next time. >> >> Regards, >> Branden >> >> [1] https://web.cs.dal.ca/~jamie/UWO/C/the10fromHenryS.html >> >> I can easily imagine that the tenet held at _some_ point in the >> C's history. It's _got_ to be the reason that the language >> relegates memset() and memcpy() to the standard library (or to the >> programmer's own devise)! :-O >> >> [2] Kernighan & Ritchie, _The C Programming Language_, 2nd edition, p. 2 >> >> Having thus admitted the camel's nose to the tent, K&R would have >> done the world a major service by making memset(), or at least >> bzero(), a language feature, the latter perhaps by having "= 0" >> validly apply to an lvalue of non-primitive type. Okay, >> _potentially_ a major service. You'd still need the self-regarding >> wizard programmers to bother coding it, which they wouldn't in many >> cases "because speed". Move fast, break stuff. >> >> C++ screwed this up too, and stubbornly stuck by it for a long >> time. >> >> https://cplusplus.github.io/CWG/issues/178.html >> >> [3] https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html >> [4] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2920.pdf > > From tuhs at tuhs.org Sun Sep 29 03:59:27 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Sat, 28 Sep 2024 10:59:27 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928165812.4uyturluj4dsuwef@illithid> References: <20240928165812.4uyturluj4dsuwef@illithid> Message-ID: <9049DF63-F7BE-494F-BF7C-6BD0565C0D06@iitbombay.org> Just responding to random things that I noticed: You don't need special syntax for tail-call. It should be done transparently when a call is the last thing that gets executed. Special syntax will merely allow confused people to use it in the wrong place and get confused more. malloc(0) should return a unique ptr. So that "T* a = malloc(0); T* b = malloc(0); a != (T*)0 && a != b". Without this, malloc(0) acts differently from malloc(n) for n > 0. Note that except for arrays, function arguments & result are copied so copying a struct makes perfect sense. Passing arrays by reference may have been due to residual Fortran influence! [Just guessing] Also note: that one exception has been the cause of many problems. In any case you have not argued convincingly about why dynamic memory allocation should be in the language (runtime) :-) And adding that wouldn't have fixed any of the existing problems with the language. Bakul > On Sep 28, 2024, at 9:58 AM, G. Branden Robinson wrote: > > At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: >>> C's refusal to specify dynamic memory allocation in the language >>> runtime (as opposed to, eventually, the standard library) >> >> This complaint overlooks one tenet of C: every operation in what you >> call "language runtime" takes O(1) time. Dynamic memory allocation >> is not such an operation. > > A fair point. Let me argue about it anyway. ;-) > > I'd make three observations. First, K&R did _not_ tout this in their > book presenting ANSI C. I went back and checked the prefaces, > introduction, and the section presenting a simple malloc()/free() > implementation. The tenet you claim for the language is not explicitly > articulated and, if I squint really hard, I can only barely perceive > (imagine?) it deeply between the lines in some of the prefatory material > to which K&R mostly confine their efforts to promote the language. In > my view, a "tenet" is something more overt: the sort of thing U.S. > politicians try to get hung on the walls of every public school > classroom, like Henry Spencer's Ten Commandments of C[1] (which itself > does not mention this "core language has only O(1) features" principle). > > Second, in reviewing K&R I was reminded that structure copying is part > of the language. ("There are no operations that manipulate an entire > array or string, although structures may be copied as a unit."[2]) > Doesn't that break the tenet right there? > > Third, and following on from the foregoing, your point reminded me of my > youth programming non-pipelined machines with no caches. You could set > your watch by (just about) any instruction in the set--and often did, > because we penurious microcomputer guys often lacked hardware real-time > clocks, too. That is to say, for a while, every instruction has an > exactly predictable and constant cycle count. (The _value_ of that > constant might depend on the addressing mode, because that would have > consequences on memory fetches, but the principle stood.) When the Z80 > extended the 8080's instruction set, they ate from Tree of Knowledge > with block-copy instructions like LDIR and LDDR, and all of a sudden you > had instructions with O(n) cycle counts. But as a rule, programmers > seemed to welcome this instead of recognizing it as knowing sin, because > you generally knew worst-case how many bytes you'd be copying and take > that into account. (The worst worst case was a mere 64kB!) > > Further, Z80 home computers in low-end configurations (that is, no disk > drives) often did a shocking thing: they ran with all interrupts masked. > All the time. The one non-maskable interrupt was RESET, after which you > weren't going to be resuming execution of your program anyway. Not from > the same instruction, at least. As I recall the TRS-80 Model I/III/4 > didn't even have logic on the motherboard to decode the Z80's "interrupt > mode 2", which was vectored, I think. Even in the "high-end" > configurations of these tiny machines, you got a whopping ONE interrupt > to play with ("IM 1"). > > Later, when the Hitachi 6309 smuggled similar block-transfer decadence > into its extensions to the Motorola 6809 (to the excitement of we > semi-consciously Unix-adjacent OS-9 users) they faced a starker problem, > because the 6809 didn't wall off interrupts in the same way the 8080 and > Z80. They therefore presented the programmer with the novelty of the > restartable instruction, and a new generation of programmers became > acquainted with the hard lessons time-sharing minicomputer people were > familiar with. > > My point in this digression is that, in my opinion, it's tough to hold > fast to the O(1) tenet you claim for C's core language and to another at > the same time: the language's identity as a "portable assembly > language". Unless every programmer has control over the compiler--and > they don't--you can't predict when the compiler will emit an O(n) block > transfer instruction. You'll just have to look at the disassembly. > > _Maybe_ you can retain purity by...never copying structs. I don't think > lint or any other tool ever checked for this. Your advocacy of this > tenet is the first time I've heard it presented. > > If you were to suggest to me that most of the time I've spent in my life > arguing with C advocates was with rotten exemplars of the species and > therefore was time wasted, I would concede the point. > > There's just so danged _many_ of them... > >> Your hobbyhorse awakened one of mine. >> >> malloc was in v7, before the C standard was written. The standard >> spinelessly buckled to allow malloc(0) to return 0, as some >> implementations gratuitously did. > > What was the alternative? There was no such thing as an exception, and > if a pointer was an int and an int was as wide as a machine address, > there'd be no way to indicate failure in-band, either. > > If the choice was that or another instance of atoi()'s wincingly awful > "does this 0 represent an error or successful conversion of a zero > input?" land mine, ANSI might have made the right choice. > >> I can't imagine that any program ever actually wanted the feature. Now >> it's one more undefined behavior that lurks in thousands of programs. > > Hoare admitted to only one billion-dollar mistake. No one dares count > how many to write in C's ledger. This was predicted, wasn't it? > Everyone loved C because it was fast: it was performant, because it > never met a runtime check it didn't eschew--recall again Kernighan > punking Pascal on this exact point--and it was quick for the programmer > to write because it never met a _compile_-time check it didn't eschew. > C was born as a language for wizards who never made mistakes. > > The problem is that, like James Madison's fictive government of angels, > such entities don't exist. The staff of the CSRC itself may have been > overwhelmingly populated with frank, modest, and self-deprecating > people--and I'll emphasize here that I'm aware of no accounts that this > is anything but true--but C unfortunately played a part in stoking a > culture of pretension among software developers. "C is a language in > which wizards program. I program in C. Therefore I'm a wizard." is how > the syllogism (spot the fallacy) went. I don't know who does more > damage--the people who believe their own BS, or the ones who know > they're scamming their colleagues. > >> There are two arguments for malloc(0), Most importantly, it caters for >> a limiting case for aggregates generated at runtime--an instance of >> Kernighan's Law, "Do nothing gracefully". It also provides a way to >> create a distinctive pointer to impart some meta-information, e.g. >> "TBD" or "end of subgroup", distinct from the null pointer, which >> merely denotes absence. > > I think I might be confused now. I've frequently seen arrays of structs > initialized from lists of literals ending in a series of "NULL" > structure members, in code that antedates or ignores C99's wonderful > feature of designated initializers for aggregate types.[3] How does > malloc(0) get this job done and what benefit does it bring? > > Last time I posted to TUHS I mentioned a proposal for explicit tail-call > elimination in C. I got the syntax wrong. The proposal was "return > goto;". The WG14 document number is N2920 and it's by Alex Gilding. > Good stuff.[4] I hope we see it in C2y. > > Predictably, I must confess that I didn't make much headway on > Schiller's 1975 "secure kernel" paper. Maybe next time. > > Regards, > Branden > > [1] https://web.cs.dal.ca/~jamie/UWO/C/the10fromHenryS.html > > I can easily imagine that the tenet held at _some_ point in the > C's history. It's _got_ to be the reason that the language > relegates memset() and memcpy() to the standard library (or to the > programmer's own devise)! :-O > > [2] Kernighan & Ritchie, _The C Programming Language_, 2nd edition, p. 2 > > Having thus admitted the camel's nose to the tent, K&R would have > done the world a major service by making memset(), or at least > bzero(), a language feature, the latter perhaps by having "= 0" > validly apply to an lvalue of non-primitive type. Okay, > _potentially_ a major service. You'd still need the self-regarding > wizard programmers to bother coding it, which they wouldn't in many > cases "because speed". Move fast, break stuff. > > C++ screwed this up too, and stubbornly stuck by it for a long time. > > https://cplusplus.github.io/CWG/issues/178.html > > [3] https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html > [4] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2920.pdf From g.branden.robinson at gmail.com Sun Sep 29 04:01:38 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 28 Sep 2024 13:01:38 -0500 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928165812.4uyturluj4dsuwef@illithid> References: <20240928165812.4uyturluj4dsuwef@illithid> Message-ID: <20240928180138.aygrwqdwrvq3n6xt@illithid> [self-follow-up] At 2024-09-28T11:58:16-0500, G. Branden Robinson wrote: > > malloc was in v7, before the C standard was written. The standard > > spinelessly buckled to allow malloc(0) to return 0, as some > > implementations gratuitously did. > > What was the alternative? There was no such thing as an exception, and > if a pointer was an int and an int was as wide as a machine address, > there'd be no way to indicate failure in-band, either. While I'm making enemies of C advocates, let me just damn myself further by suggesting an answer to my own question. The obvious and correct thing to do was to have any standard library function that could possibly fail return a structure type instead of a scalar. Such a type would have two components: the value of interest when valid, and an error indicator.[1] As John Belushi would have said at the time such design decisions were being made, "but nooooooooo". Returning a struct was an obviously HORRIBLE idea. My god, you might be stacking two ints instead of one. That doubles the badness! Oh, how we yearn for the days of the PDP-7, when resources were so scarce that a system call didn't return _anything_. If it failed, the carry flag was set. "One bit of return value ought to be enough for anyone," as I hope Ken Thompson never said. Expounders of Doug's tenet would, or should, have acknowledged that by going to the library _at all_, they were giving up any O(1) guarantee, and likely starting something O(n) or worse in time and/or space. So what's so awful about sticking on a piece of O(1) overhead? In the analysis of algorithms class lecture that the wizards slept through, it was pointed out that only the highest-order term is retained. Well, the extra int was easy to see in memory and throw a hissy fit about, and I suppose a hissy fit is exactly what happened. Much better to use a global library symbol. Call it "errno". That's sure to never cause anyone any problems with reentrancy or concurrency whatsoever. After all: "...C offers only straightforward, single-thread control flow: tests, loops, grouping, and subprograms, but not multiprogramming, parallel operations, synchronization, or coroutines." (K&R 2e, p. 2) It's grimly fascinating to me now to observe how many security vulnerabilities and other disasters have arisen from the determination of C's champions to apply it to all problems, and with especial fervor to those that K&R explicitly acknowledged it was ill-suited for. Real wizards, it seems, know only one spell, and it is tellingly hammer-shaped. Regards, Branden [1] Much later, we came to know this (in slightly cleaner form) as an "option type". Rust advocates make a big, big deal of this. Only a slightly bigger one than it deserves, but I perceive a replay of C's cultural history in the passion of Rust's advocates. Or maybe something less edifying than passion accounts for this: https://fasterthanli.me/articles/the-rustconf-keynote-fiasco-explained -------------- 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 Sep 29 04:05:59 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 28 Sep 2024 11:05:59 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928165812.4uyturluj4dsuwef@illithid> References: <20240928165812.4uyturluj4dsuwef@illithid> Message-ID: <20240928180559.GF9067@mcvoy.com> On Sat, Sep 28, 2024 at 11:58:12AM -0500, G. Branden Robinson wrote: > The problem is that, like James Madison's fictive government of angels, > such entities don't exist. The staff of the CSRC itself may have been > overwhelmingly populated with frank, modest, and self-deprecating > people--and I'll emphasize here that I'm aware of no accounts that this > is anything but true--but C unfortunately played a part in stoking a > culture of pretension among software developers. "C is a language in > which wizards program. I program in C. Therefore I'm a wizard." is how > the syllogism (spot the fallacy) went. I don't know who does more > damage--the people who believe their own BS, or the ones who know > they're scamming their colleagues. I have a somewhat different view. I have a son who is learning to program and he asked me about C. I said "C is like driving a sports car on a twisty mountain road that has cliffs and no guard rails. If you want to check your phone while you are driving, it's not for you. It requires your full, focussed attention. So that sounds bad, right? Well, if you are someone who enjoys driving a sports car, and are good at it, perhaps C is for you." So I guess I fit the description of thinking I'm a wizard, sort of. I'm good at C, there is plenty of my C open sourced, you can go read it and decide for yourself. I enjoy C. But it's not for everyone, in fact, most programmers these days would be better off in Rust or something that has guardrails. I get your points, Branden, but I'd prefer that C sticks around for the people who enjoy it and are good at it. A small crowd, for sure. --lm From g.branden.robinson at gmail.com Sun Sep 29 04:46:30 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 28 Sep 2024 13:46:30 -0500 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <1cc8e27d-6534-0002-b9a4-66e34420f413@makerlisp.com> Message-ID: <20240928184630.tyifhjjynxeo4jh3@illithid> Hi Luther, At 2024-09-28T10:47:44-0700, Luther Johnson wrote: > I don't know that structure copying breaks any complexity or bounds on > execution time rules. Many compilers may be different, but in the > generated code I've seen, when you pass in a structure to a function, > the receiving function copies it to the stack. In the portable C > compiler, when you return a structure as a result, it is first copied > to a static area, a pointer to that area is returned, then the caller > copies that out to wherever it's meant to go, either a variable that's > being assigned (which could be on the stack or elsewhere), or to a > place on the stack that was reserved for it because that result will > now be an argument to another function to be called. So there's some > copying, but that's proportional to the size of the structure, it's > linear, and there's no dynamic memory allocation going on. I have no problem with this presentation, but recall the principle--the tenet--that Doug was upholding: > > At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: > > > This complaint overlooks one tenet of C: every operation in what > > > you call "language runtime" takes O(1) time. Dynamic memory > > > allocation is not such an operation. Even without dynamic memory allocation, if you did something linear, something O(n), it was a lose and a violation of the tenet. I can easily see the appeal of a language whose every operation really is O(1). Once upon a time, a university course, or equivalent experience, in assembly language (on a CLEAN instruction set, not x86) is what taught you the virtues and drawbacks of thinking about and implementing things that way. But my view is that C hasn't been one of those languages for a very long time, since before its initial ANSI standardization at the latest. At 2024-09-28T10:52:16-0700, Luther Johnson wrote: > In the compilers I'm talking about, you pass a structure by passing a > pointer to it - but the receiving function knows the argument is a > structure, and not a pointer to a structure, so it knows it needs to > use the pointer to copy to its own local version. It's my understanding that the ability to work with structs as first-class citizens in function calls, as parameters _or_ return types, was something fairly late to stabilize in C compilers. Second-hand, I gather that pre-standard C as told by K&R explicitly did _not_ countenance this. So a lot of early C code, including that in libraries, indirected nearly all struct access, even when read-only, through pointers. This is often a win, but not always. A few minutes ago I shot off my mouth to this list about how much better the standard library design could have been if the return of structs by value had been supported much earlier. Our industry has, it seemss, been slow to appreciate the distinction between what C++ eventually came to explicitly call "copy" semantics and "move" semantics. Rust's paradigmatic dedication to the concept of data "ownership" at last seems to be popularizing the practice of thinking about these things. (For my part, I will forever hurl calumnies at computer architects who refer to copy operations as "MOV" or similar. If the operation doesn't destroy the source, it's not a move--I don't care how many thousands of pages of manuals Intel writes saying otherwise. Even the RISC-V specs screw this up, I assume in a deliberate but embarrassing attempt to win mindshare among x86 programmers who cling to this myth as they do so many others.) For a moment I considered giving credit to a virtuous few '80s C programmers who recognized that there was indeed no need to copy a struct upon passing it to a function if you knew the callee wasn't going to modify that struct...but we had a way of saying this, "const", and library writers of that era were infamously indifferent to using "const" in their APIs where it would have done good. So, no, no credit. Here's a paragraph from a 1987 text I wish I'd read back then, or at any time before being exposed to C. "[Language] does not define how parameter passing is implemented. A program is erroneous if it depends on a specific implementation method. The two obvious implementations are by copy and by reference. With an implementation that copies parameters, an `out` or `in out` actual parameter will not be updated until (normal) return from the subprogram. Therefore if the subprogram propagates an exception, the actual parameter will be unchanged. This is clearly not the case when a reference implementation is used. The difficulty with this vagueness in the definition of [language] is that it is quite awkward to be sure that a program is independent of the implementation method. (You might wonder why the language does not define the implementation method. The reason is that the copy mechanism is very inefficient with large parameters, whereas the reference mechanism is prohibitively expensive on distributed systems.)"[1] I admire the frankness. It points the way forward to reasoned discussion of engineering tradeoffs, as opposed to programming language boosterism. (By contrast, the trashing of boosters and their rhetoric is an obvious service to humanity. See? I'm charitable!) I concealed the name of the programming language because people have a tendency to unfairly disregard and denigrate it in spite of (or because of?) its many excellent properties and suitability for robust and reliable systems, in contrast to slovenly prototypes that minimize launch costs and impose negative externalities on users (and on anyone unlucky enough to be stuck supporting them). But then again cowboy programmers and their managers likely don't read my drivel anyway. They're busy chasing AI money before the bubble bursts. Anyway--the language is Ada. Regards, Branden [1] Watt, Wichmann, Findlay. _Ada Language and Methodology_. Prentice-Hall, 1987, p. 395. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From douglas.mcilroy at dartmouth.edu Sun Sep 29 08:07:34 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 28 Sep 2024 18:07:34 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <9049DF63-F7BE-494F-BF7C-6BD0565C0D06@iitbombay.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <9049DF63-F7BE-494F-BF7C-6BD0565C0D06@iitbombay.org> Message-ID: I have to concede Branden's "gotcha". Struct copying is definitely not O(1). A real-life hazard of non-O(1) operations. Vic Vyssotsky put bzero (I forget what Vic called it) into Fortran II. Sometime later, he found that a percolation simulation was running annoyingly slowly. It took some study to discover that the real inner loop of the program was not the percolation, which touched only a small fraction of a 2D field. More time went into the innocuous bzero initializer. The fix was to ADD code to the inner loop to remember what entries had been touched, and initialize only those for the next round of the simulation. > for a while, every instruction has [sic] an exactly predictable and constant cycle > count. ...[Then] all of a sudden you had instructions with O(n) cycle counts. O(n) cycle counts were nothing new. In the 1950s we had the IBM 1620 with arbitrary-length arithmetic and the 709 with "convert" instructions whose cycle count went up to 256. >> spinelessly buckled to allow malloc(0) to return 0, as some >> implementations gratuitously did. > What was the alternative? There was no such thing as an exception, and > if a pointer was an int and an int was as wide as a machine address, > there'd be no way to indicate failure in-band, either. What makes you think allocating zero space should fail? If the size n of a set is determined at run time, why should one have to special-case its space allocation when n=0? Subsequent processing of the form for(i=0; i How does malloc(0) get this job done and what benefit does it bring? If I understand the "job" (about initializing structure members) correctly, malloc(0) has no bearing on it. The benefit lies elsewhere. Apropos of tail calls, Rob Pike had a nice name for an explicit tail call, "become". It's certainly reasonable, though, to make compilers recognize tail calls implicitly. [1] Worse didn't come to worst in the original malloc. It attached metadata to each block, so even blocks of size zero consumed some memory. Doug On Sat, Sep 28, 2024 at 1:59 PM Bakul Shah via TUHS wrote: > Just responding to random things that I noticed: > > You don't need special syntax for tail-call. It should be done > transparently when a call is the last thing that gets executed. Special > syntax will merely allow confused people to use it in the wrong place and > get confused more. > > malloc(0) should return a unique ptr. So that "T* a = malloc(0); T* b = > malloc(0); a != (T*)0 && a != b". Without this, malloc(0) acts differently > from malloc(n) for n > 0. > > Note that except for arrays, function arguments & result are copied so > copying a struct makes perfect sense. Passing arrays by reference may have > been due to residual Fortran influence! [Just guessing] Also note: that one > exception has been the cause of many problems. > > In any case you have not argued convincingly about why dynamic memory > allocation should be in the language (runtime) :-) And adding that wouldn't > have fixed any of the existing problems with the language. > > Bakul > > > On Sep 28, 2024, at 9:58 AM, G. Branden Robinson < > g.branden.robinson at gmail.com> wrote: > > > > At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: > >>> C's refusal to specify dynamic memory allocation in the language > >>> runtime (as opposed to, eventually, the standard library) > >> > >> This complaint overlooks one tenet of C: every operation in what you > >> call "language runtime" takes O(1) time. Dynamic memory allocation > >> is not such an operation. > > > > A fair point. Let me argue about it anyway. ;-) > > > > I'd make three observations. First, K&R did _not_ tout this in their > > book presenting ANSI C. I went back and checked the prefaces, > > introduction, and the section presenting a simple malloc()/free() > > implementation. The tenet you claim for the language is not explicitly > > articulated and, if I squint really hard, I can only barely perceive > > (imagine?) it deeply between the lines in some of the prefatory material > > to which K&R mostly confine their efforts to promote the language. In > > my view, a "tenet" is something more overt: the sort of thing U.S. > > politicians try to get hung on the walls of every public school > > classroom, like Henry Spencer's Ten Commandments of C[1] (which itself > > does not mention this "core language has only O(1) features" principle). > > > > Second, in reviewing K&R I was reminded that structure copying is part > > of the language. ("There are no operations that manipulate an entire > > array or string, although structures may be copied as a unit."[2]) > > Doesn't that break the tenet right there? > > > > Third, and following on from the foregoing, your point reminded me of my > > youth programming non-pipelined machines with no caches. You could set > > your watch by (just about) any instruction in the set--and often did, > > because we penurious microcomputer guys often lacked hardware real-time > > clocks, too. That is to say, for a while, every instruction has an > > exactly predictable and constant cycle count. (The _value_ of that > > constant might depend on the addressing mode, because that would have > > consequences on memory fetches, but the principle stood.) When the Z80 > > extended the 8080's instruction set, they ate from Tree of Knowledge > > with block-copy instructions like LDIR and LDDR, and all of a sudden you > > had instructions with O(n) cycle counts. But as a rule, programmers > > seemed to welcome this instead of recognizing it as knowing sin, because > > you generally knew worst-case how many bytes you'd be copying and take > > that into account. (The worst worst case was a mere 64kB!) > > > > Further, Z80 home computers in low-end configurations (that is, no disk > > drives) often did a shocking thing: they ran with all interrupts masked. > > All the time. The one non-maskable interrupt was RESET, after which you > > weren't going to be resuming execution of your program anyway. Not from > > the same instruction, at least. As I recall the TRS-80 Model I/III/4 > > didn't even have logic on the motherboard to decode the Z80's "interrupt > > mode 2", which was vectored, I think. Even in the "high-end" > > configurations of these tiny machines, you got a whopping ONE interrupt > > to play with ("IM 1"). > > > > Later, when the Hitachi 6309 smuggled similar block-transfer decadence > > into its extensions to the Motorola 6809 (to the excitement of we > > semi-consciously Unix-adjacent OS-9 users) they faced a starker problem, > > because the 6809 didn't wall off interrupts in the same way the 8080 and > > Z80. They therefore presented the programmer with the novelty of the > > restartable instruction, and a new generation of programmers became > > acquainted with the hard lessons time-sharing minicomputer people were > > familiar with. > > > > My point in this digression is that, in my opinion, it's tough to hold > > fast to the O(1) tenet you claim for C's core language and to another at > > the same time: the language's identity as a "portable assembly > > language". Unless every programmer has control over the compiler--and > > they don't--you can't predict when the compiler will emit an O(n) block > > transfer instruction. You'll just have to look at the disassembly. > > > > _Maybe_ you can retain purity by...never copying structs. I don't think > > lint or any other tool ever checked for this. Your advocacy of this > > tenet is the first time I've heard it presented. > > > > If you were to suggest to me that most of the time I've spent in my life > > arguing with C advocates was with rotten exemplars of the species and > > therefore was time wasted, I would concede the point. > > > > There's just so danged _many_ of them... > > > >> Your hobbyhorse awakened one of mine. > >> > >> malloc was in v7, before the C standard was written. The standard > >> spinelessly buckled to allow malloc(0) to return 0, as some > >> implementations gratuitously did. > > > > What was the alternative? There was no such thing as an exception, and > > if a pointer was an int and an int was as wide as a machine address, > > there'd be no way to indicate failure in-band, either. > > > > If the choice was that or another instance of atoi()'s wincingly awful > > "does this 0 represent an error or successful conversion of a zero > > input?" land mine, ANSI might have made the right choice. > > > >> I can't imagine that any program ever actually wanted the feature. Now > >> it's one more undefined behavior that lurks in thousands of programs. > > > > Hoare admitted to only one billion-dollar mistake. No one dares count > > how many to write in C's ledger. This was predicted, wasn't it? > > Everyone loved C because it was fast: it was performant, because it > > never met a runtime check it didn't eschew--recall again Kernighan > > punking Pascal on this exact point--and it was quick for the programmer > > to write because it never met a _compile_-time check it didn't eschew. > > C was born as a language for wizards who never made mistakes. > > > > The problem is that, like James Madison's fictive government of angels, > > such entities don't exist. The staff of the CSRC itself may have been > > overwhelmingly populated with frank, modest, and self-deprecating > > people--and I'll emphasize here that I'm aware of no accounts that this > > is anything but true--but C unfortunately played a part in stoking a > > culture of pretension among software developers. "C is a language in > > which wizards program. I program in C. Therefore I'm a wizard." is how > > the syllogism (spot the fallacy) went. I don't know who does more > > damage--the people who believe their own BS, or the ones who know > > they're scamming their colleagues. > > > >> There are two arguments for malloc(0), Most importantly, it caters for > >> a limiting case for aggregates generated at runtime--an instance of > >> Kernighan's Law, "Do nothing gracefully". It also provides a way to > >> create a distinctive pointer to impart some meta-information, e.g. > >> "TBD" or "end of subgroup", distinct from the null pointer, which > >> merely denotes absence. > > > > I think I might be confused now. I've frequently seen arrays of structs > > initialized from lists of literals ending in a series of "NULL" > > structure members, in code that antedates or ignores C99's wonderful > > feature of designated initializers for aggregate types.[3] How does > > malloc(0) get this job done and what benefit does it bring? > > > > Last time I posted to TUHS I mentioned a proposal for explicit tail-call > > elimination in C. I got the syntax wrong. The proposal was "return > > goto;". The WG14 document number is N2920 and it's by Alex Gilding. > > Good stuff.[4] I hope we see it in C2y. > > > > Predictably, I must confess that I didn't make much headway on > > Schiller's 1975 "secure kernel" paper. Maybe next time. > > > > Regards, > > Branden > > > > [1] https://web.cs.dal.ca/~jamie/UWO/C/the10fromHenryS.html > > > > I can easily imagine that the tenet held at _some_ point in the > > C's history. It's _got_ to be the reason that the language > > relegates memset() and memcpy() to the standard library (or to the > > programmer's own devise)! :-O > > > > [2] Kernighan & Ritchie, _The C Programming Language_, 2nd edition, p. 2 > > > > Having thus admitted the camel's nose to the tent, K&R would have > > done the world a major service by making memset(), or at least > > bzero(), a language feature, the latter perhaps by having "= 0" > > validly apply to an lvalue of non-primitive type. Okay, > > _potentially_ a major service. You'd still need the self-regarding > > wizard programmers to bother coding it, which they wouldn't in many > > cases "because speed". Move fast, break stuff. > > > > C++ screwed this up too, and stubbornly stuck by it for a long time. > > > > https://cplusplus.github.io/CWG/issues/178.html > > > > [3] https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html > > [4] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2920.pdf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther.johnson at makerlisp.com Sun Sep 29 08:08:12 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Sat, 28 Sep 2024 15:08:12 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928184630.tyifhjjynxeo4jh3@illithid> References: <20240928184630.tyifhjjynxeo4jh3@illithid> Message-ID: <761d9dba-0f0d-7cef-0990-5f93e5269826@makerlisp.com> "Classic C", K&R + void function return type, enumerations, and structure passing/return, maybe a couple other things (some bug fixes/stricter rules on use of members in structs and unions), has this, I use a compiler from 1983 that lines up with an AT&T System V document detailing updates to the language. I view these kinds of changes as incremental usability and reliability fixes, well within the spirit and style, but just closing loopholes or filling in gaps of things that ought to work together, and could, without too much effort. But I agree, structures as full-fledged citizens came late to K & R / Classic C. On 09/28/2024 11:46 AM, G. Branden Robinson wrote: > Hi Luther, > > At 2024-09-28T10:47:44-0700, Luther Johnson wrote: >> I don't know that structure copying breaks any complexity or bounds on >> execution time rules. Many compilers may be different, but in the >> generated code I've seen, when you pass in a structure to a function, >> the receiving function copies it to the stack. In the portable C >> compiler, when you return a structure as a result, it is first copied >> to a static area, a pointer to that area is returned, then the caller >> copies that out to wherever it's meant to go, either a variable that's >> being assigned (which could be on the stack or elsewhere), or to a >> place on the stack that was reserved for it because that result will >> now be an argument to another function to be called. So there's some >> copying, but that's proportional to the size of the structure, it's >> linear, and there's no dynamic memory allocation going on. > I have no problem with this presentation, but recall the principle--the > tenet--that Doug was upholding: > >>> At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: >>>> This complaint overlooks one tenet of C: every operation in what >>>> you call "language runtime" takes O(1) time. Dynamic memory >>>> allocation is not such an operation. > Even without dynamic memory allocation, if you did something linear, > something O(n), it was a lose and a violation of the tenet. > > I can easily see the appeal of a language whose every operation really > is O(1). Once upon a time, a university course, or equivalent > experience, in assembly language (on a CLEAN instruction set, not x86) > is what taught you the virtues and drawbacks of thinking about and > implementing things that way. But my view is that C hasn't been one of > those languages for a very long time, since before its initial ANSI > standardization at the latest. > > At 2024-09-28T10:52:16-0700, Luther Johnson wrote: >> In the compilers I'm talking about, you pass a structure by passing a >> pointer to it - but the receiving function knows the argument is a >> structure, and not a pointer to a structure, so it knows it needs to >> use the pointer to copy to its own local version. > It's my understanding that the ability to work with structs as > first-class citizens in function calls, as parameters _or_ return types, > was something fairly late to stabilize in C compilers. Second-hand, I > gather that pre-standard C as told by K&R explicitly did _not_ > countenance this. So a lot of early C code, including that in > libraries, indirected nearly all struct access, even when read-only, > through pointers. > > This is often a win, but not always. A few minutes ago I shot off my > mouth to this list about how much better the standard library design > could have been if the return of structs by value had been supported > much earlier. > > Our industry has, it seemss, been slow to appreciate the distinction > between what C++ eventually came to explicitly call "copy" semantics and > "move" semantics. Rust's paradigmatic dedication to the concept of data > "ownership" at last seems to be popularizing the practice of thinking > about these things. (For my part, I will forever hurl calumnies at > computer architects who refer to copy operations as "MOV" or similar. > If the operation doesn't destroy the source, it's not a move--I don't > care how many thousands of pages of manuals Intel writes saying > otherwise. Even the RISC-V specs screw this up, I assume in a > deliberate but embarrassing attempt to win mindshare among x86 > programmers who cling to this myth as they do so many others.) > > For a moment I considered giving credit to a virtuous few '80s C > programmers who recognized that there was indeed no need to copy a > struct upon passing it to a function if you knew the callee wasn't going > to modify that struct...but we had a way of saying this, "const", and > library writers of that era were infamously indifferent to using "const" > in their APIs where it would have done good. So, no, no credit. > > Here's a paragraph from a 1987 text I wish I'd read back then, or at any > time before being exposed to C. > > "[Language] does not define how parameter passing is implemented. A > program is erroneous if it depends on a specific implementation method. > The two obvious implementations are by copy and by reference. With an > implementation that copies parameters, an `out` or `in out` actual > parameter will not be updated until (normal) return from the subprogram. > Therefore if the subprogram propagates an exception, the actual > parameter will be unchanged. This is clearly not the case when a > reference implementation is used. The difficulty with this vagueness in > the definition of [language] is that it is quite awkward to be sure that > a program is independent of the implementation method. (You might > wonder why the language does not define the implementation method. The > reason is that the copy mechanism is very inefficient with large > parameters, whereas the reference mechanism is prohibitively expensive > on distributed systems.)"[1] > > I admire the frankness. It points the way forward to reasoned > discussion of engineering tradeoffs, as opposed to programming language > boosterism. (By contrast, the trashing of boosters and their rhetoric > is an obvious service to humanity. See? I'm charitable!) > > I concealed the name of the programming language because people have a > tendency to unfairly disregard and denigrate it in spite of (or because > of?) its many excellent properties and suitability for robust and > reliable systems, in contrast to slovenly prototypes that minimize > launch costs and impose negative externalities on users (and on anyone > unlucky enough to be stuck supporting them). But then again cowboy > programmers and their managers likely don't read my drivel anyway. > They're busy chasing AI money before the bubble bursts. > > Anyway--the language is Ada. > > Regards, > Branden > > [1] Watt, Wichmann, Findlay. _Ada Language and Methodology_. > Prentice-Hall, 1987, p. 395. From luther.johnson at makerlisp.com Sun Sep 29 08:45:26 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Sat, 28 Sep 2024 15:45:26 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <761d9dba-0f0d-7cef-0990-5f93e5269826@makerlisp.com> References: <20240928184630.tyifhjjynxeo4jh3@illithid> <761d9dba-0f0d-7cef-0990-5f93e5269826@makerlisp.com> Message-ID: <094ff93e-5078-02ad-dff7-2ecdf12eac6c@makerlisp.com> G. Branden, I get it. From your and Doug's responses, even O(n) baked-in costs can be a problem. On 09/28/2024 03:08 PM, Luther Johnson wrote: > "Classic C", K&R + void function return type, enumerations, and > structure passing/return, maybe a couple other things (some bug > fixes/stricter rules on use of members in structs and unions), has > this, I use a compiler from 1983 that lines up with an AT&T System V > document detailing updates to the language. > > I view these kinds of changes as incremental usability and reliability > fixes, well within the spirit and style, but just closing loopholes or > filling in gaps of things that ought to work together, and could, > without too much effort. But I agree, structures as full-fledged > citizens came late to K & R / Classic C. > > On 09/28/2024 11:46 AM, G. Branden Robinson wrote: >> Hi Luther, >> >> At 2024-09-28T10:47:44-0700, Luther Johnson wrote: >>> I don't know that structure copying breaks any complexity or bounds on >>> execution time rules. Many compilers may be different, but in the >>> generated code I've seen, when you pass in a structure to a function, >>> the receiving function copies it to the stack. In the portable C >>> compiler, when you return a structure as a result, it is first copied >>> to a static area, a pointer to that area is returned, then the caller >>> copies that out to wherever it's meant to go, either a variable that's >>> being assigned (which could be on the stack or elsewhere), or to a >>> place on the stack that was reserved for it because that result will >>> now be an argument to another function to be called. So there's some >>> copying, but that's proportional to the size of the structure, it's >>> linear, and there's no dynamic memory allocation going on. >> I have no problem with this presentation, but recall the principle--the >> tenet--that Doug was upholding: >> >>>> At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: >>>>> This complaint overlooks one tenet of C: every operation in what >>>>> you call "language runtime" takes O(1) time. Dynamic memory >>>>> allocation is not such an operation. >> Even without dynamic memory allocation, if you did something linear, >> something O(n), it was a lose and a violation of the tenet. >> >> I can easily see the appeal of a language whose every operation really >> is O(1). Once upon a time, a university course, or equivalent >> experience, in assembly language (on a CLEAN instruction set, not x86) >> is what taught you the virtues and drawbacks of thinking about and >> implementing things that way. But my view is that C hasn't been one of >> those languages for a very long time, since before its initial ANSI >> standardization at the latest. >> >> At 2024-09-28T10:52:16-0700, Luther Johnson wrote: >>> In the compilers I'm talking about, you pass a structure by passing a >>> pointer to it - but the receiving function knows the argument is a >>> structure, and not a pointer to a structure, so it knows it needs to >>> use the pointer to copy to its own local version. >> It's my understanding that the ability to work with structs as >> first-class citizens in function calls, as parameters _or_ return types, >> was something fairly late to stabilize in C compilers. Second-hand, I >> gather that pre-standard C as told by K&R explicitly did _not_ >> countenance this. So a lot of early C code, including that in >> libraries, indirected nearly all struct access, even when read-only, >> through pointers. >> >> This is often a win, but not always. A few minutes ago I shot off my >> mouth to this list about how much better the standard library design >> could have been if the return of structs by value had been supported >> much earlier. >> >> Our industry has, it seemss, been slow to appreciate the distinction >> between what C++ eventually came to explicitly call "copy" semantics and >> "move" semantics. Rust's paradigmatic dedication to the concept of data >> "ownership" at last seems to be popularizing the practice of thinking >> about these things. (For my part, I will forever hurl calumnies at >> computer architects who refer to copy operations as "MOV" or similar. >> If the operation doesn't destroy the source, it's not a move--I don't >> care how many thousands of pages of manuals Intel writes saying >> otherwise. Even the RISC-V specs screw this up, I assume in a >> deliberate but embarrassing attempt to win mindshare among x86 >> programmers who cling to this myth as they do so many others.) >> >> For a moment I considered giving credit to a virtuous few '80s C >> programmers who recognized that there was indeed no need to copy a >> struct upon passing it to a function if you knew the callee wasn't going >> to modify that struct...but we had a way of saying this, "const", and >> library writers of that era were infamously indifferent to using "const" >> in their APIs where it would have done good. So, no, no credit. >> >> Here's a paragraph from a 1987 text I wish I'd read back then, or at any >> time before being exposed to C. >> >> "[Language] does not define how parameter passing is implemented. A >> program is erroneous if it depends on a specific implementation method. >> The two obvious implementations are by copy and by reference. With an >> implementation that copies parameters, an `out` or `in out` actual >> parameter will not be updated until (normal) return from the subprogram. >> Therefore if the subprogram propagates an exception, the actual >> parameter will be unchanged. This is clearly not the case when a >> reference implementation is used. The difficulty with this vagueness in >> the definition of [language] is that it is quite awkward to be sure that >> a program is independent of the implementation method. (You might >> wonder why the language does not define the implementation method. The >> reason is that the copy mechanism is very inefficient with large >> parameters, whereas the reference mechanism is prohibitively expensive >> on distributed systems.)"[1] >> >> I admire the frankness. It points the way forward to reasoned >> discussion of engineering tradeoffs, as opposed to programming language >> boosterism. (By contrast, the trashing of boosters and their rhetoric >> is an obvious service to humanity. See? I'm charitable!) >> >> I concealed the name of the programming language because people have a >> tendency to unfairly disregard and denigrate it in spite of (or because >> of?) its many excellent properties and suitability for robust and >> reliable systems, in contrast to slovenly prototypes that minimize >> launch costs and impose negative externalities on users (and on anyone >> unlucky enough to be stuck supporting them). But then again cowboy >> programmers and their managers likely don't read my drivel anyway. >> They're busy chasing AI money before the bubble bursts. >> >> Anyway--the language is Ada. >> >> Regards, >> Branden >> >> [1] Watt, Wichmann, Findlay. _Ada Language and Methodology_. >> Prentice-Hall, 1987, p. 395. > From luther.johnson at makerlisp.com Sun Sep 29 08:50:10 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Sat, 28 Sep 2024 15:50:10 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <094ff93e-5078-02ad-dff7-2ecdf12eac6c@makerlisp.com> References: <20240928184630.tyifhjjynxeo4jh3@illithid> <761d9dba-0f0d-7cef-0990-5f93e5269826@makerlisp.com> <094ff93e-5078-02ad-dff7-2ecdf12eac6c@makerlisp.com> Message-ID: <0e4994cd-4619-a937-a84a-9d0831336aee@makerlisp.com> Or to your point, we have some of these problems no matter what, so that's not a completely valid reason not to have some other facility, on the basis of its cost profile, when other things already in, have similar orders of costs. On 09/28/2024 03:45 PM, Luther Johnson wrote: > G. Branden, > > I get it. From your and Doug's responses, even O(n) baked-in costs can > be a problem. > > On 09/28/2024 03:08 PM, Luther Johnson wrote: >> "Classic C", K&R + void function return type, enumerations, and >> structure passing/return, maybe a couple other things (some bug >> fixes/stricter rules on use of members in structs and unions), has >> this, I use a compiler from 1983 that lines up with an AT&T System V >> document detailing updates to the language. >> >> I view these kinds of changes as incremental usability and >> reliability fixes, well within the spirit and style, but just closing >> loopholes or filling in gaps of things that ought to work together, >> and could, without too much effort. But I agree, structures as >> full-fledged citizens came late to K & R / Classic C. >> >> On 09/28/2024 11:46 AM, G. Branden Robinson wrote: >>> Hi Luther, >>> >>> At 2024-09-28T10:47:44-0700, Luther Johnson wrote: >>>> I don't know that structure copying breaks any complexity or bounds on >>>> execution time rules. Many compilers may be different, but in the >>>> generated code I've seen, when you pass in a structure to a function, >>>> the receiving function copies it to the stack. In the portable C >>>> compiler, when you return a structure as a result, it is first copied >>>> to a static area, a pointer to that area is returned, then the caller >>>> copies that out to wherever it's meant to go, either a variable that's >>>> being assigned (which could be on the stack or elsewhere), or to a >>>> place on the stack that was reserved for it because that result will >>>> now be an argument to another function to be called. So there's some >>>> copying, but that's proportional to the size of the structure, it's >>>> linear, and there's no dynamic memory allocation going on. >>> I have no problem with this presentation, but recall the principle--the >>> tenet--that Doug was upholding: >>> >>>>> At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: >>>>>> This complaint overlooks one tenet of C: every operation in what >>>>>> you call "language runtime" takes O(1) time. Dynamic memory >>>>>> allocation is not such an operation. >>> Even without dynamic memory allocation, if you did something linear, >>> something O(n), it was a lose and a violation of the tenet. >>> >>> I can easily see the appeal of a language whose every operation really >>> is O(1). Once upon a time, a university course, or equivalent >>> experience, in assembly language (on a CLEAN instruction set, not x86) >>> is what taught you the virtues and drawbacks of thinking about and >>> implementing things that way. But my view is that C hasn't been one of >>> those languages for a very long time, since before its initial ANSI >>> standardization at the latest. >>> >>> At 2024-09-28T10:52:16-0700, Luther Johnson wrote: >>>> In the compilers I'm talking about, you pass a structure by passing a >>>> pointer to it - but the receiving function knows the argument is a >>>> structure, and not a pointer to a structure, so it knows it needs to >>>> use the pointer to copy to its own local version. >>> It's my understanding that the ability to work with structs as >>> first-class citizens in function calls, as parameters _or_ return >>> types, >>> was something fairly late to stabilize in C compilers. Second-hand, I >>> gather that pre-standard C as told by K&R explicitly did _not_ >>> countenance this. So a lot of early C code, including that in >>> libraries, indirected nearly all struct access, even when read-only, >>> through pointers. >>> >>> This is often a win, but not always. A few minutes ago I shot off my >>> mouth to this list about how much better the standard library design >>> could have been if the return of structs by value had been supported >>> much earlier. >>> >>> Our industry has, it seemss, been slow to appreciate the distinction >>> between what C++ eventually came to explicitly call "copy" semantics >>> and >>> "move" semantics. Rust's paradigmatic dedication to the concept of >>> data >>> "ownership" at last seems to be popularizing the practice of thinking >>> about these things. (For my part, I will forever hurl calumnies at >>> computer architects who refer to copy operations as "MOV" or similar. >>> If the operation doesn't destroy the source, it's not a move--I don't >>> care how many thousands of pages of manuals Intel writes saying >>> otherwise. Even the RISC-V specs screw this up, I assume in a >>> deliberate but embarrassing attempt to win mindshare among x86 >>> programmers who cling to this myth as they do so many others.) >>> >>> For a moment I considered giving credit to a virtuous few '80s C >>> programmers who recognized that there was indeed no need to copy a >>> struct upon passing it to a function if you knew the callee wasn't >>> going >>> to modify that struct...but we had a way of saying this, "const", and >>> library writers of that era were infamously indifferent to using >>> "const" >>> in their APIs where it would have done good. So, no, no credit. >>> >>> Here's a paragraph from a 1987 text I wish I'd read back then, or at >>> any >>> time before being exposed to C. >>> >>> "[Language] does not define how parameter passing is implemented. A >>> program is erroneous if it depends on a specific implementation method. >>> The two obvious implementations are by copy and by reference. With an >>> implementation that copies parameters, an `out` or `in out` actual >>> parameter will not be updated until (normal) return from the >>> subprogram. >>> Therefore if the subprogram propagates an exception, the actual >>> parameter will be unchanged. This is clearly not the case when a >>> reference implementation is used. The difficulty with this >>> vagueness in >>> the definition of [language] is that it is quite awkward to be sure >>> that >>> a program is independent of the implementation method. (You might >>> wonder why the language does not define the implementation method. The >>> reason is that the copy mechanism is very inefficient with large >>> parameters, whereas the reference mechanism is prohibitively expensive >>> on distributed systems.)"[1] >>> >>> I admire the frankness. It points the way forward to reasoned >>> discussion of engineering tradeoffs, as opposed to programming language >>> boosterism. (By contrast, the trashing of boosters and their rhetoric >>> is an obvious service to humanity. See? I'm charitable!) >>> >>> I concealed the name of the programming language because people have a >>> tendency to unfairly disregard and denigrate it in spite of (or because >>> of?) its many excellent properties and suitability for robust and >>> reliable systems, in contrast to slovenly prototypes that minimize >>> launch costs and impose negative externalities on users (and on anyone >>> unlucky enough to be stuck supporting them). But then again cowboy >>> programmers and their managers likely don't read my drivel anyway. >>> They're busy chasing AI money before the bubble bursts. >>> >>> Anyway--the language is Ada. >>> >>> Regards, >>> Branden >>> >>> [1] Watt, Wichmann, Findlay. _Ada Language and Methodology_. >>> Prentice-Hall, 1987, p. 395. >> > From robpike at gmail.com Sun Sep 29 09:05:35 2024 From: robpike at gmail.com (Rob Pike) Date: Sun, 29 Sep 2024 09:05:35 +1000 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <9049DF63-F7BE-494F-BF7C-6BD0565C0D06@iitbombay.org> Message-ID: I wrote a letter to the ANSI C (1989) committee. Please allow malloc(0). Please allow zero-length arrays. I got two letters back, saying that malloc(0) is illegal because zero-length arrays are illegal, and the other vice versa. I fumed. -rob On Sun, Sep 29, 2024 at 8:08 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > I have to concede Branden's "gotcha". Struct copying is definitely not > O(1). > > A real-life hazard of non-O(1) operations. Vic Vyssotsky put bzero (I > forget what Vic called it) into Fortran II. Sometime later, he found that a > percolation simulation was running annoyingly slowly. It took some study to > discover that the real inner loop of the program was not the percolation, > which touched only a small fraction of a 2D field. More time went into the > innocuous bzero initializer. The fix was to ADD code to the inner loop to > remember what entries had been touched, and initialize only those for the > next round of the simulation. > > > for a while, every instruction has [sic] an exactly predictable and > constant cycle > > count. ...[Then] all of a sudden you had instructions with O(n) cycle > counts. > > O(n) cycle counts were nothing new. In the 1950s we had the IBM 1620 with > arbitrary-length arithmetic and the 709 with "convert" instructions whose > cycle count went up to 256. > > >> spinelessly buckled to allow malloc(0) to return 0, as some > >> implementations gratuitously did. > > > What was the alternative? There was no such thing as an exception, and > > if a pointer was an int and an int was as wide as a machine address, > > there'd be no way to indicate failure in-band, either. > > What makes you think allocating zero space should fail? If the size n of a > set is determined at run time, why should one have to special-case its > space allocation when n=0? Subsequent processing of the form for(i=0; i i++) {...} will handle it gracefully with no special code. Malloc should do > as it did in v7--return a non-null pointer different from any other active > malloc pointer, as Bakul stated. If worse comes to worst[1] this can be > done by padding up to the next feasible size. Regardless of how the pointer > is created, any access via it would of course be out of bounds and hence > wrong. > > > How does malloc(0) get this job done and what benefit does it bring? > > If I understand the "job" (about initializing structure members) > correctly, malloc(0) has no bearing on it. The benefit lies elsewhere. > > Apropos of tail calls, Rob Pike had a nice name for an explicit tail call, > "become". It's certainly reasonable, though, to make compilers recognize > tail calls implicitly. > > [1] Worse didn't come to worst in the original malloc. It attached > metadata to each block, so even blocks of size zero consumed some memory. > > Doug > > On Sat, Sep 28, 2024 at 1:59 PM Bakul Shah via TUHS wrote: > >> Just responding to random things that I noticed: >> >> You don't need special syntax for tail-call. It should be done >> transparently when a call is the last thing that gets executed. Special >> syntax will merely allow confused people to use it in the wrong place and >> get confused more. >> >> malloc(0) should return a unique ptr. So that "T* a = malloc(0); T* b = >> malloc(0); a != (T*)0 && a != b". Without this, malloc(0) acts differently >> from malloc(n) for n > 0. >> >> Note that except for arrays, function arguments & result are copied so >> copying a struct makes perfect sense. Passing arrays by reference may have >> been due to residual Fortran influence! [Just guessing] Also note: that one >> exception has been the cause of many problems. >> >> In any case you have not argued convincingly about why dynamic memory >> allocation should be in the language (runtime) :-) And adding that wouldn't >> have fixed any of the existing problems with the language. >> >> Bakul >> >> > On Sep 28, 2024, at 9:58 AM, G. Branden Robinson < >> g.branden.robinson at gmail.com> wrote: >> > >> > At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: >> >>> C's refusal to specify dynamic memory allocation in the language >> >>> runtime (as opposed to, eventually, the standard library) >> >> >> >> This complaint overlooks one tenet of C: every operation in what you >> >> call "language runtime" takes O(1) time. Dynamic memory allocation >> >> is not such an operation. >> > >> > A fair point. Let me argue about it anyway. ;-) >> > >> > I'd make three observations. First, K&R did _not_ tout this in their >> > book presenting ANSI C. I went back and checked the prefaces, >> > introduction, and the section presenting a simple malloc()/free() >> > implementation. The tenet you claim for the language is not explicitly >> > articulated and, if I squint really hard, I can only barely perceive >> > (imagine?) it deeply between the lines in some of the prefatory material >> > to which K&R mostly confine their efforts to promote the language. In >> > my view, a "tenet" is something more overt: the sort of thing U.S. >> > politicians try to get hung on the walls of every public school >> > classroom, like Henry Spencer's Ten Commandments of C[1] (which itself >> > does not mention this "core language has only O(1) features" principle). >> > >> > Second, in reviewing K&R I was reminded that structure copying is part >> > of the language. ("There are no operations that manipulate an entire >> > array or string, although structures may be copied as a unit."[2]) >> > Doesn't that break the tenet right there? >> > >> > Third, and following on from the foregoing, your point reminded me of my >> > youth programming non-pipelined machines with no caches. You could set >> > your watch by (just about) any instruction in the set--and often did, >> > because we penurious microcomputer guys often lacked hardware real-time >> > clocks, too. That is to say, for a while, every instruction has an >> > exactly predictable and constant cycle count. (The _value_ of that >> > constant might depend on the addressing mode, because that would have >> > consequences on memory fetches, but the principle stood.) When the Z80 >> > extended the 8080's instruction set, they ate from Tree of Knowledge >> > with block-copy instructions like LDIR and LDDR, and all of a sudden you >> > had instructions with O(n) cycle counts. But as a rule, programmers >> > seemed to welcome this instead of recognizing it as knowing sin, because >> > you generally knew worst-case how many bytes you'd be copying and take >> > that into account. (The worst worst case was a mere 64kB!) >> > >> > Further, Z80 home computers in low-end configurations (that is, no disk >> > drives) often did a shocking thing: they ran with all interrupts masked. >> > All the time. The one non-maskable interrupt was RESET, after which you >> > weren't going to be resuming execution of your program anyway. Not from >> > the same instruction, at least. As I recall the TRS-80 Model I/III/4 >> > didn't even have logic on the motherboard to decode the Z80's "interrupt >> > mode 2", which was vectored, I think. Even in the "high-end" >> > configurations of these tiny machines, you got a whopping ONE interrupt >> > to play with ("IM 1"). >> > >> > Later, when the Hitachi 6309 smuggled similar block-transfer decadence >> > into its extensions to the Motorola 6809 (to the excitement of we >> > semi-consciously Unix-adjacent OS-9 users) they faced a starker problem, >> > because the 6809 didn't wall off interrupts in the same way the 8080 and >> > Z80. They therefore presented the programmer with the novelty of the >> > restartable instruction, and a new generation of programmers became >> > acquainted with the hard lessons time-sharing minicomputer people were >> > familiar with. >> > >> > My point in this digression is that, in my opinion, it's tough to hold >> > fast to the O(1) tenet you claim for C's core language and to another at >> > the same time: the language's identity as a "portable assembly >> > language". Unless every programmer has control over the compiler--and >> > they don't--you can't predict when the compiler will emit an O(n) block >> > transfer instruction. You'll just have to look at the disassembly. >> > >> > _Maybe_ you can retain purity by...never copying structs. I don't think >> > lint or any other tool ever checked for this. Your advocacy of this >> > tenet is the first time I've heard it presented. >> > >> > If you were to suggest to me that most of the time I've spent in my life >> > arguing with C advocates was with rotten exemplars of the species and >> > therefore was time wasted, I would concede the point. >> > >> > There's just so danged _many_ of them... >> > >> >> Your hobbyhorse awakened one of mine. >> >> >> >> malloc was in v7, before the C standard was written. The standard >> >> spinelessly buckled to allow malloc(0) to return 0, as some >> >> implementations gratuitously did. >> > >> > What was the alternative? There was no such thing as an exception, and >> > if a pointer was an int and an int was as wide as a machine address, >> > there'd be no way to indicate failure in-band, either. >> > >> > If the choice was that or another instance of atoi()'s wincingly awful >> > "does this 0 represent an error or successful conversion of a zero >> > input?" land mine, ANSI might have made the right choice. >> > >> >> I can't imagine that any program ever actually wanted the feature. Now >> >> it's one more undefined behavior that lurks in thousands of programs. >> > >> > Hoare admitted to only one billion-dollar mistake. No one dares count >> > how many to write in C's ledger. This was predicted, wasn't it? >> > Everyone loved C because it was fast: it was performant, because it >> > never met a runtime check it didn't eschew--recall again Kernighan >> > punking Pascal on this exact point--and it was quick for the programmer >> > to write because it never met a _compile_-time check it didn't eschew. >> > C was born as a language for wizards who never made mistakes. >> > >> > The problem is that, like James Madison's fictive government of angels, >> > such entities don't exist. The staff of the CSRC itself may have been >> > overwhelmingly populated with frank, modest, and self-deprecating >> > people--and I'll emphasize here that I'm aware of no accounts that this >> > is anything but true--but C unfortunately played a part in stoking a >> > culture of pretension among software developers. "C is a language in >> > which wizards program. I program in C. Therefore I'm a wizard." is how >> > the syllogism (spot the fallacy) went. I don't know who does more >> > damage--the people who believe their own BS, or the ones who know >> > they're scamming their colleagues. >> > >> >> There are two arguments for malloc(0), Most importantly, it caters for >> >> a limiting case for aggregates generated at runtime--an instance of >> >> Kernighan's Law, "Do nothing gracefully". It also provides a way to >> >> create a distinctive pointer to impart some meta-information, e.g. >> >> "TBD" or "end of subgroup", distinct from the null pointer, which >> >> merely denotes absence. >> > >> > I think I might be confused now. I've frequently seen arrays of structs >> > initialized from lists of literals ending in a series of "NULL" >> > structure members, in code that antedates or ignores C99's wonderful >> > feature of designated initializers for aggregate types.[3] How does >> > malloc(0) get this job done and what benefit does it bring? >> > >> > Last time I posted to TUHS I mentioned a proposal for explicit tail-call >> > elimination in C. I got the syntax wrong. The proposal was "return >> > goto;". The WG14 document number is N2920 and it's by Alex Gilding. >> > Good stuff.[4] I hope we see it in C2y. >> > >> > Predictably, I must confess that I didn't make much headway on >> > Schiller's 1975 "secure kernel" paper. Maybe next time. >> > >> > Regards, >> > Branden >> > >> > [1] https://web.cs.dal.ca/~jamie/UWO/C/the10fromHenryS.html >> > >> > I can easily imagine that the tenet held at _some_ point in the >> > C's history. It's _got_ to be the reason that the language >> > relegates memset() and memcpy() to the standard library (or to the >> > programmer's own devise)! :-O >> > >> > [2] Kernighan & Ritchie, _The C Programming Language_, 2nd edition, p. 2 >> > >> > Having thus admitted the camel's nose to the tent, K&R would have >> > done the world a major service by making memset(), or at least >> > bzero(), a language feature, the latter perhaps by having "= 0" >> > validly apply to an lvalue of non-primitive type. Okay, >> > _potentially_ a major service. You'd still need the self-regarding >> > wizard programmers to bother coding it, which they wouldn't in many >> > cases "because speed". Move fast, break stuff. >> > >> > C++ screwed this up too, and stubbornly stuck by it for a long time. >> > >> > https://cplusplus.github.io/CWG/issues/178.html >> > >> > [3] https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html >> > [4] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2920.pdf >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Sep 29 09:30:20 2024 From: imp at bsdimp.com (Warner Losh) Date: Sat, 28 Sep 2024 17:30:20 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <9049DF63-F7BE-494F-BF7C-6BD0565C0D06@iitbombay.org> Message-ID: On Sat, Sep 28, 2024, 5:05 PM Rob Pike wrote: > I wrote a letter to the ANSI C (1989) committee. > > Please allow malloc(0). > Please allow zero-length arrays. > > I got two letters back, saying that malloc(0) is illegal because > zero-length arrays are illegal, and the other vice versa. > > I fumed. > And now we have zero length arrays an UB malloc(0). Warner -rob > > > On Sun, Sep 29, 2024 at 8:08 AM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> I have to concede Branden's "gotcha". Struct copying is definitely not >> O(1). >> >> A real-life hazard of non-O(1) operations. Vic Vyssotsky put bzero (I >> forget what Vic called it) into Fortran II. Sometime later, he found that a >> percolation simulation was running annoyingly slowly. It took some study to >> discover that the real inner loop of the program was not the percolation, >> which touched only a small fraction of a 2D field. More time went into the >> innocuous bzero initializer. The fix was to ADD code to the inner loop to >> remember what entries had been touched, and initialize only those for the >> next round of the simulation. >> >> > for a while, every instruction has [sic] an exactly predictable and >> constant cycle >> > count. ...[Then] all of a sudden you had instructions with O(n) cycle >> counts. >> >> O(n) cycle counts were nothing new. In the 1950s we had the IBM 1620 >> with arbitrary-length arithmetic and the 709 with "convert" instructions >> whose cycle count went up to 256. >> >> >> spinelessly buckled to allow malloc(0) to return 0, as some >> >> implementations gratuitously did. >> >> > What was the alternative? There was no such thing as an exception, and >> > if a pointer was an int and an int was as wide as a machine address, >> > there'd be no way to indicate failure in-band, either. >> >> What makes you think allocating zero space should fail? If the size n of >> a set is determined at run time, why should one have to special-case its >> space allocation when n=0? Subsequent processing of the form for(i=0; i> i++) {...} will handle it gracefully with no special code. Malloc should do >> as it did in v7--return a non-null pointer different from any other active >> malloc pointer, as Bakul stated. If worse comes to worst[1] this can be >> done by padding up to the next feasible size. Regardless of how the pointer >> is created, any access via it would of course be out of bounds and hence >> wrong. >> >> > How does malloc(0) get this job done and what benefit does it bring? >> >> If I understand the "job" (about initializing structure members) >> correctly, malloc(0) has no bearing on it. The benefit lies elsewhere. >> >> Apropos of tail calls, Rob Pike had a nice name for an explicit tail >> call, "become". It's certainly reasonable, though, to make compilers >> recognize tail calls implicitly. >> >> [1] Worse didn't come to worst in the original malloc. It attached >> metadata to each block, so even blocks of size zero consumed some memory. >> >> Doug >> >> On Sat, Sep 28, 2024 at 1:59 PM Bakul Shah via TUHS >> wrote: >> >>> Just responding to random things that I noticed: >>> >>> You don't need special syntax for tail-call. It should be done >>> transparently when a call is the last thing that gets executed. Special >>> syntax will merely allow confused people to use it in the wrong place and >>> get confused more. >>> >>> malloc(0) should return a unique ptr. So that "T* a = malloc(0); T* b = >>> malloc(0); a != (T*)0 && a != b". Without this, malloc(0) acts differently >>> from malloc(n) for n > 0. >>> >>> Note that except for arrays, function arguments & result are copied so >>> copying a struct makes perfect sense. Passing arrays by reference may have >>> been due to residual Fortran influence! [Just guessing] Also note: that one >>> exception has been the cause of many problems. >>> >>> In any case you have not argued convincingly about why dynamic memory >>> allocation should be in the language (runtime) :-) And adding that wouldn't >>> have fixed any of the existing problems with the language. >>> >>> Bakul >>> >>> > On Sep 28, 2024, at 9:58 AM, G. Branden Robinson < >>> g.branden.robinson at gmail.com> wrote: >>> > >>> > At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: >>> >>> C's refusal to specify dynamic memory allocation in the language >>> >>> runtime (as opposed to, eventually, the standard library) >>> >> >>> >> This complaint overlooks one tenet of C: every operation in what you >>> >> call "language runtime" takes O(1) time. Dynamic memory allocation >>> >> is not such an operation. >>> > >>> > A fair point. Let me argue about it anyway. ;-) >>> > >>> > I'd make three observations. First, K&R did _not_ tout this in their >>> > book presenting ANSI C. I went back and checked the prefaces, >>> > introduction, and the section presenting a simple malloc()/free() >>> > implementation. The tenet you claim for the language is not explicitly >>> > articulated and, if I squint really hard, I can only barely perceive >>> > (imagine?) it deeply between the lines in some of the prefatory >>> material >>> > to which K&R mostly confine their efforts to promote the language. In >>> > my view, a "tenet" is something more overt: the sort of thing U.S. >>> > politicians try to get hung on the walls of every public school >>> > classroom, like Henry Spencer's Ten Commandments of C[1] (which itself >>> > does not mention this "core language has only O(1) features" >>> principle). >>> > >>> > Second, in reviewing K&R I was reminded that structure copying is part >>> > of the language. ("There are no operations that manipulate an entire >>> > array or string, although structures may be copied as a unit."[2]) >>> > Doesn't that break the tenet right there? >>> > >>> > Third, and following on from the foregoing, your point reminded me of >>> my >>> > youth programming non-pipelined machines with no caches. You could set >>> > your watch by (just about) any instruction in the set--and often did, >>> > because we penurious microcomputer guys often lacked hardware real-time >>> > clocks, too. That is to say, for a while, every instruction has an >>> > exactly predictable and constant cycle count. (The _value_ of that >>> > constant might depend on the addressing mode, because that would have >>> > consequences on memory fetches, but the principle stood.) When the Z80 >>> > extended the 8080's instruction set, they ate from Tree of Knowledge >>> > with block-copy instructions like LDIR and LDDR, and all of a sudden >>> you >>> > had instructions with O(n) cycle counts. But as a rule, programmers >>> > seemed to welcome this instead of recognizing it as knowing sin, >>> because >>> > you generally knew worst-case how many bytes you'd be copying and take >>> > that into account. (The worst worst case was a mere 64kB!) >>> > >>> > Further, Z80 home computers in low-end configurations (that is, no disk >>> > drives) often did a shocking thing: they ran with all interrupts >>> masked. >>> > All the time. The one non-maskable interrupt was RESET, after which >>> you >>> > weren't going to be resuming execution of your program anyway. Not >>> from >>> > the same instruction, at least. As I recall the TRS-80 Model I/III/4 >>> > didn't even have logic on the motherboard to decode the Z80's >>> "interrupt >>> > mode 2", which was vectored, I think. Even in the "high-end" >>> > configurations of these tiny machines, you got a whopping ONE interrupt >>> > to play with ("IM 1"). >>> > >>> > Later, when the Hitachi 6309 smuggled similar block-transfer decadence >>> > into its extensions to the Motorola 6809 (to the excitement of we >>> > semi-consciously Unix-adjacent OS-9 users) they faced a starker >>> problem, >>> > because the 6809 didn't wall off interrupts in the same way the 8080 >>> and >>> > Z80. They therefore presented the programmer with the novelty of the >>> > restartable instruction, and a new generation of programmers became >>> > acquainted with the hard lessons time-sharing minicomputer people were >>> > familiar with. >>> > >>> > My point in this digression is that, in my opinion, it's tough to hold >>> > fast to the O(1) tenet you claim for C's core language and to another >>> at >>> > the same time: the language's identity as a "portable assembly >>> > language". Unless every programmer has control over the compiler--and >>> > they don't--you can't predict when the compiler will emit an O(n) block >>> > transfer instruction. You'll just have to look at the disassembly. >>> > >>> > _Maybe_ you can retain purity by...never copying structs. I don't >>> think >>> > lint or any other tool ever checked for this. Your advocacy of this >>> > tenet is the first time I've heard it presented. >>> > >>> > If you were to suggest to me that most of the time I've spent in my >>> life >>> > arguing with C advocates was with rotten exemplars of the species and >>> > therefore was time wasted, I would concede the point. >>> > >>> > There's just so danged _many_ of them... >>> > >>> >> Your hobbyhorse awakened one of mine. >>> >> >>> >> malloc was in v7, before the C standard was written. The standard >>> >> spinelessly buckled to allow malloc(0) to return 0, as some >>> >> implementations gratuitously did. >>> > >>> > What was the alternative? There was no such thing as an exception, and >>> > if a pointer was an int and an int was as wide as a machine address, >>> > there'd be no way to indicate failure in-band, either. >>> > >>> > If the choice was that or another instance of atoi()'s wincingly awful >>> > "does this 0 represent an error or successful conversion of a zero >>> > input?" land mine, ANSI might have made the right choice. >>> > >>> >> I can't imagine that any program ever actually wanted the feature. Now >>> >> it's one more undefined behavior that lurks in thousands of programs. >>> > >>> > Hoare admitted to only one billion-dollar mistake. No one dares count >>> > how many to write in C's ledger. This was predicted, wasn't it? >>> > Everyone loved C because it was fast: it was performant, because it >>> > never met a runtime check it didn't eschew--recall again Kernighan >>> > punking Pascal on this exact point--and it was quick for the programmer >>> > to write because it never met a _compile_-time check it didn't eschew. >>> > C was born as a language for wizards who never made mistakes. >>> > >>> > The problem is that, like James Madison's fictive government of angels, >>> > such entities don't exist. The staff of the CSRC itself may have been >>> > overwhelmingly populated with frank, modest, and self-deprecating >>> > people--and I'll emphasize here that I'm aware of no accounts that this >>> > is anything but true--but C unfortunately played a part in stoking a >>> > culture of pretension among software developers. "C is a language in >>> > which wizards program. I program in C. Therefore I'm a wizard." is >>> how >>> > the syllogism (spot the fallacy) went. I don't know who does more >>> > damage--the people who believe their own BS, or the ones who know >>> > they're scamming their colleagues. >>> > >>> >> There are two arguments for malloc(0), Most importantly, it caters for >>> >> a limiting case for aggregates generated at runtime--an instance of >>> >> Kernighan's Law, "Do nothing gracefully". It also provides a way to >>> >> create a distinctive pointer to impart some meta-information, e.g. >>> >> "TBD" or "end of subgroup", distinct from the null pointer, which >>> >> merely denotes absence. >>> > >>> > I think I might be confused now. I've frequently seen arrays of >>> structs >>> > initialized from lists of literals ending in a series of "NULL" >>> > structure members, in code that antedates or ignores C99's wonderful >>> > feature of designated initializers for aggregate types.[3] How does >>> > malloc(0) get this job done and what benefit does it bring? >>> > >>> > Last time I posted to TUHS I mentioned a proposal for explicit >>> tail-call >>> > elimination in C. I got the syntax wrong. The proposal was "return >>> > goto;". The WG14 document number is N2920 and it's by Alex Gilding. >>> > Good stuff.[4] I hope we see it in C2y. >>> > >>> > Predictably, I must confess that I didn't make much headway on >>> > Schiller's 1975 "secure kernel" paper. Maybe next time. >>> > >>> > Regards, >>> > Branden >>> > >>> > [1] https://web.cs.dal.ca/~jamie/UWO/C/the10fromHenryS.html >>> > >>> > I can easily imagine that the tenet held at _some_ point in the >>> > C's history. It's _got_ to be the reason that the language >>> > relegates memset() and memcpy() to the standard library (or to the >>> > programmer's own devise)! :-O >>> > >>> > [2] Kernighan & Ritchie, _The C Programming Language_, 2nd edition, p. >>> 2 >>> > >>> > Having thus admitted the camel's nose to the tent, K&R would have >>> > done the world a major service by making memset(), or at least >>> > bzero(), a language feature, the latter perhaps by having "= 0" >>> > validly apply to an lvalue of non-primitive type. Okay, >>> > _potentially_ a major service. You'd still need the self-regarding >>> > wizard programmers to bother coding it, which they wouldn't in many >>> > cases "because speed". Move fast, break stuff. >>> > >>> > C++ screwed this up too, and stubbornly stuck by it for a long time. >>> > >>> > https://cplusplus.github.io/CWG/issues/178.html >>> > >>> > [3] https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html >>> > [4] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2920.pdf >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Sep 29 09:38:50 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sun, 29 Sep 2024 09:38:50 +1000 Subject: [TUHS] Fwd: Trove of CSTR's Message-ID: All, I got this e-mail and thought many of you would appreciate the link. Cheers, Warren ----- Forwarded message from Poul-Henning Kamp ----- I stumbled over this: https://www.telecomarchive.com/lettermemo.html is the TUHS crew aware of that resource ? ----- End forwarded message ----- From aki at insinga.com Sun Sep 29 10:49:28 2024 From: aki at insinga.com (Aron Insinga) Date: Sat, 28 Sep 2024 20:49:28 -0400 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> I am sure that shorter shell commands and switches were helpful for *anybody* typing on a clunky, electro-mechanical Teletype (former TM).  They were for me, even though I had learned some typing in school on mechanical typewriters. For the counter-example, I wonder if anyone ever tried to type very much (verbose) DCL on VAX/VMS using a Teletype. :-) - Aron On 9/15/24 16:43, sjenkin at canb.auug.org.au wrote: > ... > For non touch typists, shorter commands & keywords are helpful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aki at insinga.com Sun Sep 29 10:57:05 2024 From: aki at insinga.com (Aron Insinga) Date: Sat, 28 Sep 2024 20:57:05 -0400 Subject: [TUHS] On computerese In-Reply-To: References: Message-ID: <5f53a471-91d8-4e71-ae81-1b6dabcad7e0@insinga.com> p.s. And I did use PDP-11 Unix on an upper-case-only ASR33 by typing backslashes before all upper-case letters to keep them from being mapped to lower case. "Unix means never having to use the shift key." (Except for those annoying all-upper-case macro names in C.) - Aron >> On 16 Sep 2024, at 05:21, Rik Farrow wrote: >> >> Was the brevity typical of Unix command names a function of the tiny >> disk and memory available? Or more a function of having a Teletype 33 >> for input? Of course, it could simply be that 'cat' is more >> convenient than 'catenate'... >> >> Rik -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Sep 29 11:09:20 2024 From: imp at bsdimp.com (Warner Losh) Date: Sat, 28 Sep 2024 19:09:20 -0600 Subject: [TUHS] On computerese In-Reply-To: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Sat, Sep 28, 2024, 6:49 PM Aron Insinga wrote: > I am sure that shorter shell commands and switches were helpful for > *anybody* typing on a clunky, electro-mechanical Teletype (former TM). > They were for me, even though I had learned some typing in school on > mechanical typewriters. > > For the counter-example, I wonder if anyone ever tried to type very much > (verbose) DCL on VAX/VMS using a Teletype. :-) > Not a teletype... but I did on a DECwriter II. It was ok, but not as nice as a crt Warner - Aron > > > On 9/15/24 16:43, sjenkin at canb.auug.org.au wrote: > > ... > For non touch typists, shorter commands & keywords are helpful. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Sep 29 11:30:42 2024 From: robpike at gmail.com (Rob Pike) Date: Sun, 29 Sep 2024 11:30:42 +1000 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: References: Message-ID: I didn't realize Kernighan and Lin was CSTR number 1. Cool. That's an important paper. -rob On Sun, Sep 29, 2024 at 9:38 AM Warren Toomey via TUHS wrote: > All, I got this e-mail and thought many of you would appreciate the link. > > Cheers, Warren > > ----- Forwarded message from Poul-Henning Kamp ----- > > I stumbled over this: > > https://www.telecomarchive.com/lettermemo.html > > is the TUHS crew aware of that resource ? > > ----- End forwarded message ----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Sep 29 12:18:13 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 28 Sep 2024 19:18:13 -0700 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: References: Message-ID: <20240929021813.GN9067@mcvoy.com> It might amuse you, or maybe you don't care, but when I was a grad student I gave my Pascal students the traveling saleman problem. I told them how hard it was (NP-hard) and said if you can find a solution that works in polynomial time, I'll dedicate my life to you to get you a Nobel Prize. I was too green to know about Turing awards. I had a math guy in the class who called me up, land lines, at 3am on a Sunday morning (Saturday night so he was working on this instead of going out to have fun). Screamed at me that he had it. He didn't. Still fun to get the kids thinking. Seems like Kernighan and Lin thought harder. On Sun, Sep 29, 2024 at 11:30:42AM +1000, Rob Pike wrote: > I didn't realize Kernighan and Lin was CSTR number 1. Cool. That's an > important paper. > > -rob > > > On Sun, Sep 29, 2024 at 9:38???AM Warren Toomey via TUHS > wrote: > > > All, I got this e-mail and thought many of you would appreciate the link. > > > > Cheers, Warren > > > > ----- Forwarded message from Poul-Henning Kamp ----- > > > > I stumbled over this: > > > > https://www.telecomarchive.com/lettermemo.html > > > > is the TUHS crew aware of that resource ? > > > > ----- End forwarded message ----- > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Sun Sep 29 12:20:07 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 28 Sep 2024 19:20:07 -0700 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: <20240929021813.GN9067@mcvoy.com> References: <20240929021813.GN9067@mcvoy.com> Message-ID: <20240929022007.GC19968@mcvoy.com> That CSTR number 1 is nicely formatted, is that troff? On Sat, Sep 28, 2024 at 07:18:13PM -0700, Larry McVoy wrote: > It might amuse you, or maybe you don't care, but when I was a grad student > I gave my Pascal students the traveling saleman problem. I told them how > hard it was (NP-hard) and said if you can find a solution that works in > polynomial time, I'll dedicate my life to you to get you a Nobel Prize. > I was too green to know about Turing awards. > > I had a math guy in the class who called me up, land lines, at 3am on a > Sunday morning (Saturday night so he was working on this instead of going > out to have fun). Screamed at me that he had it. He didn't. > > Still fun to get the kids thinking. Seems like Kernighan and Lin thought > harder. > > On Sun, Sep 29, 2024 at 11:30:42AM +1000, Rob Pike wrote: > > I didn't realize Kernighan and Lin was CSTR number 1. Cool. That's an > > important paper. > > > > -rob > > > > > > On Sun, Sep 29, 2024 at 9:38???AM Warren Toomey via TUHS > > wrote: > > > > > All, I got this e-mail and thought many of you would appreciate the link. > > > > > > Cheers, Warren > > > > > > ----- Forwarded message from Poul-Henning Kamp ----- > > > > > > I stumbled over this: > > > > > > https://www.telecomarchive.com/lettermemo.html > > > > > > is the TUHS crew aware of that resource ? > > > > > > ----- End forwarded message ----- > > > > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From g.branden.robinson at gmail.com Sun Sep 29 12:25:11 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 28 Sep 2024 21:25:11 -0500 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: <20240929022007.GC19968@mcvoy.com> References: <20240929021813.GN9067@mcvoy.com> <20240929022007.GC19968@mcvoy.com> Message-ID: <20240929022511.hhm7zew6iroykm7b@illithid> At 2024-09-28T19:20:07-0700, Larry McVoy wrote: > That CSTR number 1 is nicely formatted, is that troff? troff didn't exist yet in 1971. That is proper typesetting, though. I don't know enough to say if it's phototypeset or hot lead (can the naked eye reliably tell, if both techniques are of high quality?). We could take the question to the real typographers on the groff list. roff(7): Third Edition Unix also brought the pipe(2) system call, the explosive growth of a componentized system based around it, and a “filter model” that remains perceptible today. Equally importantly, the Bell Labs site in Murray Hill acquired a Graphic Systems C/A/T phototypesetter, and with it came the necessity of expanding the capabilities of a roff system to cope with a variety of proportionally spaced typefaces at multiple sizes. Ossanna wrote a parallel implementation of nroff for the C/A/T, dubbing it troff (for “typesetter roff”). Unfortunately, surviving documentation does not illustrate what requests were implemented at this time for C/A/T support; the troff(1) man page in Fourth Edition Unix (November 1973) does not feature a request list, unlike nroff(1). Apart from typesetter‐driven features, Unix Version 4 roffs added string definitions (.ds); made the escape character configurable (.ec); and enabled the user to write diagnostics to the standard error stream (.tm). Around 1974, empowered with multiple type sizes, italics, and a symbol font specially commissioned by Bell Labs from Graphic Systems, Kernighan and Lorinda Cherry implemented eqn for typesetting mathematics. In the same year, for Fifth Edition Unix, Ossanna combined and reimplemented the two roffs in C, using that language’s preprocessor to generate both from a single source tree. 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 egbegb2 at gmail.com Sun Sep 29 12:32:44 2024 From: egbegb2 at gmail.com (Ed Bradford) Date: Sat, 28 Sep 2024 21:32:44 -0500 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: References: Message-ID: "Look what they've done to my song, ma" Nokia Bell Labs just doesn't sound right to me and when I visit the site, well, "Look what they've ....". I wonder what happened to the amazing library at Murray Hill. NOkia Bell Labs https://www.bell-labs.com/about/locations/murray-hill-new-jersey-us/ Thank you for some of the CSTR memories. Do you think the entire collection is available somewhere or if NBL still has them? Could we prevail on NBL to release them all to the public? Ed Bradford (BTL 1976-1983) On Sat, Sep 28, 2024 at 6:47 PM Warren Toomey via TUHS wrote: > All, I got this e-mail and thought many of you would appreciate the link. > > Cheers, Warren > > ----- Forwarded message from Poul-Henning Kamp ----- > > I stumbled over this: > > https://www.telecomarchive.com/lettermemo.html > > is the TUHS crew aware of that resource ? > > ----- End forwarded message ----- > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sun Sep 29 12:36:02 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 28 Sep 2024 21:36:02 -0500 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: References: Message-ID: <20240929023602.hb2ioznpnbnnb7hs@illithid> At 2024-09-29T09:38:50+1000, Warren Toomey via TUHS wrote: > All, I got this e-mail and thought many of you would appreciate the link. Oh, man! CSTR #44! "Computer typesetting of technical journals on UNIX" Complete with measurements of costs per page, a subject we'd batted around on the groff list in the past couple of years. $30 a page--in the 1970s. :-O Great stuff. Thanks! Regards, Branden "Why, as a pup, l myself fetched thirty thousand dollars on the black market. And that was in 1954 dollars." -- Leonard Smalls -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gregg.drwho8 at gmail.com Sun Sep 29 14:37:34 2024 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Sun, 29 Sep 2024 00:37:34 -0400 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: <20240929022511.hhm7zew6iroykm7b@illithid> References: <20240929021813.GN9067@mcvoy.com> <20240929022007.GC19968@mcvoy.com> <20240929022511.hhm7zew6iroykm7b@illithid> Message-ID: Hello! I did know someone, twice, My dad and grandfather. For many years the family business was typesetting. First they ran a business based on hotmetal typography. They used the same methods that the Linotype presented. Eventually Dad switched to photo. He ran two shops, based on the L202 machine from the same company as the original one. One year he tells me about having an interesting job, doing the annual report for AT&T, because the one that the company had there, couldn't properly grok the ideas behind it, it wasn't until I got into programming that I figured it out, because the C book was, ah, done locally and that way. Ironically the font the company uses for its logo and much of its work was cut for them, it was called AT&T Gothic. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature was present when the impossible happened 23 years ago, twice." On Sun, Sep 29, 2024 at 12:22 AM G. Branden Robinson wrote: > > At 2024-09-28T19:20:07-0700, Larry McVoy wrote: > > That CSTR number 1 is nicely formatted, is that troff? > > troff didn't exist yet in 1971. > > That is proper typesetting, though. I don't know enough to say if it's > phototypeset or hot lead (can the naked eye reliably tell, if both > techniques are of high quality?). We could take the question to the > real typographers on the groff list. > > roff(7): > Third Edition Unix also brought the pipe(2) system call, the > explosive growth of a componentized system based around it, and a > “filter model” that remains perceptible today. Equally > importantly, the Bell Labs site in Murray Hill acquired a Graphic > Systems C/A/T phototypesetter, and with it came the necessity of > expanding the capabilities of a roff system to cope with a variety > of proportionally spaced typefaces at multiple sizes. Ossanna > wrote a parallel implementation of nroff for the C/A/T, dubbing it > troff (for “typesetter roff”). Unfortunately, surviving > documentation does not illustrate what requests were implemented at > this time for C/A/T support; the troff(1) man page in Fourth > Edition Unix (November 1973) does not feature a request list, > unlike nroff(1). Apart from typesetter‐driven features, Unix > Version 4 roffs added string definitions (.ds); made the escape > character configurable (.ec); and enabled the user to write > diagnostics to the standard error stream (.tm). Around 1974, > empowered with multiple type sizes, italics, and a symbol font > specially commissioned by Bell Labs from Graphic Systems, Kernighan > and Lorinda Cherry implemented eqn for typesetting mathematics. In > the same year, for Fifth Edition Unix, Ossanna combined and > reimplemented the two roffs in C, using that language’s > preprocessor to generate both from a single source tree. > > Regards, > Branden From ralph at inputplus.co.uk Sun Sep 29 20:06:11 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 29 Sep 2024 11:06:11 +0100 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <9049DF63-F7BE-494F-BF7C-6BD0565C0D06@iitbombay.org> Message-ID: <20240929100611.272292033C@orac.inputplus.co.uk> Hi Werner, > > I got two letters back, saying that malloc(0) is illegal because > > zero-length arrays are illegal, and the other vice versa. > > And now we have zero length arrays an UB malloc(0). malloc(0) isn't undefined behaviour but implementation defined. Are there prominent modern implementations which consider it an error so return NULL? -- Cheers, Ralph. From imp at bsdimp.com Sun Sep 29 22:25:49 2024 From: imp at bsdimp.com (Warner Losh) Date: Sun, 29 Sep 2024 06:25:49 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240929100611.272292033C@orac.inputplus.co.uk> References: <20240928165812.4uyturluj4dsuwef@illithid> <9049DF63-F7BE-494F-BF7C-6BD0565C0D06@iitbombay.org> <20240929100611.272292033C@orac.inputplus.co.uk> Message-ID: On Sun, Sep 29, 2024, 4:06 AM Ralph Corderoy wrote: > Hi Werner, > > > > I got two letters back, saying that malloc(0) is illegal because > > > zero-length arrays are illegal, and the other vice versa. > > > > And now we have zero length arrays an UB malloc(0). > > malloc(0) isn't undefined behaviour but implementation defined. > In modern C there is no difference between those two concepts. Are there prominent modern implementations which consider it an error so > return NULL? > Many. There are a dozen or more malloc implementations in use and they all are slightly different. Warner Warner > -- > Cheers, Ralph. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sun Sep 29 22:39:04 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 29 Sep 2024 08:39:04 -0400 Subject: [TUHS] Fwd: Trove of CSTR's Message-ID: > That CSTR number 1 is nicely formatted, is that troff? The archive's CSTR 1 is ersatz. It's a 1973 journal article obtained from JSTOR. I imagine the manuscript was largely copied from the CSTR, but the printed paper certainly differs in meta-content and in layout, say nothing of font. Having gone through the usual route of journal submission and revision, the body text is probably not word-for-word identical to the CSTR either. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Mon Sep 30 00:05:32 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 29 Sep 2024 10:05:32 -0400 Subject: [TUHS] Fwd: Trove of CSTR's Message-ID: > I wonder what happened to the amazing library at Murray Hill. Last I knew, the Bell Labs archives were intact under supervision of a professional archivist. Formally speaking, the archives and the library were distinct entities. The library, which was open to self service 24 hours a day, declined rapidly after the bean counters decreed that it should henceforth support itself on rental fees. Departments immediately turned to buying books rather than borrowing them. It's very likely that this was bad for the Labs' bottom line, but the cost (both monetary and intellectual) was not visible as a budgetary line item. The 24-hour library contributed to one of Ken's programming feats. Spurred by a lunchtime remark that it would be nice to have a unit-conversion program, Ken announced units(1) the next morning. Right from the start, the program knew more than 200 units, thanks to a book Ken grabbed from the library in the middle of the night. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Mon Sep 30 01:17:11 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 29 Sep 2024 16:17:11 +0100 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <9049DF63-F7BE-494F-BF7C-6BD0565C0D06@iitbombay.org> <20240929100611.272292033C@orac.inputplus.co.uk> Message-ID: <20240929151711.2BF7322018@orac.inputplus.co.uk> Hi Werner, > > malloc(0) isn't undefined behaviour but implementation defined. > > In modern C there is no difference between those two concepts. Can you explain more about your view or give a link if it's an accepted opinion. I'm used to an implementation stating its choices from those given by a C standard, e.g. (42) Whether the calloc, malloc, realloc, and aligned_alloc functions return a null pointer or a pointer to an allocated object when the size requested is zero (7.24.3). I'd call malloc(0) and know it's not undefined behaviour but one of those choices. -- Cheers, Ralph. From douglas.mcilroy at dartmouth.edu Mon Sep 30 02:56:07 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 29 Sep 2024 12:56:07 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) Message-ID: >>> malloc(0) isn't undefined behaviour but implementation defined. >> >> In modern C there is no difference between those two concepts. > Can you explain more about your view There certainly is a difference, but in this case the practical implications are the same: avoid malloc(0). malloc(0) lies at the high end of a range of severity of concerns about implementation-definedness. At the low end are things like the size of ints, which only affects applications that may confront very large numbers. In the middle is the default signedness of chars, which generally may be mitigated by explicit type declarations. For the size of ints, C offers guardrails like INT_MAX. There is no test to discern what an error return from malloc(0) means. Is there any other C construct that implementation-definedness renders useless? Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Mon Sep 30 06:29:23 2024 From: robpike at gmail.com (Rob Pike) Date: Mon, 30 Sep 2024 06:29:23 +1000 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: Message-ID: Gradually the writers of optimizing compilers have leaned so hard on the implementation-defined and undefined behaviors that, while far from useless, C and C++ have become non-portable and dangerously insecure, as well as often very surprising to the point that the US government arguing against using them. -rob On Mon, Sep 30, 2024 at 2:56 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > >>> malloc(0) isn't undefined behaviour but implementation defined. > >> > >> In modern C there is no difference between those two concepts. > > > Can you explain more about your view > > There certainly is a difference, but in this case the practical > implications are the same: avoid malloc(0). malloc(0) lies at the high end > of a range of severity of concerns about implementation-definedness. At the > low end are things like the size of ints, which only affects applications > that may confront very large numbers. In the middle is the default > signedness of chars, which generally may be mitigated by explicit type > declarations. > > For the size of ints, C offers guardrails like INT_MAX. There is no test > to discern what an error return from malloc(0) means. > > Is there any other C construct that implementation-definedness renders > useless? > > Doug > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rik at rikfarrow.com Mon Sep 30 07:13:32 2024 From: rik at rikfarrow.com (Rik Farrow) Date: Sun, 29 Sep 2024 14:13:32 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: Message-ID: On Sun, Sep 29, 2024 at 1:29 PM Rob Pike wrote: > Gradually the writers of optimizing compilers have leaned so hard on the > implementation-defined and undefined behaviors that, while far from > useless, C and C++ have become non-portable and dangerously insecure, as > well as often very surprising to the point that the US government arguing > against using them. > >> >> Thank goodness. I loved C when I encountered it, because the alternative was Z80 assembler. I loved having structs, because I was lousy at using offsets (off by one so often you'd think I would just have adjusted for being wrong). I'll take the guardrails, please. C: the assault rifle of programming languages... Rik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Mon Sep 30 07:24:35 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 29 Sep 2024 22:24:35 +0100 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: Message-ID: <20240929212435.6445920340@orac.inputplus.co.uk> Hi Doug, > > > > malloc(0) isn't undefined behaviour but implementation defined. > > > > > > In modern C there is no difference between those two concepts. > > There certainly is a difference, but in this case the practical > implications are the same: avoid malloc(0). Many programs wrap malloc() in some way, even if it's just to exit on failure, so working around malloc(0) is easy enough. void *saneloc(size_t size) { void *p = malloc(size); if (p || size) return p; return malloc(1); } > In the middle is the default signedness of chars, which generally may > be mitigated by explicit type declarations. Similarly, the signedness of an ‘int i: 3’ bit-field. (1) Whether a "plain" int bit-field is treated as a signed int bit-field or as an unsigned int bit-field (6.7.2, 6.7.2.1). > Is there any other C construct that implementation-definedness renders > useless? There's the '-' in "%[3-7]" for fscanf(3). (35) The interpretation of a − character that is neither the first nor the last character, nor the second where a ^ character is the first, in the scanlist for %[ conversion in the fscanf or fwscanf function (7.23.6.2, 7.31.2.1). -- Cheers, Ralph. From rich.salz at gmail.com Mon Sep 30 08:21:23 2024 From: rich.salz at gmail.com (Rich Salz) Date: Sun, 29 Sep 2024 18:21:23 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: Message-ID: > > C and C++ have become non-portable and dangerously insecure, as well as > often very surprising to the point that the US government arguing against > using them. > I thought their main arguments were to use memory-safe languages. Are you saying the C language can be as safe s go, rust, etc., by language design? (I don't think you are, but the sentence I quoted kinda implies that, at least to me.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Mon Sep 30 09:56:47 2024 From: robpike at gmail.com (Rob Pike) Date: Mon, 30 Sep 2024 09:56:47 +1000 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: Message-ID: I'm saying the exact opposite: they are unavoidably unsafe. -rob On Mon, Sep 30, 2024 at 8:21 AM Rich Salz wrote: > C and C++ have become non-portable and dangerously insecure, as well as >> often very surprising to the point that the US government arguing against >> using them. >> > > I thought their main arguments were to use memory-safe languages. Are you > saying the C language can be as safe s go, rust, etc., by language design? > (I don't think you are, but the sentence I quoted kinda implies that, at > least to me.) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Sep 30 10:36:30 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 29 Sep 2024 17:36:30 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: Message-ID: <20240930003630.GE17434@mcvoy.com> It doesn't have to be that way, C could be evolved, I built a very C like language (to the point that one of my engineers, who hated the new language on principle, fixed a bug in some diffs that flew by, he thought he was fixing a bug in C). No pointers, reference counted garbage collection, pass by value or reference, switch values could be anything, values, variables, regular expressions, etc. If I had infinite energy and money, I'd fund a gcc dialect of that C. Alas, I don't. But C is very fixable. On Mon, Sep 30, 2024 at 09:56:47AM +1000, Rob Pike wrote: > I'm saying the exact opposite: they are unavoidably unsafe. > > -rob > > > On Mon, Sep 30, 2024 at 8:21???AM Rich Salz wrote: > > > C and C++ have become non-portable and dangerously insecure, as well as > >> often very surprising to the point that the US government arguing against > >> using them. > >> > > > > I thought their main arguments were to use memory-safe languages. Are you > > saying the C language can be as safe s go, rust, etc., by language design? > > (I don't think you are, but the sentence I quoted kinda implies that, at > > least to me.) > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Mon Sep 30 10:55:13 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 29 Sep 2024 17:55:13 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240930003630.GE17434@mcvoy.com> References: <20240930003630.GE17434@mcvoy.com> Message-ID: <20240930005513.GA17089@mcvoy.com> And one other comment. I've seen all the nay sayers saying this is undefined and that will trip you up, C is full of land mines, etc, etc. I ran a company that developed a product that was orders of magnitude more complex than the v7 kernel (low bar but still) all in C and we had *NONE* of those supposed problems. We were careful to use stuff that worked, I'm "famous" in that company as the guy was viewed as "that was invented after 1980 so Larry won't let us use it". Not true, we used mmap and used POSIX signals, but mostly true. If you stick to the basics, C just works. And is portable, we supported every Unix (even SCO), MacOS, Windows, and all the Linux variants from ARM to IBM mainframes. It was fine. We did ship our own libc, NetBSD's because it had fpush() and we used that to do compression and CRC checking and it got around other crappy libc implementations. If you want to go out of your way to find places where it doesn't, umm, go you I guess, but why go there? I have an existence proof that you can use C sensibly and it is fine. The company made it to 18 years before the open source guys shut us down, not a bad run. All that said, I get it, you want guard rails. You are not wrong, the caliber of programmers these days are nowhere near Bell Labs or Sun or my guys. I'm not sure what I'd do if I were starting over, I'd lean towards C but would take a hard look at Rust. On Sun, Sep 29, 2024 at 05:36:30PM -0700, Larry McVoy wrote: > It doesn't have to be that way, C could be evolved, I built a very C > like language (to the point that one of my engineers, who hated the > new language on principle, fixed a bug in some diffs that flew by, > he thought he was fixing a bug in C). No pointers, reference counted > garbage collection, pass by value or reference, switch values could be > anything, values, variables, regular expressions, etc. > > If I had infinite energy and money, I'd fund a gcc dialect of that C. > Alas, I don't. But C is very fixable. > > On Mon, Sep 30, 2024 at 09:56:47AM +1000, Rob Pike wrote: > > I'm saying the exact opposite: they are unavoidably unsafe. > > > > -rob > > > > > > On Mon, Sep 30, 2024 at 8:21???AM Rich Salz wrote: > > > > > C and C++ have become non-portable and dangerously insecure, as well as > > >> often very surprising to the point that the US government arguing against > > >> using them. > > >> > > > > > > I thought their main arguments were to use memory-safe languages. Are you > > > saying the C language can be as safe s go, rust, etc., by language design? > > > (I don't think you are, but the sentence I quoted kinda implies that, at > > > least to me.) > > > > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From rsc at swtch.com Mon Sep 30 11:01:28 2024 From: rsc at swtch.com (Russ Cox) Date: Sun, 29 Sep 2024 21:01:28 -0400 Subject: [TUHS] On computerese In-Reply-To: <202409170554.48H5sduP148200@freefriends.org> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> <202409170554.48H5sduP148200@freefriends.org> Message-ID: On Tue, Sep 17, 2024 at 1:55 AM wrote: > I think it was only Plan 9. The change was motivated by the > rc shell, which treated x=y anywhere on the command line (not just > at the beginning of a command) as a variable assignment. > I'm a little late to the thread, but this is not quite true. rc's lexer and grammar treated = as a special symbol - just like ( or | or & or ; - and so it couldn't be used as a literal except when quoted. That is, "foo x=y" was a syntax error, not an equivalent to "x=y foo". One of the tidyings I did during covid lockdown was to rewrite rc's parser not to use yacc anymore [1], specifically to make it easy to allow "foo x=y". As I wrote in the commit message, dd fans rejoice! (Also fans of -foo=bar flag syntax.) Best, Russ [1] https://groups.google.com/g/plan9port-dev/c/AS8acHti7eo/m/0tZF7h7FBQAJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther.johnson at makerlisp.com Mon Sep 30 11:09:56 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Sun, 29 Sep 2024 18:09:56 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240930003630.GE17434@mcvoy.com> References: <20240930003630.GE17434@mcvoy.com> Message-ID: C# addresses some of the things being discussed here. I've used it, I don't care for it all that much, I prefer straight, not-at-all modern C, but I think there are probably a few dialects over the years (Objective C ?) that have addressed some of these desires for a "better C, but not C++". Do others here have comments on these inspired by C, kind of C-like, but with a few other computer science components, thrown into the language machine ? On 09/29/2024 05:36 PM, Larry McVoy wrote: > It doesn't have to be that way, C could be evolved, I built a very C > like language (to the point that one of my engineers, who hated the > new language on principle, fixed a bug in some diffs that flew by, > he thought he was fixing a bug in C). No pointers, reference counted > garbage collection, pass by value or reference, switch values could be > anything, values, variables, regular expressions, etc. > > If I had infinite energy and money, I'd fund a gcc dialect of that C. > Alas, I don't. But C is very fixable. > > On Mon, Sep 30, 2024 at 09:56:47AM +1000, Rob Pike wrote: >> I'm saying the exact opposite: they are unavoidably unsafe. >> >> -rob >> >> >> On Mon, Sep 30, 2024 at 8:21???AM Rich Salz wrote: >> >>> C and C++ have become non-portable and dangerously insecure, as well as >>>> often very surprising to the point that the US government arguing against >>>> using them. >>>> >>> I thought their main arguments were to use memory-safe languages. Are you >>> saying the C language can be as safe s go, rust, etc., by language design? >>> (I don't think you are, but the sentence I quoted kinda implies that, at >>> least to me.) >>> From egbegb2 at gmail.com Mon Sep 30 11:22:36 2024 From: egbegb2 at gmail.com (Ed Bradford) Date: Sun, 29 Sep 2024 20:22:36 -0500 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: References: Message-ID: Who is/was the professional archivist and where is/was the collection last seen? Do you have any ideas? Ed On Sun, Sep 29, 2024 at 9:12 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > I wonder what happened to the amazing library at Murray Hill. > > Last I knew, the Bell Labs archives were intact under supervision of a > professional archivist. Formally speaking, the archives and the library > were distinct entities. The library, which was open to self service 24 > hours a day, declined rapidly after the bean counters decreed that it > should henceforth support itself on rental fees. Departments immediately > turned to buying books rather than borrowing them. It's very likely that > this was bad for the Labs' bottom line, but the cost (both monetary and > intellectual) was not visible as a budgetary line item. > > The 24-hour library contributed to one of Ken's programming feats. Spurred > by a lunchtime remark that it would be nice to have a unit-conversion > program, Ken announced units(1) the next morning. Right from the start, the > program knew more than 200 units, thanks to a book Ken grabbed from the > library in the middle of the night. > > Doug > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther.johnson at makerlisp.com Mon Sep 30 11:37:10 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Sun, 29 Sep 2024 18:37:10 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930003630.GE17434@mcvoy.com> Message-ID: 'Go' is also a pretty C-like advanced C kind of thing. What do Go writers think of it vs. C, for safety, reliability, clarity of expression, etc. ? On 09/29/2024 06:09 PM, Luther Johnson wrote: > C# addresses some of the things being discussed here. I've used it, I > don't care for it all that much, I prefer straight, not-at-all modern > C, but I think there are probably a few dialects over the years > (Objective C ?) that have addressed some of these desires for a > "better C, but not C++". Do others here have comments on these > inspired by C, kind of C-like, but with a few other computer science > components, thrown into the language machine ? > > On 09/29/2024 05:36 PM, Larry McVoy wrote: >> It doesn't have to be that way, C could be evolved, I built a very C >> like language (to the point that one of my engineers, who hated the >> new language on principle, fixed a bug in some diffs that flew by, >> he thought he was fixing a bug in C). No pointers, reference counted >> garbage collection, pass by value or reference, switch values could be >> anything, values, variables, regular expressions, etc. >> >> If I had infinite energy and money, I'd fund a gcc dialect of that C. >> Alas, I don't. But C is very fixable. >> >> On Mon, Sep 30, 2024 at 09:56:47AM +1000, Rob Pike wrote: >>> I'm saying the exact opposite: they are unavoidably unsafe. >>> >>> -rob >>> >>> >>> On Mon, Sep 30, 2024 at 8:21???AM Rich Salz >>> wrote: >>> >>>> C and C++ have become non-portable and dangerously insecure, as >>>> well as >>>>> often very surprising to the point that the US government arguing >>>>> against >>>>> using them. >>>>> >>>> I thought their main arguments were to use memory-safe languages. >>>> Are you >>>> saying the C language can be as safe s go, rust, etc., by language >>>> design? >>>> (I don't think you are, but the sentence I quoted kinda implies >>>> that, at >>>> least to me.) >>>> > From rminnich at gmail.com Mon Sep 30 13:52:23 2024 From: rminnich at gmail.com (ron minnich) Date: Sun, 29 Sep 2024 20:52:23 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930003630.GE17434@mcvoy.com> Message-ID: Data point. I hope this is not too far out of TUHS scope, but ... you asked. In 2010, we at sandia journeyed to Usenix to take Russ's course on Go. At that time, we had created megatux, all written in C, all based on earlier HPC work at LANL, that allowed us to run 80,000 or so Windows VMs on a 400 node cluster, and from there run real malware to study it (and, in one case, fix a bug :-). We got done Russ's course, and on the way home, I said "we're moving it all to Go." Nobody disagreed. We never once regretted that decision. On Sun, Sep 29, 2024 at 6:47 PM Luther Johnson wrote: > 'Go' is also a pretty C-like advanced C kind of thing. What do Go > writers think of it vs. C, for safety, reliability, clarity of > expression, etc. ? > > On 09/29/2024 06:09 PM, Luther Johnson wrote: > > C# addresses some of the things being discussed here. I've used it, I > > don't care for it all that much, I prefer straight, not-at-all modern > > C, but I think there are probably a few dialects over the years > > (Objective C ?) that have addressed some of these desires for a > > "better C, but not C++". Do others here have comments on these > > inspired by C, kind of C-like, but with a few other computer science > > components, thrown into the language machine ? > > > > On 09/29/2024 05:36 PM, Larry McVoy wrote: > >> It doesn't have to be that way, C could be evolved, I built a very C > >> like language (to the point that one of my engineers, who hated the > >> new language on principle, fixed a bug in some diffs that flew by, > >> he thought he was fixing a bug in C). No pointers, reference counted > >> garbage collection, pass by value or reference, switch values could be > >> anything, values, variables, regular expressions, etc. > >> > >> If I had infinite energy and money, I'd fund a gcc dialect of that C. > >> Alas, I don't. But C is very fixable. > >> > >> On Mon, Sep 30, 2024 at 09:56:47AM +1000, Rob Pike wrote: > >>> I'm saying the exact opposite: they are unavoidably unsafe. > >>> > >>> -rob > >>> > >>> > >>> On Mon, Sep 30, 2024 at 8:21???AM Rich Salz > >>> wrote: > >>> > >>>> C and C++ have become non-portable and dangerously insecure, as > >>>> well as > >>>>> often very surprising to the point that the US government arguing > >>>>> against > >>>>> using them. > >>>>> > >>>> I thought their main arguments were to use memory-safe languages. > >>>> Are you > >>>> saying the C language can be as safe s go, rust, etc., by language > >>>> design? > >>>> (I don't think you are, but the sentence I quoted kinda implies > >>>> that, at > >>>> least to me.) > >>>> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Sep 30 18:16:56 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 30 Sep 2024 02:16:56 -0600 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> <202409170554.48H5sduP148200@freefriends.org> Message-ID: <202409300816.48U8GuKj303510@freefriends.org> Russ Cox wrote: > I'm a little late to the thread, but this is not quite true. > rc's lexer and grammar treated = as a special > symbol - just like ( or | or & or ; - and so it couldn't > be used as a literal except when quoted. > That is, "foo x=y" was a syntax error, not an equivalent to "x=y foo". OK, distinction noted. It was a long time ago. > One of the tidyings I did during covid lockdown was to rewrite > rc's parser not to use yacc anymore [1], specifically to make > it easy to allow "foo x=y". As I wrote in the commit message, > dd fans rejoice! (Also fans of -foo=bar flag syntax.) Very cool. Have other Plan 9 distros picked this up? Just wondering. Thanks, Arnold From douglas.mcilroy at dartmouth.edu Mon Sep 30 21:52:57 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 30 Sep 2024 07:52:57 -0400 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: References: Message-ID: The Bell Labs archivist, Ed Eckert, ed.eckert at nokia-bell-labs.com, played a big role in the Labs' Unix50 celebration in 2019. The archives had not only documents, but also memorabilia from the Unix Room. I obtained a 1970s TM from him more recently, probably 2022. An important organizer of Unix50 was martin.carroll at nokia-bell-labs.com. He also was the inside lead on the release of post-v7 Unix source. Doug On Sun, Sep 29, 2024 at 9:23 PM Ed Bradford wrote: > Who is/was the professional archivist and where is/was the collection last > seen? > Do you have any ideas? > > Ed > > > On Sun, Sep 29, 2024 at 9:12 AM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> > I wonder what happened to the amazing library at Murray Hill. >> >> Last I knew, the Bell Labs archives were intact under supervision of a >> professional archivist. Formally speaking, the archives and the library >> were distinct entities. The library, which was open to self service 24 >> hours a day, declined rapidly after the bean counters decreed that it >> should henceforth support itself on rental fees. Departments immediately >> turned to buying books rather than borrowing them. It's very likely that >> this was bad for the Labs' bottom line, but the cost (both monetary and >> intellectual) was not visible as a budgetary line item. >> >> The 24-hour library contributed to one of Ken's programming feats. >> Spurred by a lunchtime remark that it would be nice to have a >> unit-conversion program, Ken announced units(1) the next morning. Right >> from the start, the program knew more than 200 units, thanks to a book Ken >> grabbed from the library in the middle of the night. >> >> Doug >> > > > -- > Advice is judged by results, not by intentions. > Cicero > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsc at swtch.com Mon Sep 30 22:10:22 2024 From: rsc at swtch.com (Russ Cox) Date: Mon, 30 Sep 2024 08:10:22 -0400 Subject: [TUHS] On computerese In-Reply-To: <202409300816.48U8GuKj303510@freefriends.org> References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> <202409170554.48H5sduP148200@freefriends.org> <202409300816.48U8GuKj303510@freefriends.org> Message-ID: On Mon, Sep 30, 2024 at 4:17 AM wrote: > > One of the tidyings I did during covid lockdown was to rewrite > > rc's parser not to use yacc anymore [1], specifically to make > > it easy to allow "foo x=y". As I wrote in the commit message, > > dd fans rejoice! (Also fans of -foo=bar flag syntax.) > > Very cool. Have other Plan 9 distros picked this up? Just wondering. I looked at https://9p.io/plan9/ and also 9front and neither has the change. I don't think either is particularly maintained at this point. (I made the change in the Unix port of the tools, https://9fans.github.io/plan9port/.) Best, Russ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Mon Sep 30 22:15:03 2024 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Sep 2024 08:15:03 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <9049DF63-F7BE-494F-BF7C-6BD0565C0D06@iitbombay.org> Message-ID: On Sat, Sep 28, 2024 at 7:37 PM Warner Losh wrote: > On Sat, Sep 28, 2024, 5:05 PM Rob Pike wrote: >> I wrote a letter to the ANSI C (1989) committee. >> >> Please allow malloc(0). >> Please allow zero-length arrays. >> >> I got two letters back, saying that malloc(0) is illegal because zero-length arrays are illegal, and the other vice versa. >> >> I fumed. > > And now we have zero length arrays an UB malloc(0). I'm late to this; I know. But I wonder if perhaps you meant realloc(0, p) being made UB in C23? This caused something of a kerfuffle, perhaps exemplified by an incredibly poorly written "article" in ACM Queue. I asked Jean-Heyd Meneide why this was done, and he broke it down for me (the gist of it being, "it was the least-bad of a bunch of bad options..."). The take from the C standards committee was actually very reasonable, given the constraints they are forced to live under nowadays, even if some of the rank and file were infuriated. But I think the overall situation is illustrative of the sort of dynamic Rob alluded to. The motivations of C compiler writers and programmers have diverged; a great frustration for me is that, despite its origins as a language meant to support systems programming and operation systems implementation, compiler writers these days seem almost antagonistic to that use. Linux, for instance, is not written in "C" so much as "Linux C", which is a dialect of the language selected by selectively setting compiler flags until some set of reasonable presets tames it enough to be useful. - Dan C.