The first part of our interview
with Jim Gettys
covered many aspects of the "One Laptop Per Child"
(OLPC) system. With the second and final installment, we look at a number
of other issues, including the software which will run on the system,
security issues, and more.
LWN: Time for a few questions about the mix of software you envision running on
the OLPC systems. To start with, it appears that the system will be based
on a pared-down Fedora-based distribution?
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
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.
Will the systems as shipped be 100% free software?
OLPC itself only plans to ship free software at this time.
If not, what other code
do you think you might include?
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
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.
Is it true that there will be no package manager on this system?
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 there be any provision for customizing the system software mix,
installing localization data, or updating software?
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.
A system like this clearly needs a good set of education applications - an
area where free software has not traditionally been strong. What sort of
applications are you looking at in this area, and might any missing pieces
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,
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
Will the systems include a compiler, or, failing that, an interpreter for a
language like Python?
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
In general, is hacking one of the uses to which you
think these machines will be put?
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.
Do you expect that the kids will have root access on their systems?
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.
The plan to use LinuxBIOS is interesting. Are there reasons driving that
choice (beyond cost)?
Cost isn't a real factor in this decision. The royalty rate of a conventional BIOS
is in fact very low.
- 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
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.
Is LinuxBIOS ready for this sort of deployment?
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.
Millions of identical systems, mostly lacking professional administration,
would seem like a magnet for malware authors. What sort of thought is
being put into preventing these systems from becoming worm carriers and
large-scale zombie networks?
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
Eugene Kaspersky, who has been predicting Linux doom for years,
is now saying that the OLPC will result in a new wave of malware
from the developing world. Do you find this outcome plausible?
Why or why not?
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
Seems to me that Mr. Kaspersky knows not what he writes of, and is trying to gain
eyeballs on his stories by sensationalism.
Given the state of the art, the chances of a security vulnerability turning
up in the shipped OLPC systems must be near 100%. What happens then? How
will OLPC users obtain and install security fixes?
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
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.
Some commenters on LWN have expressed concerns that many of these systems
may be stolen from the children and used for (or sold to fund) rather less
wholesome ends. Is this an issue which the OLPC team has thought about?
Yes, we've thought about it quite a bit.
How could this risk be minimized?
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
A huge "thank you" is due to Jim, who clearly took a great deal of time to
respond to LWN's questions in such detail.
Comments (24 posted)
Red Hat is long been a likely target of legal attacks; the company has a
high profile, customers who can be threatened, and a bank balance which is
worth the trouble of coveting. So it is not entirely surprising that a
small company called FireStar chose Red Hat as the target for a software
patent suit. It is unlikely to be the last.
The patent in question is US
patent 6,101,502, which is said to be infringed by the "Hibernate"
product acquired with JBoss. This patent, filed in 1998, asserts the
A method for interfacing an object oriented software application
with a relational database, comprising the steps of:
- selecting an object model;
- generating a map of at least some relationships between schema
in the database and the selected object model;
- employing the map to create at least one interface object
associated with an object corresponding to a class associated with
the object oriented software application; and
- utilizing a runtime engine which invokes said at least one
interface object with the object oriented application to access
data from the relational database.
In other words, this is a patent on an object-oriented wrapper for data in
a relational database management system. To say that this idea is obvious
is to understate the case. The first thing any object-oriented programmer
does is to create classes to encapsulate the data to be manipulated; of
course such a programmer would create a series of objects to represent
relations in an RDBMS. One would expect that it would be possible to
examine a large number of object-oriented programs which work with RDBMS
systems and not find a single one which lacks this sort of
impedance-matching layer. So the world did not need to wait until 1998 for
the authors of this patent to come up with this idea.
Thus, if Red Hat puts up a suitable level of resistance, it should be able to
get this patent invalidated. But there is little comfort to be found
there. There are thousands of these patents in circulation and no shortage
of trolls willing to exploit them to line their own pockets. One such case
can be beaten down; but there will be more than one. Perhaps many more.
Software patents have long been seen as a serious threat to free software;
now we are beginning to see this threat come to life.
[As an aside, there have been some allegations that at least one Red Hat
employee engaged in pro-patent lobbying in Europe last year, and that, as a
result, this suit represents a sort of poetic justice. See this week's Letters Page for a
discussion of both sides of this issue. The statement from FFII found
there would appear to establish that Red Hat's position on software patents
has been clear and consistent.]
Comments (2 posted)
Your editor misses the Good Old Days, when outlandish SCO court filings
were a daily occurrence, Darl McBride's fulminations were daily press
fodder, and the occasional corporate teleconference could be counted upon
to keep blood pressures high in the community. One could almost get
nostalgic about plowing through yet another blurry PDF file filled with
bizarre legalese. The world feels a little lonely now that Chris Sontag no
longer shows his face in public.
Actually, the above paragraph is a bunch of hot air; LWN is more fun
without the SCO Group on the front page. But a certain morbid interest
suggests that the SCO end game should occasionally be chronicled as
important milestones unfold. One of those milestones was passed on
June 28, when Judge Wells issued an
order in SCO v. IBM. For those of us who have been patiently (or,
perhaps, not so patiently) waiting for SCO to feel the consequences of its
lack of discretion in public and its lack of any actual evidence of
wrongdoing, the time has finally come.
The SCO Group, remember, has been under court order for some time to
disclose "with specificity" exactly what it thinks IBM did wrong. SCO's
final answer took the form of 294 "specifics," described in a sealed
filing. IBM responded with a motion saying that most of SCO's claims
lacked the required level of specificity and should simply be thrown out,
regardless of whether they might have any merit or not. Judge Wells's
order was the court's response to this motion.
After reviewing (at length) SCO's history in the case, Judge Wells
concluded that SCO's claims were, indeed, not specific enough. Not enough
for the court, but also not up to the level that SCO expected from IBM.
Given SCO's track record in this case, the court is certain that if
IBM had simply provided line information without version and file
information for "methods," SCO would have filed motions to compel
complaining about IBM's lack of specificity. The court cannot find
any reason why SCO should not be held to the same level of
accountability that SCO held IBM to. Thus, SCO should have supplied
not only line but version and file information for whatever claims
form the basis of SCO's case against IBM.
Failure to meet the specificity requirement is not enough to throw the
claims out, however; a couple of other criteria must be met. One is that
the failure was willful - that SCO deliberately failed to disclose that
information. According to Judge Wells, that is, indeed, the case:
There is no evidence before the court to indicate that SCO lacked
the ability to comply with the court's orders. In fact, given SCO's
own public statements outlined in part supra
, it would
appear that SCO had more than enough evidence to comply with the
Based on the foregoing, the court finds that SCO has had ample
opportunity to articulate, identify and substantiate its claims
against SCO. The court further finds that such failure was
intentional and therefore willful based on SCO's disregard of the
court's orders and failure to seek clarification. In the view
of the court it is almost like SCO sought to hide its case until
the ninth inning in hopes of gaining an unfair advantage despite
being repeatedly told to put "all evidence . . . on the table."
One might well argue that this is a charitable view of SCO's behavior. But
it makes one thing clear: the court has noticed the discrepancy between
SCO's public bluster and the evidence it has actually put forward in the
Finally, IBM had to show that it was being hurt by SCO's failure. The
court had no trouble buying IBM's argument that it would be hard put to
defend a case where it is unaware of what it has done wrong. The troubles
go beyond that, though:
Without more specificity than SCO has provided some very important
questions that could materially impact this case are nearly
impossible to answer. For example, is the code that comprised the
method or concept still in use in Linux? If not, then damages may
become nominal instead of in the billions. Or, it may be possible
that the code comprising a method or concept was already disclosed
pursuant to some other license such as the BSD License.... Without
the code, however, there is no way to ascertain exactly what the
impact is of prior disclosures that may involve the code at issue
in the instant case.
The end result is that IBM won big: 182 of SCO's claims have been summarily
tossed out - just ten short of what IBM had asked for. On the order of 100
claims remain. This ruling is clearly a major blow to SCO's case, but just
how major is hard to say: since SCO's claims remain under seal, we cannot
know which ones have survived. But it is clearly a much shorter list, with
much of the "methods and concepts" vapor removed. And, just as
importantly, the court appears to have concluded that SCO has been given
plenty of rope at this point; with luck, this whole episode might just
reach a conclusion sometime soon.
Comments (4 posted)
Page editor: Jonathan Corbet
Next page: Security>>