The Perfect Computer - 36 bits?
|
From: Walter Bushell on 4 Apr 2007 09:58 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.
From: Anne & Lynn Wheeler on 4 Apr 2007 13:37 > 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. side drift ... lots of past posts discussing overflow and similar vulnerabilities http://www.garlic.com/~lynn/subintegrity.html#overflow taken to another level ... you can get into all sorts of discussions about design of SQL and relational ... vis-a-vis DBMS where user/programmer has to deal with constructs like record pointers being exposed as part of the data ... and/or other infrastructure constructs that are not part of directly solving the problem of interest. somewhat related recent posts in c.d.t and other venues http://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction http://www.garlic.com/~lynn/2007e.html#31 Quote from comp.object http://www.garlic.com/~lynn/2007e.html#36 Quote from comp.object http://www.garlic.com/~lynn/2007f.html#66 IBM System z9 http://www.garlic.com/~lynn/2007g.html#24 Bidirectional Binary Self-Joins http://www.garlic.com/~lynn/2007g.html#25 Bidirectional Binary Self-Joins http://www.garlic.com/~lynn/2007g.html#26 Bidirectional Binary Self-Joins http://www.garlic.com/~lynn/2007g.html#41 US Airways badmouths legacy system
From: Terje Mathisen on 4 Apr 2007 17:12 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. Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Charles Shannon Hendrix on 2 Apr 2007 16:33 ["Followup-To:" header set to alt.folklore.computers.] On 2007-03-30, jmfbahciv(a)aol.com <jmfbahciv(a)aol.com> wrote: >>And the system simply switches to another process while waiting for >>i/o. No problem. >> > > It is a problem because the monitor has run every job that was > runnable and _all_ are now waiting on I/O to complete. Look. > We saw this. Yeah, I'm surprised anyone would argue this point. Anyone who has played the upgrade game with x86 PCs knows about this. Upgrade my CPU, now my GPU is slow. Upgrade my GPU, and now my hard drives can't feed the CPU and GPU data fast enough. Of course, a big problem now is that hard drives aren't catching up. CPUs and GPUs are leaving them rapidly behind. You *can* get storage that is fast enough, but the expense is extreme, and it looks to be that way for some time to come. Part of the problem is also physical: small systems are just now starting to get the bus and interconnect speed needed to support faster external I/O. The graphics bus was the first to get the treatment, and I think now people area realizing that storage needs a big boost as well. -- shannon "AT" widomaker.com -- ["There are nowadays professors of philosophy, but not philosophers." ]
From: Charles Shannon Hendrix on 2 Apr 2007 16:36
["Followup-To:" header set to alt.folklore.computers.] > Sigh! I don't know what I'm going to do with you. > I wasn't talking about new games. The gamers have been > furiously typing and installing their old games and haven't > complained. Actually, Vista has been a nightmare for getting old games to work. -- shannon "AT" widomaker.com -- ["There are nowadays professors of philosophy, but not philosophers." ] |