DoD developing Linux-based "Soldier's Radio" 124
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.""
Re:Popularity doesn't always seem to be good (Score:1)
2. Freedom has to be absolute. As soon as you start dictating who can use the software and for what purpose, it's not free. Just as you can't tell the KKK to shut up because they're unpopular, you can't tell people not to use the software if you don't like them. Either you understand this "freedom" thing or you don't.
Re:Just fluff for the public (Score:1)
Re:Just fluff for the public (Score:1)
I work for a company on a research contract for the Army Research Laboratory in Adelphi, MD, and I can reliably say you are full of sh*t.
The military can do some cool stuff, but "microchips embedded in fatigue lapels to track soldiers and communicate encrypted voice transmissions" are still - at best - a pre-R&D concept.
The Army is moving towards a wired soldier, but the best they can manage is very similar to what the article above describes. Just add GPS and an electronic compass into a backpack computer, and you have something usable, if too big under current technology to be feasible.
Re:How does frequency hopping work? (Score:1)
premise is this, you provide radio A with a set
algorithim used to calculate a very large set of
what appears to be more or less random frequencies
and provide this same algorithim to radio B (this
process is called "filling" the radio in Army
crypto-speak). These algorithims are changed at
specific intervals and if someone forgets to fill
their radio they lose access to the net. In any
case, radio A and radio B then begin jumping
through the frequencies (many different freqs per
second, don't remember the exact number). In this
way, the two radios can talk to each other. Now
if you are the enemy trying to either jam, DF, or
intercept said radio, it is very difficult to do
because you don't know the algorithim and by the
time you find something on a certain freq it is
gone (not to mention it could be encrypted as
well). For more information, follow the links
to www.fas.org, a great source of info on military
hardware.
Suicidal moderators (Score:1)
Re:Great DoD thinking here . . . (Score:1)
Bill - aka taniwha
--
Re:Hard Hat? (try this URL) (Score:1)
This problem is actually _harder_ than P2P (Score:2)
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 (Score:2)
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.
Clarifications from someone who worked on it. (Score:5)
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 [wustl.edu], 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) [rutgers.edu]
A blurb on SUO SAS by SRI [sri.com]
The DARPA ATO web page describing SUO SAS [darpa.mil]
Apocalypse Now (Score:1)
__
How does frequency hopping work? (Score:2)
__
Re:Popularity doesn't always seem to be good (Score:1)
Thanks
Bruce
Re:UltraWide Band Radio (Score:2)
Re:Military Uses (Score:2)
Bruce
Before 1000 people shout "Why Not BSD?"... (Score:2)
Bruce
Re:Popularity doesn't always seem to be good (Score:3)
I considered this in writing the OSD and decided that I could not prohibit it without reducing some important freedoms.Bruce
Re:Why They Chose Linux (Score:1)
Re:Popularity doesn't always seem to be good (Score:1)
Re:Popularity doesn't always seem to be good (Score:1)
You mean someone is preventing ethnic cleansing of Serbs by Albanians? This is news to me...
Military Uses (Score:1)
Re:Popularity doesn't always seem to be good (Score:1)
Actually, Imperialistic means attempting to annex other nations. However, you're correct: we should be respecting the independence and sovereignty of other nations. In fact, I'm going to change my .sig to make a statement about this. Not that anyone will listen, but...
Re:Your sig: Swapping liberty for safety. (Score:2)
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. (Score:2)
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?
Re:Just fluff for the public (Score:1)
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Re:Just fluff for the public (Score:1)
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Just fluff for the public (Score:2)
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
unix in the field worries me (Score:2)
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:Implications (Score:1)
Just a random thought, if you put the transmitter inside the helmet, isn't there a danger of crushing it between the wearer's head and the helmet? I have worn kevlar helmets before and I just don't think there is that much room in there.
Re:Implications (Score:2)
A long time coming (Score:3)
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 (Score:3)
Cheers and congratulations to the kernel development team and Linux in general. Keep up the amazing work!
Geoff
Military and Spectrum (Score:1)
In seriousness however, I suspect half the reason this is even a possibility is that the military has got reams of spectrum while the commercial sector must pay $18 billion for every little chunk with no assurance that enough chunks will be auctioned off to make it all worthwhile.
The fact that the military, which one has to beleive looks at functionality and performance first rather than price chose a linux based system says a lot. Yeah! Having worked at a company doing embedded programming, Linux has a shot to carve out a niche in the space. Rock on.
Imperialistic? (Score:1)
If Linux is used by the US military, it's used by an all-volunteer force that is bound by oath to preserving the Constitution of the United States and DEFENDING it against all enemies, foreign and domestic. Nothing Imperialistic there.
Perhaps you've never served?
Re:Imperialistic? (Score:1)
The poster did NOT specifically mention Iraq in the same breath as "imperialism" and is thus guilty of poor English usage. (see antecedents)
Regardless, Freedom is freedom, to do with the programs whatever anyone wishes. I really doubt that Microsoft is upset that Iraq or Libya is using Windows. It's a nonsensical argument.
Re:WTF are you talking about? (Score:1)
Re:Remember DARPA's purpose (Score:1)
I first read about this in the second volume of John Master's autobiography, "The Road Past Mandalay". He wrote about an excercise he took place in when he was at Staff College where they used multi-coloured ribbons representing different frequencies stringing them across a map between communicating units. He described how complex the result was, and how quickly you ran out of frequencies. (Remember, if frequencies are too close together, you will get bleed-over and garbled signals which is Not A Good Thing.)
TCP/IP packets, on the other hand, as we all know, can resolve this problem. Which is why they are investigating this I presume.
Re:If you give a man a GPL'ed radio... (Score:2)
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 (Score:2)
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 [ietf.org] protocols that will handle networks this big. Sounds like it should stay in research labs to cook for a while longer.
Re:Talked about for years (Score:1)
Re:If you give a man a GPL'ed radio... (Score:1)
Safe from Anakin (Score:2)
Sounds much like DIRC (Score:1)
Re:Wonder how Linus Feels (Score:1)
-------
CAIMLAS
Implications (Score:2)
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:Wonder how Linus Feels (Score:2)
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:Implications (Score:2)
-------
CAIMLAS
Networking & frequency-hopping isn't new (Score:2)
-Rob Swenson, SGT, US Army
Re:Wonder how Linus Feels (Score:1)
Such as, perhaps, a 911 call center [slashdot.org]?
A new port? (Score:1)
Well, maybe we would see Linux ported to Playstation 2. *grin*
Re:Wonder how Linus Feels (Score:1)
Now that's the American way.
Re:Popularity doesn't always seem to be good (Score:1)
Re:Wonder how Linus Feels (Score:1)
And I don't think Linux has got the monopoly on one-button devices. You could do it with pretty much any system out there.
Another reason (Score:2)
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 (Score:2)
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... (Score:2)
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 (Score:2)
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 (Score:2)
I'm happy to see so many ex-military here.
I salute you, gentlemen!
Re:Remember DARPA's purpose (Score:4)
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:Military using open source... (Score:1)
The military in my experience is far more concerned with operational security- meaning "I don't want to get shot today" and in that vein prefers simple, effective machinery and computer systems that operate easily now. The Intelligence Agencies on the other hand are far more concerned than the average military member with 3 sigma security concerns.
Justin
Re:If you give a man a GPL'ed radio... (Score:4)
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.)"
WTF are you talking about? (Score:1)
"It's a kind of high-performance massively parallel computer built primarily out of commodity hardware components, running a free-software operating system like Linux or FreeBSD, interconnected by a private high-speed network. It consists of a cluster of PCs or workstations dedicated to running high-performance computing tasks. The nodes in the cluster don't sit on people's desks; they are dedicated to running cluster jobs. It is usually connected to the outside world through only a single node."
So what's this I hear about Beowulves being mobile, ad-hoc, peer-to-peer, frequency-hopping, and/or location-finding?
Just log out (Score:2)
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:Clarifications from someone who worked on it. (Score:1)
Frequency Hopping (Score:1)
Re:Why They Chose Linux (Score:5)
Re:If you give a man a GPL'ed radio... (Score:2)
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:Why They Chose Linux (Score:1)
Re:Networking & frequency-hopping isn't new (Score:1)
...and the Swedish Army has had the DART system at least since 1993, as has many other nations, I'm sure.
P. Haegglund, 2nd Lt (VO/Fk), Swedish Army
Could be Free Cell Phone Usage For Everyone (Score:1)
The concept is simple, you can use any peer to peer radio communications system. But the stuff from www.time-domain.com [time-domain.com] looks the best.
With the time-domain stuff, anything can have private communications and location detection within centimeters. The key is to use a cooperative protocol that allows units to relay traffic for units not in range of each other. Actually, you have low power units, which only talk to other units, powered units which perform relay functions a well, and high power units which can compute routing decisions.
In a metropolitain area, like the San Francisco Bay Area, high speed IP access and phone service is free. Its not hard to imagine most homes having 1 to 5 devices that would do relaying and are idle most of the time, of course, this would take a few years for adoption. To get non-local access you gateway via your own home DSL, Cable, or other Internet connection. Alternatively, you buy connectivity out of the metropolitain area network from a communications provider, such as MCI, Sprint, etc...
Essentially, cell phone calling becomes free, you only pay for the phone, the power, and long-distance Internet access.
Since you can determine geographically where transmitters are, you can also track all property containing these devices. If a TV, with a small battery, is on its way from the factory to you and it leaves its expected travel route (at least in areas where there is coverage) an alarm could trigger. More importantly, if your child left school during school hours, or left the route to or from home you could be informed.
There are a couple of open source radio relay protocols that may sound similar, but I can never tell if they get the whole picture-- even after I send this description to them they don't reply. Go figure...
Arthur Britto
ahbritto@iat.com
-
I have lots of ideas, like this one, that make business sense yet never get fully developed. Other ideas include: a micro/macro transactions system, trusted Linux security solutions, performace based Internet advertising, anonymous file storage/sharing, etc...
When I approached time-domain with the concept, they reply was essentially: go away we don't want to talk to anyone now, we are busy patenting things.
Popularity doesn't always seem to be good (Score:1)
For instance, what if Iraq started using Linux as part of it's guided missle software? Would the US try to ban the export of Linux?
Obviously, they CAN use it because it's available in other less draconian countries, and there is good reason for them to because they can make sure that it's secure. China and Mexico are switching to it, why shouldn't Iraq?
I'm just not sure that military use bodes well for the Linux community.
Re:Popularity doesn't always seem to be good (Score:1)
Re:Imperialistic? (Score:1)
http://slashdot.org/comments.pl?sid=01/03/22/01
Re:Why not a peer to peer phone network? (Score:1)
(It's called CB Radio)
Re:Remember DARPA's purpose (Score:2)
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 (Score:5)
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 (Score:5)
Re:Why They Chose Linux (Score:1)
Re:unix in the field worries me (Score:2)
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:Not so bad... (Score:1)
Ahhh, you just brought a grin to my face. I believe you'd recognize the phrase "You want me to jump out of an airplane with _this_?!?!"
Midwatch Industries
Re:Porting to multiple processors (Score:2)
Re:Clarifications from someone who worked on it. (Score:1)
Re:Clarifications from someone who worked on it. (Score:1)
I'm not sure what you mean by "no evidence of modular physical design". TAO is incredibly modular: practically any part of it can be replaced with a different implementation, and most parts have multiple implementations that you can choose from. The real problem is that the design is not documented in a manner that people outside the development team can understand.
The TAO team has been working to reduce the footprint, and to modularize the shared libraries so that you don't have to install the whole damn thing on every machine. The fact that it works on these phones indicates that it is already suitable for embedded environments, and it's going to get smaller.
Like most open-source projects, TAO's biggest failings are that it is under-documented, and doesn't have a simple "It works right out of the box" configuration.
Talked about for years (Score:1)
That DARPA is actually doing it is a good thing because the military is where a whole lot of ideas begin their life and make their way into the civilian sector.
The problem with this whole thing is the weight/bulk of all the equipment they want soldiers to carry. Grunts (I was one) already carry a buttload of equipment for everything and now they want to add more stuff.
"But it's only five ounces" you might say, well, that's true, but this is five, that is another ten, the other is a pound itself. Pretty soon you've got the person with 20 Lbs of equipment before they even get to the soldering equipment.
Another problem is battery life. How long do/will the batteries last? Soldier in the field come to depend on this piece of equipment to get his butt out of a sling and the battery dies at the worst possible time? Movement and contact is usually at night so solar is not a reliable backup.
It's worth a try, it's REALLY worth R&D money, I just hope they come up with some good answers to the problems that will creep up. The soldier in the field has already been screwed by a whole bunch of political baggage that has nothing to do with warfighting but the congresscritter has mandated because it'll bring one or two jobs in his/her district. I hope this does not become one of those.
DanH
Cav Pilot's Reference Page [cavalrypilot.com]
Hard Hat? (Score:1)
Anyone know what this is? I tried pointing my browser to www.hardhat.com [hardhat.com] and got some quite unexpected results...
Re:If you give a man a GPL'ed radio... (Score:1)
Just P2P networking by another name? (Score:2)
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:Finally (Score:4)
[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:
Re:Why They Chose Linux (Score:2)
Re:Popularity doesn't always seem to be good (Score:2)
But even if it were regulated, do you think that Saddam would respect the requirements of GPL?
Finally (Score:2)
But for now, it's radio only. Geeks in Space^H^H^H^H^HTrenches, right?
Why not a peer to peer phone network? (Score:2)
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:Wonder how Linus Feels (Score:2)
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 [gnu.org], 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:Popularity doesn't always seem to be good (Score:2)
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?
Re:Just P2P networking by another name? (Score:2)
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:This problem is actually _harder_ than P2P (Score:2)
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.
Cool! (Score:2)
Re:Just P2P networking by another name? (Score:2)
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.
-----------
If you give a man a GPL'ed radio... (Score:2)
telnet jsmith.platoon4.batallion1.army.mil root beallyoucanbe shutdown -h NOW
I can see it now... (Score:2)
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.