[cctalk] Re: mainframe vs mini
On Thu, Mar 9, 2023 at 5:05 PM Cameron Kaiser via cctalk wrote: > This has been around the block: > > You can lose a screw in a micro. > You can lose a screwdriver in a mini. > You can get lost in a mainframe. We had an Amdahl in the middle of a multi-thousand-square-foot computer room (one of several) at work 25 years ago. I do not know/remember the model number but it was made of up several cabinets not in a line. It had such a convoluted layout that you could literally stand in the "middle" of it and not see outside. If you stood in exactly the right spot, the blank panels lined up and made the visual appearance of a box with no exits. You _could_ get lost in that one, as long as you didn't take half a step away. -ethan
[cctalk] Re: List migration
Thank you everyone. I think installing the pipermail list program on the new host, just to serve as an archive function but not turn on the mailer function would be the easiest way to do it. Translating or transferring to some other platform would be a PITA Bill On Thu, Mar 16, 2023, 10:02 PM steve shumaker via cctalk < cctalk@classiccmp.org> wrote: > Greetings sir! > Who can I email to inquire about being rejected from the listserver as > spam? > > Steve > > On 7/10/22 10:38 PM, Dennis Boone via cctalk wrote: > > Friends, > > > > The process of migrating the cctalk and cctech mailing lists to a new > > host in Chicago is underway. This evening, I've moved the list mail > > handling to the new server, and this message will be the first live > > test. Assuming this works, you shouldn't have to change anything to > > post to the list. > > > > The green web pages, the old "pipermail" list archives, and web access > > to archives of new postings from this point still require a little work, > > which I hope to complete in the next day or two. I will eventually > > import the old pipermail archives into the new posting archive, but that > > may take a little longer. > > > > The new hosting is provided by the Chicago Classic Computing group. > > > > Many thanks to Jay West for hosting the lists for 20 years! > > > > /Dennis Boone > >
[cctalk] Re: mainframe vs mini
On 3/15/23 17:23, Jon Elson via cctalk wrote: > Yes, the IBM 709x ran in single-job fashion. I don't think it had > interrupts, so breaking off one program to schedule another was not > possible. Also, it had no memory protection. We had a 7094 at > Washington University in the late 1960s, and it was the main computer > resource on campus. When the moved up to a 360/50, they were able to > benefit from multiprogramming, and got a boost in throughput, although > the 7094 was QUITE a bit faster than the 360/50. Interrupts with IBM were a "if you need them, we have them". For example, the 1800 (industrial version of the 1130) and the 1710 (industrial version of the 1620) both had realtime clocks and interrupts. I find it interesting, tracing the evolution of Seymour Cray's thinking from the CDC 160A through the Cray 2. One cannot really understand, for example the thinking behind the 7600 without knowing the 6600 and its predecessors. The CDC 1604 (1959 (certainly had interrupts, both internal and external, but I do not believe it had memory protection. It did have a console loudspeaker driven by a 3-bit DAC, however. The CDC 3000 series (1962) had an interrupt capability as well as memory protection and realtime clock. When you get to the CDC 6000 era, the question of interrupts is interesting. Certainly the PPUs didn't have interrupt capability, but the CPU could be exchange-jumped by a PPU (usually PP0) to provide task-switching on demand. In general, however, CPU programs did not implement interrupt-handling as such. It is clear that Seymour initially intended most OS functions to be distributed among the PPs. I do believe that he abandoned that line of thought when it came to the 7600 and beyond. The dominant 7600 OS, SCOPE 2, was an interesting combination of privilege levels and overlapping storage protection. 7600 PPUs could not host an OS because they were confined to fixed buffer addresses in SCM. The 7600 PPs are pretty much confined to I/O. For whatever it's worth, --Chuck
[cctalk] Re: List migration
Greetings sir! Who can I email to inquire about being rejected from the listserver as spam? Steve On 7/10/22 10:38 PM, Dennis Boone via cctalk wrote: Friends, The process of migrating the cctalk and cctech mailing lists to a new host in Chicago is underway. This evening, I've moved the list mail handling to the new server, and this message will be the first live test. Assuming this works, you shouldn't have to change anything to post to the list. The green web pages, the old "pipermail" list archives, and web access to archives of new postings from this point still require a little work, which I hope to complete in the next day or two. I will eventually import the old pipermail archives into the new posting archive, but that may take a little longer. The new hosting is provided by the Chicago Classic Computing group. Many thanks to Jay West for hosting the lists for 20 years! /Dennis Boone
[cctalk] Re: Knockoffs, was: Low cost logic analyzer
On Thu, Mar 16, 2023 at 12:32 PM Alexander Huemer via cctalk < cctalk@classiccmp.org> wrote: > On Thu, Mar 16, 2023 at 11:05:41PM +0800, Tom Hunter via cctalk wrote: > > FSF does not enforce anything. > > https://gpl-violations.org/ > They do though. > > -Alex > Go to 'News' on that site and the last news about an enforcement action was from 2013. If you actually want to pursue GPL violations, especially if it's related to a non-FSF sponsored project, you'll have better luck with the EFF or appealing to someone like Popehat/Ken White to help find some *pro bono * representation. KJ
[cctalk] SmallTalk books claimed
They’re gone
[cctalk] SmallTalk 80 books available
I have the following books free to a good home: SmallTalk-80: The Language & its Implementation SmallTalk-80: The Interactive Programming Environment SmallTalk-80: Bits of History, Words of Advice Email tpisek at pobox dot com
[cctalk] Re: mainframe vs mini
>I remember when the internet and e-mail became all the rage in the late 1990s, >everything was eThis and eThat. And when Apple coined the iPhone, everything >started to become iThis and iThat. The "i" thing predated apple's use of it and certainly predated the iphone. Internet services ompanies like iVillage and many others were using it. Some IBM internet software also used this but I can't recall the names. But surely Apple jumped on the bandwagon with their iMac colorful cube thing in 1998 or thereabouts. But in general, I agree with the sentiment. 73 Eugene W2HX Subscribe to my Youtube Channel: https://www.youtube.com/@w2hx/videos
[cctalk] Re: Knockoffs, was: Low cost logic analyzer
On Thu, Mar 16, 2023 at 11:05:41PM +0800, Tom Hunter via cctalk wrote: > FSF does not enforce anything. https://gpl-violations.org/ They do though. -Alex
[cctalk] Re: Knockoffs, was: Low cost logic analyzer
> FSF does not enforce anything. I repeatedly begged for help with Desktop > CYBER which was GPL licensed and they did not even bother to reply. I'm told by a friend at Red Hat that RH/IBM has a department for that kind of thing and can/will provide legal help for outside projects. Thanks, Jonathan
[cctalk] Re: Knockoffs, was: Low cost logic analyzer
Maybe they only do for GPL items of their own. paul > On Mar 16, 2023, at 11:05 AM, Tom Hunter via cctalk > wrote: > > FSF does not enforce anything. I repeatedly begged for help with Desktop > CYBER which was GPL licensed and they did not even bother to reply. > > Tom Hunter
[cctalk] Re: Knockoffs, was: Low cost logic analyzer
FSF does not enforce anything. I repeatedly begged for help with Desktop CYBER which was GPL licensed and they did not even bother to reply. Tom Hunter On Thu, Mar 16, 2023 at 7:46 AM Paul Koning via cctalk < cctalk@classiccmp.org> wrote: > > > > On Mar 14, 2023, at 10:57 PM, Jonathan Chapman via cctalk < > cctalk@classiccmp.org> wrote: > > > >> If you posted your design as Open Source, someone else producing it > isn't a knockoff, it's the system working as intended. > > > > What is it when the design is open source, but they're not complying > with the terms of the license? That's what really bugs me, the "cost" of > producing your own from one of our designs is attribution and releasing > your design under the same or a compatible license, but apparently that's > too much to ask. > > > > Thanks, > > Jonathan > > You're talking about GPL or equivalent there -- for which the FSF has at > times been the enforcer. BSD style licenses require next to nothing of > people copying (in particular, they don't require releasing the derived > work). > > Personally I'm partial to BSD style licenses, though some of my open > source work was originally licensed under GPL. (I may change that at some > point if I want to bother.) That means I'm accepting the possibility that > someone could copy what I did and sell it as a closed product. Fine, so be > it (that doesn't close what I did, of course). > > paul > >
[cctalk] Re: mainframe vs mini
The 709x had data channels which ran asynchronously, and generated channel traps — i.e. interrupts. I don’t think it had a, say, 60Hz clock, but I/O interrupts would allow a certain basic level of multiprogramming. The IBM 1410 also had I/O interrupts, and even had a rudimentary optional teleprocessing supervisor. IBM turned some 1410s into a basic message switching system. Sent from my iPad > On Mar 15, 2023, at 19:23, Jon Elson via cctalk wrote: > > On 3/15/23 18:32, Paul Koning via cctalk wrote: >> >> Apart from spooling, which uncouples slow I/O from execution, there is also >> "multiprogramming", which means being able to run more than one job >> concurrently. Timesharing does that, of course, but I think >> multiprogramming was intended to refer to batch systems that did so. >> > Yes, the IBM 709x ran in single-job fashion. I don't think it had > interrupts, so breaking off one program to schedule another was not possible. > Also, it had no memory protection. We had a 7094 at Washington University > in the late 1960s, and it was the main computer resource on campus. When the > moved up to a 360/50, they were able to benefit from multiprogramming, and > got a boost in throughput, although the 7094 was QUITE a bit faster than the > 360/50. > > Jon >
