The world is full of fun gadgets which perform specific tasks. Those
gadgets tend to be highly closed affairs, however. Even the ones which run
Linux are sealed shut so that they cannot be played with. The result is
that many of these toys retain annoying misfeatures and do not live up to
their full potential. For this reason, most interesting electronic toys
are surrounded by a crowd of developers looking for a way in. Wouldn't it
be nice if that work weren't necessary?
One device which has begun to attract attention is the GP2X, which will be shipping
soon. This device has a superficial resemblance to the Sony PSP; it has a
central screen with a set of buttons on the right and a joystick-button on
the left. Unlike the PSP, however, it is an open device. The
specifications are available (this Wikipedia page has the
most comprehensive information), and the device runs Linux. It is clearly
meant to be hacked on, and it could be the source of no end of interesting
On the other hand, some details are scarce, and there appears to be no
place to download the Linux distribution used on the device. An earlier version of the
product page contains the ominous words "copyright protection by
certified DRM." The device will remain vaporware for a little longer; once it
is in circulation, the world will see if it is truly a Linux-friendly (as
opposed to simply Linux-using) gadget or not.
A more interesting project, one which could certainly benefit
from more development help, is Rockbox. The Rockbox developers are
creating a free system for portable music players;
the primary target is the Archos product line, but work is proceeding on
iRiver 1xx and 3xx players as well. This project (which will be releasing
version 2.5 "soon") is a demonstration of why
free software is such a nice thing to have on these devices.
A partial list of advantages to the Rockbox software would include:
- A much wider range of translations than the original manufacturer
- Numerous features for blind users, including a voice mode which reads
out menu entries as the user moves over them.
- Gapless playback.
- A wider range of codecs, enabling the use of audio formats not
supported by the manufacturer.
- A user-configurable "while playing" screen, enabling scarce display
space to be used for exactly what the user wishes to see.
- A plugin architecture for adding new features. The plugin
list appears heavily biased toward games, but it also includes image
file viewers, clocks and stopwatches, and more.
- On the iRiver: faster booting and the ability to boot into USB storage
mode when the filesystem is corrupted. So filesystem problems which
would turn a stock iRiver into a brick are recoverable with Rockbox.
The list goes on, but the point should be clear: Rockbox allows the owner
of a music player to do away with no end of annoyances, add new features,
and generally get the most out of a nice piece of hardware. The freedom to
make changes like this is what drew many of us to free software in the
The sad thing is that the Rockbox developers have had to put considerable
work into figuring out how the hardware works and developing firmware
patches. Had the vendors simply opened up their hardware in the first
place, that effort could have gone into making the software better. This
situation should eventually change: Rockbox already looks better than what
a number of manufacturers are installing onto their players. As Rockbox
develops and that gap widens, there will come a time when some manufacturer
will realize that the ability to run Rockbox will be a positive selling
point for a media player. Then, maybe, we'll have a truly open
gadget to play with.
Comments (14 posted)
Filesystem developer Hans Reiser cannot be accused of giving up quickly.
His current request
that the reiser4
filesystem be included in the 2.6.14 kernel has created a lengthy
discussion, but that's not where the story starts. In fact, Hans first asked that reiser4 be merged
in July - of 2003. For more than two years, Hans has repeated his request
and made changes in response to feedback from the kernel development
community. Yet reiser4 remains out of the mainline, and its chances of
getting into 2.6.14 appear small.
Reiser4 is an interesting filesystem. It comes with claims of improved
speed and space utilization; those are welcome, but they are beside the
real point. Reiser4 includes a "wandering log" mechanism which provides
journaling capability without the need for a separate journal. The ability
to perform multi-step transactions is built into the filesystem, though not
yet completely exposed to user space. Multi-stream files (including
file-like access to file metadata) are supported, though this feature is
turned off for the moment as well. A flexible plugin architecture makes it
easy to add new features (such as encryption, compression, different
formats, etc.) to the filesystem. And so on.
Hans Reiser and his developers at Namesys are trying to change how people
work with filesystems - and with computers as a whole. The underlying
vision is one where the filesystem implements the entire namespace used by
the system; everything truly is a file. In the Reiser view of the future,
applications like relational database managers need not exist; such tasks
will be handled in the filesystem itself.
What it comes down to is that reiser4 represents some of the most
innovative work being done with filesystems for Linux - or for any other
system. So one might well wonder why inclusion is proving to be such a
challenge. Some of the reasons are straightforward: there were genuine
issues with the code. The "files as directories" capability opened the
door to trivial, user-initiated kernel deadlocks - a feature which can
absolutely ruin those performance benchmarks. The multiplexed
sys_reiser4() system call - to be used for managing transactions,
among other things - is just the sort of call that the Linux developers are
trying to get away from (and its use of an in-kernel command interpreter
did not help). A number of other things
needed to be fixed; the Namesys hackers have been working through the list,
but a few items remain.
The real point, however, is that getting code into the kernel is an
increasingly hard thing to do. In the early days of Linux, almost any code
which made things work or added new features was welcome - we needed it
all. In more recent times, it is often hard to argue that new features are
truly needed, especially at the kernel level. So each new addition must be
weighed against the costs that will be incurred when it is added.
The result is that the standards for new kernel code have gone up
considerably over the years. Reiser4 has run into these standards, and
objections have been raised to code which duplicates features found
elsewhere in the kernel, is hard to read, violates the layering rules, has
unclear locking schemes, or which uses obsolete interfaces. The point is
that, in order to be merged, the reiser4 code must be understandable by
people other than its original developers. As Alan Cox put it:
It doesn't matter if reiser4 causes crashes. It matters that people
can fix them, that they are actively fixed and the code is
maintainable. It will have bugs, all complex code has bugs. Hans
team have demonstrated the ability to fix some of those bugs fast,
but we also all remember what happened with reiser3 later on
despite early fast fixing.
"What happened later on" is that the reiser3 developers moved on to
reiser4; not only did they stop maintaining the code, but they actively opposed updates made to
the code by other developers. At this point, reiser3 is almost entirely
maintained by non-Namesys developers. In the future, the same thing may
well happen with reiser4.
The crux is this: the Linux kernel has been around for 14 years, and is
expected to last for quite a few more. The kernel hackers understand that,
if they are insufficiently careful about what they merge now, they will
have a big mess to deal with five years down the road. Many developers,
working in all areas of the kernel, have had seemingly good code turned
away because the development community was worried about maintaining the
code in the future. The process is most frustrating for the people
involved, but it is absolutely essential if we want to continue to use
Linux into the future. To many, the difficulties encountered by reiser4
(and FUSE, and the realtime LSM, and class-based kernel resource
management, and ...) represent the kernel development process at its worst,
but the opposite is true.
That said, reiser4 has had a harder time and more microscopes applied to its
code than many other developments. Mr. Reiser's approach to community
relations, which strikes many as occasionally belligerent and paranoiac,
certainly has not helped here. This issue has been discussed often, but
there is another issue which deserves airing: some people are clearly
uncomfortable with the vision behind the ongoing Reiser filesystem effort.
It doesn't quite look like the Unix systems we grew up with. Linux is not
an experimental or research-oriented system, so the inclusion of radically
different ideas of how the system should work must be carefully
considered. But Linux must also evolve, or risk irrelevance in the
future. Hans Reiser's efforts to push that evolution are a good thing; the
community discourages such work at its peril. So perhaps the time has come
to let reiser4 in; the wider community can then get to work dealing with
any remaining issues.
Comments (53 posted)
Back in May, 1998, a group of high-profile Linux development and business
figures (including Linus Torvalds, Jon 'maddog' Hall, Bruce Perens, Ransom
Love, Larry Augustin, Eric Raymond, and others) proposed
the creation of a
Linux application binary interface (ABI) standard. This effort, called the
"Linux Standard Base," would help to ensure that applications ran on all
Linux systems. In this way, it was hoped, a great wealth of applications
for Linux would be created, and Linux would avoid the sort of fragmentation
which afflicted proprietary Unix systems. The LSB would include a formal
specification and a reference implementation; applications which ran on the
reference system could be expected to run on all LSB-compliant systems.
More than seven years later, version 3.0 of the LSB specification has been
With this release, the LSB requires the system to have a relatively new
compiler and toolchain (gcc-3.4 or newer), adds some libraries and
interfaces, and cleans up some obsolete interfaces. There are two core
variants of the LSB specification, depending on whether the target system
is expected to have graphics capability or not. Sample implementations are
available for eight different architectures. The release notes
have more details, for those who are curious.
In many circles, however, the LSB 3.0 release is being greeted with a big
yawn. Most Linux users probably have a hard time seeing how the LSB
benefits them. Ulrich Drepper, who, as maintainer of glibc is faced with a
wide range of LSB compliance issues, has recently claimed that
the LSB lacks value and should be dropped. It is a rare Linux user who
chooses a distribution or application based on its adherence to the LSB.
The stated purpose of the LSB was to encourage the availability of
applications - both free and proprietary - for Linux. So it is telling
that, among the available Linux applications, very few claim to be targeted
at LSB-compliant systems. In fact, your editor found just
one beyond the special versions of free applications in the LSB's own application battery: it's Appgen's
MyBooks, which works on bleeding-edge LSB-compliant systems like SUSE 8.1 and
SCO OpenLinux. In general, application vendors are not targeting the LSB;
they are, instead, certifying specific distributions.
Not everybody feels a need for wide availability of proprietary
applications for Linux. But, for those who do, the certification of
individual distributions is exactly the sort of situation that the LSB was
created to prevent. From that standpoint, the LSB would appear to have
That said, the LSB effort has certainly had a positive effect in bringing
Linux distributions closer, and in raising awareness among distributors of
how their offerings diverge from the standard. Even if an application is
not specifically aimed at LSB compliance, the fact that it probably just
works on non-certified systems is, at least in part, attributable to the
LSB. There is value in separating the core part of a distribution (that
which, in some sense, makes it "Linux") from the additional features and
services distributors throw in to add value to their offerings. The LSB
helps to bring that separation about.
From the moment that Linux started to attract attention outside of the development
community, detractors have grumbled that it would fragment in the same way
that Unix did. Yet, despite the existence of hundreds of distributions,
several of which are widely used, this fragmentation has not happened.
Linux applications remain portable, and, just as importantly, switching
from one distribution to another is (usually) nearly painless. Linux is
Linux, regardless of the distributor. The reasons for this state of
affairs include the use of a (more or less) common kernel and application
base, and the fact that free licensing makes it easy for good ideas to move
quickly from one distribution to another. But there is a place for
standards as well. As long as the LSB continues to codify current
expectations of what a Linux system should be, it will help to keep the
Linux universe coherent.
Comments (5 posted)
Page editor: Jonathan Corbet
Next page: Security>>