Slashdot Mirror
Windows For Warships Nearly Ready
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 is probably a positive step, in many ways. As the article shows, the previous software was terrible already. Military research and development may seem high tech and modern, but they are one of the most inefficient organizations imaginable -- tons of ancient embedded programs trying to integrate with one another. I can't imagine being a "new" programmer in the military and trying to comprehend what decades of previous programmers were trying to do, let alone keep it working.
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.
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.
Javascript + Nintendo DSi = DSiCade
Hopefully we will not be in the middle of a war when Patch Tuesday rolls around!
at least we know it's already for the Minesweepers.
How long until the "Blue Screen of Death" (BSOD) has a somewhat more ominous (and literal) meaning?
This article is infantile puffery, something that's obvious from the style.
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 in 2004 - which actually quoted dissenting engineers (who were immediately fired, go figure).
Should we laugh, cry, or protest?
you had me at #!
Hi, it appears that you are trying to fight a battle, would you like some help? *shudder*
"No freeman shall ever be debarred the use of arms." -- Thomas Jefferson
...with this one
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.
Three rings for the Elven-kings in the sky
Waht makes me Zzzzzz is everytime I read a slashdot article, I come across comments trying to predict what the other commenters (by implication, those others are less intelligent than the poster- pointing out stupidity in others in an attempt to make him look smart by association). I prefer to read posts about the subject on slashdot, rather than posts about slashdot, especially when they have the irritating smug tone of "Oh, look at all the losers and their oh so predictable posts. I'm glad I'm far more intelligent than the unwashed masses!" And, yes, I am aware that I don't have to read any posts here, and that I have not only read one of these pointless posts but replied to it.
Mod parent up!
Mod Parent up.
"+1 Direct Hit"
Proof by very large bribes. QED.
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. There was also criticism 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.
My work here is dung.
Actually, Linux IS realtime. But most people don't use it that way, and I'm not sure if there are that many applications really using the realtime extensions...
I have a really elegant proof for Fermat's last theorem. If this sig was only a bit longer...
I doubt very much that this is the Win2K that you may have bought for your desktop. Many companies make products for consumers that differ greatly to those made for the military, police, and other services. My suspicion is that this is a highly customized install that will be considerably more limited and specialized. And yes, far more stable. The details of the customization, will no doubt, not be available to the press or public (and nor should they be).
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.
Actually, Linux IS realtime. But most people don't use it that way, and I'm not sure if there are that many applications really using the realtime extensions...
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...
This guy's the limit!
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 just arcane. Following the exact same install process with the exact same install CD's will give you different results on different machines (same make and model)
Then we get into the whole concept of the Registry and DLL Hell and so forth. Un-installing an app may not get rid of all of the crap from that app and so you'll have stuff just sitting around waiting to trigger a crash. And different versions of DLL files overwrite each other so re-installing may fix app A, but break app B.
Troubleshooting on Linux is so much easier and faster. Which is one of the reasons I prefer Ubuntu (or vanilla Debian).
No internet access is irrelevant. The fact that a system like that is vulnerable AT ALL to common viruses is a recipe for disaster. Consider: Someone who doesn't like the current direction the ship is going bringing in his USB pen drive and launching a virus across the ship, taking control of it or just disabling it. While this could potentially happen with a custom designed OS, without the specs, interface calls, and knowledge of the system and how to compile for it, you aren't going to be writing many viruses at all for it. Even the potential for ACCIDENTAL infection makes it highly undesirable to have a common OS at the core of your battleship.
Obviously, this was caused by the fact that the Yorktown's control software was of a really bad design.
h tml
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
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.
Which would indicate that it was a software bug if that behaviour was documented or known.
Such would be a hardware bug if such was not documented and behaved differently in different pieces
You'd know that Win2k, however bad, is far better than what they have now.
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.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
They haven't found a way to make them leak oil yet!
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
Putting all the blue-screen jokes aside, this might be a good thing.
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.
the article. Scroll down to Big step forward and read the bit "anyone who has spent time in an RN warship is entirely accustomed to seeing equipment on which he may depend for his life occasionally throw a double six for no good reason. Windows may be unreliable, but it's hard to imagine it being as failure-prone as the kit which is out there already."
Best Slashdot Co
Given Britain exports a lot of defence technology, use of foreign machenary is not that big a problem to many nations
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.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
"You are about to launch a missile at your enemy. Cancel or Allow"
bork bork bork!
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.
There are a lot of ways that a compromised OS kernel could cause problems. It's never in complete isolation from the outside world.
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 just not the sort of thing you'd want to bet on; you're letting somebody else, presumably untrustworthy, write and compile the kernel code that runs on the bare metal. From that point onwards, you can't trust anything that the computer does. Unless you're keeping it inside a walled VM and inspecting every bit of data that it gets passed, you're vulnerable (and even then, you're just pitting yourself against the people trying to pass it some specially-crafted data to trigger the exploit).
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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.
Javascript + Nintendo DSi = DSiCade
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.
I used to work in this field (supplying software to the Navy, for use onboard warships), and the one thing I can state from my time working with people in the Navy is that they're definitely more interested in things working than in things looking good. I don't know the background to Windows being chosen, but if it was a decision made by the type of people I used to work with/for (I worked for a Navy supplier, so HM Royal Navy was in effect our client), having fancy popup messages and nice-looking GUIs won't have been anywhere near their top priority. This isn't the sort of thing that gets rushed - it's likely to have taken months if not years to come to this decision. The article's mention of outdated technology is pretty accurate - and it is because that technology has a history of doing the job well. Of course, if the decision to use Windows was made by politicians or economists...
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).
You need to turn on Windows Update, bro. This joke was patched years ago. The new Virtual Laugh Machine doesn't provide backwards compatibility for 10 year old jokes, so you'll have to pick between one of these new options:
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.
1) MS source is not a black box. Many institutions have copies of it. No, it's not open to every person in the world but it isn't this amazing trade secret. Many major universities have it (ASU is one I know of) and I'm sure as part of this the British government has it as well, if they didn't already.
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 very few that are operational as they've had to strip them for parts since they can't buy replacements.
I'd beg to differ... Free/Net/OpenBSD are more then ready for a task like this. The 4-STABLE branch of FreeBSD is rock solid, If some enterprising company came along and formally audited the code, got it DO-178B level A certified, and provided maintenance and errata fixes they could make a mint. They can also provide the source code to their clients if they want to audit the code.
The hardware is the weak link in the chain.
Northern Ireland perhaps?
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.
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.
Because they have Lucas regrigerators!
It is cowardly, and a betrayal of whatever it means to be a Jew, to act as a white man
-James Baldwin