The Perfect Computer - 36 bits?
|
From: jmfbahciv on 2 Apr 2007 07:56 In article <beb113hpl1tjebui0vn09e8m0cl5qgu7ia(a)4ax.com>, Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: >On Sat, 31 Mar 07 12:13:54 GMT in alt.folklore.computers, >jmfbahciv(a)aol.com wrote: > >>In article <tlvr03lc4tta7uc53787pi8aa0gc4ikdpm(a)4ax.com>, >> Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: >>>On Fri, 30 Mar 07 12:12:22 GMT in alt.folklore.computers, >>>jmfbahciv(a)aol.com wrote: >>> >>>>In article <573r7kF2arf8qU1(a)mid.individual.net>, >>>> =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >>>>>> OK, then my question goes back to Jan and Barb. Why was a full sysgen >>>>>> required or recommended for the situations you guys were talking about? >>>>>> Wouldn't partial gens do the job without the need for the large >>>>>> resource commitment Jan talked about? >>>>> >>>>>At least for the first 10 years or so, VAX/VMS wasn't structured in a >>>>>sufficiently loose way to make this feasible, IMO - we're talking the core >>of >>>>>the OS here, >>>> >>>>Yes, I'm talking about that, too. >>>> >>>>> of course, not all of the utilities etc. that constitute the bulk >>>>>of the code. However, if you needed to make an interface change at the >>>>syscall >>>>>level, you'd need to recompile everything. >>>> >>>>Really? Most of TOPS-10's rebuilds had to do with hardware changing, >>>>not software. Oh, I see. ARe you talking about adding a new >>>>syscall? That would be a new feature; it's safer to do a complete >>>>rebuild, especially if the syscall had anything to do with disk >>>>I/O user-mode code interfaces. >>>> >>>> >>>>> >>>>>And anyway, I can't think of a problem that would have required a rebuild. >>>>>Significantly upgrading a subsystem, like the batch or print job >>management, >>>> >>>>Nah, on the -10 that was at the app level. >>>> >>>>>would have been much easier with the source - but as I said, DEC customers >>>>>never considered such things until (too) late, in contrast to IBM's >>>>customers. >>>> >>>>Our device tables, command tables, and all fields associated with them >>>>were generated by macros based on the questions answered at MONGEN >>>>time (a program that queried the sysmanger what hardware and software >>>>features he wanted to put on his computer system). The best >>>>way to make any changes to those would be to do it the "right way". >>>>Fumble fingers can destroy machines. >>> >>>Without the sources, you'd just dump the tables, define your own macros >>>to create the entries, and add new entries to the tables; find where the >>>table origins were loaded, and patch the code to load the new origins. >> >>And now you've just overwritten code. In the biz, it's called >>buffer overflow. > >It's called system maintenance: patching the system to add >functionality. >Buffer overflow is a bug caused by amateurs masquerading as programmers. > Son, you don't know what I'm talking about. /BAH
From: jmfbahciv on 2 Apr 2007 07:59 In article <2lg113l2c561603eafaiuc6ujag7j9i2mp(a)4ax.com>, Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: >On Thu, 29 Mar 07 13:17:03 GMT in alt.folklore.computers, >jmfbahciv(a)aol.com wrote: > >>In article <sv4n039pl09njc3c36umop12hu2a45dhnr(a)4ax.com>, >> Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: >>>On Mon, 26 Mar 07 11:27:52 GMT in alt.folklore.computers, >>>jmfbahciv(a)aol.com wrote: >>> >>>>In article <Vf-dnSMExMAU4JvbnZ2dneKdnZydnZ2d(a)bt.com>, >>>> Andrew Swallow <am.swallow(a)btopenworld.com> wrote: >>>>>jmfbahciv(a)aol.com wrote: >>>>>> In article <rqh3ue.6m61.ln(a)via.reistad.name>, >>>>>> Morten Reistad <first(a)last.name> wrote: >>>>>[snip] >>>>> >>>>>>> >>>>>>> The decision of May 17th 1983 couldn't have been much different. >>>>>>> >>>>>>>> After all, people want to upgrade their computers in the most >>>>>>>> effective way possible - and the most effective way is the one that >>>>>>>> requires them to spend the least money converting their own programs >>>>>>>> and data. >>>>>>>> >>>>>>>> So if nobody makes PDP-10 computers any more, there's no particular >>>>>>>> benefit to their owners doing their next upgrade with DEC - and a >>>>>>>> motive not to do so, so as to punish this behavior. >>>>>>>> >>>>>>>> Under what circumstances would abandoning their 10 and 20 customers be >>>>>>>> rational? >>>>>>> This is where I have an issue with DEC. It was the abandonment of the >>>>>>> customers. >>>>>> >>>>>> No, no. _PDP-10_ customers. This was Bell's doing through and through. >>>>> >>>>>Worse DEC dropped the PDP-11 customers, >>>> >>>>Sigh! Now _when_ are you talking about. This was not true in >>>>the early 80s. When the PDP-11 product line was sold off, Bell >>>>was long gone. >>> >>>It was obvious DEC was dropping non-VAX h/w and s/w by the early 80s: >>>Marketing was pushing VAX and had nothing positive to say about other >>>products. >> >>That's funny because 11s were an intricate piece of the disk >>systems. There is no way a VAX would be the front end of the HSC. > >They stuck MASSbusses into the VAX backplane. >And eventually allowed VAX onto the HSC; 11s never had that option. What CPU do you think was in those HSCs to handle the protocols? > >>>>> LSI-11 customers, PDP-8 >>>>>customers and the VAX/VMS customers. Eventually the company runs >>>>>out of customers. >>> >>>DEC had no plans to produce bigger VAX systems in the early 80s, >> >>Huh? What do you mean by bigger? >> >>> and >>>peripherals were same as 11 range, so commercial non-compute >>>price/performance and expandability were non-competitive. >> >>No peripherals were not the same. > >That's all they offered when we asked for quotes. Now we get down to the real problem here. You are still pissed off from not buying some gear. Therefore, everything we ever did had to be wrong. The more you show your attitude here, the more I'm convinced that you would have been a troublesome customer and would have cost us 100 times more money than what we would have made with the sale and support contracts. <snip> /BAH
From: Charlton Wilbur on 2 Apr 2007 10:55 >>>>> "k" == krw <krw(a)att.bizzzz> writes: k> Just a guess, but perhaps [bloat is] what people really want. k> The ones who don't are generally savvy enough to strip it down k> (or build it up) to their liking. k> I know it's heretical, but I believe Linux' problem is much k> simpler; compatibility. Most of the people I know don't care, at a fundamental level, what OS they're running. They want to use the computer to do a set of tasks, and whatever OS makes it easiest to do that set of tasks wins. Many of them would be perfectly fine with Linux, but the front-loaded step of getting it set up and configured is just too much work to bother with. The extra learning curve and compatibility issues with things they're used to doing -- having to use OpenOffice instead of Microsoft Office, for instance -- is just the icing on the cake. Others know a little bit and have a support network. (My mother falls in this group.) They have no firm attachment to Windows, but their friends all use Windows and so when one of them has a technical issue he or she can talk to similar non-technical friends, and when one discovers something wonderful, he or she can spread it around. (This seems to happen with all sorts of enticing malware.) In neither case is it about the operating system, though -- it's about "I want to get work done" and "I want to use what my friends use." Oddly enough, I think these are the reasons Linux and OS X are used as widely as they are in the circles they are used, as well. Charlton -- Charlton Wilbur cwilbur(a)chromatico.net
From: Frank McCoy on 2 Apr 2007 11:24 In alt.folklore.computers Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: >Buffer overflow is a bug caused by amateurs masquerading as programmers. .... Or deliberately caused by hackers trying to break a system. -- _____ / ' / ™ ,-/-, __ __. ____ /_ (_/ / (_(_/|_/ / <_/ <_
From: krw on 2 Apr 2007 11:56
In article <a082135mvbkatdo80f6fm2cs4kgt5t8kpf(a)4ax.com>, mccoyf(a)millcomm.com says... > In alt.folklore.computers Brian Inglis > <Brian.Inglis(a)SystematicSW.Invalid> wrote: > > >Buffer overflow is a bug caused by amateurs masquerading as programmers. > > ... Or deliberately caused by hackers trying to break a system. No, if there wasn't a loose nut behind the original keyboard the hacker wouldn't have a chance at a buffer overflow. The fact that it *can* be overflowed shows a poor design. -- Keith |