Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
United States Software Linux Technology

Tux Enlisted for U.S. Defense Program 312

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 discussion has been archived. No new comments can be posted.

Tux Enlisted for U.S. Defense Program

Comments Filter:
  • by Aggamemnon ( 809791 ) on Monday April 11, 2005 @10:40AM (#12200302) Homepage
    As far as I know, the Royal Navy is still considering NT for the Type 45 - maybe this will help to change their mind.
  • by freeio ( 527954 ) on Monday April 11, 2005 @10:45AM (#12200360) Homepage
    At that price, supporting free software is a mixed bargain if I ever heard of one. Note that it supports Linux binaries, but it is not Linux as we know it.
  • by advocate_one ( 662832 ) on Monday April 11, 2005 @10:53AM (#12200441)
    expect a sharp ramp up in anti Linux/FOSS lobbying from Microsoft via supposedly worried parties... all worried about the US's defence being trusted to a "commie OS" written by "hacker"s and other "hippy" malcontents...
  • by iggymanz ( 596061 ) on Monday April 11, 2005 @10:55AM (#12200466)
    We already have military equipment running Windows. And this article isn't even about using the Linux kernel or a Linux distro, just an API on top of LynxOS. So what you said could be said about the military's use of any operating system x, what if someone develops a virus/trojan/exploit on x?
  • by Big Mark ( 575945 ) on Monday April 11, 2005 @10:57AM (#12200478)
    No, it's a real-time OS that can run Linux binaries. Linux isn't really a real-time OS, although there's been a lot of hackery recently to change this.
  • by Darkon ( 206829 ) on Monday April 11, 2005 @10:59AM (#12200505)

    Wouldn't it piss off SCO no end if someone produced a scorun app?

    They already did [demon.co.uk], and as I remember SCO were mighty pissed off [computerworld.com.au].
  • Re:Yay, no BSOD (Score:5, Interesting)

    by hey! ( 33014 ) on Monday April 11, 2005 @11:03AM (#12200528) Homepage Journal
    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.
  • by rpdillon ( 715137 ) on Monday April 11, 2005 @11:22AM (#12200715) Homepage
    Yes, but they're not just using LynxOS. They're also using BlueCat Linux, which I'm a bit worried about. I called Lynuxworks asking them if I could have access to the source code once I got my hands on the BlueCat distro. They put me off, didn't return calls, and told me they couldn't discuss that with me at "this time." I'm not saying they won't give it to me, but they're not being forthcoming, either.

    Combine this with the stunt they pulled with User Mode Linux (see this story [usermodelinux.org]) in which they used GPL'ed code, and submitted their changes back in an uncompilable tarball (no patch), and I'm getting pretty suspicious. After working out what changed and generating a patch, the UML team still couldn't make their changes compile. Presumably, Lynuxworks could (would good what the changes be unless they compiled?), so this again would indicate a violation of the GPL.

    I'm hoping FCS switches back to looking at Red Hat - at least they have a track record. When I found out FCS was using Lynuxworks, my first reation was "Who?"

  • Re:ARPA-NET (Score:5, Interesting)

    by dpilot ( 134227 ) on Monday April 11, 2005 @11:24AM (#12200757) Homepage Journal
    Thinking about this for a minute...

    What we're REALLY talking about is blue-sky, no immediate payback, research. That is, research with a true eye to the future, not the next quarter or two, the kind of research that got us where we are today. That's the realm of deep pockets and minimal (or at least enlightened/tolerant) oversight - by stockholders or congressmen. That's also the kind of research that has been all-but-destroyed in the US by beancounting, be it corporate finance types, stockholder expectations, Congress, etc.

    The US could well be moving in to an era where the only true research, the long-range stuff, goes "black" - "I could tell you, but then I'd have to kill you."

    For another perspective, see:
    http://technocrat.net/article.pl?sid=05/04/1 0/1312 50&mode=thread
    Then combine it with the fact that there are others who DO see the value of long-term research:
    http://technocrat.net/article.pl?sid=05 /04/10/1392 50&mode=thread
  • by alhaz ( 11039 ) on Monday April 11, 2005 @12:24PM (#12201529) Homepage
    Only a really topheavy organization can make this kind of mistake.

    The compatibility ABI isn't going to pass muster when it hits the QA phase, they never do. You can't realistically develop an application for one OS and expect it to work perfectly on a "compatible" OS.

    When developing vertical applications like this, it's most wise to develop for the actual physical installation that it's going to end up running on. Not just the *version, the actual functioning OS image that will ultimately be used.

    There's a term for what this is gonna end up being. The first part is cluster and the last part rhymes with truck.

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Working...