And you also need to realize that NASA needs to be extra cautious. A repeat of the Columbia disaster would raise some serious concerns about their credibility and may be detrimental to the future of space exploration in general.
Which is why, even after having collected and analyzed all the data that they do now in response to the Columbia disaster which even from the beginning seemed to show that this was a fairly minor issue, they still spent five hours discussing it before finally deciding that they should go with what that data said.
They are being extra cautious, okay? They don't need you to remind them that another disaster could ruin our space program. It's why they've taken so many steps to try to prevent it, steps they never took before Columbia and hence should be fairly obvious indicators of their caution.
Could they be wrong, and could we lose Endeavor? Yes, like you say reality can always throw a curve ball. But as best can be determined there won't be a problem, and whatever that curve ball may be they have no way of knowing. So for them to be extra cautious, as in more cautious than they already are, the only thing they could do would be to go out and fix the tiles before returning.
But a space walk is far from safe. Especially one that's never been done before. If you're being cautious instead of hysterical then you need to consider the dangers inherent to your solution in comparison to the problem you are fixing.
NASA looked at the danger both measured and hypothetical and decided the space walk was too risky. Given the amount of scrutiny they are under, the pressure to fix the problem so everyone could calm down, this means they see the dangers of the damaged tile as minimal, and the dangers of the space walk to be quite significant.
I don't know what more you want from them. Would you still have them conduct the repairs in orbit, knowing how dangerous that will be, just to satisfy your fear of the unknown?
Yeah, and about half of those are people who didn't even read the summary correctly.
For example, you posted about how "organic" is distinct from "alive" as though the summary did not make this distinction. However the summary did make that distinction, as the very part you quoted shows.
He basically already made that movie, it was called Ghosts of Mars. The "Ghosts" appeared as a cloud of red dust when they escape a possessed human who had been killed.
Under the theory that all movies are actually documentaries -- 1) we're all screwed because every time you kill someone the Dust has taken over, it just moves on to the next person, apparently getting us to commit self-genocide and 2) it will still be very stupid and boring when it happens.
"usually associated with organic compounds and with life"
So you make a post about the distinction between "organic" and "life", motivated by a phrase in the summary which... made a distinction between "organic" and "life".
Eh, okay. At least someone thought it was informative, so perhaps someone was informed.
The people who really suffer from this are Intel and AMD. They're the ones that have to design the nasty decoders for x86. They obviously find the advantages of decades of expertise in x86 ISA throughout the industry is worth the effort.
This is true, they're the ones who have to make it actually work. I think who it -really- hurts is anyone who isn't Intel or AMD trying to make an x86 chip. Unfortunately there's a lot of x86 behavior that isn't actually documented -anywhere- except inside the heads of Intel and AMD engineers and the HDL they write. Whereas a couple grad students could code up a fully Alpha-compatible cpu in a few weeks (it wouldn't be fast, but it would work). It creates a higher barrier to entry into the x86 market, and to me that's unfortunate. AMD and Intel obviously have a handle on the ISA.
And in reality a lot of the complexity of x86 decoding has been moved into the microcode engine so that the actual hardware decoders are pretty efficient.
Well, in so much as getting every operation that has to occur when you do something like a protected mode code segment load, sure the microcode deals with that. But the really hard part of x86 decode is dealing with variable-length instructions. To have a super-scalar architecture you need to be able to decode more than one instruction in a cycle, which means you need to know where the second instruction starts. A few ways of dealing with this include speculatively decoding the 2nd instruction assuming it starts at various points using parallel decoders (doesn't scale well at all), or saving marker bits in the instruction cache that tell you where instructions start (unavailable the first time you see an instruction so you have to use a slower method). Also fun to deal with is when an instruction crosses a cache-line boundary. And the essentially arbitrary number of prefixes that can be used.
Also, people shouldn't forget some of the advantages of x86, like variable instruction lengths. PowerPC and ARM may be easier to decode but they take up a ton more space and that causes a significant decrease in cache and memory efficiency. For example, I think the average x86 instruction is only 2 bytes (many are only 1 byte, if your program uses mostly 1 byte instructiosn you can get a LOT of performance this way). PowerPC is fixed at 4 bytes.
You aren't going to get very far using just 1 byte instructions. The average x86 instruction going by the spec may be 2 bytes, but the average x86 instruction in actual code is going to be more. If you're doing FP then you would be using SSE instructions which mostly use 3 bytes *just* for the opcode, not including register or memory arguments which could use 1-3 more bytes and potentially more if you're using any prefixes. In general I think this advantage of x86 isn't very significant. I think it would be interesting to measure the average instruction size used in actual code. Personally, I'd take fixed-width instructions any day.
Why is this nonsense still perpetuated? The instruction set is irrelevant - it's just an interface to tell the processor what to do.
Sure, now it is, since the decoding of CISC instructions into micro-ops has largely decoupled ISA from the microarchitecture, allowing many of those neat-o performance features you meantion like out-of-order execution. However in the past this wasn't the case and a lot of x86's odd behaviors that seemed like good ideas when they were made were serious performance limiters. Like a global eflags register that is only partially written by various instructions (and they always write even if the result isn't needed).
Even today, I would say that all those RISC ISAs are better than x86, simply from the standpoint that they are cleaner, easier to decode, have fewer tricky modes to deal with, fewer odd dependencies, and all the other things that make building an actual x86 chip a pain in the arse. No, in the end it makes no difference in performance. Yet, if you had it to do all over again, building the One ISA to Rule Them All without concern for software compatability, and you decided to make something that was more like x86 than Alpha, I'd slap the taste out of your mouth.
But we do have to be concerned with software compatability, and that I think was the GP's main point. All of those other ISAs failed to dominate -- even when there were actual performance implications! -- simply because they were not x86 and hence didn't run the majority of software. IA64 failed not because it was itself all that bad, but because it couldn't run x86 software well. So when AMD came out with 64-bit backward-compatible x86, everyone stopped caring about IA64. Because it wasn't x86, and AMD64 was.
So ultimately I agree with you both, and I don't think the GP was nonsense at all. It's a very valid point -- backward compatability is king, so x86 wins by default no matter what. Your point -- that x86 isn't actually hurting us anymore -- is just the silver lining on that cloud.
Yet another waste of silicon to 'accellerate' badly written software.
AND well-written software. What, you think you could write code that's just as fast without all the "hardware acceleration" being done for you, without using any instruction set extensions that have been added over the years? You are on crack.
Instead of devoting transistors to speed up the latest toy programming languages ('managed' code), why can't we just train programmers better?
And better profiling tools are contrary to this goal how exactly? And at what point do you tell your better-trained programmers that using those hardware acceleration features will make their code go faster?
Ahh..of course, because of java..don't bother learning HOW to optimized, let java do it FOR you...
Or let your C compiler do it for you. Whichever. There's a matter of degree, to be sure, but even still you're most likely wasting your time "optimizing" individual lines of C code since the compiler can probably do a better job and that's been the case for quite a while. The thing that will get you the most bang for buck is the same in C as it is in Java -- optimize your algorithms. Java can't do that for you, and neither can your C compiler.
Last Halloween I saw a setup with an electric guitar used to modulate (in this case turn on and off rapidly) a Tesla Coil, with the result that the bolts of electricity flying off the coil didn't just match the music, they were the music. It had a very harsh square-wave sound, but it fit perfectly with the visual display and by combining two of the coolest uses for electricity ever it reached new heights of awesome.
They could probably do the same with this by changing the rate of the pulses. Though they'd have to get higher than 1000 bursts per second unless they're just using it for the bass track.
If true, maybe they should enable a way for the processer to use that RISC code without the conversion.
I don't think that's a good idea. The internal micro-ops are machine-dependent, and they will change as the microarchitecture changes. By designing the micro-ops specific to the architecture, they can try to make the x86 instruction translate into an optimal sequence of micro-ops. As hardware functionality changes, existing x86 instructions can have the underlying ops changed to suit without you having to re-code or even re-compile your program.
For example: Barcelona is introducing 128-bit wide floating point units for SSE instructions. The previous ones were 64-bits wide, so it would take two operations (and most likely two separate micro-ops) to perform a 128 bit SSE add instruction. Whereas now it will only take one op, and the same x86 instruction can take advantage of that fact without having to know what architecture it is running on. Another example is divides, which on a machine with a hardware divide unit would be only a few instructions, but on a different machine would require a lengthy microcode routine. Your code doesn't have to know; it just runs faster on the code with the hardware DIV.
Not that you can't optimize your x86 code for particular architectures, or that there aren't x86 codes that run on one machine and not another -- though you can check whether the machine can run the code, and you aren't having the entire instruction set change out from underneath you. I'm just saying that only exposing one side of the CISC->RISC conversion gives the chip designers a lot of leeway and you probably don't want to give that up.
I believe the 486 was the last CPU to run x86 instructions natively.
Close, it was the original Pentium. The Pentium Pro -- which despite the name which just made it sound like a minor improvement to the Pentium for business/servers was actually a completely new architecture -- is where they introduced the CISC->RISC conversion. This was in part to make it feasible to have out-of-order execution which many said CISC processors would never have. Turns out they were both right and wrong.
So let's stick with x86 for now, since the gains you foresee are either non-existent or tiny and are never, ever going to outweigh the drawbacks.
As much as I hate x86 from an aesthetic point of view, I must agree with you here.
And you want them to try *again*? As far as I'm concerned the most amazing achievement of IA64 was that they got to start over from scratch, and ended up with an ISA with a manual even bigger than the IA32 manual! Going to prove that the only thing worse than an ISA developed through 20 years of engineering hackery is one developed by committee.
I don't have a source for this, but when I was at Space Camp I was told it was Shepard who said this - and c'mon, Space Camp has to be on top of this, right?
Did they send you a bill for breaking their space station?
Microsoft is out to terminate Adobe Flash, gain control of the cross-platform AJAX developers, stop Firefox growth, and force Google to work under Microsofts terms.
Negative. Microsoft is a publicly traded and owned company. Their one and only goal is to make money for their shareholders. Everything they do is subordinate to (and supportive of) that goal.
Huh, yes, MS is out to make money, thanks for the pointless observation. If you understood anything about Microsoft's methods for making money then the word "Negative" in your reply would have instead been something more akin to "Yes you are absolutely right that is clearly what they are doing".
I could see a use for a "space truck" the size of Endeavour, even after the shuttle program does out the door.
Oh sure, but you know how it is. As soon as your buddies find out you have a space truck they'll want you to help move their space sofas into their new space condo.
Though lately it's been suffering from the same thing that made SNL unwatchable for years: "the joke the skit is based around is funny for thirty seconds but the skit is seven minutes long" syndrome.
Well yes, he could no longer play the cmputer as if it were a computer, but instead had to play it as a completely unknown opponent with no prior game history. That's a steep challenge considering his opponent had been trained extensively on his complete game history.
Not no game history, only the history of the games they had played up to that point. Of course it was a challenge, but nevertheless he did it and I'm suggesting that this is part of why there were no more "oh my gosh where did that move come from" moments because he didn't allow them.
I'm certainly not denying that the cards were stacked against him in multiple ways. That's not what this is about, who is better or what have you.
I think the part that threw him was that it was a move you wouldn't expect from this computer either, based on its previous play so far anyway. Even with deep decision trees computers have horizons of how far they can look ahead and very limited understanding (intuition really) of board position. This is generally how the great players beat even very good computers -- by using that horizon against them. Given the deep blue had shown all the signs of playing exactly like a computer with a limited horizon right up until that fateful move, it did seem a little incongruous.
Right, based on the limited game history up to that point he didn't expect it -- this was game 2, Deep Blue's first victory, was it not? Or was it game 1? That there is a limited horizon is elementary. It's the distance to that horizon that matters, and it's largely a function of compute power and Deep Blue brought far more compute power than any machine Kasparov had faced. If he assumed that given the existence of a horizon that any trick designed to exploit that horizon would work, then that was his mistake because it's a bad assumption. It is said that Kasparov himself is so good at the game in part because of his ability to look farther ahead than most are able -- obviously in an intuitive fashion rather than raw analytical, but not entirely different either.
So if he used a trick that depended on the limited view of the future of the computer, but this computer had a more expansive view than he assumed, then it would make perfect sense that the trick failed. And then he adapted his play style to this reality and did not let himself be caught off guard by his notion of how limited a computer must be again. That he suspected that he was adapting to human coaches behind the scenes wouldn't have made any difference in this regard.
Someone get the 'itsatrap' tag in here quick! We know it's impossible for Microsoft to directly support a competitor in any way./sarcasm Seriously, if they actually make good on this and continue to support the Mono version, more power to them.
You should have used/naive, not/sarcasm. It's not impossible for Microsoft to directly support a competitor without any tricks, it's merely without precedent in their entire history. Seriously, it is completely normal for Microsoft to appear to directly support a competitor for a while, to support cross-platform interoperability at first, and then once everyone is complacent -- and more importantly using Microsoft software -- they pull the rug out from under them.
It most certainly is a trap, like every Microsoft move at being "open". Oh developers are concerned Silverlight will be locked to the Windows platform? Oh, don't worry, we're porting it to Linux! So the still-mostly-Windows development community starts using Silverlight, thereby getting locked into to using it, and then suddenly you find that the non-Windows versions are lagging behind in their patch level, and new features are coming in that require some Windows-only feature, and suddenly you're once again locked into Windows.
But yeah, maybe I'm wrong, and this is completely different than every other trick MS has pulled. I hear Bill Gates was born again last week.
I thought part of the reason future games didn't have such moments was that Kasparov had adjusted his play. This is the impression I got from what he said, and given that he's a brilliant Grand Master I don't doubt that he was able to adapt and provide fewer chances for the computer to get the jump on him. Though I do remember him maintaining that he believed IBM was coaching the computer.
But in my humble opinion, given a computer of such power able to look so deep into the decision trees, I'm not personally surprised that it found a move you wouldn't expect of any other computer. Surely at some number of moves into the future the computer can see the trap being sprung, and its heuristic would decide that was a bad choice. I think it's possible that this as much as anything is what caught Kasparov off-guard, the notion that given enough power a computer -could- get past the traditional limitations of algorithmic chess.
They could very easily start up the infringement train and force everyone to use SuSE linux as not to infringe on their IP. They could even sell indemnification licenses, at, oh, say $699 a pop.
And... just like with SCO's retarded license, nobody with a brain would pay for it. And if they tried to enforce it against, say, IBM, then they would find themselves being beaten around by the Nazgul just like SCO was. And subject to many of the same counter-claims that SCO is.
Unlike the SCO case, Novell actually has the resources to put a stranglehold on the community. BUT THEY DIDN'T.
They DIDN'T because they CAN'T, because JUST like in the SCO case, there IS NO INFRINGING CODE IN LINUX. It's not about resources, as SCO had plenty thanks to MS. It's just that they DIDN'T HAVE A CASE. The ruling that SCO doesn't own UNIX copyrights has brought about a quicker end, but that doesn't change the fact that up to this point SCO hasn't produced a single piece of actual evidence of infringement, and Novell, were they to try, couldn't either because IT ISN'T THERE.
So yes, let's all congratulate Novell for not going on a retarded suicide mission of a pointless lawsuit. Having an actual business that makes money, this would be stupid, and Novell isn't that stupid. I commend them for being in touch with reality.
I mean, I don't really have anything bad to say about Novell. But when they say "Oh, we're not going to sue Linux users for infringing UNIX because we're nice guys" you need to look through the transparent PR and translate that as "because we would lose horribly".
7100 ft^2? That's practically an apartment for a guy with that kind of scratch!
I agree with your sentiment completely (Al "don't worry I buy carbon credits when I take my private jet" Gore being a good example, especially because I approve of his work), but in this case I think Woz is actually doing a better job of "walking the walk" than most such people. For whatever that's worth.
Slashdot Mirror
And you also need to realize that NASA needs to be extra cautious. A repeat of the Columbia disaster would raise some serious concerns about their credibility and may be detrimental to the future of space exploration in general.
Which is why, even after having collected and analyzed all the data that they do now in response to the Columbia disaster which even from the beginning seemed to show that this was a fairly minor issue, they still spent five hours discussing it before finally deciding that they should go with what that data said.
They are being extra cautious, okay? They don't need you to remind them that another disaster could ruin our space program. It's why they've taken so many steps to try to prevent it, steps they never took before Columbia and hence should be fairly obvious indicators of their caution.
Could they be wrong, and could we lose Endeavor? Yes, like you say reality can always throw a curve ball. But as best can be determined there won't be a problem, and whatever that curve ball may be they have no way of knowing. So for them to be extra cautious, as in more cautious than they already are, the only thing they could do would be to go out and fix the tiles before returning.
But a space walk is far from safe. Especially one that's never been done before. If you're being cautious instead of hysterical then you need to consider the dangers inherent to your solution in comparison to the problem you are fixing.
NASA looked at the danger both measured and hypothetical and decided the space walk was too risky. Given the amount of scrutiny they are under, the pressure to fix the problem so everyone could calm down, this means they see the dangers of the damaged tile as minimal, and the dangers of the space walk to be quite significant.
I don't know what more you want from them. Would you still have them conduct the repairs in orbit, knowing how dangerous that will be, just to satisfy your fear of the unknown?
And I shouldn't make fun of stupid karma whores... why?
Yeah, and about half of those are people who didn't even read the summary correctly.
For example, you posted about how "organic" is distinct from "alive" as though the summary did not make this distinction. However the summary did make that distinction, as the very part you quoted shows.
He basically already made that movie, it was called Ghosts of Mars. The "Ghosts" appeared as a cloud of red dust when they escape a possessed human who had been killed.
Under the theory that all movies are actually documentaries -- 1) we're all screwed because every time you kill someone the Dust has taken over, it just moves on to the next person, apparently getting us to commit self-genocide and 2) it will still be very stupid and boring when it happens.
"usually associated with organic compounds and with life"
So you make a post about the distinction between "organic" and "life", motivated by a phrase in the summary which... made a distinction between "organic" and "life".
Eh, okay. At least someone thought it was informative, so perhaps someone was informed.
The people who really suffer from this are Intel and AMD. They're the ones that have to design the nasty decoders for x86. They obviously find the advantages of decades of expertise in x86 ISA throughout the industry is worth the effort.
This is true, they're the ones who have to make it actually work. I think who it -really- hurts is anyone who isn't Intel or AMD trying to make an x86 chip. Unfortunately there's a lot of x86 behavior that isn't actually documented -anywhere- except inside the heads of Intel and AMD engineers and the HDL they write. Whereas a couple grad students could code up a fully Alpha-compatible cpu in a few weeks (it wouldn't be fast, but it would work). It creates a higher barrier to entry into the x86 market, and to me that's unfortunate. AMD and Intel obviously have a handle on the ISA.
And in reality a lot of the complexity of x86 decoding has been moved into the microcode engine so that the actual hardware decoders are pretty efficient.
Well, in so much as getting every operation that has to occur when you do something like a protected mode code segment load, sure the microcode deals with that. But the really hard part of x86 decode is dealing with variable-length instructions. To have a super-scalar architecture you need to be able to decode more than one instruction in a cycle, which means you need to know where the second instruction starts. A few ways of dealing with this include speculatively decoding the 2nd instruction assuming it starts at various points using parallel decoders (doesn't scale well at all), or saving marker bits in the instruction cache that tell you where instructions start (unavailable the first time you see an instruction so you have to use a slower method). Also fun to deal with is when an instruction crosses a cache-line boundary. And the essentially arbitrary number of prefixes that can be used.
Also, people shouldn't forget some of the advantages of x86, like variable instruction lengths. PowerPC and ARM may be easier to decode but they take up a ton more space and that causes a significant decrease in cache and memory efficiency. For example, I think the average x86 instruction is only 2 bytes (many are only 1 byte, if your program uses mostly 1 byte instructiosn you can get a LOT of performance this way). PowerPC is fixed at 4 bytes.
You aren't going to get very far using just 1 byte instructions. The average x86 instruction going by the spec may be 2 bytes, but the average x86 instruction in actual code is going to be more. If you're doing FP then you would be using SSE instructions which mostly use 3 bytes *just* for the opcode, not including register or memory arguments which could use 1-3 more bytes and potentially more if you're using any prefixes. In general I think this advantage of x86 isn't very significant. I think it would be interesting to measure the average instruction size used in actual code. Personally, I'd take fixed-width instructions any day.
Why is this nonsense still perpetuated? The instruction set is irrelevant - it's just an interface to tell the processor what to do.
Sure, now it is, since the decoding of CISC instructions into micro-ops has largely decoupled ISA from the microarchitecture, allowing many of those neat-o performance features you meantion like out-of-order execution. However in the past this wasn't the case and a lot of x86's odd behaviors that seemed like good ideas when they were made were serious performance limiters. Like a global eflags register that is only partially written by various instructions (and they always write even if the result isn't needed).
Even today, I would say that all those RISC ISAs are better than x86, simply from the standpoint that they are cleaner, easier to decode, have fewer tricky modes to deal with, fewer odd dependencies, and all the other things that make building an actual x86 chip a pain in the arse. No, in the end it makes no difference in performance. Yet, if you had it to do all over again, building the One ISA to Rule Them All without concern for software compatability, and you decided to make something that was more like x86 than Alpha, I'd slap the taste out of your mouth.
But we do have to be concerned with software compatability, and that I think was the GP's main point. All of those other ISAs failed to dominate -- even when there were actual performance implications! -- simply because they were not x86 and hence didn't run the majority of software. IA64 failed not because it was itself all that bad, but because it couldn't run x86 software well. So when AMD came out with 64-bit backward-compatible x86, everyone stopped caring about IA64. Because it wasn't x86, and AMD64 was.
So ultimately I agree with you both, and I don't think the GP was nonsense at all. It's a very valid point -- backward compatability is king, so x86 wins by default no matter what. Your point -- that x86 isn't actually hurting us anymore -- is just the silver lining on that cloud.
They'd have been even worse off even sooner than what actually happened. Any other questions?
Yet another waste of silicon to 'accellerate' badly written software.
AND well-written software. What, you think you could write code that's just as fast without all the "hardware acceleration" being done for you, without using any instruction set extensions that have been added over the years? You are on crack.
Instead of devoting transistors to speed up the latest toy programming languages ('managed' code), why can't we just train programmers better?
And better profiling tools are contrary to this goal how exactly? And at what point do you tell your better-trained programmers that using those hardware acceleration features will make their code go faster?
Ahh..of course, because of java..don't bother learning HOW to optimized, let java do it FOR you...
Or let your C compiler do it for you. Whichever. There's a matter of degree, to be sure, but even still you're most likely wasting your time "optimizing" individual lines of C code since the compiler can probably do a better job and that's been the case for quite a while. The thing that will get you the most bang for buck is the same in C as it is in Java -- optimize your algorithms. Java can't do that for you, and neither can your C compiler.
Last Halloween I saw a setup with an electric guitar used to modulate (in this case turn on and off rapidly) a Tesla Coil, with the result that the bolts of electricity flying off the coil didn't just match the music, they were the music. It had a very harsh square-wave sound, but it fit perfectly with the visual display and by combining two of the coolest uses for electricity ever it reached new heights of awesome.
They could probably do the same with this by changing the rate of the pulses. Though they'd have to get higher than 1000 bursts per second unless they're just using it for the bass track.
If true, maybe they should enable a way for the processer to use that RISC code without the conversion.
I don't think that's a good idea. The internal micro-ops are machine-dependent, and they will change as the microarchitecture changes. By designing the micro-ops specific to the architecture, they can try to make the x86 instruction translate into an optimal sequence of micro-ops. As hardware functionality changes, existing x86 instructions can have the underlying ops changed to suit without you having to re-code or even re-compile your program.
For example: Barcelona is introducing 128-bit wide floating point units for SSE instructions. The previous ones were 64-bits wide, so it would take two operations (and most likely two separate micro-ops) to perform a 128 bit SSE add instruction. Whereas now it will only take one op, and the same x86 instruction can take advantage of that fact without having to know what architecture it is running on. Another example is divides, which on a machine with a hardware divide unit would be only a few instructions, but on a different machine would require a lengthy microcode routine. Your code doesn't have to know; it just runs faster on the code with the hardware DIV.
Not that you can't optimize your x86 code for particular architectures, or that there aren't x86 codes that run on one machine and not another -- though you can check whether the machine can run the code, and you aren't having the entire instruction set change out from underneath you. I'm just saying that only exposing one side of the CISC->RISC conversion gives the chip designers a lot of leeway and you probably don't want to give that up.
I believe the 486 was the last CPU to run x86 instructions natively.
Close, it was the original Pentium. The Pentium Pro -- which despite the name which just made it sound like a minor improvement to the Pentium for business/servers was actually a completely new architecture -- is where they introduced the CISC->RISC conversion. This was in part to make it feasible to have out-of-order execution which many said CISC processors would never have. Turns out they were both right and wrong.
So let's stick with x86 for now, since the gains you foresee are either non-existent or tiny and are never, ever going to outweigh the drawbacks.
As much as I hate x86 from an aesthetic point of view, I must agree with you here.
Well maybe I didn't notice because compared to SNL their skits were short and punchy.
Yeah, I know, Intel tried with Itanium.
And you want them to try *again*? As far as I'm concerned the most amazing achievement of IA64 was that they got to start over from scratch, and ended up with an ISA with a manual even bigger than the IA32 manual! Going to prove that the only thing worse than an ISA developed through 20 years of engineering hackery is one developed by committee.
I don't have a source for this, but when I was at Space Camp I was told it was Shepard who said this - and c'mon, Space Camp has to be on top of this, right?
Did they send you a bill for breaking their space station?
I know, lamest reference ever.
Negative. Microsoft is a publicly traded and owned company. Their one and only goal is to make money for their shareholders. Everything they do is subordinate to (and supportive of) that goal.
Huh, yes, MS is out to make money, thanks for the pointless observation. If you understood anything about Microsoft's methods for making money then the word "Negative" in your reply would have instead been something more akin to "Yes you are absolutely right that is clearly what they are doing".
I could see a use for a "space truck" the size of Endeavour, even after the shuttle program does out the door.
Oh sure, but you know how it is. As soon as your buddies find out you have a space truck they'll want you to help move their space sofas into their new space condo.
Since it sucked less than SNL.
Though lately it's been suffering from the same thing that made SNL unwatchable for years: "the joke the skit is based around is funny for thirty seconds but the skit is seven minutes long" syndrome.
Right, so only one poster thought Novell was doing us all a big favor by not suing.
Well yes, he could no longer play the cmputer as if it were a computer, but instead had to play it as a completely unknown opponent with no prior game history. That's a steep challenge considering his opponent had been trained extensively on his complete game history.
Not no game history, only the history of the games they had played up to that point. Of course it was a challenge, but nevertheless he did it and I'm suggesting that this is part of why there were no more "oh my gosh where did that move come from" moments because he didn't allow them.
I'm certainly not denying that the cards were stacked against him in multiple ways. That's not what this is about, who is better or what have you.
I think the part that threw him was that it was a move you wouldn't expect from this computer either, based on its previous play so far anyway. Even with deep decision trees computers have horizons of how far they can look ahead and very limited understanding (intuition really) of board position. This is generally how the great players beat even very good computers -- by using that horizon against them. Given the deep blue had shown all the signs of playing exactly like a computer with a limited horizon right up until that fateful move, it did seem a little incongruous.
Right, based on the limited game history up to that point he didn't expect it -- this was game 2, Deep Blue's first victory, was it not? Or was it game 1? That there is a limited horizon is elementary. It's the distance to that horizon that matters, and it's largely a function of compute power and Deep Blue brought far more compute power than any machine Kasparov had faced. If he assumed that given the existence of a horizon that any trick designed to exploit that horizon would work, then that was his mistake because it's a bad assumption. It is said that Kasparov himself is so good at the game in part because of his ability to look farther ahead than most are able -- obviously in an intuitive fashion rather than raw analytical, but not entirely different either.
So if he used a trick that depended on the limited view of the future of the computer, but this computer had a more expansive view than he assumed, then it would make perfect sense that the trick failed. And then he adapted his play style to this reality and did not let himself be caught off guard by his notion of how limited a computer must be again. That he suspected that he was adapting to human coaches behind the scenes wouldn't have made any difference in this regard.
Someone get the 'itsatrap' tag in here quick! We know it's impossible for Microsoft to directly support a competitor in any way. /sarcasm
/naive, not /sarcasm. It's not impossible for Microsoft to directly support a competitor without any tricks, it's merely without precedent in their entire history. Seriously, it is completely normal for Microsoft to appear to directly support a competitor for a while, to support cross-platform interoperability at first, and then once everyone is complacent -- and more importantly using Microsoft software -- they pull the rug out from under them.
Seriously, if they actually make good on this and continue to support the Mono version, more power to them.
You should have used
It most certainly is a trap, like every Microsoft move at being "open". Oh developers are concerned Silverlight will be locked to the Windows platform? Oh, don't worry, we're porting it to Linux! So the still-mostly-Windows development community starts using Silverlight, thereby getting locked into to using it, and then suddenly you find that the non-Windows versions are lagging behind in their patch level, and new features are coming in that require some Windows-only feature, and suddenly you're once again locked into Windows.
But yeah, maybe I'm wrong, and this is completely different than every other trick MS has pulled. I hear Bill Gates was born again last week.
I hear Deep Blue beat a Russian Grand Master at Global Thermonuclear War.
I thought part of the reason future games didn't have such moments was that Kasparov had adjusted his play. This is the impression I got from what he said, and given that he's a brilliant Grand Master I don't doubt that he was able to adapt and provide fewer chances for the computer to get the jump on him. Though I do remember him maintaining that he believed IBM was coaching the computer.
But in my humble opinion, given a computer of such power able to look so deep into the decision trees, I'm not personally surprised that it found a move you wouldn't expect of any other computer. Surely at some number of moves into the future the computer can see the trap being sprung, and its heuristic would decide that was a bad choice. I think it's possible that this as much as anything is what caught Kasparov off-guard, the notion that given enough power a computer -could- get past the traditional limitations of algorithmic chess.
They could very easily start up the infringement train and force everyone to use SuSE linux as not to infringe on their IP. They could even sell indemnification licenses, at, oh, say $699 a pop.
And... just like with SCO's retarded license, nobody with a brain would pay for it. And if they tried to enforce it against, say, IBM, then they would find themselves being beaten around by the Nazgul just like SCO was. And subject to many of the same counter-claims that SCO is.
Unlike the SCO case, Novell actually has the resources to put a stranglehold on the community. BUT THEY DIDN'T.
They DIDN'T because they CAN'T, because JUST like in the SCO case, there IS NO INFRINGING CODE IN LINUX. It's not about resources, as SCO had plenty thanks to MS. It's just that they DIDN'T HAVE A CASE. The ruling that SCO doesn't own UNIX copyrights has brought about a quicker end, but that doesn't change the fact that up to this point SCO hasn't produced a single piece of actual evidence of infringement, and Novell, were they to try, couldn't either because IT ISN'T THERE.
So yes, let's all congratulate Novell for not going on a retarded suicide mission of a pointless lawsuit. Having an actual business that makes money, this would be stupid, and Novell isn't that stupid. I commend them for being in touch with reality.
I mean, I don't really have anything bad to say about Novell. But when they say "Oh, we're not going to sue Linux users for infringing UNIX because we're nice guys" you need to look through the transparent PR and translate that as "because we would lose horribly".
7100 ft^2? That's practically an apartment for a guy with that kind of scratch!
I agree with your sentiment completely (Al "don't worry I buy carbon credits when I take my private jet" Gore being a good example, especially because I approve of his work), but in this case I think Woz is actually doing a better job of "walking the walk" than most such people. For whatever that's worth.