Slashdot Mirror
BSOD Makes Appearance at Olympic Opening Ceremonies
Whiteox writes "A BSOD was projected onto the roof of the National Stadium during the grand finale to the four-hour spectacular at the Olympics. Lenovo chairman Yang Yuanqing chose to go with XP instead of Vista because of the complexity of the IT functions at the Games. His comment on Vista? 'If it's not stable, it could have some problems,' he said. Evidently Bill Gates attended the opening ceremony, so he must have witnessed it."
They paid 40 billion for that ceremony. I can't see this improving their opinion of Microsoft much.
A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
10 points to the first person to can say what went wrong :U
Knows everything about nothing and nothing about everything.
We're living in the Matrix! And the Matrix runs Windows!
No wonder my life is a pile of shit. :)
"The fight for freedom has only just begun." - Geert Wilders
"All computers crash - I've made Linux, BSD, OSX, and Solaris machines kernel panic. Hell, I've witnessed a newer zSeries mainframe crash."
And you seem so proud of that. The goal is to make the systems function, not crash.
There are no loopholes. It's either legal or it's not.
He probably cackled maniacally and shouted over the top of the fireworks, "I made that screen blue! Bill Gates owns the Olympics! Maybe if you dirty pirates had bought a legitimate copy it would have worked better!"
You are using English. Please learn the difference between loose and lose; they're, there, and their; your and you're.
I just hope someday I'm not driving down the street and see a "lost connection to server" message flashing instead of The Reality!
That would totally freak me out.
But so few fail in such a spectacular fashion. I have never seen a kernel panic delivered in anything other than terminal font on a black and white screen. The BSOD is called the BSOD because MS, in their infinite wisdom, opened themselves up to such a joke by deciding to deliver critical system messages with a "calming" blue background and white text. And then doing so very very frequently in the early days.
Honestly, they should just make it a black screen with some fireworks and a "Congratulations, You Crashed Windows Again!". You know, make it a more positive experience for the user.
The only change I can believe in is what I find in my couch cushions.
Jeez. MS apologists always trot out that one. Making bad engineering acceptable will probably be Bill Gates' largest "contribution" to society.
In fairness to software engineering, if the "bad" hardware driver can crash the system, then the system is not ready for production and has more than a few show-stopping (no pun intended) bugs. Take a look at basic kernel or micro-kernel design principles and stop spreading the view that catastrophically bad design is acceptable.
Linux puts most drivers in the kernel and a bad driver there can cause a panic, bringing the system down.
Most of the BSDs, AFAIK, have some drivers in the kernel and others in userland processes.
I'm not sure how it's architected in Mac OS X, but I've certainly seen kernel panics on my Mac Mini.
There may be an embedded OS which is less susceptible to being killed by a poor driver, but for something like this you probably wouldn't bother with an embedded OS because there's so much more in the way of off-the-shelf software available to do the job for Windows and Linux.
Not if you are in QA/testing...
In fairness to software engineering, if the "bad" hardware driver can crash the system, then the system is not ready for production and has more than a few show-stopping (no pun intended) bugs. Take a look at basic kernel or micro-kernel design principles and stop spreading the view that catastrophically bad design is acceptable.
I'm sorry, do you know of an operating system where talking to hardware cannot cause a panic? Even microkernels such as Mach are prone to these problems. ANY time you touch hardware there can be a problem if it's coded wrong. Even microkernels have to allow DMA for certain hardware, and bad DMA can bring down a whole system without even trying. There's a basic design flaw in how normal computers operate that requires this sort of behavior from kernels, which leads to bad drivers affecting them. If you can name one system ready for general purpose for which this isn't true I would love to hear about it.
If i had one dollar for every brain you dont have, i would have $1.
I believe most of the projections were handled by HighEnd Systems DL2s and DL3s. Essentially a projector on a moving yoke, with a few extra features. Each DL2 or DL3 has its own built-in media server running Win XP Embedded.
Even if the built-in media server fell over (which is what this looked like), there is still DMX control over the unit. Pan, tilt, focus and more importantly beam blanking and projector power are still controllable. It would have been easy to shut the faulty unit down and still carry on with the show (and yes, I do work with this kind of gear).
On this scale of event, they would have had multiple operators dedicated to watching over particular areas in case of such a fault. It looks like someone wasn't paying attention.
As somebody who has written a bad device driver for Mac OSX I can confirm that a bad driver can and frequently has crashed my OS X kernel.
OS X is based on a microkernel, but in practice it is as monolithic as Linux or BSD.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
You were doing something wrong with your Windows box then. I have almost never (either with my own machines or at work) seen a BSOD that wasn't caused by faulty hardware. It happens, but it's something that happens maybe once every couple of years per computer.
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
Good point, Windows should identify the offending driver, read it's manufacturer info, then shame the creator on the BSoD.
"A fatal exception has occurred because CheapHardware's Crappy802.11g device driver was written by mildly retarded gibbons."
http://www.mhall119.com
There's a basic design flaw in how normal computers operate that requires this sort of behavior from kernels, which leads to bad drivers affecting them. If you can name one system ready for general purpose for which this isn't true I would love to hear about it.
GNU Hurd
Just disrupt the deflector shield with a tachyon burst.
All computers crash - I've made Linux, BSD, OSX, and Solaris machines kernel panic. Hell, I've witnessed a newer zSeries mainframe crash.
You are not invited into my house anymore.
It is dangerous to be right when the government is wrong.
and now, with Vista, display drivers are back to being in user-mode:
At a technical level, WDDM display drivers have two components, a kernel mode driver (KMD) that is very streamlined, and a user-mode driver that does most of the intense computations. With this model, most of the code is moved out of kernel mode. That is, the kernel mode piece is now solely responsible for lower-level functionality and the user mode piece takes on heavier functionality such as facilitating the translation from higher-level API constructs to direct GPU commands while maintaining application compatibility. This greatly reduces the chance of a fatal blue screen and most graphics driver-related problems result in at worst one application being affected.
This has actually been proposed a number of times (without the personal attacks), but rejected for two reasons:
The latter problem is more important. Problem is, kernel mode code can do *anything*, including write to other modules' memory space. So if a driver "baddisplay.sys" accidentally wrote to an uninitialized pointer that just happened to point to the memory space of "goodprinter.sys", but didn't fail as a result (remember, no real memory protection in kernel mode), and "goodprinter.sys" later reads the screwed up memory and fails, it will look like a problem in "goodprinter.sys", even though "goodprinter.sys" behaved correctly (dying when faced with an irrecoverable error).
This is why the "Problem Reports and Solutions" only provides information after conferring with MS. When it gives you an answer, it's because someone at MS took a look at your crash dump (or someone else's dump which exhibited the same problem), figured out the actual cause of the crash, and linked the crash and solution together. If it blamed the module automatically, you'd spend time harassing a perfectly innocent printer manufacturer, and MS would need to hire even more lawyers.
(Disclaimer: Former MS employee, this is only what I was told)
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
...after all, if it had just done its job flawlessly there'd be no way for the crowd to know it was a microsoft product.