Interview: Jim Gettys (Part II)

To date, Red Hat are the ones who are putting serious engineering into OLPC and doing most the heavy lifting on the base system, and have assembled a first rate team, including Dave Woodhouse and Marcelo Tosatti.

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.

OLPC itself only plans to ship free software at this time.

Let me give a concrete example: some countries have coded some educational content in Flash.

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.

This is an area where we continue to have discussions. Whether it is like conventional packaging systems or not is unclear right now. Time will tell.

Of course. There has to be. By middle school, kids are taking different courses and languages. Some kids have special needs, either advanced or the opposite. One of the major advantages that an OLPC has over conventional books, is the possibility to bring much more content appropriate for each child to that child, who live in places which lack libraries we find in U.S. and other developed nation's schools.

There is much software sold claiming to be "educational" software, which isn't. The reality is that there aren't all that many good educational applications on *any* platform. The pickings are pretty slim.

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.

Of course.

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.

Hacking, in the original positive sense of the word (see the Jargon File), we certainly believe should be strongly encouraged in interested children: computing is a fundamental skill in today's society. For others, computers will just be a tool; their pen and paper.

Yes: we want children to be able to learn computing, if they are interested. For the kid's systems, we want them "easy to fix", rather than "hard to break". For the school's servers, a shared resource, we want them to be "hard to break" *and* "easy to fix", and are exploring technologies like those developed by Planetlab.

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.

Cost isn't a real factor in this decision. The royalty rate of a conventional BIOS is in fact very low.

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.

We think so. It's already deployed commercially at pretty high scale on a number of products. And the very fast suspend/resume we may need to implement requires complete freedom of action at all levels of the machine.

I doubt they will be exactly identical (other than hardware): language is but one of the obvious differences; children take different courses, and study different languages.

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.

I don't find Mr. Kaspersky's arguments plausible, for a number of reasons.

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.

Our challenge is not just the kid's machines and operating system, but also deployment of server machines in all the schools, to cache distribute software and educational content to all of them.

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.

Yes, we've thought about it quite a bit.

First, we intend that the systems be instantly recognizable as kid's systems, not only so that kids like them and value them more and take care of them carefully, but also so that adults with machines in their possession may be asked questions about whether they should have the machine. And these systems are physically sized for smaller children, our primary "customers"; while adults can use them, it is less desirable than a bigger machine might be.

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.