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 14, 2006Democracy player 0.9Last February, the Participatory Culture Foundation announced its existence with the launch of the "Democracy" player, billed as "the world's first comprehensive open source Internet TV system." Many Linux users may be excused for not trying out the program at that time; despite being a GPL-licensed program, Democracy had not been ported to the Linux platform.That situation has now changed; on September 11, Democracy 0.9 was announced. It runs on Linux, and packages for Debian, Fedora Core, Gentoo, and Ubuntu are provided; the source is available for everybody else. Beyond the Linux port, this version promises a polished user interface, a new playlist capability, Flash video support, and more. Your editor clearly had no choice; a tool like this simply must be tried out. Unfortunately, the Democracy experience is still rather spotty at best. It requires the installation of a number of proprietary codecs (which is not particularly surprising, once one thinks about it - the Democracy developers will have no magic solutions there). The system can be sluggish to respond, and your editor never was able to get it to display a video in its own window. It also would not explain why it failed to display anything, so there was little to be done about it. But your editor was able to get far enough to realize one important thing: video display is not really what Democracy is about in the first place. This tool is really a sort of video feed aggregator for free video content; it has all the required features for sorting feeds into categories, collecting votes for interesting videos, using BitTorrent to download videos in a provider-friendly way, and more. There is also significant support for people who want to create their own video feeds. What Democracy and its supporting foundation are trying to do is to get as many people as possible into the business of creating and distributing interesting content. The term "Internet TV" is somewhat off the mark - Democracy will suit couch potatoes just fine, but its real purpose is to get them off their couches and participating in the process. It is trying to create a world where video content is free, universal, and compelling - so it has tools for finding and distributing videos but a distinct lack of DRM support. This is an important goal - television is too important to leave to the TV companies. If the Democracy system can help to bring more free content into existence, it will have done a good thing. Some progress in that direction has been made: there are, it is said, some 600 channels of free content available now, and, doubtless, more to come. The current code has real promise; it looks like a capable system for discovering, distributing, and managing interesting video content. If they can get past the remaining troublesome issues, the Democracy hackers will have created a valuable tool indeed.
cdrecord - how the distributors are respondingOne month ago, LWN ran an article about the cdrtools license change and resulting controversy. The biggest issue remains the distribution of binary versions of the mkisofs utility. This tool is licensed under the GPL, and has copyrights held by a number of authors. The current version, however, requires the libscg library - which is now distributed under Sun's CDDL license. Since the GPL and the CDDL are mutually incompatible, it is hard to see how mkisofs can be distributed legally.That situation has not changed in the last month; cdrtools author Jörg Schilling appears to be determined to go forward with the license change. What has happened, however, is that a number of distributors have responded to the change - though not all have responded in the same way. Here is a summary of what the distributors are doing:
The overall picture that results is that, while a number of distributors are taking overt action in response to the cdrtools licensing issues, others appear to be waiting until things settle - and a final 2.01.01 release is made. Only one of the distributors listed above (Mandriva) looks set, at the moment, to distribute a version of cdrtools released under the new license. For years, there has been occasional talk of forking the cdrtools package. It has remained talk, however; CD burning can be a tricky task, and, as a result, cdrtools is not a trivial package to take on. It now appears likely that this fork will happen at last; the licensing changes have given the distributors (at least those most concerned with these issues) little choice. The real remaining question, then, would be: just how many forks will result? No distributor has an interest in taking on the full maintenance of a package like this, so the incentives should be in place to bring everybody together on a single CD burning utility.
Where have all the reviewers gone?One of the often-proclaimed advantages of the free software development model is that of peer review. Our code, we claim, is better because it has been reviewed and improved by a variety of people beyond the original author(s). Reviewers, with their unique perspective, will find bugs and generally help new code fit properly into an existing project. This review process is seen as being so important that a number of projects will not accept code until it has been picked over by other developers.So reviewers are a fundamental part of the process. They are also, it seems, somewhat scarce. Consider a couple of examples:
If we truly believe that code review is a crucial part of the free software process (and, for the most part, it is likely that we do believe this), then the idea that projects are being slowed by the lack of reviewers is a bit worrying. At best, a reviewer shortage will be a bottleneck in the process; a worse possibility is that some projects will simply decide to do without. Reviewers serve a number of purposes. They can often immediately spot that bug that the developer has stared at for hours without finding. If the code is hard to understand, the reviewers will be the first to notice. If the associated documentation is incorrect or (as is more often the case) absent, the reviewers will notice that as well. When code appears to have been written using some sort of specialized, non-public knowledge, reviewers can inquire as to its provenance. Coding style issues, API misuse, inefficient algorithms, use of outdated interfaces, and more can be caught in the review process before the code hits the project's mainline. Reviewers really do increase a project's code quality and long-term maintainability. The problem is that code review can be a difficult, tiring, and thankless job. Human nature being what it is, people will often show less than the appropriate amount of gratitude when a reviewer points out their mistakes in public. This is especially true if the code has problems which will require significant amounts of work to fix. The reviewer did not create these problems, he or she is simply the messenger with the bad news. So reviewers tend to get grumpy, especially when they see the same mistakes being made over and over again. Developers get credit for their work, in various forms. It is a rare project release, however, which publicly acknowledges those who reviewed the code. Given that writing code is not only a more visible activity, but it also tends to be more fun than reviewing code written by others, it is not surprising that many developers choose to concentrate on their own work. Finally, reviewing code can be intimidating - especially if the patch of interest has a Big Name behind it. Many potential reviewers may feel that they simply do not have the standing to poke at other peoples' work. The fact is, however, that even people with a relatively small amount of experience can provide useful reviews, and learn from the process. From Greg's OLS keynote:
When you are learning to play an instrument, you don't start out
writing full symphonies on your own, you spend years reading other
peoples scores, and learning how things are put together and work
and interact. Only later do you start writing your own music, small
tunes, and then, if you want, working up to bigger pieces. The same
goes for programming. You can learn a lot from reading and
understanding other people's code. Study the things posted, and ask
why things are done specific ways, and point out problems that you
have noticed.
If we want to create the best free systems we can, we must ensure that the review portion of the process does not get slighted. To that end, people who have the requisite skills would do well to dedicate a bit of their time to reviewing code in a project that interests them. Buy a reviewer a beer, and forgive them if they tell you, in front of hundreds or thousands of developers, that your work is best suited for a place in the project's "bad examples" repository. Listen to what the reviewers say, respond to it, and thank them. The result will be better software for all of us.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||