LWN.net Weekly Edition for December 14, 2006

Playing with the OLPC

The One Laptop Per Child project is likely to be familiar to most LWN readers by now. An important milestone on this project's plan for the creation of low-cost educational systems is the production of "BTest-1" systems. The project has manufactured on the order of 1000 laptops and distributed them to testers worldwide as a way of, hopefully, shaking out the remaining hardware issues and making a start on the software side of the equation. Some systems have even been shipped to Microsoft so that some sort of Windows port can be done; this move has upset some OLPC supporters, but when the designers of the laptop said they planned to make a 100% open system, they meant it.

Your editor was lucky enough to receive one of these systems, after having been put through the indignity of seeing everybody else's "I got my laptop" posts first. There has not been a great deal of time to play with it yet, but your editor has had the chance to form some first impressions. The OLPC XO (or whatever it is eventually called) is going to be a nice system.

Back in July, we interviewed Jim Gettys about this system; one of the questions we asked was how they planned to keep adults from stealing the laptops from the children for their own purposes. Jim answered:

Even with this in mind, most people who see an OLPC for the first time are surprised by just how small it is. Understanding sets in for real when one attempts to use the keyboard; the small keys will work for a small child, but, for your fat-fingered editor, it is very much a hunt-and-peck device. There will be very few adults who will be able to type comfortably on this system. With the size of the device and its bright colors, they will also look decidedly silly in the attempt. This machine is clearly for kids.

Another way to make adults look silly is to hand the laptop to one of them and suggest that they open it. Your editor has performed this experiment several times now, and has not yet seen anybody succeed. Most people try pushing on the green square that looks like a latch, but which is, in reality, the hinge. The secret is to lift up the two "ears," which happen to be the wireless network antennas, and open the top toward the handle. Anybody attempting to use a crowbar should be stopped immediately.

The display can rotate 180 degrees and be closed over the keyboard, putting the device into "ebook" mode. There is no touchscreen on the device, so the only controls available in this mode are the eight buttons (four arrows and four which, for now, look like Sony game controller buttons) next to the display.

On the software side, the test system is running a pared-down version of the Fedora Core distribution. The kernel is essentially 2.6.19-rc2 with a fair set of patches (some since merged into the mainline) to support the OLPC hardware. Many of the basic utilities are there, and there is a Python interpreter available. But anybody looking for a C compiler, OpenOffice.org, emacs, Wesnoth, etc. will not find them. The system has little space (512MB of flash storage) and even less memory, so a lot of larger applications will never find space there.

The BTest-1 release notes make it clear that the process of putting together the software is just beginning; the focus, until now, has been on getting the hardware working. So many of the provided "activities" are present only in a preliminary form, and others are not there at all yet. It is not, according to the release notes, time to test the device on children (though your editor's children disagree rather strongly). Certainly the adults are starting to have fun with the system; your editor was gratified by this brief posting on video conferencing on the OLPC using the telepathy package.

Running software on the test system drives home a point the project has been making for some time: much of the software we run now is far too bloated and slow. With a suitable amount of attention to resource use, the OLPC hardware is powerful enough to accomplish a wide variety of tasks - web browsing, document editing, video conferencing, and more. But, with the wrong software, the system will just sit there and thrash. So one of the primary goals for the OLPC software team in the coming months will be to put the system's applications on a diet until they fit comfortably on this small system. This work will benefit us all in the end; some of the work aimed at slimming down the Gecko rendering engine can already be found in Firefox 2.

Beyond that, however, this project is setting up to put millions of Linux-based laptops into the hands of children worldwide. These systems will include mesh networking and cameras; this is a combination which is likely to lead to interesting things to see on video sharing sites - and serious news channels. The laptop will be wide open, with the "view source" functionality built in. There are many people who question this project and whether the countries involved might better spend their resources on clean water, sanitation, and so on. Those are legitimate questions which cannot be simply brushed off. But one should also consider what those kids will be able to do given better access to knowledge, communications, and a platform they can hack to their own ends. It is going to be interesting to watch.

Comments (24 posted)

The next document format battleground

Recent weeks have seen a great deal of debate over Microsoft's OpenXML document format. This format, which is headed for standard status, is a complex beast. Some have questioned whether it will ever be able to create independent implementations of OpenXML which are truly interoperable with each other. Others ask whether it is right for the free software community to even try. To many members of our community, the right path is to encourage the use of OpenDocument, which already has standard status and implementations in free software. Why get onto another document format treadmill when a better solution is already available?

These questions are valid, they deserve full consideration. But they may also, to an extent, be missing the real point. It is entirely possible that the document format battles are done; even if OpenXML is not a perfect standard, it is far more open than its predecessors. While Microsoft is not inclined to make life easy for those who would interoperate with its file formats, the company may well have realized that obscure formats have outlived their usefulness as a way of maintaining desktop domination. This might just be a battle we have won, even if the victory is rather more messy than we would like.

Before we charter an aircraft carrier for our "mission accomplished" party, however, it is worth reflecting on different forms this fight could take in the future. Cory Doctorow gave us a good hint in this InformationWeek article on "information rights management." IRM is a feature touted by Microsoft for a few years now which has the potential to complicate life considerably in the future.

IRM offers some interesting features to people who are worried about the information they put into their documents, presentations, and spreadsheets. With IRM, the document owner can specify exactly who can read a particular file, and under what conditions. Access can have an expiration time attached to it - or it can be revoked at any time. Actions like printing can be restricted. For anybody who feels the need to control information, these features cannot fail to be appealing.

But these features only work if the client plays along, and free software clients have not always distinguished themselves in this area. Or, rather, they have distinguished themselves very well by serving the needs of their users. Even if a programmer implements the "this document can only be printed once" flag, somebody else, perhaps after having lost their one printing opportunity to a particularly nasty paper jam, will hack it out. Clearly, Microsoft must prevent the creation of free applications which can read IRM-protected documents or it will be unable to live up to the promises it has made for that technology.

Microsoft has a couple of weapons at its disposal (beyond pure obscurity) which can be used against any potential free IRM implementation. One is the DMCA, which, in the US (and countries which have implemented similar laws), can be employed against those who bypass access restriction mechanisms. Anybody who posted code that, say, allowed the user to cut and paste text out of an IRM-protected document would likely face an unpleasant reception in the US. They would be in a situation much like that faced by Dmitry Sklyarov, who bypassed similar restrictions in PDF files, a few years ago.

Of course, the Sklyarov case did not necessarily work to Adobe's advantage in the end, and Microsoft might wish to avoid a similar storm of bad publicity. So, as Cory's article points out, Microsoft might pursue a different option: the use of the trusted computing module (TPM) increasingly being built into new computers. With the remote attestation feature of the TPM, it is possible to refuse to pass decryption keys to any system which cannot be shown to be running approved software. This system would be quite tight and hard to defeat - it might just work. And it would no longer matter how "open" the document format is.

The full remote attestation scenario requires the cooperation of the entire system, starting with a "secure" BIOS which initializes the TPM properly. Most systems do not currently operate in this mode, so the realization of this threat will not happen in the immediate future. One should not, however, forget that the TPM has been designed to support just this mode of operation. It does not take all that much paranoia to imagine that these capabilities will not go unused forever. "Trusted computing" has yet to touch most of us, but we ignore it at great risk. Among other things, it could make the current discussion of open document formats entirely moot.

Comments (16 posted)

Steps in the Fedora transition

The recent Fedora Summit reached a number of conclusions about the future of the project. These include the elimination of the distinction between Fedora Core and Fedora Extras and the extension of the support period for Fedora releases to approximately 13 months. Since then, various parts of the project have tried to figure out what is really going to happen. It is beginning to appear that a few things, at least, are coming into focus.

When changes of this magnitude are in store, one's thoughts immediately turn to the most important topic: what will be the project's new name? Quite a few possibilities were discussed, including Fedora Union (not everybody liked the acronym) and Fedora Freedom (which, it seems, brings unwelcome associations with "freedom fries" to a fair number of people). After weeks of discussion, it would appear that people are converging on (...drum roll...) "Fedora." Who would have guessed?

So when will the next Freedom Fries Fedora release be? According to a recently-posted schedule proposal, Fedora 7 will come out on April 24, 2007. That date seems to be driven by the Red Hat Summit, which starts on May 9; the Fedora folks would like to have something to show off at that event. On this schedule, the first test release would be on January 30, just before the next FUDcon, which appears set for February 2 to 4. Assuming the schedule does not slip, it should be possible to hand out Fedora 7 disks to Red Hat Summit attendees.

The only problem is that Fedora schedules have been known to slip at times. This realization has led to a discussion on what went wrong, and how schedule slips might be avoided this time around. There were a number of issues that came up toward the end of the Fedora Core 6 effort, some of which would have been hard to anticipate and avoid. One of the biggest issues, however, was the fact that Xen didn't work. Fedora kernel maintainer Dave Jones has some choice words about Xen, along with a grim prognosis about the potential for future problems. It rather appears that Fedora might be best served by dropping Xen altogether, but that is unlikely to happen in the short term. Red Hat Enterprise Linux needs to have Xen (after all, Novell ships it), and Fedora is where these technologies get much of their early testing.

That said, there seems to be a fair amount of sympathy for the idea of simply dropping features with problems that threaten to delay the release. Hopefully the Fedora developers won't have to make any such choices this time around, but, should something come up, it will be interesting to see how they respond.

Another open question is what happens to the Fedora Legacy project. Nobody has really taken the step of officially shutting it down. Jesse Keating has walked away from it, however, and few people seem to see much reason for keeping it going. There are users who would like to see more than 13 months of security support for Fedora releases, but the subset of those users who are willing to help Fedora Legacy provide that support is quite small.

Meanwhile, the project did (on December 12) put this note onto its web page:

Given that the project only managed one Fedora Core 4 update ever, one could argue that the situation has not changed much. But at least it is now clear. What is less clear is how the various hosting companies which offer Fedora Core 4 servers have kept them secure so far, and what they intend to do now.

Finally, the project still has not come to a final resolution on what to do about RPM. The subject was apparently discussed at the December 12 board meeting, but no communications are, as of this writing, available. With luck, we'll hear from the project on this topic before too long. Infrastructure like RPM is too important to leave in a limbo state for this long.

Comments (4 posted)