DoD developing Linux-based "Soldier's Radio"

Blind RMS Groupie writes "According to this article at EE Times, DARPA (Defense Advanced Research Projects Agency) is developing a voice/data unit for infantry soldiers based on multiple StrongARM processors and embedded Linux. The radios will link together in what is characterized as a "mobile, ad-hoc, peer-to-peer network that uses frequency-hopping technology to avoid communication intercepts and location-finding capability.""

Comments

This problem is actually _harder_ than P2P

[Tim]

"a squad leader in Alpha Company probably has no reason to communicate with another squad leader in Charlie company, so they can be on different networks. It also makes "searching" issues non-existent- the number of users on any given network is extremely limited. The network doesn't grow, it subdivides, so the N^2 problem doesn't kick in."

Well, not quite. First, the system needs to keep a record of friendly force positions, estimated enemy force positions, and other such battlefield information (the consistent tactical picture). This information has to get to whoever might need it--which may mean the people at the next echelon up, or all the people in close geographic proximity to a particular event, or soldiers involved in the same mission, or friendly units near a fire control line, etc.--depending on the type of information being processed. Thus, a system like this has to maintain complex routing rules at a contextual level, in addition to the routing difficulties that are specific to ad-hoc network systems. Imagine if gnutella had to know what file types had to go to particular users, based on preferences the users specify when they log on to the network--now imagine that the users can change their preferences at any time, and that gnutella is always required to give them all of the relevant files corresponding to their preferences. This gets messy, to say the least.

Second, this type of system is wireless and dynamic, yet nodes must be *guaranteed* some level of baseline communication. In a life or death situation, it is unacceptable to lose communication, or to be fed innaccurate information that may cause you to make misguided decisions. Yes, existing systems have this problem too, but if you want real soldiers to go to the effort of wearing these boxen and using the data they provide, you have to do better than the existing systems.

Third, how do you guarantee that the higher-ups always have a complete and accurate picture of the battlefield? Now, how do you do that without trashing the network (think 10,000 grunts constantly sending their positions over a low-bandwith RF link back to the commander)? Again, existing systems don't do this well either, but the idea is to do better than the existing systems.

The fact is, the total scope of the situational awareness problem is much larger than that faced by gnutella and other P2P systems. Sure, if you dumb everything down to the point where you're doing existing military communications over a computer instead of a radio, you won't run into these nasty little snags, but you also won't get anyone to use these devices (as you might suspect, these ultra-cool radio/computer things weigh more than a regular radio, and soldiers do NOT like to carry more shit around with them :-)

Re:This problem is actually _harder_ than P2P

[Tim]

"data is useful to only a finite number of users....there are still a finite number of lateral "hops" that a piece of data can make before it becomes irrelevant."

You're right about this, but it doesn't do anything to reduce the complexity of routing on a network like this. The addition of geographic routing to the traditional task group/hierarchical routing significantly increases the complexity of the routing decisions that must be made. And pretty much anything you do to accomodate this complexity is a trade-off in terms of bandwidth. You can't very well do hop-counting to time out messages--it's quite possible, in an ad-hoc network, that a geographically nearby node is quite distant, topologically. So you have to come up with a better way to "expire" these messages, while still assuring that the people who need them get them, and also making sure that a consistent picture of the battlefield is maintained by everyone while they're moving around from place to place.

"A division commander or his staff don't want or need information on each private anymore than a Fortune 50 CEO wants information on each employee - it's just noise. Just as a piece of information can only make so lateral hops before it becomes too distant to become useless, it can only make so many vertical hops up or down before it becomes useless."

Yes and no. The commander certainly doesn't want to see all of that data all at once, but he'll raise all kinds of hell if he can't get access to it when he does want it. So now you have to keep this data available somewhere in such a way that the commander can get it when he needs it. Further, even if you don't worry about keeping detailed information around, how exactly does the information get aggregated/summarized and resolved (e.g when N different people report on the same event, how do you filter that down?) when you're underlying network is completely dynamic? The way the military does it now is through a human-in-the-loop report cycle. This takes hours, if not days. It's one of the bottlenecks that the military wants to bypass with a network system like SAS. But it's very hard to automate.

My original point was that the things the military wants out of a system like this are significantly harder to do in an automated way than just P2P networking. Routing is just one of the concerns (though a big one), when you've got to worry about QoS, data storage and consistency. In my mind, the whole thing is less like a P2P network, and more like a gigantic, ad-hoc, distributed, intelligent database--and you've got all the same demands and expectations that you would put on a regular old Oracle database sitting behind a firewall somewhere. All in all, it's a very challenging problem.

Re:This problem is actually _harder_ than P2P

[RandomPeon]

Interesting points, but I think you're asking for more information than is useful.

First, the system needs to keep a record of friendly force positions, estimated enemy force positions, and other such battlefield information (the consistent tactical picture). This information has to get to whoever might need it--which may mean the people at the next echelon up, or all the people in close geographic proximity to a particular event, or soldiers involved in the same mission, or friendly units near a fire control line, etc.--

Again, data is useful to only a finite number of users. SSG Johnson might will consider the exact locations of other squads in his platoon useful information - he'll probably consider the location of all the squads in the company useful information. But in most circumstances, the location of squads in other companies will be useless garbage - it ain't even worth knowing. Geography may play a bigger role in determining what's worthwhile than task organization -if SSG Johnson's squad is on the left edge of his company he will probably consider information from the next company quite useful (which would complicate things), but there are still a finite number of lateral "hops" that a piece of data can make before it becomes irrelevant.

Third, how do you guarantee that the higher-ups always have a complete and accurate picture of the battlefield? Now, how do you do that without trashing the network (think 10,000 grunts constantly sending their positions over a low-bandwith RF link back to the commander)? Again, existing systems don't do this well either, but the idea is to do better than the existing systems.

Short answer - you don't. A division commander or his staff don't want or need information on each private anymore than a Fortune 50 CEO wants information on each employee - it's just noise. Just as a piece of information can only make so lateral hops before it becomes too distant to become useless, it can only make so many vertical hops up or down before it becomes useless.

Technology is a micromanager's dream - a sitution where a general officer can issue direct instructions to every one of his subordinate commanders is a bad one. Like any organization, information gets aggregated as it moves up the chain, and it gets specified/expanded as it moves down the chain. The goal should be to provide the maximum amount of information a staff can deal with and instead of giving them every detail that every subordinate unit has.

Clarifications from someone who worked on it.

[Tim]

It's odd that this just made it into the media, as this project (known as SUO SAS) has been around for the better part of 2 years now--not counting the previous phases of development, which go back several more years.

While the article got a lot of things right, it was also a good portion of hype. I worked on the networking software for this (which is built on top of the TAO CORBA ORB, btw), and while it is conceivable that it might scale up to 10,000 nodes, it is unlikely to do so in it's current form (well, as of a few months ago, anyway). In fact, we faced more or less the same scalability problems that any ad-hoc wireless network system faces, plus the added complexities of having to guarantee consistent tactical picture maintenance (how do you keep a consistent data 'picture' of an entire battlefied among 10,000 separated nodes, with no guarantees on connectivity, or even addressing between any two particular nodes? Now, how do you tackle message-based quality-of-service on top of this mess?). So, for those of you wondering, the problem tackled by this system is a lot bigger and more complicated that than faced by peer-to-peer filesharing systems (think superset of the gnutella problem), and the algorithms we were developing weren't perfect--or even good, necessarily. The problems facing ad-hoc networking are certainly as unsolved and difficult as they were before.

Another important note is that while we ultimately got our way and were able to use Linux for development (partly because we absolutely refused to work with a platform where we didn't have access to the network stack code), it was kind of an uphill battle with DARPA to do so. Linux still isn't qualified to be running on any type of deployed military system, and believe me, we heard about it constantly (I still shudder at the thought of trying to do our development in Windows...)

All that said, the concept of the project was/is pretty cool, but, as always, reality is less dramatic than its press release. If you want more info on the project and related research, here are some links:

Info on geo-routing algorithms (directly relevant to the SUO SAS problem)

A blurb on SUO SAS by SRI

The DARPA ATO web page describing SUO SAS

How does frequency hopping work?

[Pseudonymus Bosch]

I understand that by quickly switching frequencies, your emissions can be harder to jam or intercept, but how can it be easy to be listened to by friends and hard to be listened to by foes, at the same time?
__

Re:UltraWide Band Radio

[Bruce Perens]

Read your own links, please. UWB and Spread Spectrum are two different modes. Spread spectrum is commonly used for military communications and its very high usefullness is proven over about half a century. In contrast, UWB has a much smaller potential application space and a ton of hype.

Re:Military Uses

[Bruce Perens]

Since the U.S. Army paid for the BSD development, they might even understand its capabilities and no doubt they've made use of it somewhere. People who have ARPA grants send a copy of their software to Fort Huachuka. I have no idea if anyone there reads it, though.

Bruce

Before 1000 people shout "Why Not BSD?"...

[Bruce Perens]

Remember that the Berkeley System Distribution was an ARPA project. ARPA is the Advanced Research and Projects Agency of the U.S. Army. Thus, the Army paid for BSD's development.

Bruce

Re:Popularity doesn't always seem to be good

[Bruce Perens]

RMS and I discussed this once. Contrary to your expectation, RMS is not a pacifist.

I considered this in writing the OSD and decided that I could not prohibit it without reducing some important freedoms.Bruce

Re:Your sig: Swapping liberty for safety.

[GypC]

I think it is equally evil to deprive people of having their cake or eating their cake as a result of their willingness to choose eating their cake over having their cake. All people, their potential foolishness notwithstanding, have the right to have their cake and eat it too.

Why burn bridges when you can nuke the whole river?

Re:Your sig: Swapping liberty for safety.

[GypC]

The cake thing was a joke, pointing out the fallacy of the parent poster's argument. Like "You can't have your cake and eat it too," get it?

OK, never mind.

Why burn bridges when you can nuke the whole river?

Just fluff for the public

[Jack9]

Going on 10 years ago the military was using microchips embedded in fatigue lapels to track soldiers and communicate encrypted voice transmissions. My friend ... Tom we'll say, was in the US SEALs and said many things about the military's capability when dealing with operations abroad. Do you really think it's a vote for linux or a PR move to reassure the public that their tax money is being well spent by the military? Not to mention/flame that BSD would be the choice for the security conscious.

Often wrong but never in doubt.
I am Jack9.
Everyone knows me.

unix in the field worries me

[mr_burns]

In the Marines, I used a field system based on a unix. It always kinda worried me. If the enemy can get access to the shell on a box that's logged in...that's bad (DOS, sniffers, malware...OH MY!).

Mind you we had guns to keep them from getting machine access, and grenades to keep them from escalating their privilages....it still was something to think about.

Re:unix in the field worries me

[Animats]

The real risk is that some of those radios are going to be captured by the enemy. (You deploy 10,000 anythings at the individual soldier level, the enemy will get a few.) The system has to be designed so that a captured radio doesn't compromise the system, even if opened up and dumped. There are ways to do that, but most of them create operational problems. Obvious approaches, like needing a new smart card update every day, are a pain.

Hierarchy may help. Suppose that, for a radio to stay in the system as a trusted player (i.e. you get to see the broadcast situation info), at least once a day (more often in fluid situations) you have to talk to somebody of higher rank who knows you. They punch a button indicating you're you, and that keeps you on the net, and perhaps gets you newer crypto keys. You need backup authentication schemes as well, and backup ways to revoke the authority of a captured radio (especially one from a high-ranking officer) but this could handle the routine case conveniently, since most soldiers talk to a superior once in a while. Any captured radio then drops off the net reasonably quickly.

Re:Implications

[Raven667]

OK, I was thinking something along the lines of a cig pack or MP3 player, which would probably be unsuitable. Something that is just a few wafers should be fine.

A long time coming

[The Cunctator]

The people who developed the Internet, including J.C.R. Licklider (the first head of the IPTO (no, not that IPTO or that IPTO, this IPTO, okay, it's ITO now)) and Len Kleinrock (the man who invented packet-switching), proposed and worked on the idea of deploying mobile radio networks via soldiers back in the 60's.

A central problem is that all the efficiencies possible in a large-scale network are lost without some aggregation, some centralization. Kleinrock worked a bit on the idea of allowing groups of soldiers to cluster together to form temporary hubs close to where additional bandwidth was necessary, but the problem is extraordinarily difficult both mathematically and physically--it's taken a long time for systems to get small enough for the research to be feasible.

Moreover, ARPA/IPTO/ITO really lost steam around the 80's, when Bob Kahn stepped down (no offense, Saul). And they didn't have no Linux, neither. So maybe the time is right, now.

--

Wonder how Linus Feels

[geoffeg]

I gotta wonder how Linus and most of the kernel development group feels about this. While Linux probably isn't guiding missles yet (and I honestly doubt it ever will be) it is being deployed (buzzword alert) in what could be considered a life or death situation (in the end). Not only does this give Linux some impressive standing-groud, it says something about Linux, open source and (while Allchin may not agree) the "American Way". I hope to hear more stories similar to this one in the near and distant future.

Cheers and congratulations to the kernel development team and Linux in general. Keep up the amazing work!

Geoff

Re:Wonder how Linus Feels

[CAIMLAS]

That's a horribly foolish statement. Putting linux in such a device would not make it more difficult to use; if anything, it would make it easier and a one-button type job, as opposed to a larger device with dials, nobs, etc.

Maybe you should concentrate more on logic and common sense and less on linux prejudice due to the fact that you can't use linux.

Might I remind you that Torvalds is Finnish?

-------
CAIMLAS

Re:Wonder how Linus Feels

[kyz]

I gotta wonder how Linus and most of the kernel development group feels about this. While Linux probably isn't guiding missles yet

Linus and the kernel hackers are writing a UNIX kernel. That's all they're doing. They also deliberately chose the GNU General Public License, which they understand grants Freedom 0, The freedom to run the program, for any purpose .

Now, I might want to use a UNIX kernel in my criminal master plan, or my act of terrorism, or my unethical business, or even my Evil Petting Zoo. I might choose Linux, but that is not the responsibility of the kernel hackers. They are only responsible for the kernel itself, not for its use.

If the kernel was deliberately programmed to do unethical or illegal things... that would be a different matter.

Re:If you give a man a GPL'ed radio...

[SEWilco]

A soldier is a member of the military organization. The GPL gives the organization rights to the source code, not that individual.

However, whoever gets one of these radios on the military surplus market with some of the code still in memory will have GPL rights to the source code.

Re:Military and Spectrum

[jbf]

The military can spread their signal really broadly as well; this helps LPD (low probability of detection)

Georouting is going to blow for routing in some tactical situations (like jungles, mountainous terrain, and urban warfare).

I don't think there are any manet protocols that will handle networks this big. Sounds like it should stay in research labs to cook for a while longer.

Safe from Anakin

[Mignon]

It's good that this will be a distributed, peer-to-peer system. That way soldiers' communication won't be vulnerable to some dopey kid accidentally flying into the control center and blowing it up.

Implications

[CAIMLAS]

Just think of the practical field-combat implications this will or could cause.

First off, it's likely that there will be a higher quality, less feedback/static/etc signal. There will also be a potentially smaller device for the soldiers to carry around. This could allow for the entire communication device to be placed, say, inside their helmet, with the button and mic on/in their helmet straps.

I wonder if, when these things actually come out, if they'll be available to the public? I'd love to get my hands on one, if they're half as nice as I'm conceptualizing in my mind.

-------
CAIMLAS

Re:Implications

[CAIMLAS]

I suppose it's possible, but I was thinking along the lines of a slim-lined wafer type device. Maybe the thickness of one or two silicon boards with a thin, tough metal/plexiglass casing.

-------
CAIMLAS

Networking & frequency-hopping isn't new

[Noctavis]

Frequency-hopping and establishing an encrypted communications network of sorts isn't especially new. We've been doing it in the US miliary for years with SINCGARS systems.

-Rob Swenson, SGT, US Army

Another reason

[Ungrounded Lightning]

Believe it or not, individual soldiers in the Army generally still don't have personal radios down past the squad leader level.

There's a reason for this. Most field tactical radios are bulky and heavy.

That's fixable.

One that's NOT fixable is that high-energy radio noise could knock out radio communications. The Army doesn't want their small unit coordination to be so dependent on radio (or any other single thing) that things go to pieces if it's denied.

Re:Popularity doesn't always seem to be good

[dolanh]

This is the ultimate proof-of-concept - if Linux is stable enough for a combat system where failure can have life-or-death consequences for the soldiers involved, what isn't it stable enough for?

Well, remember when that arleigh burke class missile cruiser running NT went down for a while ... I guess some genius deemed it not stable enough for *that* application :)

Re:If you give a man a GPL'ed radio...

[sconeu]

No.

First, the soldier is not the client, the DoD is the client.

Second, most "soldier in the field" systems are designed to boot or login directly to the application. The soldier doesn't have development tools or any sort of stuff like that, nor does he have access to a shell to use them.

One system we developed booted directly into our X application (we did it with the inittab). The only way for us as the developers to get into the box for debugging purposes was to telnet in.

Also, this "Army of One" BS aside, those of us who develop for the Army know that we have to design for an 8th grade education. No insult intended against any green-suiters out there.

On the other hand, many of the officers and NCO's (as opposed to rank&file soldiers) have been among the most clueful customers I've ever dealt with -- much more clueful than the typical customer described here on /.

Re:New version of older Land Warrior system

[sconeu]

No. We worked on Land Warrior. The way that Land Warrior worked out, the soldier would have been a turtle. It may have been a COMPONENT of Land Warrior.

It's also a variant on something I once worked on.. handheld box for Situational Awareness, moving map. Of course, it still only used some legacy commo protocols (though we did eventually get MIL-STD-188-220A and VMF BOM running).

The automatic peering and routing are what's really about this system.

Re:Remember DARPA's purpose

[sconeu]

I've never served, but I work for a defense contractor, and have a healthy respect for you green-suiters and leathernecks.

I'm happy to see so many ex-military here.

I salute you, gentlemen!

Re:Remember DARPA's purpose

[sconeu]

Believe it or not, individual soldiers in the Army generally still don't have personal radios down past the squad leader level.

There's a reason for this. Most field tactical radios are bulky and heavy. An individual soldier doesn't really want to carry one.

Also, it's "SINCGARS", not "SINGGARS".

Re:If you give a man a GPL'ed radio...

[Jace of Fuse!]

many of the officers and NCO's (as opposed to rank&file soldiers) have been among the most clueful customers I've ever dealt with...

Commissioned Officers and Non-Commissioned Officers are more clueful because the ranking system works somewhat like the Moderation System here at Slashdot.

All of the really Intelligent and Insightful people earn promotions, and all of the idiots stay at the bottom.

It's a wonderful system that works as well to ensure that there are high quality officers in the Army as the Slashdot Moderation system ensures that there are high quality... uh... nevermind.

"Everything you know is wrong. (And stupid.)"

Just log out

[BlueUnderwear]

> You can't mod up your own posts, even if you post anonymously

If you do that, do not just check the Post anonymously box. Rather log out by following the logout link at the top of your User-info page (or simply remove the slashdot cookie using a text-editor).

Or alternatively, use hotmail to get a second (and third, and fourth, ...) account.

Also, if you pull this off, be very careful about meta-moderation (you lose one karma point each time somebody labels your moderation as "unfair").

Re:Why They Chose Linux

[Jah-Wren Ryel]

Better watch out for Colonel Panic then...

Re:If you give a man a GPL'ed radio...

[Eil]

Let's not forget the fact that all services have strict rules on what you can/cannot do with government property that you have access to.

For example, I am an avionics technician in the Air Force. We aren't allowed to perform *any* procedure that isn't listed in the technical orders. Technical orders tells us when and how we are allowed to repair something. Disregarding them or not using them while making a repair is the same as disobeying a direct order from the Secretary of Defense. Therefore, it would not be possible to simply start hacking on these gadgets even if there were the capability to do so. (And there isn't.)

It is also some kind of criminal offense, I'm sure, to use a radio modified to other than the official military specs during a mission. It could be a safety risk as well as a huge security risk, possibly putting lives on the line other than one's own.

Now, say if I were to aquire one of these radios with my own money and decided to hack on it in my own time, that would be perfectly fine. But this would depend on whether or not I could actually get one (legally) because there may or may not be licensed technology or software in it that *isn't* GPL.

Re:Remember DARPA's purpose

[Infonaut]

only the squad leader really needs one to communicate with base

So what you really mean is - "the average PFC doesn't need a radio that is tuned to the platoon or company push." I agree with you there, and I agree that an inter-squad commo capability could be a very good thing, particularly in those instances when you're on the OBJ, the 60s are yammering, the mortar rounds are falling, and you suddenly lost track of where your squad is moving.

If every PFC were on the platoon or company push, it could get to be sort of like.. well, like Slashdot . Great community, but not an execution-oriented environment ;-).

Remember DARPA's purpose

[Infonaut]

I've posted about this before - but remember that DARPA's charter is not to develop new technologies that are necessarily used "out of the box". There's a reason they're called the "Defense Advanced Research Projects Agency.

There's a higher than even chance that this will be akin to a press release about .NET from Microsoft. The initial concept of the product and the actual (if any) end result are likely to have significant variance.

However, this is part of a larger DoD trend toward providing soldiers with ubiquitous communication. Believe it or not, individual soldiers in the Army generally still don't have personal radios down past the squad leader level.

While it's been pointed out that special ops units have lots of sophisticated personal communications devices, for the average soldier or marine on the ground, there's a lot of room for improvement.

This DARPA project is one out of many different options the military is exploring, so be happy (or upset, if you're not fond of the military) that they're exploring multiple paths before committing to a massive restructuring of their tactical communications setup.

Also as has been noted elsewhere, signal-hopping has been used for years by the US military in SINGGARS systems.

Why They Chose Linux

[Cheshire Cat]

I understood the DoD chose Linux over Windows because they didn't want their soldiers to take orders from General Protection Fault! :)

Re:Why They Chose Linux

[baywulf]

They also didn't want General failure reading their drives.

Re:Porting to multiple processors

[Jagasian]

Actually, I run a Windows98SE box, for a gaming machine. USB support under Windows95,98, and 98SE is a crappy hack at best. It takes a few patches before you can get most devices to work correctly. Note that the patches are hidden deep down in the rats nest of Microsoft.com, which makes for great fun when initially setting up a Windows95,98,98SE box. Can't speak for WindowsME, as I wouldn't touch such an OS... its not as good as Windows98SE for gaming (gotta have win3.1 and DOS support).

Just P2P networking by another name?

[AnimalSnf]

Reading the article, I couldn't help but notice the similarities between DARPA's objective and the problems inherent with P2P projects like Gnutella.

First, both must overcome a lack of a central server. While Napster has a server for the clients to connect to and cell phones communicate with a radio tower in that the geographic area, a "cell", P2P and Army's new system do not.

Second, both must be adaptive to their environment. Army's system must be able to use almost any frequency within a broad range and provide a means of concealment, and P2P must able to use almost any port within TCP or UDP and vary packets enough not to be snagged by a firewall.

Third, and most challenging, both must be able to deal with that pesky bandwidth problem as the number of users increase. I will be amazed if almost the same code used by the Army, if released, would not make it into a P2P client, or vise-versa. Virtually the same problem.

Re:Just P2P networking by another name?

[RandomPeon]

First, both must overcome a lack of a central server. While Napster has a server for the clients to connect to and cell phones communicate with a radio tower in that the geographic area, a "cell", P2P and Army's new system do not.

Actually, the problem of P2P filesharing is quite different.

In a decentralized P2P filesharing network all users need to be able to communicate with all other users since any user may have information that he/she wants. But a squad leader in Alpha Company probably has no reason to communicate with another squad leader in Charlie company, so they can be on different networks. It also makes "searching" issues non-existent- the number of users on any given network is extremely limited. The network doesn't grow, it subdivides, so the N^2 problem doesn't kick in.

We already use peer communication networks of a sort- they're just much more low-tech. Each unit has their own net, and each unit has a couple people plugged into the higher HQ net - there are also parallel nets, like the fire support net, etc. This solution has worked with boring,old-fashioned radios for decades.

Re:Just P2P networking by another name?

[Seinfeld]

A couple of points
1. Bandwidth can be a problem, yes. But it is more the ability of the human mind to multithread than the technology bandwidth. Typically, you should only have one conversation thread going on a channel at a time. If you want to cause some major chaos, start up a new thread while another one is going on. In fact, the limiting factor is the single-threaded nature because the human mind would not be able to handle more reliably. So you can't even get close to maxing the radio bandwidth before you max out brain bandwidth.

2. Usually, the real problem is enough hardware to stay on all the radio networks that you needed to listen/communicate on. When I was a platoon leader in an Armored Personnel Carrier (APC), I had three radios going, each monitoring a different net. And I could have used a couple more -- I would still be switching back and forth between nets.

3. The frequency hopping is not controlled by a central server. Basically, one radio sends out a synchronization signal at the beginning, and it is the individual radio's responsiblity to keep itself sync'ed with the others' hopping. There isn't all this P2P traffic keeping everyone together. Radios "fall off" sometimes because their clocks are a bit off. But, there is no reason that thousands or millions of radios couldn't keep up. The limiting factor there is range. You really don't have much use for thousands of radios all within SINCGARS range of each other -- it'd be a pretty densely packed area.

So yes, your points are valid in theory, but the human and logistical factors impose limits way before the technological limits kick in. You could "napter-ize" the radio solution and you still couldn't jam more traffic onto a single net, because it would confuse the users of the net.
-----------

Re:Finally

[1337d00d]

The soldiers will soon be able to check e-mail and post comments on Slashdot right during the battle. Good thing - there will be less Anonymous Cowards here.

[Background: Men running everywhere, tanks crushing the trenches in the middle of a battle. Two soldiers hide at the end of a trench. One is cursing at a small, handheld LCD screen with a packet radio connection to the internet]

First soldier: Goddamn it, submit!
Second: Lets get out of here, man! That's tanks gonna crush us!
First: Just a second, I nearly got the first post!
[Second soldier runs away, and the tank crushes the first soldier while he continues to yell at the computer. Afterward, another soldier runs up, to find the screen showing this:

Slow down cowboy!

Slashdot requires you to wait 1 minute between each submission of /comments.pl in order to allow everyone to have a fair chance to post.

It's been 1 minute since your last submission!

Re:Popularity doesn't always seem to be good

[BlowCat]

GPL only regulates distribution of software. Use of software is not regulated by GPL.

But even if it were regulated, do you think that Saddam would respect the requirements of GPL?

Finally

[BlowCat]

The soldiers will soon be able to check e-mail and post comments on Slashdot right during the battle. Good thing - there will be less Anonymous Cowards here.

But for now, it's radio only. Geeks in Space^H^H^H^H^HTrenches, right?

Why not a peer to peer phone network?

[namespan]

I've been wondering for a few weeks how feasable creating an ad hoc peer-to-peer phone network would be.

Could such a system be implemented? Where, say, every person involved bought/made a radioLanPhoneBox... and as more and more people get one, more and more areas can be reached....

Alright, maybe we can introduce a mild heirarchy if it's needed to make it work?

(fully expecting someone to tell my why this can't work)

--

Re:Popularity doesn't always seem to be good

[RandomPeon]

I'm just not sure that military use bodes well for the Linux community.

This is the ultimate proof-of-concept - if Linux is stable enough for a combat system where failure can have life-or-death consequences for the soldiers involved, what isn't it stable enough for? If Linux is adaptable enough for the US Army to use in major both end-items(See previous slashdot story) and personal communications, what can't it be used for? If the NSA wants to use it as a basis for a secure system, what isn't it secure enough for? If I sold Linux-based anything, I would use this as an example.

I have to wonder what RMS would think about GPLd software being used for an imperialistic military.

Free Software requires a free environment, which the US Army exists to protect. You didn't see any Free Software coming out of the Soviet Bloc and you don't see any free software coming out of North Korea, Cuba, Iraq, or Iran today. It's a great thing when free software can be used to protect freedom. That "imperialistic" military you seem unhappy with allows you to work on any project you want and to communicate freely with developers around the world. BTW, would that be the same imperialistic military that is currently preventing cleansing in Bosnia and Kosovo?

Cool!

[BoarderPhreak]

Now if we can just apply this to Napster queries and networking, we'd be stylin!

If you give a man a GPL'ed radio...

[number one duck]

If you give a soldier a piece of equipment with the GPL attached, does that give him a right to the code? Seems dangerous for a military environment, where mistakes are directly purportional to dead men. Security through obscurity is never perfect, but it *might* help in this scenario.

telnet jsmith.platoon4.batallion1.army.mil root beallyoucanbe shutdown -h NOW

I can see it now...

[SonnicJohnny]

In RIAA vs. DoD... "The U.S. Military was brought under fire today by the RIAA due to soldiers in the field sharing MP3s over their peer to peer network."

The RIAA is said to be requesting the DoD implement filtering software in these units which would prevent their users from sharing copyrigted material.

"How can we expect artists such as Modonna and Britany to maintain their desire to create music when thousands upon thousands of soldiers are steeling their music?", one RIAA lawyer was quoted as saying.