LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
Letters to the editor
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for September 22, 2005Two approaches to Open gadgetsThe 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 applications. 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:
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 first place. 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.
Reiser4 and kernel inclusionFilesystem 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 back 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.
The relevance of the Linux Standard BaseBack 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 released. 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 failed. 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.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||