Slashdot Mirror

there's nothing inherently wrong with using proprietary communication protocols, especially when they're being used by a for-profit company.

That's where you're most completely wrong. Using a proprietary protocol is absolutely inherently bad. Especially if you're not in big business, but the millitary. I don't have time/space here to fully explain (but the links give clues), and others have written volumes.

practical reasons to not use this software do include the presence of DRM

Neither X_Bones nor Saeed al-Sahaf has given any explanation as to why DRM is impractical. In another thread it was pointed out that Saeed al-Sahaf's reaction to DRM was hardly more than an ingrained revulsion to a hated acroynym. (He immediately Godwinned)

I can think of one reason why DRM might be a negative (beyond the fact that it implies a proprietary protocol), and that is that it probably won't completely work. Users expecting protections that aren't really there may put themselves at risk. But maybe you can give some better reasons.

lot of money for something you yourself said could be done in an hour

In case you didn't pick up on this, Groove is bloatware, and only 15% of its features are needed by a normal user.

Here, I'll write one line that encompasses 60% of the features an average user needs from Groove.
25 6 * * * user rsync -e ssh user@ourproj.dyndns.org:/home/gruv/data ~user/gruv/data;chmod -R -w ~user/gruv

The other 40% functionality can be accomplished by 20-40 more lines. But of course then one more challenge is faced: convincing the network admin to allow ssh traffic. If he's smart this is already done, but if he's stupid it's impossible. So then one must turn to one of the many how-tos explaining how to pierce overly-restrictive firewalls. (It's quite funny that the main reason people are installing Groove is that it subverts their firewalls)

(even though the necessary tools are freely available on that platform, and better yet aren't tied to it)

First, I think I'd need an actual Microsoft Windows, which is non-free (and in fact 299 dollars). The .Net 7.x compiler system is also rather pricey, but I could squeak by with gcc prehaps.

But then for every other user, the necessary additional tools are sshd, crond, and python. I could convince an average Windows user to install maybe one of those, but not all of them.

Unfortunately, this kind of thing still starts in the military world. The DoD has been developing requirements for Network Centric Warfare (NCW). Basically turning warfare interfaces into a RTS game like StarCraft, C&C, complete with fog-of-war, semi-autonomous units, comm & data sharing, etc. On the technical side, this is manifesting itself as Command, Control, Communications, Computer, Intelligence, Surveillance and Reconnaissance (C4ISR) architecture. One of the first actual implementations is being worked in in the form of Future Combat Systems (FCS).

These are complex systems, so the DoD has been maturing development of modeling & simulation interoperability by making contractors adhere to High Level Architecture (HLA) so they can properly analyze these systems before deploying them. HLA basically provides a lot of the same data object registration, distribution, and interfaces that older tech like CORBA does, with extra simulation concepts.

These technologies are being commercialized under the buzzwords "Nework Centric Operations" (NCO) and "Network Enabled Operations" (NEO). Advocates usually point to well networked operations like Wal-mart, UPS, et al. as poster children for what could be done (automatic restocking, package tracking, load balancing & route optimization, etc.) with enough NEO infrastructure. A lot of the interchange standards (including C4ISR) are getting established through bodies like the OMG. Other than the interchange standards, there's not all that much new tech involved... maybe RFIDs and various other networking tech (grid/mesh networks, strong encryption/authentication, mobile IP, etc.). Most if it just involves looking at technology that already exists and figuring out how to piece it together to actually do something worthwhile.

Disclaimer: I work for one of the gov't contractors throwing all these buzzwords around.

4 comments in one:

1. Why Linux?
True, the eetimes article is discombobulated and provides little explanation of why Linux should matter at all for wargaming simulations. And the explanation it implies (that Linux helps data compatibility) is nonsensical.

However, I've seen several military simulation projects that run on Linux. The obvious reasons: The Pentagon isn't a fast or flexible software developer. These games may take decades of to produce and shape into something workable, and we can't throw them out just because new OSes (Windows XP, etc) come along.

So many projects that were first written for big iron SGI or Solaris machines are now running on Linux desktops. I've heard several ancedotes of software getting a 5x speed boost alongside a 10x drop in platform cost when changing hardware vendors from SGI to Dell.

One major simulation project is OneSAF ("One Semi-Automated Force"). You can go read the PowerPoint they gave at a Linux conference years ago. (The "CCTT" project mentioned in the article is an ancient fork of OneSAF)

2. 100 entities is small
The article says they will be reaching the point of simulating 100 entities in their exercise, up from 20 in the previous test. And it'll take place at 3 different locations.

That is tiny compared to the number already used in a military simulation last year. Millenium Challenge 2002 took place on ~15 sites around the US, and involved 13500 human participants, many of them controlling more than one "entity" in the game.

3. The Pentagon is trending back towards DIS
The article mentions this project is using the IEEE 1278 standard DIS (Distributed Interactive Simulation). That is a fairly old specification- finalized at least 10 years ago. It worked well back then, and still does. However, it fell out of popular use in the late 90s because a vantity project from Defense Modeling & Simulation Office mandated that all simulations be switched to use their new improved HLA infrastructure, which is IEEE 1516.

The HLA was a traditional example of Fred Brook's Second-System effect. That is, when a person first makes a project of a certain type, he will be conservative and careful to make something that works and he can understand. (In this case, the DIS protocol). But once the first system works well, programmers tend to get overconfident and decide to fill the second system will all manner of elaborate stuff that distracts from the real purpose. That is what happened with the HLA protocol.

HLA is a real kitchen-sink system, addressing all uses but satsifying none. Only in the past year has DMSO's political power been reduced so that wargame developers can stop using the bad, unpredictable HLA and get back to the clean, efficient, and comprehensible DIS.

4. HLA does have one advantage over DIS
The DIS protocol is a global publication system. Each computer controlling simulated entities broadcasts their position to ever other computer. (Originally this used ethernet broadcast, now it might change to internet multicast UDP). That meant that in a large exercise, people out-of-range from each other would still recieve positional updates clogging their network card. HLA included specifications to describe, geographically, who should recieve which packets. This allowed for world-spanning scenarios to be played with thousands of vehicles spread around.

The article suggests that new projects (DFIRST? I haven't heard of that before) will bring some of this capability to DIS.

4 comments in one:

1. Why Linux?
True, the eetimes article is discombobulated and provides little explanation of why Linux should matter at all for wargaming simulations. And the explanation it implies (that Linux helps data compatibility) is nonsensical.

However, I've seen several military simulation projects that run on Linux. The obvious reasons: The Pentagon isn't a fast or flexible software developer. These games may take decades of to produce and shape into something workable, and we can't throw them out just because new OSes (Windows XP, etc) come along.

So many projects that were first written for big iron SGI or Solaris machines are now running on Linux desktops. I've heard several ancedotes of software getting a 5x speed boost alongside a 10x drop in platform cost when changing hardware vendors from SGI to Dell.

One major simulation project is OneSAF ("One Semi-Automated Force"). You can go read the PowerPoint they gave at a Linux conference years ago. (The "CCTT" project mentioned in the article is an ancient fork of OneSAF)

2. 100 entities is small
The article says they will be reaching the point of simulating 100 entities in their exercise, up from 20 in the previous test. And it'll take place at 3 different locations.

That is tiny compared to the number already used in a military simulation last year. Millenium Challenge 2002 took place on ~15 sites around the US, and involved 13500 human participants, many of them controlling more than one "entity" in the game.

3. The Pentagon is trending back towards DIS
The article mentions this project is using the IEEE 1278 standard DIS (Distributed Interactive Simulation). That is a fairly old specification- finalized at least 10 years ago. It worked well back then, and still does. However, it fell out of popular use in the late 90s because a vantity project from Defense Modeling & Simulation Office mandated that all simulations be switched to use their new improved HLA infrastructure, which is IEEE 1516.

The HLA was a traditional example of Fred Brook's Second-System effect. That is, when a person first makes a project of a certain type, he will be conservative and careful to make something that works and he can understand. (In this case, the DIS protocol). But once the first system works well, programmers tend to get overconfident and decide to fill the second system will all manner of elaborate stuff that distracts from the real purpose. That is what happened with the HLA protocol.

HLA is a real kitchen-sink system, addressing all uses but satsifying none. Only in the past year has DMSO's political power been reduced so that wargame developers can stop using the bad, unpredictable HLA and get back to the clean, efficient, and comprehensible DIS.

4. HLA does have one advantage over DIS
The DIS protocol is a global publication system. Each computer controlling simulated entities broadcasts their position to ever other computer. (Originally this used ethernet broadcast, now it might change to internet multicast UDP). That meant that in a large exercise, people out-of-range from each other would still recieve positional updates clogging their network card. HLA included specifications to describe, geographically, who should recieve which packets. This allowed for world-spanning scenarios to be played with thousands of vehicles spread around.

The article suggests that new projects (DFIRST? I haven't heard of that before) will bring some of this capability to DIS.

I worked on a terrain database analysis tool, called ZCAP,
that was funded a few years back by U.S. Army STRICOM
and the Defense Modeling and Simulation Office
We distributed the application (and still do) in a complete package
that included a number of supporting free source applications, such as gnuplot
and tcl/tk. We handled the combination of free source, (no longer)export-restricted
software, and proprietarty libraries by loosely integrating
using system calls under a tk-based gui. Not very clean, but there
is a lot of good code in there, and I'm planning to gpl it in the near future.

For you computer scientists out there, the military is doing something quite large and interesting.
The HLA, the high level architecture, is a system for integrating different simulation systems into one big networked simulator.
The problems are more severe than in the current large multiplayer games because you have to link people up fairly and be realistic and you have to link different systems together.

At DMSO they are using xml for communication between different model systems. The XML defines a common format. Instead of having to support filters to convert each doc type to each other doc type you just have to be able to convert each to/from xml. If there are 3 doc types, you need 8 filters (3^2) to get to/from each. If you use XML you need 3 filters to get to/from xml. Assuming the filter is 2-way,from/to. If it is one way, to or from only, double the number of filters. This is what xml is really designed for. To get a common document format.

The US Army should create a department for this purpose. I really think it could reap dividends.

Perhaps the Defense Modeling and Simulation Office?

Real-Time System: A system that computes its results as quickly as they are needed by a real-world system. Such a system responds quickly enough that there is no perceptible delay to the human observer. In general use, the term is often perverted to mean within the patience and tolerance of a human user.

real time 1. [techspeak] adj. Describes an application which requires a program to respond to stimuli within some small upper limit of response time (typically milli- or microseconds). Process control at a chemical plant is the {canonical} example. Such applications often require special operating systems (because everything else must take a back seat to response time) and speed-tuned hardware. 2. adv. In jargon, refers to doing something while people are watching or waiting. "I asked her how to find the calling procedure's program counter on the stack and she came up with an algorithm in real time."