First, the Microsoft guy says that the reported behavior would constitute a DoS:
If you can crash my app so that I can't restart it, or have to reboot my system, well, OK - that's a DoS.
The other article, based on the security researcher's work, calls the same thing a "denial-of-service-like situation":
Two of the three bugs result in a denial-of-service-like situation, with the PC's processor maxed out at 100%, making the machine unusable until it's rebooted.
The disagreement is not over how to describe the reported behavior. The blog entry by the Microsoft guy talks about a simple, harmless crash, not a freeze and reboot, which means he isn't addressing the more serious reports at all. The official quotes from Microsoft take the same tack. It seems that Microsoft is disputing the existence of the freeze-and-reboot bug, or maybe they're just focusing on the less severe bug to confuse the issue and distract from the serious ones. Unfortunately, none of the linked articles answers that question. I can't tell whether this is being spun by Microsoft or by an anti-Microsoft summary writer, but something is missing from the story.
To position his paragraphs one above the other, he puts the one he wants above before the one he wants below in the document, and separates them with <P>. He positions his images using the appropriate attributes.
I know this is picky, since you correct yourself later, but he doesn't position anything. No way, no how. If he's even thinking about positioning, then he's violating the spirit of semantic markup by thinking about a particular browser implementation instead of thinking of the whole range of devices that render HTML, some of which don't render it visually at all.
They are a bunch or corporatists and don't even know it.
Fixed for clarity, quoted for truth. The systems for ensuring justice and freedom envisioned by libertarians are designed to protect people from only one possible bogeyman: the government. The idea that non-government entities can accumulate and wield obscene amounts of power, rendering the rights of individuals moot, either doesn't bother them or doesn't cross their minds. They don't want to stop people from acquiring power and using it to violate others' freedom. Their systems allow and virtually guarantee it. They only want to remove democratic politics as means to that power. Of course, that just makes a bunch of democratically elected rats irrelevant and replaces them with a bunch of rich or violent rats, depending on the system.
I'd be curious what kinds of professional obligations US Bar and Law societies impose on their members, particularly as to how far they allow such members to advocate their clients cases beyond the interests of justice.
As an American, I have been taught (through civics classes and television) that lawyers, with the exception of public prosecutors, are not supposed to concern themselves with justice. Lawyers are supposed to be single-minded sociopaths who are guided only by the interests of their client and the restraints of the legal system. The system is supposed to be set up so that justice emerges from this Battle Royal of lawyers and clients. If the system contains potential for abuse, it is the responsibility of lawyers to exploit it and the responsibility of society as a whole to fix it so that further abuse is prevented.
Since when do you have to be tried and convicted before being hassled by the police, especially when a big, rich Pillar of the Community tells the cops that some scruffy homocidal loser was stalking him? The cops would be good and pissed when they figured out how they'd been used, but he could probably do it in such a way that there would be no recourse against him.
That lawsuit has a pretty sound basis. From the link:
Although the nutritional information claims a serving contains 2.5 grams of fat, it actually has... 8.5 grams of fat.
The guys getting sued clearly and drastically misrepresented their product. The legal boilerplate sounds silly, but is that really anything to be surprised about? Surely you can pull a Pythonesque sentence or two out of even the most serious case.
Check your sarcasm meter; it's giving you false negatives;-)
I've read other definitions of artificial intelligence, but they are mostly just silly attempts to give some rigor to unsound intuitions like the one I stated. The ones that make any sense are not compatible with the way the term "artificial intelligence" is normally understood. They are meant to replace the traditional category of AI rather than define it. I don't see that the term as traditionally used has any use except in industry, where it is convenient shorthand for "the stuff that is difficult, but which a layman might expect to be easy." Industry finds it expedient to use terms that are relative to the state of the art, but it is wrong to pretend that these terms have any scientific or philosophical importance.
But intelligence is what distinguishes people from machines. An artificial intelligence is any machine that invalidates a person's means of making that distinction. Eventually, when computers can replicate everything we do, we will no longer respect intelligence or attach any importance to it. That's when we'll get REALLY conceited and invest ourselves in religious explanations of our superiority, since the functional ones will have failed.
a strong background that runs all the way to the bare metal (ie, assembly programming)
I agree with the general thrust of your post, but this is a pet peeve of mine. (Or maybe I'm just showing off my favority new bit of knowledge. Is there a difference?) Assembly programming doesn't take you anywhere near the metal on many modern processors, especially superscalar workstation and server processors. True, with some kinds of processors, the ISA gives you an idea of the how the processor is structured and how it will perform, but with many others, the real processor bears no similarity to the simple machine model suggested by the ISA. Modern x86 and x86_64 chips from Intel and AMD don't even execute the machine code directly; they dynamically translate the instruction stream into something more suitable for superscalar execution. x86 assembly programming only gets you close to the bare metal of (maybe) ten years ago.
the Trusted Computing Group is busy making every PC into a Tivo
Aha! Thank you for making this connection for me. I was having trouble giving a damn about this whole issue, but now I see it makes a huge difference not just for consumer electronics but for the PC hardware I'm going to (be forced to) buy in the next five years. Companies that make hardware impossible to use from open software should not be allowed to leech off GPL'ed code to do so.
I got into software well after Linux and Linus were famous, and RMS has always seemed like a bigger luminary than Linus Torvalds. I'm not a Free Software zealot. I write commercial software, and I'm very grateful for all the open-source code I use under commercial-friendly licenses. However, it can't be denied that RMS is in a class above Linus.
In the history books, Linus will go down as a hero. RMS will go down as a visionary. There's a big difference. A hero performs great deeds and proves that what was once thought impossible is possible. A visionary molds the ideas by which the next generation of heroes sees the world and chooses great deeds to accomplish. Linus is, by temperment, not a revolutionary guy. Yet he adopted a revolutionary banner (the GPL) and applied his talent to a revolutionary deed. RMS' revolution directed Linus' heroism. History is crawling with successful heroes, but their actions are guided by a relatively small number of successful visionaries.
I never said it was easy, but I have even seen it mathematically proven that any algorithm can be done in hardware, and I've duplicated most hardware into software myself, for those designs that I wanted to emulate.
I don't doubt that any software can be duplicated in hardware. Any real, running software is already implemented in hardware in some sense. I also accept that any hardware that can be described by digital logic can be duplicated in software. That leaves out an awful lot, though, including all analog devices.
FPGA designs are supposed to implement digital logic, but a mistake can easily result in a design whose behavior isn't purely digital. Those configurations, though undesirable in most circumstances, are real and can't be duplicated in software. I'm a bit out of my depth here, but many posters on this page have described examples of hardware behavior that can't be described by digital logic, and therefore can't be duplicated by abstract software.
I think he meant that misleading attempts to impress are responsible for most sexual reproduction, hence quite relevant both to your level of sexual activity and the topic of evolution. By making an on-topic statement about another poster's lack of sexual experience, he has clinched his place in the Slashdot Hall of Fame.
I won't go into details here, but anything that can be implemented in hardware can be done in software and the other way around too. This is a nearly ancient Electrical Engineering principle.
This is only true for the very small subset of designs that don't suffer from race conditions and other phenomena that hardware engineers regard as bugs. When you randomly flip gates in the design, you don't necessarily get valid digital logic.
Didn't I read about this ten years ago in Discover magazine? I remember being fascinated that some scientists had "evolved" a hardware design on reconfigurable hardware (FPGA? CPLD? don't remember), and it seemed to rely on subtle electrical effects rather than simple digital logic. The design would only work on the exact chip it was evolved on. If they even replaced the board's power supply with a different sample of the same model, it stopped producing correct output. Most of the logic gates were logically disconnected from the input and output, yet they were necessary to the design working. Amazing stuff.
I think the parent is talking about the fact that finance is full of extremely smart and hardworking people who do amazing things with Excel, VB, etc. but shy away from any tools that are too hard for Joe Shlub the data entry clerk. If only they realized that the amount of time and intelligence they invest in Excel brittleware dwarfs the time and intelligence needed to learn decent tools. But instead, you get the equivalent of, "I'm not smart enough to learn Windows. Instead I programmed my own multi-tasking windowing operating system from scratch, in assembly. I can't afford to spend time learning fancy tools."
A display that's flexible when powered down and rigid when activated. Then the display could be folded or rolled up when not in use.
A decent-sized keyboard/trackpad/battery (with decent key travel) that folds in half.
A cell phone that runs Linux and all my regular apps, but which can operate in a limited low-power mode for unattached use.
Then I carry my cell phone as normal, and when I want to use it as a computer, I unfold the keyboard/trackpad/battery and unroll whatever size screen I want. Do I want the 20" screen? Or am I on a bus and only need the 8" 640x480 screen to check my email? Maybe I have room for the 20" screen but decide to use a smaller one to conserve battery power. The keyboard would have a little arm at the top to clip a small screen to; the 20" screen would probably have its own stand that would fold into a straight line so you could roll the screen around it when not in use.
Interesting. I had a perfect record with my credit card until I missed a payment while moving. Then BAM they started charging regular fees on my previously no-fee account, my interest rate went up, and of course my credit limit went up. (Raising my credit limit was quite logical, since my missed payment was the first sign that they might someday make a decent profit off me.) Maybe if I had just called them I could have reversed all that:-O
This sort of "fiction" is a fundamental requirement of these devices to be classified as microprocessors; otherwise you'd have to perform "programming" by doing digital logic design or microcoding. It's like saying that car manufactures accomodate drivers legacy expectations by providing wheels for the car.
It isn't necessary for the ISA to be a fiction. In simple processors, the ISA *can* reflect the real, concrete structure of the processor. Assembly statements like "mov r2, r1" might tell you quite literally what is happening inside the processor. In fact, the programmer doesn't even need to know whether the ISA reflects the real structure of the processor or not. What matters to the programmer is that the behavior of the processor conforms to the model specified by the ISA.
Hardware designers went from processors almost as simple as a simple ISA to processors thousands of times more complex than the most complex ISA. Meanwhile, software programmers didn't have to come along for the ride. ISAs grew, but not at the same rate as hardware complexity. This is part of what I mean by hardware designers bending over backwards for software programmers. When it becomes possible to put more and more transistors on a microchip, yet the programming interface doesn't scale with the amount of processing power, it becomes hard to use the power efficiently. A Xeon can do a huge amount of work per unit time, but it's like five hundred people getting together to build a small house. When you throw all those transistors at a single instruction stream, most of them get applied to fairly small improvements like improving branch prediction by 2%. The instruction stream is simply inadequate to take advantage of that much hardware. Hardware efficiency suffers so programmers can keep using a simple model.
That's the logic behind multicore chips, and it's also why the Cell processor can put up such ludicrous performance numbers without any kind of technology breakthrough. Instead of wasting vast numbers of transistors on making small tweaks to single-process execution, why not make them available for real work? Let the programmer decide what to do with them. The programming model gets more complicated, but the programmer gets to use a bunch processing power that has until now been inefficiently applied because the programming interface has been too narrow.
Given the fact that the 8086/8088 couldn't natively run 8085 programs, I don't think backward compatibility was a major goal. If you have to translate instructions anyway, changing from an 8 bit address to 16 bit address isn't that much harder.
I didn't mention backward compatibility; I mentioned porting. I'm pretty sure that changing the pointer size is in fact a big deal, especially for languages like C where types aren't exactly respected. If I understand what I'm reading, Intel's design allowed old programs that used 16-bit addressing to be recompiled to use 16-bit addressing inside a single segment. That meant that nobody had to dig through old code to find and correct all the places where a pointer was stored in a 16-bit datatype. Meanwhile, new programs could use up to 20 bits of address space.
I didn't see the "leaning over backwards" you refer to. What hardware improvements have hardware designers avoided because it would have caused the current programming model to change? You don't have to look any further than the x86 architecture with its segmented memory to conclude that ease of programming has never been a key goal at Intel.
Intel desktop and workstation microprocessors, or any superscalar microprocessors for that matter, are a great example. The programmer (or compiler) writes a single-threaded assembly language program for an extremely simple machine that is basically a fiction. The assembly programmer gets to think in terms of ISA abstractions like "the EAX register" when in the real microprocessor, with its superscalar pipelines, out-of-order execution, branch prediction, and so forth, there really isn't anything you could reasonably point to and say, "This is the EAX register." The microprocessor is a dizzyingly complex hardware simulation of the simple machine that software programmers use as their mental model of "the hardware."
Thanks to the insulation provided by the instruction set architecture, programmers have been able to mostly ignore the growing complexity of microprocessors and continue thinking in terms of the same single-threaded in-order execution model and a relatively slowly evolving set of ISAs. The cost of this mismatch between hardware and programming model becomes evident when you look at how much more performance you can get when you shift some of the burden from the hardware to the programmer, as with the Cell processor. (You can also save lots of power by forcing software tools to manage instruction scheduling. Microprocessors in cell phones and other battery-powered devices typically can't afford to spend power on analyzing, reordering, and creatively dispatching instruction streams. They leave that to compiler writers and programmers.)
When you look at the alternatives (and I'm sure Intel, AMD, and IBM have worked with more alternatives than I'll ever even hear of), symmetric multiprocessing is the smallest, least disruptive step that software developers could be asked to take. We still get a nice simple machine model that thankfully reflects very little of the complexity of the underlying hardware. The only thing that has gotten worse is that instead of getting unconditional, dramatic performance improvements for no effort at all, we get dramatic performance improvements conditional on our ability to use cores efficiently. And heck, single-threaded programs might keep getting faster anyway.
P.S. I admit I don't know anything about Intel's introduction of segmentation, but reading what Wikipedia says, it seems like the key selling point of segmentation was the ease of porting old software. Requiring users to move from straightforward 16-bit addressing to straightforward 32-bit addressing would have kept both hardware and software simpler than using Intel's segmentation idea, but segmentation made it easier to port old software, so it was a success. It sounds more like a present vs. future tradeoff than a software vs. hardware tradeoff.
There are two different industries involved here: the hardware processor industry and the software industry. It looks like the former is looking for the latter to bail it out.
Considering that hardware designers have been leaning over backwards for years to help software programmers stick with one fairly easy programming model, I wouldn't be too quick to blame the hardware industry. They know which side their bread is buttered on. The hardware company that requires the least adaptation from software developers has the advantage, just like the software company that requires the least change and adaptation from users always has the advantage.
I think all the discussion over this issue suggests that it isn't low-hanging fruit.
This is Slashdot. People argue against something so they'll never have to try it:-) I've never had a choice; my first professional job was at a Java shop that used multithreaded servers, and at my current gig one of my ongoing tasks is to add multithreading to single-threaded C++ apps so that our customers get as much power as possible out of their multi-CPU workstations.
What I've learned is that there's basically a one-time cost when you redesign and refactor a single-threaded app to a multi-threaded app. Multi-threaded design is harder, but the resulting designs are often simpler, since single-threading forces you to specify many arbitrary choices about sequencing. Then when you consider resource utilization, it turns out those arbitrary choices aren't arbitrary after all, so you end up interleaving work in weird ways to keep resource utilization up. With multi-threaded apps, I just leave it up to the thread scheduler, which does a pretty damn good job.
On the programs I've worked on, the advantages of cleaner design (no need to specify serialization where it doesn't exist, no spaghetti flow control) have cancelled out the disadvantages of more complicated implementation (ensuring protection for every shared resource.) The cost of ensuring protection is mitigated by the fact that most of the resource-protection code in my programs is contained in a few shared data structure implementations that I reuse in all my projects.
Of course I write lots of single-threaded programs, too. Most of my programs start out single-threaded, with an eye toward future multithreading. Single threading has a decided advantage for simple programs; I just believe that advantage disappears when programs get large and complicated.
Slashdot Mirror
The other article, based on the security researcher's work, calls the same thing a "denial-of-service-like situation":
The disagreement is not over how to describe the reported behavior. The blog entry by the Microsoft guy talks about a simple, harmless crash, not a freeze and reboot, which means he isn't addressing the more serious reports at all. The official quotes from Microsoft take the same tack. It seems that Microsoft is disputing the existence of the freeze-and-reboot bug, or maybe they're just focusing on the less severe bug to confuse the issue and distract from the serious ones. Unfortunately, none of the linked articles answers that question. I can't tell whether this is being spun by Microsoft or by an anti-Microsoft summary writer, but something is missing from the story.
I know this is picky, since you correct yourself later, but he doesn't position anything. No way, no how. If he's even thinking about positioning, then he's violating the spirit of semantic markup by thinking about a particular browser implementation instead of thinking of the whole range of devices that render HTML, some of which don't render it visually at all.
As an American, I have been taught (through civics classes and television) that lawyers, with the exception of public prosecutors, are not supposed to concern themselves with justice. Lawyers are supposed to be single-minded sociopaths who are guided only by the interests of their client and the restraints of the legal system. The system is supposed to be set up so that justice emerges from this Battle Royal of lawyers and clients. If the system contains potential for abuse, it is the responsibility of lawyers to exploit it and the responsibility of society as a whole to fix it so that further abuse is prevented.
Since when do you have to be tried and convicted before being hassled by the police, especially when a big, rich Pillar of the Community tells the cops that some scruffy homocidal loser was stalking him? The cops would be good and pissed when they figured out how they'd been used, but he could probably do it in such a way that there would be no recourse against him.
The first two don't sound stupid. They sound like an awesome combination of a sense of humor and a lot of free time.
Check your sarcasm meter; it's giving you false negatives ;-)
I've read other definitions of artificial intelligence, but they are mostly just silly attempts to give some rigor to unsound intuitions like the one I stated. The ones that make any sense are not compatible with the way the term "artificial intelligence" is normally understood. They are meant to replace the traditional category of AI rather than define it. I don't see that the term as traditionally used has any use except in industry, where it is convenient shorthand for "the stuff that is difficult, but which a layman might expect to be easy." Industry finds it expedient to use terms that are relative to the state of the art, but it is wrong to pretend that these terms have any scientific or philosophical importance.
Right! That's why I get paid more than my former classmates. I eat and consume much more than they do.
But intelligence is what distinguishes people from machines. An artificial intelligence is any machine that invalidates a person's means of making that distinction. Eventually, when computers can replicate everything we do, we will no longer respect intelligence or attach any importance to it. That's when we'll get REALLY conceited and invest ourselves in religious explanations of our superiority, since the functional ones will have failed.
I agree with the general thrust of your post, but this is a pet peeve of mine. (Or maybe I'm just showing off my favority new bit of knowledge. Is there a difference?) Assembly programming doesn't take you anywhere near the metal on many modern processors, especially superscalar workstation and server processors. True, with some kinds of processors, the ISA gives you an idea of the how the processor is structured and how it will perform, but with many others, the real processor bears no similarity to the simple machine model suggested by the ISA. Modern x86 and x86_64 chips from Intel and AMD don't even execute the machine code directly; they dynamically translate the instruction stream into something more suitable for superscalar execution. x86 assembly programming only gets you close to the bare metal of (maybe) ten years ago.
Aha! Thank you for making this connection for me. I was having trouble giving a damn about this whole issue, but now I see it makes a huge difference not just for consumer electronics but for the PC hardware I'm going to (be forced to) buy in the next five years. Companies that make hardware impossible to use from open software should not be allowed to leech off GPL'ed code to do so.
I got into software well after Linux and Linus were famous, and RMS has always seemed like a bigger luminary than Linus Torvalds. I'm not a Free Software zealot. I write commercial software, and I'm very grateful for all the open-source code I use under commercial-friendly licenses. However, it can't be denied that RMS is in a class above Linus.
In the history books, Linus will go down as a hero. RMS will go down as a visionary. There's a big difference. A hero performs great deeds and proves that what was once thought impossible is possible. A visionary molds the ideas by which the next generation of heroes sees the world and chooses great deeds to accomplish. Linus is, by temperment, not a revolutionary guy. Yet he adopted a revolutionary banner (the GPL) and applied his talent to a revolutionary deed. RMS' revolution directed Linus' heroism. History is crawling with successful heroes, but their actions are guided by a relatively small number of successful visionaries.
I don't doubt that any software can be duplicated in hardware. Any real, running software is already implemented in hardware in some sense. I also accept that any hardware that can be described by digital logic can be duplicated in software. That leaves out an awful lot, though, including all analog devices.
FPGA designs are supposed to implement digital logic, but a mistake can easily result in a design whose behavior isn't purely digital. Those configurations, though undesirable in most circumstances, are real and can't be duplicated in software. I'm a bit out of my depth here, but many posters on this page have described examples of hardware behavior that can't be described by digital logic, and therefore can't be duplicated by abstract software.
I think he meant that misleading attempts to impress are responsible for most sexual reproduction, hence quite relevant both to your level of sexual activity and the topic of evolution. By making an on-topic statement about another poster's lack of sexual experience, he has clinched his place in the Slashdot Hall of Fame.
Replying to note that another Slashdotter has gone me one better and provided a link to the story I remembered.
This is only true for the very small subset of designs that don't suffer from race conditions and other phenomena that hardware engineers regard as bugs. When you randomly flip gates in the design, you don't necessarily get valid digital logic.
Didn't I read about this ten years ago in Discover magazine? I remember being fascinated that some scientists had "evolved" a hardware design on reconfigurable hardware (FPGA? CPLD? don't remember), and it seemed to rely on subtle electrical effects rather than simple digital logic. The design would only work on the exact chip it was evolved on. If they even replaced the board's power supply with a different sample of the same model, it stopped producing correct output. Most of the logic gates were logically disconnected from the input and output, yet they were necessary to the design working. Amazing stuff.
I think the parent is talking about the fact that finance is full of extremely smart and hardworking people who do amazing things with Excel, VB, etc. but shy away from any tools that are too hard for Joe Shlub the data entry clerk. If only they realized that the amount of time and intelligence they invest in Excel brittleware dwarfs the time and intelligence needed to learn decent tools. But instead, you get the equivalent of, "I'm not smart enough to learn Windows. Instead I programmed my own multi-tasking windowing operating system from scratch, in assembly. I can't afford to spend time learning fancy tools."
Then I carry my cell phone as normal, and when I want to use it as a computer, I unfold the keyboard/trackpad/battery and unroll whatever size screen I want. Do I want the 20" screen? Or am I on a bus and only need the 8" 640x480 screen to check my email? Maybe I have room for the 20" screen but decide to use a smaller one to conserve battery power. The keyboard would have a little arm at the top to clip a small screen to; the 20" screen would probably have its own stand that would fold into a straight line so you could roll the screen around it when not in use.
Interesting. I had a perfect record with my credit card until I missed a payment while moving. Then BAM they started charging regular fees on my previously no-fee account, my interest rate went up, and of course my credit limit went up. (Raising my credit limit was quite logical, since my missed payment was the first sign that they might someday make a decent profit off me.) Maybe if I had just called them I could have reversed all that :-O
I think I would keep a close eye on my TTL. Who would be in charge of enforcing that, anyway?
It isn't necessary for the ISA to be a fiction. In simple processors, the ISA *can* reflect the real, concrete structure of the processor. Assembly statements like "mov r2, r1" might tell you quite literally what is happening inside the processor. In fact, the programmer doesn't even need to know whether the ISA reflects the real structure of the processor or not. What matters to the programmer is that the behavior of the processor conforms to the model specified by the ISA.
Hardware designers went from processors almost as simple as a simple ISA to processors thousands of times more complex than the most complex ISA. Meanwhile, software programmers didn't have to come along for the ride. ISAs grew, but not at the same rate as hardware complexity. This is part of what I mean by hardware designers bending over backwards for software programmers. When it becomes possible to put more and more transistors on a microchip, yet the programming interface doesn't scale with the amount of processing power, it becomes hard to use the power efficiently. A Xeon can do a huge amount of work per unit time, but it's like five hundred people getting together to build a small house. When you throw all those transistors at a single instruction stream, most of them get applied to fairly small improvements like improving branch prediction by 2%. The instruction stream is simply inadequate to take advantage of that much hardware. Hardware efficiency suffers so programmers can keep using a simple model.
That's the logic behind multicore chips, and it's also why the Cell processor can put up such ludicrous performance numbers without any kind of technology breakthrough. Instead of wasting vast numbers of transistors on making small tweaks to single-process execution, why not make them available for real work? Let the programmer decide what to do with them. The programming model gets more complicated, but the programmer gets to use a bunch processing power that has until now been inefficiently applied because the programming interface has been too narrow.
I didn't mention backward compatibility; I mentioned porting. I'm pretty sure that changing the pointer size is in fact a big deal, especially for languages like C where types aren't exactly respected. If I understand what I'm reading, Intel's design allowed old programs that used 16-bit addressing to be recompiled to use 16-bit addressing inside a single segment. That meant that nobody had to dig through old code to find and correct all the places where a pointer was stored in a 16-bit datatype. Meanwhile, new programs could use up to 20 bits of address space.
Intel desktop and workstation microprocessors, or any superscalar microprocessors for that matter, are a great example. The programmer (or compiler) writes a single-threaded assembly language program for an extremely simple machine that is basically a fiction. The assembly programmer gets to think in terms of ISA abstractions like "the EAX register" when in the real microprocessor, with its superscalar pipelines, out-of-order execution, branch prediction, and so forth, there really isn't anything you could reasonably point to and say, "This is the EAX register." The microprocessor is a dizzyingly complex hardware simulation of the simple machine that software programmers use as their mental model of "the hardware."
Thanks to the insulation provided by the instruction set architecture, programmers have been able to mostly ignore the growing complexity of microprocessors and continue thinking in terms of the same single-threaded in-order execution model and a relatively slowly evolving set of ISAs. The cost of this mismatch between hardware and programming model becomes evident when you look at how much more performance you can get when you shift some of the burden from the hardware to the programmer, as with the Cell processor. (You can also save lots of power by forcing software tools to manage instruction scheduling. Microprocessors in cell phones and other battery-powered devices typically can't afford to spend power on analyzing, reordering, and creatively dispatching instruction streams. They leave that to compiler writers and programmers.)
When you look at the alternatives (and I'm sure Intel, AMD, and IBM have worked with more alternatives than I'll ever even hear of), symmetric multiprocessing is the smallest, least disruptive step that software developers could be asked to take. We still get a nice simple machine model that thankfully reflects very little of the complexity of the underlying hardware. The only thing that has gotten worse is that instead of getting unconditional, dramatic performance improvements for no effort at all, we get dramatic performance improvements conditional on our ability to use cores efficiently. And heck, single-threaded programs might keep getting faster anyway.
P.S. I admit I don't know anything about Intel's introduction of segmentation, but reading what Wikipedia says, it seems like the key selling point of segmentation was the ease of porting old software. Requiring users to move from straightforward 16-bit addressing to straightforward 32-bit addressing would have kept both hardware and software simpler than using Intel's segmentation idea, but segmentation made it easier to port old software, so it was a success. It sounds more like a present vs. future tradeoff than a software vs. hardware tradeoff.
Considering that hardware designers have been leaning over backwards for years to help software programmers stick with one fairly easy programming model, I wouldn't be too quick to blame the hardware industry. They know which side their bread is buttered on. The hardware company that requires the least adaptation from software developers has the advantage, just like the software company that requires the least change and adaptation from users always has the advantage.
This is Slashdot. People argue against something so they'll never have to try it :-) I've never had a choice; my first professional job was at a Java shop that used multithreaded servers, and at my current gig one of my ongoing tasks is to add multithreading to single-threaded C++ apps so that our customers get as much power as possible out of their multi-CPU workstations.
What I've learned is that there's basically a one-time cost when you redesign and refactor a single-threaded app to a multi-threaded app. Multi-threaded design is harder, but the resulting designs are often simpler, since single-threading forces you to specify many arbitrary choices about sequencing. Then when you consider resource utilization, it turns out those arbitrary choices aren't arbitrary after all, so you end up interleaving work in weird ways to keep resource utilization up. With multi-threaded apps, I just leave it up to the thread scheduler, which does a pretty damn good job.
On the programs I've worked on, the advantages of cleaner design (no need to specify serialization where it doesn't exist, no spaghetti flow control) have cancelled out the disadvantages of more complicated implementation (ensuring protection for every shared resource.) The cost of ensuring protection is mitigated by the fact that most of the resource-protection code in my programs is contained in a few shared data structure implementations that I reuse in all my projects.
Of course I write lots of single-threaded programs, too. Most of my programs start out single-threaded, with an eye toward future multithreading. Single threading has a decided advantage for simple programs; I just believe that advantage disappears when programs get large and complicated.