From jnc at mercury.lcs.mit.edu Mon Aug 1 05:57:02 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 31 Jul 2022 15:57:02 -0400 (EDT) Subject: [TUHS] LSX issues and musing Message-ID: <20220731195702.ACC4218C0C1@mercury.lcs.mit.edu> {I was going to reply to an earlier message, but my CFS left me with insufficient energy; I'll try and catch up on the points I was goibf to make here.} > From: Gavin Tersteeg > This leaves me with about 1.9kb of space left in the kernel for > additional drivers I'm curious how much memory you have in your target system; it must not be a lot, if you're targeting LSX. I ask because LSX has been somewhat 'lobotimized' (I don't mean that in a negative way; it's just recognition that LSX has had a lot of corners trimmed, to squeeze it down as much as possible), and some of those trims behind some of the issues you're having (below). At the time the LSI-11 came out, semiconductor DRAM was just getting started, so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11 core memory cards :-), to produce the 40KB target for LSX systems, was then a reasonable configuration. These days, one has to really search to find anything smaller than 64KB... It might be easier to just run MINI-UNIX (which is much closer to V6, and thus a known quantity), than add a lot of things back in to LSX to produce what will effectively be MINI-UNIX; even if you have to buy a bit more QBUS memory for the machine. > the LSX "mkfs" was hardcoded to create filesystems with 6 blocks of > inodes. This maxed the number of files on a disk to 96, but even with > the maximum circumvented LSX would only tolerate a maximum of 101 files. And here you're seeing the 'lobotomizing' of LSX come into play. That '101' made me suspicious, as the base V6 'caches' 100 free inodes in the super-block; once those are used, it scans the ilist on disk to refill it. The code in alloc$ialloc in LSX is hard to understand (there are a lot of #ifdef's), and it's very different from the V6 code, but I'm pretty sure it doesn't refill the 'cache' after it uses the cached 100 free inodes. So, you can have as many free inodes on a disk as you want, but LSX will never use more than the first 100. (Note that the comment in the LSX source "up to 100 spare I nodes in the super block. When this runs out, a linear search through the I list is instituted to pick up 100 more." is inaccurate; it probably wasn't updated after the code was changed. ISTR tis is true of a lot of the comments.) Use MINI-UNIX. > A fresh filesystem that was mkfs'd on stock V6 can be mounted on LSX, > but any attempt to create files on it will fail. The V6 'mkfs' does not fill the free inode cache in the super-block. So, it's empty when you start out. The LSX ialloc() says: if(fp->s_ninode > 0) { ... } u.u_error = ENOSPC; return(NULL); which would produce what you're seeing. Also, another problem with trying to 'push' LSX into a previously un-handled operating regions (e.g. large disks, but there are likely others) is that there are probably things that are un-tested in that previously unused operating mode, and there may be un-found bugs that you trip across. Use MINI-UNIX. > Interestingly enough, existing large V6 RK05 images can be mounted, > read from, and written to. The only limitations on these pre existing > images is that if enough files are deleted, the system will randomly crash. I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and alloc.c), but I couldn't quickly find the cause; it isn't obvious. (When unlinking a file, the blocks in the file have to be freed - that's inode 'ip' - and the directory - inode 'pp' - has to be updated; so it's pretty complicated.) Use MINI-UNIX. > The information there about continuous files ... will be extremely > helpful if I ever try to make those work in the future. My recollection is that the LSX kernel doesn't have code to create contiguous files; the LSX page at the CHWiki says "the paper describing LSX indicates there were two separate programs, one to allocate space for such files, and one to move a file into such an area, but they do not seem to be extant". If you find them, could you let me know? Thanks. Noel From heinz at osta.com Mon Aug 1 15:37:35 2022 From: heinz at osta.com (Heinz Lycklama) Date: Sun, 31 Jul 2022 22:37:35 -0700 Subject: [TUHS] LSX issues and musing In-Reply-To: <20220731195702.ACC4218C0C1@mercury.lcs.mit.edu> References: <20220731195702.ACC4218C0C1@mercury.lcs.mit.edu> Message-ID: Remember that the LSX and Mini-UNIX systems were developed for two different purposes.     1. LSX had limited resources available to it and thus         some general-purpose features had to be removed.         LSX supported some new features for the support         of real-time systems and intelligent terminals. The         features included contiguous files and asynchronous         read/write capabilities.     2. Mini-UNIX was developed to run on PDP11/10 computers         without memory management support at the hardware level.         Larger main memory and faster larger disks were available.         It was designed to support up to four users at a time, and         thus needed to support the latest UNIX System features         without the additional features available on LSX. To answer the question below about kernel code to create contiguous - the only change in the kernel code was to recognize a contiguous file in the inode. The actual file had to be created by a system program to keep the kernel as small as possible. Heinz On 7/31/2022 12:57 PM, Noel Chiappa wrote: > {I was going to reply to an earlier message, but my CFS left me with > insufficient energy; I'll try and catch up on the points I was goibf to make > here.} > > > From: Gavin Tersteeg > > > This leaves me with about 1.9kb of space left in the kernel for > > additional drivers > > I'm curious how much memory you have in your target system; it must not be a > lot, if you're targeting LSX. > > I ask because LSX has been somewhat 'lobotimized' (I don't mean that in a > negative way; it's just recognition that LSX has had a lot of corners > trimmed, to squeeze it down as much as possible), and some of those trims > behind some of the issues you're having (below). > > At the time the LSI-11 came out, semiconductor DRAM was just getting started, > so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11 core > memory cards :-), to produce the 40KB target for LSX systems, was then a > reasonable configuration. These days, one has to really search to find > anything smaller than 64KB... > > It might be easier to just run MINI-UNIX (which is much closer to V6, and > thus a known quantity), than add a lot of things back in to LSX to produce > what will effectively be MINI-UNIX; even if you have to buy a bit more QBUS > memory for the machine. > > > > the LSX "mkfs" was hardcoded to create filesystems with 6 blocks of > > inodes. This maxed the number of files on a disk to 96, but even with > > the maximum circumvented LSX would only tolerate a maximum of 101 files. > > And here you're seeing the 'lobotomizing' of LSX come into play. That '101' > made me suspicious, as the base V6 'caches' 100 free inodes in the > super-block; once those are used, it scans the ilist on disk to refill it. > > The code in alloc$ialloc in LSX is hard to understand (there are a lot of > #ifdef's), and it's very different from the V6 code, but I'm pretty sure it > doesn't refill the 'cache' after it uses the cached 100 free inodes. So, you > can have as many free inodes on a disk as you want, but LSX will never use > more than the first 100. > > (Note that the comment in the LSX source "up to 100 spare I nodes in the > super block. When this runs out, a linear search through the I list is > instituted to pick up 100 more." is inaccurate; it probably wasn't updated > after the code was changed. ISTR tis is true of a lot of the comments.) > > Use MINI-UNIX. > > > A fresh filesystem that was mkfs'd on stock V6 can be mounted on LSX, > > but any attempt to create files on it will fail. > > The V6 'mkfs' does not fill the free inode cache in the super-block. So, it's > empty when you start out. The LSX ialloc() says: > > if(fp->s_ninode > 0) { > ... > } > u.u_error = ENOSPC; > return(NULL); > > which would produce what you're seeing. > > Also, another problem with trying to 'push' LSX into a previously un-handled > operating regions (e.g. large disks, but there are likely others) is that > there are probably things that are un-tested in that previously unused > operating mode, and there may be un-found bugs that you trip across. > > Use MINI-UNIX. > > > Interestingly enough, existing large V6 RK05 images can be mounted, > > read from, and written to. The only limitations on these pre existing > > images is that if enough files are deleted, the system will randomly crash. > > I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and alloc.c), > but I couldn't quickly find the cause; it isn't obvious. (When unlinking a > file, the blocks in the file have to be freed - that's inode 'ip' - and the > directory - inode 'pp' - has to be updated; so it's pretty complicated.) > > Use MINI-UNIX. > > > > The information there about continuous files ... will be extremely > > helpful if I ever try to make those work in the future. > > My recollection is that the LSX kernel doesn't have code to create contiguous > files; the LSX page at the CHWiki says "the paper describing LSX indicates > there were two separate programs, one to allocate space for such files, and > one to move a file into such an area, but they do not seem to be extant". If > you find them, could you let me know? Thanks. > > Noel From gctersteeg at gmail.com Wed Aug 3 03:56:18 2022 From: gctersteeg at gmail.com (Gavin Tersteeg) Date: Tue, 2 Aug 2022 12:56:18 -0500 Subject: [TUHS] LSX issues and musing In-Reply-To: References: <20220731195702.ACC4218C0C1@mercury.lcs.mit.edu> Message-ID: I was heavily considering using Mini-UNIX for this project, but picked LSX for a few reasons. The biggest reason is that Mini-UNIX has features that I don't really need, and I figured it would be easier to add what I wanted to LSX than remove what I didn't from Mini-UNIX. My target system (A Heathkit H11) does have the full 56K of memory, but I would like to get as much user space as possible. It will also be running on the equivalent of a RX02 disk system, not a high speed spinning disk that Mini-UNIX seems to expect. Regardless, if LSX proves to be too much of a hassle, I will probably just switch to Mini-UNIX. The inode allocation stuff seems to be what is causing the issues. When I mount the filesystem on stock V6, create a file, and then remount it on LSX, it (seems) to work again. Hopefully this code isn't too hard to add back, but if need be I can live with the 100 file limit. Unless I decide to try to get a hard drive hooked up, of course. Right now I am working on getting the hardware up and running again. I am hoping to bring all of this to VCFMW to show off, but since I have to go back to college in a few weeks I have a lot of work ahead of me. Thank you for the help, Gavin On Mon, Aug 1, 2022 at 12:37 AM Heinz Lycklama wrote: > Remember that the LSX and Mini-UNIX systems were > developed for two different purposes. > 1. LSX had limited resources available to it and thus > some general-purpose features had to be removed. > LSX supported some new features for the support > of real-time systems and intelligent terminals. The > features included contiguous files and asynchronous > read/write capabilities. > 2. Mini-UNIX was developed to run on PDP11/10 computers > without memory management support at the hardware level. > Larger main memory and faster larger disks were available. > It was designed to support up to four users at a time, and > thus needed to support the latest UNIX System features > without the additional features available on LSX. > > To answer the question below about kernel code to create > contiguous - the only change in the kernel code was to > recognize a contiguous file in the inode. The actual file > had to be created by a system program to keep the > kernel as small as possible. > > Heinz > > On 7/31/2022 12:57 PM, Noel Chiappa wrote: > > {I was going to reply to an earlier message, but my CFS left me with > > insufficient energy; I'll try and catch up on the points I was goibf to > make > > here.} > > > > > From: Gavin Tersteeg > > > > > This leaves me with about 1.9kb of space left in the kernel for > > > additional drivers > > > > I'm curious how much memory you have in your target system; it must not > be a > > lot, if you're targeting LSX. > > > > I ask because LSX has been somewhat 'lobotimized' (I don't mean that in a > > negative way; it's just recognition that LSX has had a lot of corners > > trimmed, to squeeze it down as much as possible), and some of those trims > > behind some of the issues you're having (below). > > > > At the time the LSI-11 came out, semiconductor DRAM was just getting > started, > > so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11 > core > > memory cards :-), to produce the 40KB target for LSX systems, was then a > > reasonable configuration. These days, one has to really search to find > > anything smaller than 64KB... > > > > It might be easier to just run MINI-UNIX (which is much closer to V6, and > > thus a known quantity), than add a lot of things back in to LSX to > produce > > what will effectively be MINI-UNIX; even if you have to buy a bit more > QBUS > > memory for the machine. > > > > > > > the LSX "mkfs" was hardcoded to create filesystems with 6 blocks > of > > > inodes. This maxed the number of files on a disk to 96, but even > with > > > the maximum circumvented LSX would only tolerate a maximum of 101 > files. > > > > And here you're seeing the 'lobotomizing' of LSX come into play. That > '101' > > made me suspicious, as the base V6 'caches' 100 free inodes in the > > super-block; once those are used, it scans the ilist on disk to refill > it. > > > > The code in alloc$ialloc in LSX is hard to understand (there are a lot of > > #ifdef's), and it's very different from the V6 code, but I'm pretty sure > it > > doesn't refill the 'cache' after it uses the cached 100 free inodes. So, > you > > can have as many free inodes on a disk as you want, but LSX will never > use > > more than the first 100. > > > > (Note that the comment in the LSX source "up to 100 spare I nodes in the > > super block. When this runs out, a linear search through the I list is > > instituted to pick up 100 more." is inaccurate; it probably wasn't > updated > > after the code was changed. ISTR tis is true of a lot of the comments.) > > > > Use MINI-UNIX. > > > > > A fresh filesystem that was mkfs'd on stock V6 can be mounted on > LSX, > > > but any attempt to create files on it will fail. > > > > The V6 'mkfs' does not fill the free inode cache in the super-block. So, > it's > > empty when you start out. The LSX ialloc() says: > > > > if(fp->s_ninode > 0) { > > ... > > } > > u.u_error = ENOSPC; > > return(NULL); > > > > which would produce what you're seeing. > > > > Also, another problem with trying to 'push' LSX into a previously > un-handled > > operating regions (e.g. large disks, but there are likely others) is that > > there are probably things that are un-tested in that previously unused > > operating mode, and there may be un-found bugs that you trip across. > > > > Use MINI-UNIX. > > > > > Interestingly enough, existing large V6 RK05 images can be > mounted, > > > read from, and written to. The only limitations on these pre > existing > > > images is that if enough files are deleted, the system will > randomly crash. > > > > I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and > alloc.c), > > but I couldn't quickly find the cause; it isn't obvious. (When unlinking > a > > file, the blocks in the file have to be freed - that's inode 'ip' - and > the > > directory - inode 'pp' - has to be updated; so it's pretty complicated.) > > > > Use MINI-UNIX. > > > > > > > The information there about continuous files ... will be extremely > > > helpful if I ever try to make those work in the future. > > > > My recollection is that the LSX kernel doesn't have code to create > contiguous > > files; the LSX page at the CHWiki says "the paper describing LSX > indicates > > there were two separate programs, one to allocate space for such files, > and > > one to move a file into such an area, but they do not seem to be > extant". If > > you find them, could you let me know? Thanks. > > > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at osta.com Wed Aug 3 10:07:25 2022 From: heinz at osta.com (Heinz Lycklama) Date: Tue, 2 Aug 2022 17:07:25 -0700 Subject: [TUHS] Documentation on MERT added to TUHS Message-ID: <8aa97449-2f8d-fb4e-6c72-1bfcd11a6a67@osta.com> The MERT (Multi-Environment Real-Time) system was developed at Bell Telephone Laboratories in Murray Hill, NJ by myself and Doug Bayer in the mid 1970's on a DEC PDP 11/45 computer. MERT was picked up by the UNIX Support Group (USG) in 1977 and has been distributed and supported throughout the Bell System. The MERT Manual consists of both the MERT Programmer's Manual and the UNIX Programmer's Manual. You can find all of this documentation at:     1. https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/ The hosting of this manual online was made possible by Clem Cole's painstaking efforts to scan in and organize the hundreds of pages in the hard copy MERT Manual. Clem had previously scanned in my Technical Memoranda documenting my work at Bell Labs in the 1970's on MERT, LSX, Mini-UNIX and the Mini-Computer Satellite Processor System:     2. https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/ The monthly UNIX Technology Advisor newsletter published in 1989 and 1990 contains articles written by some of the leading open systems industry pioneers. The first issue is available online here:     3. https://www.tuhs.org/Archive/Documentation/Unix_Advisor/ I want to thank Warren Toomey for providing and maintaining the TUHS.org platform for the hosting of this historical information on UNIX systems for the community. Heinz Lycklama -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Aug 3 10:14:23 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 2 Aug 2022 17:14:23 -0700 Subject: [TUHS] Documentation on MERT added to TUHS In-Reply-To: <8aa97449-2f8d-fb4e-6c72-1bfcd11a6a67@osta.com> References: <8aa97449-2f8d-fb4e-6c72-1bfcd11a6a67@osta.com> Message-ID: <20220803001423.GE20034@mcvoy.com> Was MERT anything like Victor Yodaiken's RT linux? He did a real time kernel that ran all of Unix as the idle process in the real time kernel. It was pretty slick, unfortunately Wind River bought it and killed it so it wasn't competition to their less well thought out system. Victor's paper is here http://mcvoy.com/lm/papers/rtlmanifesto.pdf On Tue, Aug 02, 2022 at 05:07:25PM -0700, Heinz Lycklama wrote: > The MERT (Multi-Environment Real-Time) system was developed > at Bell Telephone Laboratories in Murray Hill, NJ by myself and > Doug Bayer in the mid 1970's on a DEC PDP 11/45 computer. > MERT was picked up by the UNIX Support Group (USG) in 1977 and > has been distributed and supported throughout the Bell System. > The MERT Manual consists of both the MERT Programmer's > Manual and the UNIX Programmer's Manual. You can find > all of this documentation at: > ?????? 1. https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/ > The hosting of this manual online was made possible by Clem Cole's > painstaking efforts to scan in and organize the hundreds of pages > in the hard copy MERT Manual. Clem had previously scanned in > my Technical Memoranda documenting my work at Bell Labs in > the 1970's on MERT, LSX, Mini-UNIX and the Mini-Computer > Satellite Processor System: > ?????? 2. > https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/ > The monthly UNIX Technology Advisor newsletter published > in 1989 and 1990 contains articles written by some of the leading > open systems industry pioneers. The first issue is available online here: > ?????? 3. https://www.tuhs.org/Archive/Documentation/Unix_Advisor/ > I want to thank Warren Toomey for providing and maintaining > the TUHS.org platform for the hosting of this > historical information > on UNIX systems for the community. > > Heinz Lycklama -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From sjenkin at canb.auug.org.au Wed Aug 3 14:32:10 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Wed, 3 Aug 2022 14:32:10 +1000 Subject: [TUHS] LSX issues and musing In-Reply-To: References: <20220731195702.ACC4218C0C1@mercury.lcs.mit.edu> Message-ID: <496D2B07-8C23-4D2F-ABA7-132E8E2106C6@canb.auug.org.au> > On 3 Aug 2022, at 03:56, Gavin Tersteeg wrote: > > My target system (A Heathkit H11) does have the full 56K of memory, I wasn’t aware of the Heathkit H11 in 1980. Did work with someone circa 1984 that owned a DEC device, a VT71 or VT72, that had an LSI-11 + Q-Bus inside. The H11 wasn’t that differently priced to the IBM PC 3 years later, at least for an entry system. Any ideas on why businesses didn’t pick up the H11 in 1980? [priced too high for hobbyists] Possibly: Marketing, ’support’, form-factor/physical size, peripherals - no display / keyboard on H11, serial terminal - or ’software’ availability? Price didn’t win the market. IBM’s 5150 was never “cheapest” or technically “best” at any time - hence rapid rise of (variable quality) clones, built down to a price. Gates, Allen & Ballmer understood business users wanted “Off the Shelf Software" from Independent Software Vendors (ISV’s). For ISV's to target/support MS-DOS 1.0, Microsoft provided a mechanical translation tool to convert from CP/M executable to MS-DOS. Wikipedia says: 1978: H11 US$1295 (kit) or US$1595 fully assembled ("4kword base system”) display advert $1295 kit + postage/freight, bare system, 8KB (4kword), 6 Q-bus slots free. ROM ? 1981: IBM 5150(PC) US$1,565 for "16 KB RAM, Color Graphics Adapter, and no disk drives.” ( I only saw 5150’s with 2x 5.25” 360KB floppies included - otherwise, can’t run programs & store files) ( we had someone buy an almost clone with 2x 8” floppies, @ 1.2MB each to run a database they had, 320/360K didn’t cut it ) -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From ron at ronnatalie.com Wed Aug 3 14:55:22 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 03 Aug 2022 04:55:22 +0000 Subject: [TUHS] LSX issues and musing In-Reply-To: <496D2B07-8C23-4D2F-ABA7-132E8E2106C6@canb.auug.org.au> References: <20220731195702.ACC4218C0C1@mercury.lcs.mit.edu> <496D2B07-8C23-4D2F-ABA7-132E8E2106C6@canb.auug.org.au> Message-ID: The H11 was made worse by the matching H9 terminal which was a real turkey. Rather than having regular key caps, it just had lots of identical buttons which you stuck stickers to with the letters, etc.. In addition, if you sent it lower case letters, it printed gibberish rather than just showing upper case versions of it. You had to home lcase mode in stty worked properly. From g.branden.robinson at gmail.com Wed Aug 3 15:09:21 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Wed, 3 Aug 2022 00:09:21 -0500 Subject: [TUHS] LSX issues and musing In-Reply-To: <496D2B07-8C23-4D2F-ABA7-132E8E2106C6@canb.auug.org.au> References: <20220731195702.ACC4218C0C1@mercury.lcs.mit.edu> <496D2B07-8C23-4D2F-ABA7-132E8E2106C6@canb.auug.org.au> Message-ID: <20220803050921.lgmzvgtpye5rseol@illithid> At 2022-08-03T14:32:10+1000, steve jenkin wrote: > Price didn’t win the market. IBM’s 5150 was never “cheapest” or > technically “best” at any time - hence rapid rise of (variable > quality) clones, built down to a price. > > Wikipedia says: > > 1978: H11 US$1295 (kit) or US$1595 fully assembled ("4kword base system”) > display advert > > $1295 kit + postage/freight, bare system, 8KB > (4kword), 6 Q-bus slots free. ROM ? > > 1981: IBM 5150(PC) US$1,565 for "16 KB RAM, Color Graphics > Adapter, and no disk drives.” > ( I only saw 5150’s with 2x 5.25” 360KB floppies > included - otherwise, can’t run programs & store > files) Yeah, you could. You simply didn't store stuff to disks. You used audio cassette tape. https://en.wikipedia.org/wiki/IBM_cassette_tape 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 jnc at mercury.lcs.mit.edu Thu Aug 4 01:17:09 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 3 Aug 2022 11:17:09 -0400 (EDT) Subject: [TUHS] LSX issues and musing Message-ID: <20220803151709.E4CA718C0CF@mercury.lcs.mit.edu> > Also, another problem with trying to 'push' LSX into a previously > un-handled operating regions (e.g. large disks, but there are likely > others) is that there are probably things that are un-tested in that > previously unused operating mode, and there may be un-found bugs that > you trip across. 'Speak of the devil, and hear the sound of his wings.' >> From: Gavin Tersteeg >> Interestingly enough, existing large V6 RK05 images can be mounted, >> read from, and written to. The only limitations on these pre existing >> images is that if enough files are deleted, the system will randomly >> crash. > I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and > alloc.c), but I couldn't quickly find the cause; it isn't obvious. I don't know if the following is _the_ cause of the crashes, but another problem (another aspect of the '100 free inodes cache' thing) swam up out of my brain. If you look at V6's alloc$ifree(), it says: if(fp->s_ninode >= 100) return; fp->s_inode[fp->s_ninode++] = ino; LSX's is missing the first two lines. So, if you try and free more than 100 inodes on LSX, the next line will march out of the s_inode array and smash other fields in the in-core copy of the super-block. Like I said, this is not certain to be the cause of those crashes; and it's not really a 'bug' (as in the opening observation) - but the general sense of that observation is right on target. LSX is really designed to operate only on disks with less than 100 inodes, and tring to run it elsewhere is going to run into issues. How many similar limitations exist in other areas I don't know. > From: Heinz Lycklama > Remember that the LSX and Mini-UNIX systems were developed for two > different purposes. Oh, that's understood - but this just re-states my observation, that LSX was designed to operate in a certain environment, and trying to run it elsewhere is just asking for problems. Noel From john at jfloren.net Fri Aug 5 05:45:16 2022 From: john at jfloren.net (John Floren) Date: Thu, 04 Aug 2022 19:45:16 +0000 Subject: [TUHS] The MGR window system and the Macintosh Message-ID: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> Today I came across an article about the MGR window system for Unix: https://hack.org/mc/mgr/ One thing that interested me was a note that some versions worked on the Macintosh: > The window system ran on many different hardware platforms, at least > these: Sun 3/xx workstations running SunOS, which was the the original > development platform, Sun SPARCstations (SunOS and then ported by me to > Solaris), Intel x86 based PCs (Coherent, Minix, FreeBSD or Linux), > Atari ST (under MiNT), AT&T UnixPC (SysV) and the Macintosh. As the owner of a Macintosh Plus, I think it would be a very interesting thing to experiment with, but I haven't had much luck finding any more information about it. Does anyone know more about MGR, particularly on the Mac? That page has the source for MGR 0.69, but there's no mention of the Macintosh in it (aside from comments about how it was supported on older versions...) John From aek at bitsavers.org Fri Aug 5 06:18:27 2022 From: aek at bitsavers.org (Al Kossow) Date: Thu, 4 Aug 2022 13:18:27 -0700 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> Message-ID: On 8/4/22 12:45 PM, John Floren wrote: > Today I came across an article about the MGR window system for Unix: > https://hack.org/mc/mgr/ > > One thing that interested me was a note that some versions worked on the > Macintosh: https://news.ycombinator.com/item?id=22457846 gives the origins I probably have the code in the backups of the archive that I used to maintain on the Apple VAX at that time. From jnc at mercury.lcs.mit.edu Fri Aug 5 06:20:26 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 4 Aug 2022 16:20:26 -0400 (EDT) Subject: [TUHS] Document on BBN's VAX Unix TCP Message-ID: <20220804202026.53AB818C0DE@mercury.lcs.mit.edu> While looking for something else, I found this: VAX-UNIX Networking Support Project Implementation Description Robert F. Gurwitz; January, 1981 https://www.rfc-editor.org/ien/ien168.txt in a somewhat obscure location. I have no idea if it's already widely known or not, but here it is anyway. Noel From aek at bitsavers.org Fri Aug 5 06:29:00 2022 From: aek at bitsavers.org (Al Kossow) Date: Thu, 4 Aug 2022 13:29:00 -0700 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> Message-ID: <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> On 8/4/22 1:18 PM, Al Kossow wrote: > On 8/4/22 12:45 PM, John Floren wrote: >> Today I came across an article about the MGR window system for Unix: >> https://hack.org/mc/mgr/ >> >> One thing that interested me was a note that some versions worked on the >> Macintosh: > > https://news.ycombinator.com/item?id=22457846 > > gives the origins > > I probably have the code in the backups of the archive that I used to maintain on the Apple VAX > at that time. you can find the original c.s.unix files here http://sources.vsta.org/comp.sources.unix/volume17/mgr i think I may need to push this to bitsavers. the c.s.unix archive was a little more difficult to find than I thought. From crossd at gmail.com Fri Aug 5 07:14:02 2022 From: crossd at gmail.com (Dan Cross) Date: Thu, 4 Aug 2022 17:14:02 -0400 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> Message-ID: On Thu, Aug 4, 2022 at 3:46 PM John Floren wrote: > [snip] > Does anyone know more about MGR, particularly on the Mac? That page has > the source for MGR 0.69, but there's no mention of the Macintosh in it > (aside from comments about how it was supported on older versions...) I got it working once under FreeBSD back in the 4.x days. It wasn't particularly notable, or at least didn't leave much of an impression; it presented a pretty "standard" (and primitive!) graphical experience. I believe it was monochrome, with amber on black. I don't know anything about it on the Mac, I'm afraid; I suspect it probably ran in a Window under Finder, but that is pure speculation. - Dan C. From bakul at iitbombay.org Fri Aug 5 08:07:30 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 4 Aug 2022 15:07:30 -0700 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> Message-ID: <566D98A2-B976-44A9-BD53-F10ECC7E24BC@iitbombay.org> > On Aug 4, 2022, at 2:14 PM, Dan Cross wrote: > > On Thu, Aug 4, 2022 at 3:46 PM John Floren wrote: >> [snip] >> Does anyone know more about MGR, particularly on the Mac? That page has >> the source for MGR 0.69, but there's no mention of the Macintosh in it >> (aside from comments about how it was supported on older versions...) > > I got it working once under FreeBSD back in the 4.x days. > > It wasn't particularly notable, or at least didn't leave much of an > impression; it presented a pretty "standard" (and primitive!) > graphical experience. I believe it was monochrome, with amber > on black. > > I don't know anything about it on the Mac, I'm afraid; I suspect it > probably ran in a Window under Finder, but that is pure speculation. From its wikipedia entry: The initial Macintosh port was done on a Macintosh Plus computer using the Lightspeed C compiler. It was a hybrid port in that many of the low-level operations were passed on to QuickDraw instead of using the internal bitmap code. The application did not conform to the Macintosh user interface guidelines as it took over the entire screen. The initial version used either available serial port as the communications channel. A later update of the port could use either ethernet or serial communications. [No reference to how this was obtained] MGR reference manual (from Stephen A. Uhler's home page): https://sau.homeip.net/papers/mgrman.pdf Architecture and Design of the MGR Window System: https://sau.homeip.net/papers/arch.pdf Here it says a port to Macintosh-Plus was done in two weeks. From tuhs at tuhs.org Fri Aug 5 09:07:05 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Thu, 4 Aug 2022 17:07:05 -0600 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> Message-ID: On 8/4/22 2:29 PM, Al Kossow wrote: > you can find the original c.s.unix files here > http://sources.vsta.org/comp.sources.unix/volume17/mgr Oh ... that's going to be a slippery slope. I've already downloaded 108 MB and plan on integrating the messages into a Maildir where -- I think -- my MUA will make it trivial to read messages. }:-) I looked through the index.2 file from volume 29 for volumes 28, 27, and part of 26 where I found half a dozen or more things that I want to investigate. I suspect I'm going to be printing that listing and highlighting things of interest. I think there's a rabbit hole at the bottom of the slippery slope that I'm already sliding down. > i think I may need to push this to bitsavers. the c.s.unix archive > was a little more difficult to find than I thought. Is that your site? Or someone else's. The URL tends to indicate the latter. I ask because I'd be happy to mirror it on my site. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From tuhs at tuhs.org Fri Aug 5 09:09:32 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Thu, 4 Aug 2022 17:09:32 -0600 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: <566D98A2-B976-44A9-BD53-F10ECC7E24BC@iitbombay.org> References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <566D98A2-B976-44A9-BD53-F10ECC7E24BC@iitbombay.org> Message-ID: <65dd4b96-d08d-610e-5fa7-d228f093b78d@spamtrap.tnetconsulting.net> On 8/4/22 4:07 PM, Bakul Shah wrote: > From its wikipedia entry: > > The initial Macintosh port was done on a Macintosh Plus computer > using the Lightspeed C compiler. It was a hybrid port in that many > of the low-level operations were passed on to QuickDraw instead of > using the internal bitmap code. The application did not conform to > the Macintosh user interface guidelines as it took over the entire > screen. The initial version used either available serial port as the > communications channel. A later update of the port could use either > ethernet or serial communications. The idea of something doing graphics over a serial port is intriguing to me. Eliding some form of IP over a dial up connection. The closest thing that comes to mind is Sixel or ReGIS graphics. > [No reference to how this was obtained] > > MGR reference manual (from Stephen A. Uhler's home page): > https://sau.homeip.net/papers/mgrman.pdf > > Architecture and Design of the MGR Window System: > https://sau.homeip.net/papers/arch.pdf > > Here it says a port to Macintosh-Plus was done in two weeks. :-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From rich.salz at gmail.com Fri Aug 5 09:16:11 2022 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 4 Aug 2022 19:16:11 -0400 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> Message-ID: I think if you search for "comp.sources.unix archive" or maybe "mod.sources" you should find lots of places. I don't have a copy:) /r$, moderator thereto PS: Uhler presented MGR at Usenix. A year or two later he presented spiff, a "spiffy diff" and he got much better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Aug 5 09:21:28 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 4 Aug 2022 16:21:28 -0700 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> Message-ID: > On Aug 4, 2022, at 4:07 PM, Grant Taylor via TUHS wrote: > > On 8/4/22 2:29 PM, Al Kossow wrote: >> i think I may need to push this to bitsavers. the c.s.unix archive was a little more difficult to find than I thought. > > Is that your site? Or someone else's. The URL tends to indicate the latter. I believe that is Andy Valencia's site. He is the author of VSTa microkernel. > I ask because I'd be happy to mirror it on my site. I think Usenet bits are archived on archive.org. For instance: https://archive.org/details/cdrom-usernet-sources-newsgroups-1994-10-1 You can also find them on googlegroups but don't know what damage they may have done. I FTPed all comp.sources.{unix,x} posts from DEC's gatekeeper about 20 years back. I still prefer local copies of things I may want to check out again! From aek at bitsavers.org Fri Aug 5 09:42:28 2022 From: aek at bitsavers.org (Al Kossow) Date: Thu, 4 Aug 2022 16:42:28 -0700 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> Message-ID: <165ffedb-413e-5119-bf63-3209cb5cd2da@bitsavers.org> On 8/4/22 4:21 PM, Bakul Shah wrote: > I think Usenet bits are archived on archive.org. Forgot about the Walnut Creek Sources CD from 1992 https://archive.org/details/CDROM_March92 From tuhs at tuhs.org Fri Aug 5 09:51:18 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Thu, 4 Aug 2022 17:51:18 -0600 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: <165ffedb-413e-5119-bf63-3209cb5cd2da@bitsavers.org> References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> <165ffedb-413e-5119-bf63-3209cb5cd2da@bitsavers.org> Message-ID: <55d4387a-9987-7c67-0184-f5894e640465@spamtrap.tnetconsulting.net> On 8/4/22 5:42 PM, Al Kossow wrote: > Forgot about the Walnut Creek Sources CD from 1992 > > https://archive.org/details/CDROM_March92 LOL You all are feeding a -- let's go with -- questionable hobby. At least it's cheaper than a hole in the water that you pour money into. a.k.a. a boat. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From lm at mcvoy.com Fri Aug 5 09:56:23 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 4 Aug 2022 16:56:23 -0700 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> Message-ID: <20220804235623.GQ1959@mcvoy.com> On Thu, Aug 04, 2022 at 04:21:28PM -0700, Bakul Shah wrote: > > > On Aug 4, 2022, at 4:07 PM, Grant Taylor via TUHS wrote: > > > > On 8/4/22 2:29 PM, Al Kossow wrote: > >> i think I may need to push this to bitsavers. the c.s.unix archive was a little more difficult to find than I thought. > > > > Is that your site? Or someone else's. The URL tends to indicate the latter. > > I believe that is Andy Valencia's site. He is the author of VSTa microkernel. > > > I ask because I'd be happy to mirror it on my site. > > I think Usenet bits are archived on archive.org. For instance: > https://archive.org/details/cdrom-usernet-sources-newsgroups-1994-10-1 > > You can also find them on googlegroups but don't know what damage they may > have done. Oh, the damage that Google has done to netnews is immense. Remember dejanews? With their spiffy search interface that would let you look for stuff in date ranges? Yeah, google bought dejanews, killed the search (because theirs was "better", it most definitely is not), and then did google groups which is complete garbage. From lm at mcvoy.com Fri Aug 5 09:58:30 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 4 Aug 2022 16:58:30 -0700 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: <55d4387a-9987-7c67-0184-f5894e640465@spamtrap.tnetconsulting.net> References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> <165ffedb-413e-5119-bf63-3209cb5cd2da@bitsavers.org> <55d4387a-9987-7c67-0184-f5894e640465@spamtrap.tnetconsulting.net> Message-ID: <20220804235830.GR1959@mcvoy.com> On Thu, Aug 04, 2022 at 05:51:18PM -0600, Grant Taylor via TUHS wrote: > At least it's cheaper than a hole in the water that you pour money into. > a.k.a. a boat. See my signature :) I bought new so most of the money poured was up front, I paid 10x what a buddy of mine did who has the same boat (Grady-White 228 if anyone cares) but mine just works and he is constantly working on his. I got the better deal if you care about your time. I want to fish, not wrench. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From atrn at optusnet.com.au Fri Aug 5 10:37:11 2022 From: atrn at optusnet.com.au (Andrew Newman) Date: Fri, 5 Aug 2022 10:37:11 +1000 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: <65dd4b96-d08d-610e-5fa7-d228f093b78d@spamtrap.tnetconsulting.net> References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <566D98A2-B976-44A9-BD53-F10ECC7E24BC@iitbombay.org> <65dd4b96-d08d-610e-5fa7-d228f093b78d@spamtrap.tnetconsulting.net> Message-ID: > On 5 Aug 2022, at 9:09 am, Grant Taylor via TUHS wrote: > > > The idea of something doing graphics over a serial port is intriguing to me. Eliding some form of IP over a dial up connection. > > The closest thing that comes to mind is Sixel or ReGIS graphics. In the early to mid 1980s I used Tektronix storage terminals hooked up to a PDP-11 and/or VAX. And we also had an AED terminal that did raster graphics. All via serial comms. There's a bunch of AED documentation online, including this... http://www.bitsavers.org/pdf/aed/brochures/AED_767_Brochure_Jun82.pdf (searching for AED graphics terminal will lead you to the user manual which has a lot more detail and electrical specs and so on) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Fri Aug 5 11:59:50 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 4 Aug 2022 18:59:50 -0700 Subject: [TUHS] Document on BBN's VAX Unix TCP (Noel Chiappa) Message-ID: <6BC10DD4-DC23-4D74-970C-25BDA17544CC@planet.nl> > While looking for something else, I found this: > > VAX-UNIX Networking Support Project Implementation Description > Robert F. Gurwitz; January, 1981 > https://www.rfc-editor.org/ien/ien168.txt > > in a somewhat obscure location. I have no idea if it's already widely known > or not, but here it is anyway. Hi Noel, Thank you for highlighting this document. I had seen it before and the implementation (as found on the tapes from CSRG and now on THUS) follows the plan outlined in IEN168 quite closely. The first snapshot of the code is just a few months after this document. In a way it is modeled after the UoI Arpanet Unix implementation (and thank you again for finding that source!), with a separate (kernel) process for network activity. In my experiments I have found that it is not all that easy to get smooth network data flow as this network process is difficult to schedule just right. I now better understand why Joy moved to "software interrupts” to get better scheduling of kernel network operations. Wbr, Paul From aek at bitsavers.org Fri Aug 5 12:14:47 2022 From: aek at bitsavers.org (Al Kossow) Date: Thu, 4 Aug 2022 19:14:47 -0700 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <566D98A2-B976-44A9-BD53-F10ECC7E24BC@iitbombay.org> <65dd4b96-d08d-610e-5fa7-d228f093b78d@spamtrap.tnetconsulting.net> Message-ID: <3e226172-b395-f5c1-df2c-b383024a08df@bitsavers.org> On 8/4/22 5:37 PM, Andrew Newman wrote: > There's a bunch of AED documentation online, including this... > > http://www.bitsavers.org/pdf/aed/brochures/AED_767_Brochure_Jun82.pdf I worked at AED before going to Apple, to stay sort of window related, the last project I worked on at AED was a VME and Qbus board set that was a complete color X terminal. At the time, Jim Gettys didn't see the point of the product. http://bitsavers.org/pdf/aed/colorware_cards/pictures/screen.jpg From tuhs at tuhs.org Fri Aug 5 14:26:51 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Thu, 4 Aug 2022 22:26:51 -0600 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: <20220804235830.GR1959@mcvoy.com> References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> <165ffedb-413e-5119-bf63-3209cb5cd2da@bitsavers.org> <55d4387a-9987-7c67-0184-f5894e640465@spamtrap.tnetconsulting.net> <20220804235830.GR1959@mcvoy.com> Message-ID: On 8/4/22 5:58 PM, Larry McVoy wrote: > See my signature :) I'm glad to see the :) because I did mean it as a joke and to be funny. > I bought new so most of the money poured was up front, I paid 10x > what a buddy of mine did who has the same boat (Grady-White 228 if > anyone cares) but mine just works and he is constantly working on his. > I got the better deal if you care about your time. There's the purchase price and then there's the total cost of ownership. > I want to fish, not wrench. I like that phrase and it's intent. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From tuhs at tuhs.org Fri Aug 5 14:35:23 2022 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Thu, 4 Aug 2022 21:35:23 -0700 Subject: [TUHS] LSX issues and musing Message-ID: > Any ideas on why businesses didn’t pick up the H11 in 1980? > [priced too high for hobbyists] > > Wikipedia says: > > 1978: H11 US$1295 (kit) or US$1595 fully assembled ("4kword base system”) > display advert $1295 kit + postage/freight, bare system, 8KB (4kword), 6 Q-bus slots free. ROM ? > > 1981: IBM 5150(PC) US$1,565 for "16 KB RAM, Color Graphics Adapter, and no disk drives.” > ( I only saw 5150’s with 2x 5.25” 360KB floppies included - otherwise, can’t run programs & store files) Note that those are nominal prices. In terms of purchasing power USD 1595 in 1978 equated about USD 2200 in 1981 (https://www.in2013dollars.com/us/inflation/1978?endYear=1981&amount=1595). Otherwise agree with your observation on packaged, off-the-shelf software being the main driver. In small business before the IBM PC, Visicalc drove Apple II uptake; Wordstar, C-Basic 2 and DBase drove CP/M uptake. Would LSI-11 hardware with LSX, ed and nroff have been competitive in small business? The experiences of John Walker (of AutoCAD fame) suggests not: https://www.fourmilab.ch/documents/marinchip/ From arnold at skeeve.com Fri Aug 5 18:38:57 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 05 Aug 2022 02:38:57 -0600 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> Message-ID: <202208050838.2758cvcE018667@freefriends.org> John Floren wrote: > Today I came across an article about the MGR window system for Unix: > https://hack.org/mc/mgr/ I ran it for a while on a sparcstation. Compared to X Windows on the same hardware it was super fast. IIRC the version I used supported color. Although I owned a UnixPC, I never botherd to put MGR on it. It was a neat, small footprint windowing system. Arnold From clemc at ccc.com Fri Aug 5 23:33:05 2022 From: clemc at ccc.com (Clem Cole) Date: Fri, 5 Aug 2022 09:33:05 -0400 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: <3e226172-b395-f5c1-df2c-b383024a08df@bitsavers.org> References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <566D98A2-B976-44A9-BD53-F10ECC7E24BC@iitbombay.org> <65dd4b96-d08d-610e-5fa7-d228f093b78d@spamtrap.tnetconsulting.net> <3e226172-b395-f5c1-df2c-b383024a08df@bitsavers.org> Message-ID: This thread needs to move to COFF to continue - although my own story is 1/2 about BSD and the VAX. On Thu, Aug 4, 2022 at 10:15 PM Al Kossow wrote: > On 8/4/22 5:37 PM, Andrew Newman wrote: > > > There's a bunch of AED documentation online, including this... > > > > http://www.bitsavers.org/pdf/aed/brochures/AED_767_Brochure_Jun82.pdf < > http://www.bitsavers.org/pdf/aed/brochures/AED_767_Brochure_Jun82.pdf> > > I worked at AED before going to Apple, to stay sort of window related, the > last project I worked on at AED was > a VME and Qbus board set that was a complete color X terminal. > I had to chuckle when I read that. In the fall of '82 (I think), we got a Smalltalk VM from PARC at UCB. Dave Unger, Ken Keller, and I - plus some other folks in Patterson's systems seminar who's names I have since forgotten, wrote a VM in C for the VAX/BSD. We used an AED512 and Keller's graphics library from his thesis running over a 19.2 serial link as the output. About a month after we had it running, a couple of us got to visit PARC, and Peter Deutch showed us Smalltalk running on a Dorado. He ran his hand with the mouse across the screen opening and closing a bunch of windows randomly. We started laughing and Peter asked us what was so funny. We told him what he did would have taken at least 5 minutes to redisplay on BSD/VAX version. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Aug 9 05:08:11 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 08 Aug 2022 19:08:11 +0000 Subject: [TUHS] Likelihood of Extant Less-Distributed Tapes and Sources Message-ID: Good morning everyone. Wanted to pose the question since folks here would probably be more likely to know than anyone. What are the chances that there are surviving tapes of some of the UNIX versions that weren't so well publicized. The versions that come to mind are the CB and USG lines especially, with PWB 2.0 and TS 4.0 getting honorable mention. If folks will recall, we did luck out in that Arnold, a member of this mailing list, did have a documentation trove from TS 4.0, but no binary or source code assets. This had me curious on what trying to unearth these would even look like. Has anyone tried to dive deep on this sort of stuff before? Would it look more like trying to find old Bell facilities that might have a tape bumping around in a box in a basement somewhere, or is it more likely that if anything survived it would have been due to being nabbed by an employee or contractor before disposal? Or even just in general, what would folks say is the likelihood that there is a recoverable tape of any of this material just waiting to see the light of day? The closest we have on CB is a paper scan of the kernel sources, and I don't know that any assets from USG-proper have ever percolated up, closest thing to any of that would be the kernel routine description bumping around on the archive somewhere. PWB 2.0 is mentioned in several places, but no empirical evidence has surfaced as far as I know, and with 4.0 of course we have the documents Arnold thankfully preserved, but that's it. Thanks in advance for any insight or thoughts. My concern is that there is a rapidly closing window on ever being able to properly preserve these parts of the UNIX story, although recognition must be paid to all of the hard work folks have done here thus far to keep this valuable part of computing history in the collective consciousness and accessible to researchers and programmers for years and years to come. - Matt G. P.S. Even more honorable mention is the Bell Interdata 8/32 work. I've read several places that never saw outside distribution, but I would have to wonder if any of that work survived beyond the visible portability changes in V7. From tuhs at tuhs.org Tue Aug 9 09:52:00 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 08 Aug 2022 23:52:00 +0000 Subject: [TUHS] Documents for UNIX Collections Message-ID: I didn't expect to have more documents to share this soon, but I've just secured a trove of early System V/5.0 documents, as listed: System V User's Manual System V Administrator's Manual System V Error Message Manual System V Transition Aids System V Release Description User's Guide Operator's Guide Administrator's Guide Programming Guide Graphics Guide Support Tools Guide Document Processing Guide The System V-prefixed ones are very specifically labeled System V, although I know at least of the User's and Administrator's Manuals with "Release 5.0" branding out in the wild as well. I've got two of the User's Manuals exhibiting this difference. I believe I've seen a scan of the Admin's Manual with 5.0 as well, but I would have to go searching for it, it's on bitsavers perhaps? In any case, this is the documentation series for the initial releases of System V, the ones with "UNIX System" in big letters with grid patterns fading out into the background. I don't know if the second set is considered part of the Release 5.0 or System V version of the document package, or if they made that distinction, but as of present I can positively identify the first 5 as being specifically for the System V version of this release. What is particularly curious is there are documents displaying "System V" but with a Western Electric logo on the front. I've seen a scan of a System V gold User's Manual with the logo removed and a disclaimer on the front page explaining that they can't use the Bell logo anymore due to the divestiture, likewise on bitsavers I'm pretty sure, so this may establish that there were at least three revisions: Release 5.0, System V pre-divestiture, and System V post-divestiture. Now for a little plug, just because she's been so incredibly helpful, I bought these from Leslie (last name unknown) known as "oldmaddogshop" on eBay. We got chatting for a little while and her husband was a computing professor at the University of Portland for some time as it sounds, and they're currently starting to go through the decades of literature and hardware he's picked up over the years for sale on eBay and perhaps other avenues. She very specifically mentioned a PDP-8 that he happens to have that he's hoping they can coordinate to donate to a museum or some other way to get it into a relatively publicly accessible space rather than winding up in the closet of a private collector. I told her I'd drop a brief mention in letting folks know about the documents in case they'd want the option of perusing some of what they're going to be offloading. She made mention of a stack of USENIX manuals as well, I have a smattering of 4.2 and 4.3 manuals already, so someone may be lucky enough to snag those soon enough. Up currently are an early SVID and some OSF/Motif stuff, but she said they've got plenty of boxes of books to go through. Anywho, once I receive these documents, I plan on starting the scanning process much like with the UNIX/TS 4.0 stuff, and will be in touch with Warren concerning hosting and a release as time goes on. One bit of input if anyone knows, does the above list represent (aside from Release 5.0 variants) the complete documentation package for System V gold? I can't say I've come across any other titles, and most certainly haven't seen PDFs of anything that isn't included here, but I see plenty of titles I've never seen scanned. If nothing else, I'm hoping that "Release Description" document may have a brief flyover of the published materials, akin to the list of books at the beginning of the SVR4 manuals or the documentation roadmaps of earlier UNIX/TS and PWB releases. - Matt G. From aek at bitsavers.org Tue Aug 9 10:37:37 2022 From: aek at bitsavers.org (Al Kossow) Date: Mon, 8 Aug 2022 17:37:37 -0700 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: References: Message-ID: On 8/8/22 4:52 PM, segaloco via TUHS wrote: > I didn't expect to have more documents to share this soon, but I've just secured a trove of early System V/5.0 documents Hopefully, you've learned something about scanning and won't produce the same shit scans you dumped on IA From dave at horsfall.org Tue Aug 9 11:46:38 2022 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 9 Aug 2022 11:46:38 +1000 (EST) Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> Message-ID: [ Moved to COFF ] On Thu, 4 Aug 2022, Dan Cross wrote: [...] > It wasn't particularly notable, or at least didn't leave much of an > impression; it presented a pretty "standard" (and primitive!) > graphical experience. I believe it was monochrome, with amber > on black. It also ran on the Applix 1616, an Aussie designed and built 68000 system; it was pretty much ahead of its time. https://en.wikipedia.org/wiki/Applix_1616 -- Dave From dave at horsfall.org Tue Aug 9 11:50:35 2022 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 9 Aug 2022 11:50:35 +1000 (EST) Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> Message-ID: On Tue, 9 Aug 2022, Dave Horsfall wrote: > It also ran on the Applix 1616, an Aussie designed and built 68000 > system; it was pretty much ahead of its time. > > https://en.wikipedia.org/wiki/Applix_1616 Oops; I forgot the article describing how MGR was ported to said box: http://ericlindsay.com/applix/mgr.pdf -- Dave From jgevaryahu at hotmail.com Tue Aug 9 15:12:50 2022 From: jgevaryahu at hotmail.com (Jonathan Gevaryahu) Date: Tue, 9 Aug 2022 01:12:50 -0400 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <20220729050748.GB12246@tau1.ceti.pl> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> <20220729050748.GB12246@tau1.ceti.pl> Message-ID: On 7/29/2022 1:07 AM, Tomasz Rola wrote: > On Wed, Jul 27, 2022 at 10:13:04PM -0600, William H. Mitchell wrote: > [...] >> Phil Budne: Thanks for your CSNOBOL4 implementation! I’ve used it to show students SNOBOL4 in a comparative languages class at the U of Arizona. (I was thinking your name sounded familiar!) >> >>> On Jul 27, 2022, at 7:03 PM, Phil Budne wrote: >>> >>>> Anyway, I have got Phil Budne's implementation >>> C'est moi! SNOBOL came out of Bell Labs in Holmdel NJ. >>> There was a SNOBOL3 implementation in Unix 6th Edition days called "sno". > [...] > > Yes, I have had a look and it seems to be very nicely written > project. Oh, and there is plenty of Snobol4 code to look at, too... > > Thank you. > Speaking of SNOBOL4, I typed up the SNOBOL code from the NRL Report 7948 (1975) titled "Automatic Translation of English Text to Phonetics by Means of Letter-to-Sound Rules" by Honey Sue Elovitz, Rodney W. Johnson, Astrid McHugh and John E. Shore, and made some minor modifications to make it work properly with the windows/catspaw version of snobol/spitbol. It might not be necessary to make those changes at all, with Phil's version, I'll need to try that! I have both the patched and unpatched versions at https://github.com/Lord-Nightmare/NRL_TextToPhonemes and it does behave correctly/matches the paper (at least the patched version does). I recently (within the past month) discovered another later port of the NRL ruleset from 1978 as part of Peter B. Maggs' ANGLOPHONE package for S-100 systems, intended for use with the Computalker CT-1 speech synthesis S-100 card. Apparently Rodney W. Johnson had continued developing the rules even after the 1975/1976 publications of the NRL report and the IEEE ITASSP version of said report, and I haven't updated the bibliography on the github readme yet. Jonathan G. -- Jonathan Gevaryahu AKA Lord Nightmare jgevaryahu at gmail.com jgevaryahu at hotmail.com From robpike at gmail.com Tue Aug 9 16:11:38 2022 From: robpike at gmail.com (Rob Pike) Date: Tue, 9 Aug 2022 16:11:38 +1000 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> <20220729050748.GB12246@tau1.ceti.pl> Message-ID: We're probably well off topic now but... Many years ago I ran into Bob Dewar on a visit to Cambridge University and we got to talking. He said that the original implementation of SPITBOL, for the System/360, was in assembler (of course), and written by him and Belcher (?). The story he told was that they wrote it all down first, put it on punch cards, and sent it to the IBM machine. The next day they got back a listing with a bunch of errors. They iterated. By the fourth round—fifth day—they had a working SPITBOL. I still marvel at the productivity and precision of his generation of programmers. -rob On Tue, Aug 9, 2022 at 3:13 PM Jonathan Gevaryahu wrote: > On 7/29/2022 1:07 AM, Tomasz Rola wrote: > > On Wed, Jul 27, 2022 at 10:13:04PM -0600, William H. Mitchell wrote: > > [...] > >> Phil Budne: Thanks for your CSNOBOL4 implementation! I’ve used it to > show students SNOBOL4 in a comparative languages class at the U of > Arizona. (I was thinking your name sounded familiar!) > >> > >>> On Jul 27, 2022, at 7:03 PM, Phil Budne wrote: > >>> > >>>> Anyway, I have got Phil Budne's implementation > >>> C'est moi! SNOBOL came out of Bell Labs in Holmdel NJ. > >>> There was a SNOBOL3 implementation in Unix 6th Edition days called > "sno". > > [...] > > > > Yes, I have had a look and it seems to be very nicely written > > project. Oh, and there is plenty of Snobol4 code to look at, too... > > > > Thank you. > > > Speaking of SNOBOL4, I typed up the SNOBOL code from the NRL Report 7948 > (1975) titled "Automatic Translation of English Text to Phonetics by > Means of Letter-to-Sound Rules" by Honey Sue Elovitz, Rodney W. Johnson, > Astrid McHugh and John E. Shore, and made some minor modifications to > make it work properly with the windows/catspaw version of snobol/spitbol. > > It might not be necessary to make those changes at all, with Phil's > version, I'll need to try that! > > I have both the patched and unpatched versions at > https://github.com/Lord-Nightmare/NRL_TextToPhonemes and it does behave > correctly/matches the paper (at least the patched version does). > > I recently (within the past month) discovered another later port of the > NRL ruleset from 1978 as part of Peter B. Maggs' ANGLOPHONE package for > S-100 systems, intended for use with the Computalker CT-1 speech > synthesis S-100 card. Apparently Rodney W. Johnson had continued > developing the rules even after the 1975/1976 publications of the NRL > report and the IEEE ITASSP version of said report, and I haven't updated > the bibliography on the github readme yet. > > > Jonathan G. > > -- > Jonathan Gevaryahu AKA Lord Nightmare > jgevaryahu at gmail.com > jgevaryahu at hotmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Aug 9 17:00:31 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 09 Aug 2022 07:00:31 +0000 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: References: Message-ID: Frankly I will scan however I want given I am both paying for the documents myself and scanning them in my own free time. You can take your elitism elsewhere rather than offering unsolicited criticism of work you aren't even going to do. Please keep this thread on topic, contribute or don't. - Matt G. ------- Original Message ------- On Monday, August 8th, 2022 at 5:37 PM, Al Kossow wrote: > On 8/8/22 4:52 PM, segaloco via TUHS wrote: > > > I didn't expect to have more documents to share this soon, but I've just secured a trove of early System V/5.0 documents > > > Hopefully, you've learned something about scanning and won't produce the same shit scans you dumped on IA From aek at bitsavers.org Tue Aug 9 22:49:43 2022 From: aek at bitsavers.org (Al Kossow) Date: Tue, 9 Aug 2022 05:49:43 -0700 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: References: Message-ID: On 8/9/22 12:00 AM, segaloco wrote: > Frankly I will scan however I want given I am both paying for the documents myself and scanning them in my own free time. Queue the virtue signaling. That is EXACTLY why I sent the rude message. I spent days cleaning up your scans to meet the bitsavers scanning quality requirements of the garbage you produced, because you spent a WHOLE DAY scanning them. I've been doing this for twenty years, don't talk to me about time or money spent doing this From clemc at ccc.com Tue Aug 9 23:34:57 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 9 Aug 2022 09:34:57 -0400 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> <20220729050748.GB12246@tau1.ceti.pl> Message-ID: On Tue, Aug 9, 2022 at 2:12 AM Rob Pike wrote: > > I still marvel at the productivity and precision of his generation of > programmers. > Amen. When I was first learning the ins and outs of the implementation of the York/APL System for the 360, I was regaled with similar stories and hoped that I could measure up to their standards. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Aug 9 23:56:31 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 9 Aug 2022 06:56:31 -0700 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: References: <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> <20220729050748.GB12246@tau1.ceti.pl> Message-ID: <20220809135631.GH20435@mcvoy.com> On Tue, Aug 09, 2022 at 04:11:38PM +1000, Rob Pike wrote: > We're probably well off topic now but... > > Many years ago I ran into Bob Dewar on a visit to Cambridge University and > we got to talking. He said that the original implementation of SPITBOL, for > the System/360, was in assembler (of course), and written by him and > Belcher (?). The story he told was that they wrote it all down first, put > it on punch cards, and sent it to the IBM machine. The next day they got > back a listing with a bunch of errors. They iterated. By the fourth > round???fifth day???they had a working SPITBOL. > > I still marvel at the productivity and precision of his generation of > programmers. I had the same reaction to pic(1). You could look at the code and "see" what it was doing. I've always believed that pic was so well designed because it took a day to get the print out (back then), so you had to have a language where you could see what it was doing. From tuhs at tuhs.org Wed Aug 10 01:14:57 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 09 Aug 2022 15:14:57 +0000 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: References: Message-ID: I'm literally the one doing it now. Got a problem with it? Tough, you're not the one doing *these* documents. Literally nobody is asking you to take on the magnanimous task of "cleaning them up". Do it yourself or step aside, but again, don't derail a thread about work I am going to do to lob criticism of work you aren't going to do. Be childish somewhere else. Sorry Al is stinking up this thread, this is the last thing I wanted, I'm just contributing. - Matt G. ------- Original Message ------- On Tuesday, August 9th, 2022 at 5:49 AM, Al Kossow wrote: > On 8/9/22 12:00 AM, segaloco wrote: > > > Frankly I will scan however I want given I am both paying for the documents myself and scanning them in my own free time. > > > Queue the virtue signaling. > > That is EXACTLY why I sent the rude message. > I spent days cleaning up your scans to meet the bitsavers scanning quality requirements of the > garbage you produced, because you spent a WHOLE DAY scanning them. > > I've been doing this for twenty years, don't talk to me about time or money spent doing this From andrew at humeweb.com Wed Aug 10 01:15:38 2022 From: andrew at humeweb.com (Andrew Hume) Date: Tue, 9 Aug 2022 08:15:38 -0700 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> <20220729050748.GB12246@tau1.ceti.pl> Message-ID: <1815F4B8-D6B4-4C71-AC05-27D88C1E580D@humeweb.com> rob, clem: has there been a shift in ability? or is this more likely a sampling bias (because there were so many fewer programmers then)? > On Aug 9, 2022, at 6:34 AM, Clem Cole wrote: > > > > On Tue, Aug 9, 2022 at 2:12 AM Rob Pike > wrote: > > I still marvel at the productivity and precision of his generation of programmers. > Amen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at anduin.eldar.org Wed Aug 10 01:16:08 2022 From: brad at anduin.eldar.org (Brad Spencer) Date: Tue, 09 Aug 2022 11:16:08 -0400 Subject: [TUHS] Likelihood of Extant Less-Distributed Tapes and Sources In-Reply-To: (message from segaloco via TUHS on Mon, 08 Aug 2022 19:08:11 +0000) Message-ID: segaloco via TUHS writes: > Good morning everyone. Wanted to pose the question since folks here would probably be more likely to know than anyone. > > What are the chances that there are surviving tapes of some of the UNIX versions that weren't so well publicized. The versions that come to mind are the CB and USG lines especially, with PWB 2.0 and TS 4.0 getting honorable mention. If folks will recall, we did luck out in that Arnold, a member of this mailing list, did have a documentation trove from TS 4.0, but no binary or source code assets. This had me curious on what trying to unearth these would even look like. > > Has anyone tried to dive deep on this sort of stuff before? Would it look more like trying to find old Bell facilities that might have a tape bumping around in a box in a basement somewhere, or is it more likely that if anything survived it would have been due to being nabbed by an employee or contractor before disposal? Or even just in general, what would folks say is the likelihood that there is a recoverable tape of any of this material just waiting to see the light of day? The closest we have on CB is a paper scan of the kernel sources, and I don't know that any assets from USG-proper have ever percolated up, closest thing to any of that would be the kernel routine description bumping around on the archive somewhere. PWB 2.0 is mentioned in several places, but no empirical evidence has surfaced as far as I know, and with 4.0 of course we have the documents Arnold thankfully preserved, but that's it. [snip] I am not sure where CBUNIX was actually developed, but I spent 12 years at 6200 Broad Street and a tiny bit at 6400 Broad Street and knew folks who were associated with the Dublin Training center. I didn't do operating systems development and I did not work on the physical switch gear, rather I was in one of the many support system products that got sold to all of the RBOCs and around the world. The Broad Street site(s) have been sold off many years ago. All that remains of 6200 Broad is the front part of the building. The back part, the factory and much of the high bay area, fell in on itself some years ago and the rubble was cleared away. The concrete floor still remains. A hospital system bought the building grounds and much of the rest of the land was sold off and houses were built and some fast food joints put in. As far as I can tell 6400 Broad is gone, having been torn down some time ago. My memory isn't clear what happened to Dublin, but around the time of the Lucent split from AT&T or perhaps during the dark down years that followed, Dublin ceased to be a thing. I suspect sold a long time ago. I would guess that if there is anything left of CBUNIX it would be in a personal collection of stuff at this point. The story of the sale of 6200 is a bit of a mess... the hospital system actually bought the front part some years before Lucent left the building completely (Lucent moved their entrance to the east side of the building). I had an office in the front part of the building and we had a rush move to cubes that were created in the high bay area in the middle of the building when the sale was done and over with. Lots and lots of computers and devices were destroyed during that time as there was no space to keep them and I am sure that a lot was lost. The 6200 site had a industrial sized metal compactor and it was not uncommon for entire 3B2, Sun workstations and probably entire Vax systems would just be tossed in and smashed (flattened, crushed and shredded). Our group had a 3B system that was used for simulation work to the product I worked on and it was marked for destruction by mistake and destroyed out from under us one day. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From rich.salz at gmail.com Wed Aug 10 01:39:32 2022 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 9 Aug 2022 11:39:32 -0400 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> <20220729050748.GB12246@tau1.ceti.pl> Message-ID: On Tue, Aug 9, 2022 at 9:36 AM Clem Cole wrote: > > On Tue, Aug 9, 2022 at 2:12 AM Rob Pike wrote: > >> >> I still marvel at the productivity and precision of his generation of >> programmers. >> > Amen. > > When I was first learning the ins and outs of the implementation of the > York/APL System for the 360, I was regaled with similar stories and hoped > that I could measure up to their standards. > If you don't know about Mel who wrote a cheating blackjack game for a drum memory machine, read https://www.cs.utah.edu/~elb/folklore/mel.html And the postscript. > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From whm at msweng.com Wed Aug 10 02:45:53 2022 From: whm at msweng.com (William H. Mitchell) Date: Tue, 9 Aug 2022 09:45:53 -0700 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> <20220729050748.GB12246@tau1.ceti.pl> Message-ID: <444E7F34-EBFF-4BCD-9138-665BEB88B164@msweng.com> A cool thing you buy in those days was the full source code for SPITBOL, on microfiche. I bought a copy and a number of my friends did, too. It was really beautiful code. > On Aug 8, 2022, at 11:11 PM, Rob Pike wrote: > > We're probably well off topic now but... > > Many years ago I ran into Bob Dewar on a visit to Cambridge University and we got to talking. He said that the original implementation of SPITBOL, for the System/360, was in assembler (of course), and written by him and Belcher (?). The story he told was that they wrote it all down first, put it on punch cards, and sent it to the IBM machine. The next day they got back a listing with a bunch of errors. They iterated. By the fourth round—fifth day—they had a working SPITBOL. > > I still marvel at the productivity and precision of his generation of programmers. > > -rob From imp at bsdimp.com Wed Aug 10 03:16:30 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 9 Aug 2022 11:16:30 -0600 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: References: Message-ID: Perhaps Al could offer those areas that segaloco could use to improve the scans. Let's get over the 'presentation' of the issue (which we all are thinking in the back of our minds sucked) and understand how we call can produce better scans without getting overly defensive or protective about it (both reactions don't really help, and frankly aren't fun to read played out in a public list). Warner On Tue, Aug 9, 2022 at 9:15 AM segaloco via TUHS wrote: > I'm literally the one doing it now. Got a problem with it? Tough, you're > not the one doing *these* documents. Literally nobody is asking you to > take on the magnanimous task of "cleaning them up". Do it yourself or step > aside, but again, don't derail a thread about work I am going to do to lob > criticism of work you aren't going to do. Be childish somewhere else. > Sorry Al is stinking up this thread, this is the last thing I wanted, I'm > just contributing. > > - Matt G. > > ------- Original Message ------- > On Tuesday, August 9th, 2022 at 5:49 AM, Al Kossow > wrote: > > > > On 8/9/22 12:00 AM, segaloco wrote: > > > > > Frankly I will scan however I want given I am both paying for the > documents myself and scanning them in my own free time. > > > > > > Queue the virtue signaling. > > > > That is EXACTLY why I sent the rude message. > > I spent days cleaning up your scans to meet the bitsavers scanning > quality requirements of the > > garbage you produced, because you spent a WHOLE DAY scanning them. > > > > I've been doing this for twenty years, don't talk to me about time or > money spent doing this > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Wed Aug 10 03:22:57 2022 From: will.senn at gmail.com (Will Senn) Date: Tue, 9 Aug 2022 12:22:57 -0500 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: References: Message-ID: Amen to that. Scanning is very difficult to get right and folks that get it working well aren't great about making simplified processes accessible to others. Will On 8/9/22 12:16 PM, Warner Losh wrote: > Perhaps Al could offer those areas that segaloco could use to > improve the scans. > > Let's get over the 'presentation' of the issue (which we all are > thinking in the back of our minds sucked) and understand how we call > can produce better scans without getting overly defensive or > protective about it (both reactions don't really help, and frankly > aren't fun to read played out in a public list). > > Warner > > On Tue, Aug 9, 2022 at 9:15 AM segaloco via TUHS wrote: > > I'm literally the one doing it now.  Got a problem with it? Tough, > you're not the one doing *these* documents.  Literally nobody is > asking you to take on the magnanimous task of "cleaning them up".  > Do it yourself or step aside, but again, don't derail a thread > about work I am going to do to lob criticism of work you aren't > going to do.  Be childish somewhere else.  Sorry Al is stinking up > this thread, this is the last thing I wanted, I'm just contributing. > > - Matt G. > > ------- Original Message ------- > On Tuesday, August 9th, 2022 at 5:49 AM, Al Kossow > wrote: > > > > On 8/9/22 12:00 AM, segaloco wrote: > > > > > Frankly I will scan however I want given I am both paying for > the documents myself and scanning them in my own free time. > > > > > > Queue the virtue signaling. > > > > That is EXACTLY why I sent the rude message. > > I spent days cleaning up your scans to meet the bitsavers > scanning quality requirements of the > > garbage you produced, because you spent a WHOLE DAY scanning them. > > > > I've been doing this for twenty years, don't talk to me about > time or money spent doing this > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Aug 10 03:42:32 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 9 Aug 2022 13:42:32 -0400 (EDT) Subject: [TUHS] SNOBOL and RATSNO Message-ID: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> > From: Rob Pike > I still marvel at the productivity and precision of his generatio We noticed the same thing happening in the IETF, as the number of people working on networking went up. The explanation is really quite simple, once you think about it a bit. If you have a very small group, it is quite possible to have a very high level. (Not if it's selected randomly, of course; there has to be some sorting function.) However, as the group gets much larger, it is _necessarily_ much more 'average' in the skill/etc level of its members. This rule applies to any group - which includes the members of TUHS, of course. Noel From clemc at ccc.com Wed Aug 10 04:26:43 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 9 Aug 2022 14:26:43 -0400 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <1815F4B8-D6B4-4C71-AC05-27D88C1E580D@humeweb.com> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> <20220729050748.GB12246@tau1.ceti.pl> <1815F4B8-D6B4-4C71-AC05-27D88C1E580D@humeweb.com> Message-ID: On Tue, Aug 9, 2022 at 11:15 AM Andrew Hume wrote: > rob, clem: > > has there been a shift in ability? or is this more likely a sampling bias > (because there were so many fewer programmers then)? > Certainly part of it. But I think was more likely the type of person than the number. In those days because the tools and use of them required extreme precision, only the precise found their way. What's the Pixar Incredible's line: *If everyone is super, no one will be.* ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Aug 10 04:49:10 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 9 Aug 2022 11:49:10 -0700 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> References: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> Message-ID: <20220809184910.GC21168@mcvoy.com> On Tue, Aug 09, 2022 at 01:42:32PM -0400, Noel Chiappa wrote: > > From: Rob Pike > > > I still marvel at the productivity and precision of his generatio > > We noticed the same thing happening in the IETF, as the number of people > working on networking went up. The explanation is really quite simple, once > you think about it a bit. > > If you have a very small group, it is quite possible to have a very high > level. (Not if it's selected randomly, of course; there has to be some > sorting function.) However, as the group gets much larger, it is > _necessarily_ much more 'average' in the skill/etc level of its members. I used to complain about this at Sun and was dryly told "We get it, Larry, you are yeast. You need flour to make bread." And as time went on, I found that the smart people tended to find each other. So it was fine. It is more fun when it is a highly curated group of smart people. Made me work hard to keep up. From tjteixeira at earthlink.net Wed Aug 10 04:52:09 2022 From: tjteixeira at earthlink.net (Tom Teixeira) Date: Tue, 9 Aug 2022 14:52:09 -0400 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <1815F4B8-D6B4-4C71-AC05-27D88C1E580D@humeweb.com> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> <20220729050748.GB12246@tau1.ceti.pl> <1815F4B8-D6B4-4C71-AC05-27D88C1E580D@humeweb.com> Message-ID: <3aee23e2-8fd3-4586-2dd4-741eea495182@earthlink.net> I'll confess: I was never very good at bench checking batch programs, but only had at most a handful of assignments in college: generally cycles were cheap on time-sharing systems and I quickly adapted to interactive debugging. Over time (with embedded systems in networking gear and other applications), that wasn't possible and the new skill I admired was being able to add effective logging to diagnose problems. And since most of those systems were some combination of real-time/multiprocessor/multithreaded, it was generally not possible to deterministically repeat the sequence. On 8/9/22 11:15 AM, Andrew Hume wrote: > rob, clem: > > has there been a shift in ability? or is this more likely a sampling bias > (because there were so many fewer programmers then)? > > >> On Aug 9, 2022, at 6:34 AM, Clem Cole wrote: >> >> >> >> On Tue, Aug 9, 2022 at 2:12 AM Rob Pike wrote: >> >> >> I still marvel at the productivity and precision of his >> generation of programmers. >> >> Amen. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjteixeira at earthlink.net Wed Aug 10 04:54:08 2022 From: tjteixeira at earthlink.net (Tom Teixeira) Date: Tue, 9 Aug 2022 14:54:08 -0400 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <20220809184910.GC21168@mcvoy.com> References: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> <20220809184910.GC21168@mcvoy.com> Message-ID: <092e2eda-9b02-39a9-9de3-8343cd337d78@earthlink.net> On 8/9/22 2:49 PM, Larry McVoy wrote: > On Tue, Aug 09, 2022 at 01:42:32PM -0400, Noel Chiappa wrote: >> > From: Rob Pike >> >> > I still marvel at the productivity and precision of his generatio >> >> We noticed the same thing happening in the IETF, as the number of people >> working on networking went up. The explanation is really quite simple, once >> you think about it a bit. >> >> If you have a very small group, it is quite possible to have a very high >> level. (Not if it's selected randomly, of course; there has to be some >> sorting function.) However, as the group gets much larger, it is >> _necessarily_ much more 'average' in the skill/etc level of its members. > I used to complain about this at Sun and was dryly told "We get it, > Larry, you are yeast. You need flour to make bread." > > And as time went on, I found that the smart people tended to find each > other. So it was fine. > > It is more fun when it is a highly curated group of smart people. Made > me work hard to keep up. Put another way, "If you're always the smartest person in the room, you're spending your time in the wrong rooms." From lm at mcvoy.com Wed Aug 10 05:00:28 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 9 Aug 2022 12:00:28 -0700 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <092e2eda-9b02-39a9-9de3-8343cd337d78@earthlink.net> References: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> <20220809184910.GC21168@mcvoy.com> <092e2eda-9b02-39a9-9de3-8343cd337d78@earthlink.net> Message-ID: <20220809190028.GD21168@mcvoy.com> On Tue, Aug 09, 2022 at 02:54:08PM -0400, Tom Teixeira wrote: > On 8/9/22 2:49 PM, Larry McVoy wrote: > >On Tue, Aug 09, 2022 at 01:42:32PM -0400, Noel Chiappa wrote: > >> > From: Rob Pike > >> > >> > I still marvel at the productivity and precision of his generatio > >> > >>We noticed the same thing happening in the IETF, as the number of people > >>working on networking went up. The explanation is really quite simple, once > >>you think about it a bit. > >> > >>If you have a very small group, it is quite possible to have a very high > >>level. (Not if it's selected randomly, of course; there has to be some > >>sorting function.) However, as the group gets much larger, it is > >>_necessarily_ much more 'average' in the skill/etc level of its members. > >I used to complain about this at Sun and was dryly told "We get it, > >Larry, you are yeast. You need flour to make bread." > > > >And as time went on, I found that the smart people tended to find each > >other. So it was fine. > > > >It is more fun when it is a highly curated group of smart people. Made > >me work hard to keep up. > > Put another way, "If you're always the smartest person in the room, you're > spending your time in the wrong rooms." I was usually the dumbest one in the room, I found the right rooms :-) I personally like being "dumb", the other people just make you want to work harder to reach their level. Back when I used to play pool pretty seriously, I always tried to play people better than me. You get lazy if you are the best. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From marzhall.o at gmail.com Wed Aug 10 05:21:49 2022 From: marzhall.o at gmail.com (Marshall Conover) Date: Tue, 9 Aug 2022 15:21:49 -0400 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <20220809190028.GD21168@mcvoy.com> References: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> <20220809184910.GC21168@mcvoy.com> <092e2eda-9b02-39a9-9de3-8343cd337d78@earthlink.net> <20220809190028.GD21168@mcvoy.com> Message-ID: > I've always believed that pic was so well designed because it took a day to get the print out (back then), so you had to have a language where you could see what it was doing. > I'll confess: I was never very good at bench checking batch programs, but only had at most a handful of assignments in college: generally cycles were cheap on time-sharing systems and I quickly adapted to interactive debugging. Along these lines, if I'm understanding correctly, my hunch would be that part of the precision being discussed was born out of necessity. When you can't debug interactively, you're forced to be precise with your changes, influencing how you think. On the flip side, when interactive development is an option, there's an easy route to take - and so that's what ends up informing those developmer's thought patterns. I think it's possible that if you were to force a new generation to only be able to iterate once a day, you may end up with a new generation with that precision. Perhaps material for a fun experiment for the teachers on the list. Cheers, Marshall On Tue, Aug 9, 2022 at 3:01 PM Larry McVoy wrote: > > On Tue, Aug 09, 2022 at 02:54:08PM -0400, Tom Teixeira wrote: > > On 8/9/22 2:49 PM, Larry McVoy wrote: > > >On Tue, Aug 09, 2022 at 01:42:32PM -0400, Noel Chiappa wrote: > > >> > From: Rob Pike > > >> > > >> > I still marvel at the productivity and precision of his generatio > > >> > > >>We noticed the same thing happening in the IETF, as the number of people > > >>working on networking went up. The explanation is really quite simple, once > > >>you think about it a bit. > > >> > > >>If you have a very small group, it is quite possible to have a very high > > >>level. (Not if it's selected randomly, of course; there has to be some > > >>sorting function.) However, as the group gets much larger, it is > > >>_necessarily_ much more 'average' in the skill/etc level of its members. > > >I used to complain about this at Sun and was dryly told "We get it, > > >Larry, you are yeast. You need flour to make bread." > > > > > >And as time went on, I found that the smart people tended to find each > > >other. So it was fine. > > > > > >It is more fun when it is a highly curated group of smart people. Made > > >me work hard to keep up. > > > > Put another way, "If you're always the smartest person in the room, you're > > spending your time in the wrong rooms." > > I was usually the dumbest one in the room, I found the right rooms :-) > > I personally like being "dumb", the other people just make you want to > work harder to reach their level. Back when I used to play pool pretty > seriously, I always tried to play people better than me. You get lazy > if you are the best. > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From imp at bsdimp.com Wed Aug 10 06:19:29 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 9 Aug 2022 14:19:29 -0600 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: References: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> <20220809184910.GC21168@mcvoy.com> <092e2eda-9b02-39a9-9de3-8343cd337d78@earthlink.net> <20220809190028.GD21168@mcvoy.com> Message-ID: On Tue, Aug 9, 2022 at 1:23 PM Marshall Conover wrote: > > I've always believed that pic was so well designed > because it took a day to get the print out (back then), so you had to > have a language where you could see what it was doing. > > > I'll confess: I was never very good at bench checking batch programs, > but only had at most a handful of assignments in college: generally cycles > were cheap on time-sharing systems and I quickly adapted to interactive > debugging. > > Along these lines, if I'm understanding correctly, my hunch would be > that part of the precision being discussed was born out of necessity. > When you can't debug interactively, you're forced to be precise with > your changes, influencing how you think. On the flip side, when > interactive development is an option, there's an easy route to take - > and so that's what ends up informing those developmer's thought > patterns. > > I think it's possible that if you were to force a new generation to > only be able to iterate once a day, you may end up with a new > generation with that precision. Perhaps material for a fun experiment > for the teachers on the list. > I think it was a confluence of many things. Programs had to be smaller (bigger ones didn't fit). Interactive terminals were non-existant or extremely limited (80x24). Printing out listings and 'desk checking' the output was something you had plenty of time to do. Computing budgets were tiny: You had only so many $$$ for your runs and if you made too many, you'd run out of $$$ before you were done (more applicable as a student than as a professional post school though). Consequently your time was plentiful and computer time was scarce. Plus people from that generation tended to think globally and didn't compartmentalize as much as is done today (where people are told that everything below you in the stack can be considered hardware don't worry about how it works). The systems were also simpler to program, since all the 'go fast' caveats you have to cope with in todays system didn't exists, which also encourage global thinking. Plus, computer programmers tended to be the best and the brightest because they were the only ones that could (a) afford to undertake their study and (b) the only ones that didn't wash out of very demanding university programs. Plus companies tended to only trust their super expensive machines to the best and the brightest, further enhancing their skills (which we now know are built with repetition) while the less bright tended to be relegated to other machines with fewer opportunities. (yes, I know the previous paragraph way over-generalizes a very complex and subtle dynamic that was at play, hence 'tendency' rather than some other more definite word). Warner > Cheers, > > Marshall > > On Tue, Aug 9, 2022 at 3:01 PM Larry McVoy wrote: > > > > On Tue, Aug 09, 2022 at 02:54:08PM -0400, Tom Teixeira wrote: > > > On 8/9/22 2:49 PM, Larry McVoy wrote: > > > >On Tue, Aug 09, 2022 at 01:42:32PM -0400, Noel Chiappa wrote: > > > >> > From: Rob Pike > > > >> > > > >> > I still marvel at the productivity and precision of his > generatio > > > >> > > > >>We noticed the same thing happening in the IETF, as the number of > people > > > >>working on networking went up. The explanation is really quite > simple, once > > > >>you think about it a bit. > > > >> > > > >>If you have a very small group, it is quite possible to have a very > high > > > >>level. (Not if it's selected randomly, of course; there has to be > some > > > >>sorting function.) However, as the group gets much larger, it is > > > >>_necessarily_ much more 'average' in the skill/etc level of its > members. > > > >I used to complain about this at Sun and was dryly told "We get it, > > > >Larry, you are yeast. You need flour to make bread." > > > > > > > >And as time went on, I found that the smart people tended to find each > > > >other. So it was fine. > > > > > > > >It is more fun when it is a highly curated group of smart people. > Made > > > >me work hard to keep up. > > > > > > Put another way, "If you're always the smartest person in the room, > you're > > > spending your time in the wrong rooms." > > > > I was usually the dumbest one in the room, I found the right rooms :-) > > > > I personally like being "dumb", the other people just make you want to > > work harder to reach their level. Back when I used to play pool pretty > > seriously, I always tried to play people better than me. You get lazy > > if you are the best. > > > > -- > > --- > > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Wed Aug 10 06:43:06 2022 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Tue, 9 Aug 2022 15:43:06 -0500 Subject: [TUHS] mainframe $ budgets [was Re: Re: SNOBOL and RATSNO In-Reply-To: References: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> <20220809184910.GC21168@mcvoy.com> <092e2eda-9b02-39a9-9de3-8343cd337d78@earthlink.net> <20220809190028.GD21168@mcvoy.com> Message-ID: Early on in my career at IBM Yorktown, ca. 1976, I was submitting many long running simulation jobs to the 360/91 there. At one point, the head of computer systems (I.T. if you will) wrote to the head of computer sciences (my department) complaining that I had just spent $50K over some short period, asking if this was justified. My management shrugged it off, encouraged me to continue what I was doing. I might still have the letter somewhere. A couple of years later, while on the faculty at U.T. Austin, one of the main budgetary items in research grant proposals was purchase of mini-computers, assuming those were a more efficient use of funds than paying for time at the campus computing center (then using CDC 6600 and successors). COFF? Charlie On 8/9/2022 3:19 PM, Warner Losh wrote: > Computing budgets were tiny: You had only so many $$$ for your runs and > if you made > too many, you'd run out of $$$ before you were done (more applicable as > a student than > as a professional post school though). Consequently your time was > plentiful and > computer time was scarce. -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From marc.donner at gmail.com Wed Aug 10 06:58:49 2022 From: marc.donner at gmail.com (Marc Donner) Date: Tue, 9 Aug 2022 16:58:49 -0400 Subject: [TUHS] mainframe $ budgets [was Re: Re: SNOBOL and RATSNO In-Reply-To: References: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> <20220809184910.GC21168@mcvoy.com> <092e2eda-9b02-39a9-9de3-8343cd337d78@earthlink.net> <20220809190028.GD21168@mcvoy.com> Message-ID: LOL I joined IBM Research in Yorktown in 1978. I was an electrical engineer and one of the first problems I was given was modeling a novel concept for an X-Y touch panel. I realized that the model is basically solving Laplace's equation in the plane. I was not a programmer at the time, so I asked what was the recommended thing for that. I was told APL, so I grabbed a manual and got to work. Within a day or two I had a nice solver working and was getting useful results. (Of course, solving Laplace in the plane by relaxation is the slowest possible way to get to the answer, but I didn't know much about numerical methods back in those days.) The next week I got a visit from the same IT weenies who had bothered you. They told me that in my first week on the job I had managed to be the biggest consumer of CPU cycles on the 370/168 and that I had to learn to program in PL/I because compiled was better than interpreted. It took me several weeks to get it working, since PL/I was such a pain in the neck and I had to learn all sorts of stuff about how numbers were represented in the hardware. Obviously my time was worth less than the computer's. Bleh. ===== nygeek.net mindthegapdialogs.com/home On Tue, Aug 9, 2022 at 4:43 PM Charles H Sauer (he/him) < sauer at technologists.com> wrote: > Early on in my career at IBM Yorktown, ca. 1976, I was submitting many > long running simulation jobs to the 360/91 there. At one point, the head > of computer systems (I.T. if you will) wrote to the head of computer > sciences (my department) complaining that I had just spent $50K over > some short period, asking if this was justified. My management shrugged > it off, encouraged me to continue what I was doing. I might still have > the letter somewhere. > > A couple of years later, while on the faculty at U.T. Austin, one of the > main budgetary items in research grant proposals was purchase of > mini-computers, assuming those were a more efficient use of funds than > paying for time at the campus computing center (then using CDC 6600 and > successors). > > COFF? > > Charlie > > On 8/9/2022 3:19 PM, Warner Losh wrote: > > > Computing budgets were tiny: You had only so many $$$ for your runs and > > if you made > > too many, you'd run out of $$$ before you were done (more applicable as > > a student than > > as a professional post school though). Consequently your time was > > plentiful and > > computer time was scarce. > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/Twitter > : CharlesHSauer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mah at mhorton.net Wed Aug 10 07:09:32 2022 From: mah at mhorton.net (Mary Ann Horton) Date: Tue, 9 Aug 2022 14:09:32 -0700 Subject: [TUHS] Likelihood of Extant Less-Distributed Tapes and Sources In-Reply-To: References: Message-ID: <99f89c2a-5b62-c8fc-825e-edb8ff7b458e@mhorton.net> I'm sure CB-UNIX was developed at CB, e.g. 6200 E Broad, by Dale DeJager's and Tom Cook's team, the Operating Systems Group (cbosg). As Brad aptly describes, there is no hope of finding any old tapes in the CB building. It's been part of Mt. Carmel hospital for years. Thanks, /Mary Ann Horton/ (she/her/ma'am) maryannhorton.com On 8/9/22 08:16, Brad Spencer wrote: > segaloco via TUHS writes: > >> Good morning everyone. Wanted to pose the question since folks here would probably be more likely to know than anyone. >> >> What are the chances that there are surviving tapes of some of the UNIX versions that weren't so well publicized. The versions that come to mind are the CB and USG lines especially, with PWB 2.0 and TS 4.0 getting honorable mention. If folks will recall, we did luck out in that Arnold, a member of this mailing list, did have a documentation trove from TS 4.0, but no binary or source code assets. This had me curious on what trying to unearth these would even look like. >> >> Has anyone tried to dive deep on this sort of stuff before? Would it look more like trying to find old Bell facilities that might have a tape bumping around in a box in a basement somewhere, or is it more likely that if anything survived it would have been due to being nabbed by an employee or contractor before disposal? Or even just in general, what would folks say is the likelihood that there is a recoverable tape of any of this material just waiting to see the light of day? The closest we have on CB is a paper scan of the kernel sources, and I don't know that any assets from USG-proper have ever percolated up, closest thing to any of that would be the kernel routine description bumping around on the archive somewhere. PWB 2.0 is mentioned in several places, but no empirical evidence has surfaced as far as I know, and with 4.0 of course we have the documents Arnold thankfully preserved, but that's it. > [snip] > > I am not sure where CBUNIX was actually developed, but I spent 12 years > at 6200 Broad Street and a tiny bit at 6400 Broad Street and knew folks > who were associated with the Dublin Training center. I didn't do > operating systems development and I did not work on the physical switch > gear, rather I was in one of the many support system products that got > sold to all of the RBOCs and around the world. > > The Broad Street site(s) have been sold off many years ago. All that > remains of 6200 Broad is the front part of the building. The back part, > the factory and much of the high bay area, fell in on itself some years > ago and the rubble was cleared away. The concrete floor still remains. > A hospital system bought the building grounds and much of the rest of > the land was sold off and houses were built and some fast food joints > put in. As far as I can tell 6400 Broad is gone, having been torn down > some time ago. > > My memory isn't clear what happened to Dublin, but around the time of > the Lucent split from AT&T or perhaps during the dark down years that > followed, Dublin ceased to be a thing. I suspect sold a long time ago. > > I would guess that if there is anything left of CBUNIX it would be in a > personal collection of stuff at this point. > > The story of the sale of 6200 is a bit of a mess... the hospital system > actually bought the front part some years before Lucent left the > building completely (Lucent moved their entrance to the east side of the > building). I had an office in the front part of the building and we had > a rush move to cubes that were created in the high bay area in the > middle of the building when the sale was done and over with. Lots and > lots of computers and devices were destroyed during that time as there > was no space to keep them and I am sure that a lot was lost. The 6200 > site had a industrial sized metal compactor and it was not uncommon for > entire 3B2, Sun workstations and probably entire Vax systems would just > be tossed in and smashed (flattened, crushed and shredded). Our group > had a 3B system that was used for simulation work to the product I > worked on and it was marked for destruction by mistake and destroyed out > from under us one day. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Wed Aug 10 07:25:58 2022 From: robpike at gmail.com (Rob Pike) Date: Wed, 10 Aug 2022 07:25:58 +1000 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <1815F4B8-D6B4-4C71-AC05-27D88C1E580D@humeweb.com> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> <20220729050748.GB12246@tau1.ceti.pl> <1815F4B8-D6B4-4C71-AC05-27D88C1E580D@humeweb.com> Message-ID: I think both factors were relevant, as well as the preciousness and pace of it all, as discussed by others here. -rob On Wed, Aug 10, 2022 at 1:15 AM Andrew Hume wrote: > rob, clem: > > has there been a shift in ability? or is this more likely a sampling bias > (because there were so many fewer programmers then)? > > > On Aug 9, 2022, at 6:34 AM, Clem Cole wrote: > > > > On Tue, Aug 9, 2022 at 2:12 AM Rob Pike wrote: > >> >> I still marvel at the productivity and precision of his generation of >> programmers. >> > Amen. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Wed Aug 10 08:18:52 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 9 Aug 2022 18:18:52 -0400 Subject: [TUHS] SNOBOL and RATSNO Message-ID: > I've always believed that pic was so well designed > because it took a day to get the print out (back then), I'm afraid this belief is urban legend. Credit for pic is due 100% to Kernighan, not to the contemporary pace of computing practice. Even in the 1950s, we had one-hour turnaround at Bell Labs. And the leap from batch processing had happened well before pic. Turnaround on modest Unix source files and tests has changed little in the past fifty years. Doug From lm at mcvoy.com Wed Aug 10 08:25:12 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 9 Aug 2022 15:25:12 -0700 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: References: Message-ID: <20220809222512.GG21168@mcvoy.com> On Tue, Aug 09, 2022 at 06:18:52PM -0400, Douglas McIlroy wrote: > > I've always believed that pic was so well designed > > because it took a day to get the print out (back then), > > I'm afraid this belief is urban legend. Credit for pic is due 100% to > Kernighan, not to the contemporary pace of computing practice. Well kudos to Brian then. Pic is one the best designed tools I've ever seen. From sauer at technologists.com Wed Aug 10 08:49:50 2022 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Tue, 9 Aug 2022 17:49:50 -0500 Subject: [TUHS] mainframe $ budgets [was Re: Re: SNOBOL and RATSNO In-Reply-To: References: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> <20220809184910.GC21168@mcvoy.com> <092e2eda-9b02-39a9-9de3-8343cd337d78@earthlink.net> <20220809190028.GD21168@mcvoy.com> Message-ID: And, of course, it should be noted that $50K was significantly more than typical annual salaries for researchers back then. On 8/9/2022 3:58 PM, Marc Donner wrote: > LOL > > I joined IBM Research in Yorktown in 1978.  I was an electrical engineer > and one of the first problems I was given was modeling a novel concept > for an X-Y touch panel.  I realized that the model is basically solving > Laplace's equation in the plane.  I was not a programmer at the time, so > I asked what was the recommended thing for that.  I was told APL, so I > grabbed a manual and got to work. > > Within a day or two I had a nice solver working and was getting useful > results. > > (Of course, solving Laplace in the plane by relaxation is the slowest > possible way to get to the answer, but I didn't know much about > numerical methods back in those days.) > > The next week I got a visit from the same IT weenies who had bothered > you.  They told me that in my first week on the job I had managed to be > the biggest consumer of CPU cycles on the 370/168 and that I had to > learn to program in PL/I because compiled was better than interpreted. > It took me several weeks to get it working, since PL/I was such a pain > in the neck and I had to learn all sorts of stuff about how numbers were > represented in the hardware. > > Obviously my time was worth less than the computer's. > > Bleh. > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Tue, Aug 9, 2022 at 4:43 PM Charles H Sauer (he/him) > > wrote: > > Early on in my career at IBM Yorktown, ca. 1976, I was submitting many > long running simulation jobs to the 360/91 there. At one point, the > head > of computer systems (I.T. if you will) wrote to the head of computer > sciences (my department) complaining that I had just spent $50K over > some short period, asking if this was justified. My management shrugged > it off, encouraged me to continue what I was doing. I might still have > the letter somewhere. > > A couple of years later, while on the faculty at U.T. Austin, one of > the > main budgetary items in research grant proposals was purchase of > mini-computers, assuming those were a more efficient use of funds than > paying for time at the campus computing center (then using CDC 6600 and > successors). > > COFF? > > Charlie > > On 8/9/2022 3:19 PM, Warner Losh wrote: > > > Computing budgets were tiny: You had only so many $$$ for your > runs and > > if you made > > too many, you'd run out of $$$ before you were done (more > applicable as > > a student than > > as a professional post school though). Consequently your time was > > plentiful and > > computer time was scarce. > > -- > voice: +1.512.784.7526       e-mail: sauer at technologists.com > > fax: +1.512.346.5240         Web: https://technologists.com/sauer/ > Facebook/Google/Twitter > : CharlesHSauer > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From hveit01 at web.de Wed Aug 10 20:29:24 2022 From: hveit01 at web.de (Holger Veit) Date: Wed, 10 Aug 2022 12:29:24 +0200 Subject: [TUHS] PCS Munix kernel source Message-ID: <2b4956cb-228c-72db-8f0f-6e9907864b8c@web.de> Hi all, I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to https://github.com/hveit01/pcs-munix. MUNIX was an AT&T SVR3.x implementation for the German PCS Cadmus workstations in the 80's. They were based on Motorola 68020 CPUs on a DEC QBUS. The interesting feature of this kernel is the integration of the Newcastle Connection network (https://en.wikipedia.org/wiki/Newcastle_Connection) which I found, beyond a tech report https://assets.cs.ncl.ac.uk/TRs/175.pdf, no further references for. The kernel source was reverse engineered and verified (see readme in the distribution who this was done) from the binary tape at ftp.informatik.uni-stuttgart.de/pub/cm/pcs/sw/IS0371P.tap (Computer museum of the University of Stuttgart), and to my knowledge reveals the Newcastle connection code for the first time in a commercial Unix. The Github package includes the kernel sources, i/O drivers, several standard libraries, the disassembled boot ROM and for reference, two of my tools, a partial syscall emulator pcsrun which allowed me to run the C compiler and other native binaries outside the PCS hardware/Unix environment, and a disassembler pcsdis for the specific COFF dialect (note that IDA will produce garbage without a specific patch). Regards Holger From arnold at skeeve.com Thu Aug 11 01:05:20 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 10 Aug 2022 09:05:20 -0600 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: References: Message-ID: <202208101505.27AF5Ko7020961@freefriends.org> Hi All. Douglas McIlroy wrote: > > I've always believed that pic was so well designed > > because it took a day to get the print out (back then), > > I'm afraid this belief is urban legend. Credit for pic is due 100% to > Kernighan, not to the contemporary pace of computing practice. I occassionally forward TUHS items (that I think are) of interest to Brian. I have in the past forwarded one of Larry's "I like pic because I can read the code and visualize the picture" emails to him. He responded that he didn't work that way. :-) Here, by permission, is his response to Larry's latest note of that kind, which I think is also of more or less general interest: > Date: Tue, 9 Aug 2022 19:03:00 -0400 (EDT) > From: Brian Kernighan > To: arnold at skeeve.com > Subject: Re: larry mcvoy on pic, again > > I don't know that I would read too much into the development of > Pic, though my memory is so dim that it would all be made up > anyway. > > One observation: with Yacc and Lex available, languages were a lot > easier to implement; I had already done a troff preprocessor so > that aspect was well in hand. And I was actually the owner of > troff at the same time, so I could mix and match (e.g., the > primitives for drawing lines). I think that "seeing the output" > wasn't too hard, either because I could use the typesetter, or the > Tectronix 4014 (?) for which there was a troff output emulator > that I think I wrote. > > The main issues as I recall were figuring out coordinate systems, > since Pic had Y going positive as with conventional plotting, > while troff had it going negative (down the page is higher Y > values). > > But it's all kind of fuzzy at this point. From imp at bsdimp.com Thu Aug 11 02:12:04 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 10 Aug 2022 10:12:04 -0600 Subject: [TUHS] PCS Munix kernel source In-Reply-To: <2b4956cb-228c-72db-8f0f-6e9907864b8c@web.de> References: <2b4956cb-228c-72db-8f0f-6e9907864b8c@web.de> Message-ID: On Wed, Aug 10, 2022 at 4:29 AM Holger Veit wrote: > Hi all, > > I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to > https://github.com/hveit01/pcs-munix. > This is really cool! > MUNIX was an AT&T SVR3.x implementation for the German PCS Cadmus > workstations in the 80's. They were > based on Motorola 68020 CPUs on a DEC QBUS. > Fun times that combination... > The interesting feature of this kernel is the integration of the > Newcastle Connection network > (https://en.wikipedia.org/wiki/Newcastle_Connection) which I found, > beyond a tech report https://assets.cs.ncl.ac.uk/TRs/175.pdf, no further > references for. > > The kernel source was reverse engineered and verified (see readme in the > distribution who this was done) from the binary tape at > ftp.informatik.uni-stuttgart.de/pub/cm/pcs/sw/IS0371P.tap (Computer > museum of the University of Stuttgart), and to my knowledge reveals the > Newcastle connection code for the first time in a commercial Unix. > > The Github package includes the kernel sources, i/O drivers, several > standard libraries, the disassembled boot ROM and for reference, two of > my tools, a partial syscall emulator pcsrun which allowed me to run the > C compiler and other native binaries outside the PCS hardware/Unix > environment, and a disassembler pcsdis for the specific COFF dialect > (note that IDA will produce garbage without a specific patch). > I love it. This is quite similar, though further along, than my on-again off-again efforts to do the same with Venix 86/R for my Rainbow... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Aug 11 03:14:17 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 10 Aug 2022 10:14:17 -0700 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <202208101505.27AF5Ko7020961@freefriends.org> References: <202208101505.27AF5Ko7020961@freefriends.org> Message-ID: <20220810171417.GY21168@mcvoy.com> Well, I stand behind my comments. Take a look at what xfig(1) produces and contrast that with even an average pic(1) source file. You can't see what xfig is saying but you can easily see what pic is saying. Maybe people just haven't written much pic, but what you can do with it, and see without rendering it, is pretty amazing. I got James Clark to add the 'i'th concept so you could do for loops to lay out elements and I wrote a pic script where you could set variables like cpus, networks, disks and it would draw different configurations of a SPARCcluster. Pic is pretty neat, I find it easier to read than any of the other troff preprocessors. On Wed, Aug 10, 2022 at 09:05:20AM -0600, arnold at skeeve.com wrote: > Hi All. > > Douglas McIlroy wrote: > > > > I've always believed that pic was so well designed > > > because it took a day to get the print out (back then), > > > > I'm afraid this belief is urban legend. Credit for pic is due 100% to > > Kernighan, not to the contemporary pace of computing practice. > > I occassionally forward TUHS items (that I think are) of interest > to Brian. I have in the past forwarded one of Larry's "I like pic > because I can read the code and visualize the picture" emails to > him. He responded that he didn't work that way. :-) > > Here, by permission, is his response to Larry's latest note of > that kind, which I think is also of more or less general interest: > > > Date: Tue, 9 Aug 2022 19:03:00 -0400 (EDT) > > From: Brian Kernighan > > To: arnold at skeeve.com > > Subject: Re: larry mcvoy on pic, again > > > > I don't know that I would read too much into the development of > > Pic, though my memory is so dim that it would all be made up > > anyway. > > > > One observation: with Yacc and Lex available, languages were a lot > > easier to implement; I had already done a troff preprocessor so > > that aspect was well in hand. And I was actually the owner of > > troff at the same time, so I could mix and match (e.g., the > > primitives for drawing lines). I think that "seeing the output" > > wasn't too hard, either because I could use the typesetter, or the > > Tectronix 4014 (?) for which there was a troff output emulator > > that I think I wrote. > > > > The main issues as I recall were figuring out coordinate systems, > > since Pic had Y going positive as with conventional plotting, > > while troff had it going negative (down the page is higher Y > > values). > > > > But it's all kind of fuzzy at this point. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From emu at e-bbes.com Thu Aug 11 03:15:14 2022 From: emu at e-bbes.com (emanuel stiebler) Date: Wed, 10 Aug 2022 13:15:14 -0400 Subject: [TUHS] PCS Munix kernel source In-Reply-To: <2b4956cb-228c-72db-8f0f-6e9907864b8c@web.de> References: <2b4956cb-228c-72db-8f0f-6e9907864b8c@web.de> Message-ID: On 2022-08-10 06:29, Holger Veit wrote: > Hi all, > > I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to > https://github.com/hveit01/pcs-munix. > > MUNIX was an AT&T SVR3.x implementation for the German PCS Cadmus > workstations in the 80's. They were > based on Motorola 68020 CPUs on a DEC QBUS. Great little machines, and nice graphics options. I loved working on them. Thanks for sharing! From arnold at skeeve.com Thu Aug 11 03:37:56 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 10 Aug 2022 11:37:56 -0600 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <20220810171417.GY21168@mcvoy.com> References: <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> Message-ID: <202208101737.27AHbupN011923@freefriends.org> Oh, I'm not arguing with any of this. I'm merely noting that you are unusual in your ability to easily visualize pic results from looking at the code. Arnold Larry McVoy wrote: > Well, I stand behind my comments. Take a look at what xfig(1) > produces and contrast that with even an average pic(1) source > file. You can't see what xfig is saying but you can easily see > what pic is saying. > > Maybe people just haven't written much pic, but what you can do > with it, and see without rendering it, is pretty amazing. > > I got James Clark to add the 'i'th concept so you could do for > loops to lay out elements and I wrote a pic script where you > could set variables like cpus, networks, disks and it would > draw different configurations of a SPARCcluster. > > Pic is pretty neat, I find it easier to read than any of the > other troff preprocessors. > > On Wed, Aug 10, 2022 at 09:05:20AM -0600, arnold at skeeve.com wrote: > > Hi All. > > > > Douglas McIlroy wrote: > > > > > > I've always believed that pic was so well designed > > > > because it took a day to get the print out (back then), > > > > > > I'm afraid this belief is urban legend. Credit for pic is due 100% to > > > Kernighan, not to the contemporary pace of computing practice. > > > > I occassionally forward TUHS items (that I think are) of interest > > to Brian. I have in the past forwarded one of Larry's "I like pic > > because I can read the code and visualize the picture" emails to > > him. He responded that he didn't work that way. :-) > > > > Here, by permission, is his response to Larry's latest note of > > that kind, which I think is also of more or less general interest: > > > > > Date: Tue, 9 Aug 2022 19:03:00 -0400 (EDT) > > > From: Brian Kernighan > > > To: arnold at skeeve.com > > > Subject: Re: larry mcvoy on pic, again > > > > > > I don't know that I would read too much into the development of > > > Pic, though my memory is so dim that it would all be made up > > > anyway. > > > > > > One observation: with Yacc and Lex available, languages were a lot > > > easier to implement; I had already done a troff preprocessor so > > > that aspect was well in hand. And I was actually the owner of > > > troff at the same time, so I could mix and match (e.g., the > > > primitives for drawing lines). I think that "seeing the output" > > > wasn't too hard, either because I could use the typesetter, or the > > > Tectronix 4014 (?) for which there was a troff output emulator > > > that I think I wrote. > > > > > > The main issues as I recall were figuring out coordinate systems, > > > since Pic had Y going positive as with conventional plotting, > > > while troff had it going negative (down the page is higher Y > > > values). > > > > > > But it's all kind of fuzzy at this point. > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From jon at fourwinds.com Thu Aug 11 03:44:32 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 10 Aug 2022 10:44:32 -0700 Subject: [TUHS] SNOBOL and RATSNO [ really pic ] In-Reply-To: <202208101737.27AHbupN011923@freefriends.org> References: <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> Message-ID: <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> arnold at skeeve.com writes: > Oh, I'm not arguing with any of this. I'm merely noting that > you are unusual in your ability to easily visualize pic results > from looking at the code. Not at all. I'm a big fan of pic too. And I've written preprocessors for it, such as one that generated GANTT charts. To me, the best feature of pic is invisible elements. As Larry pointed out, xfig uses absolute coordinates and is a mess. When I use pic, I usually start out with a big invisible box and hang things off of it. That makes it trivial to do things like shrinking or growing just by changing the invisible box size. In my opinion, the biggest failing of pic comes from the one-way connection to troff. It's really hard to do things like "box that fits this text". Jon From lm at mcvoy.com Thu Aug 11 04:02:10 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 10 Aug 2022 11:02:10 -0700 Subject: [TUHS] SNOBOL and RATSNO [ really pic ] In-Reply-To: <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> References: <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> Message-ID: <20220810180210.GZ21168@mcvoy.com> On Wed, Aug 10, 2022 at 10:44:32AM -0700, Jon Steinhart wrote: > arnold at skeeve.com writes: > > Oh, I'm not arguing with any of this. I'm merely noting that > > you are unusual in your ability to easily visualize pic results > > from looking at the code. > > Not at all. I'm a big fan of pic too. And I've written preprocessors > for it, such as one that generated GANTT charts. > > To me, the best feature of pic is invisible elements. As Larry pointed > out, xfig uses absolute coordinates and is a mess. When I use pic, I > usually start out with a big invisible box and hang things off of it. > That makes it trivial to do things like shrinking or growing just by > changing the invisible box size. > > In my opinion, the biggest failing of pic comes from the one-way connection > to troff. It's really hard to do things like "box that fits this text". Jon gets it, I'm not the only one. I do the same thing with a big invisble box, it gives you a mental place to place things. Also agree with the "box that fits this text" problem, pic really could use a sizeof("this text in the current font/point size/line spacing") that returns x,y. But I don't see how to do that because pic doesn't have that info, pic would need to be able to ask troff what those are. Oh, and I've written my own crappy version of grap(1) that spits out pic, it was pretty easy. So at least Jon sees pic like I do and I suspect there are plenty more who do as well. Spend some time writing some pic scripts and I suspect anyone can get good at seeing what it is doing. It's a super pleasant little language. From jon at fourwinds.com Thu Aug 11 04:04:31 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 10 Aug 2022 11:04:31 -0700 Subject: [TUHS] SNOBOL and RATSNO [ really pic ] In-Reply-To: <20220810180210.GZ21168@mcvoy.com> References: <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> <20220810180210.GZ21168@mcvoy.com> Message-ID: <202208101804.27AI4VkB1221117@darkstar.fourwinds.com> Larry McVoy writes: > Jon gets it, I'm not the only one. I do the same thing with a big > invisble box, it gives you a mental place to place things. > > Also agree with the "box that fits this text" problem, pic really could > use a sizeof("this text in the current font/point size/line spacing") > that returns x,y. But I don't see how to do that because pic doesn't > have that info, pic would need to be able to ask troff what those are. > > Oh, and I've written my own crappy version of grap(1) that spits out > pic, it was pretty easy. > > So at least Jon sees pic like I do and I suspect there are plenty more > who do as well. Spend some time writing some pic scripts and I suspect > anyone can get good at seeing what it is doing. It's a super pleasant > little language. Stop being so agreeable, go fishing or something :-) Might have mentioned this before, but I have a toolchain for converting pic to SVG as that's the only vector format that can be included in word documents. From michael at kjorling.se Thu Aug 11 04:13:44 2022 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 10 Aug 2022 18:13:44 +0000 Subject: [TUHS] pic In-Reply-To: <202208101804.27AI4VkB1221117@darkstar.fourwinds.com> References: <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> <20220810180210.GZ21168@mcvoy.com> <202208101804.27AI4VkB1221117@darkstar.fourwinds.com> Message-ID: <0f770026-f894-45bf-ad99-b7f3eb5af311@home.arpa> On 10 Aug 2022 11:04 -0700, from jon at fourwinds.com (Jon Steinhart): > Might have mentioned this before, but I have a toolchain for converting > pic to SVG as that's the only vector format that can be included in word > documents. Would that happen to be available somewhere, for posterity? -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From drb at msu.edu Thu Aug 11 04:19:11 2022 From: drb at msu.edu (Dennis Boone) Date: Wed, 10 Aug 2022 14:19:11 -0400 Subject: [TUHS] pic In-Reply-To: (Your message of Wed, 10 Aug 2022 18:13:44 -0000.) <0f770026-f894-45bf-ad99-b7f3eb5af311@home.arpa> References: <0f770026-f894-45bf-ad99-b7f3eb5af311@home.arpa> <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> <20220810180210.GZ21168@mcvoy.com> <202208101804.27AI4VkB1221117@darkstar.fourwinds.com> Message-ID: <20220810181911.50EEB3EE724@yagi.h-net.msu.edu> > Would that happen to be available somewhere, for posterity? pic2plot, from the plotutils package, will do pic -> various formats, including svg. De From jon at fourwinds.com Thu Aug 11 04:24:26 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 10 Aug 2022 11:24:26 -0700 Subject: [TUHS] pic In-Reply-To: <20220810181911.50EEB3EE724@yagi.h-net.msu.edu> References: <0f770026-f894-45bf-ad99-b7f3eb5af311@home.arpa> <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> <20220810180210.GZ21168@mcvoy.com> <202208101804.27AI4VkB1221117@darkstar.fourwinds.com> <20220810181911.50EEB3EE724@yagi.h-net.msu.edu> Message-ID: <202208101824.27AIOQG81222103@darkstar.fourwinds.com> Dennis Boone writes: > > Would that happen to be available somewhere, for posterity? > > pic2plot, from the plotutils package, will do pic -> various formats, > including svg. Huh. Wasn't aware of that one, but seems to rely on a groff svg driver which I've never seen. What I've done is pic -> groff -> ps2pdf -> pdf2svg -> inkscape. Inkscape is used just to crop bounding box to the image size so that there's not a huge amount of whitespace. From joe at via.net Thu Aug 11 04:24:09 2022 From: joe at via.net (joe mcguckin) Date: Wed, 10 Aug 2022 11:24:09 -0700 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <202208101737.27AHbupN011923@freefriends.org> References: <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> Message-ID: <55D3A193-2CD3-4876-9D43-65F3D6FEAC86@via.net> I used to work for a computer manufacturer that was nearly dead - lots of cubicles piled full of junk. The reference manuals had these very nice diagrams of the computer boards detailing the connectors on the board edges. Imagine my surprise when I discovered all the artwork was PIC generated… Joe Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Aug 10, 2022, at 10:37 AM, arnold at skeeve.com wrote: > > Oh, I'm not arguing with any of this. I'm merely noting that > you are unusual in your ability to easily visualize pic results > from looking at the code. > > Arnold > > Larry McVoy wrote: > >> Well, I stand behind my comments. Take a look at what xfig(1) >> produces and contrast that with even an average pic(1) source >> file. You can't see what xfig is saying but you can easily see >> what pic is saying. >> >> Maybe people just haven't written much pic, but what you can do >> with it, and see without rendering it, is pretty amazing. >> >> I got James Clark to add the 'i'th concept so you could do for >> loops to lay out elements and I wrote a pic script where you >> could set variables like cpus, networks, disks and it would >> draw different configurations of a SPARCcluster. >> >> Pic is pretty neat, I find it easier to read than any of the >> other troff preprocessors. >> >> On Wed, Aug 10, 2022 at 09:05:20AM -0600, arnold at skeeve.com wrote: >>> Hi All. >>> >>> Douglas McIlroy wrote: >>> >>>>> I've always believed that pic was so well designed >>>>> because it took a day to get the print out (back then), >>>> >>>> I'm afraid this belief is urban legend. Credit for pic is due 100% to >>>> Kernighan, not to the contemporary pace of computing practice. >>> >>> I occassionally forward TUHS items (that I think are) of interest >>> to Brian. I have in the past forwarded one of Larry's "I like pic >>> because I can read the code and visualize the picture" emails to >>> him. He responded that he didn't work that way. :-) >>> >>> Here, by permission, is his response to Larry's latest note of >>> that kind, which I think is also of more or less general interest: >>> >>>> Date: Tue, 9 Aug 2022 19:03:00 -0400 (EDT) >>>> From: Brian Kernighan >>>> To: arnold at skeeve.com >>>> Subject: Re: larry mcvoy on pic, again >>>> >>>> I don't know that I would read too much into the development of >>>> Pic, though my memory is so dim that it would all be made up >>>> anyway. >>>> >>>> One observation: with Yacc and Lex available, languages were a lot >>>> easier to implement; I had already done a troff preprocessor so >>>> that aspect was well in hand. And I was actually the owner of >>>> troff at the same time, so I could mix and match (e.g., the >>>> primitives for drawing lines). I think that "seeing the output" >>>> wasn't too hard, either because I could use the typesetter, or the >>>> Tectronix 4014 (?) for which there was a troff output emulator >>>> that I think I wrote. >>>> >>>> The main issues as I recall were figuring out coordinate systems, >>>> since Pic had Y going positive as with conventional plotting, >>>> while troff had it going negative (down the page is higher Y >>>> values). >>>> >>>> But it's all kind of fuzzy at this point. >> >> -- >> --- >> Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat -------------- next part -------------- An HTML attachment was scrubbed... URL: From ches at cheswick.com Thu Aug 11 07:13:02 2022 From: ches at cheswick.com (Bill Cheswick) Date: Wed, 10 Aug 2022 17:13:02 -0400 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> References: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> Message-ID: “The trouble with folk songs is thst they are written by the people.” -Tom Lehrer. Ches > On Aug 9, 2022, at 13:42, jnc at mercury.lcs.mit.edu wrote: > > However, as the group gets much larger, it is > _necessarily_ much more 'average' in the skill/etc level of its members. From cowan at ccil.org Thu Aug 11 07:30:51 2022 From: cowan at ccil.org (John Cowan) Date: Wed, 10 Aug 2022 17:30:51 -0400 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: References: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> Message-ID: On Wed, Aug 10, 2022 at 5:13 PM Bill Cheswick wrote: > “The trouble with folk songs is thst they are written by the people.” -Tom > Lehrer. Lehrer's songs, especially "The Periodic Table", have now become subject to the folk process themselves. "Goldilocks and the Three Bears" was originally written by the Romantic poet Robert Southey, although in his version the bears' antagonist was a "wicked old woman". -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Aug 11 10:10:57 2022 From: crossd at gmail.com (Dan Cross) Date: Wed, 10 Aug 2022 20:10:57 -0400 Subject: [TUHS] pic In-Reply-To: <202208101824.27AIOQG81222103@darkstar.fourwinds.com> References: <0f770026-f894-45bf-ad99-b7f3eb5af311@home.arpa> <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> <20220810180210.GZ21168@mcvoy.com> <202208101804.27AI4VkB1221117@darkstar.fourwinds.com> <20220810181911.50EEB3EE724@yagi.h-net.msu.edu> <202208101824.27AIOQG81222103@darkstar.fourwinds.com> Message-ID: On Wed, Aug 10, 2022 at 2:24 PM Jon Steinhart wrote: > Dennis Boone writes: > > > Would that happen to be available somewhere, for posterity? > > > > pic2plot, from the plotutils package, will do pic -> various formats, > > including svg. > > Huh. Wasn't aware of that one, but seems to rely on a groff svg driver > which I've never seen. > > What I've done is pic -> groff -> ps2pdf -> pdf2svg -> inkscape. > Inkscape is used just to crop bounding box to the image size so > that there's not a huge amount of whitespace. Google has built an in-house documentation system based on extended markdown, and it was very nice: check your text markdown files into a specially-named subdirectory in the monorepo and point a web browser at an internal service for a nicely rendered web version, available immediately. There was a syntax for including graphviz markup, and something similar for (I think) state diagrams, but support for more general drawing was missing, and I thought pic(1) would be just dandy, if it could be persuaded to generate SVG. I wrote to Brian, who works part-time at Google, and pitched the idea to him, and he extended pic to generate SVG, though it wasn't clear to what sources he was modifying, exactly. Then the pandemic hit, and I ended up leaving Google, so I don't think it went beyond that, but IIRC he said that coercing pic to generate SVG wasn't particularly difficult. - Dan C. From tuhs at tuhs.org Thu Aug 11 16:04:30 2022 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Thu, 11 Aug 2022 08:04:30 +0200 Subject: [TUHS] PCS Munix kernel source Message-ID: > Message: 4 > Date: Wed, 10 Aug 2022 12:29:24 +0200 > From: Holger Veit > Subject: [TUHS] PCS Munix kernel source > > Hi all, > > I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to > https://github.com/hveit01/pcs-munix. Thank you for sharing this work, most impressive! > MUNIX was an AT&T SVR3.x implementation ... Are you sure? Could it perhaps be SVR2? (I don’t see any STREAMS stuff that one would expect for R3). > The interesting feature of this kernel is the integration of the > Newcastle Connection network One of my interests is Unix (packet) networking 1975-1985 and that includes Newcastle Connection. I’ve so far not dived deep into this, but your work may be the trigger for some further investigation. My understanding so far (from reading the paper a few years ago) is that Newcastle Connection works at the level of libc, substituting system calls like open() and exec() with library routines that scan the path, and if it is a network path invokes user mode routines that use remote procedure calls to give the illusion of a networked kernel. I’ve briefly looked at the Git repo, but I do not see that structure in the code. Could you elaborate a bit more on how Newcastle Connection operates in this kernel? Happy to communicate off-list if it goes in too much detail. I note that the repo Readme says that the kernel only does some basic IP networking as a carrier, but I also see some files in the tree that seem to implement a form of tcp (and that seem unrelated to the early Unix tcp/ip’s that I have seen so far). Or am I reading too much into these files? === Re-reading the Newcastle Connection paper also brought up some citations from Bell Labs work that seems to have been lost. There is a reference to “RIDE” which appears to be a system similar to Newcastle Connection. The RIDE paper is from 1979 and it mentions that RIDE is a Datakit re-implementation of earlier an earlier system that ran on Spider. Any recollections about these things among the TUHS readership? The other citation is for J. C. Kaufeld and D. L. Russell, "Distributed UNIX System", in Workshop on Fundamental Issues in Distributed Computing, ACM SIGOPS and SIGPLAN (15-17 Dec. 1980). It seems contemporaneous with the Luderer/Marshall/Chu work on S/F-Unix. I could not find this paper so far. Here, too, any recollections about this distributed Unix among the TUHS readership? From ralph at inputplus.co.uk Thu Aug 11 17:37:45 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 11 Aug 2022 08:37:45 +0100 Subject: [TUHS] pic's One-way Information Flow. (Was: SNOBOL and RATSNO) In-Reply-To: <20220810180210.GZ21168@mcvoy.com> References: <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> <20220810180210.GZ21168@mcvoy.com> Message-ID: <20220811073745.848C2218D8@orac.inputplus.co.uk> Hi Larry, > Also agree with the "box that fits this text" problem, pic really > could use a sizeof("this text in the current font/point size/line > spacing") that returns x,y. But I don't see how to do that because > pic doesn't have that info, pic would need to be able to ask troff > what those are. Rather than work out the coordinates of everything, could pic punt some of that downstream to troff by producing expressions which rest on variables set by troff to, say, the width of a diversion. The order of evaluation presented to troff would obviously have to be topological on the dependencies which bars cycles. It would add elasticity to a drawing. The other approach would be a multi-pass effort where pic initially assumes unknown dimensions, like some text's width, but also outputs troff which will store the actual width for input to pic on future runs. -- Cheers, Ralph. From hveit01 at web.de Thu Aug 11 19:01:16 2022 From: hveit01 at web.de (Holger Veit) Date: Thu, 11 Aug 2022 11:01:16 +0200 Subject: [TUHS] PCS Munix kernel source In-Reply-To: References: Message-ID: Am 11.08.2022 um 08:04 schrieb Paul Ruizendaal: > MUNIX was an AT&T SVR3.x implementation ... > Are you sure? Could it perhaps be SVR2? (I don’t see any STREAMS stuff that one would expect for R3). It is a hybrid system. I found files and similarities in R1, R2 as well as R3 - the C compiler (in my queue) for instance is likely derived (and heavily modified) from a R1 origin, but in this version itself linked with a C library where parts are newer, namely from a later released version (in the update 3-3.1 in tape IS0463P) which I'll add in the future. I am sure that the kernel libs will then reveal the missing streams stuff. I think it was a rolling release which also still contains parts of the older 16 bit MUNIX for a 68010 with Motorolas FFP lib - the kernel still contains an obsolete module named m68341 which emulates an incompatible floating point lib. The 32 bit system here demands a 68020/68881 combination. There are also several QBUS I/O drivers which seem to stem from the 16 bit systems which likely do no longer access real existing hardware because the newer systems used a communication controller board named ICC with an own 68010 processor and a highly stripped down tailored UNIX (?) on it. This is also on my to-do list. @readers of TUHS: can anyone say something about m68341? There are Motorola FFP libs elsewhere on the net, but this appears to be a complete copro emulation which intercepts the line-F interrupt which I could not locate so far. Internally, it is pretty much optimized - I doubt it was cooked at PCS itself, so it is likely a Motorola product. And no, it has absolutely nothing to do with the embedded controller MC68341. Currently I am dissecting the also rather unique a68 assembler which is a modified Trix/Mical assembler; after that, I'll look into the IS0463P update. >> The interesting feature of this kernel is the integration of the >> Newcastle Connection network > One of my interests is Unix (packet) networking 1975-1985 and that includes Newcastle Connection. I’ve so far not dived deep into this, but your work may be the trigger for some further investigation. > > My understanding so far (from reading the paper a few years ago) is that Newcastle Connection works at the level of libc, substituting system calls like open() and exec() with library routines that scan the path, and if it is a network path invokes user mode routines that use remote procedure calls to give the illusion of a networked kernel. I’ve briefly looked at the Git repo, but I do not see that structure in the code. Could you elaborate a bit more on how Newcastle Connection operates in this kernel? Happy to communicate off-list if it goes in too much detail. Maybe the original NC did so, but here there are numerous additions to the kernel, including a new syscall uipacket() which is the gateway into the MUNET/NC implementation. Stuff is in /usr/sys/munet, the low level networking is in uipacket.c and uiswtch.c which will process RPC open/close/read/write/exec etc. calls, as well support master and diskless nodes). The OS code is full of "if (master) {...} else {...}' code which then redirects detected access to remote paths to the network handler. > > I note that the repo Readme says that the kernel only does some basic IP networking as a carrier, but I also see some files in the tree that seem to implement a form of tcp (and that seem unrelated to the early Unix tcp/ip’s that I have seen so far). Or am I reading too much into these files? > > === > > Re-reading the Newcastle Connection paper also brought up some citations from Bell Labs work that seems to have been lost. There is a reference to “RIDE” which appears to be a system similar to Newcastle Connection. The RIDE paper is from 1979 and it mentions that RIDE is a Datakit re-implementation of earlier an earlier system that ran on Spider. Any recollections about these things among the TUHS readership? > > The other citation is for J. C. Kaufeld and D. L. Russell, "Distributed UNIX System", in Workshop on Fundamental Issues in Distributed Computing, ACM SIGOPS and SIGPLAN (15-17 Dec. 1980). It seems contemporaneous with the Luderer/Marshall/Chu work on S/F-Unix. I could not find this paper so far. Here, too, any recollections about this distributed Unix among the TUHS readership? Good to mention this. I am interested in such stuff as well. Regards Holger From arnold at skeeve.com Thu Aug 11 22:13:23 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 11 Aug 2022 06:13:23 -0600 Subject: [TUHS] pic In-Reply-To: References: <0f770026-f894-45bf-ad99-b7f3eb5af311@home.arpa> <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> <20220810180210.GZ21168@mcvoy.com> <202208101804.27AI4VkB1221117@darkstar.fourwinds.com> <20220810181911.50EEB3EE724@yagi.h-net.msu.edu> <202208101824.27AIOQG81222103@darkstar.fourwinds.com> Message-ID: <202208111213.27BCDOfi019865@freefriends.org> Dan Cross wrote: > I wrote to Brian, who works part-time at Google, and > pitched the idea to him, and he extended pic to > generate SVG, though it wasn't clear to what sources > he was modifying, exactly. Then the pandemic hit, and > I ended up leaving Google, so I don't think it went > beyond that, but IIRC he said that coercing pic to > generate SVG wasn't particularly difficult. I'm sure he'd have been messing with his own sources. These days it'd be best to tr to get new features into GNU pic (IMHO, of course). Arnold From beebe at math.utah.edu Thu Aug 11 23:32:14 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu, 11 Aug 2022 07:32:14 -0600 Subject: [TUHS] PCS Munix kernel source In-Reply-To: Message-ID: Paul Ruizendaal writes on the TUHS list today: >> ... >> ... the Luderer/Marshall/Chu work on S/F-Unix. I could not find this >> paper so far. Here, too, any recollections about this distributed Unix >> among the TUHS readership? >> ... Is this the sought paper?: @String{j-OPER-SYS-REV = "Operating Systems Review"} @Article{Luderer:1981:DUS, author = "G. W. R. Luderer and H. Che and J. P. Haggerty and P. A. Kirslis and W. T. Marshall", title = "A distributed {UNIX} system based on a virtual circuit switch", journal = j-OPER-SYS-REV, volume = "15", number = "5", pages = "160--168", month = dec, year = "1981", CODEN = "OSRED8", ISSN = "0163-5980 (print), 1943-586X (electronic)", ISSN-L = "0163-5980", bibdate = "Sat Aug 26 08:55:53 MDT 2006", bibsource = "http://portal.acm.org/; http://www.math.utah.edu/pub/tex/bib/unix.bib", acknowledgement = ack-nhfb, fjournal = "ACM SIGOPS Operating Systems Review", journal-URL = "http://portal.acm.org/browse_dl.cfm?idx=J597", } ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From crossd at gmail.com Fri Aug 12 00:34:50 2022 From: crossd at gmail.com (Dan Cross) Date: Thu, 11 Aug 2022 10:34:50 -0400 Subject: [TUHS] pic In-Reply-To: <202208111213.27BCDOfi019865@freefriends.org> References: <0f770026-f894-45bf-ad99-b7f3eb5af311@home.arpa> <202208101505.27AF5Ko7020961@freefriends.org> <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> <20220810180210.GZ21168@mcvoy.com> <202208101804.27AI4VkB1221117@darkstar.fourwinds.com> <20220810181911.50EEB3EE724@yagi.h-net.msu.edu> <202208101824.27AIOQG81222103@darkstar.fourwinds.com> <202208111213.27BCDOfi019865@freefriends.org> Message-ID: On Thu, Aug 11, 2022 at 8:13 AM wrote: > Dan Cross wrote: > > I wrote to Brian, who works part-time at Google, and > > pitched the idea to him, and he extended pic to > > generate SVG, though it wasn't clear to what sources > > he was modifying, exactly. Then the pandemic hit, and > > I ended up leaving Google, so I don't think it went > > beyond that, but IIRC he said that coercing pic to > > generate SVG wasn't particularly difficult. > > I'm sure he'd have been messing with his own sources. These > days it'd be best to tr to get new features into GNU pic > (IMHO, of course). Oh surely. I just don't know what sources those would be, exactly; presumably some derivative he's been shepherded all these years? I wonder what it is.... - Dan C. From marc.donner at gmail.com Fri Aug 12 02:08:39 2022 From: marc.donner at gmail.com (Marc Donner) Date: Thu, 11 Aug 2022 12:08:39 -0400 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: References: <20220809174232.A882C18C08A@mercury.lcs.mit.edu> Message-ID: Here's your blackmail video: https://www.youtube.com/watch?v=02N_UOmT8Kk&t=2s ===== nygeek.net mindthegapdialogs.com/home On Wed, Aug 10, 2022 at 5:32 PM John Cowan wrote: > > > On Wed, Aug 10, 2022 at 5:13 PM Bill Cheswick wrote: > >> “The trouble with folk songs is thst they are written by the people.” >> -Tom Lehrer. > > > Lehrer's songs, especially "The Periodic Table", have now become subject > to the folk process themselves. "Goldilocks and the Three Bears" was > originally written by the Romantic poet Robert Southey, although in his > version the bears' antagonist was a "wicked old woman". > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Aug 12 11:33:12 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 12 Aug 2022 01:33:12 +0000 Subject: [TUHS] Documents for UNIX Collections Message-ID: And I've received the documents! This is a pastebin with the rough contents of the documentation package. https://pastebin.com/jAqqBXA4 Now for some analysis: The User's Manual is branded System V but also displays a Western Electric Bell logo. I've seen Release 5.0 manuals displaying the Bell logo and System V manuals without, but never a System V with. That implies the publication of the manual had to change a few times, one to switch from internal Release 5.0 to commercial System V and another time to remove the Bell logo due to divestiture. I would have to wonder if similar transition can be seen with different revisions of these documents? The Release Description manual has a list of System V relevant documents and they all appear to be accounted for here, so this should represent the wealth of documentation available to a user of System V Gold in 1983. Most documents are traceable to documents in the Unix 4.0 collection. I've suffixed various documents here with the coordinate to the same in the 4.0 collection. Changes of note: - The System V documentation includes instructions for 3B20S machines as well as the instructions for DEC equipment. PDP-11 and VAX guidance have been combined into a single document. - The System V documentation adds documents concerning an "Auto Call" feature. Didn't see this anywhere in 4.0, so should be new circa System V. - This documentation refers to the last version as System III rather than making any mention of 4.0. Given that the specific documents mentioning this are System V-branded, and there are comparable documents that are Release 5.0 branded, this implies there may be a document floating around out there somewhere equivalent to the Release Description manual but that actually covers the transition from 4.0 to 5.0. - The documentation package drops the updated CACM paper, likely because it's available all sorts of other places. - The summary and documentation roadmap documents appear to have been synthesized and combined into the Release Description. - Snyder and Mashey's shell tutorial was either dropped or combined with Bourne's shell introduction - No evidence of an MM foldout like was distributed with 4.0 (and before, there are sources around implying these foldouts started with the PWB group, may have been printed as early as 1977) - Either the original EQN paper is dropped or relevant bits mashed together with the user's guide - EFL documentation seems to be dropped, or is merged into one of the other Fortran documents somewhere down in there. The processor is still in the man pages though. - ADB documentation seems to be dropped, likewise still in the manuals, listed as DEC only. Since System V seems to treat DEC as PDP-11+VAX, does this imply there was a VAX ADB? My understanding is SDB started on 32V and was *the* debugger for VAX. - Unix Virtual Protocol papers are dropped, they were marked as 3.0 only in the 4.0 manuals anyhow, so probably not relevant. - The Standalone I/O Library and SASH (Shell) paper is dropped - None of the internals nor security papers seem to have made it, so no Unix Implemention, I/O Implementation, PDP and Portable C Compiler Tours, Assembler Manual, PDP-11/23 and 11/34, or Password Security papers. These will likely be a slower burn than the 4.0 documents since I purchased them myself and am not in a hurry to get them shipped back to someone. That said, if there's anything in the above pastebin that particularly piques any interest, I can try to move those to the top of the stack and get scans done sooner rather than later. I'll also be doing some analysis between these and the 4.0 docs to try and better determine authorship of various documents, my hope is to have a pretty clear picture of whos work went into each manual by the time I'm done with it all. - Matt G. From g.branden.robinson at gmail.com Fri Aug 12 11:52:55 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Thu, 11 Aug 2022 20:52:55 -0500 Subject: [TUHS] pic In-Reply-To: References: <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> <20220810180210.GZ21168@mcvoy.com> <202208101804.27AI4VkB1221117@darkstar.fourwinds.com> <20220810181911.50EEB3EE724@yagi.h-net.msu.edu> <202208101824.27AIOQG81222103@darkstar.fourwinds.com> <202208111213.27BCDOfi019865@freefriends.org> Message-ID: <20220812015255.5mexb5ndknnzlhms@illithid> [looping in groff list] At 2022-08-11T10:34:50-0400, Dan Cross wrote: > On Thu, Aug 11, 2022 at 8:13 AM wrote: > > Dan Cross wrote: > > > I wrote to Brian, who works part-time at Google, and pitched the > > > idea to him, and he extended pic to generate SVG, though it wasn't > > > clear to what sources he was modifying, exactly. Then the pandemic > > > hit, and I ended up leaving Google, so I don't think it went > > > beyond that, but IIRC he said that coercing pic to generate SVG > > > wasn't particularly difficult. > > > > I'm sure he'd have been messing with his own sources. These days > > it'd be best to tr to get new features into GNU pic (IMHO, of > > course). > > Oh surely. I just don't know what sources those would be, exactly; > presumably some derivative he's been shepherded all these years? I > wonder what it is.... Per Kernighan's _Unix: A History and a Memoir_ (2020), it seems likely that it was simply groff. "Camera-ready copy for this book was produced by the author in Times Roman and Helvetica, using groff, ghostscript, and other open source Unix tools." (copyright page) Further, figure 5.4 in that work was "created with Pic" (p. 95). GNU pic is already parameterized in the output format it produces, supporting four variants: "tpic" (`-c` option), "tex" (`-t`), "fig" (`-f`), and "troff". "fig" support has been #defined out for years and may never have been completed. SVG output, perhaps behind an `-s` flag, would be extremely helpful toward simplifying groff's HTML output story. (The other barrier is tbl's production of HTML tables, Savannah #60052.[1]) Regards, Branden [1] https://savannah.gnu.org/bugs/?60052 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From g.branden.robinson at gmail.com Fri Aug 12 12:06:53 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Thu, 11 Aug 2022 21:06:53 -0500 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: References: Message-ID: <20220812020653.ltfxtvi5earzlbmk@illithid> At 2022-08-12T01:33:12+0000, segaloco via TUHS wrote: > - Either the original EQN paper is dropped or relevant bits mashed > together with the user's guide V7 Unix shipped sources for both[1] but all typeset versions of the Unix Programmer's Manual I've seen (both scanned and HRW's physical copies) omit the white paper. Having recently undertaken to re-set these with groff,[2] I surmise that this is because there was already much overlap in content. What remained in the white paper was largely the de rigueur journalese about why this contribution was significant and scientifically noteworthy. It may have been felt that paid licensees already perceived such value. Regards, Branden [1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/eqn [2] https://minnie.tuhs.org/pipermail/tuhs/2022-July/026090.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From arnold at skeeve.com Fri Aug 12 16:41:29 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 12 Aug 2022 00:41:29 -0600 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: References: Message-ID: <202208120641.27C6fTNJ015169@freefriends.org> segaloco via TUHS wrote: > - This documentation refers to the last version as System III rather than > making any mention of 4.0. This is because 4.0 was never released outside the Bell System. When I did contract programming at Southern Bell, they told me that the practice was to publicly release one version behind what was running internally; thus System III was released when they were running 4.0 in the Bell System. They changed their minds when it came to System V, deciding to release the current internal version publicly as well. I also suspect that the System V doc drops all mention of IBM S/370 support for Unix. HTH, Arnold From arnold at skeeve.com Fri Aug 12 16:46:57 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 12 Aug 2022 00:46:57 -0600 Subject: [TUHS] pic In-Reply-To: <20220812015255.5mexb5ndknnzlhms@illithid> References: <20220810171417.GY21168@mcvoy.com> <202208101737.27AHbupN011923@freefriends.org> <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> <20220810180210.GZ21168@mcvoy.com> <202208101804.27AI4VkB1221117@darkstar.fourwinds.com> <20220810181911.50EEB3EE724@yagi.h-net.msu.edu> <202208101824.27AIOQG81222103@darkstar.fourwinds.com> <202208111213.27BCDOfi019865@freefriends.org> <20220812015255.5mexb5ndknnzlhms@illithid> Message-ID: <202208120646.27C6kvJE015824@freefriends.org> "G. Branden Robinson" wrote: > > Oh surely. I just don't know what sources those would be, exactly; > > presumably some derivative he's been shepherded all these years? I > > wonder what it is.... > > Per Kernighan's _Unix: A History and a Memoir_ (2020), it seems likely > that it was simply groff. Knowing BWK, I personally doubt that he'd have messed with GNU pic when he has his own copy of the original program that he himself wrote. I'm also quite sure that he prefers C to C++. > "Camera-ready copy for this book was produced by the author in Times > Roman and Helvetica, using groff, ghostscript, and other open source > Unix tools." (copyright page) Sure, because he works on Linux and MacOS and the GNU tools are easily installable and "just work". Of course, Dan could always just ask Brian what he did. :-) Arnold From tuhs at tuhs.org Fri Aug 12 21:01:31 2022 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Fri, 12 Aug 2022 13:01:31 +0200 Subject: [TUHS] Documents for UNIX Collections Message-ID: <94434410-26C2-48D5-AC8F-260DC3D3AA4B@planet.nl> > And I've received the documents! This is a pastebin with the rough contents of the documentation package. > > https://pastebin.com/jAqqBXA4 > > Now for some analysis: I’m interested in the journey of SysV IPC. So far I have established that these originated in CBUnix, with a lot of thinking on how to optimize these around the time that Unix 3.0/4.0/5.0 happened. They did not appear in Unix 3.0 / SysIII, and from the Unix 4.0 documentation I gather that it was not included there either. This would make Unix 5.0 / SysV R1 the first release with what is now known as SysV IPC. The PDP11 version of R1 has the CBUnix version of shared memory, as the VAX version did not make sense in the limited address space of the PDP11. From the pastebin summary, it would seem that IPC is not in this documentation either? That would be surprising, and reopens the possibility that IPC was part of Unix 4.0 Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Aug 12 21:15:52 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 12 Aug 2022 05:15:52 -0600 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: <94434410-26C2-48D5-AC8F-260DC3D3AA4B@planet.nl> References: <94434410-26C2-48D5-AC8F-260DC3D3AA4B@planet.nl> Message-ID: <202208121115.27CBFq0A028975@freefriends.org> Paul Ruizendaal via TUHS wrote: > I’m interested in the journey of SysV IPC. So far I have established > that these originated in CBUnix, with a lot of thinking on how to optimize > these around the time that Unix 3.0/4.0/5.0 happened. They did not appear > in Unix 3.0 / SysIII, and from the Unix 4.0 documentation I gather that > it was not included there either. I am not sure you can make that conclusion, as the 4.0 printed documents did not include the programmer's manual; instead they gave out the 3.0 manual and there was a list of changes somewhere in the other doc. Unfortunately, without actual 4.0 sources, it will always be a question. I have this VERY vague memory that I saw IPC in 4.0, but I could very easily be wrong... It was over 40 years ago, after all. :-) Arnold From jsg at jsg.id.au Fri Aug 12 21:41:57 2022 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 12 Aug 2022 21:41:57 +1000 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: <202208121115.27CBFq0A028975@freefriends.org> References: <94434410-26C2-48D5-AC8F-260DC3D3AA4B@planet.nl> <202208121115.27CBFq0A028975@freefriends.org> Message-ID: On Fri, Aug 12, 2022 at 05:15:52AM -0600, arnold at skeeve.com wrote: > Paul Ruizendaal via TUHS wrote: > > > I’m interested in the journey of SysV IPC. So far I have established > > that these originated in CBUnix, with a lot of thinking on how to optimize > > these around the time that Unix 3.0/4.0/5.0 happened. They did not appear > > in Unix 3.0 / SysIII, and from the Unix 4.0 documentation I gather that > > it was not included there either. > > I am not sure you can make that conclusion, as the 4.0 printed documents > did not include the programmer's manual; instead they gave out the > 3.0 manual and there was a list of changes somewhere in the other doc. > > Unfortunately, without actual 4.0 sources, it will always be a question. > > I have this VERY vague memory that I saw IPC in 4.0, but I could > very easily be wrong... It was over 40 years ago, after all. :-) "Release 4.0 was launched from this organization in March. It introduced new IPC mechanisms" from pg 39 of Pirzada's thesis https://spiral.imperial.ac.uk/bitstream/10044/1/7942/1/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf referred to in tuhs/Documentation/Emails/dmr_wkt "Other treasures: Shamim Pirzada did most of a PhD thesis on Unix as an exemplar of software evolution for Imperial College (London) that (in the part I have) contains a pretty good account of details of history up to about 1988." From imp at bsdimp.com Sat Aug 13 02:06:22 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 12 Aug 2022 10:06:22 -0600 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: References: <94434410-26C2-48D5-AC8F-260DC3D3AA4B@planet.nl> <202208121115.27CBFq0A028975@freefriends.org> Message-ID: On Fri, Aug 12, 2022 at 5:42 AM Jonathan Gray wrote: > On Fri, Aug 12, 2022 at 05:15:52AM -0600, arnold at skeeve.com wrote: > > Paul Ruizendaal via TUHS wrote: > > > > > I’m interested in the journey of SysV IPC. So far I have established > > > that these originated in CBUnix, with a lot of thinking on how to > optimize > > > these around the time that Unix 3.0/4.0/5.0 happened. They did not > appear > > > in Unix 3.0 / SysIII, and from the Unix 4.0 documentation I gather that > > > it was not included there either. > > > > I am not sure you can make that conclusion, as the 4.0 printed documents > > did not include the programmer's manual; instead they gave out the > > 3.0 manual and there was a list of changes somewhere in the other doc. > > > > Unfortunately, without actual 4.0 sources, it will always be a question. > > > > I have this VERY vague memory that I saw IPC in 4.0, but I could > > very easily be wrong... It was over 40 years ago, after all. :-) > > "Release 4.0 was launched from this organization in March. It introduced > new IPC mechanisms" > > from pg 39 of Pirzada's thesis > > https://spiral.imperial.ac.uk/bitstream/10044/1/7942/1/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf But also "Release 4.2 was launched in February 1982 for both the 3B & the DEC machines. It contained improvements to the data communications and networking software and more mature IPC" though it goes on to say 4.2 was provisional. 5.0 did have more things from CBUNIX: init and getty. I've also found this: https://groups.google.com/g/net.unix/c/-H9x36DMOBQ/m/P_G_s9SJBrgJ "Eventually, UNIX/TS was augmented to have many of the features present in CB-UNIX (this was done by Roger Faulkner at Indian Hill, BTL. This, in turn, became the base for UNIX 4.0, which was never released externally." This from a supervisor at Columbus... Warner referred to in tuhs/Documentation/Emails/dmr_wkt > > "Other treasures: Shamim Pirzada did most of a PhD thesis on Unix > as an exemplar of software evolution for Imperial College (London) > that (in the part I have) contains a pretty good account of details > of history up to about 1988." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Aug 13 02:37:32 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 12 Aug 2022 10:37:32 -0600 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: References: <94434410-26C2-48D5-AC8F-260DC3D3AA4B@planet.nl> <202208121115.27CBFq0A028975@freefriends.org> Message-ID: On Fri, Aug 12, 2022 at 10:06 AM Warner Losh wrote: > > > On Fri, Aug 12, 2022 at 5:42 AM Jonathan Gray wrote: > >> On Fri, Aug 12, 2022 at 05:15:52AM -0600, arnold at skeeve.com wrote: >> > Paul Ruizendaal via TUHS wrote: >> > >> > > I’m interested in the journey of SysV IPC. So far I have established >> > > that these originated in CBUnix, with a lot of thinking on how to >> optimize >> > > these around the time that Unix 3.0/4.0/5.0 happened. They did not >> appear >> > > in Unix 3.0 / SysIII, and from the Unix 4.0 documentation I gather >> that >> > > it was not included there either. >> > >> > I am not sure you can make that conclusion, as the 4.0 printed documents >> > did not include the programmer's manual; instead they gave out the >> > 3.0 manual and there was a list of changes somewhere in the other doc. >> > >> > Unfortunately, without actual 4.0 sources, it will always be a question. >> > >> > I have this VERY vague memory that I saw IPC in 4.0, but I could >> > very easily be wrong... It was over 40 years ago, after all. :-) >> >> "Release 4.0 was launched from this organization in March. It introduced >> new IPC mechanisms" >> >> from pg 39 of Pirzada's thesis >> >> https://spiral.imperial.ac.uk/bitstream/10044/1/7942/1/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf > > > But also "Release 4.2 was launched in February 1982 for both the 3B & the > DEC > machines. It contained improvements to the data communications and > networking > software and more mature IPC" though it goes on to say 4.2 was > provisional. 5.0 > did have more things from CBUNIX: init and getty. > > I've also found this: > > https://groups.google.com/g/net.unix/c/-H9x36DMOBQ/m/P_G_s9SJBrgJ > > "Eventually, UNIX/TS was augmented to have > many of the features present in CB-UNIX (this was done by Roger Faulkner > at Indian Hill, BTL. This, in turn, became the base for UNIX 4.0, which > was never released externally." > > This from a supervisor at Columbus... > Oh, see also the message from Guy Harris a few messages previous to the one that opens up with the above link (minor edits by me): " doug_gwyn>The UNIX System V IPC was already present in USG UNIX 4.1. doug_gwyn>(Not related to 4.1BSD.) For you real UNIX trivia freaks, the USG 4.0 IPC was different from the USG 4.1 IPC. The original message send/receive system calls sent to a process ID; they were changed to send to message queues, which had a 32-bit unique ID, instead (which makes more sense, as it permits you to transparently replace servers). " The note is extensive and goes into a lot of other areas related to IPC and lists names and references too. In fact the whole thread is a good candidate to be hoisted from google groups while we have the chance and placed into the TUHS archive. Is there a process for that? Warner Warner > > referred to in tuhs/Documentation/Emails/dmr_wkt >> >> "Other treasures: Shamim Pirzada did most of a PhD thesis on Unix >> as an exemplar of software evolution for Imperial College (London) >> that (in the part I have) contains a pretty good account of details >> of history up to about 1988." >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Aug 13 04:52:41 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 12 Aug 2022 18:52:41 +0000 Subject: [TUHS] SysIII and SysV Feature Lineage (was: Documents for UNIX Collections) Message-ID: Thread fork as we're drifting from documentation research specifically. One matter that keeps coming to mind for me is the formal history of the runlevel-based init system.  It isn't in Research obviously, nor was it in PWB.  The first time it shows up in the wild is System III, but this version is slightly different than what was in CB-UNIX at the time, which is what eventually wound up in System V. The pressing question is whether the version in System III represents an earlier borrowing from CB or if perhaps the runlevel init started in USG, got bumped over to CB and improved, then that improved version came back to supported UNIX in 5.0. As for the notable differences: SysIII init allows for runlevels 1-9.  It will call /etc/rc with the current state, the prior state, and the number of times the current state has been entered.  If the script is called for instance due to a powerfailure, then the current state is passed suffixed with an 'x'.  The inittab entries are in a different format: state:id:flags:process Where state is the runlevel, id is a two-character identifier, flags can be either 'c' (like respawn) or 'o' (like off I think). No flag then indicates to run once. Flags 't' or 'k' will terminate or kill a process before it is started again if a given runlevel is entered and it is already running. This of course is in contrast to SysV init which instead offers runlevels 0-6 as well as a, b, and c. Init itself can be called with runlevels S|s or Q|q additionally and these act as calls to enter single user mode or rerun the current init state if I'm understanding correctly. Neither S nor Q options appear to be valid for the inittab runlevel. Init tab entries here are: id:rstate:action:process Where id and rstate are essentially just the same fields from SysIII swapped. Action replaces the flags field with the more well known respawn, wait, once, initdefault, etc. behaviors. All in all, different enough that inittabs between the two wouldn't be compatible. SysV also includes the telinit command which appears to be able to handle those a, b, and c runlevels. Anywho, that's my understanding of the init changes, with the pertinent question remaining whether the SysIII-style init ultimately started from the same place as SysV, or if the general design idea was there between USG and CB, and they got to a similar answer from different directions. Colon-delimited /etc files aren't uncommon, so while unlikely, it could be entirely possible the two inittab formats arose relatively independently, but the truth remains obscure in my mind at least. I don't really blame Research for not picking up this init system, it seems like there were a few parallel streams of development around the turn of the 80s, and the easier answer was probably to just stay the course. I seem to recall reading in a thread somewhere Rob Pike discussing the resistance in the Research group regarding sucking up each and every little feature USG tried to promulgate as standard, and this init system got specific mention. - Matt G. From g.branden.robinson at gmail.com Sat Aug 13 06:49:02 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 12 Aug 2022 15:49:02 -0500 Subject: [TUHS] pic In-Reply-To: <202208120646.27C6kvJE015824@freefriends.org> References: <202208101744.27AHiWOT1220324@darkstar.fourwinds.com> <20220810180210.GZ21168@mcvoy.com> <202208101804.27AI4VkB1221117@darkstar.fourwinds.com> <20220810181911.50EEB3EE724@yagi.h-net.msu.edu> <202208101824.27AIOQG81222103@darkstar.fourwinds.com> <202208111213.27BCDOfi019865@freefriends.org> <20220812015255.5mexb5ndknnzlhms@illithid> <202208120646.27C6kvJE015824@freefriends.org> Message-ID: <20220812204902.n4fsdbvm7z3nrk5e@illithid> At 2022-08-12T00:46:57-0600, arnold at skeeve.com wrote: > "G. Branden Robinson" wrote: > > > Oh surely. I just don't know what sources those would be, exactly; > > > presumably some derivative he's been shepherded all these years? I > > > wonder what it is.... > > > > Per Kernighan's _Unix: A History and a Memoir_ (2020), it seems > > likely that it was simply groff. > > Knowing BWK, I personally doubt that he'd have messed with GNU pic > when he has his own copy of the original program that he himself wrote. Wishful thinking on my part, maybe. > I'm also quite sure that he prefers C to C++. No doubt--but groff is pretty accessible to C programmers, being almost entirely of an ancient vintage of C++. We don't have rvalue references inside lambda expressions inside templates, for instance. 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 Aug 14 05:51:37 2022 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Sat, 13 Aug 2022 21:51:37 +0200 Subject: [TUHS] Documents for UNIX Collections In-Reply-To: References: <94434410-26C2-48D5-AC8F-260DC3D3AA4B@planet.nl> <202208121115.27CBFq0A028975@freefriends.org> Message-ID: <55E37709-253F-45F3-BEC5-D9D084B27EA2@planet.nl> Thanks all for those pointers on the lineage of SysV IPC. All highly interesting! Paul From pnr at planet.nl Sun Aug 14 06:40:26 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 13 Aug 2022 22:40:26 +0200 Subject: [TUHS] PCS Munix kernel source In-Reply-To: References: Message-ID: <4418AB9D-1174-480C-9BC3-7F39F0593D11@planet.nl> > On Aug 11, 2022, at 11:01 AM, Holger Veit wrote: >> >> >> My understanding so far (from reading the paper a few years ago) is that Newcastle Connection works at the level of libc, substituting system calls like open() and exec() with library routines that scan the path, and if it is a network path invokes user mode routines that use remote procedure calls to give the illusion of a networked kernel. I’ve briefly looked at the Git repo, but I do not see that structure in the code. Could you elaborate a bit more on how Newcastle Connection operates in this kernel? Happy to communicate off-list if it goes in too much detail. > Maybe the original NC did so, but here there are numerous additions to > the kernel, including a new syscall uipacket() which is the gateway into > the MUNET/NC implementation. Stuff is in /usr/sys/munet, the low level > networking is in uipacket.c and uiswtch.c which will process RPC > open/close/read/write/exec etc. calls, as well support master and > diskless nodes). The OS code is full of "if (master) {...} else {...}' > code which then redirects detected access to remote paths to the network > handler. I came across a later paper for Unix United / Newcastle Connection. It seems to consider moving parts of the code into the kernel, to combat executable bloat (the relevant libc code would be copied into every executable, prior to shared libraries): https://www.researchgate.net/publication/2997714_The_architecture_of_UNIX_united >> Re-reading the Newcastle Connection paper also brought up some citations from Bell Labs work that seems to have been lost. There is a reference to “RIDE” which appears to be a system similar to Newcastle Connection. The RIDE paper is from 1979 and it mentions that RIDE is a Datakit re-implementation of earlier an earlier system that ran on Spider. Any recollections about these things among the TUHS readership? >> >> The other citation is for J. C. Kaufeld and D. L. Russell, "Distributed UNIX System", in Workshop on Fundamental Issues in Distributed Computing, ACM SIGOPS and SIGPLAN (15-17 Dec. 1980). It seems contemporaneous with the Luderer/Marshall/Chu work on S/F-Unix. I could not find this paper so far. Here, too, any recollections about this distributed Unix among the TUHS readership? > Good to mention this. I am interested in such stuff as well. I found a summary of that ACM SIGOPS workshop. There is a half page summary about David Russels presentation on “Distributed Unix”: ==== 2.4 David Russell: Distributed UNIX Distributed UNIX is an experimental system consisting of a collection of machines running a modified version of UNIX. Communication among processors is performed by a packet switching network built on Datakit hardware. The network has a capacity of roughly 7.5 megabits, shared among several channels. Addressing is done by channel, not by target processor. Messages are received in the order sent. To the user, communication takes the form of a virtual circuit, a logical full-duplex connection between processors. A virtual circuit can be modeled as a box with four ends: DIN and DOUT control data transmission, and CIN and COUT control transmission of control information. Circuits can be spliced together, or attached to devices. Circuits can also be joined into groups. A virtual circuit is set up in the following way: a socket is created with a globally unique name, and processes then request connections to the named socket. Routing information is implicit. Virtual circuits support location transparency, since sockets can move, but not replication transparency. If a circuit breaks, it is set up again, although it is up to the user to handle recovery of state information. Machine failure will destroy a virtual circuit. A transparent distributed file system was set up. When a remote file is accessed, a socket name is generated, which is used to establish a connection with a daemon at the file server processor. The daemon carries out the file access on behalf of the remote user. In conclusion, offloading of tasks was found to work well. The path manager maintains very little state. The splice interface between virtual circuits was found to be very efficient, although UNIX scheduling was not appropriate for fast setup of circuits. ==== The modeling of virtual circuits sounds like a mid-point between Chesson’s multiplexed files and Ritchie’s streams. The file system actually sounds like it could be the RIDE system. Maybe this Distributed Unix and RIDE are one and the same thing. (although the original Newcastle Connection paper suggests they are not: https://inis.iaea.org/collection/NCLCollectionStore/_Public/16/081/16081910.pdf?r=1&r=1). Paul From joseph at josephholsten.com Tue Aug 16 04:28:54 2022 From: joseph at josephholsten.com (Joseph Holsten) Date: Mon, 15 Aug 2022 11:28:54 -0700 Subject: [TUHS] Editor for Mortals History Message-ID: <7a9e28f3-ff88-47ca-a4c1-e7fc20eef619@www.fastmail.com> Hello everyone! I’ve been digging into text editor history, and I found: “This provided another huge step forward in usability and allowed us to maintain our modeless approach to screen editing, which was, we feel, superior to the Vi approach.” from https://www.coulouris.net/cs_history/em_story/ This makes me want to know em’s history outside the usual precursor-to-vi narrative. Does anyone know much about the timeline of em from 1971 (QMC Unix installation) to 1976 (Intro to W M Joy @ UCB)? And does anyone know of developments to it after 1976-04-29? That’s the last date within text in the https://www.coulouris.net/cs_history/em_story/emsource/ files. (Also grumble grumble broken touch feature detection in that shar, which indicates last mod of 1996-02-18). Anyone other than Coulouris used em in the last 45 years? -- Joseph Holsten http://josephholsten.com mailto:joseph at josephholsten.com tel:+1-360-927-7234 From arnold at skeeve.com Thu Aug 18 20:01:24 2022 From: arnold at skeeve.com (Arnold Robbins) Date: Thu, 18 Aug 2022 13:01:24 +0300 Subject: [TUHS] Nice video with Brian Kernighan Message-ID: https://www.youtube.com/watch?v=GNyQxXw_oMQ Not quite 30 minutes long. Mostly about the history of awk but some other stuff, including a nice plug for TUHS at the end. Arnold From clemc at ccc.com Fri Aug 19 07:58:35 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 18 Aug 2022 17:58:35 -0400 Subject: [TUHS] Nice video with Brian Kernighan In-Reply-To: References: Message-ID: Thanks Arnold -- always fun. ᐧ On Thu, Aug 18, 2022 at 6:01 AM Arnold Robbins wrote: > https://www.youtube.com/watch?v=GNyQxXw_oMQ > > Not quite 30 minutes long. Mostly about the history of awk but some > other stuff, including a nice plug for TUHS at the end. > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Aug 19 08:48:44 2022 From: tuhs at tuhs.org (Pete Wright via TUHS) Date: Thu, 18 Aug 2022 15:48:44 -0700 Subject: [TUHS] Nice video with Brian Kernighan In-Reply-To: References: Message-ID: <9e060307-6c7e-1ea3-7926-01a1cb047d58@nomadlogic.org> On 8/18/22 14:58, Clem Cole wrote: > Thanks Arnold -- always fun. agreed!  i shared this with my data engineering team - i hope historical context like this helps them in how they approach their data processing tasks. -pete -- Pete Wright pete at nomadlogic.org @nomadlogicLA -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sun Aug 21 01:48:00 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 20 Aug 2022 11:48:00 -0400 Subject: [TUHS] Nice video with Brian Kernighan Message-ID: Brian's tribute to the brilliant regex mechanism that awk borrowed from egrep spurred memories. For more than forty years I claimed credit for stimulating Ken to liberate grep from ed. Then, thanks to TUHS, I learned that I had merely caused Ken to spring from the closet a program he had already made for his own use. There's a related story for egrep. Al Aho made a deterministic regular-expression recognizer as a faster replacement for the non-deterministic recognizer in grep. He also extended the domain of patterns to full regular expressions, including alternation; thus the "e" in egrep. About the same time, I built on Norm Shryer's personal calendar utility. I wanted to generalize Norm's strict syntax for dates to cover most any (American) representation of dates, and to warn about tomorrow's calendar as well as today's--where "tomorrow" could extend across a weekend or holiday. Egrep was just the tool I needed for picking the dates out of a free-form calendar file. I wrote a little program that built an egrep pattern based on today's date. The following mouthful for Saturday, August 20 covers Sunday and Monday, too. (Note that, in egrep, newline is a synonym for |, the alternation operator.) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*20)([^0123456789]|$) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*21)([^0123456789]|$) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*22)([^0123456789]|$) It worked like a charm, except that it took a good part of a minute to handle even a tiny calendar file. The reason: the state count of the deterministic automaton was exponentially larger than the regular regular expression; and egrep had to build the automaton before it could run it. Al was mortified that an early serious use of egrep should be such a turkey. But Al was undaunted. He replaced the automaton construction with an equivalent lazy algorithm that constructed a state only when the recognizer was about to visit it. This made egrep into the brilliant tool that Brian praised. What I don't know is whether the calendar program stimulated the idea of lazy implementation, or whether Al, like Ken before him with grep, already had the idea up his sleeve. Doug From clemc at ccc.com Sun Aug 21 02:17:02 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 20 Aug 2022 12:17:02 -0400 Subject: [TUHS] Nice video with Brian Kernighan In-Reply-To: References: Message-ID: Doug, No matter. I have often thought about what an amazing muse you were to so many people regarding so many different ideas that have panned out. It seems to me that you were always there at the right time. Your powers to get the best from everyone around you are unlike anyone else I have ever been lucky enough to have met. Although I have also often said to students the one really hard thing to directly teach, that you can learn by looking at people that came before you is 'good taste.' We all owe you as much thanks for being there and inspiring your peers, as for their brilliance in implementing the concepts with style and taste. Clem ᐧ On Sat, Aug 20, 2022 at 11:49 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > Brian's tribute to the brilliant regex mechanism that awk borrowed > from egrep spurred memories. > > For more than forty years I claimed credit for stimulating Ken to > liberate grep from ed. Then, thanks to TUHS, I learned that I had > merely caused Ken to spring from the closet a program he had already > made for his own use. > > There's a related story for egrep. Al Aho made a deterministic > regular-expression recognizer as a faster replacement for the > non-deterministic recognizer in grep. He also extended the domain of > patterns to full regular expressions, including alternation; thus the > "e" in egrep. > > About the same time, I built on Norm Shryer's personal calendar > utility. I wanted to generalize Norm's strict syntax for dates to > cover most any (American) representation of dates, and to warn about > tomorrow's calendar as well as today's--where "tomorrow" could extend > across a weekend or holiday. > > Egrep was just the tool I needed for picking the dates out of a > free-form calendar file. I wrote a little program that built an egrep > pattern based on today's date. The following mouthful for Saturday, > August 20 covers Sunday and Monday, too. (Note that, in egrep, newline > is a synonym for |, the alternation operator.) > > (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*20)([^0123456789]|$) > (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*21)([^0123456789]|$) > (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*22)([^0123456789]|$) > > It worked like a charm, except that it took a good part of a minute to > handle even a tiny calendar file. The reason: the state count of the > deterministic automaton was exponentially larger than the regular > regular expression; and egrep had to build the automaton before it > could run it. Al was mortified that an early serious use of egrep > should be such a turkey. > > But Al was undaunted. He replaced the automaton construction with an > equivalent lazy algorithm that constructed a state only when the > recognizer was about to visit it. This made egrep into the brilliant > tool that Brian praised. > > What I don't know is whether the calendar program stimulated the idea > of lazy implementation, or whether Al, like Ken before him with grep, > already had the idea up his sleeve. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Sun Aug 21 04:24:57 2022 From: rdm at cfcl.com (Rich Morin) Date: Sat, 20 Aug 2022 11:24:57 -0700 Subject: [TUHS] Nice video with Brian Kernighan In-Reply-To: References: Message-ID: After watching the video, I remain curious about a couple of things. Q: What were Brian's main contributions to AWK? (aside from the book :-) Q: Where did the idea for AWK originate? FWIW, my spouse (Vicki Brown) used AWK to support her Master's thesis. She: - defined a common, human-friendly data format - used AWK to convert it for submission to IBM and Univac programs - used AWK to boil down the output (printer plots of dendograms) - used AWK to convert the data for use with my SunCore interpreter This all worked very well, but some real pain was involved when her advisor asked her to convert her scripts to Fortran... -r From mohd.akram at outlook.com Sun Aug 21 19:36:03 2022 From: mohd.akram at outlook.com (Mohamed Akram) Date: Sun, 21 Aug 2022 09:36:03 +0000 Subject: [TUHS] Nice video with Brian Kernighan In-Reply-To: References: Message-ID: Hi folks, This is my first time posting on this list, it’s been such a joy to read about so many little-known yet enduring and consequential aspects of UNIX. I had written a short post [1] about the calendar utility some time ago, with a brief glimpse at its history. Seeing its implementation, it certainly made me scratch my head a bit - who would think to create a program whose sole purpose was to dynamically generate a regular expression that would then be fed into another program (it doesn’t stop there either, as my post goes into). I found it to be perhaps the most illustrative and comprehensive example of UNIX composition that I had come across. Unbeknownst to me that it was Douglas McIlroy who had written this program, which in hindsight should not come as a surprise at all, him being the exemplar of composing simple, orthogonal, yet robust tools to get a job done quickly and efficiently. Thank you Doug for your reply, I thoroughly enjoyed learning more about the origins and history of the calendar program. That it was the impetus to turn egrep into the performant and viable tool that we know today further colors the picture of this unassuming utility. [1] https://akr.am/blog/posts/today-in-history-brought-to-you-by-unix Regards, Mohamed On Aug 20, 2022, at 7:48 PM, Douglas McIlroy > wrote: Brian's tribute to the brilliant regex mechanism that awk borrowed from egrep spurred memories. For more than forty years I claimed credit for stimulating Ken to liberate grep from ed. Then, thanks to TUHS, I learned that I had merely caused Ken to spring from the closet a program he had already made for his own use. There's a related story for egrep. Al Aho made a deterministic regular-expression recognizer as a faster replacement for the non-deterministic recognizer in grep. He also extended the domain of patterns to full regular expressions, including alternation; thus the "e" in egrep. About the same time, I built on Norm Shryer's personal calendar utility. I wanted to generalize Norm's strict syntax for dates to cover most any (American) representation of dates, and to warn about tomorrow's calendar as well as today's--where "tomorrow" could extend across a weekend or holiday. Egrep was just the tool I needed for picking the dates out of a free-form calendar file. I wrote a little program that built an egrep pattern based on today's date. The following mouthful for Saturday, August 20 covers Sunday and Monday, too. (Note that, in egrep, newline is a synonym for |, the alternation operator.) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*20)([^0123456789]|$) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*21)([^0123456789]|$) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*22)([^0123456789]|$) It worked like a charm, except that it took a good part of a minute to handle even a tiny calendar file. The reason: the state count of the deterministic automaton was exponentially larger than the regular regular expression; and egrep had to build the automaton before it could run it. Al was mortified that an early serious use of egrep should be such a turkey. But Al was undaunted. He replaced the automaton construction with an equivalent lazy algorithm that constructed a state only when the recognizer was about to visit it. This made egrep into the brilliant tool that Brian praised. What I don't know is whether the calendar program stimulated the idea of lazy implementation, or whether Al, like Ken before him with grep, already had the idea up his sleeve. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Mon Aug 22 01:09:11 2022 From: cowan at ccil.org (John Cowan) Date: Sun, 21 Aug 2022 11:09:11 -0400 Subject: [TUHS] Nice video with Brian Kernighan In-Reply-To: References: Message-ID: On Sat, Aug 20, 2022 at 2:26 PM Rich Morin wrote: > - used AWK to convert the data for use with my SunCore interpreter > What is this SunCore of which you speak? Dr. Google reports too many confounds. > This all worked very well, but some real pain was involved when her > advisor asked her to convert her scripts to Fortran... > Nowadays, of course, awk is actually more readily available than Fortran. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Aug 22 01:41:02 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 21 Aug 2022 11:41:02 -0400 Subject: [TUHS] Nice video with Brian Kernighan In-Reply-To: References: Message-ID: On Sun, Aug 21, 2022 at 11:11 AM John Cowan wrote: > Nowadays, of course, awk is actually more readily available than Fortran. > > Becare of a statement/thinking like that. While you and I might not program with it, I can show you some interesting usage graphs. Simply over 90% of all supercomputer cycles are still Fortran (why - because the Math has not changed - *a.k.a.* Cole's law). Plus Fortran2018 is not the language Rich and I learned in the 1960s and 1970s. Also remember that there are multiple extremely good commercial (production quality) Fortran2018 implementations that are freely available for download for everything from Windows to Linux to macOS [as I like to say - I don't program in it, but FTN has paid my salary pretty much my mine entire 55+ years in the biz and make damned sure my OS and my systems run programs compiled with it really well]. If you are interested, here is a pointer to the Intel one: HPC Toolkit Download which has the DNA from the old DEC compilers ground up and injected into BTW [note you will need to download the free C/C++ compiler too which contains the runtimes libraries that Fortran uses and shares]. While its Fortran 2018, it will even compile 'dust decks Fortran-IV' - fixed format too. Programs like Adventure 'just work' (are actually part of the test suite). FWIW: I believe the Portland Group's compilers were/are also freely available and maybe IBM's also but I have not tried to get them in a few years. BTW: I have a young Mech E professor friend teaching/doing research @ an infamous engineering school here in the Boston area. He got his PhD about 5-6 years ago at another infamous school in the midwest. What are all his students using for their research? (which is thermal properties of materials - trying to get the heat out our Si we can run them faster without them melting). It is all Fortran, with a little bit of Numpy (running on their Macs) to prep the data, but anything that matters runs on the clusters in is Fortran. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Mon Aug 22 06:07:42 2022 From: rdm at cfcl.com (Rich Morin) Date: Sun, 21 Aug 2022 13:07:42 -0700 Subject: [TUHS] Nice video with Brian Kernighan In-Reply-To: References: Message-ID: <48947943-90FA-43DA-A7FD-4B75BE9549C7@cfcl.com> > On Aug 21, 2022, at 08:09, John Cowan wrote: > > On Sat, Aug 20, 2022 at 2:26 PM Rich Morin wrote: > > - used AWK to convert the data for use with my SunCore interpreter > > What is this SunCore of which you speak? Dr. Google reports too many confounds. ... I was able to find some web mentions of the relevant SunCore. I've put a set of links below, which others may well be able to improve upon. Anyway, the SunCore Graphics Package shipped with early versions of SunOS. It was a set of C libraries which allowed programs to draw on the bitmapped display. My interpreter read simple text commands (eg, "fn_name arg_1 ..."), parsed them, and made the specified library calls. -r P.S. For the curious... The dendrogram plotting software, which ran on U of MD's IBM and Univac mainframes, generated line printer plot files. These used characters such as dashes and vertical bars to draw the dendrogram "trees". So, Vicki's code needed to scan the files, extract the shape of each tree, and generate plotting commands for my interpreter. The production process for that part of Vicki's thesis was roughly as follows: - hand-code data files in a common, human-friendly format (vi) - convert into formats for the IBM and Univac software (AWK) - upload and process the files, then download the results - analyze the line printer plot files of dendrograms (AWK) - generate commands for the SunCore interpreter (AWK) - run the interpreter, generating diagrams on the display - dump bitmap images of the displayed diagrams - print the images, using a dot-matrix printer The text portion of the thesis was generated using a different tool chain: - create and/or edit the thesis text (vi) - format the text for printing (nroff) - print on an IBM I/O selectric (Datel 30) Printing on the Datel 30 was complicated by several factors. It wanted BCDIC correspondence code, rather than ASCII. Also, it needed null characters to provide enough time for various activities (eg, print ball rotation, carriage returns, line feeds). And, given that paper feeding was a manual process, we needed a way to initiate printing of a new page, reprint botched pages, etc. So, I wrote a small utility program that handled all of this. # Links https://en.wikipedia.org/wiki/Dendrogram http://vtda.org/docs/computing/Sun/software/800-1115-01%20-%20SunOS%201.1%20Programmer's%20Reference%20Manual%20for%20SunCore.pdf http://vtda.org/docs/computing/Sun/software/800-1787-10_SunCoreReferenceManual_RevA_9May88.pdf http://www-lehre.inf.uos.de/~sp/Man/_Man_SunOS_4.1.3_html/html6/suncoredemos.6.html From cowan at ccil.org Mon Aug 22 12:49:50 2022 From: cowan at ccil.org (John Cowan) Date: Sun, 21 Aug 2022 22:49:50 -0400 Subject: [TUHS] Nice video with Brian Kernighan In-Reply-To: References: Message-ID: On Sun, Aug 21, 2022 at 11:41 AM Clem Cole wrote: > On Sun, Aug 21, 2022 at 11:11 AM John Cowan wrote: > >> Nowadays, of course, awk is actually more readily available than Fortran. >> >> Becare of a statement/thinking like that. > What I meant was that if you walk up to a (non-Windows) computer and type `awk`, it starts up (and prints a help message, if it's gawk). But if you type f90 or whatever, you probably get "f90: command not found". That's not to say that you can't install it easily enough if you have root, but it does mean Fortran is less widely available. > > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Tue Aug 23 01:35:38 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 22 Aug 2022 15:35:38 +0000 Subject: [TUHS] Extracting files from various old dump/restore tapes Message-ID: <7w7d30jnp1.fsf@junk.nocrew.org> Hello, I have on my hands many images of tapes that seems to have been written by various implementaions of dump. I see the magic numbers 60011 and 60012 in little and big endian at offsets 18 (16-bit version?) and 24 (32-bit version?). I don't know the dating of the tapes, but around 1980 would be a reasonable guess. Are there some easy to use (ready to run on a modern Unix) tools to extract files from such tape files? I'm not looking to restore a file system on disk, just extract the files. From imp at bsdimp.com Tue Aug 23 02:27:31 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 22 Aug 2022 10:27:31 -0600 Subject: [TUHS] Extracting files from various old dump/restore tapes In-Reply-To: <7w7d30jnp1.fsf@junk.nocrew.org> References: <7w7d30jnp1.fsf@junk.nocrew.org> Message-ID: FreeBSD deleted some compat code in the kernel some time ago, and it turns out that restore used that to read old dump tapes, so we broke old dump tapes. So you can't use FreeBSD's unmodified. So 60011 is OFS_MAGIC and 60012 is NFS_MAGIC. Both of these are variants on UFS, but really old. And given they are at different offsets, you'll likely need to reverse engineer the offsets used for the platform's dinode. dump from 4.4BSD had 'natural' types (so long was used which would affect the offsets). It seems to be able to read both NFS_MAGIC and OFS_MAGIC tapes, but you'll likely have to hack together u_spcl that's specific to the platform which may take a little trial and error if you don't know what the typedefs for daddr_t etc are. There's also a 4.1 dump/restore you might need (available in the 4.4BSD Alpha archive and likely all earlier versions in TUHS). Without more specific data it's hard to know if there's an extant binary that can be run in emulation to read these tapes. Warner On Mon, Aug 22, 2022 at 9:35 AM Lars Brinkhoff wrote: > Hello, > > I have on my hands many images of tapes that seems to have been written > by various implementaions of dump. I see the magic numbers 60011 and > 60012 in little and big endian at offsets 18 (16-bit version?) and 24 > (32-bit version?). I don't know the dating of the tapes, but around > 1980 would be a reasonable guess. > > Are there some easy to use (ready to run on a modern Unix) tools to > extract files from such tape files? > > I'm not looking to restore a file system on disk, just extract the > files. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Tue Aug 23 02:53:35 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 22 Aug 2022 09:53:35 -0700 Subject: [TUHS] Extracting files from various old dump/restore tapes In-Reply-To: References: <7w7d30jnp1.fsf@junk.nocrew.org> Message-ID: <9CB31023-9485-4BE8-9B1F-2A6165044BE4@iitbombay.org> On Aug 22, 2022, at 9:27 AM, Warner Losh wrote: > > FreeBSD deleted some compat code in the kernel some time ago, and it turns > out that restore used that to read old dump tapes, so we broke old dump tapes. > So you can't use FreeBSD's unmodified. May be run an older release that has this code? From imp at bsdimp.com Tue Aug 23 02:56:09 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 22 Aug 2022 10:56:09 -0600 Subject: [TUHS] Extracting files from various old dump/restore tapes In-Reply-To: <9CB31023-9485-4BE8-9B1F-2A6165044BE4@iitbombay.org> References: <7w7d30jnp1.fsf@junk.nocrew.org> <9CB31023-9485-4BE8-9B1F-2A6165044BE4@iitbombay.org> Message-ID: On Mon, Aug 22, 2022 at 10:53 AM Bakul Shah wrote: > On Aug 22, 2022, at 9:27 AM, Warner Losh wrote: > > > > FreeBSD deleted some compat code in the kernel some time ago, and it > turns > > out that restore used that to read old dump tapes, so we broke old dump > tapes. > > So you can't use FreeBSD's unmodified. > > May be run an older release that has this code? > That only works if the dinode structures line up exactly to whatever these tapes are from. The 16-bit ones likely need to use the V7 restore (maybe running in emulation in simh), the 32-bit ones might be able to use V32 or 4BSD running in emulation, if that's what the tapes are from. But the multi-endian suggests that maybe things are more complex than that. FreeBSD's restore from older releases might work, but only for the 32-bit stuff and only if we're lucky... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Tue Aug 23 15:55:22 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 23 Aug 2022 05:55:22 +0000 Subject: [TUHS] Extracting files from various old dump/restore tapes In-Reply-To: (Warner Losh's message of "Mon, 22 Aug 2022 10:27:31 -0600") References: <7w7d30jnp1.fsf@junk.nocrew.org> Message-ID: <7wlerfijw5.fsf@junk.nocrew.org> Warner Losh wrote: > So 60011 is OFS_MAGIC and 60012 is NFS_MAGIC. Both of these are > variants on UFS, but really old. And given they are at different > offsets, you'll likely need to reverse engineer the offsets used for > the platform's dinode. So anyway, it seems my best bet would be getting an old "restore" and hack it till it runs. Part of the problem is that there are hundreds of these images, so it would be a lot of work to examine them individually in emulated systems. A good first start to examine the content would be to just list the file names. > Without more specific data it's hard to know if there's an extant > binary that can be run in emulation to read these tapes. The tapes are from MIT's "Tapes of Tech Square" collection. Likely candidates include PDP-11 V7, 4.x BSD on VAX, and Sun workstations. I suppose the latter would use the big endian format. There are also many variations of the tar and cpio formats, but I'm on firmer ground there. From imp at bsdimp.com Tue Aug 23 23:02:20 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 23 Aug 2022 07:02:20 -0600 Subject: [TUHS] Extracting files from various old dump/restore tapes In-Reply-To: <7wlerfijw5.fsf@junk.nocrew.org> References: <7w7d30jnp1.fsf@junk.nocrew.org> <7wlerfijw5.fsf@junk.nocrew.org> Message-ID: On Mon, Aug 22, 2022 at 11:55 PM Lars Brinkhoff wrote: > Warner Losh wrote: > > So 60011 is OFS_MAGIC and 60012 is NFS_MAGIC. Both of these are > > variants on UFS, but really old. And given they are at different > > offsets, you'll likely need to reverse engineer the offsets used for > > the platform's dinode. > > So anyway, it seems my best bet would be getting an old "restore" and > hack it till it runs. > > Part of the problem is that there are hundreds of these images, so it > would be a lot of work to examine them individually in emulated systems. > A good first start to examine the content would be to just list the file > names. > For V7 tapes, you can run the V7 binaries using apout with very little effort. This is a user-level emulation of a pdp-11 with the system calls for v5, v6, v7 and some of the BSDs. It's in the tuhs archives under Distributions/Research/Dennis_v1/unix72/tools/apout. I used it to extract files from V7 automatically that I used in the 2.11 back-patching-to-the-original-tapes script I wrote. > > Without more specific data it's hard to know if there's an extant > > binary that can be run in emulation to read these tapes. > > The tapes are from MIT's "Tapes of Tech Square" collection. Likely > candidates include PDP-11 V7, 4.x BSD on VAX, and Sun workstations. I > suppose the latter would use the big endian format. > Very cool. I suspect if you want one tool for them all, you'll need to take restore and teach it to cope with multiple endians and word sizes... It's likely not a huge effort, but the restor code from V7 makes use of a lot of type-punning... > There are also many variations of the tar and cpio formats, but I'm on > firmer ground there. > Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Aug 26 22:08:07 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 26 Aug 2022 06:08:07 -0600 Subject: [TUHS] off topic: whither the pcc-revived project? Message-ID: <202208261208.27QC87oU032062@freefriends.org> Hi. I'm hoping some of the BSD people here may know. I've been keeping a git mirror of the PCC Revived project, but in the past month or so it's gone dark. The website is no longer there, the CVS repos don't answer, and an email to the mailing list went unanswered. Does anyone know anything about it? Did it move to somewhere else? I use pcc for testing, it's much faster than GCC and clang. And in general, I think it's a cool thing. :-) Thanks, Arnold