Two things. Firstly it took a long time, 50 years or so, before it was possible to operate a car with such little knowledge of its operating principles. A lot of reliability engineering was needed, and a lot of user interface standardisation (like the steering wheel, and which way it turns).
Secondly, one of the truly remarkable things about computers, and software is how much it is possible to gain from using them, even when you don't actually understand very much about how to use them, or anything about how they work, and even when they work pretty badly and unreliably (like most current software). Just think how much we'll be able to do when (a) they're built right, and (b) we all know how to use them
1. The focus issue depends on the distance. To focus an optical beam (500nm wavelength) on a 1km sail at distance d meters, you need an aperture over which the laser is coherent of:
5*d*10^-10 m
so, at d = 40 000km (Geostatioery orbit distances) you need 20 mm aperture (perfectly standard laser aperture, off-the-shelf)
at d = 400 000km (lunar distances) you need 20cm aperture, so some reasonable optics, but nothing silly
at d = 60 000 000 km (Mars orbit insertion, using Earth based lasers) you need 30m aperture. This could probably be done, but is exceeding proven technology
at d = 10^9km (outer solar system) you need a 500m diameter coherent laser source. We have no real idea how to do that.
at d = 10^16m (1 parsec) you need a 5000 km diamater coherent laser source to focus your beam onto the 1km sail.
2. This is easy to calculate. You have to balance the ability of your sail to radiate away the absorbed energy with its strength and its reflectivity. I believe the best bet was thought to be a tungsten foil. Aluminium is more reflective, but not nearly as strong.
4. see 1.
5. The other win with light is that the momentum transfered to the spaceship does not degrade quickly with the speed of the ship. If you use a slower beam, you get more momentum/energy initially, but as the speed of the ship gets up towards that of the beam it becomes less useful
Recent data, including that from the Gallileo entry probe suggests that Jupiters atmosphere is highly convective. Anything drifting in the atmoshphere would be regularly sucked down to extreme depths, and thereby VERY thoroughly pressure-cooked, before being pushed back up to the surface again. Anything that could manage to live there (except, perhaps in some small, and unexpectedly stably non-convective corner somewhere) would have to be either very active (to deliberately stay at the top of the convective cycle) or much tougher than any molecule that we can think up. In either case, a few bacteria are unlikely to cause much trouble,
Patents have long since outlived their purpose -- the market encourages innovation without government enforced monopolies
This was not the purpose of patents, at least not originally. They were there to promote disclosure. If you were prepared to publish your idea, you got a time-limited monopoly. I'm not saying that the system still makes sense, but this was the original logic.
I think the situation at Googol is quite special. Although they have a TB of data, it is very slow changing (once per months, so about 300KB/sec) and what they have to do it is very (integer) CPU intensive. They remark that it distributes really well, so presumably network latency between the PCs isn't a problem, and locality of access to the data is good. Given that (see SpecCPU2000 for instance) Intel processors on cheap motherboards really is a big win for performance/purchase price.
This leaves the management questions. Presumably most of these PCs are configured exactly identically, apart from the ethernet card numbers, and the work is controlled by some central servers (for which big Suns might well be appropriate). So, if I was setting this up, how would I handle hardware failures:
1. a PC blows up 2. the central server notices some timeout on a parcel of work or a heart-beat and takes that node out of the active list. 3. the central server (or another one specialized for the job) makes a more intensive effort to sort out the problem. If it can get in, it can probably trigger a reboot, or even a re-install, remotely. 4. If it can't get in at all then human assistance is needed. Add a task "reset node 1234" to the next hourly jobs printout for the operator 5. On the next pass through that part of the warehouse, the operator hits reset. The node tries to reboot, goes through health tests, possibly does an auto reinstall. 6. If no life then add it to the daily list for the operator with the electric handcart to pull and replace, send it in the daily shipment to the supplier.
I don't know for sure that this is how they do it, but it's how I would do it. Failure is a nuisance when it happens every few weeks. If it happens every few hours, then you can make it routine and pain-free. In a cluster of 4000 identical machines, hardware failures are part of life.
You mention other things: power -- a bare PC processor mobo and hard drive draws about 90W. So the whole cluster is about 360KW. This is a lot of power to get in, and heat to get out, but well within the normal range of, for instance, small factories, and the people who supply kit for that should be able to cope easily. PCs will work OK in any heat and humidity that people will, so ordinary office-grade air-conditioning will be fine.
So, in their very unusual circumstances, this probably is the right call for Google. They can routinize hardware failures to the point where they just cause a statistically predictable amount of work that must be budgetted for. The central servers that control all this, store the TB database, etc. are another story. There, the more conventional rules apply, and I would bet that those are normal server hardware -- Sun, IBM or high-end Intel servers.
Realistically, despite the hype, this is not going to go to the VILLAGES in India (which may well not have railway stations, or reliable electricity) but to the smaller cities and towns. This seems a sensible step. In such a town, there will be a significant group who can speak, read and write English (school teachers, medical people, administrators) and a very plausible demand for email communication with other towns and higher levels of government heirarchy, and for access to information that the government can put on the Web.
I suspect the main market for the cybercafes will initially be tourists -- the Indian middle class is growing fast, but is mainly near the big cities, but if that subsidises an email and Web connection for the town doctor or secondary school, so much the better.
This is a good article. They eventually come down against using RDRAM for most purposes at the moment, but explain why they think it is a long term winner.
Briefly: bandwidth does matter some now, and will matter more. There is a real detectable gain from moving the RAM clock on any current system from 66 to 100 to 133 MHz, even if you fiddle with the settings to cancel out the latency gain. Forthcoming peripheral technologies: AGP 4x, 66MHz PCI busses, ATA-100, will all place more demand on memory bandwidth. Now, SDRAM has a fairly clear route to about 2.1 or maybe 2.6 GB/s bandwidth (DDR at up to 166MHz) but no obvious path beyond there.
DRDRAM can go up to about 3.2 GB/s per bus (800MHz DDR x 16 bits) eventually, and does 1.6GB/s per bus now. This is broadly comparable with SDRAM. On the other hand fitting two or more SDRAM busses onto a motherboard seems pretty hopeless for general purposes. The track count would be very silly indeed. Intels 840 chipset already supports 2 RDRAM busses. In terms of track count, it would not be inconceivable to get 4 onto a motherboard. This is the key advantage of RDRAM: lower track counts, allowing multiple busses. I have yet to hear how any SDRAM solution can beat this in the medium term. On the other hand this is for the medium term. In the short term, RDRAM is only a good deal if you don't need too much, and you really need peack bandwidth.
I always buy IBM drives for file servers. I have NEVER had one fail on me, and I have had all too many failures from other suppliers. The price difference is not extreme, and the hassle reduction is huge.
A Sun Ultra 300 is 100 by definition, twice as big a number means that the test took half as long.
There are no Athlon figures up (anyone know them?).
Conclusion, the current generation of alphas really screams. A 1.2GHz version should be quite something! HP stays ahead in the astonishingly much performance per MHz ratings, pursued by IBM.
Space is pretty empty. If you stay away from the close vicinty of planets (low Earth orbit, Saturn's or Jupiter's rings, etc.) then you are pretty much safe from anything larger than a very small grain of dust. Presumably the sail is designed to limit the damage done by such grains (like ripstop nylon).
The best trajectory to get benefit from the Sun depends on the level of thrust that can be achieved. If it is high enough to get well beyond solar escape velocity in one perihelion pass close to the Sun then that is the thing to do. A swing by Jupiter may be the way to get that close perihelion pass (Ulysses did something similar).
If not, then you might as well just spiral out from wherever you are, there's nothing to gain by spiralling out from close in.
The first remark is that this is VERY far from a man-carrying mission. The second is to see "Robert L Forward's "The Flight of the Dragonfly" for lots of technical detailsof a hypothetical laser-pushed man-carrying sail. As I recall, the sail was 2000 miles across, and the laser array consumes about 10^16 Watts of solar enegry. Even so, he had to resort to "magical" drugs to keep his crew alive long enough.
He used one method of stopping: cut off the outer part of the sail and use it to reflect the laser beam back onto the central section which carries the crew.
I have heard two others proposed, both in the "The Mote in God's Eye":
1. dump all excess mass and dive very close to the target star. Hope to stop before you fry.
2. charge the ship up to a high voltage and use the galactic magnetic field to spin you around, enter the target system from behind and use the original laser beam to brake.
Antimatter rockets are starting to look like a better deal for interstellar trips.
As we are seeing with Linux, one of the most profitable (or least loss-making) services to provide is that of identifying, quality-controlling, and wrapping up a set of mutually compatible versions of software. This is RedHat's core business, more or less, and is the main bottleneck for non-commercial distros like Debian.
While I could go out and find all the versions of all the software I need as tarballs or whatever, download them one at a time and resolve all the compatibility issues between them, I haven't the time. On the other hand, this activity has massive economies of scale. RedHat can do this task for me, assemble the results on a CD and sell millions of copies.
However, this brings the suits back into the loop. Sure the developers of package X have nothing except artistic pleasure and a desire for kudos to consider when deciding what features to add to version n+1 of their program, or when to release it, but RedHat suits will decide whether to put version n, or version n+1 or version n+1 pre 17 with a few of RHs own patches onto the CD, and they have marketing considerations in mind.
On the other hand, it's a BETTER market. There is less lockin, because all Linux distros are drawing on the same body of programs; the programs are ultimately better because people are working on them for love; and there is more information around to assess the suits' decisions against.
The thing to understand is that, as someone has said, XML is not, in itself, a representation format for anything. Instead it (and its cousins XSL etc.) are a framework for representation formats.
XML fixes a low-level syntax for identifying what is a tag, which is the matching close tag, etc. (like HTML without the meanings for the tags, and with some obvious (in hindsight) stupidities removed. By actually defining meanings for the tags, and specifying what tags are allowed in what contexts, you can then construct a representation format for some type of data.
So what is the point, I hear you cry! Well the point is that
1) The XML rules encourage you to be sensible in defining your format
2) Applications handling different XML-based formats can share large chunks of parser code
3) The common underpinning makes it much easier to work with hybrid documents that include data in multiple XML-based representation formats
4) Some limited processing and checking can be done just with the raw XML and perhaps the formal format specification (the DTD).
There is a problem with the "when it's ready" philosophy, which is that the release schedule of a piece of cooperatively developed software is bistable. In one mode, releases are frequent, so the "penalty" of your favourite feature being held over to the next release is small, and so the pressure to get features into the current release is reduced, and it is easier to make frequent releases. In the other mode, the opposite happens. Everyone wants their feature in the current release, because they don't know when the next one will be, so it gets harder and harder to get releases stable and out.
Perhaps it's a litlle far fetched for 2025, but I can see a scenario where the Information Corps becomes utterly crucial. Not just a vital support/espionage/sabotage operation, but actually the heart of the war.
Consider. War is essentially a matter of getting another country to do what you want. You could do this in various ways:
1. Kill off everyone living there and colonise it with your own supporters
2. March in a land army, kill off all the current rulers and their troops, install a regime, backed by said army, that will make the people do what you want.
3. Do enough damage to the country with sanctions, bombs, etc. that the current regime decided to do what you want to get you off their backs
Now consider the information Corps solution:
4. Take over their data networks, and send orders on behalf of the current regime to do what you wanted anyway. More sophisticated versions include faking input data to the regime so that it decides to do what you want, etc. An extreme version of this applies where the population of your enemy country has neural interfaces, and you hack those -- make the enemy people WANT to do what you want by hacking their brains.
In this scenario, the Information Corps is the "leading edge" of the war. Once you control their top-level C3 infrastructure, you have won, there is nothing else left to do. Other forces would be in support roles like nuking unhackable backup stores, kidnapping people who know key passwords, infiltrating secure areas to make network connections, destroying systems to trigger less secure failover procedures, etc.
The term comes from the Spanish for "little war" and originated in the Peninsular Campaign of the Napoleonic wars, when Spanish guerillas assisted by British gold, British ships and some Spanish regular soldiers made life hell for the French armies and French pupper regime.
I fancy wasnering down to our micro (and nano) engineering dept. here at Birmingham Uni (UK) and seeing if they could make a nano-sized version. Portable difference engines:) Ok, I know it'd only run for a few seconds before siezing (lubricant molecules are of the same order as some component dinemsions) but it'd still be cool.
Drexler's "Engines of Creation" (the seminal nanotech book) included some basic feasibility computations for nano-mechanical computers. They were binary not decimal, and based mainly on sliding rods rather than cogs, but the idea is there. Lubrication is not really the right way to think at those scales -- you simply have to make sure that none of the atoms on component A is going to bond to any atoms on component B in a way that you don't want. Fluorinating all the spare bonds at the surfaces works well.
I'd heard this too. It seems Babbage could have done it if he'd had the money and perhaps the Project Management skills. It wasn't an absolute problem with materials or machine tools.
Slashdot Mirror
Two things. Firstly it took a long time, 50 years or so, before it was possible to operate a car with such little knowledge of its operating principles. A lot of reliability engineering was needed, and a lot of user interface standardisation (like the steering wheel, and which way it turns).
Secondly, one of the truly remarkable things about computers, and software is how much it is possible to gain from using them, even when you don't actually understand very much about how to use them, or anything about how they work, and even when they work pretty badly and unreliably (like most current software). Just think how much we'll be able to do when (a) they're built right, and (b) we all know how to use them
1. The focus issue depends on the distance. To focus an optical beam (500nm wavelength) on a 1km sail at distance d meters, you need an aperture over which the laser is coherent of:
5*d*10^-10 m
so, at d = 40 000km (Geostatioery orbit distances) you need 20 mm aperture (perfectly standard laser aperture, off-the-shelf)
at d = 400 000km (lunar distances) you need 20cm aperture, so some reasonable optics, but nothing silly
at d = 60 000 000 km (Mars orbit insertion, using Earth based lasers) you need 30m aperture. This could probably be done, but is exceeding proven technology
at d = 10^9km (outer solar system) you need a 500m diameter coherent laser source. We have no real idea how to do that.
at d = 10^16m (1 parsec) you need a 5000 km diamater coherent laser source to focus your beam onto the 1km sail.
2. This is easy to calculate. You have to balance the ability of your sail to radiate away the absorbed energy with its strength and its reflectivity. I believe the best bet was thought to be a tungsten foil. Aluminium is more reflective, but not nearly as strong.
4. see 1.
5. The other win with light is that the momentum transfered to the spaceship does not degrade quickly with the speed of the ship. If you use a slower beam, you get more momentum/energy initially, but as the speed of the ship gets up towards that of the beam it becomes less useful
Recent data, including that from the Gallileo entry probe suggests that Jupiters atmosphere is highly convective. Anything drifting in the atmoshphere would be regularly sucked down to extreme depths, and thereby VERY thoroughly pressure-cooked, before being pushed back up to the surface again. Anything that could manage to live there (except, perhaps in some small, and unexpectedly stably non-convective corner somewhere) would have to be either very active (to deliberately stay at the top of the convective cycle) or much tougher than any molecule that we can think up. In either case, a few bacteria are unlikely to cause much trouble,
Um, no. A crore is 100 lakh and a lakh is 100 000. So the estimated cost is 3.5 x 10^10 rupees, which is about $10^9.
This is either very cheap for a manned mission or very expensive for a probe.
I believe that Intel does have trademarks on
hexium, sextium, heptium, septium and all plausible variations.
I think the situation at Googol is quite special. Although they have a TB of data, it is very slow changing (once per months, so about 300KB/sec) and what they have to do it is very (integer) CPU intensive. They remark that it distributes really well, so presumably network latency between the PCs isn't a problem, and locality of access to the data is good. Given that (see SpecCPU2000 for instance) Intel processors on cheap motherboards really is a big win for performance/purchase price.
This leaves the management questions. Presumably most of these PCs are configured exactly identically, apart from the ethernet card numbers, and the work is controlled by some central servers (for which big Suns might well be appropriate). So, if I was setting this up, how would I handle hardware failures:
1. a PC blows up
2. the central server notices some timeout on a
parcel of work or a heart-beat and takes that node out of the active list.
3. the central server (or another one specialized for the job) makes a more intensive effort to sort out the problem. If it can get in, it can probably trigger a reboot, or even a re-install, remotely.
4. If it can't get in at all then human assistance is needed. Add a task "reset node 1234" to the next hourly jobs printout for the operator
5. On the next pass through that part of the warehouse, the operator hits reset. The node tries to reboot, goes through health tests, possibly does an auto reinstall.
6. If no life then add it to the daily list for the operator with the electric handcart to pull and replace, send it in the daily shipment to the supplier.
I don't know for sure that this is how they do it, but it's how I would do it. Failure is a nuisance when it happens every few weeks. If it happens every few hours, then you can make it routine and pain-free. In a cluster of 4000 identical machines, hardware failures are part of life.
You mention other things: power -- a bare PC processor mobo and hard drive draws about 90W. So the whole cluster is about 360KW. This is a lot of power to get in, and heat to get out, but well within the normal range of, for instance, small factories, and the people who supply kit for that should be able to cope easily. PCs will work OK in any heat and humidity that people will, so ordinary office-grade air-conditioning will be fine.
So, in their very unusual circumstances, this probably is the right call for Google. They can routinize hardware failures to the point where they just cause a statistically predictable amount of work that must be budgetted for. The central servers that control all this, store the TB database, etc. are another story. There, the more conventional rules apply, and I would bet that those are normal server hardware -- Sun, IBM or high-end Intel servers.
Realistically, despite the hype, this is not going to go to the VILLAGES in India (which may well not have railway stations, or reliable electricity) but to the smaller cities and towns. This seems a sensible step. In such a town, there will be a significant group who can speak, read and write English (school teachers, medical people, administrators) and a very plausible demand for email communication with other towns and higher levels of government heirarchy, and for access to information that the government can put on the Web.
I suspect the main market for the cybercafes will initially be tourists -- the Indian middle class is growing fast, but is mainly near the big cities, but if that subsidises an email and Web connection for the town doctor or secondary school, so much the better.
This is a good article. They eventually come down
against using RDRAM for most purposes at the moment, but explain why they think it is a long term winner.
Briefly: bandwidth does matter some now, and will matter more. There is a real detectable gain from moving the RAM clock on any current system from 66 to 100 to 133 MHz, even if you fiddle with the settings to cancel out the latency gain. Forthcoming peripheral technologies: AGP 4x, 66MHz PCI busses, ATA-100, will all place more demand on memory bandwidth. Now, SDRAM has a fairly clear route to about 2.1 or maybe 2.6 GB/s bandwidth (DDR at up to 166MHz) but no obvious path beyond there.
DRDRAM can go up to about 3.2 GB/s per bus (800MHz DDR x 16 bits) eventually, and does 1.6GB/s per bus now. This is broadly comparable with SDRAM. On the other hand fitting two or more SDRAM busses onto a motherboard seems pretty hopeless for general purposes. The track count would be very silly indeed. Intels 840 chipset already supports 2 RDRAM busses. In terms of track count, it would not be inconceivable to get 4 onto a motherboard. This is the key advantage of RDRAM: lower track counts, allowing multiple busses. I have yet to hear how any SDRAM solution can beat this in the medium term. On the other hand this is for the medium term. In the short term, RDRAM is only a good deal if you don't need too much, and you really need peack bandwidth.
I always buy IBM drives for file servers. I have NEVER had one fail on me, and I have had all too many failures from other suppliers. The price difference is not extreme, and the hassle reduction is huge.
Not in SPECint2000, according to the figues above, although a 1GHz Athlon might five it a run for its money on your figures.
Try SPEC at http://www.spec.org . They have a very nice configurable search system for their CPU95 and CPU2000 benchmark results databases.
To take a few high points from the current data:
alpha 21264 667MHz, integer 424, FP 514
Pentium III 1GHz, integer 407, FP 273
HP PA-RISC 8600 552MHz integer 367, FP 338
Pentium III 800MHz integer 361, FP 260
Power-3 375MHz integer 248, FP 330
Sun Ultra 333MHz integer 133, FP 128
A Sun Ultra 300 is 100 by definition, twice as
big a number means that the test took half as long.
There are no Athlon figures up (anyone know them?).
Conclusion, the current generation of alphas really screams. A 1.2GHz version should be quite something! HP stays ahead in the astonishingly much performance per MHz ratings, pursued by IBM.
Space is pretty empty. If you stay away from the close vicinty of planets (low Earth orbit, Saturn's or Jupiter's rings, etc.) then you are pretty much safe from anything larger than a very small grain of dust. Presumably the sail is designed to limit the damage done by such grains (like ripstop nylon).
The best trajectory to get benefit from the Sun depends on the level of thrust that can be achieved. If it is high enough to get well beyond solar escape velocity in one perihelion pass close to the Sun then that is the thing to do. A swing by Jupiter may be the way to get that close perihelion pass (Ulysses did something similar).
If not, then you might as well just spiral out from wherever you are, there's nothing to gain by spiralling out from close in.
Steve
The first remark is that this is VERY far from a man-carrying mission. The second is to see "Robert L Forward's "The Flight of the Dragonfly" for lots of technical detailsof a hypothetical laser-pushed man-carrying sail. As I recall, the sail was 2000 miles across, and the laser array consumes about 10^16 Watts of solar enegry. Even so, he had to resort to "magical" drugs to keep his crew alive long enough.
He used one method of stopping: cut off the outer part of the sail and use it to reflect the laser beam back onto the central section which carries the crew.
I have heard two others proposed, both in the "The Mote in God's Eye":
1. dump all excess mass and dive very close to the target star. Hope to stop before you fry.
2. charge the ship up to a high voltage and use the galactic magnetic field to spin you around, enter the target system from behind and use the original laser beam to brake.
Antimatter rockets are starting to look like a better deal for interstellar trips.
Steve
As we are seeing with Linux, one of the most profitable (or least loss-making) services to provide is that of identifying, quality-controlling, and wrapping up a set of mutually compatible versions of software. This is RedHat's core business, more or less, and is the main bottleneck for non-commercial distros like Debian.
While I could go out and find all the versions of all the software I need as tarballs or whatever, download them one at a time and resolve all the compatibility issues between them, I haven't the time. On the other hand, this activity has massive economies of scale. RedHat can do this task for me, assemble the results on a CD and sell millions of copies.
However, this brings the suits back into the loop. Sure the developers of package X have nothing except artistic pleasure and a desire for kudos to consider when deciding what features to add to version n+1 of their program, or when to release it, but RedHat suits will decide whether to put version n, or version n+1 or version n+1 pre 17 with a few of RHs own patches onto the CD, and they have marketing considerations in mind.
On the other hand, it's a BETTER market. There is less lockin, because all Linux distros are drawing on the same body of programs; the programs are ultimately better because people are working on them for love; and there is more information around to assess the suits' decisions against.
Bad question as it stands. The books were a spin-off from the radio series.
The thing to understand is that, as someone has said, XML is not, in itself, a representation format for anything. Instead it (and its cousins XSL etc.) are a framework for representation formats.
XML fixes a low-level syntax for identifying what is a tag, which is the matching close tag, etc. (like HTML without the meanings for the tags, and with some obvious (in hindsight) stupidities removed. By actually defining meanings for the tags, and specifying what tags are allowed in what contexts, you can then construct a representation format for some type of data.
So what is the point, I hear you cry! Well the point is that
1) The XML rules encourage you to be sensible in defining your format
2) Applications handling different XML-based formats can share large chunks of parser code
3) The common underpinning makes it much easier to
work with hybrid documents that include data in multiple XML-based representation formats
4) Some limited processing and checking can be done just with the raw XML and perhaps the formal
format specification (the DTD).
Steve
I rather thought the +-21 and +-24 terms which are roughly as you have them, came from Finnish.
Steve
There is a problem with the "when it's ready" philosophy, which is that the release schedule of a piece of cooperatively developed software is bistable. In one mode, releases are frequent, so the "penalty" of your favourite feature being held over to the next release is small, and so the pressure to get features into the current release is reduced, and it is easier to make frequent releases. In the other mode, the opposite happens. Everyone wants their feature in the current release, because they don't know when the next one will be, so it gets harder and harder to get releases stable and out.
Steve
It's also worth noting that this is a totally different process.
Perhaps it's a litlle far fetched for 2025, but I can see a scenario where the Information Corps becomes utterly crucial. Not just a vital support/espionage/sabotage operation, but actually the heart of the war.
Consider. War is essentially a matter of getting another country to do what you want. You could do this in various ways:
1. Kill off everyone living there and colonise it with your own supporters
2. March in a land army, kill off all the current rulers and their troops, install a regime, backed by said army, that will make the people do what you want.
3. Do enough damage to the country with sanctions, bombs, etc. that the current regime decided to do what you want to get you off their backs
Now consider the information Corps solution:
4. Take over their data networks, and send orders on behalf of the current regime to do what you wanted anyway. More sophisticated versions include faking input data to the regime so that it decides to do what you want, etc. An extreme version of this applies where the population of your enemy country has neural interfaces, and you hack those -- make the enemy people WANT to do what you want by hacking their brains.
In this scenario, the Information Corps is the "leading edge" of the war. Once you control their top-level C3 infrastructure, you have won, there is nothing else left to do. Other forces would be in support roles like nuking unhackable backup stores, kidnapping people who know key passwords, infiltrating secure areas to make network connections, destroying systems to trigger less secure failover procedures, etc.
The term comes from the Spanish for "little war" and originated in the Peninsular Campaign of the Napoleonic wars, when Spanish guerillas assisted by British gold, British ships and some Spanish regular soldiers made life hell for the French armies and French pupper regime.
Yep. You can find it from http://www.fourmilab.ch by dearching for "analytical". Thanks.
I'd heard this too. It seems Babbage could have done it if he'd had the money and perhaps the Project Management skills. It wasn't an absolute problem with materials or machine tools.