Windows For Warships Nearly Ready 387
mattaw writes "The Register is carrying the sanest and balanced article on Windows deployment in UK warships that I have read to date in the public domain.
As an ex-naval bod myself we have long considered that this is potentially a REAL problem. The main issues are the huge amount of unrelated code that is imported with the kernel and the need for incredibly fast response times."
Sortof a Microsoft fanboy, but... (Score:5, Insightful)
Sure, there are many options out there -- Linux, continuing to use a proprietary OS, Windows, whatever. Yet with technology changing as fast as it does (even military hardware), it does make sense to use an operating system that has some base support for almost everything. In this case, it is Microsoft.
Does Windows crash often? For many users, I think the answer is yes. But in my experience, you can tailor a Windows installation to just the most basic requirements and it runs fairly well. I highly doubt that warships would be connecting to the public Internet with the users downloading any number of buggy apps to conflict with mission-critical applications. Since that is the case, there are a number of long term installations that I have familiarity with that have been running Win2K (and some WinXP) that have been running flawlessly for years for my client base. None of these installations are on a public IP, none of them allow end-user application installation, and all of them have been extremely rock solid AND easy to maintain when necessary. As the article shows, their main connection is a unidirectional 300 baud ship-to-shore link.
We're not talking about a machine running everything, just specific software for a specific purpose. Anything is a step in the right direction when you consider what a Luddite the military can be in terms of support applications versus the modern hardware they're running. Training new users on ancient system is very inefficient and dangerous (read the article on their ancient interface hardware!), giving them an interface they recognize makes sense from many angles, including safety. The interface to enable weapons firing won't rely just on Windows to approve or disapprove a launch -- there are always old-fashioned hard key-based turn-locks that override whatever the software does. If they want to launch a missile, the physical keys must be turned, and THEN the software must be approved. If there's a glitch after this hard-approval is turned, it can't be in grave error.
The bottom line is that I liked Win2K towards the end of its supported life. I had many customers who were unhappy about moving to Windows XP, and we still support numerous servers running Windows 2000 for mission critical (not THIS critical, though) applications that are running strong and haven't had to be restarted in over a year or longer (one customer hasn't rebooted their Win2K installation in 3 years). The software works, the API interface is known by most modern programmers, user interface is comfortable for almost everyone, and as long as you don't connect it to the public Internet or try to install a variety of conflicting/buggy applications, you're in good shape.
I think this option is better than Linux or F/OSS operating systems that would possibly require MORE training for their programmers and users to learn. My biggest frustration with F/OSS operating systems is that the user interface is counter-intuitive for a lot of Windows-friendly users, and even worse, trying to find an "old but stable" operating system is a mess as the F/OSS operating system support-base seems to be more focused on the latest stable builds rather than what mission-critical users would want: older software that has a longer history of running well for a given situation.
Blue Screen of Death? (Score:5, Funny)
Re:Blue Screen of Death? (Score:5, Funny)
Not sure how to launch the latest megaton H-bomb? Let Clippy guide you...
Re:Blue Screen of Death? (Score:5, Funny)
That's the same Clippy that routinely calls home to Microsoft, right?
Sounds like a good plan to me. ;-)
You need to turn on Windows Update... (Score:2, Funny)
1. Bart calls API. "Is your remote registry service running?" "Well, you better go catch it."
2. Two kernels walk into a bar. The third one panics.
Next time, please refer to the KB article.
But It's Still Software From Another Country (Score:5, Insightful)
Who cares about training when you're now dependent on a company in another nation? What happens when there's another nutcase in the white house who orders Microsoft to cut off updates or support to foreign military customers?
I believe prior to BAE's sole recommendation that AMS, a company that specializes in Combat Management Systems, recommended Unix [theregister.co.uk]. There was also criticism [theregister.co.uk] of a lack of third party external review for this decision (not sure if that's linked in the original article or not). If it's the case that BAE up and said "We're going with Win2K" and the government said "ok," I would be a bit concerned.
I do not think the United States Navy would willingly rely on any foreign proprietary software.
Re: (Score:2)
http://en.wikipedia.org/wiki/Trident_missile [wikipedia.org]
As Wiki confirms, these are made right up the street from me at:
Contractor: Lockheed Martin Space Systems, Sunnyvale, California
It's an Amerian system that Britain coughed up 5% of the R&D costs. Britain has no independent nuclear systems.
Why the British don't make computers (Score:5, Funny)
And Why do the British Drink Warm Beer? (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
I think this option is better than Linux or F/OSS operating systems that would possibly require MORE training for their programmers and users to learn.
You must not be a resident of the United Kingdom. I find it interesting that any country's government or military would rely on a foreign proprietary piece of software to reach mission critical goals.
You mean like how Australia is strongly considering it's involvement in the F-35 Joint Strike Fighter project because we can't get access to the source code?
http://www.aph.gov.au/Library/Pubs/rn/2005-06/06 rn32.htm is a current overview of our involvement and committment, and the very first issue (under Current Issues) is access to the source.
From the report:
While earlier problems such as aircraft weight and range have apparently been solved, questions about the release of the computer source code that makes the aircraft so unique have emerged as a potential showstopper for international clients. The source code in question refers to the millions of lines of computer code that allow this 21st-century aircraft to fly and to fight. Without complete access to this source code, Australia will be unable to modify or even maintain the aircraft independently--as it has done so successfully for many years with the F-111.
The question about the release of the source code to Australia has not been confirmed publicly. It is understood that maintenance of the JSF will be undertaken in a regional logistics and maintenance centre run by Lockheed Martin. Without access to the source code, Australia may in coming decades be put in the invidious position of having no option but to pay whatever Lockheed Martin asks during future contract negotiations for the ongoing maintenance of Australia's strike fighters.
It seems that the UK is also considering pulling out of the F-35 for the same reason - and if the UK pulls out, so might Australia.
Re:But It's Still Software From Another Country (Score:4, Insightful)
even if there is a back door, what good is it if the machine is not connected to anything that the NSA could practically get too.
unless I'm missing something obvious?
Re: (Score:3, Funny)
Do you really want to play that game? (Score:3, Interesting)
Specific vulnerabilities would depend on function, but if you're designing a backdoor, you can certainly find a way to trigger it that doesn't depend on a network connection. Particularly if you have access to the device drivers and stuff at the same time, you could figure out a way to trigger the backdoor through a device that's not normally assumed to be a security threat.
It's
Re: (Score:3, Informative)
Software is far more dangerous than machinery. (Score:5, Insightful)
Buying machinery is one thing; software is quite another. With a machine, even a fairly complicated one, you can with enough effort, understand what's going on inside it.
Say you have an Apache helicopter. When you buy that helicopter, you also buy training. Not only do you send the pilots in for training, but you also send all of the maintenance people, pad crews, etc. They learn how to service it, tear-down the engines, etc. So what you get back is far from just the machine, you get a machine, and a crew who (ought to) basically understands it. And if you really want to understand it, if you're any country worth discussing, you ought to have at least a few engineers who could spend a few weeks figuring out key parts.
But with software, you're buying a true black box. You're being handed something (which, if every line of code was the size of a watch-gear, would probably be as big as a trailer truck) that you cannot have any significant insight into the workings of. You have no idea how it really works, or what it's truly programmed to do.
With a machine, you can tear the thing apart on receipt and make sure there's nothing suspect in there; no bombs or homing beacons, etc. You really can't do that with a large piece of precompiled software. You are totally at the mercy of the people who built it; you're taking them at their word that they haven't backdoored it.
And for what it's worth, if I were the CIA in the U.S., you'd bet I'd be leaning on Microsoft to seriously backdoor every piece of software that it sold for military purposes abroad. To them, it's a perfect way to prevent resale to folks that we don't like (or later decide we don't like). Sure, we're friends with the British, but what if the British in 10 years sell a destroyer to the South Africans, who sell it to the Egyptians, who sell it to the Iranians? Suddenly, a way of making it go dead in the water would come in handy. You'd better bet that the folks in Langley, who are paid to be paranoid, have thought about this, too.
Software is inherently different than physical machinery, because while physical devices can be taken apart and investigated, and follow basically well-understood rules (physics, chemistry, etc.), software does not. A large binary blob is as close to indecipherable as a functional object can get, and there's really no way to secure it. It is an inherent risk, and one that I'm not sure many established militaries are putting enough thought into.
Re:Software is far more dangerous than machinery. (Score:4, Interesting)
And for what it's worth, if I were the CIA in the U.S., you'd bet I'd be leaning on Microsoft to seriously backdoor every piece of software that it sold for military purposes abroad.
You might do that, but that's not all you'd do. If I were the CIA, I'd be sure that at least a dozen or so CIA agents with impeccable references applied for jobs at Microsoft, and had back doors in the code and smuggled private stuff out for analysis and all kinds of similar work. I'd also do that if I were the FSB, or Mossad, or any other government intelligence agency. But as Microsoft is in the USA, I'd figure the CIA has an easier time of it.
I'd also have agents at Sun, and Apple, and IBM, and Xerox. This isn't a Microsoft rant; this is just pointing out that "good spy agencies have good spies anywhere machines are made that process important information".
Two things (Score:3, Interesting)
2) All the training and whatnot still doesn't change the fact that you can only get parts from US suppliers for US hardware. Iran is in that situation with the F-14s the US gave them back in the day. They have
Re: (Score:3, Insightful)
Look at Debian on BSD. They're swapping the Linux kernel while keeping the GNU tools and Debian packaging. You could swap
Re: (Score:3, Interesting)
Britain tends to support the unionists who want NI to stay part of the UK. The US tends to support the republicans who want NI to become part of a united Ireland.
Re: (Score:2)
But in my experience, you can tailor a Windows installation to just the most basic requirements and it runs fairly well. I highly doubt that warships would be connecting to the public Internet with the users downloading any number of buggy apps to conflict with mission-critical applications.
In my experience, you don't need to download any buggy apps to conflict with mission-critical applications in order to have problems. Microsoft has plenty of annoying bugs without any Internet connection at all.
Sure, once you get all of the bugs ironed out and the system well-integrated and everything disabled except for what you need, it can run well. But that's true of virtually any modern OS -- Linux, OS X, *BSD.
However, security holes, which are huge in Windows, still represent a huge issue, even wit
Re:Sortof a Microsoft fanboy, but... (Score:5, Informative)
Re: (Score:2)
And there it is, the hidden reason:
They've got to support win-modems!
Wonder how long the phone cord holds up in salt water?
Re:Sortof a Microsoft fanboy, but... (Score:4, Insightful)
(A) Bad hardware
(B) Bad drivers - usually the graphics driver.
The more complicated 3D stuff an app does, especially a game, the more problematic it is in terms of stability, though this is not always the case - many professional apps put a lot more time into getting aroudn these bugs.
On one machine I had, regardless of the OS, if I had high network IO with either high CPU use or high 3D use, it crashed. Changed the mobo, problem went away.
On another, it had not only one of the worst SATA chips out there, but probably one of the worst implementations of said chip. Linux and FreeBSD solved the stability issue by not installing on anything except IDE drives, Windows on the other hand installed, but had issues. A new SATA controller card fixed that.
Yes Windows has issues. But in my old Windows 2000 box, with a Tyan Trinity S1598 based box, K6-III 450 and 512MB of memory, I was regularly getting multi-month uptimes. And I even gamed a bit, though not much.
The point is, as you stated, you
(1) Driver quality is more relevant - I don't know the details but a bad driver is less likely to crash the whole system, in my experience, in FreeBSD or Linux.
(2) Windows is more likely to load up on bad hardware. It's also more vulnerable to issues related to bad hardware.
Note: this is just for 2000 and later (really, in my experience XP is a downgrade on stability, and I can't say much on Vista, though mileage may vary). 9x variants of Windows were crashmonsters.
Re: (Score:2)
Re: (Score:2)
Windows would have one definet disadvantage of *NIX though. Because of the ways you can run various *NIX systems, if something knowcked out the system disk, you could possibly still get a few seconds to minutes of run time out of the system (and if it were specifically planned for, even hours). Windows would be gone in miliseconds.
You do have a point there. And I agree, I'd rather see something than Windows on a military ship (I'd vote BSD
Re: (Score:2)
I'd rather see DOS 6.22 running than windows on a mission critical system. You couldn't do much with DOS but it didn't really crash much when operated within parameters.
I suspect you didn't really mean DOS though, I suspect you meant pre-NT-style windows. I haven't seen NT style windows to be all its cracked up to be. My observations are that security features are more abundent but severe actively
Now try maintaining a lot of them. (Score:3, Informative)
While that may be your experience, if such were the case with the majority, Windows would be far more reliable than it is.
That would be because it should be easy to identify the buggy drivers (your "B") or to use a diagnostic program to stress test the other components (your "A").
In my experience (supporting 100+ workstations), Windows is jus
Re: (Score:2)
As for (B) and stress tests, The trick isn't so much to put a high load in all the time, but to trigger the wrong event in the wrong state, stress tests can easily miss this
How is it worse? (Score:3, Insightful)
Okay, but now explain HOW it is "worse".
Under Ubuntu, if the library isn't in the repository, that single app won't install so you know it won't work.
With Windows, installing a new app causes one or more existing (and previously working) apps to stop working.
Re: (Score:2)
With apt and yum, I've often seen
Package A requires Library X version Y
Package B requiers Library X version Z
and they would *NOT* install simultaniously without fiddling and telling the updaters to ignore dependancies, etc.
Or, alterna
Here's what MSDN says about it. (Score:2)
So you had seen in back with 9x ... but not recently ... even with "hundreds of program installs".
... in MSDN ... talking about DLL Hell and even why it was still a problem in 2005. And it provides help in how to mitigate the problem.
Here's an article from 2005
http://msdn.microsoft.com/msdnmag/issues/05/04/Reg FreeCOM/ [microsoft.com]
Re: (Score:2)
I don't know, I just have not had the issue since 9x. A lot of it is, I think, because many programs have their own local variants of anything they use that tends to conflict with other apps, in their own directory. It's certainly more wasteful than the *nix mindset in terms of space, but space it cheap.
Re:Sortof a Microsoft fanboy, but... (Score:5, Interesting)
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.
Re: (Score:2, Informative)
It should also be mentioned that due to cosmic radiation it's better to use larger circuits instead of those smaller and smaller processes that are used for modern CPUs as that reduces the likelyhood of data corruption through radiation.
Re: (Score:2)
What did you mean here?
Re: (Score:2)
I mean that they moved a load of TTL chips on a circuit board to a miniturized semiconductor that did the same thing.
FreeBSD is up to the task. (Score:3)
The hardware is the weak link in the chain.
Re: (Score:3, Informative)
In the case of military systems I would think both of those problems would be avoided as they are going to be running hardware and software designed specifically for the application and none of it
Re:Sortof a Microsoft fanboy, but... (Score:4, Insightful)
Okay we are talking about embedded systems! The user interface to an advanced missile defence system will not be the same as Word!
Also I pray to God that they don't hire your typical Windows VB programmers for these jobs so that extra training for the programmers is bunk.
The simple truth is that no "off the self" software should be run on these systems. You are not going to run Word or the latest version of Photoshop on your Command and control systems. You can put a great looking user interface on any OS if you want to so the user friendliness of Windows doesn't really matter. The other issue is going with W2K is you are stuck using X86. Unless they want to move to Vista they are stuck using 32 code.
Seems like a bad plan to be stuck with one type of CPU and a near end of life OS.
Solars, QNX, OpenBSD, VMS, Linux, are any number of secure, actively developed, and or real-time capable OSs seem like better choices.
Re: (Score:2)
I don't agree that linux of F/OSS is a bad option, I almost entirely disagree with your last paragraph, however, this is one of the best arguements I have seen in a long time on
Personally I would like to see opensource used more within military and government facilities, I especially think something like rtlinux would be good for this kind of
Re:Sortof a Microsoft fanboy, but... (Score:5, Insightful)
A competent windows admin can harden windows, he can harden it more than an incompetent *nix admin can. But windows simply can't be hardened to the degree that *nix can. With a *nix system you can remove everything that is not neccesary right down to unused kernel components. You will never be able to say that, windows will always have tens of thousands of lines of code with bug potential running that have nothing to do with your application.
The interface is also fairly irrelevent when you are running a single application fullscreen. These aren't desktops.
The problems are EOL and NCW/GIG (Score:2)
These ships will be in operation for decades. Major overhauls are spaced far apart. When Windows 2000 leaves extended support and goes end-of-life, what's the Royal Navy going to do? Ask politely for the source code? And for a few hundred Microsoft engineers to understand it? SELinux or Trusted BSD they just might be able to maintain in-house, if they just have to have an externally developed OS.
>their main connection is a un
Re: (Score:2)
I can see you've not done a lot of research. There are a lot more choices out there than Linux. FreeBSD, for one, is very stable and has been around as long as Linux has. It's also not been plagued by the "release-of-
USS Yorktown & Blue Ridge (Score:5, Interesting)
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 [linuxtoday.com]. The result? The ship was infected with the Melissa Macro Virus. (Source - Section 12.4 [packetstormsecurity.org])
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.
If you'd read the article (Score:2)
Re: (Score:2)
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.
That's always a lie. (Score:5, Insightful)
I find this hard to believe. This sounds like something that you'd hear from someone who had already decided to upgrade.
Their current system works; therefore, it is inherently superior to any new, unproven, new system. There should be a huge barrier to upgrading with anything, because you're replacing a devil you know with a devil you don't. The new system should have to have demonstrated credentials in other similar situations, proving that it's at least as capable as what it's replacing. Things like ease-of-use and training should all fall under the system's core purpose.
I've seen companies replace "legacy" systems because some manager walked out onto the production floor / cube-pit and was horrified to see green-screen terminals sitting around. To them, terminals = old, old = bad, end of discussion. So they would come up with reasons to upgrade, and say things like 'well, it couldn't be worse than what we have!' with complete neglect for the fact that the old systems, by virtue of having been there for a long time, clearly did their job.
And, bottom line, it's a lot easier to train someone on a complicated green-screen system that always works, than on an unpredictable new system, where you have a ton of gotchas and error modes. Generally, once you get everything worked out, and people know what things they just can't do because it'll crash the system, you haven't really simplified anything. I have personally seen tens of millions of dollars wasted on 'upgrades' like this, where the result was so much worse than the beginning, that it immediately rolled into a new cycle of upgrades -- the executives believing, like deranged poker players, that as long as they had tossed that many millions into the pot, that they would surely solve it with a few million more.
This sounds like the same thing is happening; someone freaked because the equipment and software is old, but didn't realize that there's no logical reason why something that's old is necessarily bad, if it's still doing it's job. "Anything is better than this" is always false if what you have right now gets you through the day and does its job. Unless the system you're implementing has a strong track record of doing the same job elsewhere, you have nothing besides a salesman's promise that it's going to be better. And remember: at the end of the job, that salesman is going to disappear, and you're going to be stuck using whatever is left.
I heard it from reading (Score:3, Interesting)
Dangerous assumption. (Score:2)
Re: (Score:2)
Which is why they're presumably using a heavily locked down version of Windows 2000 Server with no Internet access.
Re: (Score:3, Insightful)
Re: (Score:2)
These aren't corporate desktops. The military are not stupid enough to make such attacks easy.
Re: (Score:2)
Safeguards intentionally disabled, it was a test (Score:4, Insightful)
You are mistaken. Safeguards were intentionally disabled.
The truth is that a server app corrupted it's data, a client app tried to use that bad data, and the client app failed to control equipment. Can happen with any OS. Add to this the fact that the ship was a test platform not an operational ship and they were trying to break things.
"Others insist that NT was not the culprit. According to Lieutenant Commander Roderick Fraser, who was the chief engineer on board the ship at the time of the incident, the fault was with certain applications that were developed by CAE Electronics in Leesburg, Va. As Harvey McKelvey, former director of navy programs for CAE, admits, "If you want to put a stick in anybody's eye, it should be in ours." But McKelvey adds that the crash would not have happened if the navy had been using a production version of the CAE software, which he asserts has safeguards to prevent the type of failure that occurred."
http://www.sciam.com/1998/1198issue/1198techbus2.
"McKelvey writes that the failure, "was not the result of any system software or design deficiency but rather a decision to allow the ship to manipulate the software to stimulate [sic] machinery casualties for training purposes and the 'tuning' of propulsion machinery operating parameters. In the usual shipboard installation, this capability is not allowed.""
http://catless.ncl.ac.uk/Risks/20.37.html#subj1 [ncl.ac.uk]
Re:Safeguards intentionally disabled, it was a tes (Score:5, Insightful)
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.
You need responsiveness and stability (Score:2, Insightful)
At the very least, a DIY linux bundle would be a hell of a lot better than Windows. But even Linux isn't realtime.
Is there DRM for radar/sonar devices?
Tom
Re: (Score:3, Informative)
Re:You need responsiveness and stability (Score:5, Funny)
Realtime support has been included in the mainline kernel for almost a whole four months now. I can't fathom why they aren't already using it on warships...
Re: (Score:2)
Realtime support has been included in several distributions (free and paid) for some time, the RTLinux project has been around since 1998. My understanding is that, for the most part, large changes don't get included into the mainline kernel until the've been independently proven to work without significant problems.
Re: (Score:2)
I only said it was realtime, not that it was currently stable. I'd actually agree on using a tried and tested RTOS, that's specifically has been built to be a RTOS, and not something that has been built to be a generic OS with RT enhancements bolted on afterwards.
You sunk my battleship! (Score:2)
"Wargames" All over again? (Score:2)
Oh Oh! (Score:5, Funny)
Well... (Score:2, Funny)
"sanest and balanced"? you're joking (Score:5, Insightful)
Take non sequiturs such as "Windows may be unreliable, but it's hard to imagine it being as failure-prone as the kit which is out there already." This logic may suffice for a lightweight Register article but it's no way to justify picking the worst available consumer grade O/S over proven systems such as Solaris, OpenVMS, or other far more reliable alternatives.
The Reg ran a better article [theregister.co.uk] in 2004 - which actually quoted dissenting engineers (who were immediately fired, go figure).
Should we laugh, cry, or protest?
Re: (Score:2, Funny)
Re: (Score:2)
Not enough Fear Uncertainty and Doubt for you?
The 2004 article was a piece of crap. "You could get infected with malware by browsing to a nasty web site." Um, yeah, assuming that the security configuration would be completely and totally wide open, and the ship's internal systems would be used for visiting Pr0N sites, then yes, it could.
By the same logic, submarines should
We should laugh (Score:2)
Blue Screen! (Score:2)
Microsoft War 2007 (Score:5, Funny)
I really don't know where to begin... (Score:5, Funny)
System: Are you sure that you want to go out into open waters? Your ship could be the victim of a denial of territory-attack!
Operator: Yes. Raise the anchor.
System: Double the killer delete select all?
Operator: Enemy ship spotted. Fire at will!
System: Before you can continue, system needs to be rebooted. Restart now?
Operator: Activate sonar.
System: Before you can proceed, we need to ensure that you are running Windows Genuine Advantage. Please proceed. We will send all of your hardware info to Microsoft. Information will be treated anonymously.
Etc etc.
makes about as much sense as... (Score:2)
Hot cha cha cha cha!!
Read the Article (Score:2)
back to the future .. (Score:2)
No one in their right mind would use a desktop PC to operate a warship. The decision to go with Windows was a political and financial one and made in opposition to criticism from BAE's own engineers.
'A specialized, stripped-down, offline version of Windows 2000 is going to be stable and secure'
Why are they using seven year old technology. Why not upgrade to Vista. Actually, now that I think of it, the WinTel 'computer' also has a number of failure modes, like forgetti
Not the Win2K you may have (Score:4, Insightful)
As for the articles description of some of the systems out there that are being used by the militaries of the world. It's pretty accurate.
I had a Vic20 that had more power than some of the systems still out there.
I knew IT! (Score:2)
I would have thought it would have taken longer for Microsoft to get to this point but,
"Now I need a freaking Battleship with a Nuclear reactor to run Windows!"
Don't they call them portholes? (Score:2)
Well, if this doesn't pan out they could always use that agreement with SuSE and release Naval Linux...
The Culture beat the royal navy to it. (Score:2)
LSV Your system needs to be restarted
GSV Click here to start
And the latest and greatest:
ROU, Cancel or Allow, psychopath class
( http://en.wikipedia.org/wiki/List_of_ships_(The_C
Embedded training software: (Score:2)
huge amount of unrelated code .. (Score:2)
I beg to differ, is any kind of server OS suitable to the task. How about a distributed system running on embedded hardware with multiple 'failure modes' and communication channels. And I don't mean code running from a rom, something like small independent devices running as finite state machine with known predictable behavour. That way when a shell blows a hole in you
welcome to the weird and wonderful future (Score:2)
one wonders what someone like jules verne or isaac asimov would have thought of such a world
or imagine telling a naval commander in the days of the dreadnought [wikipedia.org], those undisputed impenetrable ocean fortresses they were, that in the future, some teenager pecking at a typewriter in front of a cathode ray tube type device a continent away could magically disarm his entire fleet
it truly boggles the mind, and yet it is the reality we find ourselves in today
if life seems munda
Forgive the potentially stupid question... (Score:2)
Too expensive? Time consuming? Difficult? Why haven't they just done that...?
Obligatory joke (Score:2)
Yes.
"This is a potentially dangerous action. Are you sure you want to contine?"
Yes.
Good idea for usability...but with caveats. (Score:4, Informative)
Windows does have a closed-source kernel, but it does have the advantage of hosting a user interface that even the most basic-knowledge recruit will know. Windows is on 90+% of the world's computers, and absolutely every younger person knows how to navigate around in it.
Here's a parallel example from my line of work...the airline business. Lots of carriers have systems that were designed 20-30 years ago. Most have GUIs slapped over the top of a terminal emulator, but even those are cryptic. Some airlines send their customer service agents to a month of training just to get them to memorize the key parts of the system. I would imagine military systems of the same vintage are even more complex, and force a serviceperson to endure many months of training. Training, by the way, that will prove useless in the real world.
I'll bet the defense contractors designing any Windows-based system have full access to the kernel source anyway. Also, don't forget that stuff designed for the battlefield isn't exactly slapped together by a bunch of new graduates who picked up a ".NET for Dummies" book.
Microsoft certified Missile Launcher .. (Score:2)
'I would imagine military systems of the same vintage
You have got to be kidding. I don't know about you, but I want someone in control of nuclear missile launches to have a tad more than two weeks training in filling in check boxes.
Microsoft Windows Vista -- Warship Edition (Score:5, Funny)
Beware the Dateline, Daylight Saving, & go Vir (Score:2)
Don't fight wars where they observe Daylight Savings Time.
And run a hundred copies of your battle software as virtual machines, so that if one crashes you've got 99 hot standby's to switch to.
That's the way industry goes (Score:4, Insightful)
I worked as an intern for a big company in the power protection and control field (i.e. power substation automation). It's not warship control and if something fails probably no-one is going to be killed, but things will break and money will be lost.
They had some in-house software to program the protection and control devices. That software could also be run under Windows for testing and debugging purposes. I worked on a prototype of an extension of said testing and debugging environment, so I have a bit of experience with this kind of embedded-ish real-time Windows programming, and I must say that Windows is definitely not the way to go for anything like that. It just lacks the flexibility of operating systems made for this sort of task.
Later I found out that what they actually wanted to do is to replace the special-purpose systems with the simulation and debugging environment, all running on Windows because it was supposedly much easier to use and what not. They're going to use my prototype to do so :-(
I have the impression that Windows is often chosen for this sort of task because management knows it and has the feeling that "Microsoft is the real thing", that it is easier to find experienced developers for Windows than for any other platform and that the development tools are better and/or more user friendly. While I agree on the last two points, I'd like to point out that "experienced Windows developer" does not mean experienced real-time, high-reliability-systems or embedded developer, and that the development tools are mostly focused on GUI/Network service programming which is what windows is mainly used for.
I'm sure there are lots of people out there with way more experience in this field than me, but if I were to decide for an OS on a warship it would definitely not be Windows, Unix or any other general purpose OS, but something which can be customized and is built for this kind of task - VxWorks or something similar.
Worrying trend... (Score:2)
Because "everybody else is doing it".
It's what you get when you let non-technical people make technical decisions.
Trident FUD (Score:5, Informative)
And the 98/1 is incapable of running Windows without a ground up rewrite - it's a (IIRC) 24 bit machine with an architecture that is (to put it mildly) wildly different from a PC.
The line "We're starting to search really hard for things to panic about here." from TFA could more accurately be written "We're writing nonsense here without actually having a clue" - which makes one wonder about the veracity of the remainder of the article. Especially since on a mailing list for sailors and naval professionals (of many nations) I am on, many things about US and UK kit are discussed - but the massive reliability issues TFA brings up (handwaves) are notable by their absence.
The bit in TFA about paper charts is especially telling - because any experienced and knowledgable sailor knows those charts have been retained on purpose. Charts don't crash - and the vast majority of the time they are more than sufficient to the task.
From TFA:
More pure FUD - because having a high tech navigation system is no proof against crashing into things. Witness the recent grounding of USS San Francisco - caused by a combination of operator error and a bit of seafloor being less than accurately mapped. (Much of the Earth's water is poorly mapped by modern standards - including harbors!) Equally, consider the hundreds of times a year the RN *does* move in and out of harbor without crashing into things.
I could go on - but I can summarize fairly succinctly; The author of the Register article not only appears to know very little about Naval matters, but he appears to have learned what he does know from USENET trolls and Slashdot. The biography appended to the article indicates he spent his time in EOD - not someone I would expect to be knowledgeable about ship operations. It also reveals he wrote a book detailing the problems with the procurement system - whose Amazon reviews show to contain a systemic bias againt BAE.
My qualifications? (Since the question will come up.) 10 years in the USN Submarine Service working with the MK88 and MK 98 Trident Fire Control Systems, as well as 30 odd years of studying naval technology and issues.
Mad. (Score:2)
I can see it now. While at sea every PC suddenly displaying following message:
TO CONTINUE PLEASE DOWNLOAD WINDOWS GENUINE ADVANTAGE AND AUTHENTICATE YOUR COPY OF WINDO
to be fair to the Navy... (Score:5, Informative)
Having said that, while I worked on these projects, at the same agency the FIST project was getting under way (a project to equip infantry with personal computer/weapons systems, with HUD in-helmet). At least in our part of the business, it was a standing joke because it ran on windows (95, I think) and kept crashing (our team was using Solaris at the time).
US Navy... (Score:4, Informative)
Sometime in the early 90s, many of the west coast fleet had adopted a WindowsNT based system dubbed "IT21" (Information Technology, 21st Century). If I recall correctly, SPAWAR (a US Navy owned Corporation), was a considerable driving force behind deployment. Most of the use for this IT21 system was for console/end-user use. And not necessarily used for firecontrol, navigation, tactical displays et al. Thank god, but this system was plagued from the get go. Sadly, many of those who go to work for SPAWAR aren't really bright as too many are old retired Navy Chiefs and Officers riding it out in a nice, secure job.
Side Note: What SPAWAR should be doing, is to aggressively recruit military personal on their way out of the armed forces. All military forces go through a lot of debriefing for those deciding to not re-enlist or continue their commission. A lengthy "education" effort, that gives us more than two weeks of "What benefits you get from the VA", "Your rights as a Veteran", "Montgomery GI Bill and how to use it"... et al. But, they don't... I never saw a SPAWAR rep asking any of us if we would like to apply--(since we are technically active military, initiate a "agency" transfer request from one to another.)
Back on topic. The entire network was a mess. And the fact it was Windows didn't make it any cleaner. BDCs, PDCs... crashing right and left, half the time entire decks (which is a big deal on an aircraft carrier) were offline. But, one very disturbing thing is...
A (once upon a time) friend and I compromised the entire Windows based network. Because I had (and still maintain) a clearance, oh boy, it was an issue that had me pretty nervous. Nevermind the details of this. Let us simply acknowledge that the US Navy doesn't have a sense of humor!
The entire infrastructure for the IT21 system was infested with numerous security issues. Not exactly the problems of those designing the network because most of the problems were due to Microsoft Software and recommended or required services to accomodate the design requirements.
Is it still as bad? Unless the Navy has flipped upside-down, delcare the aft end of a ship the front... IT21 system is likely still being used. Admiral... whoever at the time also pushed the issue in an effort to update the technology used by the sailors in the Fleet. (While the Navy always had impressive R&D, and neat technology buried deep within implementation. Most of the sailors were still using 486s on the desktops, which makes the Navy seem "out-dated" regardless if they actually were. Let's face it, a sailor to do his job still doesn't need much more than a 486 for most of them. In any case, as with a General, an Admiral makes a demand a billion other hopeful high-ranking personell will use their power to "suck him off in hopes of getting recommended to 'Flag'". Things get done, whether for the best or the worst.
There wasn't many computers on our Carrier we didn't have full access to. From the unix servers down in the RM (Radio Man) space, to the skippers personal IT21 desktop in his room.
BTW, we got off scotch free. And the speed in which we compromised the network could cause nose-bleeds. The network was so bad, that half the time (for the only reason we compromised the network), we ended up having to play "Admin" and fixing things (including making things more secure.) so we could do what we wanted.
Re: (Score:2, Funny)
Just have your CC# ready when you call in for support.
As long as the problem isn't with the weapons system then I think Microsoft would have a good incentive to provide support free of charge ;)
Re: (Score:2, Funny)
"+1 Direct Hit"
Re:Zzzzzz... (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)