The Perfect Computer - 36 bits?
|
From: Charles Shannon Hendrix on 2 Apr 2007 16:38 ["Followup-To:" header set to alt.folklore.computers.] > Remember how long Vista was at Beta release. It comes down to are > many games that are at least 4 years old still played by gamers who > buy the latest OS? Games that came out in the last few months won't play well on Vista. Also, a lot of gamers who play old games do buy new systems to play them on. -- shannon "AT" widomaker.com -- ["There are nowadays professors of philosophy, but not philosophers." ]
From: Charles Shannon Hendrix on 2 Apr 2007 20:16 ["Followup-To:" header set to alt.folklore.computers.] >> With PCs the user companies >>set up their own support teams. > > Wrong. Huh? Are you telling me that the support team I set up a few years ago didnt' exist, and that I dreamed doing it? Are you saying that the multi-billion dollar industry of third party in-house support for everything from embedded systems to mainframes doesn't exist, and all those in it are hallucinating? Do tell... :) >> Windows needs more support people >>than Unix. > > Wrong. Wrong in what way? I've done both jobs, and I know for a very painful fact that Windows systems, regardless of use, require more support. It's a fairly close call on the desktop, but anything else is solidly in favor of UNIX, often drastically so. >> The VAX system managers would have found themselves >>supporting networks of several hundred secretaries with microVAXs on >>their desks rather than one machine. DEC would only need to fix the >>problems the system managers cannot. > > Wrong. OK... explain why a problem that's fixable by local personnel somehow would need DEC to fix it. Maybe you have a point, but "Wrong" doesn't explain it very well. > Now go back and do the math. How many people would have to hired > and trained and sitting at a phone to provide technical support > to a million system installations. At the last such shop where I worked, 15. -- shannon "AT" widomaker.com -- ["There are nowadays professors of philosophy, but not philosophers." ]
From: jmfbahciv on 5 Apr 2007 07:04 In article <proto-A67E59.09585204042007(a)032-325-625.area1.spcsdns.net>, Walter Bushell <proto(a)oanix.com> wrote: >In article <euvvpj$8qk_010(a)s1007.apx1.sbo.ma.dialup.rcn.com>, > jmfbahciv(a)aol.com wrote: > >> In article <proto-6CE80E.14515402042007(a)032-325-625.area1.spcsdns.net>, >> Walter Bushell <proto(a)oanix.com> wrote: >> >In article <MPG.207af1c58caebfc498a29f(a)news.individual.net>, >> > krw <krw(a)att.bizzzz> wrote: >> > >> >> 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. >> > >> >Could be bad design or bad implementation. It's something an >> >applications programmer should not have to worry about. The more things >> >that a programmer has to concentrate on the more things elude attention. >> >> None of you have obviously done any monitor development (as your primary >> job). >> >> /BAH > >I did say "application programmer", the OS is quite different in the >kernel anyway. My opinion dictates that the same high standards and discipline should also be used when doing the app coding. Stating that the OS is different in the kernel is no excuse for slop. Slop breeds more sloppiness and trains all newbies, especially the bit god acolytes that sloppy is the standard. Now do you get it? /BAH
From: jmfbahciv on 5 Apr 2007 07:15 In article <svgde4-kqo.ln1(a)osl016lin.hda.hydro.com>, Terje Mathisen <terje.mathisen(a)hda.hydro.com> wrote: >Brian Inglis wrote: >> On Mon, 02 Apr 07 11:53:42 GMT in alt.folklore.computers, >> jmfbahciv(a)aol.com wrote: >>> DEC documented all of its opcodes. Those that were not used >>> were documented as "Reserved for future use". >> >> Some documented opcodes did different things on different >> implementations, making it possible to determine what kind of CPU you >> were running on, based on the bugs. > >That was the case for early x86 cpus as well: > >One 808x clone (possibly NEC?) implemented one of the BCD/ASCII opcodes >as documented, without noticing that the opcode had the decimal 10 as >the second opcode byte: On an Intel cpu you can/could replace that value >with something else, like using 16 to split a byte value into two hex >nibbles. Our attitude was to provide a documented way to query the system both software and hardware. If there is disagreement, we wanted to know about it. It was called a sanity check. Please not that ITS, TOPS-20, TOPS-10, and something else OSes each have a value assigned to them. Any software could write a UUO asking the system which OS it thought it was running. Then the code could then branch to the appropriate section of code that knew how to interface with the returned OS. This was a design feature and allowed any app code to interface with any PDP-10 OS without rebuilding. I don't know if anybody wrote code that used this feature. /BAH
From: Rich Alderson on 5 Apr 2007 17:23
jmfbahciv(a)aol.com writes: > Our attitude was to provide a documented way to query the system both > software and hardware. If there is disagreement, we wanted to know about it. > It was called a sanity check. Please not that ITS, TOPS-20, TOPS-10, and > something else OSes each have a value assigned to them. Any software could > write a UUO asking the system which OS it thought it was running. Then the > code could then branch to the appropriate section of code that knew how to > interface with the returned OS. This was a design feature and allowed any > app code to interface with any PDP-10 OS without rebuilding. That's software. > I don't know if anybody wrote code that used this feature. Yes, people did, and do. And I mean besides me. On the hardware side, there are bits of code in the beginning of several of the diagnostics that determine what hardware platform is under test, for example by checking the result of MOVE 1,[-2,,777777] AOBJN 1,.+1 SKIPE 1 <branch to code for KA-10 processor> since the KA-10 actually adds 1,,1 to the AC so that the carry out of the right half propagates to the left. There are programmatic ways to detect the Model 166 processor (PDP-6), the KA-10, the KI-10, the KL-10, the KS-10, and the Toad-1. I assume that there were checks for various Foonly and Systems Concepts boxen. -- Rich Alderson | /"\ ASCII ribbon | news(a)alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | |