• Choose a category
• All
• Classic-Fiction

It's ironic, then, that one of the things that real people demonstrably do not want in their present situation is everyware. There is no constituency for it, no pent-up demand; you'll never hear someone spontaneously express a wish for a ubiquitous house or city. There are days, in fact, when it can seem to me that the entire endeavor has arisen out of some combination of the technically feasible and that which is of interest to people working in human-computer interaction. Or worse, much worse: out of marketing, and the desire to sell people yet more things for which they have neither a legitimate need nor even much in the way of honest desire.

What people do want, and will ask for, is more granular. They want, as Mark Weiser knew so long ago, to be granted a god's-eye view of the available parking spaces nearby, to spend less time fumbling with change at the register, to have fewer different remote controls to figure out and keep track of.

And, of course, everyware is the (or at least an) answer to all of these questions. But until those of us in the field are better able to convey this premise to the wider world in convincing and compelling detail, we can expect that adoption will be significantly slower than might otherwise be the case.

Thesis 59

The necessary processor speed already exists.

Of the major limiting factors on ubiquitous computing, one of the most vexing—and certainly the most fundamental—has always been processor speed. The challenges posed by the deployment of computing out in the everyday environment, whether parsing the meaning of a gesture in real time or tracking 500 individual trajectories through an intersection, have always been particularly processor-intensive.

But if processor speed has historically constituted a brake on development, it needn't any longer. The extravagance of computational resources such applications require is now both technically feasible and, at long last, economic.

The machine I am writing these words on operates at a clock speed of 1.5 GHz—that is, the internal clock by which it meters its processes cycles 1.5 billion times every second. While this sounds impressive enough in the abstract, it's not particularly fast, even by contemporary standards. Central processors that operate more than twice as fast are widely commercially available; a 2004 version of Intel's Pentium 4 chip runs at 3.4 GHz, and by the time this book reaches your hands, the CPU inside the most generic of PCs will likely be faster yet.

We know, too, that relying on CPU clock speeds for estimates of maximum speed can be deceptive: such general-purpose chips are held to speeds well below the theoretical maximum, while specialized chips can be optimized to the requirements of a particular application—video or sound processing, encryption, and so on. In synchrony, CPUs and specialized chips already handle with aplomb the elaborate variety of processor-intensive applications familiar from the desktop, from richly immersive games to real-time multiway videoconferencing.

In principle, then, a locally ubiquitous system—say, one dedicated to household management—built right now from commonly available CPUs and supported by a battery of specialized helpers, should be perfectly adequate to the range of routine tasks foreseeable in such a setting. Excepting those problems we've already identified as "AI-hard," which aren't as a rule well-suited to brute-force approaches anyway, there shouldn't be anything in the home beyond the compass of such a system.

Especially if a grid architecture is employed—if, that is, the computational burden imposed by more convoluted processes is distributed through the constellation of locally-embedded processors, working in parallel—today's clock speeds are entirely adequate to deliver services to the user smoothly and reliably. Whatever challenges exist, it's hard to imagine that they would be order-of-magnitude harder than supporting an iRoom-style collaborative workspace, and that was achieved with 2001-vintage