Interview: Jim Gettys (Part II)

Red Hat is putting together a pared-down Fedora derivative distribution. The community being what it is, I expect others will put other distributions on the machine as well, given that the OLPC system is an open platform. I'm not sure such duplication is worthwhile, but I'm resigned to it.

I *really* urge everyone to cooperate very strongly at the level of the software for the kids, no matter what the underlying distribution in the long term. This project is fundamentally about kids learning and helping the world; not about free software.

That being said, *free software enables the kids to learn computing in a way that they cannot learn it on closed proprietary platforms*. We are therefore very much part of the free and open source software community.

Chris' team is putting together a python based environment (into which conventional applications can be embedded) aimed at young children, temporarily called "sugar" (more information can be found in postings here, here, here, and here); conventional GUI's are not good for children still learning to read. I have a 8 year old son and an 11 year old daughter, and so have seen over the last few years first hand how unsuitable conventional desktops are for young children.

The Sugar environment, by using the Avahi library (zeroconf/mdns technology), will show the presence of people on the network as a fundamental aid to building collaborative applications. Collaboration is fundamental to learning: most kids learn from their peer group, and teachers serve as the guides.

We are strongly recommending that future content not be created in closed format like Flash, whose format is closed, lack tools for manipulation, and present major problems for accessibility tools.

But some countries have such content today, and need to use it immediately. And since there is so much flash content on the web, it would not surprise me if countries arrange for Flash to be installed, even if they do not have existing educational content in Flash. We are encouraging everyone to use open standards based formats, and to release useful content under appropriate free creative commons and free software licenses.

Reality being what it is, even if we had veto power over software on the machine (which we certainly don't), we'll see such software included on the machine by the time it in children and teacher's hands; just not distributed from OLPC, but added on afterwords.

We believe all children learn by doing, and should be authoring content, not only passively reading unchangeable engraved in stone content. We are placing some major bets on wiki technology as a base for this. (Not wiki markup though!).

I'd also like to draw your attention to a web site: logowiki.net. Content doesn't have to be static at all, and content can be programs, even programs for young children. The ability to run simulations and manipulate the starting conditions is a major tool to learning.

And one more hardware feature is unique to our machine: you can choose to use the audio input as a direct analog input, allowing direct measurements be made with very cheap sensors (e.g. photodiodes, accelerometers, etc.).

With the likes of Seymour Papert and Alan Kay involved, I think we're in for some fun stuff. For example I saw a demo this week of a wonderful music application called TamTam, that Jean Piche' et al in Canada and Ireland are building using the Csound synthesis software Barry Vercoe originally developed.

At a minimum, we expect Logo, javascript and python to be present, and compilers as well when needed by interested kids. Learning programming, though, is best done in interpreted language environment, rather than compiled languages. Certainly C++ should never be a child's first computer language.

Being root on your own personal machine is fundamentally different than having any access to information on the network you should not have. Project Athena, at MIT (where such technologies as Kerberos, X11, the first network IM system, among others), demonstrated this even 20 years ago: on those systems having root access does not get you access to anything but the services you had access to as an individual user. The root password on those systems has been posted for years: it just doesn't matter, if you do your homework properly.

Capability:

• we'd like to be able to boot over the mesh network for (re)install
• we may need to follow Mark Foster's fast suspend/resume path, in which case having full source may be essential to its success.
• We want interested kids to be able to see how computers really work and learn accordingly.

Some years ago when I was working on Linux on the iPAQ, we had a 12 year old who was hacking on our boot loader, and learning tremendously as a result. Those outstanding kids should also have the opportunity to learn computing deeply.

And if they need professional administration, we've failed.

Our view is that systems cannot require professional administration at a local level: we could not deploy quickly on this scale and have sufficient expertise if this were required. Part of the IPv6 argument is exactly to allow administration to scale and to simplify administration.

We certainly are aware that security is a challenge: young children are not noted for choosing and keeping secure good passwords, and we are looking at other methods as a result.

We expect to deploy SELinux protecting the "standard" network services on our machines to help protect against day-0 attacks, to prevent bad guys from successfully attacking our systems and prevent such people from using our systems as a point of attack.

And keeping our systems up to date automatically is obviously essential.

As far as malware from the developing world: malware for what? Malware is very rare on Linux or Apple's OS/X systems: both systems break out of the starting gate much less insecure than Windows, and writing malware for either is inherently more difficult. And if Mr. Kaspersky's worried about kids in the developing world writing malware on the OLPC systems to attack Windows, how are the kids going to test such Windows malware since our machines are running Linux?

Malware authors working for profit (e.g. stealing passwords and accounts) are certainly going to be older than our kids, and will find a standard Windows system a much more productive development environment, and internet cafe's a much more anonymous place to launch attacks than our school environments.

Lastly, both at the school servers, and the networks supporting them, we have good places to prevent, stop, and track down any such attacks, much better than you'd find in the anonymous world of Internet Cafe's where anyone can pay for anonymous usage.

And high bandwidth back-haul from schools is unlikely to be very common, limiting the problem if it does occur. There are much better targets for zombies: e.g. systems all over the developed world where each machine has a high bandwidth broadband connection, rather than a kid's machine on a large shared mesh network back connected through a similar single connection. Per compromised machine, there may be a difference of a hundred to one of useful bandwidth.

Seems to me that Mr. Kaspersky knows not what he writes of, and is trying to gain eyeballs on his stories by sensationalism.

We expect the kids machines to be updated from school servers, and possibly from other kid's systems.

The closest management tools to what we need appears to be many of the technologies developed by PlanetLab: the commercial distributed content systems are unlikely to work, presuming as they do that systems are in data centers and always/usually available over high speed networks.

At our scale, (and with the highly variable Internet connections we expect), a presumption of constant connectivity seems untenable. We'll know more as we look into this aspect of the project more fully over the next few months.

Second, public education about these distinctive systems is a topic we've discussed with deployment countries as a deterrent.

Third, by saturating each area during deployment, rather than distributing machines piecemeal, we can expect much better mesh networking performance, but also less child from child theft.

Fourth, there will be a commercial version of the machine (that will look quite different) at some point in the project, to reduce the pressure for these unique systems. As I explained before, there are quite a few ways in which these machines are unique, so we'd like there to be fewer reasons for theft, by enabling a commercial version. These commercial machines may also help cross subsidize the children's machine, for as long as the market might bear such a price differential.

Fifth, by its nature, there is a network MAC address in each machine that can aid its tracing, in the case of theft, once a system is recovered. We are, however, very concerned about the child's privacy and safety, and so don't want the systems to go around broadcasting the hardware MAC address in the normal case.

And we're exploring some other possible identity systems as well that may help in this area.