Inventing the Future

Mesh Networks

, , , ,

There’s an interesting short editorial in Tech Review about the significance of mesh networks. This is where wireless networks can be made from a vast network of independent, individually owned, volunteer peers, rather than a centralized distribution of wires or radios towers. The essay brings together three themes of Wetmachine.

The technology is an overlay on a self-organizing P2P network, closely related to Croquet and the Internet itself, and a strong interest of Croquet and TCP/IP architect David Reed. There’s “Inventing the Future.”

The essay then mentions how such networks are not owned by anyone, and that this effects commercial network carriers, particularly for the “last mile.” There’s “Tales of the Sausage Factory.” (Indeed, I am indebted to Harold for first exposing me to this powerful technology, right here on Wetmachine.)

Finally, the editor broaches the cybernetic quality of these beasts. Meshes draw inspiration from the behavior of swarming bees, so might not there be emergent properties in such meshes that go beyond sterile function? There’s our host John Sundman, whose “Cheap Complex Devices” draws more than a casual comparison between a swarm and human consciousness — or is it computer consciousness?

TeaTime in a Nutshell, by My Daughter

,

My oldest daughter (age 13) just “independently” invented Croquet. Or more specifically, she’s reinvented the underlying computation model called TeaTime. She’s been playing a computer game called “Sims”, in which a single player can create a simulated world, populated with characters that she has configured. These character interact with each other based on their “personalities.”

The version of Sims she uses is not collaborative: each game is independent of anyone else playing the game. But my daughter has a friend (born within a few hours of her, from two parents that lived in the same dorm as my wife and I). Her friend also has Sims, and being 13 year old girls, they play their own games while they talk on the phone with each other. “Let’s make a character called ‘Howard.” Let’s have him do such-and-such. Let’s do this. Let’s do that.“

They’re each using the telephone to coordinate the ”commands” to their respective simulations. Then the games play, producing the same results, even though the game isn’t designed to be networked. That’s exactly how Croquet works.

Now, there are other issues in the Sims, and these girls are as interested in the differences as in keeping things in synch. Pretty cool.

The Imagination Age

, ,

This month’s Tech Review has an editorial that begins “Inventing the future…” and end with these two paragraphs:

“Traditionally, Technology Review hasn’t written that much about society. Our subject matter is emerging technologies, and they have historically been purchased by corporations, universities, and governments. That’s because emerging technologies used to require an extraordinary capital investment, one well beyond the means of most people in their private capacities. Nor did most people see the need to experiment with really novel technologies. Thus the personal computer, the local-area network, the Internet itself were all first used in commercial, government, or academic settings.

”But this is changing. The spread of cheap laptops, handheld devices, affordable Internet access, Wi-Fi, and a dozen other consumer technologies has led to a wonderful explosion of new social applications for them. But here’s the really interesting thing: most of these social technologies have simple editing and programming tools that let ordinary folks do innovative things that risk-averse corporations and government agencies would be hesitant to try. We suspect that Technology Review will be writing about the impact of new technologies on society much more frequently. Besides, social technologies are more fun.”

Here’s the letter to the editors that I just sent:

Continue reading

Scaling to the Enterprise (Part 4 of 4)

, , , , ,

4. HOW RELIABLE IS THE COMMUNITY?

(See part 1.)

None of the previous matters if the software isn’t useful, or if we are not allowed to use the software. The former is what we’re working on, but the latter is a very complex issue. Croquet is certainly not at critical mass. It could certainly go away. However, we feel it is immune at least from licensing plays such as those that have plagued the use of proprietary systems in higher ed, or those that have fractured the Java community. As the number of users in such systems grows, attempts for controlling proprietary lock-in have been very expensive. Croquet fights this in several ways: with an open source license in which all work on Croquet itself is available to anyone; with a P2P architecture that eliminates any advantage to “controlling the servers”; and with a dynamic language that eliminates any advantage to “controlling the release.” We feel that this last will be further strengthened by upcoming work in architecture and security, to be carried out here at UW. For the general health of the community, I look forward to upcoming announcements.

Scaling to the Enterprise (Part 3 of 4)

, , , , ,

3. HOW WILL APPLICATIONS BE DEVELOPED?
(See part 1.)

It is not practical to expect users to develop applications in Squeak. There is too much to learn. But neither is it practical to expect users to develop applications in Java or ANY OTHER COMPUTER LANGUAGE. There is no way that any community of professional developers could possibly keep up with the demand that we hope for unique applications. No matter what language they used, nor even how many developers were available. There’s simply many more users — and user needs — than there are developers. As with scalability of load, we need another approach. The answer is the same: push the load to the edge of the network.

Continue reading

Scaling to the Enterprise (Part 2 of 4)

, , , , ,

2. HOW MUCH USE CAN THE APPLICATION SUPPORT?
(See part 1.)

The architecture of Croquet is very different from that of, for example, J2EE applications. In a client-server application, one server or server “farm” must process each and every interaction initiated by the thousands or millions of users. The only thing processed on the end-user’s computer may be as little as the HTML formatting of the text and image results. Every single other computation must be handled on the big-iron servers. To double the number of users, the capacity of the servers must be doubled. It should be no surprise, then, that so much effort goes into trying to squeeze out each available computing cycle in such architectures.

When an application has state — that is, when results depend on previous results rather than simply generating static files — client-server does MUCH worse. The amount of storage required can go up much faster. In some cases the application state depends on the number of possible connections between users or between applications. The storage (and certain kinds of search-like operations) increases as the square of the number of users or applications (N^2, c.f. Metcalfe’s law). But we are particularly interested in allowing students and faculty to form their own ad-hoc groups among which to communicate and solve problems. A client-server architecture hosting such “group forming” applications would grow exponentially to the number of users (2^N, c.f. Reed’s 3rd law). With only a few users, this architecture would not work at all, no matter how (finitely) fast the servers, or what language the application is written in. (See Reed’s discussion for a surprisingly accessible treatment of value, saturation, and other issues.)

Continue reading

Scaling to the Enterprise (Part 1 of 4)

, , , ,

Croquet is built on some well-used, but not mainstream technologies. A colleague has asked “Why should we believe that Squeak scales to the enterprise?” I’d like to share my answer, to solicit comment.

It is good to ask this, and there are several aspects to the answer:
1. How reliable is the underlying software?
2. How much use can the software support?
3. How will applications be developed?
4. How reliable is the community.

Part 1 of 4.

Continue reading

Back to the Future

, , , ,

In working on Brie, I had been vaguely aware that the ‘Self’ language was similarly based on copying prototypes rather than instantiating classes. So I kind of went ‘yeah, whatever’ when Rick McGeer and others told me to check up on this ’80’s Xerox PARC project.

Wow. I hadn’t realized that Self was so close in both the domain and the solution spaces. If there’s interest I’ll try to produce a comparison later, but for now, check out the Self site and, in particular, this paper.

Transparent Computing

, , , , ,

In What Is It About Immersive 3D?, I claim that being immersed in among the application components allows and encourages us to mix and match among bits and pieces of different applications. That is, we’re getting rid of the idea of having separate “applications” on a computer.

I forgot to mention the other aspect of immersive 3d: that we want to get rid of the computer. Well, actually, that we want to make using each application object feel like a real world object, not a computer thingie. The direct manipulation feel makes it easier to work with stuff, and the lack of indirect abstractions and symbols makes it easier to understand.

A few examples below the fold.

Continue reading