Slashdot Mirror
Tux Enlisted for U.S. Defense Program
An anonymous reader writes "Linux is a key part of the Army's massive $200B FCS (Future Computing System) initiative, it seems. RTOS vendor LynuxWorks was chosen to provide the OS for 18 weapons platforms under development, because its LynxOS-178 real-time OS can run Linux binaries -- including the "common operating environment" that Boeing is developing for FCS."
...this paper talks about using the open source, BSD-licensed agent framework COUGAAR to run FCS modeling tests.
Also, there's a bunch of COUGAAR support software written in Ruby, i.e., ACME.
The Army reading list
Nothing says "feel-good bluegrass tech movement" like becoming part of the military industrial complex.
- Rory [Microsoft Employee] | Free dirt: neopoleon.com
That is all.
Colonel Panic: Not just a reaction to incorrect artillery coordinates anymore!
Do you like German cars?
No more so than cars, truck, aluminum, steel, or coffee is. All of which is used by the military around the world, for good or evil.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
LynxOS is older than Linux. Development on LynxOS began in Dallas, TX in early 1986. The system was built for the 68000 architecture originally, targetting a custom-built 68010 VME bus CPU. The software was compiled with the C compiler sold by Megamax for the Macintosh. LynxOS was ported to the IA86 for the 386 in 1988-1989. The LynxOS ABI compatibility history goes back to about 1989 also, when SVR3 compatibility was added to the system. No UNIX or (of course) Linux code was used in the development of the OS.
Well, BSODs are pretty much a thing of the past, at least unless you have a defective hardware.
That said, when Windows is used where formerly an embedded OS is used, there is a tendency not to do a very good job stripping out all the stuff that's not needed. Since you aren't going to be patching things that much in the field, this could lead to known security holes on deployed systems for a long time. It may not matter, indeed usually the excuse is that it won't matter, but sometimes the unforseen happens. It's not unheard of for "embedded" versions of windows to have problems like windows file sharing turned on. The hardware engineers don't think like sysadmins.
This problem is not intrinsic to Windows; I've seen the same thing recently on a box that controlled an under vehicle scanner. It used stock SUSE with an old verison of BIND and samba, trhe3 works. The customer wanted to connect it via wireless to a central guard station. This was a bad idea. The security holes in the box are harmless as long as it is stand alone, but on a network they are huge liabilities.
At least with Linux, you can go the Linux from scratch route, which minimizes you exposure to security holes in ancient software.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
In a letter to the "Comment and Discussion" department, published in the Aug 98 _Naval_Institute_Proceedings_, page 22, Captain Richard T. Rushton, then-CO of _Yorktown_, categorically states, "The _Yorktown_ was never towed as a result of any Smart Ship initiative. During my command, we lost propulsion power twice while using the new technology. Each time, we knew what caused the interrupt and were underway again in about 30 minutes. The September 1997 incident was caused by incorrect data insertion by a well-trained crewman. The _Yorktown_ returned to port using two FFG-7 emergency control units that specifically had been requested by me, and supported by other commands as a risk reducer. We knew there were some risks in the engineering development model propulsion-control system installed under a rapid prototyping development effort. The bottom line: The data field safeguards found in production-level systems were not installed yet in the _Yorktown_ by intention, until complete wring-out was accomplished."
Further: ... She went on to execute a five-month Caribbean deployment that included extensive Smart Ship assessments by the Operational Test and Evaluation Force and Navy Manpower Analysis Center. Both organizations evaluated the _Yorktown_ as fully capable in meeting the required operational capabilities in a projected operating environment. ..."
"The _Yorktown_ never missed an operational commitment, nor did she suffer a mission-degrading casualty during the Smart Ship assessment period. During that time she certified to deploy under the normal fleet training and assessment process.