Instead of corrupting data? It may stop it in its tracks, but that's no guarantee that stopping at that point prevents corrupting data. It may already be corrupted, or the act of truncating the computation (rather than gracefully failing) results in a now-corrupt output.
Now, I would buy "instead of continuing and potentially making matters worse." If you're expecting it to prevent data corruption outright, though, your expectations are too high.
Range checking only gets you so far, and it only catches the most basic bugs. Some languages give you 'assert()' to handle that; others have "programming by contract." Heck, wrap everything in classes that maintain tight control over their invariants and throw exceptions whenever they get cranky. That'll do, right? Not really. It's no silver bullet: Usually, the real bugs--the ones that take the longest to debug and require the deepest thought--result from more complex constraints getting violated, or fundamental thinkos about the problem domain.
For example, a buffer overflow can be caught with range checking on array indices. Compilers can (and will, if you ask) insert those checks. Typically, fixing the overflow is quick; you just add a simple check prior to filling the buffer. Buffer bloat, on the other hand is an Internet-wide level bug that no amount of range checking, constraint checking or other simple debug techniques will catch for you. It resulted from fundamental thinkos about how to configure the software under the Internet at a grand scale.
Ok, so that's perhaps an extreme comparison at far opposite ends of the scale. I'm fully aware that the bug "depth" vs. "frequency" distribution probably has a nice 1/x shape, with the shallower bugs occurring far, far more frequently than the deeper bugs. But, at the same time, by very virtue of their frequency and shallowness, they become the most quickly dispatched and easily avoided by a programmer with any experience.
At least for me, it's as if I've developed an X-ray vision for the really basic bugs. I've been known to walk into a coworker's office and point out "that isn't going to work--you have a stray semicolon after that for() loop" or "there's an off-by-one error there" or other such things. I don't have synesthesia, but still it's almost as if such things show up in a different, if invisible, color or something. Finding and fixing the deeper bugs requires understanding far more of the system at a more thorough level.
I personally am a fan of "debugging by printf." Kernighan and Pike make a good argument for it in The Practice of Programming. But, that's not limited to debugging, really. It's a great tool for understanding one's own code. Basically, whenever I want to get a greater intuition about how something works, I load it up with print statements at strategic points. I guess you might call it "understanding through printf."
I'll be honest: I didn't invest an hour of my time watching this video. How really does his technique compare to "understanding through printf"?
While it may be a bit extreme, I think the ideal solution is to start the workday a couple hours past sunrise in the winter and a couple hours before sunrise in the summer. You'll be active during the warmest hours of winter and cooler hours in summer, you'll have free time during daylight hours year round, you'll commute to work in bright sunlight during the winter, and you'll avoid staring into the sun while commuting most of the year.
Hmm, if you do that, I'll move to Michigan in the winter, but go south in the summer.. It only gets about 9 hours of daylight then. Seriously, what you're proposing would amount to folks at northern latitudes going to work at like 10AM in December, but like 4AM in June. Are you crazy?
And what about folks further south? Puerto Rico doesn't even do DST, because its sunrise/sunset vary by about 1hr end to end.
I hate missing sunshine in the winter, going to and coming from work in the dark. I personally would rather they just do year-round DST so I can at least get some sun on one end of my day. And, added bonus, I wouldn't have to dink with my clocks twice a year.
Well, there was an Intellivision computer. Two, actually: The Keyboard Component and the Entertainment Computer System. That said, none of the AD&D games for the Intellivision required either.
Ok, I'm sure someone up-thread has said this: Sure, video game consoles are made out of computer parts, and so technically have a computer inside them. That said, most people generally understand a video game console (whose primary and usually sole purpose is to play games) to be something different than what they'd call a computer.
While many people may primarily use their computer to play games, and while games may drive the development of much computer technology, computers are able to do a much wider range of things by default. You don't find too many word processors targeted at an Atari 2600, for example, or spreadsheets targeted at an Intellivision. But, you'll find both and more targeted at everything from a Commodore 64 to an Apple ][ to an Amiga.
"Does it come with a keyboard by default?" If the answer is no, then it's probably not what most people would consider a computer.
The distinction is strong enough that the FTC started fining Mattel $10,000 a day for failing to release their computer add-on for the Intellivision back in the 1980s. Mattel had marketed an add-on that would transform a basic Intellivision game system into a full-blown computer suitable for the sorts of things that people feel distinguish a "computer" from a "game system." When that machine turned out to be too expensive and Mattel didn't release it to the broader market, the FTC started slapping them with the fine. Eventually, Mattel released the wimpy "Entertainment Computer System" add-on, which did add a keyboard and an extremely weak BASIC variant. It barely crosses the threshold of what one might consider a "computer," but it was enough for the FTC.
In my mind, it serves as a useful example for defining the threshold between the two concepts.
In any case, I think this article, by confining itself to computer games, misses out on many RPG-defining games that were console only. Sure, you have the ground-breaking, if simple AD&D games for the Intellivision, but also you have games like Phantasy Star, Final Fantasy, Dragon Warrior, etc. Despite the distinction between "game console" and "computer", I think it's difficult to argue the two worlds didn't feed each other.
And just how exactly does that stop FooCompany.com from tracking me on their website even if I have cookies disabled? The answer is: it exactly allows FooCompany.com to track me more thoroughly. In fact, Bank of America uses one of these Flash apps to identify the computer I'm logging in from. It will skip some of the extra authentication steps it normally does.
The main use model I've heard is for these flash apps to store backup copies of cookies you might have blocked or deleted. Alternately, you can use this to throw some additional metadata into a URL or an http POST request, and you can now propagate this information across domains too. The main website hosts "tracker.swf" in their own domain (perhaps on an ad server that shares the domain but not the IP address), but it phones home via http to some other domain.
While the average web surfer doesn't think about Flash in that way, it's not too surprising a company that makes its fortunes on ad revenue and customer profiling understands its real role on the Web.
This is why I run flash-block, and only unblock the very occasional app and/or game I care to interact with, and not the half dozen other ones on the same page that don't seem to do anything interesting to me.
Ok, you and someone on the article both said the same thing, with absolutely nothing to back it up. Care to elaborate? I'm particularly curious how a.NET bytecode executable ends up as baroque machine code as opposed to CLI bytecode like most.NET languages.
It's out there. I remember reading about a engine control algorithm running on a 68HC16 microcontroller in Circuit Cellar Ink back in the mid-90s, and it was written in object oriented assembler. It caught me so off-guard that I still remember it almost 20 years later.
Multiples of 32K, eh? This smells like an issue that needs a well timed cache miss to trigger. IIRC, the L1D is 64K, two-way associative. Addresses that are multiples of 32K apart will map to the same cache line.
For the failing alignments, does one of the POP instructions cause %rsp to cross cache line boundaries?
TCP's checksum is notoriously weak though. For example, if you send a file filled with 0xFF, 0x00, 0xFF, 0x00.., but that triggered a 1 bit shift framing error so it came out, say, 0xFE, 0x01, 0xFE, 0x01, the TCP checksum would be the same for both. Heck, you can even swap bytes and TCP won't notice, since the TCP checksum is just a 1s complement 16-bit sum.
I'm going to guess that just about any fancier checksum probably would have caught the problem. Even a plain 16-bit CRC.
Given the range of clock speeds and devices (a 1.9GHz Opteron and a 3GHz Phenom II), that seems unlikely to me. If I'm not mistaken, they're even in different technology nodes (65nm vs. 45nm). So, an electrical issue seems unlikely to me. It seems more likely to me that it's a return-stack related logic issue, since it affects a deeply recursive function.
Since it happens only when the system is under load, I'm guessing you need a well timed cache miss or TLB miss to make it happen. The NOP that "fixes things" may be forcing some serialization which prevents the code above it from interfering with the function epilog.
Then there's unintended features such as pipeline oddities. If you have self modifying code, and it changes the destination of a jump instruction immediately before executing it, the computer will jump to the old address.
Long before CPUID, something like this was used to detect whether you were running an 8088 or an 8086. If I recall correctly, the BIU would fetch up to 3 "bus widths" ahead, which on the 8088 is 3 bytes, but on the 8086 is 6 bytes. If you modified some code in that 3 byte window of difference, the 8088 would see it but the 8086 would not. A branch, though, would flush the BIU.
Modern compilers also don't tend to push/pop anyway. They tend to atomically allocate a frame with a single SP update, and use frame-pointer-relative addressing to manipulate the stack frame. This allows for more parallelism, since any moves into/out-of the frame can run in parallel, and the only serialization is the single SP update. For example: (and pardon Slashdot's mandatory mangling of the formatting...)
That's a function entry with a pretty beefy stack frame. All RBP-relative addressing and a single stack move with the SUBQ. The other end of the function releases the stack frame with only a single "pop":
leave
ret
That moves RBP into RSP and pops the old RBP. No need to explicitly pop all those passed-on-the-stack arguments. This function isn't even a leaf function--it calls calloc, at least.
Now I do see some functions that push/pop RBX, so there are a few push/pops out there, and they also happen to be leaf functions. In fact, I do see an example of a "pop, pop, ret" right here:
Iiiiiinteresting. I don't even see RBX getting used explicitly elsewhere in the body of the function. I wonder what that is all about? RBX isn't used implicitly by anything that I remember offhand. That's usually AX/DX (or EAX/EDX, RAX/RDX). Hmmm.
I'm pretty sure it was with the introduction of the Pentium (which had the famous FDIV bug) that John Carmack officially made the switch to single precision FP for most things because it was finally fast enough. FP wasn't cheap, per se, but the simplification it brings over keeping track of binary points and precision/range tradeoffs in integerized algorithms should not be underestimated either.
For example, if I want to do a floating point multiply and add, I just say: f3 = f0 * f1 + f2. Before I even start writing a fixed-point multiply and add, I need to ask what the Q points (binary points) are for each of the terms, what Q point you'd like for the result, and what sort of rounding (if any) the result requires for stability. You can end up with a monstrosity like this, assuming all four numbers are at the same Q point:
x3 = (int)(((long long)x0 * x1 + (1LL > Q) + x2;
Ok, maybe you hide that behind a macro, but what about cases where some of the terms are at different Q points? A fully general macro (which is no fun to write, BTW) would also have a ton of arguments, and only reduce you to something like x3 = FXMULADD(x0, Q0, x1, Q1, x2, Q2, Q3); which won't win you any awards in the clarity department.
And look at the operations themselves, too. You have type promotion, extra adds and shifts... the instruction sequence itself isn't super efficient. It pays off when floating point takes 10s and 100s of cycles, but is a dubious win when most of the core FP starts coming down into the single digits. With the Pentium's dual pipes and the fact you could keep integer instructions flowing in parallel to the float, that's effectively what happened. And notice we haven't even talked about dynamic range and overflow errors and how they screw you up. If you have to add tests for that... yuck. With floating point, you degrade gracefully if your dynamic range spikes a little higher than you expect.
Anyway, getting back on topic: This isn't the first time an x86 has had a stack-pointer related bug. I remember the 80386s that had the so-called "POPAD bug". That one was a bit easier to hit.
Hopefully, AMD will be able to publish a microcode update or something to work around theirs. That's one thing modern x86s have over their predecessors: A good number of CPU bugs can be patched around with microcode updates. I believe Intel added that with the Pentium Pro, and AMD followed suit. I believe my Phenom is one of the affected parts. I guess I'll have to keep an eye out for such a patch.
Ugh. Winmodems were turds, period. They weren't modems at all. They were sound cards with a telephone interface. All of the "modem" was implemented on the host CPU. That's likely why it didn't run under OS/2--it needed a low-level driver that could preempt the operating system to keep the modem fed.
They had nothing whatsoever to do with the so-called "Rockwell chipset" that made my 1992 vintage Zoom so inexpensive relative to its time. I personally refused to ever knowingly buy a Winmodem. If my modem didn't hook up with a serial cable, I didn't want it. Once I moved to Linux in 1993, it wasn't just a point of pride, but of necessity.
Is it really the software, or is it proper formulations of hypotheses to test against the raw data? It's one thing to say "I'm looking for the XYZ particle." It's quite another to say "If an XYZ particle interacts with a ZYX particle in such-a-such way, it should result in ZZZ and XXX decaying in such-a-such pattern. Did we see that pattern?" Wash, rinse, repeat for all possible interactions and decay product patterns.
I'm not a particle physicist, but my impression from the outside looking in is that the limit seems to be the creativity of the physicists constructing "experiments" to run against the data based on careful extrapolations from the standard model.
Any physicists here on/. that can confirm, deny or refine that impression?
Slashdot Mirror
Instead of corrupting data? It may stop it in its tracks, but that's no guarantee that stopping at that point prevents corrupting data. It may already be corrupted, or the act of truncating the computation (rather than gracefully failing) results in a now-corrupt output.
Now, I would buy "instead of continuing and potentially making matters worse." If you're expecting it to prevent data corruption outright, though, your expectations are too high.
Range checking only gets you so far, and it only catches the most basic bugs. Some languages give you 'assert()' to handle that; others have "programming by contract." Heck, wrap everything in classes that maintain tight control over their invariants and throw exceptions whenever they get cranky. That'll do, right? Not really. It's no silver bullet: Usually, the real bugs--the ones that take the longest to debug and require the deepest thought--result from more complex constraints getting violated, or fundamental thinkos about the problem domain.
For example, a buffer overflow can be caught with range checking on array indices. Compilers can (and will, if you ask) insert those checks. Typically, fixing the overflow is quick; you just add a simple check prior to filling the buffer. Buffer bloat, on the other hand is an Internet-wide level bug that no amount of range checking, constraint checking or other simple debug techniques will catch for you. It resulted from fundamental thinkos about how to configure the software under the Internet at a grand scale.
Ok, so that's perhaps an extreme comparison at far opposite ends of the scale. I'm fully aware that the bug "depth" vs. "frequency" distribution probably has a nice 1/x shape, with the shallower bugs occurring far, far more frequently than the deeper bugs. But, at the same time, by very virtue of their frequency and shallowness, they become the most quickly dispatched and easily avoided by a programmer with any experience.
At least for me, it's as if I've developed an X-ray vision for the really basic bugs. I've been known to walk into a coworker's office and point out "that isn't going to work--you have a stray semicolon after that for() loop" or "there's an off-by-one error there" or other such things. I don't have synesthesia, but still it's almost as if such things show up in a different, if invisible, color or something. Finding and fixing the deeper bugs requires understanding far more of the system at a more thorough level.
But an hour long video holding all of the content? Couldn't it be a static document with a handful of short demo videos?
I personally am a fan of "debugging by printf." Kernighan and Pike make a good argument for it in The Practice of Programming. But, that's not limited to debugging, really. It's a great tool for understanding one's own code. Basically, whenever I want to get a greater intuition about how something works, I load it up with print statements at strategic points. I guess you might call it "understanding through printf."
I'll be honest: I didn't invest an hour of my time watching this video. How really does his technique compare to "understanding through printf"?
Hmm, if you do that, I'll move to Michigan in the winter, but go south in the summer.. It only gets about 9 hours of daylight then. Seriously, what you're proposing would amount to folks at northern latitudes going to work at like 10AM in December, but like 4AM in June. Are you crazy?
And what about folks further south? Puerto Rico doesn't even do DST, because its sunrise/sunset vary by about 1hr end to end.
I hate missing sunshine in the winter, going to and coming from work in the dark. I personally would rather they just do year-round DST so I can at least get some sun on one end of my day. And, added bonus, I wouldn't have to dink with my clocks twice a year.
Well, there was an Intellivision computer. Two, actually: The Keyboard Component and the Entertainment Computer System. That said, none of the AD&D games for the Intellivision required either.
There was a version of AD&D Treasure of Tarmin for the Mattel Aquarius Computer, though.
Ok, I'm sure someone up-thread has said this: Sure, video game consoles are made out of computer parts, and so technically have a computer inside them. That said, most people generally understand a video game console (whose primary and usually sole purpose is to play games) to be something different than what they'd call a computer.
While many people may primarily use their computer to play games, and while games may drive the development of much computer technology, computers are able to do a much wider range of things by default. You don't find too many word processors targeted at an Atari 2600, for example, or spreadsheets targeted at an Intellivision. But, you'll find both and more targeted at everything from a Commodore 64 to an Apple ][ to an Amiga.
"Does it come with a keyboard by default?" If the answer is no, then it's probably not what most people would consider a computer.
The distinction is strong enough that the FTC started fining Mattel $10,000 a day for failing to release their computer add-on for the Intellivision back in the 1980s. Mattel had marketed an add-on that would transform a basic Intellivision game system into a full-blown computer suitable for the sorts of things that people feel distinguish a "computer" from a "game system." When that machine turned out to be too expensive and Mattel didn't release it to the broader market, the FTC started slapping them with the fine. Eventually, Mattel released the wimpy "Entertainment Computer System" add-on, which did add a keyboard and an extremely weak BASIC variant. It barely crosses the threshold of what one might consider a "computer," but it was enough for the FTC.
In my mind, it serves as a useful example for defining the threshold between the two concepts.
In any case, I think this article, by confining itself to computer games, misses out on many RPG-defining games that were console only. Sure, you have the ground-breaking, if simple AD&D games for the Intellivision, but also you have games like Phantasy Star, Final Fantasy, Dragon Warrior, etc. Despite the distinction between "game console" and "computer", I think it's difficult to argue the two worlds didn't feed each other.
I'm not saying it's some big security hole. I'm saying it's the reason it ended up under the "Privacy" tab in Chrome, as opposed to somewhere else.
And just how exactly does that stop FooCompany.com from tracking me on their website even if I have cookies disabled? The answer is: it exactly allows FooCompany.com to track me more thoroughly. In fact, Bank of America uses one of these Flash apps to identify the computer I'm logging in from. It will skip some of the extra authentication steps it normally does.
The main use model I've heard is for these flash apps to store backup copies of cookies you might have blocked or deleted. Alternately, you can use this to throw some additional metadata into a URL or an http POST request, and you can now propagate this information across domains too. The main website hosts "tracker.swf" in their own domain (perhaps on an ad server that shares the domain but not the IP address), but it phones home via http to some other domain.
Putting "Flash" under "Privacy" makes sense if you understand how much of the Flash out there really gets used. Flash apps can store a fair bit of data locally on your HD without setting a normal HTTP cookie, which makes tiny, invisible Flash apps handy for tracking purposes.
While the average web surfer doesn't think about Flash in that way, it's not too surprising a company that makes its fortunes on ad revenue and customer profiling understands its real role on the Web.
This is why I run flash-block, and only unblock the very occasional app and/or game I care to interact with, and not the half dozen other ones on the same page that don't seem to do anything interesting to me.
Hey, folks, where's the screenshots at? Here's mine...
Ok, you and someone on the article both said the same thing, with absolutely nothing to back it up. Care to elaborate? I'm particularly curious how a .NET bytecode executable ends up as baroque machine code as opposed to CLI bytecode like most .NET languages.
It's out there. I remember reading about a engine control algorithm running on a 68HC16 microcontroller in Circuit Cellar Ink back in the mid-90s, and it was written in object oriented assembler. It caught me so off-guard that I still remember it almost 20 years later.
I should say, does %rsp cross cache line boundaries in that particular pop sequence at the time of the crash?
Multiples of 32K, eh? This smells like an issue that needs a well timed cache miss to trigger. IIRC, the L1D is 64K, two-way associative. Addresses that are multiples of 32K apart will map to the same cache line.
For the failing alignments, does one of the POP instructions cause %rsp to cross cache line boundaries?
TCP's checksum is notoriously weak though. For example, if you send a file filled with 0xFF, 0x00, 0xFF, 0x00.., but that triggered a 1 bit shift framing error so it came out, say, 0xFE, 0x01, 0xFE, 0x01, the TCP checksum would be the same for both. Heck, you can even swap bytes and TCP won't notice, since the TCP checksum is just a 1s complement 16-bit sum.
I'm going to guess that just about any fancier checksum probably would have caught the problem. Even a plain 16-bit CRC.
Given the range of clock speeds and devices (a 1.9GHz Opteron and a 3GHz Phenom II), that seems unlikely to me. If I'm not mistaken, they're even in different technology nodes (65nm vs. 45nm). So, an electrical issue seems unlikely to me. It seems more likely to me that it's a return-stack related logic issue, since it affects a deeply recursive function.
Since it happens only when the system is under load, I'm guessing you need a well timed cache miss or TLB miss to make it happen. The NOP that "fixes things" may be forcing some serialization which prevents the code above it from interfering with the function epilog.
Long before CPUID, something like this was used to detect whether you were running an 8088 or an 8086. If I recall correctly, the BIU would fetch up to 3 "bus widths" ahead, which on the 8088 is 3 bytes, but on the 8086 is 6 bytes. If you modified some code in that 3 byte window of difference, the 8088 would see it but the 8086 would not. A branch, though, would flush the BIU.
Modern compilers also don't tend to push/pop anyway. They tend to atomically allocate a frame with a single SP update, and use frame-pointer-relative addressing to manipulate the stack frame. This allows for more parallelism, since any moves into/out-of the frame can run in parallel, and the only serialization is the single SP update. For example: (and pardon Slashdot's mandatory mangling of the formatting...)
pushq %rbp #
movq %rsp, %rbp #,
subq $64, %rsp #,
movq %rdi, -40(%rbp) # spec, spec
movl %esi, -44(%rbp) # source_x, source_x
movl %edx, -48(%rbp) # source_y, source_y
movl %ecx, -52(%rbp) # target_x, target_x
movl %r8d, -56(%rbp) # target_y, target_y
movl %r9d, -60(%rbp) # bpp, bpp
That's a function entry with a pretty beefy stack frame. All RBP-relative addressing and a single stack move with the SUBQ. The other end of the function releases the stack frame with only a single "pop":
leave
ret
That moves RBP into RSP and pops the old RBP. No need to explicitly pop all those passed-on-the-stack arguments. This function isn't even a leaf function--it calls calloc, at least.
Now I do see some functions that push/pop RBX, so there are a few push/pops out there, and they also happen to be leaf functions. In fact, I do see an example of a "pop, pop, ret" right here:
gfx_scale_set_palette:
....
pushq %rbp #
movq %rsp, %rbp #,
pushq %rbx #
popq %rbx #
leave
ret
Iiiiiinteresting. I don't even see RBX getting used explicitly elsewhere in the body of the function. I wonder what that is all about? RBX isn't used implicitly by anything that I remember offhand. That's usually AX/DX (or EAX/EDX, RAX/RDX). Hmmm.
Ugh... this expression was correct when I typed it. Part of it got eaten due to missing HTML escapes. Grrr...
x3 = (int)(((long long)x0 * x1 + (1LL << (Q-1)) >> Q) + x2;
I'm pretty sure it was with the introduction of the Pentium (which had the famous FDIV bug) that John Carmack officially made the switch to single precision FP for most things because it was finally fast enough. FP wasn't cheap, per se, but the simplification it brings over keeping track of binary points and precision/range tradeoffs in integerized algorithms should not be underestimated either.
For example, if I want to do a floating point multiply and add, I just say: f3 = f0 * f1 + f2. Before I even start writing a fixed-point multiply and add, I need to ask what the Q points (binary points) are for each of the terms, what Q point you'd like for the result, and what sort of rounding (if any) the result requires for stability. You can end up with a monstrosity like this, assuming all four numbers are at the same Q point:
x3 = (int)(((long long)x0 * x1 + (1LL > Q) + x2;
Ok, maybe you hide that behind a macro, but what about cases where some of the terms are at different Q points? A fully general macro (which is no fun to write, BTW) would also have a ton of arguments, and only reduce you to something like x3 = FXMULADD(x0, Q0, x1, Q1, x2, Q2, Q3); which won't win you any awards in the clarity department.
And look at the operations themselves, too. You have type promotion, extra adds and shifts... the instruction sequence itself isn't super efficient. It pays off when floating point takes 10s and 100s of cycles, but is a dubious win when most of the core FP starts coming down into the single digits. With the Pentium's dual pipes and the fact you could keep integer instructions flowing in parallel to the float, that's effectively what happened. And notice we haven't even talked about dynamic range and overflow errors and how they screw you up. If you have to add tests for that... yuck. With floating point, you degrade gracefully if your dynamic range spikes a little higher than you expect.
Anyway, getting back on topic: This isn't the first time an x86 has had a stack-pointer related bug. I remember the 80386s that had the so-called "POPAD bug". That one was a bit easier to hit.
Hopefully, AMD will be able to publish a microcode update or something to work around theirs. That's one thing modern x86s have over their predecessors: A good number of CPU bugs can be patched around with microcode updates. I believe Intel added that with the Pentium Pro, and AMD followed suit. I believe my Phenom is one of the affected parts. I guess I'll have to keep an eye out for such a patch.
Ugh. Winmodems were turds, period. They weren't modems at all. They were sound cards with a telephone interface. All of the "modem" was implemented on the host CPU. That's likely why it didn't run under OS/2--it needed a low-level driver that could preempt the operating system to keep the modem fed.
They had nothing whatsoever to do with the so-called "Rockwell chipset" that made my 1992 vintage Zoom so inexpensive relative to its time. I personally refused to ever knowingly buy a Winmodem. If my modem didn't hook up with a serial cable, I didn't want it. Once I moved to Linux in 1993, it wasn't just a point of pride, but of necessity.
Is it really the software, or is it proper formulations of hypotheses to test against the raw data? It's one thing to say "I'm looking for the XYZ particle." It's quite another to say "If an XYZ particle interacts with a ZYX particle in such-a-such way, it should result in ZZZ and XXX decaying in such-a-such pattern. Did we see that pattern?" Wash, rinse, repeat for all possible interactions and decay product patterns.
I'm not a particle physicist, but my impression from the outside looking in is that the limit seems to be the creativity of the physicists constructing "experiments" to run against the data based on careful extrapolations from the standard model.
Any physicists here on /. that can confirm, deny or refine that impression?
Of course, M is the 13th character in the English alphabet, so aren't they really just two ways of saying the same thing?
Ok, so mine wasn't the only brain thinking "floating point particle accelerator" or something in that space...