The One Laptop Per Child project
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:
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.
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
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
Comments (24 posted)
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
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
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
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)
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:
The current model for supporting maintenance distributions is being
re-examined. In the meantime, we are unable to extend support to
older Fedora Core releases as we had planned. As of now, Fedora
Core 4 and earlier distributions are no longer being maintained.
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
too long. Infrastructure like RPM is too important to leave in a limbo
state for this long.
Comments (4 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Another kernel core dump security issue; New vulnerabilities in clamav, gnupg, kdegraphics, madwifi, ...
- Kernel: Coming soon to a kernel near you; Kevent take 26; Video4Linux2 part 4: inputs and outputs.
- Distributions: Ulteo Linux Sirius Alpha; OpenPKG Enterprise 1; pure:dyne; Debian Etch frozen; Pioneer Linux
- Development: Campcaster - broadcast radio with Linux,
Django/Rails comparisons, Guido's Mondrian project,
new versions of Rivendell, RFIDIOt, Tftpy, Midgard,
Linux-ready Firmware Developer Kit, PLplot, Covered, eispice, GnuCash,
Qt, wxWidgets, Wine, CLAM, pnpd, OO.o, ISO Master, MeshLab, PIL, 4Suite XML,
BuildBot, LDTP, Mercurial.
- Press: ODF vs Open XML, FSFE's Georg Greve on Open XML, Seymour Papert injured,
Desktop Architects Meeting, LISA '06, OIN's Jerry Rosenthal interviewed,
LMN's Fred Trotter interviewed, FDS intro, Campcaster review, DHS reviews
open-source code, LinuxBIOS ready to go mainstream, Mozilla to collaborate with Linux distros.
- Announcements: FSF pledges $60K for Ryzom; Open XML given ISO approval, Sirius supports KDE, Java Open Review launched,
Open-Xchange and MySQL partner, Java SE 6 announced, Yellow Dog Linux on
PLAYSTATION3, Open Source Software for Sustainable Human Development,
SAGE Outstanding Achievement Award, LAC2007 CFP, Xorg Dev Conf CFP,
video of Eben Moglen at the Plone Conf.
- Letters: The benefits of software freedom.