From edouardklein at gmail.com Sun Jul 2 02:00:07 2023 From: edouardklein at gmail.com (Edouard Klein) Date: Sat, 01 Jul 2023 18:00:07 +0200 Subject: [COFF] A slack clone in 5 lines of bash Message-ID: <877crjfwnv.fsf@gmail.com> Dear Old Farts, I've written a chat system that relies at its core on UNIX's permission system. All the explanations are here: https://the-dam.org/docs/explanations/suc.html I thought it would be of interest to the list as it has one foot in the past (using system primitives from the 70's for access control) and one foot in the future: (optionally) using GNU Guix's declarative configuration to create the necessary users, groups, and files. I know most of you have used (and some maybe still do) talk et al. This system is even simpler, just a forever loop: while /usr/bin/true do read -r line || exit 0 # EOF /usr/bin/echo "$(/usr/bin/date --iso-8601=seconds)"\ "$(printf "%-9s" "$(/usr/bin/id --user --name --real)")" \ "$line" >> /var/lib/suc/"$1" done I'd be happy to hear any comments or to welcome you on the Dam, where we test this stuff. Cheers ! Edouard. From coff at tuhs.org Sun Jul 2 08:48:54 2023 From: coff at tuhs.org (segaloco via COFF) Date: Sat, 01 Jul 2023 22:48:54 +0000 Subject: [COFF] IBM SLT Module Identity? Message-ID: Hello, today I have received an IBM binder from 1974 pertaining to IBM Skylab activities as well as a small IBM SLT, single wide, with four modules on it. Two of the modules are labeled: 361456 IBM WF 1 03S 215 And the other two are: 361453 IBM 22 1-009 415 >From what I could find online, there is a close SLT card with 4 of the 361453's instead of 2, but that doesn't help much. That board is listed as 00211 in the reference this info is from[1]. Faintly on the connector I can make out: 00008 A 0 204 YM It is very, very faint in places though so that may not be correct. The specific little blocks on the board appear to show up on others, so nothing unheard of, although I wouldn't know where to start on identifying what this does precisely, all I can find are cursory references in a few places to the numbers on the chips re: SLT modules. - Matt G. [1] - https://ibm-slt-reference.fandom.com/wiki/SLT_Board_List (why is this a fandom.com wiki...) P.S. If you or a loved one are in possession of IBM mainframe hardware that would benefit from this SLT board, happy to send it to you, I probably won't do much with it unless I can figure out the pinout and do weird things over GPIO pins from one of my single boards. From coff at tuhs.org Tue Jul 4 11:57:55 2023 From: coff at tuhs.org (segaloco via COFF) Date: Tue, 04 Jul 2023 01:57:55 +0000 Subject: [COFF] Bell System and the Video Game Industry? Message-ID: <_l_rdK2ywBoEAheCu4dCFyJ3cyXymIXgMK9-_bgAtMwLXtmr2sZnuRvjFc6jqn6K0X_E2MuSEMm5_iVO7eBeYTOpRHVRuypykZD_au00R-c=@protonmail.com> So this evening I've been tinkering with a WECo 2500 I've been using for playing with telecom stuff, admiring the quality of the DTMF module, and it got me thinking, gee, this same craftsmanship would make for some very nice arcade buttons, which then further had me pondering on the breadth of the Bell System's capabilities and the unique needs of the video game industry in the early 80s. In many respects, the combination of Western Electric and Bell Laboratories could've been a hotbed of video game console and software development, what with WECo's capability to produce hardware such as coin slots, buttons, wiring harnesses for all sorts of equipment, etc. and then of course the software prowess of the Labs. Was there to anyone here's knowledge any serious consideration of this market by Bell? The famous story of UNIX's origins includes Space Travel, and from the very first manual, games of various kinds have accompanied UNIX wherever it goes. It seems that out of most companies, the Bell System would've been very well poised, what with their own CPU architecture and other fab operations, manufacturing and distribution chains, and so on. There's a looooot of R&D that companies such as Atari and Nintendo had to engage in that the Bell System had years if not decades of expertise in. Would anti-trust stuff have come into play in that regard? Bell couldn't compete in the computer market, and I suppose it would depend on the legal definitions applicable to video game hardware and software at the time. In any case, undercurrent here is the 2500 is a fine telephone, if the same minds behind some of this WECo hardware had gone into video gaming, I wonder how different things would've turned out. - Matt G. From crossd at gmail.com Thu Jul 6 07:48:00 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 5 Jul 2023 17:48:00 -0400 Subject: [COFF] [TUHS] Re: the wheel of reincarnation goes sideways In-Reply-To: References: Message-ID: On Mon, Mar 13, 2023 at 6:34 PM Dan Cross wrote: > On Mon, Mar 13, 2023 at 6:16 PM Peter Pentchev wrote: > > On Wed, Mar 08, 2023 at 02:52:43PM -0500, Dan Cross wrote: > > > [bumping to COFF] > > > > > > On Wed, Mar 8, 2023 at 2:05 PM ron minnich wrote: > > > > The wheel of reincarnation discussion got me to thinking: > > [snip] > > > > The evolution of platforms like laptops to becoming full distributed systems continues. > > > > The wheel of reincarnation spins counter clockwise -- or sideways? > > > > > > About a year ago, I ran across an email written a decade or more prior > > > on some mainframe mailing list where someone wrote something like, > > > "wow! It just occurred to me that my Athlon machine is faster than the > > > ES/3090-600J I used in 1989!" Some guy responded angrily, rising to > > > the wounded honor of IBM, raving about how preposterous this was > > > because the mainframe could handle a thousand users logged in at one > > > time and there's no way this Linux box could ever do that. > > [snip] > > > For that matter, a > > > thousand users probably _could_ telnet into the Athlon system. With > > > telnet in line mode, it'd probably even be decently responsive. > > > > sdf.org (formerly sdf.lonestar.org) comes to mind... > > I don't know if a thousand users ever logged in there at one time, but > they do tend to have a lot of simultaneous logins. I thought some folks here might find this interesting. Someone else today reminded me of tilde.town, which is a publicly accessible machine running Linux. They have a shocking amount of use: tilde% hostname tilde.town tilde% uname -a Linux tilde.town 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux tilde% uptime 21:38:01 up 156 days, 17:15, 454 users, load average: 3.82, 4.40, 4.19 tilde% Not quite a thousand users logged in simultaneously, but half that. If one counts the number of processes associated with pseudoterminals, it's more (I guess a lot of users are running tmux and/or screen). The system is also surprisingly modest: 6 cores, 16GiB of RAM and about 1TB of storage. It's surprisingly zippy. - Dan C. From coff at tuhs.org Thu Jul 6 09:58:50 2023 From: coff at tuhs.org (Grant Taylor via COFF) Date: Wed, 5 Jul 2023 18:58:50 -0500 Subject: [COFF] [TUHS] Re: the wheel of reincarnation goes sideways In-Reply-To: References: Message-ID: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> On 7/5/23 4:48 PM, Dan Cross wrote: > I thought some folks here might find this interesting. Someone else > today reminded me of tilde.town, which is a publicly accessible > machine running Linux. They have a shocking amount of use: O.o? > tilde% hostname > tilde.town > tilde% uname -a > Linux tilde.town 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 > UTC 2023 x86_64 x86_64 x86_64 GNU/Linux > tilde% uptime > 21:38:01 up 156 days, 17:15, 454 users, load average: 3.82, 4.40, 4.19 > tilde% Well I'll be. Someone is running a multi-user Unix system. That's something I've always wanted to do or find someone doing. > Not quite a thousand users logged in simultaneously, but half that. If > one counts the number of processes associated with pseudoterminals, > it's more (I guess a lot of users are running tmux and/or screen). :-) > The system is also surprisingly modest: 6 cores, 16GiB of RAM and > about 1TB of storage. I can't yet tell if that's six logical CPUs or more. x86_64 cores /could/ have hyper-threading et al. and more logical CPUs. But still, six contemporary CPUs could be a lot of computing power. 16 GB of memory is nothing to sneeze at, especially for running commands in a CLI environment. -- I'm assuming no daemons saying FEED ME RAM. > It's surprisingly zippy. I applied for membership. I'll be interested to see if I'm granted logon permission. :-) Thank you for sharing Dan. Grant. . . . From dave at horsfall.org Thu Jul 6 11:02:44 2023 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 6 Jul 2023 11:02:44 +1000 (EST) Subject: [COFF] [TUHS] Re: the wheel of reincarnation goes sideways In-Reply-To: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> References: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> Message-ID: On Wed, 5 Jul 2023, Grant Taylor via COFF wrote: > > 21:38:01 up 156 days, 17:15, 454 users, load average: 3.82, 4.40, 4.19 > > tilde% > > Well I'll be. Someone is running a multi-user Unix system. That's > something I've always wanted to do or find someone doing. Is there anyone else here who is not running a Unix box at home? FreeBSD is your friend... My box (aneurin.horsfall.org/aneurin.kfu) is a bit idle right now, but: 10:59AM up 146 days, 17:43, 5 users, load averages: 1.16, 0.65, 0.50 USER TTY FROM LOGIN@ IDLE WHAT dave v0 - 09Feb23 4:37 zsh dave pts/0 mackie.kfu 29Jun23 - w dave pts/1 mackie.kfu 29Jun23 7days tail -F /var/log/ma dave pts/2 mackie.kfu 29Jun23 7days tail -F /var/log/ht dave pts/3 mackie.kfu 29Jun23 1 zsh (Mackie of course is my MacBook) _ -- Dave From crossd at gmail.com Thu Jul 6 12:35:48 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 5 Jul 2023 22:35:48 -0400 Subject: [COFF] [TUHS] Re: the wheel of reincarnation goes sideways In-Reply-To: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> References: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> Message-ID: On Wed, Jul 5, 2023 at 7:59 PM Grant Taylor via COFF wrote: > On 7/5/23 4:48 PM, Dan Cross wrote: > > I thought some folks here might find this interesting. Someone else > > today reminded me of tilde.town, which is a publicly accessible > > machine running Linux. They have a shocking amount of use: > > O.o? > > > tilde% hostname > > tilde.town > > tilde% uname -a > > Linux tilde.town 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 > > UTC 2023 x86_64 x86_64 x86_64 GNU/Linux > > tilde% uptime > > 21:38:01 up 156 days, 17:15, 454 users, load average: 3.82, 4.40, 4.19 > > tilde% > > Well I'll be. Someone is running a multi-user Unix system. That's > something I've always wanted to do or find someone doing. There are a bunch of such systems. https://sdf.org/ has been doing it for decades now, as has M-Net and formerly Grex (which got shut down on April 15 of this year). > > Not quite a thousand users logged in simultaneously, but half that. If > > one counts the number of processes associated with pseudoterminals, > > it's more (I guess a lot of users are running tmux and/or screen). > > :-) > > > The system is also surprisingly modest: 6 cores, 16GiB of RAM and > > about 1TB of storage. > > I can't yet tell if that's six logical CPUs or more. x86_64 cores > /could/ have hyper-threading et al. and more logical CPUs. This was from the output of `top` and `htop`; if SMT is in use, Linux generally reports those as separate LPs, so I'm going to assume that if it only lists 6 CPUs, there are only 6 logical processors (either 6 cores with SMT disabled or 6 virtual CPUs; I don't know if it's a VPS or what). > But still, six contemporary CPUs could be a lot of computing power. > > 16 GB of memory is nothing to sneeze at, especially for running commands > in a CLI environment. -- I'm assuming no daemons saying FEED ME RAM. I think they run a fairly robust web presence including a Mastodon server and some other stuff as well; I see postgresql running, a bunch of other random stuff. Curiously (or not) no SMTP service. I'm told they run a Gopher server, which seems like a waste of time to be, but hey: to each their own. > > It's surprisingly zippy. > > I applied for membership. I'll be interested to see if I'm granted > logon permission. :-) > > Thank you for sharing Dan. Have fun! - Dan C. From coff at tuhs.org Thu Jul 6 14:18:21 2023 From: coff at tuhs.org (Robert Stanford via COFF) Date: Thu, 6 Jul 2023 14:18:21 +1000 Subject: [COFF] [TUHS] Re: the wheel of reincarnation goes sideways In-Reply-To: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> References: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> Message-ID: <7a73463c-cddb-8d65-6549-0f891765ca76@stanford.com.au> On 6/7/23 09:58, Grant Taylor via COFF wrote: > > Well I'll be.  Someone is running a multi-user Unix system. That's > something I've always wanted to do or find someone doing. I still have to occasionally manage a multi user SCO system with a bunch of dusty VT320's scattered through an old building, the original hardware is lost in space and it is now virtualised. There is even a couple of serial line printers. From sjenkin at canb.auug.org.au Thu Jul 6 18:48:32 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Thu, 6 Jul 2023 18:48:32 +1000 Subject: [COFF] Bell System and the Video Game Industry? In-Reply-To: <_l_rdK2ywBoEAheCu4dCFyJ3cyXymIXgMK9-_bgAtMwLXtmr2sZnuRvjFc6jqn6K0X_E2MuSEMm5_iVO7eBeYTOpRHVRuypykZD_au00R-c=@protonmail.com> References: <_l_rdK2ywBoEAheCu4dCFyJ3cyXymIXgMK9-_bgAtMwLXtmr2sZnuRvjFc6jqn6K0X_E2MuSEMm5_iVO7eBeYTOpRHVRuypykZD_au00R-c=@protonmail.com> Message-ID: > On 4 Jul 2023, at 11:57, segaloco via COFF wrote: > > So this evening I've been tinkering with a WECo 2500 I've been using for playing with telecom stuff, admiring the quality of the DTMF module, and it got me thinking, gee, this same craftsmanship would make for some very nice arcade buttons, which then further had me pondering on the breadth of the Bell System's capabilities and the unique needs of the video game industry in the early 80s. > > In many respects, the combination of Western Electric and Bell Laboratories could've been a hotbed of video game console and software development, what with WECo's capability to produce hardware such as coin slots, buttons, wiring harnesses for all sorts of equipment, etc. and then of course the software prowess of the Labs. > > Was there to anyone here's knowledge any serious consideration of this market by Bell? The famous story of UNIX's origins includes Space Travel, and from the very first manual, games of various kinds have accompanied UNIX wherever it goes. It seems that out of most companies, the Bell System would've been very well poised, what with their own CPU architecture and other fab operations, manufacturing and distribution chains, and so on. There's a looooot of R&D that companies such as Atari and Nintendo had to engage in that the Bell System had years if not decades of expertise in. Would anti-trust stuff have come into play in that regard? Bell couldn't compete in the computer market, and I suppose it would depend on the legal definitions applicable to video game hardware and software at the time. > > In any case, undercurrent here is the 2500 is a fine telephone, if the same minds behind some of this WECo hardware had gone into video gaming, I wonder how different things would've turned out. > > - Matt G. Matt, An astute question and one that, IMHO, deserves an answer because, if you’re asking, you never saw AT&T operate as a full throated monopoly. A caveat, I wasn’t ever at Bell Labs, didn’t work in the USA but have talked to folk. The short answer would be “Suits and Lawyers”. Second part is the postscript in Rob Pike’s story / history of Music on the Plan 9 CD. P.S. No, I don’t have the music any more. Too sad to keep. The people on this list who built software and made hardware would’ve put their case to ‘management’ and we know that the answer was “No”. The same response Ken got in 1969 when 127 asked for a PDP-10, forcing him to find the PDP-7. If people haven't responded, it’s because decades later, it’s still too raw. Rachel Chalmers in her 1999 article on John Lions, quotes Dennis Ritchie commenting on Western Electric’s control of Unix V7 and after: "Code Critic” "Even though in the 1970s Unix was not a commercial proposition, USG and the lawyers were cautious. At any rate, we in research lost the argument.” [ for cheap licences & teaching & commentaries ] Chalmers concludes, on Mike Tilson et al at (real) SCO making ‘legacy Unix’ source available for a nominal fee again. [ ?year?] [ someone can correct me on versions & conditions ] "Research, at last, had won." The Bell Labs researchers were very innovative and ‘curious’ - did a whole bunch of stuff in many fields. That management & legal stance of ‘protecting’ all I.P. it could claim and trying to charge as much as it could, how did it work out for them? In 1974, Ken, Dennis et al launched Unix to the world via CACM. In 1984, AT&T ‘demerged’ in the ‘Baby Bells’ and the new AT&T keeping Bells Labs, Western Electric (?) and ‘Long Lines’. This allowed them to compete with IBM et al in Computers and Software (and vice versa, IBM bought Rolm & tried telephony) With USL and the large number of Unix licences granted with _zero_ marketing and support, I’m guessing the “smart managers” thought they’d create another massive fortune. In 1994, AT&T sold off their Computers (to NCR) and Software (Unix) to Novel, who’d already paid for some of it. [ Novel sold on USL and some rights to SCO later, which led to the “new SCO” suit against The World, ] [ claiming Linux infringed its I.P. and it was owed gazillions in back payments from anyone who could even spell Linux. ] [ smarter people than me will correct this, I’m sure ] In ~2004, AT&T was bought by one of the Baby Bells, SBC, which kept the name but changed the business culture. The Proof is in the Pudding… AT&T management in the 1960’s & 70’s thought they could ‘milk’ Unix and new IC-based computers in the same way they’d milked the telephone business since Alexander Graham Bell invented a working telephone circa 1875. Their mismanagement killed the business, causing Bell Labs as we knew it, to eventually fade away. I hope that’s somewhat an answer for me, if not correct & complete, it also explains why the ‘combatants’ aren’t keen to talk about their experiences. all my best steve -- 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 sjenkin at canb.auug.org.au Thu Jul 6 18:58:02 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Thu, 6 Jul 2023 18:58:02 +1000 Subject: [COFF] Advice sought: what to eventually do with my 1977 Lions Commentary? Message-ID: <5E647D93-0DA8-4891-B7E1-D6FB86065DAF@canb.auug.org.au> I’ve no intention of selling these items and am definitely NOT disposing of them yet. No ‘offers’ please. In 1977, I took John’s “Operating Systems” course, and was one of 60-80 students who bought the first print run of the Commentary. I’m looking for suggestions of what to do with these three items pictured, some ideas of what to put in my will or donate before I go. Warren doesn’t need Yet Another Copy, he has some better copies already :) They aren’t in pristine condition and I made notes in both books, in pencil at least. The cover of the red book has slightly deteriorated. steve j PS: if the image is stripped by the list, a copy at: -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SteveJ_Lions-Commentary.jpeg Type: image/jpeg Size: 67218 bytes Desc: not available URL: From coff at tuhs.org Fri Jul 7 02:47:59 2023 From: coff at tuhs.org (Grant Taylor via COFF) Date: Thu, 6 Jul 2023 11:47:59 -0500 Subject: [COFF] [TUHS] Re: the wheel of reincarnation goes sideways In-Reply-To: References: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> Message-ID: On 7/5/23 8:02 PM, Dave Horsfall wrote: > Is there anyone else here who is not running a Unix box at home? FreeBSD > is your friend... I've got many /single/ user boxen at home (and elsewhere), both physical and virtual. I was specifically referring to /multiple/ user boxen. It seems to me that with the ease with which we can create (virtual) Unix boxen, the vast majority of them tend to be /single/ user or single purpose boxen. As such the proportion of /multi/ user boxen seems to be significantly reduced. So, to me, a /multi/ user boxen tends to stand out compared to the sea of /single/ user boxen. Grant. . . . From coff at tuhs.org Fri Jul 7 02:53:35 2023 From: coff at tuhs.org (Grant Taylor via COFF) Date: Thu, 6 Jul 2023 11:53:35 -0500 Subject: [COFF] [TUHS] Re: the wheel of reincarnation goes sideways In-Reply-To: <7a73463c-cddb-8d65-6549-0f891765ca76@stanford.com.au> References: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> <7a73463c-cddb-8d65-6549-0f891765ca76@stanford.com.au> Message-ID: <7f0a5d70-6a89-f57c-3a1d-01619421a461@tnetconsulting.net> On 7/5/23 11:18 PM, Robert Stanford via COFF wrote: > I still have to occasionally manage a multi user SCO system with a bunch > of dusty VT320's scattered through an old building, the original > hardware is lost in space and it is now virtualised. There is even a > couple of serial line printers. I administer a handful of physical Sun / Oracle boxen running Solaris at $DAY_JOB, each with a handful of local zones thereon. The local zones have multiple people logging and running an application. But these users aren't Unix users per-se. Rather they are running a singular line of business application (or very closely related / associated applications). This is vastly different than what I consider to be a shell box, wherein people do all sort of things on the system: - email - web - document processing - programming - etc It's the multiple users doing different things on a common box that seems so rare to me in 2023. Grant. . . . From athornton at gmail.com Fri Jul 7 03:54:48 2023 From: athornton at gmail.com (Adam Thornton) Date: Thu, 6 Jul 2023 10:54:48 -0700 Subject: [COFF] [TUHS] Re: the wheel of reincarnation goes sideways In-Reply-To: <7f0a5d70-6a89-f57c-3a1d-01619421a461@tnetconsulting.net> References: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> <7a73463c-cddb-8d65-6549-0f891765ca76@stanford.com.au> <7f0a5d70-6a89-f57c-3a1d-01619421a461@tnetconsulting.net> Message-ID: Multiple users doing different things on what _appears_ to be a common box has become pretty rare, I will grant (although that lovely Slack-in-five-lines-of-shell thing that was recently posted maybe here, maybe not, was very cute). But of course almost everything that's not happening inside your own house or your own on-prem data center is many, many, many users on a single box, each virtualized somehow (whether that be a classical VM, or a paravirt KVM guest, or just an OCI container) so each user has the experience of having a machine to themself. It's like it's 1967 again! Welcome to CP/40! Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Fri Jul 7 08:29:09 2023 From: coff at tuhs.org (segaloco via COFF) Date: Thu, 06 Jul 2023 22:29:09 +0000 Subject: [COFF] Bell System and the Video Game Industry? In-Reply-To: References: <_l_rdK2ywBoEAheCu4dCFyJ3cyXymIXgMK9-_bgAtMwLXtmr2sZnuRvjFc6jqn6K0X_E2MuSEMm5_iVO7eBeYTOpRHVRuypykZD_au00R-c=@protonmail.com> Message-ID: > Their mismanagement killed the business, causing Bell Labs as we knew it, to eventually fade away. > > I hope that’s somewhat an answer for me, if not correct & complete, it also explains why the ‘combatants’ > aren’t keen to talk about their experiences. > > all my best > steve Oh I know that struggle all too well, what potential are we on the cusp of vs. what do the suits want/need. Given WECo's legacy in the audio realm, I find that Plan9 story particularly disheartening, electrified (audio) signals and the complex manipulation and supplementation thereof is what one would think is the chief concern of a telecom behemoth. I'd never heard the bit about the hardware business winding up with NCR, although I guess I've never looked in that direction as hard as the USL path through Novell. That gives me more to study in my nebulous 3B20 and kin research. I'm glad I wasn't in the know at the time of all the SCO stuff (and was a kid that didn't care) because I probably would've shoved all sorts of feet into my mouth in the sorts of debates over software freedom that were going on at the time. Looking back, that must've been such a frustrating time, I don't blame folks for coming out of that with battle scars. Well now I've got this morbid curiosity to see if I can FPGA a WE32000-ish video game console...but that goes on the endless pile of "eventually"s. Thanks for the background Steve! - Matt G. From brad at anduin.eldar.org Fri Jul 7 09:12:30 2023 From: brad at anduin.eldar.org (Brad Spencer) Date: Thu, 06 Jul 2023 19:12:30 -0400 Subject: [COFF] Bell System and the Video Game Industry? In-Reply-To: (message from steve jenkin on Thu, 6 Jul 2023 18:48:32 +1000) Message-ID: steve jenkin writes: >> On 4 Jul 2023, at 11:57, segaloco via COFF wrote: >> >> So this evening I've been tinkering with a WECo 2500 I've been using for playing with telecom stuff, admiring the quality of the DTMF module, and it got me thinking, gee, this same craftsmanship would make for some very nice arcade buttons, which then further had me pondering on the breadth of the Bell System's capabilities and the unique needs of the video game industry in the early 80s. >> >> In many respects, the combination of Western Electric and Bell Laboratories could've been a hotbed of video game console and software development, what with WECo's capability to produce hardware such as coin slots, buttons, wiring harnesses for all sorts of equipment, etc. and then of course the software prowess of the Labs. >> >> Was there to anyone here's knowledge any serious consideration of this market by Bell? The famous story of UNIX's origins includes Space Travel, and from the very first manual, games of various kinds have accompanied UNIX wherever it goes. It seems that out of most companies, the Bell System would've been very well poised, what with their own CPU architecture and other fab operations, manufacturing and distribution chains, and so on. There's a looooot of R&D that companies such as Atari and Nintendo had to engage in that the Bell System had years if not decades of expertise in. Would anti-trust stuff have come into play in that regard? Bell couldn't compete in the computer market, and I suppose it would depend on the legal definitions applicable to video game hardware and software at the time. >> >> In any case, undercurrent here is the 2500 is a fine telephone, if the same minds behind some of this WECo hardware had gone into video gaming, I wonder how different things would've turned out. >> >> - Matt G. > > Matt, > > An astute question and one that, IMHO, deserves an answer because, if you’re asking, you never saw AT&T operate as a full throated monopoly. > A caveat, I wasn’t ever at Bell Labs, didn’t work in the USA but have talked to folk. > > The short answer would be “Suits and Lawyers”. [None of the following really answers the original question, but may be interesting anyway] So... I wasn't there for the earlier times, certainly not the monopoly days, but I was there later and (in my opinion) until Lucent more or less fell apart (and maybe after that), AT&T and all of the companies it spawned still acted like a monopoly in a lot of ways (and I include the Baby Bells in that). Yes, it was often about "Suits and Lawyers"... [snip] > That management & legal stance of ‘protecting’ all I.P. it could claim and trying to charge as much as it could, > how did it work out for them? That persisted until I left in the early 2000s. I had a account rep say that they had no idea how much anything costed because each customer was charged something different. More or less it came down to "Charge the customer as much as you can get away with". As a developer, we certainly didn't have any idea for what a end customer was paying. Maybe an interesting side story.... I was sold as a Value Added Service once for $40,000 to a end customer. I went on site to two different locations that the customer had, and performed about 8 hours of work all told spread out over two days. The sales person who sold this VAS to the customer was very worried that the customer would be unhappy if I didn't spend a week on the effort... personally I just wanted to get the work done and get home, and I knew that the customer would be happy with it taking only two days... [snip] > In 1994, AT&T sold off their Computers (to NCR) and Software (Unix) to Novel, who’d already paid for some of it. I was there more or less for the NCR thing.... what I remember is that it was bought to get access to a computer platform outright. NCR was renamed GIS and later spun back out of AT&T as NCR again (if I remember it all correctly). My group was forced to port our application platform to GIS even though we wanted to move to HP instead. When GIS didn't pan out for us (in the end) we ended up on HP anyway. [snip] > AT&T management in the 1960’s & 70’s thought they could ‘milk’ Unix and new IC-based computers in the same way > they’d milked the telephone business since Alexander Graham Bell invented a working telephone circa 1875. The management thought that they could milk EVERYTHING. The product I worked on was ported and ported and ported starting with a VAX running SVR3 (or maybe something earlier) to an HP (when I left)... I suppose it makes some sense, as it made money as it was, but it was really hard to innovate. I managed to do it a couple of times, but my efforts were really rare. The product I worked on was pure software doing traffic management on a classic circuit switched phone network. But, as best as I can tell, products like the 5ESS did the same thing. As I remember it, the 5ESS-2000 was the 5E software running on a couple of Sun sparcs in a emulator. Some of the assembly happened at 6200 Broad St. and I got to observe some of it while walking around the factory floor after lunch. I recall two sparc servers hooked together with an internal Ethernet switch. Slap all of that in a 5E cabinet and you were good to go. Part of this stagnate nature was the demand of the customer base in the US, for the product I worked on, at least... they did tend to demand that nearly NOTHING change about the product at all (at least at the time). > Their mismanagement killed the business, causing Bell Labs as we knew it, to eventually fade away. I agree pretty much with that, but probably have somewhat different reasoning as to the why. I see it more as the management had little idea as to what they had a lot of the time. I worked with a guy who had been there a lot longer then I had... something like 20 years when I started... and I don't think he had ever worked on a product in the 20 years UNTIL he arrived on ours that ever actually went to market and if it did ever lasted any great length of time. A lot of the stuff he worked on was pretty neat, but was either in the wrong place at the wrong time, or was mismarketed or honestly was just silly (i.e. some product to stroke the ego of someone in management). [snip] > all my best > steve > > -- > 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 -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From sjenkin at canb.auug.org.au Sat Jul 8 17:45:36 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Sat, 8 Jul 2023 17:45:36 +1000 Subject: [COFF] Butler Lampson's 1973 Xerox PARC memo "Why Alto?" Message-ID: <5E4113AB-AAF8-42D1-9A75-DF6BF659251A@canb.auug.org.au> What struck me reading this is the estimated price (~$10K) to build an Alto, elsewhere I’ve seen $12K and 80 built in the first run. [ a note elsewhere says $4,000 on 128KB of RAM. 4k-bit or 16-kbit chips? unsure ] I believe the first "PDP-11” bought by 127 at Bell Labs was ~$65k fully configured (Doug M could confirm or not), although the disk drive took some time to come. Later, that model was called PDP-11/20. Why the price difference? PARC was doing DIY - it’s parts only, not a commercial production run with wages, space, tooling & R+D costs and marketing/sales to be amortised, with a 80%+ Gross Margin required, as per DEC. Why didn’t Bell Labs build their own “Personal Computer” like PARC? They had the need, the vision, the knowledge & expertise. I’d suggest three reasons: - The Consent Decree. AT&T couldn’t get into the Computer Market, only able to build computers for internal use. They didn’t need GUI PC’s to run telephone exchanges. - Bell Labs management: they’d been burned by MULTICS and, rightly, refused the CSRC a PDP-10 in 1969. - Nobody ’needed’ to save money building another DIY low-performance device. A home-grown supercomputer maybe :) It’s an accident of history that PARC could’ve, but didn’t, port Unix to the Alto in 1974. By V7 in 1978, my guess it was too late because both sides had locked in ‘commercial’ positions and for PARC to rewrite code wasn’t justified: “If it ain’t Broke”… Porting Unix before 1974 was possible: PARC are sure to have had close contact with UC Berkeley and the hardware/software groups there. Then 10 years later both Apple and Microsoft re-invent Graphical computing using commodity VLSI cpu’s. Which was exactly the technology innovation path planned by Alan Kay in 1970: build today what’ll be cheap hardware in 10 years and figure out how to use it. Ironic that in 1994 there was the big Apple v Microsoft lawsuit over GUI’s & who owned what I.P. Xerox woke up up midway through and filed their own infringement suit, and lost. [ dismissed because approx they'd waited too long ] ============== PDF: Other formats: ============== -- 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 mparson at bl.org Mon Jul 10 00:55:41 2023 From: mparson at bl.org (Michael Parson) Date: Sun, 09 Jul 2023 09:55:41 -0500 Subject: [COFF] [TUHS] Re: the wheel of reincarnation goes sideways In-Reply-To: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> References: <08ed6c3a-f2d3-590c-7de4-e01164271da1@tnetconsulting.net> Message-ID: <0e0064dae74c2275ca50ac6453457eef@bl.org> On 2023-07-05 18:58, Grant Taylor via COFF wrote: > On 7/5/23 4:48 PM, Dan Cross wrote: >> I thought some folks here might find this interesting. Someone else >> today reminded me of tilde.town, which is a publicly accessible >> machine running Linux. They have a shocking amount of use: > > O.o? > >> tilde% hostname >> tilde.town >> tilde% uname -a >> Linux tilde.town 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 >> UTC 2023 x86_64 x86_64 x86_64 GNU/Linux >> tilde% uptime >> 21:38:01 up 156 days, 17:15, 454 users, load average: 3.82, 4.40, >> 4.19 >> tilde% > > Well I'll be. Someone is running a multi-user Unix system. That's > something I've always wanted to do or find someone doing. > >> Not quite a thousand users logged in simultaneously, but half that. If >> one counts the number of processes associated with pseudoterminals, >> it's more (I guess a lot of users are running tmux and/or screen). There's also nyx.net. I've had an account with them since it was nyx.cs.du.edu and was run on a Sun Sparcstation 10 and a Sparcstation 2 running SunOS 4.1.x. At some point in the late 90s/early 2000s, they moved to x86 systems running Linux. Looks like it has been running in AWS since 2016 or so. Currently is running on Ubuntu 20.04. Near as I can tell, they are still accepting new signups. I've been running this domain (bl.org) as a multi-user system for friends and family for a few decades. Started out on my Amiga 3000 running NetBSD 1.6 hanging off my ISDN line at home, then a friend donated his DEC Multia/Alpha system to the cause. When I changed jobs and lost the ISDN, I found a local colo and built a 1U x86 system which lasted for a few years, bouncing between colos as I found better deals, and is now a VM with Linode, still running NetBSD (8.1, need to update it one of these days). I think I'm down to about 3 active users these days, peaked at about maybe 8-10. Most of my users just use me for pop/imap/web mail that isn't one of the major free providers, though I also provide primary/secondary DNS and MX for a few domains run by friends. -- Michael Parson Pflugerville, TX From jnc at mercury.lcs.mit.edu Mon Jul 10 05:50:22 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 9 Jul 2023 15:50:22 -0400 (EDT) Subject: [COFF] Butler Lampson's 1973 Xerox PARC memo "Why Alto?" Message-ID: <20230709195022.DA64318C08F@mercury.lcs.mit.edu> > From: steve jenkin > What struck me reading this is the estimated price (~$10K) to build an > .. [ a note elsewhere says $4,000 on 128KB of RAM. 4k-bit or 16-kbit > chips? unsure ] 16K (4116) - at least, in the Alto II I have images of. Maxc used 1103's (1K), but they were a few years before the Alto. > I believe the first "PDP-11" bought by 127 at Bell Labs was ~$65k fully > configured I got out my August 1971 -11/20 price sheet, and that sounds about right. The machine had "24K bytes of core memory .. and a disk with 1K blocks (512K bytes ... a single .5 MB disk .. every few hours' work by the typists meant pushing out more information onto DECtape, because of the very small disk." ("The Evolution of the Unix Time-sharing System"): 11,450 Basic machine CPU + 8KB memory 6,000 16KB memory (maybe 7,000, if MM11-F) 4,000 TC11 DECtape controller 4,700 TU56 DECtape transport 5,000 RF11 controller 9,000 RS11 drive 3,900 PC11 paper tape ------- 44,050 (Although Bell probably got a discount?) The machine later had an RK03: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u0.s but that wasn't there initially (they are 2.4MB, larger than the stated disk); it cost 5,900 (RK11 controller) + 9,000 (RK03 drive). Also, no signs of the KE11-A in the V1 code (1,900 when it eventually appeared). The machine had extra serial lines (on DC11's), but they weren't much; 750 per line. > Why the price difference? Memory was part of it. The -11/20 used core; $9,000 for the memory alone. Also, the machine was a generation older, the first DEC machine built out of IC's - all SSI. (It wasn't micro-coded; rather, a state machine. Cheap PROM and SRAM didn't exist yet.) Noel From clemc at ccc.com Mon Jul 10 07:03:19 2023 From: clemc at ccc.com (Clem Cole) Date: Sun, 9 Jul 2023 17:03:19 -0400 Subject: [COFF] Butler Lampson's 1973 Xerox PARC memo "Why Alto?" In-Reply-To: <5E4113AB-AAF8-42D1-9A75-DF6BF659251A@canb.auug.org.au> References: <5E4113AB-AAF8-42D1-9A75-DF6BF659251A@canb.auug.org.au> Message-ID: Steve - I'm going to do a small rebuttal here. You ask an interesting question as we look back on history, but to be honest I. think the real thing is that neither the Xerox folks nor the BTL folks in those days were actually paying that much attention to each other AND they were considering different problems. It turns out, if they had "blended" their idea, maybe the workstation world that would be birthed in the mid-1980s might have been different. On Sat, Jul 8, 2023 at 3:45 AM steve jenkin wrote: > What struck me reading this is the estimated price (~$10K) to build an > Alto, elsewhere I’ve seen $12K and 80 built in the first run. > [ a note elsewhere says $4,000 on 128KB of RAM. 4k-bit or 16-kbit chips? > unsure ] > I'm pretty sure the first Alto's used Intel 1103A (1Kx1), although the Intel 2106 (4Kx1) was coming on the scene - you would have to ask Roger Bates if he remembers, as I believe that he designed the original memory boards for Alto. That said, by the time of the second generation Alto's, Roger and Chuck switched to a Mostek MK4116 - at least, that is my memory from the ones we had a CMU a few years later. > I’d suggest three reasons: > > - The Consent Decree. AT&T couldn’t get into the Computer Market, > only able to build computers for internal use. > They didn’t need GUI PC’s to run telephone exchanges. > Put differently -- solving different markets. Xerox was in the office automation business - which was based on selling paper for their coping machines. Bob Taylor's real vision was that for all of the "paperless office" comments of the day, he realized Xerox could sell way more paper if it were easier to produce. The Alto was thinking that at some time a currently very expensive piece of equipment (the computer), would be cost-effective. How would it be useful for an office? > > - Bell Labs management: > they’d been burned by MULTICS and, rightly, refused the > CSRC a PDP-10 in 1969. > > - Nobody ’needed’ to save money building another DIY > low-performance device. > A home-grown supercomputer maybe :) > BTL was trying to figure out how to more efficiently write/program and deploy them to aid in running a complex switching system - their business. Again the idea of a computing "utility" was often discussed. Computers cost big money to buy, deploy and operate. How do you use them better? > > > It’s an accident of history that PARC could’ve, but didn’t, port Unix to > the Alto in 1974. > Ouch ... not so fast. First, the HW lacked an MMU. I had to teach Roger how they worked 5 years later when we built Magnolia and why they were a good idea [I did the basic design of the Magonia MMU so we could run UNIX]. I remember Roger telling me at the time, that Thacker and Lampson didn't think they needed them if the computer was only being used for one purpose. BTW: that was the same argument Jobs used a few years later when Motorola offered them at a bargain price the optional MMU chip for the MAC design they were developing because 68000 designers (Nick, Les, and team) had used PDP-11s at Schumblege before then went to Motorola. They knew that not having an MMU was going to be a real problem, plus they had used a UNIX box to help design their chip. Second, Ken does not do his sabbatical to UCB until 1975. While Butler still had a fondness for UCB, there was not much interaction by then. At the time, the primary computer at UCB was a CDC6600, and there was more influence from "up the hill" on EECS from LBL than from PARC [and remember that national labs like LBL are primarily using supers from CDC and later Cray]. Also please remember that the "CS" types on the ARPANET are PDP-10 folks. UCB does not have one. In fact, the original ARPAnet connection eventually to Ing70 was a VDH interface that ran down the hill from the IMP at LBL, and that would not come for a few years yet. PARC had much more influence at Stanford than at UCB. Stanford was on the ARPANET [UCB was not for a long time yet] and Stanford was using PDP-10s. PARC's Frankenstein MAXC was a PDP-10 clone with an Alto for its front end instead of a PDP-11. > By V7 in 1978, my guess it was too late because both sides had locked in > ‘commercial’ positions and for PARC to rewrite code wasn’t justified: “If > it ain’t Broke”… Hmmmm, the PARC folks were rewriting code at this time. The original Alto is mostly BCPL and "Nova-Code" ( the original DG Nova microcode Bulter and Chuck created). By 1978, both Smalltalk and Cedar had been built at PARC. Also, think about why Ethernet was created? Metcalfe and Boggs proposed it as a way to connect the different processors in a high-end Xerox copier. It's used as a "network" that we know it was after they built it. PUP and things like the Press format [later XNS and Interpress come later]. So, I don't think it was anything more than just focus. PARC was solving one problem with the Alto and the BTL folks created UNIX to solve another. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Mon Jul 10 07:51:52 2023 From: stewart at serissa.com (Larry Stewart) Date: Sun, 9 Jul 2023 17:51:52 -0400 Subject: [COFF] Butler Lampson's 1973 Xerox PARC memo "Why Alto?" In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From rtomek at ceti.pl Mon Jul 10 19:08:04 2023 From: rtomek at ceti.pl (Tomasz Rola) Date: Mon, 10 Jul 2023 11:08:04 +0200 Subject: [COFF] Reader, paper, tablet, phone (was: Re: Reading PDFs on a mobile. (Was: Requesting thoughts on extended regular expressions in grep.)) In-Reply-To: <4dcc6c-4689-3fd6-5438-c8c4bba7f0f6@bl.org> References: <8d1de5c8-1f34-3d37-395d-0f1da7b062ec@spamtrap.tnetconsulting.net> <20230303105928.E88AB215AA@orac.inputplus.co.uk> <20230303134215.3ED63215AA@orac.inputplus.co.uk> <21e8477c-c388-7b90-ed10-21c7f76f0892@spamtrap.tnetconsulting.net> <20230304101533.D9CCF2021A@orac.inputplus.co.uk> <36b395af-caa2-f685-cc54-5f193cd8b1e2@bl.org> <4dcc6c-4689-3fd6-5438-c8c4bba7f0f6@bl.org> Message-ID: On Thu, Jun 22, 2023 at 10:45:43AM -0500, Michael Parson wrote: > On Tue, 20 Jun 2023, Tomasz Rola wrote: > > On Tue, Jun 20, 2023 at 11:02:33AM -0500, Michael Parson wrote: > > > [...] > > a. have sd card slot in a reader (I mean hardware with e-ink, not some > > app on a phone). This means a card can be slipped into the box without > > opening it. This means the box is not water-proof. However, I had a > > look inside and I suspect it can still be water-prooved with duct > > tape, if someone wants it so much. > Hello again and sorry for the late answer. Busy, hardware glitches, tired, etc. > (For the record, the "device" I'm discussing is my Boox Nova Air 7.8" E Ink > tablet, Amazon product B09FQ14Z6N.) > > What are you wanting/needing an SD card for? Extra storage? > File-transfer? For what I use this device for, the built-in storage > (32GB) has been more than enough to hold the books & notes I need it to. There is no use pattern as such. It was just very convenient to have one. When I bought my first reader, PocketBook 622 (or something like it, a good decade ago), it only had 2GB of flash. Of this, about half was already prefilled with free ebooks, free photos to see in some app. I decided to keep all this, which left me with .LT. 1GB for my use. If I wanted just epubs, this was more than enough to have few thousands files. But, an atlas of human anatomy from Internet Archive was ca. 8MB, Lisp 1.5 manual from bitsavers was another 9MB and if I wanted some more, space would quickly ran out. An 8GB card solved the problem. Later on, a member of family fell in love with e-reader, too. But, in her hands they died rather quickly. So we struck a deal - she will buy me a new one and get mine, which after a year of use was still mostly like new. I just replugged SD card and it was it. Now I have two broken Pocketbooks 622 in a drawer, waiting for their chance - just replace their displays. Later on, I bought me an Inkpad (again from Pocketbook, probably I am a fanboy). This one had about 7.8'' display, many more inky pixels and not too big cpu, so was a bit sluggish. But I liked it. Alas, it entered nirvana as a result of botched upgrade. If I am to believe internet, it can be pulled back into this world with the help of specially crafted serial cable and kermit. So, later on I bought me a Pocketbook 633 (definitely a fanboy!). This one can display 256 colors on outer LCD display and 16 levels of grey on inner e-ink display, which combines into 4096 colors. I wanted to give it a try, but if this specimmen dies, I will go back to normal e-ink b/w. The colors are there, but nothing outstanding. Ok for office kind of documents - pie charts, graphs etc. Space photographs, ukiyo-e, n nono no. Besides, if I use color, it powers on the LCD layer and consumes significantly more power than when it goes with e-ink only. For some documents, color can be turned off, for icons on main page, they show in color. Each time I just replug the card. So next time, I guess I will be looking for another reader with a slot. As of what you write about using cable and or BT for file transfer, it is all true but if reader does not work anymore, it might be hard to get files back. Or impossible. I have a smartphone, just to make a photo sometimes, nothing more, and I store it all on sdcard, again. This one phone does not want to emulate pendrive when I plug it into my Linux box, I had to install ftp server on it (phone). If it dies, I will unplug the card. Easy as a pie. No need to spend days looking for some bloody program which maybe is Windows-XP-only or maybe just been dropped from manufacturer support website. So I guess my next phone should better have a socket for sdcard, too. This is the future - if I have a need to support, I need to support it by me. Investing money in something that may turn into a brick and get my stuff with it - I do not think so. Too bad if some manufacturer does not want to play along, but they come by a dozen so maybe I can find what I want :-)... [...] > This device does not advertise any water-proofing at all. Well, somehow all readers without sdcard tout about them being waterproof. Like I wanted to read in water. [...] > The exception to this is my watch. I have a Fossil Hybrid smart-watch. > It's an analog watch with an e-ink background that can show me > alerts/info from my phone. It only needs to be charged about once every > 10 days or so. I don't want a watch that I'd have to recharge daily. I bought me a cheap mechanical clock from China (say, 17 bucks). It only needs a "mechanical recharge" once a day and I have to turn it back 5 minutes once a week to keep it somewhat accurate. Good enough for me. [...] > The other thing I use this device for is for hand-written notes and > sketches. Writing on the screen with the stylus feels a lot like > writing with a pencil on paper. I'm not an artist by any stretch, but > sometimes writing things out and using boxes, circles, helps sort things > out in my head, or sometimes I'll sketch things out while working on a > design I eventually want to 3d print. All stuff I'd historically done in > a paper notebook, but now I have similarly-sized electronic notepad > where I can erase mistakes, have layers to my drawings (like > photoshop/gimp/etc), zoom in/out, etc. Well I went the other way - bought some pencils to see how it goes with paper notes. Color crayons, some other thingies for making circles and lines (compass, ruler). Now, seems I will have to make some kind of notebook (in a future, not now) because what I see in my shops somehow does not convince me to buy (yeah I know about moleskines and leichturms, but this is not what I want, not sure what I want). Right now, it is just a normal crappy school notebook but with nice cover :-) . > The notepad app is also linked to my DropBox account, so when I'm done > with whatever doodles/notes/sketches, I can then load them up on one > of my other systems as PDFs. I've even toyed with the idea of writing "Dropbox baaad, shoe box good" :-) -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From coff at tuhs.org Mon Jul 24 07:20:37 2023 From: coff at tuhs.org (segaloco via COFF) Date: Sun, 23 Jul 2023 21:20:37 +0000 Subject: [COFF] Seeking Some Books (Primarily Standards) Message-ID: Good afternoon or whichever time of day you find yourself in. I come to you today in my search for some non-UNIX materials for a change. The following have been on my search list lately in no particular priority: - Standards: COBOL 68 C 89 C++ 98 Minimal BASIC 78 Full BASIC 87 SQL (any rev) IS0 9660 (CD FS, any rev) ISO 5807 (Flow Charts, any rev) - Manuals: PDP-11/20 Processor Handbook (EAE manual too if it's separate) WE32000 and family literature GE/Honeywell mainframe and G(E)COS documents The IBM 704 FORTRAN Manual (The -original- FORTRAN book) The Codasyl COBOL Report (The -original- COBOL book) Any Interdata 7 or 8/32 documentation (or other Interdata stuff really) The Ti TMS9918 manual The Philips "Red Book" CDDA standard If it's part of one, the Bell System Practices Issue containing, or separately otherwise, BSP 502-503-101 (2500 and 2554 reference) If any of these are burning a hole in your bookshelf and you'd like to sell them off, just let me know, I'll take em off your hands and make it worth your while. I'm not hurting for any of them, but rather, I see an opportunity to get things on my shelf that may facilitate expansion of some of my existing projects in new directions in the coming years. Also, I'm in full understanding of the rarity of some of these materials and would like to stress my interest in quality reference material. Of course, that's not to dismiss legitimate valuation, rather, simply to inform that I intend to turn no profit from these materials, and wherever they wind up after their (hopefully very long) tenure in my library will likely have happened via donation. - Matt G. P.S. On that last note, does anyone know if a CHM registration of an artifact[1] means they truly have a physical object in a physical archive somewhere? That's one of the sorts of things I intend to look into in however many decades fate gives me til I need to start thinking about it. [1] - https://www.computerhistory.org/collections/catalog/102721523 From jnc at mercury.lcs.mit.edu Mon Jul 24 10:50:29 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 23 Jul 2023 20:50:29 -0400 (EDT) Subject: [COFF] Seeking Some Books (Primarily Standards) Message-ID: <20230724005029.A6C9418C084@mercury.lcs.mit.edu> > From: Matt G. > PDP-11/20 Processor Handbook > (EAE manual too if it's separate) Yes and no. There are separate manuals for the EAE (links here: https://gunkies.org/wiki/KE11-A_Extended_Arithmetic_Element https://gunkies.org/wiki/KE11-B_Extended_Arithmetic_Element the -B is the same to program as the -A; its implementation is just a single board, though) but the -11/20 processor handbook (the second version; the one dated 1972) does have a chapter (Chapter 8; Part I) on the EAE. (For no reason I can understand, neither the -11/05 nor the -11/04 processor handbook covers the EAE, even though neither one has the EIS, and if you need multiply/etc in hardware on either one, the EAE is your only choice). Noel From stuff at riddermarkfarm.ca Mon Jul 24 11:10:10 2023 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Sun, 23 Jul 2023 21:10:10 -0400 Subject: [COFF] Seeking Some Books (Primarily Standards) In-Reply-To: References: Message-ID: <4dff1dd1-d6d9-d1e6-44a1-b8f74a703e05@riddermarkfarm.ca> Greetings, Matt. On 2023-07-23 17:20, segaloco via COFF wrote: > Good afternoon or whichever time of day you find yourself in. I come to you today in my search for some non-UNIX materials for a change. The following have been on my search list lately in no particular priority: > > - Standards: > COBOL 68 > C 89 > C++ 98 > Minimal BASIC 78 > Full BASIC 87 > SQL (any rev) > IS0 9660 (CD FS, any rev) > ISO 5807 (Flow Charts, any rev) [...] > Also, I'm in full understanding of the rarity of some of these materials and would like to stress my interest in quality reference material. Of course, that's not to dismiss legitimate valuation, rather, simply to inform that I intend to turn no profit from these materials, and wherever they wind up after their (hopefully very long) tenure in my library will likely have happened via donation. > > - Matt G. If you are willing to pay exorbitant amounts, most of the standards are available from the ISO store (e.g., C89: https://www.iso.org/standard/74528.html , ISO5807: https://www.iso.org/standard/11955.html , ISO9660: https://www.iso.org/standard/81979.html , and so on). Sincerely, john From coff at tuhs.org Tue Jul 25 17:41:44 2023 From: coff at tuhs.org (Warren Toomey via COFF) Date: Tue, 25 Jul 2023 17:41:44 +1000 Subject: [COFF] Wanted: 16-bit big-endian Unix-like environment and/or libc Message-ID: Hi all, I'm looking for a 16-bit big-endian Unix-like development environment with a reasonably new C compiler and a symbolic debugger. And/or, a libc with source code suitable for a 16-bit big-endian environment. Rationale: I've designed and built a 6809 single board computer (SBC) with 8K ROM, 2K I/O space for a UART and block storage, and 56K RAM. It's a big-endian platform and the C compiler has 16-bit ints by default. I've been able to take the filesystem code from XV6 and get it to fit into the ROM with a hundred bytes spare. The available Unix-like system calls are: dup, read, write, close, fstat, link, unlink, open, mkdir, chdir, exit, spawn and the spawn is like exec(). There is no fork() and no multitasking. I've got many of the existing XV6 userland programs to run along with a small shell that can do basic redirection. Now I'm trying to bring up a libc on the platform. I'm currently trying the libc from FUZIX but I'm not wedded to it, so alternative libc recommendations are most welcome. There's no debugging environment on this SBC. I do have a simulator that matches the hardware, but I can only breakpoint at addresses and single-step instructions. It makes debugging pretty tedious! So I was thinking of using an existing Unix-like platform to bring up the libc. That way, if there are bugs, I can use an existing symbolic debugger on the platform. I could use 2.11BSD as the dev platform but it's little-endian; I'm worried that there might be endian issues that stop me finding bugs that will arise on the 16-bit 6809 platform. As for which libc: I looked at the 2.11BSD libc/include and there's so much stuff I don't need (networking etc.) that it's hard to winnow down to just what I need. The FUZIX libc looks good. I just came across Elks and that might be a possible alternative. Are there others to consider? Anyway, thanks in advance for your suggestions. Cheers, Warren References: XV6: https://github.com/mit-pdos/xv6-public FUXIZ: https://github.com/EtchedPixels/FUZIX/tree/master/Library Elks: https://github.com/jbruchon/elks/tree/master/libc From clemc at ccc.com Wed Jul 26 00:07:37 2023 From: clemc at ccc.com (Clem Cole) Date: Tue, 25 Jul 2023 10:07:37 -0400 Subject: [COFF] Wanted: 16-bit big-endian Unix-like environment and/or libc In-Reply-To: References: Message-ID: Warren - can not help you other than some thoughts/pointers for some next steps. 1. https://www.noicedebugger.com/ - it's not FOSS and you have to buy it. No idea how good it is. 2. OS9 was a Unix-like system for the MC6809 back in the day -- maybe look for tools for that. 3. http://www.compilers.de/vbcc.html is a full ISO C99 C compiler that is very portable and targets a number of 8-bit and 16-bit processors including the MC6809 4. WRT to the symbolic debugger, the issue will be 8/16-bit and big-endian. There were numerous ports of Mark Linton's dbx (it should be on the 4.2 BSD - tape it was his thesis). Dbx was the predecessor to gdb and was used to make a number of MC68K debuggers such as the original ones at Masscomp and Sun. But address space is likely to be an issue since Mark wrote it for a vax originally. 5. Since the MOS6502 was so ubiquitous and it is also big-endian since its "parent" was the MC6800 (Moto developed the MC6809 as the MC6800 follow on, in response to it when Peddle and team left Moto to build the MOS6501 and MC6502). So you might look for tools for it and retarget - there are numerous "C 6502" tool kits in the wild. There are simulators that I know about and often they have an embedded, but I never looked for a pure debugger. https://github.com/unoCamel/6502-Debugger claims its a debugger but I think it more of simulator. 6. I believe that https://lng.sourceforge.net/ had a debugger in it, which might be place to start - it was suppose to target a couple of processors like the 6502 7. Check out: https://en.wikipedia.org/wiki/GNO/ME GNO github sources which was a UNIX clone for the Apple-II ᐧ ᐧ ᐧ On Tue, Jul 25, 2023 at 3:44 AM Warren Toomey via COFF wrote: > Hi all, I'm looking for a 16-bit big-endian Unix-like development > environment with a reasonably new C compiler and a symbolic debugger. > And/or, a libc with source code suitable for a 16-bit big-endian > environment. > > Rationale: I've designed and built a 6809 single board computer (SBC) with > 8K ROM, 2K I/O space for a UART and block storage, and 56K RAM. It's a > big-endian platform and the C compiler has 16-bit ints by default. I've > been able to take the filesystem code from XV6 and get it to fit into > the ROM with a hundred bytes spare. The available Unix-like system calls > are: > > dup, read, write, close, fstat, link, > unlink, open, mkdir, chdir, exit, spawn > > and the spawn is like exec(). There is no fork() and no multitasking. > I've got many of the existing XV6 userland programs to run along with a > small shell that can do basic redirection. > > Now I'm trying to bring up a libc on the platform. I'm currently trying > the libc from FUZIX but I'm not wedded to it, so alternative libc > recommendations are most welcome. > > There's no debugging environment on this SBC. I do have a simulator that > matches the hardware, but I can only breakpoint at addresses and > single-step > instructions. It makes debugging pretty tedious! So I was thinking of > using an existing Unix-like platform to bring up the libc. That way, if > there are bugs, I can use an existing symbolic debugger on the platform. > > I could use 2.11BSD as the dev platform but it's little-endian; I'm worried > that there might be endian issues that stop me finding bugs that will arise > on the 16-bit 6809 platform. > > As for which libc: I looked at the 2.11BSD libc/include and there's so > much stuff I don't need (networking etc.) that it's hard to winnow down > to just what I need. The FUZIX libc looks good. I just came across Elks > and that might be a possible alternative. Are there others to consider? > > Anyway, thanks in advance for your suggestions. > > Cheers, Warren > > References: > > XV6: https://github.com/mit-pdos/xv6-public > FUXIZ: https://github.com/EtchedPixels/FUZIX/tree/master/Library > Elks: https://github.com/jbruchon/elks/tree/master/libc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Wed Jul 26 09:23:01 2023 From: coff at tuhs.org (segaloco via COFF) Date: Tue, 25 Jul 2023 23:23:01 +0000 Subject: [COFF] What Happened to Interdata? Message-ID: So I've been studying the Interdata 32-bit machines a bit more closely lately and I'm wondering if someone who was there at the time has the scoop on what happened to them. The Wikipedia article gives some good info on their history but not really anything about, say, failed follow-ons that tanked their market, significant reasons for avoidance, or anything like that. I also find myself wondering why Bell didn't do anything with the Interdata work after springboarding further portability efforts while several other little streams, even those unreleased like the S/370 and 8086 ports seemed to stick around internally for longer. Were Interdata machines problematic in some sort of way, or was it merely fate, with more popular minis from DEC simply spacing them out of the market? Part of my interest too comes from what influence the legacy of Interdata may have had on Perkin-Elmer, as I've worked with Perkin-Elmer analytical equipment several times in the chemistry-side of my career and am curious if I was ever operating some vague descendent of Interdata designs in the embedded controllers in say one of my mass specs back when. - Matt G. P.S. Looking for more general history hence COFF, but towards a more UNIXy end, if there's any sort of missing scoop on the life and times of the Bell Interdata 8/32 port, for instance, whether it ever saw literally any production use in the System or was only ever on the machines being used for the portability work, I'm sure that could benefit from a CC to TUHS if that history winds up in this thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Jul 27 00:38:04 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 26 Jul 2023 10:38:04 -0400 Subject: [COFF] What Happened to Interdata? In-Reply-To: References: Message-ID: On 7/25/23, segaloco via COFF wrote: > Were Interdata machines > problematic in some sort of way, or was it merely fate, with more popular > minis from DEC simply spacing them out of the market? I suspect that Interdata had the same problem with their S/360 lookalikes that RCA did with theirs. If your business model is to provide a cheaper hardware alternative to IBM, your machine has to run IBM software, particularly the OS. When IBM did their pre-release of the S/370 specifications they deliberately left out key bits of the privileged architecture, such as the detailed bit layout of the PSW. Companies such as RCA and Interdata had make guesses while designing their S/370 lookalikes and in some cases they guessed wrong. RCA's Spectra 70 couldn't run IBM OS/VS or DOS/VS and that made it a total non-starter for most IBM commercial shops. I suspect Interdata ran into the same problem. Yes, they could design their own me-too operating systems, but they would always lag behind on new IBM OS features, on which critical IBM applications would depend. The IBM customer base knew this and stuck with genuine IBM. A lower price point wasn't enough to make up for the incompatibility. The advent of 32-bit minicomputers at the end of the 1970s brought down for good the IBM price umbrella under which Interdata and other lookalikes had been living. An example of how high that price umbrella had been: In 1978 my undergraduate alma mater was a true-blue IBM shop with a S/370 model 125 running batch, CICS, and a small BASIC timesharing system for the students. They'd outgrown the model 125. IBM's solution was to upgrade to a model 135. For the same price as the IBM processor upgrade, DEC was offering a complete VAX-11/780 system to run timesharing and other academic computing, with the S/370-125 devoted exclusively to the business side of things. The 11/780 was roughly equivalent in computing power to an IBM S/370-158--two models up from the 125. Buying the 11/780 was a complete no-brainer. IBM was forced to cut prices on the S/370 line, and that fatally destroyed Interdata's one advantage over true S/360/370. -Paul W. From coff at tuhs.org Thu Jul 27 03:39:54 2023 From: coff at tuhs.org (segaloco via COFF) Date: Wed, 26 Jul 2023 17:39:54 +0000 Subject: [COFF] What Happened to Interdata? In-Reply-To: References: Message-ID: > If your business model is to > provide a cheaper hardware alternative to IBM, your machine has to run > IBM software, particularly the OS. > > -Paul W. I think that's what tripped me up studying this, I didn't realize Interdata was trying to compete with IBM in the mainframe world. My only knowledge of them is via the UNIX connection regarding 7/32 and 8/32, which gave me the impression that Interdata was more in DECs market slice with minis than competing with IBM mainframes. That certainly puts their history in better perspective for me, thanks Paul! - Matt G. From grog at lemis.com Thu Jul 27 13:43:50 2023 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 27 Jul 2023 13:43:50 +1000 Subject: [COFF] What Happened to Interdata? In-Reply-To: References: Message-ID: <20230727034350.GC92211@eureka.lemis.com> On Wednesday, 26 July 2023 at 10:38:04 -0400, Paul Winalski wrote: > On 7/25/23, segaloco via COFF wrote: >> Were Interdata machines >> problematic in some sort of way, or was it merely fate, with more popular >> minis from DEC simply spacing them out of the market? > > I suspect that Interdata had the same problem with their S/360 > lookalikes that RCA did with theirs. If your business model is to > provide a cheaper hardware alternative to IBM, your machine has to run > IBM software, particularly the OS. That's not the way I remember it. RCA (and UNIVAC with them) and Interdata had instruction sets that were close to the IBM instruction set, but my recollection was that they were different enough that IBM software wouldn't run on them. That's a different situation from Amdahl, which was almost completely compatible. But that was a few years ago now, and I have forgotten the details. Does anybody know for sure whether they could run IBM software? I know from my time at UNIVAC that the 9000 series had their own operating systems. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From paul.winalski at gmail.com Fri Jul 28 02:30:45 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 27 Jul 2023 12:30:45 -0400 Subject: [COFF] What Happened to Interdata? In-Reply-To: <20230727034350.GC92211@eureka.lemis.com> References: <20230727034350.GC92211@eureka.lemis.com> Message-ID: On 7/26/23, Greg 'groggy' Lehey wrote: > > That's not the way I remember it. RCA (and UNIVAC with them) and > Interdata had instruction sets that were close to the IBM instruction > set, but my recollection was that they were different enough that IBM > software wouldn't run on them. That's a different situation from > Amdahl, which was almost completely compatible. As I recall it, the RCA Specra 70 was compatible with the IBM System 360 instruction set. It thus could run S/360 user applications. And maybe OS/360? The downfall came with S/370. IBM withheld the privileged portions of the architecture (including dynamic address translation [DAT; virtual memory]) and so when OS/VS and DOS/VS came out they wouldn't run on Spectra 70. RCA was forced to develop their own OS. Over time key IBM applications such as CICS depended on new features in OS/VS and DOS/VS. It wouldn't surprise me if many of those dependencies were gratuitous. So RCA was stuck in an endless cycle of having to add new (D)OS/VS features to their own OS. The big IT customers who form this market valued stability more than the lower price for the Spectra vs. S/370, and so RCA lost its market and eventually gave up. By the time Amdahl founded his own company, the privileged side of the S/370 architecture had been revealed. The S/370 architecture allows for a restricted set of model-dependent behavior and features in areas such as control register semantics and machine check handling. The Amdahl CPUs were no different from the S/370s as one model of S/370 is from another. (D)OS/VS keeps this model-dependent code in separate modules from the bulk of the OS. Amdahl only had to provide their own set of model-dependent modules. A smaller--and tractable--task compared to what had faced RCA and Interdata at the start of the S/370 era. -Paul W. From jnc at mercury.lcs.mit.edu Fri Jul 28 05:16:43 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 27 Jul 2023 15:16:43 -0400 (EDT) Subject: [COFF] What Happened to Interdata? Message-ID: <20230727191643.AE34718C079@mercury.lcs.mit.edu> > From: Greg 'groggy' Lehey > Interdata had instruction sets that were close to the IBM instruction > set, but my recollection was that they were different enough that IBM > software wouldn't run on them. Bitsavers doesn't have a wealth of Interdata documentation, but there is some: http://bitsavers.org/pdf/interdata/32bit/ Someone who's familiar with the 360 instruction set should be able to look at e.g.: http://bitsavers.org/pdf/interdata/32bit/8-32/8-32_Brochure_1977.pdf and see how compatible it is. Noel From paul.winalski at gmail.com Fri Jul 28 06:33:54 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 27 Jul 2023 16:33:54 -0400 Subject: [COFF] What Happened to Interdata? In-Reply-To: <20230727191643.AE34718C079@mercury.lcs.mit.edu> References: <20230727191643.AE34718C079@mercury.lcs.mit.edu> Message-ID: On 7/27/23, Noel Chiappa wrote: > > Someone who's familiar with the 360 instruction set should be able to look > at e.g.: > > and see how compatible it is. Thanks for the pointer. I took a quick look. My knowledge of the S/360 instruction set is very rusty at this point--it's been over 40 years since I programmed in it. The program status word (PSW) format looks very familiar. Both architectures seem to support 24-bit addressing. Interdata has some data types and instructions for manipulating them not present in S/360. Circular lists, for example, and instructions for CRC calculation. I didn't see anything about packed or zoned decimal support. So perhaps an extended subset of S/360. I'd have to do a side-by-side comparison between this document and S/360 Principles of Operation to determine the level of binary program compatibility, if any. But it looks like it might be better than the HitchHiker's Guide to the Galaxy adage: "almost, but not quite, entirely unlike tea." -Paul W From grog at lemis.com Fri Jul 28 13:38:18 2023 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 28 Jul 2023 13:38:18 +1000 Subject: [COFF] What Happened to Interdata? In-Reply-To: References: <20230727191643.AE34718C079@mercury.lcs.mit.edu> Message-ID: <20230728033818.GG92211@eureka.lemis.com> On Thursday, 27 July 2023 at 16:33:54 -0400, Paul Winalski wrote: > On 7/27/23, Noel Chiappa wrote: > >> Someone who's familiar with the 360 instruction set should be able to look >> at e.g.: >> >> and see how compatible it is. > > Interdata has some data types and instructions for manipulating them > not present in S/360. Circular lists, for example, and instructions > for CRC calculation. Yes, it's possible that both Interdata and RCA/UNIVAC/ICL instruction sets are supersets of the /360 instruction set. The only one I still remember is the LI (load immediate) instruction. The /360 did the same function with LA (load address), but IIRC that was RX (4 bytes), while LI was RR (2 bytes). > I didn't see anything about packed or zoned decimal support. > > So perhaps an extended subset of S/360. I'd have to do a side-by-side > comparison between this document and S/360 Principles of Operation to > determine the level of binary program compatibility, if any. But it > looks like it might be better than the HitchHiker's Guide to the > Galaxy adage: "almost, but not quite, entirely unlike tea." Yes, that seems reasonable. My guess was that binary compatibility wasn't a big issue in those days, since nearly all applications software was written only for specific installations. And of course licensing issues would preclude running IBM OS on the other machines. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From paul.winalski at gmail.com Sat Jul 29 02:18:19 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 28 Jul 2023 12:18:19 -0400 Subject: [COFF] What Happened to Interdata? In-Reply-To: <20230728033818.GG92211@eureka.lemis.com> References: <20230727191643.AE34718C079@mercury.lcs.mit.edu> <20230728033818.GG92211@eureka.lemis.com> Message-ID: On 7/27/23, Greg 'groggy' Lehey wrote: > > My guess was that binary compatibility > wasn't a big issue in those days, since nearly all applications > software was written only for specific installations. And of course > licensing issues would preclude running IBM OS on the other machines. That certainly was true for S/360 in the 1960s. IBM bundled its software offerings with its hardware. If you leased an IBM S/360, you got the development toolset (compilers, link editor, assembler) for free, as well as utilities such as sort/merge. Source code for the OS and the utilities was readily available in microfiche form. There were very few thrid-party software offerings. One that sticks in my mind is SyncSort, a sort/merge utility that far outperformed IBM's sort/merge program. If you were a big S/360 data center doing really serious, high-volume stuff, you used Storage Technology tape drives and SyncSort. That all changed when a 1969 antitrust complaint caused IBM to unbundle its software from hardware. Before, you got the software for free as part of your hardware lease. After, you had to buy a separate license for each software product. -Paul W. From coff at tuhs.org Sun Jul 30 09:26:21 2023 From: coff at tuhs.org (segaloco via COFF) Date: Sat, 29 Jul 2023 23:26:21 +0000 Subject: [COFF] Typical Fate of Older Hardware Message-ID: Howdy folks, I wanted to get some thoughts and experiences with regards to what sort of EOL handling of mainframe/mini hardware was typical. Part of this is to inform what and where to look for old hardware things. So the details may differ with era, but what I'm curious about is back in the day, when a mainframe or mini was essentially decommissioned, what was more likely to be done with the central unit, and peripherals if they weren't forward compatible with that user's new system. Were machines typically offloaded for money to smaller ops, or was it more common to simply dispose of/recycle components? As a more pointed example, if you worked in a shop that had IBM S/3x0, PDPs, larger 3B hardware, when those fell out of use, what was the protocol for getting rid of it? Were most machines "disposed of" in a complete way, or was it very typical to parts it out first, meaning most machines that reached EOL simply don't exist anymore, they weren't moved as a unit, rather, they're any number of independent parts floating around anywhere from individual collections to slowly decaying in a landfill somewhere. My fear is that the latter was more common, as that's what I've seen in my lab days; old instrumentation wasn't just auctioned off or otherwise gotten rid of complete, we'd typically parts the things out resulting in a chassis and some of the paneling going in one waste stream, unsalvageable parts like burnt out boards going in another, and anything reusable like ribbon cables and controller boards being stashed to replace parts on their siblings in the lab. I dunno if this is apples to oranges though because the main instruments I'm thinking of, the HP/Agilent 5890, 6890, and 7890 series, had different lifespan expectations than computing systems had, and share a lot more of the under the hood components like solenoids and gas tubing systems, so that may not be a good comparison, just the closest one I have from my own personal experience. Thoughts? - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Sun Jul 30 13:04:43 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Sun, 30 Jul 2023 13:04:43 +1000 Subject: [COFF] Typical Fate of Older Hardware In-Reply-To: References: Message-ID: <8B61E61D-E6CD-4B30-8188-3D42A3BDA92E@canb.auug.org.au> Matt, You ask _great_ questions. How far back are you talking? I think drawing a time box (start, end) around what you collect would give you returns. There’s a central problem: there’s no money in old gear, while storage costs mount over time. i.e. Who’s Going to Fund You? [ Midnight Oil: Who’s Going to Save You? ] It comes down to individuals keeping relics and privately funding collections. Some manufacturers had museums, archives & collections, but those were broken up when companies closed / merged. There’s a famous archive collection that was lost due to wild fires… Gordon Bell points out that in 1984, there were 91 US Computer Manufacturers. Of them, in 1990 IBM & HP plus DEC & Data General) were left. [ MIPS, SGI, SUN & a host of others using RISC came & went over 1-2 decades ] In 2000, just IBM & HP left from 1984, with computing being excised from HP at some point. IBM survived 1991/ 92 after declaring the largest corporate losses in US history, to the time. I think there’s around 10,000 IBM mainframes left now. Conversely, the number of running ‘instances’ continues to grow while physical machines & sites keep dwindling. Specialists firms now host many mainframes. The real US experts are CHM, whom you already know. This is the Aussie version - which has had problems with keeping its physical collection. They’d been given ‘cheap’ (free) storage space, then the owners developed the site. A useful research project would be to compile a definitive list :) The collective noun / Industry Term for obsolete equipment used to be “boat anchor”. Finding old pieces of historic machines is hard. They’re big & often fragile. Older (60’s & 70’s) gear was worth crushing & extracting the gold & copper. That happened to a system I once worked on - it took a whole floor of an exchange :-/ I was asked in the mid 1980’s about reusing chips from a later model IBM 370 (40xx?). A friend’s company was upgrading all it gear after _3_ years. They got a quote for removal - it was worth less than nothing, they had to pay to have it removed & broken down. As a Mech-Eng, he couldn’t believe it. He took it for the steel cabinets & dumped the electronics. Remember that floor space, volume, power (kW), environment/ HVAC shrunk significantly over time and various types of equipment & media stopped being used: cards, paper tape, 1/2” mag tape, disk packs… There’s no point in keeping old media if you can’t read the data therein, and older peripherals aren’t “free” - you’ve got to keep old machines that can attach to them. Which costs space, power and maintenance and sometimes important data is accidentally ‘orphaned’. For “Sound & Film”, Australia keeps a national archive and is in a constant race against time transferring content from old media to current. The problem once was unstable “nitrate” film stock, now it’s 2” tape masters :( While MIPS, GB & TB expanded, LAN’s and affordable networks gave us workstations & much more. There’s many generations of superseded kit, data and software to choose from :) There may have been 60,000 PDP-11’s produced and some were kept running for decades commercially. Old, rusting hulks might be sitting in the corner of factories & barns still - the same as vintage cars sitting ’somewhere’, rusting away. Australia has the “Honour” of still having the only complete pre-1950 valve computer known. It was built in Sydney & used there from 1949 to 1955, then moved to Melbourne in 1956 & used until 1964. It was then put in storage & mostly forgotten about until 1996, when it was made to work again. It was put on display for a few years. Not quite bureaucratic “benign neglect”, but close. CSIRAC’s 1953 replacement at Sydney Uni ran until 1963, then was ‘broken up’. All the best in your quest - it’s a great question. I hope others can give you better, more concrete leads in where to find “Old Electronics Kit”. It might be OK to drive around the country side looking for old cars rusting in fields or barns, but that’s not going to work for old electronics. People simply won’t know what they’re looking at when ‘cleaning out’ an old house, they won’t understand that some of the items have value to collectors. I’ve seen this with my own family. The Big Clean Out was unplanned & hurried. Some people took stuff they thought might be valuable, but making a buck was the motive. A bunch of working electronics was tossed in the ’skip’ (dumpster), not even recycled. Ken Thompson wrote he once got interested in player pianos and discovered there’s a firm somewhere in the USA that has a large collection and will restore items on demand. There might be people that curate & repair Old Electronics in the same way. all my best steve j ================= The Last of the First, CSIRAC: Australia’s First Computer While other first generation computers around the world were being shut down and dismantled, CSIRAC at the University of Melbourne began a ser- viceable second life. Further engineering improvements were gradually incorporated into CSIRAC during its time in Melbourne. For a further 8 years CSIRAC functioned as an open-shop computing service and during this period, from June 1956 to June 1964, CSIRAC was switched on for about 30,000 hours and processed about 700 computing projects. Total maintenance time was approximately 10% of switch-on time. At the time of CSIRAC’s shutdown in November 1964 it was already recognised by its operators to be an historically important technological artefact. This realisation was probably the major factor that contributed towards its preservation. Most other first generation electronic computers were dismantled and scrapped. In most cases only a few minor artefacts remain extant. Although Museum Victoria accepted CSIRAC for its collection the computer was never put on public display. Its sheer bulk, and the relative drabness of its exterior, mitigated against it being easily placed in any exhibition. From 1964 to 1980 it was kept in storage at the museum’s warehouse at Abbotsford where it was only sighted by staff and a few enthusiasts. In 1980, Gerry Maynard, then Head of the Department of Electronic Data Processing at Caulfield, decided it would be an appropriate tribute to Trevor Pearcey to have CSIRAC placed on display at Caulfield. Arrangements were made to move the computer from Museum Victoria to the Caulfield campus. Assembly was supervised by John Daly. From 1980 to 1992 CSIRAC remained on show at Caulfield and was a popular public attraction on Open Days. In September 1992 the computer was returned to Museum Victoria (Scienceworks), but once again was placed in storage, this time at a museum store in Maribyrnong. While in storage there, CSIRAC, in January 1995, was lucky to survive a flood of the Maribyrnong River. Water reached the base of the computer but fortunately no damage was done. ================= > On 30 Jul 2023, at 09:26, segaloco via COFF wrote: > > Howdy folks, I wanted to get some thoughts and experiences with regards to what sort of EOL handling of mainframe/mini hardware was typical. Part of this is to inform what and where to look for old hardware things. > > So the details may differ with era, but what I'm curious about is back in the day, when a mainframe or mini was essentially decommissioned, what was more likely to be done with the central unit, and peripherals if they weren't forward compatible with that user's new system. > > Were machines typically offloaded for money to smaller ops, or was it more common to simply dispose of/recycle components? As a more pointed example, if you worked in a shop that had IBM S/3x0, PDPs, larger 3B hardware, when those fell out of use, what was the protocol for getting rid of it? Were most machines "disposed of" in a complete way, or was it very typical to parts it out first, meaning most machines that reached EOL simply don't exist anymore, they weren't moved as a unit, rather, they're any number of independent parts floating around anywhere from individual collections to slowly decaying in a landfill somewhere. > > My fear is that the latter was more common, as that's what I've seen in my lab days; old instrumentation wasn't just auctioned off or otherwise gotten rid of complete, we'd typically parts the things out resulting in a chassis and some of the paneling going in one waste stream, unsalvageable parts like burnt out boards going in another, and anything reusable like ribbon cables and controller boards being stashed to replace parts on their siblings in the lab. I dunno if this is apples to oranges though because the main instruments I'm thinking of, the HP/Agilent 5890, 6890, and 7890 series, had different lifespan expectations than computing systems had, and share a lot more of the under the hood components like solenoids and gas tubing systems, so that may not be a good comparison, just the closest one I have from my own personal experience. > > Thoughts? > > - Matt G. -- 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 coff at tuhs.org Sun Jul 30 13:33:06 2023 From: coff at tuhs.org (segaloco via COFF) Date: Sun, 30 Jul 2023 03:33:06 +0000 Subject: [COFF] Typical Fate of Older Hardware In-Reply-To: <8B61E61D-E6CD-4B30-8188-3D42A3BDA92E@canb.auug.org.au> References: <8B61E61D-E6CD-4B30-8188-3D42A3BDA92E@canb.auug.org.au> Message-ID: > How far back are you talking? > I think drawing a time box (start, end) around what you collect > would give you returns. > ... > Steve Jenkin I actually don't consider myself much of a collector of anything besides information. Even the physical books and such I've accumulated lately, save for select pieces, I eventually want to get into some other library. I'm not on the hunt for some piece of hardware I want to order and keep around here, rather, seeing if there's avenues I should keep my eye on while searching around for documents and other history that, say, I could then get the CHM or another involved with. For instance, one "goal" if you will is to somehow run down a (working or not) 3B20S and put the right folks in contact to see about preserving the thing. Even better if I can travel and help with some of the restore, but honestly at the end of the day I'm just after lost history. That said, hardware significant to the pre-divestiture UNIX-and-adjacent history takes priority with me, stuff like Interdata 32-bit, various 3B machines, etc. so to put years on it would be 69-84. I'm actually kicking myself because there was a MacTutor (WE Mac-8 SBC) on eBay this past couple of years and it had been bought by the time I made up my mind on it. My hope was to document it as much as I could and then see if LCM or CHM were interested in it for their archives. I do have a AT&T UNIX PC I intend to get rolling eventually but that's about as far as my on-hand hardware ambitions go, and certainly isn't relevant to early history. I would maybe go for a higher end SGI for myself if I found one at an agreeable price, but even that would be mostly to experiment with IRIS GL and their specific graphics hardware. I'm trying not to let too many hardware distractions get between me and my SBC experiments though, too much coding for the past will keep me from coding for the present. After all, one of my chief personal motivations in studying the past is to better understand how we got here and where we're headed. - Matt G. From coff at tuhs.org Mon Jul 31 02:15:46 2023 From: coff at tuhs.org (Grant Taylor via COFF) Date: Sun, 30 Jul 2023 11:15:46 -0500 Subject: [COFF] Typical Fate of Older Hardware In-Reply-To: References: Message-ID: <5ec59010-d848-8adc-9872-7a4e6fb599eb@tnetconsulting.net> On 7/29/23 6:26 PM, segaloco via COFF wrote: > Howdy folks, I wanted to get some thoughts and experiences with regards > to what sort of EOL handling of mainframe/mini hardware was typical. My experience disposing of things is from the late '90s and early '00s and is for much smaller things. So it may very well differ. But, that being said, I observed basically three different phases of hardware divestiture where I was working. 1) Send everything, effectively donating it, to a municipal / state facility that served as a surplus property sale house hosting monthly auctions. -- Conceptually some proceeds supposedly came back to us ... eventually. 2) Per prodding form some of us employees who were interested in running some of the things at home persuaded the powers that be to sell things through public approved outlets, e.g. GovDeals(.com), where the public and employees, could bid on equipment. The problem was that selling things this way didn't yield enough profit to offset the expense of doing so. 3) The municipality decided that it was more fiscally responsible to return to the first method. > Part of this is to inform what and where to look for old hardware things. I think that saved searches on typical sites are probably the best locations that I've found. I'd be interested in learning about more. - eBay - Craigslist - Mercari - GovDeals Others suggest: - etsy I was never in geographic proximity to any electronics recycling / salvage stores like were so common on the coasts. The best I had was the aforementioned state run surplus auction and others further away. There is also the very unofficial and always denied "fell off of a truck" ostensibly on it's way to aforementioned surplus disposal locations. > So the details may differ with era, but what I'm curious about is back > in the day, when a mainframe or mini was essentially decommissioned, > what was more likely to be done with the central unit, and peripherals > if they weren't forward compatible with that user's new system. I've been around a number of locations that retained compatible peripherals for as long as they could and as long as they worked. Leveraging the existing investment was often a significant influence into choosing new systems, at least up to (close to) the replacement cost for said peripherals. > Were machines typically offloaded for money to smaller ops, or was it > more common to simply dispose of/recycle components? As a more pointed > example, if you worked in a shop that had IBM S/3x0, PDPs, larger 3B > hardware, when those fell out of use, what was the protocol for getting > rid of it? Were most machines "disposed of" in a complete way, or was it > very typical to parts it out first, meaning most machines that reached > EOL simply don't exist anymore, they weren't moved as a unit, rather, > they're any number of independent parts floating around anywhere from > individual collections to slowly decaying in a landfill somewhere. The other thing that I saw done was businesses holding onto older equipment and simply storing it somewhere because divesting it was problematic for one reason or another. So there was usually a room, in a basement or attic that collected things. -- Usually basement as heavy things have a natural tendency to go down. -- Then once every so often (3-8 years seemed to be what I saw) the older things in the room, if not the entire room, would be purged. Often unceremoniously and without any respect for the equipment. > Thoughts? At my last job I whitnessed, and could do nothing to stop, a bunch of servers have their hard drives removed, still on the sleds, and shredded. Then the systems they were in were sold at surplus -- again for very little money. The lack of sleds made the systems much less usable. But the business found it to not be worth the time and effort to remove the drives from the sleds and return the sleds to the systems for resale. It seems like it really always does come down to what is the most economical / least expensive option for businesses. :-( Grant. . . . From paul.winalski at gmail.com Mon Jul 31 07:51:16 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 30 Jul 2023 17:51:16 -0400 Subject: [COFF] Typical Fate of Older Hardware In-Reply-To: References: Message-ID: On 7/29/23, segaloco via COFF wrote: > > Were machines typically offloaded for money to smaller ops, or was it more > common to simply dispose of/recycle components? As a more pointed example, > if you worked in a shop that had IBM S/3x0, PDPs, larger 3B hardware, when > those fell out of use, what was the protocol for getting rid of it? Were > most machines "disposed of" in a complete way, or was it very typical to > parts it out first, meaning most machines that reached EOL simply don't > exist anymore, they weren't moved as a unit, rather, they're any number of > independent parts floating around anywhere from individual collections to > slowly decaying in a landfill somewhere. In the 1970s there was an active market for used IBM gear. Those shops still running second generation computers such as the IBM 1400 and 9000 series were often willing to buy CPUs to cannibalize them for spare parts to keep their own systems running. Otherwise there wasn't much call for second-hand CPUs. Aside from them being much slower, one year's electricity needed to power a second generation CPU could probably pay for a third generation CPU. Peripherals had more of a second hand market. Older card readers, card punches, printers, and tape drives still worked perfectly well with newer hardware. This was especially true of the IBM 1403 printer. This was arguably the best line printer ever made. When System/370 came along, IBM had a newer line printer (the 3203) for it, but nearly everyone (including myself) considered it inferior to the older 1403. I know of one shop that sold off its 1400 system, which had a1401 CPU, 1402 card read/punch, and 1403 printer. The used computer dealer offered them $18,000 for the whole system, or $15,000 just for the 1403 printer. Maintenance and support are, I think, the two main roadblocks to an aftermarket for used computers. By the time a shop decides to upgrade and get rid of its old hardware, it will already be difficult to find a support specialist trained on the gear and to find spare parts. That's why used computers, especially the CPUs, tenddc to become spare parts themselves. -Paul W. From steffen at sdaoden.eu Mon Jul 31 06:33:21 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sun, 30 Jul 2023 22:33:21 +0200 Subject: [COFF] Typical Fate of Older Hardware In-Reply-To: <5ec59010-d848-8adc-9872-7a4e6fb599eb@tnetconsulting.net> References: <5ec59010-d848-8adc-9872-7a4e6fb599eb@tnetconsulting.net> Message-ID: <20230730203321.QWoHZ%steffen@sdaoden.eu> Grant Taylor via COFF wrote in <5ec59010-d848-8adc-9872-7a4e6fb599eb at tnetconsulting.net>: |On 7/29/23 6:26 PM, segaloco via COFF wrote: |> Howdy folks, I wanted to get some thoughts and experiences with regards |> to what sort of EOL handling of mainframe/mini hardware was typical. | |My experience disposing of things is from the late '90s and early '00s |and is for much smaller things. So it may very well differ. Around 1990(+ a bit) i worked during holiday for a company which collected old computers, monitors etc from authorities and, well, other companies. Myriads of (plastic) keyboards, cables, etc., it all was thrown into containers (ie rolled down the floor, then blindly thrown), all mixed up. I (a prowd owner of an i386 DX 40 by that time iirc) shortly thought of, you know, but to no avail. I have no idea, i am pretty sure it all went down to Africa or India, where young people and other unlucky then had to pave their way through, as is still mostly the case today, _i think_. Let's just hope they do not have illnesses because of the (likely) toxic interour. (Having said that, i myself also worked for a short time for another company where i was crawling through cable and such shafts, .. without any mask .. Not to talk about waste incinator and chemical industry here (Merck and Rhön etc), they were also filter free, .. and then i was also smoking for over twenty years. How did i end up here now?? I hope i am still from one of those generations which can live a hundred years nonetheless.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)