This is definitely *interesting* news, but it's questionable whether it will change anything. Even the best intentioned CEOs have a hard time risking their cash cows on untested brands and genres.
Truth be told, I think EA needs to manage it like a stock portfolio. Have X amount of high risk, Y amount of medium risk, and Z amount of low risk. The actual percentages of those items can vary depending on the market climate and the status of the company.
The advantage to a mixed strategy is that EA can continue to provide fans of a series with some sequels, but dial back the number in exchange for developing new genres and brands. Developing those brands could potentially provide EA with a sizable library of IP without having to stripmine the small development houses. That gives them a mixture of low and high risk. Something that can guarantee a positive cash flow when properly handled.
For the medium risk stuff, EA should pull out some of their old IP and see about doing proper updates or sequels to them. Rather than just mining the name (as they have done in the past), they should give the development team a free hand to develop a game in the true spirit of the original. For example, Wing Commander is a series that is sorely missed by fans. It never really died, having been killed off by EA's strip mining procedures. What they need to do is go drag Point of No Return Entertainment out of their pit, and get Chris Roberts to direct a new WC game. The costs would be significant, but there is a significant market that would purchase the game just because it's Wing Commander. That mitigates the risk some, and provides EA with a chance to make incredible sums of money off the title.
I suppose we'll have to see whether this new CEO shows the inititive to take his company in such a direction.
On another topic, who thinks that Wing Commander is ripe for a reboot?:D
Fair enough. I guess my issue then is that I don't understand what you're concerned about. The Apple phone in its current incarnation would be unlikely to sell, but I don't see any barriers to Apple designing a 3G version of the phone. Indeed, the only reason why the phone is as limited as it currently is, is due to Apple's contract with Cingular. They've already said that they will eventually branch out to other carriers, which means that the phone radio specs will change. (Not at all uncommon for mobile handsets.) So worrying about their phone being "only" 2G seems a bit pessimistic, doesn't it?
The iPhone is 2G, thus any company endorsing it would effectively be discouraging the use of 3G and those lucrative MMS facilities.
You're assuming that Apple won't upgrade the phone for the market. The unit technically has all the right software facilities, it just needs a smidge of different hardware. There's little doubt in my mind that when Apple is ready to crack the European market, they will have the necessary CDMA/TDMA hardware ready. Especially if they try and support the Sprint Nextel CDMA network before they make the move to Europe.
That's the point - a battleship that can only go in circles at 1/4 surface speed while involved in a battle is completely and utterly useless for all practical purposes.
No, the point is that had the Bismarck been designed like the automated systems on the Yorktown, she would have suffered catastrophic failure of all ships systems across the board. She didn't, which makes DerekLyons's example incorrect. While, the ability to survive in that situation didn't help her much, she may have been salvagable in other engagement situations.
NOT that I would have considered that a good thing. We had enough problems with Nazi Germany without their Battleships surviving the fray.
The Yorktown failure was caused by user error and poor input validation, not Windows.
Which caused a divide by zero error, which caused a buffer overflow, which caused a memory leak, which caused a cascading failure of the entire damn network!
Result: Dead ship. Brought down by the very capable hands of some poor midshipman.
Any ship that can so easily experience a failure in every one of its subsystems is not built on a good design.
Was it Windows that was the problem, per se? Not directly, but it highlights the issues with running consumer software in situations where people's lives are on the line. The error should have stopped at the divide by zero, and gotten no farther. But it didn't. Rather than the individual subsystem doing a fast reboot to come back online without the other subsystems being affected (like what the avionics of Fighter Jets do), it was allowed to cascade into a complete failure of all the ships systems. NOT GOOD.
TFA pointed out that to execute commands under the olds system an operator needed to flawlessly key in a string with no spaces or deletes.
Yes, I read that. Given the advances in technology, do you think it would be faster, better, and cheaper to fix that little problem in a working system, or would it be better to replace the entire computer system with a 100% untested OS and hardware configuration?
No, it only caused it to go in circles without the capability of correcting course or manouvering to avoid fire. For a battleship, I'd say that's pretty bad, but whatever.
Of course it's bad. But that didn't cause a cascade failure through the rest of the ship. Her guns didn't go offline, her screws didn't stop spinning, her command and control was still functioning, etc. It was certainly a critical hit for her tactical situation, but having the entire ship stop working because of a destroyed rudder would have been even worse.
Had the ship been part of a fleet action (rather than operating independently), then the survival of her other systems would have been more valuable. Perhaps even to the point of saving the ship. Unfortunately (for her), the ship was chased down and beaten senseless by everything the British forces could muster.
The Hood had a problem shared by many of the battlecruisers of that time, which was the lack of real deck armour.
Agreed. However, this was considered more of a tradeoff by the British rather than a flaw. Their thought was that by reducing the deck armor*, the ship could be made faster so that she could close gaps in a hurry. The design didn't really work out all that well, but it was intentional.
Or is that armour? No wonder she blew up. No armor!:P
The thing you fail to mention (or understand) is this: Yorktown's example is a rare one - well out at the end of the bell curve. Ships like her (and Franklin or Puffer) are the exception, not the rule.
Actually, you should take a look at the service record of the Yorktown carriers, and their descendents: The Essex class carriers. The entire lineage was at the "end of the bell curve".
Actually, when you look at all WWII ship losses, rather than cherrypicking - you find multiple cases of ships being lost because a single critical system crashing/faling/being damaged. (Bismark and her rudder, Prince of Wales and her screw, and Hood all come to mind.)
The Bismarck's rudder was a hit to a key system, but it didn't cause a failure across the board. The ship continued to fight through the night, even after such a critical wound. Come morning, she was still fighting. The British managed to silence most of her fighting ability through continual pounding, but were running low on ammunition. In the end, she still had engines and a sound hull, but was scuttled by her own crew to prevent capture by the enemy.
As for the Prince of Wales, she was a sitting duck. Battleships had no real defense against airpower in their day. (Technically, they don't really have a good defense now, either. Which is why they were retired: They were nothing more than cannon fodder.) Combined with existing unrepaired damage, inexperienced crew, and a radar that was non-functioning at the time they left port, it's no wonder that she ended up taking 6 torpedos and a bomb. I don't know enough about them, but the Dual Purpose guns being tied to the engines seems like a bad design to me. The Yorktown carriers didn't lose their defenseive capabilities just because their primary boilers were offline.
Lastly, the Hood took extreme damage which managed to penetrate the ship's magazine. Ships were armored against such attacks, but there's only so much that can be done. If a shell or fire hits the magazine, the resulting explosion will happily obliterate all the systems that might still be in operation. (aka, the rest of the damn ship)
Consider the loss of Thresher caused by the cascading effects of a single small leak!
The Thresher you're referring to was not a WWII warship. It was an experimental new nuclear vessel that suffered from a severe design flaw. The WWII Thresher was not destroyed, but was decomissioned.
However, it was critically flawed. The Navy found these flaws to be unacceptable and launched the SUBSAFE program to investigate the shipyard's design and construciton of these vessels. It found a variety of flaws and errors that were not up to Navy standards. Rather than accept such a failure as normal (as apparently is being suggested with the Yorktown), the Navy immediately demanded that the vessels be redesigned to eliminate these flaws.
Or perhaps we're the ones being realistic? From TFA:
It gets worse. This Windows box, unlike the one in the Trident sub, is by necessity heavily networked. A destroyer command system has to constantly communicate with other ships, aircraft, satellites, various organisations in the UK - lots of different computers.
It still won't be easy to hack a destroyer, but it will be distinctly possible. If you can't do it over a network, physically infiltrating a surface warship is a trivial task compared to getting aboard a Trident sub. Surface vessels have dozens of upper-deck doors and hatches, compared to a submarine's handful. Destroyers routinely tie up at berths without shoreside security, guarded by no more than a pair of gangway sentries. A surface warship's crew can and often do bring guests and visitors aboard. Security cockups have been known even in naval bases.
So a malware-infected Type 45 is actually achievable, and the destroyer computer will routinely have autonomous weapons authority.
Read your article again: "After a crew member mistakenly entered a zero into the data field of an application, the computer system proceeded to divide another quantity by that zero. The operation caused a buffer overflow, in which data leak from a temporary storage space in memory, and the error eventually brought down the ship's propulsion system. The result: the Yorktown was dead in the water for more than two hours."
Safeguards disabled or not, that is not an acceptable outcome. These machines kill people. The error should have stopped at the divide by zero. But it didn't. It resulted in a buffer overflow. Which resulted in a memory leak. Which resulted in the eventual crash of the entire network.
All that Mr. McKelvey is saying is that they didn't have the checks in place that would have prevented such values from being entered. The fact still remains that a single bug took down every subsystem in the ship. That is unacceptable, as situations may arise where invalid data either passes the checks by accident, or is unexpectedly created from inside the system. (e.g. Sensors sometimes give values that are unexpected.) Proper design would have taken into account that this could happen, and protected each system against crashes in other systems.
In any case, all the Navy was attempting to do was drive machinary outside of their speced ranges. Allowing those ranges to be manually overridden is not an excuse for total failure. The Yorktown was a warship. Which means that she may have been called upon to operate outside of safe limits inside a variety of combat situations. Would it be acceptable for the ship to crash because the crew was trying to compensate for battle damage? And if the ship's systems are so vulnerable without these checks, what happens when damage from enemy fire starts causing power spikes and drops? Does every subsystem cascade into failure just because a different networked subsystem failed?
If the USS Yorktown (CV-5) had been equipped with these systems, we would have lost the Pacific theater in WWII. Rather than continuing to fight after taking torpedo after torpedo after torpedo, her systems would have crashed or been corrupted, and that would have been the end of her fighting ability.
Never mind the reality that the Yorktown carrier had continued operations at the Battle of Coral Sea after receiving a bomb through the deck that penetrated the hull and exploded below decks. The damage was estimated to take 3 months back in port to repair. Never mind that she was hastily patched up in only three days and sent straight back out to the Battle of Midway. Never mind that she took 3 bombs from enemy fighter planes before the boilers were taken offline for repairs. Never mind that she was back up and giving 20 knots only one hour later. Never mind that in her heavily damaged, beaten, and bruised state, she still managed to evade two torpedos through wild maneuvering before the enemy torpedoing finally tore into her hull. Two torpedos ripped into her and jammed her rudder. Her powerplants went offline and she began to list. The ship was abandoned, but wasn't lost until the next day when another two torpedos contacted her hull during (amazingly successful) salvage operations.
THAT is the type of hell that these computer systems will need to go through. They must fight to the last minute to make sure that the ship remains operational. The lives of those on board, and those back home may depend on it some day. Having systems crash at the slightest sign of bad data is not acceptable. Bad data is a guarantee in these systems. When the ship starts taking damage, she WILL experience failures. There's no question about it. But one failure should never, ever, ever lead to another one. If it does, people die and wars are lost.
And that's going to stop someone from accidently running into another divide by zero bug? Or from the system being compromised by a tech who decided to interface his laptop for convenience of system administration, and accidently carried a virus from shore? Or even foreign agents installing sophisticated spyware* because the OS is designed to run user programs? And that's assuming that situations don't arise where the Windows Task Scheduler is busy, and fails to respond fast enough in combat situations! (Never a problem in RTOSes, where they're designed with such situations in mind.)
There are just so many things that can go wrong here, that it's not even funny. This simply is not a wise move. Not by a long shot.
You'd know that Win2k, however bad, is far better than what they have now.
How so? Because the old system requires training to use? Shock and horrors.:-/
The old system worked. It was difficult to use because of the technology of the time, but it's not like they can't upgrade that (or design a new system) rather than trusting the lives of their sailors and country to a yank system that the US Navy couldn't even get working.
As the article shows, the previous software was terrible already.
I think you're missing the point. These are systems that control nuclear weapons. Not to mention, perserve the lives of sailors in both combat and non-combat situations. They've kept the existing systems because they work, not because they impress anyone. The prudent solution is to upgrade these systems cautiously, with an eye toward a zero possibility for failure. Which not only excludes the use of Windows, but excludes the use of Linux, Mac OS X, FreeBSD, or just about anything else that the military hasn't either built themselves or gone over with a fine-tooth comb.
Consider the case of NASA. The Space Shuttle still runs on IBM's AP-101 computer systems from the 1970's. The only upgrade was a move from TTL circuitry to a semiconductor design. (The AP-101S.) Astronauts still pull out the flight manual and punch in program codes to execute computer-controlled flight maneuvers. More sophisticated systems are available today, so why hasn't NASA upgraded the computers?
The answer is "because it works". The shuttle actually has 5 AP-101 computers, four of which are redundantly in sync to catch failures, and one which runs software written by a completely different team. Should any of the computers start giving different answers, NASA will immediately take measures to determine what is wrong, why, and how they can fix or work around it in whatever time window is available to them. (Obviously, some situations are tight on available time, and may require that manual control be established.) Just try getting that sort of reliability out of a Windows-based flight computer!
I know this is Slashdot, where nerds like their OSes. But there are times when the best solution for the job does not involve your favorite OS, hardware, or even your design philosophy. People's lives are on the line. It's best that the right choice be the one that provides the absolute best chance of preserving those lives rather than taking the chance (however infinitesimal) in exchange for some pretty buttons to click on.
I'm not saying that Her Majesty's Navy shouldn't upgrade her systems to ones with better combat effectiveness, but I am saying that Windows-based systems are not it. Not the software, not the hardware, and not the overall design. It's the wrong solution to the problem. I can only pray that it doesn't get someone killed.
I'm sure we all remember how well things went for the U.S.S. Yorktown; an Aegis Class missile destroyer that ended up dead in the water after a crew member entered a zero into a database. Obviously, this was caused by the fact that the Yorktown's control software was of a really bad design. Critical systems should have never been so tightly linked that a failure in one area would cause a cascading failure across the ship. Still, it raised a lot of questions about the wisdom of using consumer software for life and death situations.
Two years after that, the Navy had still not learned their lesson. The flagship of the seventh fleet, the USS Blue Ridge, was deployed in 1999 with Windows-based Command and Control systems. The result? The ship was infected with the Melissa Macro Virus. (Source - Section 12.4)
I'm sorry, but when you're taking men into combat, you want equipment that has been designed to do what needs to be done, not pretty features that let the GIs open their email attachments. There's a reason why the current military setup in the US is for the crew to have their own laptops for personal use. Using a consumer OS in a battle-critical system is nothing but a recipe for disaster. It's too bad that Her Majesty's Navy has failed to learn from the mistakes of others.
I think you misunderstand. My suspicion stems from the author's motivations, not whether Microsoft is involved or not. His first post was made to a software forum, where it's unlikely he was compensated for it. His second post was made to a semi-official corporate "blog", which raises questions about if he's being paid or not. Being an author myself, I know that's it's incredibly easy to step over the lines of journalistic integrity in exchange for that few hundred dollars of pay.
The question is, did the author really change his mind, or is he writing the conclusions that he knows will net him an income? If it's the former, he really should have expanded his article to prevent this sort of issue. If it's the latter, then the author is untrustworthy and should no longer be paid to provide his opinion in any professionally written form.
Microsoft never enters into the equation here, save for the fact that some entities may have a monetary interest in promoting Microsoft Windows -OR- Linux. (There's money in both directions.) That being said, it is sad that this issue may never have come up if the order of the articles was reversed. Slashdot is very pro-Linux (something which I am ambivalent about), meaning that it would have likely been seen as a win rather than the questionable journalism it is.
I have a feeling that as the author worked more and more with the different threading models, he seems to have a more matured opinion.
Normally I'd agree with you. But if you read both articles, you realize that his intentions may be a bit less honorable. The Win32 article is the exact same article, but with the conclusions changed. Maturing opinions usually result in some discussion of why one has changed their mind (even if it's only mentioned in passing) and/or a deep explanation of what caused their mind to change. This smells more like an attempt to play both sides.
Of course, it could be that the author is simply not comfortable with writing. He could be looking to make a quick buck by taking a simple forum post of his and modifying it to reflect his current opinion. It's worth giving him the benefit of the doubt on, but I am certainly suspicious.
The problem with your logic is that your mom probably doesn't want to send a file in the first place. She wants to send the content. An email editor could (should?) have an "insert document" button that would use the copy of Word on your machine to convert the file to RTF (which generally works quite well) and send it as an rtf email (which is fairly well supported). Alternatively, attaching a Word file could present a dialog: "Send unaltered" or "Convert to compatible format and set" (with better text for those two options). The problem isn't the standard per se -- the problem is the email interface.
That's exactly what I was getting at. There should be a common interchange format. It shouldn't even ask whether the file should be converted ("mom" doesn't know the answer), it should just do it. If everyone agrees on the format, then it will Just Work(TM). Which makes "mom" very happy indeed.:P
From what I've heard the rumours about the disc spinning constantly or backwards compared to normal drives were myths from the GameCube discs, which turned out to be regular DVDs with a slightly different encoder or something.
The backwards spin *is* a myth. However, the Constant Angular Velocity is the encoding of which you're thinking about. When you write a disc with CAV, the data spaces out differently than the more tightly packed CLV technology. However, it's easier on the motor because the motor doesn't have to step up and down speeds so much.
No offense, but I'm getting sick of this line of reasoning.
Too bad. Because it is a real problem. When "mom" wants to give someone a movie, she only needs to give them a DVD. That's a standard. When "mom" wants to listen to music, she only needs a CD player. That's a standard. When "mom" wants to send a letter, she uses U.S. Letter paper with English words on it that fits into a Standard Size Envelope. That's a standard.
When "mom" wants to send a document through email, she either has to use the MS Office psuedo-standard forced upon the industry, or she needs to thoroughly understand which format is which in an attempt to ensure that the person on the other end knows how to read the file. When she receives a file, if it's not in the same MS Office psuedo-standard, she can't read it.
Like it or not, that's a real problem and Microsoft has the industry by the balls. If a standard interchange format existed, then "mom" would be able to use just about any computer and program, with the expectation that the computer will be able to read/send in that interchange format.
The M in HTML stands for MARKUP. And it means it. HTML is NOT a layout language. Never has been, and apparently never will be despite unending attempts to use it for page layout.
CSS *is* a layout language, however. It works in conjunction with HTML. In theory, at least, pure CSS/XHTML should layout the same in every browser. (Ftom a practical perspective, of course, no one fully implements the CSS standard.)
In any case, that's beside the point I was trying to make. My point is that a 200 page HTML/CSS file is an unweildly beast that will take forever to make changes to. Which is not surprising, given that markup languages are serial formats. Microsoft Word gets around this problem by using a binary format that can be updated without rewriting the entire file. (Thus why Microsoft Documents have a nasty habit of getting bigger rather than smaller.) Markup formats don't have this advantage, and rely on heavy processing power and fast I/O to make up for their deficiencies.
That's why I say that (X)HTML/CSS makes a great intermediary format, but it's not so good as a local data store.
Yeah, but that "book" is fsck'n ugly. It doesn't even compare to a professionally typeset book, or something produced in LaTeX.
You don't typeset with Microsoft Word, either. Which makes the entire argument specious. Word processors like MS Word and OOo Writer are for creating common documents like letters, memos, and maybe the occasional flyer. Neither one is particularly good at anything even close to professional publishing work. Even the book authors just use Word (or surprisingly, OOo Writer!) to do the text content. That text is then exported to a more sophisticated program, where the actual typesetting and page layouts are done.
I think this fellow's point is that HTML/CSS formats can store any information that a Word Processor might need to store, with no need to invoke new technologies. To a certain extent, he may be correct. Unfortunately, HTML/CSS may make a good intermediary format, but it is not particularly good from a performance or usability perspective. Then again, XML formats in general are fairly poor choices for the same reason.
I think if we want to break this conundrum, the industry is going to have to learn how to keep local data stores that are of high performance, while exporting intermediary formats when emailing or uploading to external computers. The only problem is finding a way of doing this so that it's completely transparent to users. The mythical "mom" doesn't want to worry about emailing a document in the right format, or having the right program to read the attachment she received. She just wants it to do what she tells it, with no bloody prompting with questions she has no answers for.
We never know enough. But we could spend unlimited amounts of money on trying to find the answers. The problem is that NASA has a relatively fixed budget, and needs to look at getting the most answers for their dollars. For right now, the money spent per answer is terrible. Worse yet, we know enough to make future missions a success, which just makes the ROI that much worse.
If the ISS was doing research into, say, a new power source that would solve our energy needs for the next few decades, then I'd say the money is extremely well spent. But setting new records on the number of spacewalks per astronaut? For the amount of money being spent on the ISS, that's not a good use of our limited funds.
Slashdot Mirror
This is definitely *interesting* news, but it's questionable whether it will change anything. Even the best intentioned CEOs have a hard time risking their cash cows on untested brands and genres.
:D
Truth be told, I think EA needs to manage it like a stock portfolio. Have X amount of high risk, Y amount of medium risk, and Z amount of low risk. The actual percentages of those items can vary depending on the market climate and the status of the company.
The advantage to a mixed strategy is that EA can continue to provide fans of a series with some sequels, but dial back the number in exchange for developing new genres and brands. Developing those brands could potentially provide EA with a sizable library of IP without having to stripmine the small development houses. That gives them a mixture of low and high risk. Something that can guarantee a positive cash flow when properly handled.
For the medium risk stuff, EA should pull out some of their old IP and see about doing proper updates or sequels to them. Rather than just mining the name (as they have done in the past), they should give the development team a free hand to develop a game in the true spirit of the original. For example, Wing Commander is a series that is sorely missed by fans. It never really died, having been killed off by EA's strip mining procedures. What they need to do is go drag Point of No Return Entertainment out of their pit, and get Chris Roberts to direct a new WC game. The costs would be significant, but there is a significant market that would purchase the game just because it's Wing Commander. That mitigates the risk some, and provides EA with a chance to make incredible sums of money off the title.
I suppose we'll have to see whether this new CEO shows the inititive to take his company in such a direction.
On another topic, who thinks that Wing Commander is ripe for a reboot?
Fair enough. I guess my issue then is that I don't understand what you're concerned about. The Apple phone in its current incarnation would be unlikely to sell, but I don't see any barriers to Apple designing a 3G version of the phone. Indeed, the only reason why the phone is as limited as it currently is, is due to Apple's contract with Cingular. They've already said that they will eventually branch out to other carriers, which means that the phone radio specs will change. (Not at all uncommon for mobile handsets.) So worrying about their phone being "only" 2G seems a bit pessimistic, doesn't it?
You're assuming that Apple won't upgrade the phone for the market. The unit technically has all the right software facilities, it just needs a smidge of different hardware. There's little doubt in my mind that when Apple is ready to crack the European market, they will have the necessary CDMA/TDMA hardware ready. Especially if they try and support the Sprint Nextel CDMA network before they make the move to Europe.
No, the point is that had the Bismarck been designed like the automated systems on the Yorktown, she would have suffered catastrophic failure of all ships systems across the board. She didn't, which makes DerekLyons's example incorrect. While, the ability to survive in that situation didn't help her much, she may have been salvagable in other engagement situations.
NOT that I would have considered that a good thing. We had enough problems with Nazi Germany without their Battleships surviving the fray.
Which caused a divide by zero error, which caused a buffer overflow, which caused a memory leak, which caused a cascading failure of the entire damn network!
Result: Dead ship. Brought down by the very capable hands of some poor midshipman.
Any ship that can so easily experience a failure in every one of its subsystems is not built on a good design.
Was it Windows that was the problem, per se? Not directly, but it highlights the issues with running consumer software in situations where people's lives are on the line. The error should have stopped at the divide by zero, and gotten no farther. But it didn't. Rather than the individual subsystem doing a fast reboot to come back online without the other subsystems being affected (like what the avionics of Fighter Jets do), it was allowed to cascade into a complete failure of all the ships systems. NOT GOOD.
Yes, I read that. Given the advances in technology, do you think it would be faster, better, and cheaper to fix that little problem in a working system, or would it be better to replace the entire computer system with a 100% untested OS and hardware configuration?
Of course it's bad. But that didn't cause a cascade failure through the rest of the ship. Her guns didn't go offline, her screws didn't stop spinning, her command and control was still functioning, etc. It was certainly a critical hit for her tactical situation, but having the entire ship stop working because of a destroyed rudder would have been even worse.
Had the ship been part of a fleet action (rather than operating independently), then the survival of her other systems would have been more valuable. Perhaps even to the point of saving the ship. Unfortunately (for her), the ship was chased down and beaten senseless by everything the British forces could muster.
Agreed. However, this was considered more of a tradeoff by the British rather than a flaw. Their thought was that by reducing the deck armor*, the ship could be made faster so that she could close gaps in a hurry. The design didn't really work out all that well, but it was intentional.
Or is that armour? No wonder she blew up. No armor!
Actually, you should take a look at the service record of the Yorktown carriers, and their descendents: The Essex class carriers. The entire lineage was at the "end of the bell curve".
The Bismarck's rudder was a hit to a key system, but it didn't cause a failure across the board. The ship continued to fight through the night, even after such a critical wound. Come morning, she was still fighting. The British managed to silence most of her fighting ability through continual pounding, but were running low on ammunition. In the end, she still had engines and a sound hull, but was scuttled by her own crew to prevent capture by the enemy.
As for the Prince of Wales, she was a sitting duck. Battleships had no real defense against airpower in their day. (Technically, they don't really have a good defense now, either. Which is why they were retired: They were nothing more than cannon fodder.) Combined with existing unrepaired damage, inexperienced crew, and a radar that was non-functioning at the time they left port, it's no wonder that she ended up taking 6 torpedos and a bomb. I don't know enough about them, but the Dual Purpose guns being tied to the engines seems like a bad design to me. The Yorktown carriers didn't lose their defenseive capabilities just because their primary boilers were offline.
Lastly, the Hood took extreme damage which managed to penetrate the ship's magazine. Ships were armored against such attacks, but there's only so much that can be done. If a shell or fire hits the magazine, the resulting explosion will happily obliterate all the systems that might still be in operation. (aka, the rest of the damn ship)
The Thresher you're referring to was not a WWII warship. It was an experimental new nuclear vessel that suffered from a severe design flaw. The WWII Thresher was not destroyed, but was decomissioned.
However, it was critically flawed. The Navy found these flaws to be unacceptable and launched the SUBSAFE program to investigate the shipyard's design and construciton of these vessels. It found a variety of flaws and errors that were not up to Navy standards. Rather than accept such a failure as normal (as apparently is being suggested with the Yorktown), the Navy immediately demanded that the vessels be redesigned to eliminate these flaws.
I mean that they moved a load of TTL chips on a circuit board to a miniturized semiconductor that did the same thing.
Read your article again: "After a crew member mistakenly entered a zero into the data field of an application, the computer system proceeded to divide another quantity by that zero. The operation caused a buffer overflow, in which data leak from a temporary storage space in memory, and the error eventually brought down the ship's propulsion system. The result: the Yorktown was dead in the water for more than two hours."
Safeguards disabled or not, that is not an acceptable outcome. These machines kill people. The error should have stopped at the divide by zero. But it didn't. It resulted in a buffer overflow. Which resulted in a memory leak. Which resulted in the eventual crash of the entire network.
All that Mr. McKelvey is saying is that they didn't have the checks in place that would have prevented such values from being entered. The fact still remains that a single bug took down every subsystem in the ship. That is unacceptable, as situations may arise where invalid data either passes the checks by accident, or is unexpectedly created from inside the system. (e.g. Sensors sometimes give values that are unexpected.) Proper design would have taken into account that this could happen, and protected each system against crashes in other systems.
In any case, all the Navy was attempting to do was drive machinary outside of their speced ranges. Allowing those ranges to be manually overridden is not an excuse for total failure. The Yorktown was a warship. Which means that she may have been called upon to operate outside of safe limits inside a variety of combat situations. Would it be acceptable for the ship to crash because the crew was trying to compensate for battle damage? And if the ship's systems are so vulnerable without these checks, what happens when damage from enemy fire starts causing power spikes and drops? Does every subsystem cascade into failure just because a different networked subsystem failed?
If the USS Yorktown (CV-5) had been equipped with these systems, we would have lost the Pacific theater in WWII. Rather than continuing to fight after taking torpedo after torpedo after torpedo, her systems would have crashed or been corrupted, and that would have been the end of her fighting ability.
Never mind the reality that the Yorktown carrier had continued operations at the Battle of Coral Sea after receiving a bomb through the deck that penetrated the hull and exploded below decks. The damage was estimated to take 3 months back in port to repair. Never mind that she was hastily patched up in only three days and sent straight back out to the Battle of Midway. Never mind that she took 3 bombs from enemy fighter planes before the boilers were taken offline for repairs. Never mind that she was back up and giving 20 knots only one hour later. Never mind that in her heavily damaged, beaten, and bruised state, she still managed to evade two torpedos through wild maneuvering before the enemy torpedoing finally tore into her hull. Two torpedos ripped into her and
jammed her rudder. Her powerplants went offline and she began to list. The ship was abandoned, but wasn't lost until the next day when another two torpedos contacted her hull during (amazingly successful) salvage operations.
THAT is the type of hell that these computer systems will need to go through. They must fight to the last minute to make sure that the ship remains operational. The lives of those on board, and those back home may depend on it some day. Having systems crash at the slightest sign of bad data is not acceptable. Bad data is a guarantee in these systems. When the ship starts taking damage, she WILL experience failures. There's no question about it. But one failure should never, ever, ever lead to another one. If it does, people die and wars are lost.
And that's going to stop someone from accidently running into another divide by zero bug? Or from the system being compromised by a tech who decided to interface his laptop for convenience of system administration, and accidently carried a virus from shore? Or even foreign agents installing sophisticated spyware* because the OS is designed to run user programs? And that's assuming that situations don't arise where the Windows Task Scheduler is busy, and fails to respond fast enough in combat situations! (Never a problem in RTOSes, where they're designed with such situations in mind.)
:P
There are just so many things that can go wrong here, that it's not even funny. This simply is not a wise move. Not by a long shot.
* Brings new meaning to the term, doesn't it?
How so? Because the old system requires training to use? Shock and horrors.
The old system worked. It was difficult to use because of the technology of the time, but it's not like they can't upgrade that (or design a new system) rather than trusting the lives of their sailors and country to a yank system that the US Navy couldn't even get working.
I think you're missing the point. These are systems that control nuclear weapons. Not to mention, perserve the lives of sailors in both combat and non-combat situations. They've kept the existing systems because they work, not because they impress anyone. The prudent solution is to upgrade these systems cautiously, with an eye toward a zero possibility for failure. Which not only excludes the use of Windows, but excludes the use of Linux, Mac OS X, FreeBSD, or just about anything else that the military hasn't either built themselves or gone over with a fine-tooth comb.
Consider the case of NASA. The Space Shuttle still runs on IBM's AP-101 computer systems from the 1970's. The only upgrade was a move from TTL circuitry to a semiconductor design. (The AP-101S.) Astronauts still pull out the flight manual and punch in program codes to execute computer-controlled flight maneuvers. More sophisticated systems are available today, so why hasn't NASA upgraded the computers?
The answer is "because it works". The shuttle actually has 5 AP-101 computers, four of which are redundantly in sync to catch failures, and one which runs software written by a completely different team. Should any of the computers start giving different answers, NASA will immediately take measures to determine what is wrong, why, and how they can fix or work around it in whatever time window is available to them. (Obviously, some situations are tight on available time, and may require that manual control be established.) Just try getting that sort of reliability out of a Windows-based flight computer!
I know this is Slashdot, where nerds like their OSes. But there are times when the best solution for the job does not involve your favorite OS, hardware, or even your design philosophy. People's lives are on the line. It's best that the right choice be the one that provides the absolute best chance of preserving those lives rather than taking the chance (however infinitesimal) in exchange for some pretty buttons to click on.
I'm not saying that Her Majesty's Navy shouldn't upgrade her systems to ones with better combat effectiveness, but I am saying that Windows-based systems are not it. Not the software, not the hardware, and not the overall design. It's the wrong solution to the problem. I can only pray that it doesn't get someone killed.
I'm sure we all remember how well things went for the U.S.S. Yorktown; an Aegis Class missile destroyer that ended up dead in the water after a crew member entered a zero into a database. Obviously, this was caused by the fact that the Yorktown's control software was of a really bad design. Critical systems should have never been so tightly linked that a failure in one area would cause a cascading failure across the ship. Still, it raised a lot of questions about the wisdom of using consumer software for life and death situations.
Two years after that, the Navy had still not learned their lesson. The flagship of the seventh fleet, the USS Blue Ridge, was deployed in 1999 with Windows-based Command and Control systems. The result? The ship was infected with the Melissa Macro Virus. (Source - Section 12.4)
I'm sorry, but when you're taking men into combat, you want equipment that has been designed to do what needs to be done, not pretty features that let the GIs open their email attachments. There's a reason why the current military setup in the US is for the crew to have their own laptops for personal use. Using a consumer OS in a battle-critical system is nothing but a recipe for disaster. It's too bad that Her Majesty's Navy has failed to learn from the mistakes of others.
I think you misunderstand. My suspicion stems from the author's motivations, not whether Microsoft is involved or not. His first post was made to a software forum, where it's unlikely he was compensated for it. His second post was made to a semi-official corporate "blog", which raises questions about if he's being paid or not. Being an author myself, I know that's it's incredibly easy to step over the lines of journalistic integrity in exchange for that few hundred dollars of pay.
The question is, did the author really change his mind, or is he writing the conclusions that he knows will net him an income? If it's the former, he really should have expanded his article to prevent this sort of issue. If it's the latter, then the author is untrustworthy and should no longer be paid to provide his opinion in any professionally written form.
Microsoft never enters into the equation here, save for the fact that some entities may have a monetary interest in promoting Microsoft Windows -OR- Linux. (There's money in both directions.) That being said, it is sad that this issue may never have come up if the order of the articles was reversed. Slashdot is very pro-Linux (something which I am ambivalent about), meaning that it would have likely been seen as a win rather than the questionable journalism it is.
Normally I'd agree with you. But if you read both articles, you realize that his intentions may be a bit less honorable. The Win32 article is the exact same article, but with the conclusions changed. Maturing opinions usually result in some discussion of why one has changed their mind (even if it's only mentioned in passing) and/or a deep explanation of what caused their mind to change. This smells more like an attempt to play both sides.
Of course, it could be that the author is simply not comfortable with writing. He could be looking to make a quick buck by taking a simple forum post of his and modifying it to reflect his current opinion. It's worth giving him the benefit of the doubt on, but I am certainly suspicious.
That's exactly what I was getting at. There should be a common interchange format. It shouldn't even ask whether the file should be converted ("mom" doesn't know the answer), it should just do it. If everyone agrees on the format, then it will Just Work(TM). Which makes "mom" very happy indeed.
The backwards spin *is* a myth. However, the Constant Angular Velocity is the encoding of which you're thinking about. When you write a disc with CAV, the data spaces out differently than the more tightly packed CLV technology. However, it's easier on the motor because the motor doesn't have to step up and down speeds so much.
Here's *a* source: http://www.emulanium.com/gamecube.php
Another: http://www.wiili.org/index.php/GameCube_Optical_D
Tons More: http://www.google.com/search?q=Gamecube+Constant+
Too bad. Because it is a real problem. When "mom" wants to give someone a movie, she only needs to give them a DVD. That's a standard. When "mom" wants to listen to music, she only needs a CD player. That's a standard. When "mom" wants to send a letter, she uses U.S. Letter paper with English words on it that fits into a Standard Size Envelope. That's a standard.
When "mom" wants to send a document through email, she either has to use the MS Office psuedo-standard forced upon the industry, or she needs to thoroughly understand which format is which in an attempt to ensure that the person on the other end knows how to read the file. When she receives a file, if it's not in the same MS Office psuedo-standard, she can't read it.
Like it or not, that's a real problem and Microsoft has the industry by the balls. If a standard interchange format existed, then "mom" would be able to use just about any computer and program, with the expectation that the computer will be able to read/send in that interchange format.
CSS *is* a layout language, however. It works in conjunction with HTML. In theory, at least, pure CSS/XHTML should layout the same in every browser. (Ftom a practical perspective, of course, no one fully implements the CSS standard.)
In any case, that's beside the point I was trying to make. My point is that a 200 page HTML/CSS file is an unweildly beast that will take forever to make changes to. Which is not surprising, given that markup languages are serial formats. Microsoft Word gets around this problem by using a binary format that can be updated without rewriting the entire file. (Thus why Microsoft Documents have a nasty habit of getting bigger rather than smaller.) Markup formats don't have this advantage, and rely on heavy processing power and fast I/O to make up for their deficiencies.
That's why I say that (X)HTML/CSS makes a great intermediary format, but it's not so good as a local data store.
You don't typeset with Microsoft Word, either. Which makes the entire argument specious. Word processors like MS Word and OOo Writer are for creating common documents like letters, memos, and maybe the occasional flyer. Neither one is particularly good at anything even close to professional publishing work. Even the book authors just use Word (or surprisingly, OOo Writer!) to do the text content. That text is then exported to a more sophisticated program, where the actual typesetting and page layouts are done.
I think this fellow's point is that HTML/CSS formats can store any information that a Word Processor might need to store, with no need to invoke new technologies. To a certain extent, he may be correct. Unfortunately, HTML/CSS may make a good intermediary format, but it is not particularly good from a performance or usability perspective. Then again, XML formats in general are fairly poor choices for the same reason.
I think if we want to break this conundrum, the industry is going to have to learn how to keep local data stores that are of high performance, while exporting intermediary formats when emailing or uploading to external computers. The only problem is finding a way of doing this so that it's completely transparent to users. The mythical "mom" doesn't want to worry about emailing a document in the right format, or having the right program to read the attachment she received. She just wants it to do what she tells it, with no bloody prompting with questions she has no answers for.
We never know enough. But we could spend unlimited amounts of money on trying to find the answers. The problem is that NASA has a relatively fixed budget, and needs to look at getting the most answers for their dollars. For right now, the money spent per answer is terrible. Worse yet, we know enough to make future missions a success, which just makes the ROI that much worse.
If the ISS was doing research into, say, a new power source that would solve our energy needs for the next few decades, then I'd say the money is extremely well spent. But setting new records on the number of spacewalks per astronaut? For the amount of money being spent on the ISS, that's not a good use of our limited funds.
Block him from gaining Customer Service (a.k.a. "admin") rights to the system, not block him from being a customer. RTFA.
I think you forgot, "This message (and house) will self-destruct in 10 seconds. 9... 8..."