Slashdot Log In
Windows For Warships Nearly Ready
Posted by
Hemos
on Mon Feb 26, 2007 11:19 AM
from the like-windows-for-workgroups-with-guns dept.
from the like-windows-for-workgroups-with-guns dept.
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."
This discussion has been archived.
No new comments can be posted.
Windows For Warships Nearly Ready
|
Log In/Create an Account
| Top
| 387 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
Sortof a Microsoft fanboy, but... (Score:5, Insightful)
(http://www.unanimocracy.com/about.html | Last Journal: Tuesday April 04 2006, @12:04PM)
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. ;-)
But It's Still Software From Another Country (Score:5, Insightful)
(http://slashdot.org/~eldavojohn/ | Last Journal: Tuesday October 16, @03:26PM)
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.
Software is far more dangerous than machinery. (Score:5, Insightful)
(http://kadin.sdf-us.org/ | Last Journal: Tuesday October 16, @01:46PM)
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".
Why the British don't make computers (Score:5, Funny)
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:Sortof a Microsoft fanboy, but... (Score:5, Informative)
(http://www.biochem.ucl.ac.uk/ | Last Journal: Thursday November 01 2001, @09:11AM)
Re:Sortof a Microsoft fanboy, but... (Score:4, Insightful)
(Last Journal: Tuesday February 06 2007, @09:13AM)
(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:Sortof a Microsoft fanboy, but... (Score:5, Interesting)
(http://www.intelligentblogger.com/ | Last Journal: Monday August 27, @11:47AM)
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:Sortof a Microsoft fanboy, but... (Score:4, Insightful)
(http://www.gemstate.net/friends | Last Journal: Tuesday September 11, @10:32AM)
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:Sortof a Microsoft fanboy, but... (Score:5, Insightful)
(http://www.ganjablogger.com/ | Last Journal: Thursday January 05 2006, @05:36PM)
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.
USS Yorktown & Blue Ridge (Score:5, Interesting)
(http://www.intelligentblogger.com/ | Last Journal: Monday August 27, @11:47AM)
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.
That's always a lie. (Score:5, Insightful)
(http://kadin.sdf-us.org/ | Last Journal: Tuesday October 16, @01:46PM)
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.
Safeguards intentionally disabled, it was a test (Score:4, Insightful)
(http://slashdot.org/)
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)
(http://www.intelligentblogger.com/ | Last Journal: Monday August 27, @11:47AM)
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.
Re:You need responsiveness and stability (Score:5, Funny)
(http://evil.google.com/)
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...
Oh Oh! (Score:5, Funny)
"sanest and balanced"? you're joking (Score:5, Insightful)
(http://www.telegraphics.com.au/ | Last Journal: Tuesday November 06, @03:35PM)
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?
Microsoft War 2007 (Score:5, Funny)
(Last Journal: Thursday June 28, @08:26PM)
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.
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.
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 Windows Vista -- Warship Edition (Score:5, Funny)
That's the way industry goes (Score:4, Insightful)
(http://www.isotton.com/)
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.
Trident FUD (Score:5, Informative)
(http://derekl1963.livejournal.com/)
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.
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:Zzzzzz... (Score:5, Insightful)