Numbers like 52 million are attention grabbers, especially when they refer
to students getting access to Linux. That's the number of Brazilian
public school students who will have access to Linux-based educational
computers in some 53,000 labs spread throughout the country. As reported
on Mauricio Piacentini's weblog, the Brazilian government already has
17,000 of the labs up and running and plan to be fully rolled out by the
end of 2009.
The project, called ProInfo, is run by the Ministry of Education (MEC) for
Brazil. Piacentini heard about it at the recent Fórum Internacional Software
Livre (FISL) conference, which is held annually in Porto Alegre,
Brazil. He noted that the project is not only providing computers and
infrastructure, but also a "Linux Educacional" distribution with free
educational and entertainment software along with other "open content".
The distribution is Debian-based using KDE 3.5 as its desktop.
Packages from the KDE Education Project
(KDE-Edu) and KDE Games Center
(KDEGames) were included. The project customized the interface, adding a
quick navigation bar at the top (seen at left). This is the second version
of the distribution incorporating feedback from installations of the
previous version. The distribution ISOs, open content, and some
documentation (all in Portuguese) can be found at the MEC ProInfo
There are various different lab configurations that ProInfo has devised
that depend on the nature of the location of the school. Urban labs have
equipment for up to fifteen students whereas rural installations have
power-friendly hardware that can support up to five users. There is also a
configuration targeted at schools for people with special needs that has a large
display and accessibility tools added to the distribution. ProInfo also
has a project that sounds much like OLPC, except in Portuguese: Um
Computador por Aluno ("One computer per student") that plans to bring
150,000 laptops (possibly Intel Classmate PCs) to students over the next
year or so.
Some have quibbled about the number of students estimated, but even if it is
overestimated by a factor of two or three—which seems
unlikely—it is still an enormous project that will impact a huge
number of students. Free software is perfect for these kinds of projects,
because it can reduce the hardware requirements significantly, eliminate
licensing nightmares, and provide a look "under the hood" for students who
are interested. Computer skills are largely portable if some of
those students end up using other operating systems in the future, but
because they are using free software now, any documents, pictures, music,
and other data files will be able to move with them.
Folks from the KDE project are justifiably proud of this deployment.
It uses KDE 3.5, but plans are afoot to work with MEC to explore using KDE4
the road according to KDE hackers Piacentini and Aaron
Seigo. Many have been concerned about the future of KDE 3.5, but the
project has always maintained that it will be around for a long time. As
KDE 3.5 will be supported in the market for many years to come due to
deployments such as this one. Looking towards the future, KDE4 will likely
make some things even easier for them in the future, such as how to
implement the navigation bar they added to the top of desktop as a result
of usability research done involving this specific audience. With Plasma, a
Proponents of the other desktops or distributions should be cheering this
deployment as well. There will probably be lots of lessons learned that
can apply to other projects in Brazil or elsewhere that standardize on a
different set of software components. This is an exciting project for
the free software community. But even more importantly, it is great to see
so many of these tools become available to those who have not yet been
exposed to them.
Comments (4 posted)
Over the last couple of weeks there has been an interesting set of articles
posted on various weblogs on how Sun is managing its open source projects.
As more companies try to get involved with free software, they may find
things to learn from this discussion. So here are a few thoughts on
corporate open source.
It all started with a
posting by Ted Ts'o which stated:
So if you run into a Sun salescritter or a Sun CEO claiming that
OpenSolaris is just like Linux, it's not. Fundamentally, Open
Solaris has been released under a Open Source license, but it is
not an Open Source development community. Maybe it will be someday,
as some Sun executives have claimed, but it's definitely not a
priority by Sun; if it was, it would have been done before now.
The posting drew responses from Dave
Neary and Alvaro
Lopez Ortega, among others; both the original messages and the
responses to it are
worth reading in their entirety. In summary, the responses say that (1) Sun
really is trying to be a good open source player, and (2) Sun has done
as well as could be expected, that the creation of
true open source communities is hard.
The first part can only be true. Sun has been the source of a great deal
of free software, including packages like OpenOffice.org which are found in
almost every Linux distribution. This company has released its core
operating system as open source, and it is making noises about, finally,
making Java truly open at all levels. There are few companies which have
contributed code at this level, and that should be recognized. Beyond any
doubt, Sun is contributing to this community.
What people question, though, is Sun's interest in creating real
communities around its open source projects. These projects are
notoriously hard to participate in and contribute to. As Ted points out,
OpenSolaris currently gets less than one patch per day from outside the
company, the project's governing board is made up entirely of Sun
employees, and its (non-distributed) revision control system lives inside
the Sun firewall. External OpenSolaris developers have known to quit with
Sun agreed that "OpenSolaris" would be governed by the community
and yet has refused, in every step along the way, to cede any real
control over the software produced or the way it is produced, and
continues to make private decisions every day that are later
promoted as decisions for this thing we call OpenSolaris. Rather
than be honest about it and restructure the community to correspond
to this MySolaris style of over-the-wall development, Sun prefers
to lie to the external community members while ignoring their
OpenOffice.org, too, remains hard to work with; thus the
many discouraged comments on the ooo-build
wiki from developers who want to get things done:
Many ooo-build patches are ready for up-streaming but there is no /
little response from up-stream. Worse there is the perception that
taking leadership and actually doing something about merging fixes
would be firmly opposed. Finally - even when maintainers are
active, responsive & friendly - there is no agreed mechanism for
blanket approving fixes - or sub-types of trivial fixes, which thus
tend to fester in IssueZilla.
The key to what is going on here can be found in many places, including in
Besides, the OpenSolaris development model is quite different
because of a number of technical reasons. IMO, the first one is
something as simple as that we want to ensure its quality by
following a number of processes. Another very important technical
point is that we want OpenSolaris to continue being binary
compatible (ABI) with the previous Solaris revisions, which is
something Linux could not even dream of.
The real issue is control; Sun does not want to relinquish control over how
its projects evolve. This is not a particularly uncommon situation with
corporate-controlled projects; these projects will always be subject to the
controlling company's agenda. Thus, no developer is likely to be
successful in projects like:
- Adding features to MySQL which provide the functionality which is
otherwise being reserved for the "enterprise" offerings.
- Adding packages to Fedora which make Red Hat's legal department
- Adding features to projects owned by the Free Software Foundation
which, in the FSF's opinion, are not consistent with its goals;
support for loading Emacs modules from an external repository is one
- Making any changes to Firefox which could threaten Mozilla
Corporation's revenue stream from Google.
Companies which control open source projects in this way are generally
acting within their rights; they may even be acting in their own best
interests. The software is still open source. But the retention of this
sort of control will have an effect on the community which builds around
the software. In many cases, it can have the effect of preventing the
creation of that community in the first place.
And that, too, may be what the company had in mind. There are a number of
company-controlled open source projects which, by all appearances, are
mostly for show and bragging rights. The company does not really seem to
have much interest in developing a significant external community. In
cases like this, if the software on offer is valuable enough, the result
will often be a more community-oriented fork. Projects like ADempiere, LedgerSMB, and Cinelerra CV result from this kind of
Opinions clearly differ on whether Sun is truly uninterested in the
creation of outside development communities for its projects, or whether it
simply is having a hard time letting go. If the latter is the case, then
Sun might be well advised to follow Dave
Neary's suggestion and create a separate, non-profit foundation for the
development of OpenOffice.org. Sun's apologists are right when they say
that turning a large blob of proprietary code into free software is a hard
thing to do. But it's harder if you don't give the community the power to
help; in the case of OpenOffice.org, there would appear to be enough of an
interested community to make a real go at it. This might be Sun's best
chance to show that it can create real development communities
around its software.
Comments (16 posted)
On April 28, a California jury found Hans Reiser guilty of first-degree
murder. There has been a lot of speculation in the press, both before and
after the conviction, on what the loss of Mr. Reiser will mean for the
Linux community. Much of that speculation, it seems, lacks an
understanding of what Mr. Reiser's role in the community really was. Your
editor will take no position on whether his conviction was correct or just.
But there are things to be said about what this conviction will mean.
Hans Reiser was, of course, the designer (and, to an extent, implementer)
of the reiserfs filesystem. When it was merged, reiserfs had the
distinction of being the first journaling filesystem for Linux which was
intended for general use; it also offered good performance in some
situations, especially those involving lots of small files. Reiserfs saw a
significant amount of use and was adopted by a handful of distributors.
There are, doubtless, quite a few reiserfs deployments still operating out
Mr. Reiser's role in reiserfs development and maintenance ended some years
ago, though. He stopped work on it when reiser4 development started, and
even opposed the incorporation
of improvements done by others. Reiserfs
continues to be maintained independently of its creator, though there is
not much interest in adding features to it at this point. Reiserfs is
nearing the end of its run, and nothing which happened this week has
changed that situation in any way.
There is more concern about what will happen with Reiser4, Mr. Reiser's
next generation filesystem. Many reports have suggested that current
events spell the end for this project, but it is worth taking a look at the
longer history. Reiser4 is not exactly new; it was first posted in 2002. Mr. Reiser made
an unsuccessful effort to get it merged for the 2.6.0 kernel, and frequently
thereafter. He blamed commercial interests and
politics for his failure in this regard, but the real situation is more
straightforward than that.
Reiser4 tried to do a number of things very differently from other
filesystems. It included some very non-POSIX semantics which raised red
flags within the development community. There was a multipurpose
reiser4() system call which implemented a wide range of features
and included an in-kernel interpreter for a special language. There was a
low-level plugin mechanism which raised concerns (not all justified) about
varying on-disk formats and proprietary formats. Reiser4 did many things
at the filesystem level that others thought should be done at the virtual
instead. The "files as
directories" feature, beyond striking people as strange, opened up a wide
range of trivial deadlock scenarios.
In summary, this code was nowhere near ready for inclusion into the
mainline kernel. Kernel development projects which are done in isolation
often encounter this kind of surprise when they are finally posted to the
Over the next few years work on reiser4 continued. Many of the problems
were solved by simply removing most of the features which made reiser4
unique, turning it into just another filesystem. Once you have just
another filesystem, attention will turn to performance; in this case, many
people found that they got benchmark results which differed from those
posted by Mr. Reiser. Community interest in this filesystem fell over
time, and the development rate fell as well. There was still work
happening to prepare reiser4 for the mainline kernel when Mr. Reiser was
arrested, but it was moving slowly.
Perhaps the biggest obstacle to the inclusion of reiser4, though, was the
confrontational approach taken toward the rest of the community.
When developers pointed out problems with reiser4, Mr. Reiser had a
tendency to question their motives rather than pay attention to what they
were saying. His interactions with the community were characterized by
What makes you think kernel developers have a deep understanding of
the value of connectivity in the OS? They don't. The average kernel
developer is not particularly bright.
A number of developers reached a point where they simply chose not to
engage with him any more. By rejecting the development community,
Mr. Reiser remained forever an outsider to it.
And that is why the practical effect of Mr. Reiser's conviction on the
community will be relatively small, at least in the short term. As
brilliant as he is, his effectiveness was limited by his disregard for the
rest of the community and his certainty of always being right. He could
have accomplished much more with a different approach.
That said, his loss is unfortunate. He did prove able, over a number of
years, to raise funds for Linux filesystem work, and the community
benefited from that work. Some of the reiser4 developers are still
interested in working on that code, and they still submit patches. But now
nobody is paying them to do that work, which puts the whole enterprise in
danger. There are limits to how long reiser4 development can be carried
forward as a labor of love.
The biggest loss, though, is elsewhere. More than anybody else, Mr. Reiser
put a lot of thought into what our systems should look like in the future.
He saw capable filesystems as the way to make our systems far more powerful
than they are now. In a world where the filesystem was the only namespace
of any significance on the system, all objects would be equal and the
number of potential connections between them would explode. His long-term
goal was not (just) better benchmarks; it was to create a filesystem which
could serve as this all-encompassing namespace. It was a radical idea, and,
perhaps, impractical. But our future comes from ideas like that.
After a few relatively quiet years, there is now a flurry of activity
around Linux filesystems. The challenges in this area are large, but we
have many highly capable developers working on the problem and there can be
no real doubt that Linux filesystems will continue to be among the best
available anywhere. But
that development community has lost a voice which, for all its faults, had
some unique and innovative things to say, and we are all poorer for it.
Comments (33 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: The Tahoe secure filesystem; New vulnerabilities in asterisk, kdelibs, ldm, wordpress,...
- Kernel: The 2.6.26 merge window, part 2; Restricting root with per-process securebits; Ksplice.
- Distributions: Distributions in the Summer of Code; The Heron has landed; Slackware 12.1 RC3; Gentoo 2008.0_beta2; Fedora 7 End of Life; Ubuntu Open Week
- Development: Stream video and audio with Boxtream, GNOME 2.24 roadmap, Python stdlib reorg, subversion's future, new versions of Firebird, FreeIPA, Wubi, GARNOME, GnuCash, OpenCards, UFO:Alien Invasion, FLTK, jack-smf-utils.
- Press: Stallman: Can we rescue OLPC from Windows?, Linux and Formula One,
Linux training in Italy, ten arguments for switching to Linux,
Linux is top embedded OS, interviews with Sung Jae, Donald Knuth,
Joe Miller and Walter Bender, open-source video streaming,
Phoronix Test Suite.
- Announcements: LWN guest author index, KDE for 52M Brazilian students, Linux Incompatibility List needs help, OLPC photos, GSoC projects, CadSoft Eagle 5.0, OpenLogic hits 400 package mark, VIA driver development portal, OSSCoNF cfp, YAPC::NA schedule, Paul McKenney on Realtime Linux.