Military Matters

In March 2005, we wrote an entry on "Military Uses of Nanotechnology." It has become the most popular item we've ever posted, generating more than 140 comments, many of them long and detailed.

One reader requested that we "paste the 2007 [portion] of the comment thread onto a new thread if possible, to give mercy to any dial-up blog readers." Unfortunately, it's not possible to move those existing comments to a new blog entry. What we can do is raise the topic again, as we are doing here, and hope that new comments will be posted to this entry.

Issues currently under discussion include:

• Whether the "Eutactic Paperweight" problem--that advanced products will be mostly software, and software is very hard to design quickly--will slow military development enough that unstable arms races and winner-take-all outcomes can be avoided.
• What effect Soviet spying had on Soviet development of the A-bomb.
• Whether molecular manufacturing products will make battlefields unsurvivable for soldiers.
• The effects of anti-weapon treaties.

Another thing that we -- or someone else -- might do is harvest those comments for the most interesting ideas and post them for easier public viewing at the Wise-Nano.org wiki site. It would be great if a volunteer could undertake that project. (Remember that everything posted to the Wise-Nano site must be released under the Gnu Free Documentation License by the original author.)

On the subject of military matters, here's a new item:

The U.S. Army is developing a robot that fires a machine gun with half-mile accuracy. Troops operate the machine remotely from a suitcase-size computer that lets them peer through the robot's five cameras and drive it by tilting a joystick.

The $250,000 robot -- known as Special Weapons Observation Remote Reconnaissance Direct-Action System, or SWORDS -- is intended as a way to keep troops out of harm's way.

The Department of Defense is investing $130 billion over the next 20 years in the Future Combat System, a network of computerized weapons and robotic vehicles.

That's a summary at KurzweilAI.net, based on this article in the New Jersey Star-Ledger.

We should make it very clear that the new weapon being described here is not a product of molecular manufacturing. It does, however, indicate one possible direction of future warfare, a trend that may be accelerated by nanofactory technology. That direction is toward the removal of (some) soldiers from the battlefield, an idea that was discussed extensively in the comment thread referred to previously.

Molecular manufacturing could allow full mechanization of field warfare [as we've said before]. Rather than improved human soldiers, we may see revolutionary new approaches to attacking and defending. This might seem to offer the potential for saving many lives, but in reality it could do the opposite.

Instead of removing humans from the field of battle, automated or remote-controlled weapons may make it easier to take the battlefield to the humans. Although these new weapons may shift the focus of conflict away from conventional battlefields, new battlefields will have to be developed, and many of these may overlay civilian populations.

Mike Treder

Tags: nanotechnology nanotech nano science technology ethics weblog blog

Comments

[Brian Wang]

the ongoing budget pressure from the Iraq war is causing budget cuts for the Future combat system program.

http://www.defensetech.org/archives/003044.html

Work has happened and will continue to happen in this area. Defensetech.org believes this money could be spent more effectively.

http://www.defensetech.org/archives/cat_fcs_watch.html

A quote from them:
Here's a thought: stick to proven, affordable armored vehicles that work (and might even be better suited to future fights than FCS) while investing some of the savings in more ships and C-17s, speeding up deployments at a fraction of the cost.

My example, A10 are cheap, robust and effective tankbusters
http://en.wikipedia.org/wiki/A-10_Thunderbolt_II

[Chris Phoenix, CRN]

In the previous thread, Greg Trocchia and I have been talking about how far software development could be speeded up by unlimited quantities of hardware. I'm a former embedded software engineer and he does Software QA and was "a small cog in the Military Industrial Complex for the first dozen years of my career", so we both know what we're talking about.

We now return to the show in progress...

Greg, your "perfect storm" bugs come in two flavors: those where the program's failure leaves a detailed trace, and those where it doesn't. If I had a record of everything a system was doing at the time a bug appeared, that bug would only have to happen *once* in order to be found and shot. It doesn't take long to scan a sequential record to see where the first bad entry is. And then it doesn't take long to figure out why the transition from good to bad happened.

Of course a *complete* record of everything the system was doing is nearly impossible to store. But in a well-designed and lavishly overpowered system, we *can* keep a record of all data going into and out of every procedure. And that should be enough.

Today, I can almost guarantee there's no such thing as a lavishly overpowered UAV. With molecular manufacturing, there would be.

I will admit that I've never designed high-bitrate sensor-interpretation software, and my small early experience with robotic control software was not very productive. It's possible that robotic R&D would continue to be highly difficult even in supercomputer-powered systems. I'm surprised that aircraft control algorithms took so long to develop--IIRC it was only in the last decade that anyone figured out how to drive a standard helicopter autonomously. On the other hand, a lot of the problem with robotics is inadequate sensors, actuators, and computers. And a lot of that problem is driven by the astronomical cost of the good stuff, and the non-existence of the great stuff.

If I could get gigapixel video at 1000 frames per second, or megapixel at a million FPS, and if I had the computer horsepower to do frame-to-frame compares and the actuators to jitter the lens precisely, I bet I could learn quite a lot about the 3D nature of the environment with fairly simple brute-force algorithms.

Chris

[Chris Phoenix, CRN]

Phillip Huggan wrote:
"Bioweapons treaties were tongue-in-cheek documents agreed to. In reality the US had planted counter-spies that were "informing" the Soviets the USA had achieved bioweapons breakthroughs. The US thought the USSR would waste a bunch of cash trying to match these alleged "breakthroughs" (it was a generally succesful strategy; ultimately unsustainable military expenditures bankrupted the USSR). In fact, the Soviets poured rubles into achieving new bioweapons and *successfully* attained them, the most publicly known of is weaponized Anthrax. Oops. These scientists are still in high demand today enabling cheap WMDs."

That reminds me of something I read a few years ago--a first-person account by an engineer who had the rather fun job of taking German research scientists out of action during WWII. He and his colleagues would make a complicated device that did nothing, shoot holes in it with captured German ammunition, and leave it on battlefields during retreats.

The idea, of course, was to make the Germans waste their time trying to figure out mysterious "superweapons" that didn't actually do anything.

Ever since I read that, I have wondered how many German inventions resulted from those twisted-up hunks of mystery.

It's well known that simply knowing that something can be done makes it much easier to do again. And tech developers frequently credit success on a project to not knowing it was supposed to be impossible. Having a goal to shoot for unleashes vast reservoirs of creativity--as we saw in the recent Ideas Factory.

If you could put a scientist in a mindset outside of all boxes, they could probably invent almost anything. Telling a scientist, "This device does something--figure out what" when it actually does nothing sounds like an excellent way to engage their pure creativity, unfettered by any preconceived notions.

It's a truism of logic that you can prove anything at all starting from a contradiction. I have sometimes wondered what would happen if you took a physicist, a biochemist, and a neuroanatomist, hypnotized them to believe that telepathy was a real and natural phenomenon, and asked them to work together to figure out how it worked. They probably wouldn't invent telepathy, but they'd probably invent something pretty cool!

Chris

[Greg]

>>It is easy to verify if a MNT aerospace test has occured if a MNT industrial facility is rendered transparent via (conventional nanotech) surveillence.
You are wrong about Biopreparat. Bioweapons treaties were tongue-in-cheek documents agreed to. In reality the US had planted counter-spies that were "informing" the Soviets the USA had achieved bioweapons breakthroughs. The US thought the USSR would waste a bunch of cash trying to match these alleged "breakthroughs" (it was a generally succesful strategy; ultimately unsustainable military expenditures bankrupted the USSR). In fact, the Soviets poured rubles into achieving new bioweapons and *successfully* attained them, the most publicly known of is weaponized Anthrax. Oops. These scientists are still in high demand today enabling cheap WMDs.
<< note- this post was in the previous thread

That runs very much counter to the way I heard things, here is a link:

http://www.fas.org/bwc/papers/review/post.htm

According to Federation of American Scientists (FAS), the disinformation campaign occurred BEFORE we signed the Biological Weapons Convention of 1972. I will include the relevant section:

"There was no knowledge at the time concerning Soviet BW weapons or stockpiles. The move very likely led to the Biological Weapons Convention of 1972. Information has recently become available about an impossibly mindless and irresponsible disinformation effort carried out by the US Federal Bureau of Investigation (FBI) that supplied disinformation to the USSR to the effect that the US had maintained a covert BW program beyond the November 1969 Presidential announcement of its termination. When the counterproductive potential of this disinformation effort was realized, it was terminated in mid-1971."

And here is the section on the Soviet Program:

"In the decades after WWII the USSR built the largest, most ambitious, and most advanced offensive BW system that the world ever saw.[15] But it was not seen. Contrary to the US (and UK) programs, it was a totally secret, covert program. After 1972/75, it was also a program that was in absolute violation of the Biological Weapons Convention, a treaty for which the USSR was a co-depository."

Several points here: 1) I am in total agreement with the characterization of the disinformation campaign as "impossibly mindless and irresponsible". Leading me to wonder if, as was the case for ex-SecDef Rumsfeld, the author of this campaign somehow found a spot in our current administration (it is a cheap shot, I know, but I just couldn't help myself). 2) According to FAS Biopreparat only began to be suspected in the 1980's and confirmed between 1989 and 1992 by defectors. The USSR was able to keep a huge effort under wraps for a long time and the Biological Weapons Convention did not for a minute stop the USSR from going ahead. The FAS site strongly suggests that the US did not regard the Treaty as "Tongue in Cheek" although the Treaty, as seen above did not in fact provide any such benefits. 3) Even if I were to assume that _your_ version is correct and the FAS was flat wrong, my point about unverifiable treaties still holds up. To wit, the disinformation campaign was effective in getting the USSR to spend billions of rubles that they could ill afford because they could not count on the fact that we weren't producing bio-weapons (that we were not, in fact, producing) without ironclad verification and a treaty did nothing to change that dynamic.

[Greg]

>>Greg, your "perfect storm" bugs come in two flavors: those where the program's failure leaves a detailed trace, and those where it doesn't. If I had a record of everything a system was doing at the time a bug appeared, that bug would only have to happen *once* in order to be found and shot. It doesn't take long to scan a sequential record to see where the first bad entry is. And then it doesn't take long to figure out why the transition from good to bad happened.
Of course a *complete* record of everything the system was doing is nearly impossible to store. But in a well-designed and lavishly overpowered system, we *can* keep a record of all data going into and out of every procedure. And that should be enough.
<<

I think you are underestimating the degree of subtlety and complexity of "perfect storm" bugs, let me give you a hypothetical example of the sort of confluence I am talking about to illustrate. Let's say that have a heavy load on one part of the subsystem which leads to a hot spot in your multi-processor , multi-threaded setup, since this is real-time this leads to some bits being "dropped on the floor" as they can't be processed in time. Let's say this also give rise to a race condition. Let us then say that there is a buffer in a totally separate part of the system that overflows and causes the return location of a subroutine to be altered, which then interacts with the hot-spot and the race condition. Let's further posit that the heavy loading that I spoke of causes a different process to go into "live-lock" and time out except that as the timeout is ready to happen, the process is able to complete its task which causes a bug in the time-out handling to manifest, which then proceeds to interact with the race condition and the bad return from jump causing the system to (incorrectly) self-diagnose the problem and apply an inappropriate method of "recovery" from the bug which then interacts with the race condition the corrupted jump return and the bad time out handling to...

I hope you get the picture here. Latent bugs are latent because they happen infrequently and such a confluence is more rare by the product of the independent probabilities but: 1) In systems that are sufficiently complex and do lots and lots of processing you can accumulate a huge number of "trials" and 2) As my example illustrates, when the system is in an unusual state it significantly increases the odds of previously unknown bugs to manifest (and perhaps, to interact). Even if you have god-like information about the state of the system just prior to the anomaly, this does not necessarily imply that you will be able to figure out what went wrong. The kind of execution trace that you refer to is very good for nailing singleton bugs to the wall, but I am much less convinced that the technique will be up to the task of teasing out what happens when there is a confluence of separate anomalies. I would also suggest that even if you *can* tease out the isolated elements of the overall failure, it certainly is going to take very significant amount of time to do so. Having information at hand is one thing, being able to utilize a huge mass of information and differentiate signal from noise is something else.

>> I'm surprised that aircraft control algorithms took so long to develop--IIRC it was only in the last decade that anyone figured out how to drive a standard helicopter autonomously. On the other hand, a lot of the problem with robotics is inadequate sensors, actuators, and computers. And a lot of that problem is driven by the astronomical cost of the good stuff, and the non-existence of the great stuff.
If I could get gigapixel video at 1000 frames per second, or megapixel at a million FPS, and if I had the computer horsepower to do frame-to-frame compares and the actuators to jitter the lens precisely, I bet I could learn quite a lot about the 3D nature of the environment with fairly simple brute-force algorithms.
<<

Even if I were to take this all as a given, the task is *much* more complex than merely flying the bird. Remember, you are talking about a system which is designed to be: a) autonomous and b) lethal. Tell me that there isn't going to be a LOT of code devoted to making sure that this combination does not bring you to grief.

[Brian Wang]

More effort and military budget should be spent on game changers rather than more of the same. Robots that carry guns while interesting for science fiction and help slightly with a more antiseptic war from the US side. Do not change the situation that much.

Always on, high resolution sensors and radar like on the skin of long duration blimp that monitor movement in a city and allow rewinding to see who did what in a monitored region. Remote detection of nuclear and bioweapons and components. Those would be pre-MNT game changers.

Molecular nanotechnology would be a game changer many times over. Inexpensive but creative efforts like the IdeasFactory discussed in the other articles show that $10-100 million per year would be being big results. Less than one F22 fighter.

Many of the current problems stem from not changing the game correctly (mismanaging tech choices) over the past 60 years. Not continuing the shift to nuclear power in the 1970s. Instead of being stuck at 20% for electricity from nuclear power if we were at 200%. 100% for electricity and heat and then another 100% for powering cars, trains and buses then the middle east would not be so important. That would allow dealing from a position of strength. Sufficient MNT can change the energy situation with massively efficient solar and lots of it.

[Greg]

>>the ongoing budget pressure from the Iraq war is causing budget cuts for the Future combat system program.
http://www.defensetech.org/archives/003044.html
Work has happened and will continue to happen in this area. Defensetech.org believes this money could be spent more effectively.
http://www.defensetech.org/archives/cat_fcs_watch.html
A quote from them:
Here's a thought: stick to proven, affordable armored vehicles that work (and might even be better suited to future fights than FCS) while investing some of the savings in more ships and C-17s, speeding up deployments at a fraction of the cost.
<<

Even if the military R&D and procurement process was perfectly rational, un-selfinterested, and free to use efficacy as the yardstick by which it makes its decisions unhampered by extraneous considerations (I assure you none of these things are close to true) we would still have the question of how much to spend on readiness and procurement versus how much to spend on R&D. Wars today are come-as-you are affairs so no matter how much killer stuff you have in R&D, if you get into a war now with less than adequate material, training, maintenance, and the like you will pay the price in blood. That said, even a superb wood and sail navy would be just target practice for steam-powered ironclads with turrets (say of the vintage of HMS Dreadnaught). The useful thing about spending almost as much on your military as the rest of the world put together is that it provide considerable room to get the mix not quite right and still be OK. I like the idea of more airlift and sealift. It may not be glamorous, but there is great value in being there "Firstist with the mostest".

My take on the FCS is that it has some of the classic characteristics of "problem" weapon systems particularly in terms of overreach and trying to be all things to all people. Some of the tradeoffs made in terms of sacrifice of armor protection have historically not worked out well.

>>My example, A10 are cheap, robust and effective tankbusters
http://en.wikipedia.org/wiki/A-10_Thunderbolt_II
<<

My take on the A10 is that its fate was sealed long before its birth, when the Air Force became a separate service and was given sole responsibility for all fixed-wing aircraft. The problem is that, unfortunately, in addition to being "cheap, robust, and effective" the Warthog (as its fliers referred to it) was also ugly, hence the nickname Warthog, slow (for a jet) and decidedly low tech (again, we are speaking in relative terms here). What is more, and this I think would be fatal in itself, the A10 is an aircraft designed to do one thing: close support, and do it superlatively. The problem with this is that the Air Force institutionally HATES the close support mission because it is just that: support. Close support automatically locks the Air Force into a subsidiary role on the battlefield. Now taking a fighter like the F16 and loading it with bombs and tasking it to do close support is one thing, but having a plane (and a slow, ungainly plane at that) which is good for nothing else is another thing entirely.

Now the rational thing would have been to give the Army and Marines special dispensation from the "fixed-wing" rule so that they could do their own close support (the Army and Marines LOVE close support every bit as much as the Air Force HATES it), but see my remark above concerning rationality. As a result of all of this, not only was the A10 allowed to go out of production, but the company that made it, Republic , went belly up (as someone born and bred on Long Island, I was all too aware of this as part of the general implosion of the defense industry on LI, which is how I ended up leaving the Military Industrial Complex)

[Phillip Huggan]

Greg, my point is that a bioweapons treaty is irrelevant because it is impossible even if granted access to every warehouse in a foreign nation; to verify there isn't a biolab in operation. Testing aerospace devices covertly might be impossible given tomorrow's (pre-MNT) atmospheric surveillence technologies.

Teleoperated weaponry is much different than is robotics/AI operated. The latter is susceptible to signal jamming. It will be interesting to see if robotics technology advances faster than does signal jamming technology.

[Phillip Huggan]

typo above. Teleoperation can be jammed not robotics.

[Brian Wang]

Greg is right about and I am aware of the procurement inefficiencies and inter-defense department politics. This irrationality causes spending on procurement that I think wastes over 100 billion of the defense departments nearly 500 billion dollars each year.

One of the problems with the game changers is that they are mainly not better weapon systems. They are radically better sensors and detection equipment. Future combat is about boosting the equipment and coordinating everything in the armed forces. It is overly complicated. The key area of change is sensors that could track and detect who the real enemy is based on tracking actions. The US overmatches their opponents in firepower now and does not to spend so much for further overmatching.

The key is to define the missions say takedown Iran and N Korea and then analyse and work towards how to do that in the most elegant and low cost way. Partly political (could be all political) and determine what is the gear and tech that would help transform the political situation.

The nebulous fight two simultaneous wars with general opponents is too open ended. Also, pre-emptive arms race with China is a waste of time. Unlike the old USSR. China will be an economic match. But the gear and time for such a competition will not be for 15-30 years. So purchases now will be outdated then. Plus China has success within the current economic system. Why would they need to use an extensive military option. It is almost exclusively economic losers, who cannot deliver to their populace economically, that end up encouraging the outside the system, rogue state, terrorist elements.

Focus on efficiently managing the economy and defense budget and tech investment can create more economic strength and efficiencies can be generated. It matters for economic loser countries (so the better option for their populace is not terrorism or poverty) and it matters for the USA so that it can outgrow dependency and totally pull away economically.

If it was 100 billion/year on programs for optimal economic return, energy independence, technological development, space development then it would start paying off within a few years and it could be done in a way that would not hurt current military capability. Economic and technological transformation would trickle down to a more robust military capability.

cheap high impact tech programs:
MNT budget would return big.

DNA nanotech and synthetic biology extension (like UK ideas factories, note transforming research and development with this kind of effort and online collaboration)

Quantum computers. A few billion to build scaled up and advanced DWave System Adiabatic superconductor quantum computers and the ion quantum computers.

Broadband boost (a couple of billion could rapidly allow deployment of 100mbps to 1gbps which would make online collaboration a lot more productive). Key productivity infrastructure.

Magnetically inflated and magnetically assembled structures for space. Plasma magnets. Transform what can be done in space.

[Brian Wang]

Two more high impact projects would be mass producable nuclear reactors. Ideally thorium based.

Lighter weight but high power (300MW to 1GW+) nuclear reactors that could be placed onto the moon. Could be used to transform the industrial work that could be done there.
Design and build robotic/teleoperated mining and processing machines. Goal be able to make more of the heavy parts of factories.

moving to non-chemically based launch and power systems (advanced mini-mag orion, thorium reactors, Z-pinch or Bussard fusion) would change the political situation as well.

Only a few chemical power projects makes sense. Hyperefficient genetically engineered biofuel production.

[bruno Debois]

Dear Sir,
I would like to ask you , how the nanotechnology can help the Nuclear waste vitrification?
regards

[Brian Wang]

Please look at the
thorium energy blog

and the
thorium discussion board

It discusses how the right nuclear reactor can generate a lot less waste and none of the long lived (10,000 year) waste.

It could also burn through the current long lived waste. This reduces the nuclear waste problem.

Containment for a few hundred years is a simpler problem.

The problem should be how do we get a cleaner burning nuclear fuel cycle to reduce waste.

the liquid boiler reactors were always meant to be a stop gap measure. President look the French have a nuclear energy reactor we need one. Well we have these boiler reactors we were working on for our subs. Great. Lets stick those on land and encase them in cement.

We could make better molten salt reactors.

Lets do that later. Later has not come yet.

[Greg]

>>Greg, my point is that a bioweapons treaty is irrelevant because it is impossible even if granted access to every warehouse in a foreign nation; to verify there isn't a biolab in operation. Testing aerospace devices covertly might be impossible given tomorrow's (pre-MNT) atmospheric surveillence technologies.
<<

I think that we, implicitly at least, have agreed that treaties which are incapable of being verified offer no real protection from the weapon systems limited or proscribed by them. I hope that you are correct about surveillance technology. One lesson I believe that we can take away from the Cold War is that in the absence of dependable knowledge of the military capabilities of prospectively hostile powers, speculation will create bogey-men where none exist. In this environment, war is more likely than if everyone knows what everyone else is doing.

Some of the nano-weapons I can imagine being created are more akin to bioweapons than to aircraft and missiles and the like, what I refer to as a SmartPlague. There are some factors which mitigate against the worst prospects of this. First off, a SmartPlague is not likely to be an easy thing to nano-engineer. The "Plague" part will be the easier bit, the "Smart" part of it will, I think, be substantially more difficult. I have previously indicated that the combination of autonomy and lethality is a combination poised to ensnare the developers of such weapons in Murphy's law at its most malevolent and destructive. Any development team with a scintilla of common sense will make sure that multiple safeguards exist to make sure that this does not come to pass. As a result, SmartPlague and similar type weapons will be a considerable while in the development.

This brings me to my second point, one which is difficult to overemphasize. We often imagine weapon systems like SmartPlague as being deployed against opponents with capabilities like our own and (wrongly) conclude that the opposition will be helpless against it. In reality, such systems are likely to be developed in a world where the defender likely has access to advanced nanosystems of their own. Consider a nano-manufactured “mosquito” programmed to deliver, say, a gram of botulinum toxin to targeted individuals. For you or me right now, that would constitute a lethal threat. But suppose we had a blood stream containing countless microbivores, all programmed to swarm to and nullify invading pathogens. Even if the microbivores were not made to deal with botulinum toxin (which they might well be, in addition to being hard to infect, I for one would like to be very hard to poison as well and would want some of the immune bots able to defeat as many toxins as possible) it would not seem too big a modification to make a version of the microbivore capable of dealing with that threat. Once “hardened” in this way, I would no longer find the threat to be anywhere near as worrisome as I do now. And yes, microbivores are advanced nano-systems, but then so are SmartPlagues- which is exactly my point

>>Teleoperated weaponry is much different than is robotics/AI operated. The latter is susceptible to signal jamming. It will be interesting to see if robotics technology advances faster than does signal jamming technology.

typo above. Teleoperation can be jammed not robotics.
<<

True, as with any system that requires a communication link, teleoperation has a potential vulnerability in such a communication link. This vulnerability can be mitigated by using redundant channels and fancy comm-tech like spread spectrum, ultra-wide band, and heavy doses of crypto. One nice thing about such systems is that even if such things fail, your system is likely to fail in a safe mode (unless your opposition is so good that they can actually acquire control of your systems, which is not an easy thing to do). With robotics, as decades of SF will attest to, fail-safe is a great deal harder to arrange in autonomous weapon systems.

[Greg]

>>Also, pre-emptive arms race with China is a waste of time. Unlike the old USSR. China will be an economic match. But the gear and time for such a competition will not be for 15-30 years. So purchases now will be outdated then. Plus China has success within the current economic system. Why would they need to use an extensive military option. It is almost exclusively economic losers, who cannot deliver to their populace economically, that end up encouraging the outside the system, rogue state, terrorist elements.
<<

I see it just the opposite way. Because China has a rapidly growing economy, they _might_ be tempted to gain something like parity with the US militarily. By spending as much as we do on the DoD, we are signaling to China that we are willing to spend whatever it takes to prevent this from happening (and, we have a decades-old running start, to boot). By making it clear up front just how expensive a proposition this will be from the outset, we dissuade China from the temptation alluded to above and, hence, actually end up spending less than we would if we were to be engaged in an arms race.

This will work so long as the US military supremacy is not perceived as an existential threat to China. While there are certainly points of friction between ourselves and China in military terms (Taiwan being foremost), it is pretty clear that this is not the case today and is unlikely to be the case in the near future. Even as regards Taiwan, we currently have a rough but workable tacit agreement between us. The US officially agrees with China to the fiction that China and Taiwan are not separate countries and agrees in the desirability of political union between the two at some (unspecified) future time. China, for its part, agrees to live with fact that, de facto, Taiwan has a government that is not controlled in Beijing and will not take military steps to change this so long as Taiwan does not declare its independence de jure.

[Brian Wang]

Instead of the US spending money on the DOD to discourage China from an arms race with a "look how much money we are willing to spend".

The US and China could each adopt a minimal deterrence strategy vis-a-vis each other. The US has enough military capability to deter any rational opponent. I would argue that the Chinese leadership is rational.

Then any extra money that either side uses for stock piled weaponry is not useful.

Since neither side would have enough military advantage or the will to fight the other since. Even now with the US far in the lead china could still inflict a hundred million casualties on the US. In the future, both sides will be able to fairly easily maintain that level or higher deterrence. Extra deterrence is a waste if you are not actually trying for military domination.

Then money spent building the economy and technology would be better.

I believe that better technology spending by the US on the projects I mentioned previously could start ratcheting up the economic growth rate of the USA. By increasing the growth rate and economic size of the USA, the US could maintain a larger economy that China for far longer and maybe indefinitely.

If China blows by the US economically say to three times the size of the US economy. Then it will be easy for China to get parity with the US and even exceed the USs military. The example is how easy it was for the US to overmatch the USSR even when the USSR was spending 20% of its economy on defense while the US spent about 5%. The bigger economy is where this competition is between China and the USA. Don't grow fast enough and you are on track to irrelevance. (See Europe and Japan.)

[Chris Phoenix, CRN]

Greg, the nasty bug situation you described isn't news to me--remember that I was an embedded programmer on RTOS.

We need to separate, to the extent possible, the conversations about debugging and QA. After thinking about your scenario in detail, I'm still convinced that a lavishly overpowered system, in which the software is broken horizontally into little pieces that can't twiddle each other's bits unnoticed, could speed debugging by an order of magnitude.

If a programmer knows a complete input state, a complete output state, and is familiar with a linear chain of code that led from one to the other, then it doesn't matter if that code is 10,000 lines long--that bug is usually dead within the hour. And if the data is trustworthy, the bug shouldn't have to be evoked twice.

You didn't describe multiple rare situations combining to create a bug--you described multiple bugs combining to create a mess. But even that mess is mostly untangle-able if you can see every bit of communication between processes.

Now, I'll admit that if you have a sequence of independent bugs, and the first one messes up the system in a way that makes it hard to find the second one, but the second one only happens as a result of the first--but is nonetheless a separate bug--then I can't guarantee to find both bugs from a single event, and after fixing the first, the second may not crop up again during testing.

I am still certain I can reduce debugging time by an order of magnitude (and BTW, the company I worked for built products with a process already an order of magnitude faster than several big competitors). I had hoped to reduce QA time as a result, but perhaps not. So let me ask a different question, going back to something you said a while ago about the time required for planning SQA.

If you as an SQA planner knew that a system was divided vertically into layers that wouldn't interact, would that speed the SQA process? Suppose you could test a layer of functionality--say, keeping the control surfaces at the commanded angles... and then, knowing it was reliable, test the layer above--say, the autopilot... and then, knowing how that worked, test the flight path layer... then the navigation layer... knowing for sure that a buffer overrun in the autopilot *could not* corrupt data in navigation, and vice versa... would that speed SQA any? I'd think it would make your test matrices much smaller.

Chris

[Chris Phoenix, CRN]

Greg, "One lesson I believe that we can take away from the Cold War is that in the absence of dependable knowledge of the military capabilities of prospectively hostile powers, speculation will create bogey-men where none exist. In this environment, war is more likely than if everyone knows what everyone else is doing."

I might take away a slightly different lesson. Uncertainty and incomplete knowledge (along with international distrust) allow defense contractors and their partners in government to make a case for building all sorts of pricey weapons systems.

But the result of my lesson is the same as yours: war is more likely.

I don't think it's being partisan to add that incomplete knowledge about Iraq led to unfounded fears that made war a lot more likely there.

Chris

[Greg]

>>I believe that better technology spending by the US on the projects I mentioned previously could start ratcheting up the economic growth rate of the USA. By increasing the growth rate and economic size of the USA, the US could maintain a larger economy that China for far longer and maybe indefinitely.

If China blows by the US economically say to three times the size of the US economy. Then it will be easy for China to get parity with the US and even exceed the USs military. The example is how easy it was for the US to overmatch the USSR even when the USSR was spending 20% of its economy on defense while the US spent about 5%. The bigger economy is where this competition is between China and the USA. Don't grow fast enough and you are on track to irrelevance. (See Europe and Japan.)<<

Some thoughts here:

1) US military spending is not "aimed" at China per se (and we should take care that it not be perceived as such, lest it create a rival unnecessarily) but discourages anyone else from trying to play "king of the hill". For this reason, the bilateral agreement you suggest is not a great substitute. Add to this the fact that the military spending provides us with capabilities we desire completely apart form the deterrence I spoke of, (a primary example of such capability being the ability to project power to wherever it is felt to be needed) and a bilateral agreement becomes even a worse trade off.

2) Combine the above with the fact that the spending devoted to DoD is, in terms of recent (i.e. Cold War) history, a very sustainable sum even after factoring in post 9/11 spending hikes.

3) That the US could match China's growth rate is an exercise in implausibility. Given the sizes of the US and Chinese economy, the US would have to grow by an amount equal to the whole Chinese economy every 18 months to keep pace with China's growth rate. We can't do that (Absent advanced MM and *powerful* design AI to complement it). China can't either, which is why their growth will tail off as they get bigger. I note that there are alternative ways of figuring GDP using Purchasing Power Parity that make the Chinese economy out to be substantially larger than I am assuming. I reject the use of PPP in this context because the whole concept behind it is to account for the fact that things can be had more cheaply in China (in this instance). The reason I do this is that World Class militaries cost world class bucks. What you can buy at cheap local prices is essentially what the PLA is now, a numerically large but outdated force structure.

4) Size of economy isn't everything. We were able to spend the USSR into the ground during the Cold War not simply because our economy was much bigger than theirs, but also because their economy was _massively_ dysfunctional to its very core. To risk sounding like a shill for Max Boot, War Made New details any number of instances where the smaller poorer side was able do develop and field a military capable of mauling that fielded by the bigger richer adversary.

[Brian Wang]

I am speaking bilaterally because China and the US are the ones who will be competing for top economy from 2013+. India could factor in later. I do not think there are any other potential king of the hill candidates.

The lower level for the two in the lead would still be higher than any other paupers or princes.

It would not remove the project power capability.

Is the US economy being the most it can be?

In terms of increasing the maximum non-inflationary economic growth rate of a country. The productivity in the economy needs to be increased.

http://stlouisfed.org/publications/re/2001/c/pages/lead-article.html

If we get to molecular manufacturing sooner and to exponential manufacturing then we will get to faster productivity increases.

Getting to real technological advances that drive productivity and you can get to faster economic growth.

Historically, productivity booms have followed technological breakthroughs that had widespread commercial applications. The industrial revolutions of the 18th and 19th centuries were associated with the introduction of new general purpose technologies, such as the steam engine and electric power, which had numerous applications throughout the economy. The computer also appears to be a general purpose technology and an important source of the recent increase in productivity and economic growth.

Those kind of productivity and widely applicable technologies seem to be within reach. The faster they are reached. The sooner the economy can slip into a faster gear without triggering inflation.

Unless we get to new technologies that change the military situation, we will currently be in pretty much a stalemate situation for the big powers.

We are in agreement on PPP.

I don't believe in new war. I believe that different sides can mismanage a war and make it look like the smaller more ruthless force has come up with something new. But I think the reality is that the big side may not be willing to use the tactics that will work to crush the smaller, poorer guy.
If the line is drawn around a larger and attackable group containing the smaller force. Then full destructive force is used until those within the line unconditionally surrender. that would work. Old war would beat new war.

Size of economy matters unless you are counting on the other side being a military or procurement chump. Is the other side building a maginot line? Are they unwilling to use their forces to their full destructive force? Trying to fight antiseptically?

[Greg]

>>We need to separate, to the extent possible, the conversations about debugging and QA
. After thinking about your scenario in detail, I'm still convinced that a lavishly overpowered system, in which the software is broken horizontally into little pieces that can't twiddle each other's bits unnoticed, could speed debugging by an order of magnitude.<<

Sometimes separating the two is problematic even if they are being done by different individuals, as is often the case. The reason is that debug, fix, and build a new version of the software often drives test schedules (note that this is particularly true in circumstances like that you posit, where massively parallel test platforms are able to heavily pare down the time needed for test execution).

>>Now, I'll admit that if you have a sequence of independent bugs, and the first one messes up the system in a way that makes it hard to find the second one, but the second one only happens as a result of the first--but is nonetheless a separate bug--then I can't guarantee to find both bugs from a single event, and after fixing the first, the second may not crop up again during testing.<<

If you can fix enough components of the problem in a "perfect storm" scenario, you may be able to successfully complete testing, but only at the price of leaving latent (and lurking) the unnoticed bugs (the finding of which, I remind, is the purpose for testing in the first place).

>>If you as an SQA planner knew that a system was divided vertically into layers that wouldn't interact, would that speed the SQA process? Suppose you could test a layer of functionality--say, keeping the control surfaces at the commanded angles... and then, knowing it was reliable, test the layer above--say, the autopilot... and then, knowing how that worked, test the flight path layer... then the navigation layer... knowing for sure that a buffer overrun in the autopilot *could not* corrupt data in navigation, and vice versa... would that speed SQA any? I'd think it would make your test matrices much smaller.<<

Actually, it wouldn't. First off, I believe you are making an unwarranted assumption. The various layers and components of the system can have clean interfaces, well defined interfaces, but they must *have* interfaces. If they don't, you don't have a system, you have a set of components flying in loose formation (whether or not those components comprise a helicopter. For those confused by this last, see the comments on this web page: http://www.physicsforums.com/archive/index.php/t-126816.html ). The auto-pilot layer must talk to the control surface layer, and talk frequently in all probability. This means that even if control surface and auto-pilot have been through their paces separately without incident, there is still the possibility of them failing to act correctly in concert. Separate verification of components, whether on the same layer or of those constituting different layers of the system, is fairly standard in my experience and, to the extent that this is the case, the resulting benefits have already been factored into the software engineering of the system

The other big reason why this fails to speed things up for me is that, in general, by the time software is passed to me to verify, the components (tested separately or not) have almost invariably already been integrated into a system (or at least a partial system that is complete enough to that the missing bits won't have too much of an initial impact on the testing I am doing). The requirements that I work from are, as a rule, system level requirements. To use the UAV example, I will be asked to verify something like: The system shall require no more than 15 seconds to complete any mission profile alteration (including the time to decrypt the update from the secure data link). In this example, I typically would not be doing separate timing of the decryption process. I would, instead, try to come up with the most time consuming update to the mission profile possible and time things end-to-end. I have no reason to believe my experience to be atypical of formal SQA done elsewhere. As a result, what benefits there are to clean and modular design, in terms of impact on SQA schedule come mainly from making it easier than might otherwise be the case to find and fix bugs that I find, without introducing more in the process. As you may have noticed, this brings us conveniently full circle right to where I started this comment ;-)

Greg- still leery about the notion of an order of magnitude speed-up, sans Strong AI

[Chris Phoenix]

Greg - Sorry to have taken so long to respond to this.

I don't have more arguments to make at this point. Except that if we got to a point where SQA required an order of magnitude more time than the rest of the project combined (including software writing and debugging), people would find *some* way to get around that. Perhaps do as Google has done--deploy a beta and let thousands of real users pound on it for years.

Chris

[Greg]

>>Greg - Sorry to have taken so long to respond to this.<<

No problem as far as I am concerned, even if you had responded more quickly, I would have been fighting off a nasty cold (my first in several years), so in terms of round-trip time everything evens out.

>>I don't have more arguments to make at this point. Except that if we got to a point where SQA required an order of magnitude more time than the rest of the project combined (including software writing and debugging)<<

Let me clarify my thoughts here, while I claim that SQA is a part of software development that, past a certain point, resists attempts to speed it up by use of automation, masses of hardware, and the like, I am _not_ claiming that it is uniquely resistant in this respect. Other phases: Requirements gathering/Spec writing and high-level Architecture/System Design come to mind, share the property of requiring actual non-trivial understanding of what the system is really all about such that I believe it would take strong AI to be able to do this function. Now it might be that there is a very significant component of these tasks that can be separated out and automated without needing strong AI, while I am dubious about this prospect I cannot speak as authoritatively about them as I can about SQA (which is the reason I chose to address the issue in terms of SQA in the first place).

>> people would find *some* way to get around that.<<

While asserting this is all well and good, let me suggest that for an on-going (as opposed to hypothetical) software development effort, someone in charge counting on this happening (I hope you won't take offense if I refer to it as "Faith-Based Program Management") is something I have had occasion to observe and the results usually are not very pretty.

>>Perhaps do as Google has done--deploy a beta and let thousands of real users pound on it for years.<<

While there may well be circumstances like Google's where this is appropriate, let's return to the example that you were using at the outset of this discussion: an armed nano-UAV. I have already characterized such an application as one which requires that the UAV in question be both: A) Autonomous and B) Lethal. It may be the case that there is an application somewhere that is less suited to a Google-like: "Get some beta out there and see what breaks" approach, but I am hard pressed to think what that might be.

[Chris Phoenix, CRN]

Greg:

My impression, gathered only as a consumer, is that during the .com frenzy, it frequently took only a few months to go from idea to website. The website may not have had its full functionality, and it may have been buggy and crufty, but it made a stake in the ground that could then be advanced on incrementally.

I think Extreme Programming has a similar idea: start with a bare-bones project, and add to it incrementally, gathering user feedback along the way.

This approach allows some compression of the product conception, design, specification, and QA phases. If the project is well architected, then the core functionality will be quite well tested by the time the externals are added. If it's not well architected... well, the author of _The Mythical Man-Month_ advised, "Plan to throw one away," and I think that's good advice.

In today's reality, a buggy autonomous lethal weapon is only a problem if it puts your own people at risk. What do you think is the ratio of Iraqi combatants to civilians killed today? Would it be higher with buggy but rapidly-debugged autonomous weapons, and fewer justifiably paranoid occupying soldiers? And even if it were, would Americans care?

(I'm not entirely sure that the UAV would have to be autonomous. It might be remotely controlled. I'm sorry if I've forgotten the part of your argument that explains why the UAV would have to be autonomous.)

When I said that people would find a way around order-of-magnitude bottlenecks in the R&D cycle, I did not mean that people should count on that in any particular development program. I meant that new development methodologies would evolve which would not suffer the bottleneck.

I've obtained a copy of War Made New and have finished the Gunpowder Revolution section. One thing that seems clear is that while ability to develop new tactics was important in the beginning, by the end, the ability to adopt known tactics was all-important. "The West" could do it--train soldiers, plan logistics, and place the focus of decision away from both the top (rulers) and the bottom (warriors). "The Rest" couldn't.

The account of the British in India makes it clear that expectation is a large part of success. Ignore the odds--just go in expecting to win, and you will... if your audacity is matched by your ability... but audacity can find ways to extract the last drop of value from ability.

I have no doubt that a lot of military organizations, given a nanofactory, would be unable to break free of today's design cycle.

I also have very little doubt that a small, smart, audacious group of developers, if asked to speed up the entire design cycle by an order of magnitude, could do so. I don't know exactly how. I don't know if a small group that did so would be world-changing... but remember Sweden.

I strongly suspect that with a few years of practice--some of which could be obtained prior to nanofactory availability--a design flow could be developed that would speed up the design cycle by *two* orders of magnitude. It might not have QA at all. It might involve thousands of civilian hobbyists watching the battle in real-time and thinking up new weapon designs to solve real-time problems. It might involve modular weapons.

Think of a warplane being loaded with a mix of missiles and bombs for a particular mission. Now think of a tank commander deciding which type of round to fire next--a much faster process. Now imagine a UAV with 100 tiny payload bays of 100-gram capacity. Knowing the approximate mission parameters, designers bid for slots. Up to 100 payloads from 100 designers are selected and loaded; the UAV flies over an enemy city; each designer gets to control deployment of their payload. The payloads that do the most damage, and future payloads from those designers, are loaded more often; the designers are paid; and the designs are published for others to learn from. How quickly would payloads evolve?

Your reaction--that you can't think of a less appropriate setting for a Google-like beta-launch approach than a battlefield--will probably be shared by most militaries. Would you expect a soldier to launch a weapon without knowing what it would do? No... but somewhere out there is a Sweden that will eat our lunch someday, because they will be willing to do that.

Chris

[Chris Phoenix, CRN]

Brian - "I don't believe in new war. I believe that different sides can mismanage a war and make it look like the smaller more ruthless force has come up with something new. But I think the reality is that the big side may not be willing to use the tactics that will work to crush the smaller, poorer guy."

Having read the first 111 pages of War Made New by Max Boot, I'll second Greg's recommendation.

It is not always ruthlessness that wins battles. Ruthlessness was part of why France took Italy in 1494. But several factors combined to let England defeat the Spanish Armada - better guns, better tactics, more inventiveness, the use of fireboats to panic the Spanish at a key encounter...

Gustavus Adolphus of Sweden was clearly innovative. I don't think anyone could say the Spanish army was lacking in ruthlessness. But Gustavus simply used his guns and pikes in a far more efficient way--he invented it, so the Spanish were not unwilling but unable to adopt it--they didn't know about it!

In India, the Marathas knew about European tactics and discipline, and hired European officers, but were institutionally unable to adopt the new methods fully. Here it was lack of a good command structure, and not lack of ruthlessness, that led the Maratha calvary to stand idle while the British mopped up the Maratha infantry at Assaye.

Anyone who thinks that superior numbers can always win need only look at the Spanish conquest of South America.

Chris