Slashdot Mirror
Computer Glitch Halts Seattle New Year's Fireworks
supersat writes "At the stroke of midnight New Year's Eve, Seattle's fireworks show ground to a halt. The source of the problem is reported to be a corrupted file that wasn't checked until the last minute. After two reboots, the fireworks had to be detonated manually. And yes ... one blog commenter, claiming to have worked on prior shows, said that the shows run on Windows."
Well, unless it was an operating system problem and not bad data or bad programming, what's the point in mentioning that other than childish bashing?
Shouldn't that be "the show doesn't 'run' on Windows" ?
Someone wasn't there click "Allow" when the dialog popped up asking "Are you sure you want to proceed with the fireworks extravaganza?"
Have a squat over at the hobo house.
Those fireworks were not vista Certified.
fuck those assholes.
Dear Taco,
I realize retirement is good but could you please come out of hiding, fix the code that shows the url a link points to in case it redirects...
And if not then please release the IPS of these clowns, I promise I won't leave any traces.
Happy new year
MP3 Search Engine
Gee, who can guess which version of Windows they were running?
Microsoft's Windows Home Server corrupts files?
Is this 2007th's last Microsoft caused disaster... ;-)
...or 2008th first ?
The best part is that it happened in Microsofts backyard.
--
Just trying to get my first "Funny" tag in 2008
Unless you know what the file was stored on, what interactions with the computer caused the halting of the program and on what basis they decided to continue manually, you are jumping to conclusions. One guy even claimed there was BSOD mentioned in the article (nowhere was it mentioned I can see). After years of supporting computers and servers, I can confidently tell you there is no way of knowing what caused the glitches from the article. A corrupted file on which several pieces of hardware are going to coordinate something as complicated as a fireworks display is probably not caused by the operating system, as the operating system has no reason to modify the file at all, and will only be reading it. More likely is a malfunctioning hard drive, possibly bad media that was used to transfer the file from one location to another, Or possibly a bad connection between the file storing device and the computer running the program. If you look up corrupted file you will see that every operating system known to man has to deal with that. There is no operating system that can magically correct the corrupted file and cause a fireworks display to run correctly. That is just silly talk.
Sorry. Couldn't resist.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
From what little we have to go on in the article, it looks like there was a problem with syncing to time code. It's been a few years since I last did time as a tech at a major theme park, but our fireworks shows looked a little like this: There was a dedicated computer running the pyro controls, one running sound playback, one controlling the lasers, one controlling lights and fog, and one controlling some miscellany such as a 70mm film projector and the large water pumps that produced a screen the movie was rear-projected onto. All of these computers could be a little buggy given that this was in the days of windows 98 and getting device drivers to play nice was always a problem. But this stuff was worked out long before showtime. The biggest problem that could show up at the last minute would be the SMPTE time code that keeps it all synced up. One intermittent cabling problem somewhere in the system could cause a computer to get bad or no time code signal at all, causing at least that one element to not playback correctly. The best way to solve this problem was to notice it ASAP, usually in the few seconds of preroll before the show starts so that you can manually sync everything at a predetermined point. But there really is no ability to pause just one element or speed up others. Once you're off time code, you're going to have to go manual, and at least with pyro with all of the different fuse delays involved, manual just isn't going to be quite right. The only other last minute problem I could think of would be a corrupted file, or more than likely a revision that wasn't saved correctly or an outdated file being loaded automatically by the show control software and no one verifying that it was the proper version. These holiday shows are a one off, of course, so there is no dress rehearsel. You can run all the simulations you want, but you only get to fire off the pyro once.
I've seen so many instances of BSOD's on things like gas pumps, ATM's, etc. Windows sucks. Am I using it, yes I am. I'm well familiar with its eccentricities. Would I use it for mission critical projects, hell no.
Yeah, it could have been worse, imagine if they used the algorithm from the program that determines how long a file will take to to transfer...
:)
10... 9... 80.. 6430... 6... -3..
happy new years
Your point is valid: the failure was probably not directly attributable to the operating system. It may be that the automation was developed in Java/Eclipse and would have broken identically on any platform.
/. has been that Microsoft tools are explicitly designed to interfere with the freedom of its users and especially developers. This is not an especially contentions point in the debate because the Microsoft side of the argument is that this is their value-add. Deployments of Microsoft products are argued to be more consistent because the tools prohibit 'hacking'. Microsoft proponents also claim that there is less need for freedom in Microsoft tools because they tools integrate with each other seamlessly and 'just work'.
However, the point of many Microsoft 'haters' on
The reason some folks make these childish comments may be little more than "I told you so"-ism with a little confirmation bias, but the longer-winded version of these comments don't get any attention any more. The longer versions are basically re-hashes of essays by the likes of RMS, ESR, Bruce Perens, Linus Torvalds, Larry Wall and other FOSS folks.
So, in short, tools which are designed to prevent their users from modifying them attract and breed users who have no interest or experience in knowing how their tools work, how they don't work, and how to integrate them with tools which were not developed by the same company. "It only runs on Windows" is an indication to some that a tool is fragile, so whenever something breaks those people will naturally assume that thing runs on Windows even if Windows was not the cause of the breakage.
To answer your question, the point of mentioning that it runs on Windows is to re-iterate the above.