There's a semantic debate here about what you call the bright cloud of liquid oxygen and hydrogen that appears when a ginourmous fuel tank disintegrates at Mach 2. The dinstinction I think is that the tank didn't pop like a firecracker. It got a hole burned in the side, which caused a change in aerodynamics, which caused the whole thing to tear apart, and puff, you've got a big expanding cloud of gas with some random shuttle parts in it.
One interesting tear-down of an Intel chip (Core Duo, I think) suggested that Intel is not scaling geometries as agressively as would be suggested by the roadmap nodes, but gaining more performance from other process innovations such as strained silicon. It may be that Intel's allowing its gates to be a few nanometers longer than the should to reach the next node ahead of the pack.
I tend to agree. If Google was be the usurper, why can't it be usurped itself?
I wonder, though, if it's now possible to achieve the step-function improvement in relevancy that Google achieved. And I think that this time around, the giants won't be sleeping-- They'll buy the upstarts or copy them.
Chip bugs often are due to the intersection of the domains that the "chip simulations" you mention. You get static timing analysis, power analysis, logic verification, transient simulation at various process and applied conditions. But many of the analyses are done without true interlock with the other simulators. And you get layered levels of abstraction, and all sort of automated tools hooking all the abstracted components together...
So if you look at the list of errata, you see things like flags not getting set properly after the execution of an instruction. What could cause this? 1.) The design was logically incorrect. 2.) The design was logically correct, but the flag is never properly latched on the correct cycle for all hardware. 3.) The flag doesnt get set for slow hardware. 4.) The flag doesn't get set for hardware that has issues with supply integrity. Etc etc.
One would think that if they screwed up the implementation of a long-lived feature, it wasn't a logic error (likely to be caught by running verification) but an error caused by the analog or physical world intruding upon the digital domain. Some small amount of this may be expected-- oh crap! 1% of chips have an obscure timing issue we can't catch in test-- but if it is a true logic bug, someone screwed up.
Civilization carried on in the Islamic world, as well, although Genghis Khan certainly threw a wrench in the works in the 1200s.
Re:Don't suppose the No Nukes freaks will apologiz
on
Pluto Probe Launches
·
· Score: 1
Here's another clue for you: A modern 747, fully loaded, generates as much thrust as John Glenn's Atlas. At the time of his flight, about 4% of all Atlas launches fail. In 2006 around 3% of all Atlas launches fail.
Dude, you can't fly into space with a jet engine, even if that jet engine could be attached to an airframe that could withstand accelerating to orbital velocity.
If your scenario happened, it could be solved from earth. (Obviously not cheaply or easily, but it's not inconceivable).
How? By shooting the debris with a ground-based laser long enough to slow it down and de-orbit it.
Re:Don't suppose the No Nukes freaks will apologiz
on
Pluto Probe Launches
·
· Score: 1
No, it's stone cold truth. Any other brand of engineer that designed something that failed as much as 2% of the time would be considered an utter failure.
I work in the semiconductor industry, and we love it when chip yields get as high as 98%. In fact, we expect much more than 2% of our chips to fail to work. Not those we ship to customers, of course. There the failure rate is more like 1 in 10,000 or better.
Anyways, my point is, stop talking out of your ass. Shit happens when the task at hand is difficult, and reliable, affordable launchers are difficult. Probably because you're trying to wrap a fragile aluminum and composite cylinder around a HUGE FUCKING EXPLOSION and ride it in precisely the correct direction at really high velocity and acceleration.
My biggest complaint is when the submitter blatantly trolls in the headlines.
Or similarly when the submission is ended with a lame rhetorical question that spawns dozens of replies all explaining what a stupid question it is. If the submission isn't going to trigger good discussion without the Stupid Question, the Stupid Question isn't going to help.
The biggest challenge though, is probably insurmountable, and that's product line integration.
Interestingly enough, IBM has needed to forge that path with its own legacy systems-- the S/390 now System Z mainframes, the AS400 now i5 midrange, the RS6000 now p5 RISC machines, and the x86 xSeries servers and blades. HP also dealt with Alpha and PA-RISC architectures... and HP-UX and whatever DEC's flavor of Unix is.
If Snapple were to take a page out of IBM's book, Solaris would run on all the Sun hardware, OS/X on all the apple hardware, and Linux on everything. Truly overlapping hardware capabilities (SPARC/G5 AMD+Sun/Apple+Intel) would eventually be merged, but unique hardware capabilities (T1) would be allowed to stay in a given product line. But what is most interesting is the extent to which disparate product lines can be maintained over decades and produce steady revenue from happy customers. Don't tell them they have to change anything, and if they want a new box, it'll run everything the 15-year old doorstop chugging away in the closet did.
If Snapple were to take a page out of HP's (Carly's?) book, they'd try to to migrate everything to Itanium, and trade all the Alpha (err, Sparc) designers to Intel.
That's a naive view of community. It's a naive view of how rules and laws must evolve. You can't just set up Slashdot, get it humming along nicely, and hope never to discuss the ways in which it must change to stay relevant.
No feedback is negative feedback, so people stop submitting. Create a few radio buttons for common rejection criteria: "Duplicate." "Old." "Miscategorized." "Incoherent." "Obscure." Whatever! If you let people know what to not submit, they may actually try submitting more, rather than giving up.
Linux is great for commodity x86 servers, but on IBM's high-end hardware AIX stands head and shoulders above it.
AIX provides IBM a guaranteed path to providing a kernel enabling those high-end hardware features. Sure, everything may get into Linux eventually, but AIX milestones are a bit more predictable for IBM.
In 200 years, not ONE new technology or idealogy has surfaced that the Constitution does not completely cover. Name one. You can't.
Steamboats. If things were clearer, the commerce clause would only cover interstate tariffs, not all the other stuff now extrapolated. Wiretaps. If things were clearer, wiretaps might actually have been judged to be prohibited by the 4th.
You can't possibly claim that the constitution clearly covered all eventualities without being subject to some debate over its intent or explicit prohibitions. The framers didn't think so-- that's why there's a Supreme Court.
In other news, the military uses Goodyear tires, and Goodyear tire developers are currently mulling the ethical implications.
Grandparent quoted (or invented) completely unsubstantiated claim about Itanium taking market share.
There's a semantic debate here about what you call the bright cloud of liquid oxygen and hydrogen that appears when a ginourmous fuel tank disintegrates at Mach 2. The dinstinction I think is that the tank didn't pop like a firecracker. It got a hole burned in the side, which caused a change in aerodynamics, which caused the whole thing to tear apart, and puff, you've got a big expanding cloud of gas with some random shuttle parts in it.
They would start with simpler chips first. Maybe even flash.
One interesting tear-down of an Intel chip (Core Duo, I think) suggested that Intel is not scaling geometries as agressively as would be suggested by the roadmap nodes, but gaining more performance from other process innovations such as strained silicon. It may be that Intel's allowing its gates to be a few nanometers longer than the should to reach the next node ahead of the pack.
What did Debian find wrong with the Free Documentation License?
The reason ice cores are important is that they contain records of climate change, and climate change is big news these days.
I wonder, though, if it's now possible to achieve the step-function improvement in relevancy that Google achieved. And I think that this time around, the giants won't be sleeping-- They'll buy the upstarts or copy them.
So if you look at the list of errata, you see things like flags not getting set properly after the execution of an instruction. What could cause this? 1.) The design was logically incorrect. 2.) The design was logically correct, but the flag is never properly latched on the correct cycle for all hardware. 3.) The flag doesnt get set for slow hardware. 4.) The flag doesn't get set for hardware that has issues with supply integrity. Etc etc.
One would think that if they screwed up the implementation of a long-lived feature, it wasn't a logic error (likely to be caught by running verification) but an error caused by the analog or physical world intruding upon the digital domain. Some small amount of this may be expected-- oh crap! 1% of chips have an obscure timing issue we can't catch in test-- but if it is a true logic bug, someone screwed up.
Civilization carried on in the Islamic world, as well, although Genghis Khan certainly threw a wrench in the works in the 1200s.
If your scenario happened, it could be solved from earth. (Obviously not cheaply or easily, but it's not inconceivable). How? By shooting the debris with a ground-based laser long enough to slow it down and de-orbit it.
Anyways, my point is, stop talking out of your ass. Shit happens when the task at hand is difficult, and reliable, affordable launchers are difficult. Probably because you're trying to wrap a fragile aluminum and composite cylinder around a HUGE FUCKING EXPLOSION and ride it in precisely the correct direction at really high velocity and acceleration.
Actually, Genesis was launched after Stardust. Too bad they didn't recycle the parachute hardware's design.
If Snapple were to take a page out of IBM's book, Solaris would run on all the Sun hardware, OS/X on all the apple hardware, and Linux on everything. Truly overlapping hardware capabilities (SPARC/G5 AMD+Sun/Apple+Intel) would eventually be merged, but unique hardware capabilities (T1) would be allowed to stay in a given product line. But what is most interesting is the extent to which disparate product lines can be maintained over decades and produce steady revenue from happy customers. Don't tell them they have to change anything, and if they want a new box, it'll run everything the 15-year old doorstop chugging away in the closet did.
If Snapple were to take a page out of HP's (Carly's?) book, they'd try to to migrate everything to Itanium, and trade all the Alpha (err, Sparc) designers to Intel.
That's a naive view of community. It's a naive view of how rules and laws must evolve. You can't just set up Slashdot, get it humming along nicely, and hope never to discuss the ways in which it must change to stay relevant.
No feedback is negative feedback, so people stop submitting. Create a few radio buttons for common rejection criteria: "Duplicate." "Old." "Miscategorized." "Incoherent." "Obscure." Whatever! If you let people know what to not submit, they may actually try submitting more, rather than giving up.
AIX provides IBM a guaranteed path to providing a kernel enabling those high-end hardware features. Sure, everything may get into Linux eventually, but AIX milestones are a bit more predictable for IBM.
Not enough can be said about this one icon.
It's about Viiv and a media center mac mini, If you ask me.
Don't waste your time on the gems that end many Slashdot stories.
This seems to conclude that only Hawaii will be devastated.
You can't possibly claim that the constitution clearly covered all eventualities without being subject to some debate over its intent or explicit prohibitions. The framers didn't think so-- that's why there's a Supreme Court.