User: Password:
Subscribe / Log in / New account

Leading items

Democracy player 0.9

Last 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.

Comments (13 posted)

cdrecord - how the distributors are responding

One 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:

  • Debian was the first distributor to notice the license problem, and the Debian developers have reacted quickly. It now appears that etch will ship with cdrkit, a new project based on a version of cdrtools from before the license change. The Debian maintainers are actively pushing forward with this project, and they have approached other distributors to see if they want to help.

  • Fedora has dropped back to the 2.01 release, which predates the most controversial license changes. That change allows them to get the Fedora Core 6 release out without excess worry or delay while the longer-term plan is worked out. That process appears to be going slowly, with the Fedora cdrtools maintainer not yet participating in the discussion.

    Meanwhile, Fedora has also slipped a version of libburn into the Extras repository.

  • Gentoo has taken an interesting approach. Since Gentoo distributes in source form, the developers have concluded that they need not worry about this issue. There is no combination of mkisofs and libscg until the end user builds a binary - and the user has the right to do that. As long as those binaries are not distributed, licensing does not come into play. Thus, Gentoo ships the (relicensed) 2.01.01-a11 release.

    That said, the Gentoo developers have also put cdrkit into their distribution, and it looks like that is what they plan to support going into the future.

  • Mandriva has made no public statements about the license change at all. The recently announced Mandriva 2007 release candidate contains version 2.01.01-a11, which includes the relicensed code.

  • Slackware has no recent cdrtools-related entries in the current changelog. The upcoming Slackware 11 release appears to be poised to ship version 2.01.

  • SUSE's response, so far, is "We'll look into cdrkit." The current "factory" OpenSUSE tree contains version 2.01.

  • Ubuntu currently has 2.01.01-a3 (which predates the license change) in the repository for the upcoming "edgy" release; cdrkit has not yet made an appearance there. It would be surprising if Ubuntu failed to follow Debian's lead on this, however.

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.

Comments (4 posted)

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:

  • In the kernel space, the reiser4 filesystem has been held up for some time. There are many reasons for that delay, but one of those has been the lack of a thorough review by somebody who understands the Linux virtual filesystem layer well. Greg Kroah-Hartman, in his OLS keynote, said, more generally: "The big problem ... is we really only have a very small group of people reviewing code in the kernel community."

  • The PostgreSQL developers have been engaged in a lengthy discussion on the upcoming 8.2 release, why it is taking as long as it is, and why this release appears (to them) to have little in the way of exciting new features. The conversation has touched on various aspects of that project's development process; there are many things for those developers to think about. One of them, though, as expressed by one of the participants, is: "...the real problem seems to be we do not have enough patch reviewers."

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.

Comments (21 posted)

Page editor: Jonathan Corbet
Next page: Security>>

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds