LWN.net Logo

Advertisement

E-Commerce & credit card processing - the Open Source way!

Advertise here

LWN.net Weekly Edition for January 6, 2011

2011 predictions

By Jonathan Corbet
January 5, 2011
As your editor reviewed his 2010 predictions, the thought that often came to mind was "obvious" or "boring." Making obvious predictions may be a way to boost your editor's sense of omniscience (said omniscience, unfortunately, only being acknowledged by your editor's dog), but it takes away some of the fun. So, this time around, an attempt has been made to go just a little further afield. With luck, it will make for some fun in December when it is time to come back and laugh at how bad these guesses were.

The LibreOffice fork will take off, taking most of the wind out of OpenOffice's sails by the end of the year. StarOffice may continue as a commercial product, but its user base will be small. LibreOffice will improve considerably in this time but, your editor confidently predicts, it will still be too big and still really annoying to use.

The Mageia and IllumOS forks will fare less well. The Mageia folks have seemingly been mostly concerned with lengthy discussions about the layout of the package repositories so far; no release is in sight. More to the point, though, it seems that the rumors of Mandriva's demise may have been a little exaggerated. IllumOS looks like it may lack a critical mass of developers, and some of the most committed people appear to not get along very well. It's not at all clear that anything derived from Solaris will have relevance in the free software world for long.

MeeGo will be a surprisingly big success. Android is increasingly looking like the Windows of the handset world - a universal operating environment which turns the hardware into a boring, low-margin commodity product. Manufacturers will be keen to see a competitor which allows them to differentiate themselves and to limit Google's control.

Along those same lines, it will be a make-or-break year for WebOS, which has yet to make a lot of waves under HP's management. Should the system be released on (relatively) open handsets, it may yet surprise us.

Google will take its place as a major kernel contributor. Google is already a massive contributor of code to the community, of course, even if its "throw it over the wall" style does not suit everybody. Over the course of the last year, though, your editor has noticed an increase in Google engineers showing up at conferences and discussing the company's needs. Google folk are increasingly being allowed (and encouraged) to come out and play, and everybody will benefit from that.

ChromeOS will struggle this year. The need for another "thin terminal" system is not entirely clear, especially once ChromeOS users discover that they can get a real Linux-based operating system on the same hardware. That "real" system may be a netbook-oriented distribution, or it may be some form of Android. Either way, it only takes one must-have application to drive users toward a distribution which is oriented toward the installation of local applications.

We will see huge legal and technical battles as governments and corporations try to restrict what can be done on the net. Futile attempts to shut down sites like Wikileaks or to stop those who would demonstrate the weakness of the cellular network can only lead to an increase in repressive actions worldwide. Efforts by network providers to increase revenues will have similar effects. It will be a tumultuous year.

Targeted attacks will increase; Stuxnet, said by some to have destroyed 1000 centrifuges in Iran, is only the beginning. Security will be a bigger deal, and Linux will benefit from an increased emphasis on security. That said, alas, it would not be surprising to see a successful Stuxnet-like attack against Linux-based systems this year.

A free driver for an embedded graphics chipset will be released by a previously recalcitrant vendor. Embedded graphics is currently one of the most problematic areas for free support, but the commercial pressures will prove to be strong enough to motivate at least one vendor to open up. It is a pattern we have seen many times in the past.

At the distribution level, the tension between providing stability and providing current software will increase. Fedora has already had significant amounts of internal strife around this issue; at the other end, users of stable "enterprise" distributions often find themselves needing something newer. In 2010, we saw Oracle basing an enterprise distribution on a newer kernel; in 2011, we'll see more attempts to provide the best of both worlds.

openSUSE will change in response to the above-mentioned pressures and others; by the end of the year we may see ultra-stable and leading-edge variants of openSUSE alongside the current "just right" distribution. What will happen to Novell and SUSE under Attachmate is hard to predict, but openSUSE will continue to thrive regardless.

Business models based on control of the code will fade in prominence over the course of the year. It will become clear that "open core" programs, while being free software, do not generate the sort of community that truly brings code to life. Projects requiring copyright assignment will increasingly be seen in the same light - especially those projects which are owned by for-profit corporations. Neither open core nor copyright assignment will go away in 2011, but developers - who already favor more open and diversely-owned projects - will shy away from them.

Need we conclude by saying that Linux and free software will finish the year stronger than ever? That was clear in late 1997 when LWN was in the planning stages, and it hasn't changed since. This year will certainly have its ups and downs, but our community will find itself in great shape at the other end.

Comments (33 posted)

Mozilla releases a beta of the revised MPL

January 5, 2011

This article was contributed by Nathan Willis

The Mozilla Foundation released "beta 1" of its upcoming revision to the Mozilla Public License (MPL) last month — the license's first update in more than a decade. Mozilla first set out to shorten, simplify, and modernize the MPL in March of 2010, developing the preliminary revisions based on feedback from its own license compliance team and talks with the Free Software Foundation (FSF) and Open Source Initiative (OSI). MPL 2.0 Beta 1 is open for public comment, which the project hopes to incorporate into a final release candidate in the coming months.

Rewriting in public

The current MPL is at version 1.1, which debuted in 1999. Back at the beginning of the update effort, Mozilla defined a set of issues it wanted to address in the new revision. These started with simplifying both the language of the license as well as its requirements; common terminology in software licensing has changed over the last ten years, and downstream MPL users found several of the notification and re-licensing requirements confusing or difficult. Although the MPL is specific to Mozilla, and derivative licenses could alter jurisdiction-specific terms, Mozilla's global developer community reportedly had trouble with US-centric copyright- and contract-law language, necessitating some globalization work.

Perhaps the most far-reaching changes to the MPL are those that affect its compatibility with the other top-tier FLOSS licenses: namely the GPL, LGPL, and the Apache license, which is a popular choice for web-oriented projects. In addition to Mozilla itself, some high-profile projects use derivatives of the existing MPL, including Sun's Common Development and Distribution License (CDDL), the Yahoo Public License, and several individual projects, such as Erlang and SugarCRM.

Mozilla made it clear at the outset that it was committed to remaining an open source license as defined by the OSI and both a copyleft and free software license as defined by the FSF. However, the project also stated clearly that it would not be considering two potential changes: moving from the existing "weak copyleft" to a "strong copyleft," and incorporating a Software-as-a-Service (SaaS) clause à la the AGPL. Mozilla reasoned that the former change would radically impact the way Mozilla projects function, and the latter — although an important issue — is controversial enough that it would overshadow the work of updating and modernizing the rest of the license.

The first "alpha" draft of MPL 2.0 was released in July, written by Mozilla's MPL team, and was followed by two more alphas in September and October. Although the initial feedback mechanism was the MPL-Update mailing list, beginning with alpha 2 an HTML version of the license was published at the web-annotation site co-ment.com so that interested parties could mark up and comment on specific lines and phrases. Using that system, interested parties can add comments to a shared version of the the current revision, which will be reviewed by the project team.

The co-ment.com utility is very easy to work with, although it allows any user to attach a name and email address to their mark-up without address verification — so be wary if you spot suspiciously-exuberant cheers attributed to key FSF officials (for the record, I did submit four grammatical comments under the username "n8willis" just to see how it worked). Mozilla notes that co-ment.com itself was inspired by the FSF's online annotation tool used in the GPLv3 comment process. It seems a bit ironic that Mozilla chose to utilize a closed-source tool rather than the original — although FSF's own description of the tool as "daunting-to-install" suggests one simple explanation.

The MPL 2.0 alphas were low-profile announcements, but the December beta was the subject of a blog announcement by Mozilla's Mitchell Baker, soliciting comments from the public at large. The draft license is available as plain text, HTML, and PDF, and is accompanied by a discussion document [PDF] that includes justifications for the major changes, plus a full diff between beta 1 and alpha 3 and a full diff between beta 1 and MPL version 1.1.

The terms they are a-changin'

Most of the changes, naturally, took place between MPL 1.1 and the alphas, though 2.0 beta 1 brought its share of tweaks. The new license is approximately 38% shorter (2289 words, down from 3702), thanks to the removal of several definitions in section 1 and some redundant language, plus the consolidation of several sections (such as independent references to requirements that persist in future versions of the MPL). The substantive changes begin with the removal of all instances of the terms "Original Software" and "Initial Developer." These terms were used in MPL 1.1 to make distinctions between the creator of an MPL-licensed work and subsequent contributors; now all "Contributors" and "Contributions" are treated equally.

There are also simplifications in section 3 about distributing executables. MPL 1.1 spends some time discussing the differences between distributing source code and executables, enumerating rules about placing source code on the same physical media as executables, and honoring written offers. The 2.0 beta dispenses with most of that in favor of a much shorter "You must inform third-party recipients of the Executable form how they can obtain a copy of such Source Code form by reasonable means, at no more than a nominal charge." In a related change, section 1 also abbreviates the older version's discussion of what constitutes "source code" — calling it the "form of the work preferred for making modifications." This is meant to simplify debate over things like scripting languages, where the line between executable and source becomes fuzzy.

The beta also simplifies the notification process required of derivative software makers in section 3 considerably. MPL 1.1 required them describe any changes that they made to the MPL source code, to inform their users of all third-party intellectual property claims they were aware of that pertained to the code, and to document API changes that would be affected by patent claims. In several places it even specified that these notifications must be done in a file named LEGAL.The revised section 3.1 states that source distribution requires you to "inform recipients that the Covered Software is governed by the terms of this License, and how they can obtain a copy of this License." Section 3.2 says that executable distribution requires you to make the source available as described in 3.1, and "inform third-party recipients of the Executable form how they can obtain a copy of such Source Code form by reasonable means, at no more than a nominal charge." Reasonable means and nominal charge are not explicitly defined.

Section 5.2 is the "patent defense" clause, stating that initiating litigation (against any entity) involving a patent claim against the software terminates the license. This section was rewritten so that its language was compatible with the Apache license, closing a much-lamented inconsistency between the two. It also explicitly excludes several types of defensive litigation (such as seeking a declaratory judgment) from triggering the termination clause, and clarifies some grace-period language pertaining to restoring someone's right to redistribute the software if they come back into compliance with the license.

The globalization improvements are found in the "Miscellaneous" section, section 8. While the MPL 1.1 specified that litigation about the license could only be brought in the Northern District of California, the new license requires it to be brought in "the courts of a jurisdiction wherein the defendant maintains its principal place of business and such litigation shall be governed by laws of that jurisdiction" — which is seen as simplifying the situation for third-party code contributors.

Section 9 updates and clarifies the Mozilla Foundation as the sole steward of the MPL, removing all lingering mention of Netscape Corporation, and simplifies the language dealing with creating new licenses based on the MPL (essentially, references to Mozilla must be removed and the name of the license changed).

Compatibility with the FSF's license portfolio is dealt with in a new manner in section 10. While MPL 1.1 touched on other licenses only in a "Multiple Licensed Code" section which permitted the Initial Developer to provide a license choice, MPL 2.0 beta 1 allows anyone to designate their own contributions as "Compatible Software" with the GPL (2.0 or later), LGPL (2.1 or later), or AGPL (3.0 or later). Section 10.3 further specifies that developers may distribute a combined, derivative work based on MPL 2.0 code under one of those licenses, provided that they make their own contributions available under the MPL.

These requirements attempt to deal with one of the Mozilla community's unique sticking points, the "single-license fork". The problem occurs when a project builds on top of Mozilla code (which is tri-licensed under the MPL, GPL, or LGPL), but only releases modifications under one of the non-MPL licenses, thus effectively cutting it off from use by other tri-licensed Mozilla projects.

Impact

The revised MPL will probably only have a direct impact on two distinct sets of users: contributors to official Mozilla projects that live in non-US jurisdictions, and developers of outside, derivative projects. The former group benefits from the clearer language around copyrights and patents along with the generalized rules about litigation and jurisdiction. The latter group gets a mixed bag; better compatibility with GPL and Apache licensed works is a definite plus, while those players not interested in licensing their contributions under the MPL may not like the closing of the single-license fork loophole.

On the other hand, the reorganization and simplification of the license text benefits everyone. Ten years is a long time in this industry, and although most people's understanding of the issues and terms used in the MPL has not changed in that time, Mozilla has learned from experience that some of the requirements and clauses were not having the desired effect. The principle example of this is MPL 1.1's section 3.3 — the requirement that downstream redistributors describe all modifications made to the original code and include a statement telling users that the files have been modified from their original forms. Mozilla admits in practice this requirement is usually ignored, and in the era of distributed version control it adds little value.

It will be interesting to see how many of the changes proposed for MPL 2.0 are adopted by downstream licenses. Some, particularly those from projects that build on the Mozilla codebase like Celtx, will likely release new versions of their own licenses to maintain language compatibility.

It's less clear what will happen to the corporate controlled licenses like CDDL. CDDL has entertained proposed revisions on its own development path since its creation, and few if any of Sun's CDDL-licensed products interact with official Mozilla code. It is interesting to note, however, that several of the changes made to CDDL from MPL 1.1 are also incorporated in MPL 2.0 beta 1: use of the term "Software" instead of "Code," elimination of several definitions, and simplifying the distribution requirement language.

On that subject, however, it is also interesting that the CDDL's authors chose to widen the definition of distribution so that it includes application service providers, while Mozilla chose not address network applications at all. The project clearly needs to do so at some point, not just because of its stated commitment to the open web philosophy, but because it develops several high-profile web applications itself: Bugzilla, Bonsai, Tinderbox, Skywriter, Firefox Sync, and the Mozilla Labs Raindrop experiment.

Looking at the comments and the mailing list, there does not appear to be much call from the public as a whole for Mozilla to take a stronger copyleft stance. To review, MPL is regarded by the FSF as a "weak" copyleft because it uses a "per file" copyleft model. In other words, if you make changes to a source file, the modified file must be released under the MPL. But you can link the original MPL-ed software to other code that is published under any license at all (including a proprietary one). In contrast, the LGPL regards linking two applications or libraries as triggering the LGPL's license on the combined work.

Luis Villa, who has spearheaded the public comment and feedback process for MPL, says that the final MPL 2.0 is a "'release when ready' old-school open source process" that may involve another beta before any release candidate version is published, if there are enough comments or questions. The comment system for beta 1 remains open to the public until the team decides otherwise, as does the MPL-Update mailing list. Finally, for those with comments they wish to share away from the public's prying eyes, Mozilla has also established a "private feedback" email address.

Licenses are rarely regarded as exciting and cool, but as everyone in the FOSS universe knows, they constitute the backbone of what keeps free software free and open source open. Of the major licenses in use today, MPL is the second oldest in terms of when it was last updated — only the minimal and unrestrictive MIT/X11 license has gone longer without a refresh. Opportunities to participate in the license-drafting process are rare — so if you have a concern, the time to speak up is now.

Comments (16 posted)

A look at some free RSS readers

January 1, 2011

This article was contributed by Joe 'Zonker' Brockmeier.

Like many people, I get almost all of my news online. To get it quickly and efficiently, I use a newsreader to skim the RSS or Atom feeds from sites (like LWN) that I find useful. Until recently, I'd been using Google Reader as the best option to manage and read my feeds — but after hearing about the Mutt of newsreaders, I decided to skim the open source options for news reading to see if I could make the switch.

The first on my list was Newsbeuter. The name is a play on "Wildbeuter," which is German for "hunter-gatherer," which seems apt enough for how one forages for information today. Newsbeuter is a text-based newsreader that bears more than a passing resemblance to Mutt, not just in appearance but also in configurability. I also found it interesting because it offered synchronization with Google Reader — meaning that it should be a simple thing to maintain my existing feeds without any real hassle.

The 2.3 release of Newsbeuter was released in June, so I compiled that and set to work. Note that 2.3 is packaged for Fedora, but not for Ubuntu which still carries the 2.2 release. That release has some issues with Google Reader sync, so if you're on Ubuntu or an Ubuntu-derived distribution and want Reader support you'll need to compile from source. Note that Newsbeuter also supports Bloglines, but I don't have an active Bloglines account.

I started with my Google Reader account and found that Newsbeuter works as advertised — albeit with a bit of work. The release notes for Newsbeuter say that it supports not only syncing with Google Reader, but also the sharing and starring features in Reader. If you share an article in Google Reader it can be seen by any of the people "following" your account (an attempt by Google to dip into social networking). Starred articles are saved for later. These work, but it requires editing the Newsbeuter configuration file and setting up "flags" for starring and saving. Newsbeuter doesn't support commenting on articles through Google Reader, however, but truly dedicated users can follow this guide by Aaron Toponce to use Newsbeuter and Mutt to add comments to items shared through Google Reader.

[Newsbeuter feed]

The display for Newsbeuter is much like Mutt — when you open Newsbeuter, all the feeds are displayed in a long list that includes the number of articles available and how many are read/unread. You drill down by feed or using tags (more on that shortly) to sort the feeds or articles you want to display. Everything, of course, is keyboard-driven and once you have the keystrokes down you can skim through feeds very quickly and efficiently. Even when managing hundreds of feeds and syncing with Google Reader, Newsbeuter was always speedy.

Want to save something for later? Newsbeuter will save any article as a text file, with URLs from the article saved as footnotes in the feed. If you've used Mutt, Pine, or another text-based mail reader, Newsbeuter will feel quite familiar.

Newsbeuter does more than just fetch, display, and save feeds, of course. It has advanced features that let users filter, tag, bookmark, and even script interactions with their RSS feeds. You can set up tags for one or more feeds and use those tags to show (or not) specific lists of feeds. This is done automatically if you're importing feeds from Google Reader — Newsbeuter sets up tags for each folder (if any) that you have used to organize feeds in Google Reader.

Newsbeuter supports a "killfile" for feeds, so users can weed out specific topics. This works by feed or across all feeds. For example, you could set up a killfile to ignore any articles from LWN's RSS feed that contains the name of a distribution that you don't care about.

It also supports "query feeds," which are special feeds created from running a query on one or more feeds. This is a filter that is created from the cache of downloaded articles. For instance, you could set up a query feed that shows only unread articles, or groups the articles from two or more feeds. Queries and other filters can be built using the filter language for Newsbeuter, which is fairly expressive.

[Newsbeuter article]

Since Newsbeuter is a text program, it leaves something to be desired in displaying feeds that feature much in the way of graphics. Since I subscribe to several picture of the day feeds, such as the Astronomy Picture of the Day feed, I needed to find a way to open certain items in a regular browser. Newsbeuter, of course, has a command to open feeds in an external browser — and this can be configured to work with any browser from Lynx to Firefox.

Newsbeuter even features a limited command mode so users can modify Newsbeuter's configuration on the fly, save articles, and jump through article feeds.

In short, Newsbeuter can be configured every which way from Sunday. The color scheme, how feeds are displayed, how articles are bookmarked or saved for later — it's one of the most flexible feed readers that you'll encounter. It's also one that requires a certain amount of dedication — configuring Newsbeuter to work just right can take quite a lot of experimentation. Like Mutt, this pays heavy dividends for users who spend a great deal of time skimming feeds. For casual users, Newsbeuter is probably overkill.

For podcast fans, Newsbeuter also includes a podcast manager called Podbeuter. It handles downloading podcasts and can be configured to pass podcasts on to helper programs to play the podcasts. Not being a podcast fan, this isn't something I've made extensive use of, but it's a vital feature for many users.

Newsbeuter source is available from Github, and is under an MIT/X license. If you're compiling from source, it requires Structured Terminal Forms Language/Library (STFL), SQLite 3.5 or newer, libcurl, and several other dependencies that might not be available by default.

Aggregation and mail readers

Newsbeuter, like Mutt, is swift, efficient, and highly configurable. But Newsbeuter isn't actually integrated with Mutt. For users who want to tie feeds into their mail client, Linux offers quite a few RSS/Atom-friendly mailers.

For users who want to tie feed reading with their email, Evolution, Thunderbird, and Claws Mail can all handle the task. Thunderbird has built-in support for feeds, whereas Evolution and Claws Mail require a plugin to be able to consume RSS. Claws actually requires two plugins for feeds if you want to render HTML properly, as Claws doesn't handle HTML without enabling an HTML viewer in addition to the RSSyl feed plugin.

For processing RSS feeds, Thunderbird seemed to handle importing and fetching feeds faster than Claws or Evolution. Evolution was by far the slowest to import the feed list I exported from Google Reader. As for reading feeds, it's really a matter of taste — and if you choose to read feeds from within the mail client, it's probably because you've already settled on a mail client. The main complaint I had with Thunderbird was that it didn't respect the folder hierarchy when importing my feed list from Google — it choose to import more than 100 feeds into separate folders for each feed, rather than recognizing the folder organization that was set up in Google Reader.

GUI aggregators

Aside from GUI mail clients with aggregation features, you'll find quite a few standalone GUI clients as well. The offerings are far too numerous to describe each in depth, but some of the most popular are Blam, Liferea, Akregator, and RSSOwl.

Blam is part of the GNOME Project, and ideal for users who want a minimalist approach to feed reading. It provides all the basics that users would need to manage and read a set of feeds — but that's about it. For instance, unlike many readers, Blam has no way to save an entry for later use. It also is limited to one entry at a time — most GUI readers allow the user to open multiple entries in new tabs or a new window. It's a decent choice for users who have just a handful of feeds, and don't want to save feeds for later, but if configurability is desirable, Blam isn't the best choice.

Liferea is a more flexible GTK-based option. It offers several modes to view feeds, a tabbed interface (to view multiple entries/feeds) and integrates with external services to bookmark items from feeds that users would like to save for later or share on social services. Liferea supports everything from Delicious to Twitter, and quite a few more.

Another bonus for Liferea is integration with Bloglines and Google Reader. You can manage feeds locally, or just hook Liferea into a Google Reader or Bloglines account and go. Its rendering of Google Reader feeds is another story. Liferea ignores folders, so all Google Reader feeds are displayed as a flat list. Liferea also gets bogged down a bit when handling hundreds of feeds — so it may not be the best choice for power users who have a long list of feeds to manage. When using Liferea connected to my Google Reader account it was very boggy, and had problems parsing some of the feeds.

[Akregator]

Akregator is a full-featured feed reader that integrates with the Kontact suite for KDE, or runs as a standalone application. Like Liferea, it supports several views and has a tabbed interface. It's fast and doesn't choke on a large set of feeds. It doesn't offer integration with online newsreaders, but it does import Google Reader's OPML export properly — that is, if you have feeds organized by folders, Akregator recognizes and creates those folders when importing feeds. You can save feeds in Akregator by marking them "important," but it doesn't really give any way to export an entry.

RSSOwl is a multi-platform newsreader based on Eclipse. Unlike Liferea, Blam, and Akregator, it's not packaged with most major distributions — so if you want to give RSSOwl a shot you'll need to get it from the RSSOwl site. The project does offer Linux-specific packages, so it's not hard to install. Since it's based on Eclipse, you'll also need to have a Java Runtime Environment (JRE) to use it.

[RSSOwl]

While RSSOwl doesn't support Google Reader integration, it will import feeds directly from Google Reader without requiring you to export an OPML file. You'll need to provide your username and password, and RSSOwl provides an import wizard that gives the option of importing one, some, or all feeds from Google Reader. It also has a tutorial that runs on startup to walk through all of its features. Overall, it's a very well-polished application. In addition to reading and saving feeds, it supports saved searches — so you can create a special feed that consists of results for a search against one or more feeds. So, for example, you could create a special feed from a search for "Linus" against LWN's RSS feed and check that daily for kernel updates.

RSSOwl also has features to help discover new sources of news that might be of interest. Go to Tools -> "Find new Feeds" and enter a search term. RSSOwl turns up a list of feeds, and their descriptions, that you can opt to subscribe to. The quality of the results vary, of course. A search for "Linux kernel" turned up everything from Greg Kroah-Hartman's blog to some relatively obscure feeds of comments related to posts about Linux on some random Web sites. If Blam is a minimal feed reader, RSSOwl is a maximal reader — very capable, but a bit complex. If you spend a lot of time in the feed reader, it's worth spending the time to learn. The only real complaints I have about RSSOwl are that it doesn't actually sync with Google Reader, and that its sharing features are a bit primitive. When sending to Twitter, for instance, it just opens Twitter and pastes the URL for the original news item in the update form. It'd be nice if it included the post title and shortened the URL.

Finally, it's worth noting that RSSOwl is probably the best documented of all the options — not only does it have extensive help, but it also has a fairly useful tutorial that is displayed on first run that explains its features.

Or you could just turn your Web browser into a newsreader. Firefox, of course, has native support for feeds as "live bookmarks." For users who have a few beloved feeds or a select few that they'd like to keep close tabs on, the live bookmarks are useful. This simply creates a folder of virtual bookmarks that link to entries from an RSS or Atom feed. Firefox simply lists the headline/title for each feed and then opens the source in the browser — so it's not much faster than just going to the site directly.

The Sage extension for Firefox turns Firefox into a full-blown feed reader. Sage has its own stylesheet, so all feeds look alike when using Sage, even though Firefox would be fully capable of displaying the full site. The Sage stylesheet can be modified, though, so users can tweak the output to their liking.

Feeds are displayed as a set of folders in the left-hand side of the Firefox window, much like the Bookmark or History sidebar. Note that only one sidebar can be in use at a time. Overall, Sage is a usable reader and handy for Firefox die-hards who just want to keep track of a few feeds. Sage will handle larger numbers of feeds, of course, but it becomes a bit unwieldy.

The other downside to Sage is that it's not necessarily available for the latest releases of Firefox. It tracks the stable releases OK, but Sage is not up to date for the Firefox 4.0 betas. Since I usually track the latest Firefox betas, it means that Sage is not an option.

Your very own Planet

Another way to go is to create your own Web site from a set of feeds, or create a "Planet" site for sharing a set of feeds so people can easily browse all the posts from news feeds specific to a project. This was made popular with the original Planet feed reader. It uses Feed Parser to consume feeds and a templating engine to produce static pages. However, Planet's development seems to have slowed considerably — if not entirely stopped. The last updates in Jeff Waugh's repository are dated early 2007.

Development seems to have carried on, somewhat quietly, with Planet Venus. It's not reflected on the Planet site at all, but digging through the mailing lists one finds development has continued under the name Venus or Planet Venus. Venus is "a radical refactoring of Planet 2.0," and development discussions continue on the old Planet mailing lists.

Another popular, and currently maintained, project is the RSS Aggregator Without Delusions of Grandeur, or rawdog. Like Planet and Venus, rawdog takes feeds and creates a static "river of news" that's suitable for a single user to keep track of her favorite feeds, or for publishing a planet Web site. Planet KDE, for instance, is based on rawdog.

The downside to Planet, Venus, and rawdog, is that they require the user to configure not just the aggregator software, but also to maintain a Web server. For publishing a project planet this is not particularly onerous, but for personal use it's overkill for most users. The planet-type aggregators are also a bit less flexible in terms of adding feeds, and they tend to be sensitive to malformed feeds. Whereas Thunderbird or Newsbeuter might just skip over a feed with errors or unrecognized elements, planet type aggregators tend to choke on malformed feeds and unrecognized elements.

Summary

It's safe to say that any Linux user will be able to find at least one feed reader that fits their needs. Even with all the newsreaders mentioned here, this isn't a comprehensive list of newsreader alternatives. Which one is best? That depends almost entirely on the user. Most any of the newsreaders would be adequate for users with a small (less than, say, 50) collection of feeds. But if you spend a fair amount of time skimming feeds for work or pleasure, a couple of newsreaders stand out.

Newsbeuter is the best for those who prefer keyboard-driven, text-based options. It's flexible, fast, and pays dividends for users who are willing to spend the time customizing it to fit their feed-reading habits. For those who prefer GUI apps, RSSOwl is the application with the most features and flexibility. Users who don't want to maintain a separate application for newsfeeds should look at Thunderbird.

It's interesting to note, though, that of all the options available none are really a competitor to Google Reader itself. Though one can find several Web-based aggregators that will build static "river of news"-style pages out of a feed collection, I couldn't find any real Web-based clients that allow feed management via the browser, or the same kind of feed organization (folders) and navigation that Reader offers. The closest option here would probably be Sage, for users who want to handle all their reading via the browser.

That aside, Linux users are not hurting for choice. The crop of newsreaders for Linux is plentiful, you only need to decide how you'd like to manage feeds and then select from several excellent options.

Comments (34 posted)

Page editor: Jonathan Corbet

Security

Default "secrets"

By Jake Edge
January 5, 2011

One of the simplest principles of cryptography is that the secret keys which are used for encryption must be kept, well, secret. Exposing the key to anyone other than the intended recipient of the message can pretty obviously lead to a compromise of the encrypted data. So, for example, hardcoding a secret key into a firmware image is unlikely to lead to secure communications using that key. Unfortunately, networking device makers—and the creators of free software firmware replacements for those devices—seem to have missed, or ignored, this basic principle.

The problem stems from the SSL keys that are installed into the firmware images for the devices. In many cases, those keys—including the supposedly private key—are generated when the image is built and then flashed into hundreds or thousands of different devices. If one can get access to the private SSL key, traffic encrypted with it (which might include HTTPS or VPN traffic) can be trivially decrypted. As the announcement of the LittleBlackBox project describes, it is, unfortunately, rather easy to obtain said keys; in fact the project provides a database of thousands of private keys indexed by their public key.

In practical terms, that means an attacker can access a vulnerable SSL-protected web site, retrieve the public key certificate, look up the corresponding private key, and decrypt any traffic that is sent or received by the web site. An attacker could also do a man-in-the-middle attack by pretending to be the site in question, as there would be no way to determine that the spoofer wasn't the real site. In order to do either of those things, though, the attacker must get access to the encrypted data stream.

Open, or weakly secured, wireless networks are the easiest way for an attacker to get that access—or to become a man in the middle. As the concerns over Firesheep have shown, there is still a lot of traffic that travels unencrypted over wireless networks. Ironically, HTTPS is touted as a solution to that problem, but that only works if the private keys are kept secret. For the web applications targeted by Firesheep, that is not likely to be a problem, as their private keys were presumably generated individually and kept safe. But for others who might be using wireless networks to configure their routers—or connect to another network via VPN—it could be a much bigger problem.

While reconfiguring your router from the local coffee shop may be a pretty rare event, even having the HTTPS-enabled web server available over the internet gives an attacker the ability to retrieve the public key, which can then be looked up in the LittleBlackBox database. If that SSL key is used for other things like VPN—something that might well be used at an open WiFi hotspot—that traffic is at risk as well. The right solution seems clear: don't supply default "secrets". In some ways, this problem parallels the longstanding, but hopefully improving, situation with default administrative passwords.

Device manufacturers and firmware projects should not be shipping SSL keys and either generate them at "first boot" or provide a way for users to generate and upload their own keys. There are a few different reasons that it isn't always done that way today, from concerns over devices having enough entropy to generate a random key to the amount of time it can take to generate a key on a slow CPU, but those reasons aren't really offset by the damage that could be done. Users who enable HTTPS access to their devices do so with the idea that it will be more secure, and can be used in places where unencrypted communication doesn't make sense.

There are also hurdles to overcome in either creating a key for each device (and/or firmware image) or providing instructions for users but, once again, that really doesn't help users that are relying on the device for secure communications. While some in the DD-WRT community don't see it as a big problem it is likely more serious than they are crediting. It would make far more sense to disable HTTPS access entirely—perhaps requiring a manual process to generate keys and enable that access—than it does to provide well-known keys.

While the problem highlighted by LittleBlackBox isn't earth-shattering, it does show the sometimes cavalier attitude towards security that is shown by some in the embedded device arena. When you are selling (or providing) a device or firmware that is meant to secure someone's network, it makes sense to proceed carefully. And to keep secrets, secret.

Comments (32 posted)

Brief items

Security quotes of the week

The bankers also fret that "future research, which may potentially be more damaging, may also be published in this level of detail". Indeed. Omar is one of my coauthors on a new Chip-and-PIN paper that's been accepted for Financial Cryptography 2011. So here is our Christmas present to the bankers: it means you all have to come to this conference to hear what we have to say!
-- Ross Anderson after a bankers' trade association tried to quash some Chip-and-PIN research

Of course, in addition to the "green" advantages of this technology, there are privacy implications. Even without your consent, the electric company and the water company are permitted to continuously measure your use of electricity and water; taken to the extreme, this monitoring alone could tell them exactly when you use each and every device in your house.
-- Andrew Appel on research that can identify the signatures of electronic and water-based (e.g. sink, toilet) devices

Did you notice that? A two-terabyte rainbow table. A few years ago, that kind of storage was largely theoretical. Now it's both cheap and portable.
-- Bruce Schneier on GSM decryption

Comments (none posted)

Breaking GSM With a $15 Phone … Plus Smarts (Wired)

Wired's Threat Level blog looks at a GSM cellphone eavesdropping demonstration made at the recent Chaos Computer Club Congress in Berlin. "As part of this background communication, GSM networks send out strings of identifying information, as well as essentially empty "Are you there?" messages. Empty space in these messages is filled with buffer bytes. Although a new GSM standard was put in place several years ago to turn these buffers into random bytes, they in fact remain largely identical today, under a much older standard. [...] This allows the researchers to predict with a high degree of probability the plain-text content of these encrypted system messages. This, combined with a two-terabyte table of precomputed encryption keys (a so-called rainbow table), allows a cracking program to discover the secret key to the session’s encryption in about 20 seconds."

Comments (none posted)

Bareil: Linux Security, one year later...

Nicolas Bareil looks at GNU/Linux security in 2010. "Bug #1: Disabling frontier: The kernel has to validate each user-provided pointer to check if it is coming from user or kernel space. This is done by access_ok() with a simple comparison of the address against a limit (XXX). Sometimes, the kernel needs to use function which are normally designed to be called by userspace, and as such, theses functions checks the provenance of the pointer... which is embarrassing because the kernel only provides kernel pointers. So the kernel goes evil and cheats by manipulating the boundary via set_fs() in order to make access_ok() always successful. At this moment and until the kernel undoes its boundary manipulation, there is no protection against NULL pointer dereference attack." (Thanks to Patrick Guignot)

Comments (none posted)

Spengler: False Boundaries and Arbitrary Code Execution

Brad Spengler has posted a review of Linux capabilities and how they can be leveraged for full root privileges on the grsecurity blog. In short, 20 of the 35 capabilities bits allow actions that can result in root privileges from an exploitable program. "As mentioned earlier, there are 35 capabilities currently implemented. I'll now discuss each capability that is effectively equal to root and a rough description of how each transition is made. I will try to make a distinction between cases that are generally applicable and those that are situational. Since we've already established that real uid 0 is equivalent to having full capabilities on any normal system, I'll assume we're a non-root user with only the mentioned capability raised." (Thanks to Dan Carpenter.)

Comments (44 posted)

New vulnerabilities

dbus: denial of service

Package(s):dbus CVE #(s):CVE-2010-4352
Created:December 27, 2010 Updated:January 5, 2011
Description: From the Red Hat bugzilla:

A stack overflow flaw was found in the way the D-BUS message bus service / messaging facility validated messages with excessive number of nested variants. A local, authenticated user could use this flaw to cause dbus daemon to crash (denial of service) via a specially-crafted message sent to the system bus.

Alerts:
Fedora FEDORA-2010-19166 2010-12-21

Comments (none posted)

drupal-views: cross-site scripting

Package(s):drupal-views CVE #(s):
Created:January 4, 2011 Updated:January 5, 2011
Description: From the Drupal advisory:

The Views module provides a flexible method for Drupal site designers to control how lists and tables of content are presented. Under certain circumstances, Views could display parts of the page path without escaping, resulting in a relected Cross Site Scripting (XSS) vulnerability. An attacker could exploit this to gain full administrative access.

Alerts:
Fedora FEDORA-2010-19009 2010-12-17
Fedora FEDORA-2010-18927 2010-12-17

Comments (none posted)

eclipse: cross-site scripting

Package(s):eclipse CVE #(s):
Created:December 27, 2010 Updated:January 5, 2011
Description: From the Red Hat bugzilla:

It was reported that the Eclipse Help Contents were vulnerable to Cross Site Scripting vulnerabilities in the /help/index.jsp and /help/advanced/content.jsp URLs that are served by the built-in Jetty Web Server plugin.

Alerts:
Fedora FEDORA-2010-19006 2010-12-17
Fedora FEDORA-2010-18990 2010-12-17

Comments (none posted)

evince: arbitrary code execution

Package(s):evince CVE #(s):CVE-2010-2640 CVE-2010-2641 CVE-2010-2642 CVE-2010-2643
Created:January 5, 2011 Updated:January 13, 2011
Description: From the Ubuntu advisory:

Jon Larimer discovered that Evince's font parsers incorrectly handled certain buffer lengths when rendering a DVI file. By tricking a user into opening or previewing a DVI file that uses a specially crafted font file, an attacker could crash evince or execute arbitrary code with the user's privileges.

Alerts:
Ubuntu USN-1035-1 2011-01-05
Red Hat RHSA-2011:0009-01 2011-01-06
Fedora FEDORA-2011-0208 2011-01-07
Fedora FEDORA-2011-0224 2011-01-07
Mandriva MDVSA-2011:005 2011-01-13

Comments (none posted)

gif2png: arbitrary code execution

Package(s):gif2png CVE #(s):CVE-2009-5018
Created:January 5, 2011 Updated:January 17, 2011
Description: From the Gentoo advisory:

gif2png contains a command line parsing vulnerability that may result in a stack overflow due to an unexpectedly long input filename.

A remote attacker could entice a user to open a specially crafted image, possibly resulting in the execution of arbitrary code with the privileges of the user running the application, or a Denial of Service. Note that applications relying on gif2png to process images can also trigger the vulnerability.

Alerts:
Gentoo 201101-01 2011-01-05
Mandriva MDVSA-2011:009 2011-01-14

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):kernel CVE #(s):CVE-2010-4347 CVE-2010-4258 CVE-2010-4165 CVE-2010-4175 CVE-2010-4163
Created:January 3, 2011 Updated:January 14, 2011
Description: From the openSUSE advisory:

CVE-2010-4347: A local user could inject ACPI code into the kernel via the world-writable "custom_debug" file, allowing local privilege escalation.

CVE-2010-4258: A local attacker could use a Oops (kernel crash) caused by other flaws to write a 0 byte to a attacker controlled address in the kernel. This could lead to privilege escalation together with other issues.

CVE-2010-4165: The do_tcp_setsockopt function in net/ipv4/tcp.c in the Linux kernel did not properly restrict TCP_MAXSEG (aka MSS) values, which allows local users to cause a denial of service (OOPS) via a setsockopt call that specifies a small value, leading to a divide-by-zero error or incorrect use of a signed integer.

CVE-2010-4175: A local attacker could cause memory overruns in the RDS protocol stack, potentially crashing the kernel. So far it is considered not to be exploitable.

CVE-2010-4163: By submitting certain I/O requests with 0 length, a local user could have caused a kernel panic.

Alerts:
openSUSE openSUSE-SU-2011:0004-1 2011-01-03
openSUSE openSUSE-SU-2011:0003-1 2011-01-03
Red Hat RHSA-2011:0007-01 2011-01-11
Red Hat RHSA-2011:0017-01 2011-01-13
SUSE SUSE-SA:2011:004 2011-01-14

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):kernel CVE #(s):CVE-2010-3699 CVE-2010-4161 CVE-2010-4242 CVE-2010-4247
Created:January 4, 2011 Updated:January 12, 2011
Description: From the Red Hat advisory:

* A flaw was found in the Xenbus code for the unified block-device I/O interface back end. A privileged guest user could use this flaw to cause a denial of service on the host system running the Xen hypervisor. (CVE-2010-3699)

* The fix for Red Hat Bugzilla bug 484590 as provided in RHSA-2009:1243 introduced a regression. A local, unprivileged user could use this flaw to cause a denial of service. (CVE-2010-4161)

* A NULL pointer dereference flaw was found in the Bluetooth HCI UART driver in the Linux kernel. A local, unprivileged user could use this flaw to cause a denial of service. (CVE-2010-4242)

* It was found that a malicious guest running on the Xen hypervisor could place invalid data in the memory that the guest shared with the blkback and blktap back-end drivers, resulting in a denial of service on the host system. (CVE-2010-4247)

Alerts:
Red Hat RHSA-2011:0004-01 2011-01-04
CentOS CESA-2011:0004 2011-01-06
Red Hat RHSA-2011:0007-01 2011-01-11

Comments (none posted)

libwmf: multiple vulnerabilities

Package(s):libwmf CVE #(s):CVE-2007-0455 CVE-2007-3472 CVE-2007-3473 CVE-2007-3474 CVE-2007-3475 CVE-2007-3476 CVE-2007-3477 CVE-2007-3478
Created:January 5, 2011 Updated:January 5, 2011
Description: From the Red Hat advisory:

libwmf embeds an old version of gd (2.0.1beta) which has a number of vulnerabilities associated with it.

CVE-2007-0455 CVE-2007-3472 CVE-2007-3473 CVE-2007-3474 CVE-2007-3475 CVE-2007-3476 CVE-2007-3477 CVE-2007-3478

Cursory inspection of one of the patch diffs shows that no patches have been applied to libwmf.

Alerts:
Fedora FEDORA-2010-19033 2010-12-17
Fedora FEDORA-2010-19022 2010-12-17

Comments (none posted)

libxml2: arbitrary code execution

Package(s):libxml2 CVE #(s):CVE-2010-4494
Created:December 27, 2010 Updated:January 5, 2011
Description: From the Debian advisory:

Yang Dingning discovered a double free in libxml's Xpath processing, which might allow the execution of arbitrary code.

Alerts:
Debian DSA-2137-1 2010-12-26
Mandriva MDVSA-2010:260 2010-12-29

Comments (none posted)

mantis: multiple vulnerabilities

Package(s):mantis CVE #(s):CVE-2010-3763 CVE-2010-4348 CVE-2010-4349 CVE-2010-4350
Created:January 3, 2011 Updated:January 5, 2011
Description: From the Red Hat bugzilla entry:

Cross-site scripting (XSS) vulnerability in core/summary_api.php in MantisBT before 1.2.3 allows remote attackers to inject arbitrary web script or HTML via the Summary field, a different vector than CVE-2010-3303. (CVE-2010-3763)

From the Red Hat bugzilla entry:

The MantisBT project was notified by Gjoko Krstic of Zero Science Lab (gjoko@zeroscience.mk) of multiple vulnerabilities affecting MantisBT <1.2.4.

The two following advisories have been released explaining the vulnerabilities in greater detail:

http://www.zeroscience.mk/en/vulnerabilities/ZSL-2010-4983.php

http://www.zeroscience.mk/en/vulnerabilities/ZSL-2010-4984.php (CVE-2010-4348, CVE-2010-4349, CVE-2010-4350)

Alerts:
Fedora FEDORA-2010-19078 2010-12-19
Fedora FEDORA-2010-19070 2010-12-19

Comments (none posted)

opensc: arbitrary code execution

Package(s):opensc CVE #(s):CVE-2010-4523
Created:January 4, 2011 Updated:January 17, 2011
Description: From the Red Hat bugzilla:

Three stack-based buffer overflow flaws were found in the way OpenSC device drivers for A-Trust ACOS, ACS ACOS5 and STARCOS SPK 2.3 based smart cards processed certain values of card serial number. A local attacker could use this flaw to execute arbitrary code, with the privileges of the user running the opesc-tool or opensc-explorer binaries via a malicious smart card, with specially-crafted value of its serial number, inserted to the system.

Alerts:
Fedora FEDORA-2010-19192 2010-12-22
Fedora FEDORA-2010-19193 2010-12-22
Mandriva MDVSA-2011:011 2011-01-15

Comments (none posted)

perl-IO-Socket-SSL: denial of service

Package(s):perl-IO-Socket-SSL CVE #(s):CVE-2010-4334
Created:December 27, 2010 Updated:January 5, 2011
Description: From the Red Hat bugzilla:

A Debian bug report indicated that using the IO::Socket::SSL perl module, if the verify_mode were set to 0x03 (verify peer, fail verification if no peer certificate exists), that the requests were removed unless either the ca_file or ca_path were supplied. This means that IO::Socket::SSL "fails open" if the user forgets to supply information about an acceptable set of trusted CAs, rather than "failing closed" (denying access by default, rather than allowing it).

Alerts:
Fedora FEDORA-2010-19058 2010-12-18
Fedora FEDORA-2010-19054 2010-12-18

Comments (none posted)

phpmyadmin: multiple vulnerabilities

Package(s):phpmyadmin CVE #(s):CVE-2010-4480 CVE-2010-4481
Created:December 31, 2010 Updated:January 5, 2011
Description: From the Debian advisory:

Cross site scripting was possible in errors, that allowed a remote attacker to inject arbitrary web script or HTML. (CVE-2010-4480)

Display of PHP's phpinfo() function was available to world, but only if this functionality had been enabled (defaults to off). This may leak some information about the host system. (CVE-2010-4481)

Alerts:
Debian DSA-2139-1 2010-12-31
Mandriva MDVSA-2011:000 2011-01-05

Comments (none posted)

wordpress: SQL injection

Package(s):wordpress CVE #(s):CVE-2010-4257
Created:December 29, 2010 Updated:January 10, 2011
Description:

From the Debian advisory:

Vladimir Kolesnikov discovered a SQL injection vulnerability in wordpress, a weblog manager. An authenticated users could execute arbitrary SQL commands via the Send Trackbacks field.

Alerts:
Debian DSA-2138-1 2010-12-29
Fedora FEDORA-2010-19296 2010-12-29
Fedora FEDORA-2010-19290 2010-12-29
Fedora FEDORA-2010-19329 2010-12-31
Fedora FEDORA-2010-19330 2010-12-31

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The 2.6.37 kernel is out, released by Linus Torvalds on January 4. New features in 2.6.37 include ext4 scalability improvements, jump labels, "tiny preempt RCU", more BKL removal work, getting rid of barriers in the block subsystem, much of the Xen Dom0 support, fanotify has been re-enabled, and more. As always, see the KernelNewbies 2.6.37 page for lots more information. "As to the big picture, on the whole I think 2.6.37 has been fairly calm. That will likely change with the merge window, as I'm looking forward to getting the new RCU-based pathname lookup and similar exciting features. So enjoy the calm sanity while it lasts." While the merge window is theoretically open, Torvalds said that he will wait a bit before starting the process to "let 2.6.37 cool for a few days to try to encourage people to look at the release rather than go all crazy with newly merged features in the next tree".

While we were on our holiday break, 2.6.37-rc8 was released on December 28. "The -rc8 release shouldn't be all that exciting. The most noticeable is probably the fact that hopefully the 'blank screen' problem with intel graphics is fixed. But on the whole, it's all just a collection of random fixes all over." See the full changelog for all the details.

There have been no stable releases made in the last two weeks. The 2.6.34.8 and 2.6.32.28 longterm kernels along with the 2.6.36.3 stable kernel are in the review process at the time of this writing.

Comments (1 posted)

Quotes of the fortnight

Basically, file systems are not databases, and databases are not file systems. There seems to be an unfortunate tendency for application programmers to want to use file systems as databases, and they suffer as a result.
-- Ted Ts'o

We simply do not add kernel facilities that can produce a stack overflow, memory corruption and triple fault if a rare debug statement triggers in an IRQ context by accident.
-- Ingo Molnar

There is absolutely _no_ excuse for an endless loop in kernel mode. Certainly not "the other end is incompetent".

EVERYBODY is incompetent sometimes. That just means that you must never trust the other end too much. You can't say "we require the server to be sane in order not to lock up".

-- Linus Torvalds

Comments (53 posted)

Paul McKenney's parallel programming book

Paul McKenney has announced the availability of his book on parallel programming. "My thought had been to complete it, then announce it. But I finally realized that it really never will be complete, at least not as long as people keep coming up with new parallel-programming ideas, which I most definitely hope will continue for a very long time." As a mere 358-page PDF, the book clearly has room for growth, but there's a lot of useful information there. A git repository is available for those who want to follow the progress of the book or help with its development.

Comments (29 posted)

Gettys: Bufferbloat in 802.11 and 3G Networks

Jim Gettys has another post on bufferbloat, this time looking at "big fat networks". "A simple concrete optimal example of such a busy network might be 25 802.11 nodes, each with a single packet buffer; no transmit ring, no device hardware buffer, trying to transmit to an access point. Some nodes are far away, and the AP adapts down to, say 2Mbps. This is common. You therefore have 25 * 1500 bytes of buffering; this is > .15 seconds excluding any overhead, if everything goes well; the buffers on the different machines have "aggregated" behavior. This is the optimal case for such a busy network. Even a 802.11g network with everyone running full speed will only be about 10 times better than this."

Comments (16 posted)

Announcing the beta release of PowerTOP 2.0

Arjan van de Ven has announced the beta release of PowerTOP 2.0. "The PowerTOP 2.0 release is effectively a complete rewrite of the PowerTOP code base. The old 1.x code base had grown rather out of hand, having gotten many new features after the very first PowerTOP release without the foresight of a design that accommodated all these features. This new 2.0 codebase extensively uses the kernel "perf" infrastructure to give much more accurate data for the various reports; make sure to enable this in your kernel configuration!"

Full Story (comments: 1)

Kernel development news

A Linux kernel compatibility layer for FreeBSD?

By Jake Edge
January 5, 2011

As part of his work in porting a Linux-based InfiniBand stack to FreeBSD, Jeff Roberson put together a compatibility layer that maps Linux-specific kernel functionality to FreeBSD equivalents. He announced this effort on the freebsd-arch mailing list in order to get a general sense of what other FreeBSD developers thought of the idea—and whether it might make sense to combine it with other, similar, compatibility shims. The thread gives an interesting look into the problems that less popular operating systems have when trying to support new functionality that is already well-established in Linux, even if all of that code is not in the mainline.

The InfiniBand stack that Roberson ported was developed by the OpenFabrics Alliance as part of its OpenFabrics Enterprise Distribution (OFED). It largely consists of patches on top of the existing Linux InfiniBand code. All of the code is available under both the GPL and BSD licenses, which is what allowed Roberson to port it to FreeBSD. In order to minimize changes to that stack, though, he created a fairly large compatibility layer:

The infiniband port has been done by creating a 10,000 line KPI [Kernel Programming Interface] compatability layer. With this layer the vast majority of the driver code runs unmodified. The exceptions are anything that interfaces with skbs and most of the code that deals with network interfaces.

Roberson goes on to list the kinds of things that the compatibility layer supports, including atomic operations, various device types, interrupts, kobjects, radix and rbtrees, lists, spinlocks, and so on. For the most part, it is just translating Linux-isms into their FreeBSD counterparts. The current state of the wrapper can be seen in Roberson's svn repository, which consists of a linux kernel include tree along with code to implement those Linux-isms. The OFED code can then be built by pointing it at the include tree.

Only those parts of Linux that were needed by the OFED code were actually implemented in the compatibility layer, but Roberson wonders if it makes sense to combine his effort with others:

I have seen that some attempt at similar wrappers has been made elsewhere. I wonder if instead of making each one tailored to individual components, which mostly seem to be filesystems so far, should we put this in a central place under compat somewhere?

While there was some predictable Linux-bashing in the thread, most participants seemed favorably inclined toward the compatibility layer itself, as well as making it more widely available to other parts of the FreeBSD kernel tree. There are some difficulties, of course, including exactly which Linux kernel version should be tracked. As was pointed out, somewhat caustically, by Garrett Wollman in the thread, internal Linux interfaces change with some frequency, and without much warning:

Fundamentally, maintaining any sort of Linux compatibility is a losing battle, since the hordes will keep on rototilling interfaces in every release until the cows come home, with no concern (and in many cases utter contempt) for anyone else who might need to maintain kernel code. It's a testament to their size and ability that they have managed to keep the system relatively usable and stable over the long term when major parts of the system get replaced on such a regular basis.

It's not just the size and ability of the Linux community that has led to a stable and usable system, though. As Matthew Jacob notes, Linux developers point to the ability to change the internal interfaces as one of the strengths of their development model. Although the FreeBSD developers may not agree with it, the stable_api_nonsense document does provide reasons for the Linux developers' disdain for stable internal APIs.

Still, choosing a kernel version to track is not necessarily easy. Based on some previous work maintaining an out-of-tree Linux filesystem, Chris BeHanna was able to offer some advice on that:

I would say that you want to pick a major release of one or at most two major commercial distros (I'll pick on Red Hat Enterprise Linux and the enterprise SuSE for illustration), and track the major releases of them that correspond to roughly the same Linux kernel version, and then STICK to that for the life of a given FreeBSD release stream. Commercial vendors backport fixes into their otherwise-fairly-stable major releases, which minimizes your pain. There are still some changes here and there along the way, and you have to decide how many kernel config options you are willing to support (I'd suggest the default SMP, maybe the default PAE, and punt everything else or you'll go mad).

The combinatorial pain of committing to more than that leads to a desire for seppuku: I had to support multiple kernel versions each (and often multiple configurations per kernel) for Red Hat 7, 8, 9; RHEL 4 and 5, SuSE Enterprise 9, 10, 10.1, and 10.2, SuSE Desktop 9 and 10, and Fedora 4, 5, and 6 across x86, x86-64, and IA-64, and it ended up being more than 400 binaries to be generated, tested, and delivered every time we issued a patch release.

There are some obvious advantages to using the OFED code with minimal modifications. Bug fixes and enhancements are being made regularly that could be incorporated into the FreeBSD kernel fairly easily using the compatibility layer. But some argue that adding such a layer will result in fewer vendors trying to get their code working natively for FreeBSD, likening it to the linuxulator that allows Linux binaries to run on FreeBSD. Alexander Kabaev put it this way:

[...] [A] Linux compat layer in kernel will have the same effect as linuxulator in userland - we do have some vendors still trying to bother with FreeBSD drivers for their hardware now and we will have none after we provide the possibility to hack their Linux code to run somewhat stably on top of Linux compat layer.

But Roberson is not convinced that the linuxulator has had a negative effect on FreeBSD market share, and instead sees it as allowing FreeBSD to "stay relevant in areas where companies can not justify an independent FreeBSD effort. Adobe is a good example of this."

Roberson seems to be taking a pragmatic approach to getting InfiniBand support into current versions of FreeBSD. Evidently there is an InfiniBand stack that runs on earlier versions of FreeBSD, but it hasn't been maintained for more recent kernels. There aren't any real alternatives, as he sees it:

Our options are, to leave FreeBSD users without infiniband, which I can tell you has cost us more market share as I know of specific cases we have lost due to it. To maintain our own stack independently, which no one has the budget for. Or to try to integrate with OFED. Do you see some other approach?

So far, there has been no answer to his question. It may be that the compatibility layer continues to live in the InfiniBand tree, rather than move to a more widely accessible place, but there seems to be no one stepping up to develop and maintain a FreeBSD-specific stack. While there is some resistance to the 10,000-line size of the layer, it is, for the most part, a pretty thin shim, as Roberson describes:

Let's talk nuts and bolts about what this thing does. In the vast majority of cases it simply shuffles arguments and function names around where there is a 1:1 correlation between linux api and FreeBSD API. Think about things like atomics, callouts, locks, jiffies vs ticks, etc. In these areas the systems are trivially different. In a very small number of areas where this wasn't the case I did a direct port and noted it with an #ifdef.

It wasn't brought up in the thread, but there may also be questions about the license of the compatibility layer (seemingly BSD-only) at some point. Lawyers might argue that it is a derivative work of the Linux kernel. It's unlikely to be a real problem unless someone takes the code into a closed-source product, which is something that the BSD license allows. Specifically licensing it under the GPL would avoid that particular problem, though that might not fit well with the goals of the FreeBSD project.

It is undoubtedly galling to some in the FreeBSD community to adopt a big chunk of Linux code along with a Linux mapping layer, but the reality is that the community isn't large enough to go it alone, at least for InfiniBand. In some ways it is reminiscent of the problems that came about when the new direct rendering manager (DRM) development process was announced. In both cases, the community of FreeBSD users and developers is just not large enough to justify some kind of dual-OS approach.

On the other hand, though, in both cases the licenses specifically allow Linux and FreeBSD (and others) to incorporate the code. While there are lots of technical and development process barriers to more collaboration between Linux and the BSD world, the usually painful license incompatibility issue did not rear its head. With luck, that will play out well for both sides, with dual-licensed patches going in both directions, hopefully without the rancor that sometimes occurs.

[Thanks to James Andrewartha for giving us a heads-up about this topic.]

Comments (6 posted)

The trouble with firmware

By Jake Edge
January 5, 2011

Within the various communities that make up the free software world, there are many different opinions on exactly what constitutes "freedom". Those opinions run the gamut from extremely pragmatic to exceedingly strict definitions of "free". Firmware blobs for drivers—almost always released without source code and often without any clear license—have been particularly troublesome for certain projects. Debian has struggled with the problem over the years, finally resolving it by moving the non-free firmware out of its main repository for the upcoming 6.0 ("Squeeze") release. But there are others who find even that insufficient and would like to see any mention of the non-free firmware files removed from the kernel.

The Linux-libre project aims to deliver a completely free (under its definition) Linux distribution. It does that by removing any programs that either don't come with source code, or that has source code that is licensed in a way that does not allow users to modify it. Many Linux distributions already follow those guidelines, but Linux-libre takes things one step further and removes anything that "induces or requires you to install additional pieces of non-Free Software".

As might be guessed, Linux-libre has a rather liberal interpretation of what "induces" means, which is where the kernel firmware loading mechanism runs afoul of the distribution's goals. Linux-libre has already eliminated the non-free firmware from its repositories, but there is still a problem: the kernel will make a request to user space for (potentially) non-free firmware when it loads a driver that requires it. So in the minds of the Linux-libre developers, the kernel is now inducing users to install non-free software.

If user space cannot find the firmware file, then the driver obviously cannot load it into the hardware. That makes the hardware non-functional, presumably, but far worse from an inducement perspective, the kernel puts a message into the log specifically noting the filename that couldn't be found. Evidently, that will induce users to go find a file by that name and install it, thus resulting in a non-free system.

In a discussion about Debian's Squeeze kernel on the linux-libre mailing list, Richard Stallman mentioned a plan to obfuscate the names of the firmware files within the Linux-libre kernel. Part of his message was picked up as a Kernel page "quote of the week", partly because it seems like something of a contradiction to promote freedom by hiding the proper names of firmware files. It's also a little puzzling because the GPL and the software freedom movement is so clearly focused on the rights of users.

But Stallman isn't trying to stop users from finding the firmware, he just wants to ensure that the distribution doesn't induce them to install it. That distinction may seem rather arbitrary to many, but not to him. In response to a concern expressed by Alexandre Oliva about web pages that would show the mapping between the Linux-libre obfuscated names and those of the actual filenames, Stallman explained:

Remember, the goal is not to prevent people from finding these files. [...] Our goal is to avoid steering users towards nonfree software. If they find these identifiers and look them up, I think it will be clear to them that we are not.

The plan seems to go far beyond just creating a kernel with obfuscated firmware names, though. It would be fairly straightforward to run a script on the kernel source that applied some kind of obfuscation filter to the firmware filenames before building the kernel, but that doesn't completely alleviate the problem for Linux-libre. It would also like to have a kernel Git repository with the mangled filenames, but there are problems with that approach as Oliva notes:

I'd love to have this in a git repository rather than as deblobbing scripts, but a solution for the problem of creating a git repository that can track Linux upstream without carrying the non-Free bits that the Linux git repository carries has so far eluded me.

From there, the conversation starts to take on some Orwellian tones. It is not enough to just have the new firmware filenames in the HEAD of the Git repository, Oliva and Stallman would like to eliminate references to the original filenames (and the firmware files themselves) from the repository history. But they also would like to be able to pull from Linus Torvalds's mainline tree periodically. It is a tricky set of conditions to try to fulfill.

As part of the discussion on how to handle it, Stallman seems to bristle over the term "rewriting history"—perhaps because of its Orwellian overtones. He sees that term as (somehow) pushing Torvalds's views:

In effect, it claims that "If Torvalds let someone put nonfree software into a present or even past version of Linux, everyone who wants to refer to a repository of Linux is obligated to refer to that nonfree code." That is his views. We believe it is wrong to tell anyone about this nonfree software, and we will not follow his views.

Stallman doesn't necessarily see being able to pull from the mainline as much more than a convenience. But Oliva, who clearly has more Git and kernel workflow experience than Stallman, is fairly adamant:

However, it is an absolute must for any of us to be able to trivially pull changes from upstream. Actually, make that upstreams, for any branch that tracks Linus' tree and has additional patches might be desirable for any of us to merge into our personal or published repositories. If the Linux-libre repository doesn't fit into people's regular workflow, there will be a strong incentive against using it, against developing improvements for Linux on it. It would be self-defeating. I don't want this kind of pain, not for myself, not for other contributors.

To that end, Oliva asked for ways to accomplish this goal on the Git mailing list. He comes up with some plausible scenarios where others might want this kind of functionality, beyond just the needs of Linux-libre:

Say, portions that are illegal, immoral or too risky in my jurisdiction: patented stuff that lawyers say I should not distribute in any way, unauthorized or otherwise copyright-infringing bits, text or pictures that are offensive or even illegal to publish, i.e., stuff that I must not be caught distributing and that, ideally, I could arrange to not even possess.

A few suggestions of possible workflows were made in that thread, but Oliva seems to be leaning toward using git-filter-branch and either some scripts or changes to Git to facilitate this effort. While his scenarios are a little bit of a stretch—why distribute a project that contains these problematic pieces?—they aren't completely beyond the pale. Others could benefit from whatever solution Linux-libre finally settles on.

It's certainly not the first time that Stallman has seemed to be tilting at windmills, and plenty of folks will find this effort to be pointless, even comical. There are some good arguments on both sides of the firmware debate, but it is a bit hard to see how making it more difficult to get hardware working on Linux-libre is going to lead to more adoption of that distribution. Far more likely, it would seem, is that folks just grab a different distribution (or operating system entirely) and move on.

Comments (24 posted)

Who wrote 2.6.37

By Jonathan Corbet
December 30, 2010
The 2.6.37 development cycle is coming to a close; that must mean that it is time to look at the development statistics for this release. 2.6.37 has been a more active cycle than most, with 11,220 non-merge changesets added (as of 2.6.37-rc7). Only three cycles have seen more changes: 2.6.25 (12,243 changesets), 2.6.29 (11,678), and 2.6.30 (11,989). The relatively slow period since 2.6.33 appears to have come to an end.

The 2.6.36 kernel was unique in that it was actually smaller than its predecessor. 2.6.37 does not continue that trend; some 1,140,000 lines of code were added, and 641,000 lines were removed, for a net growth of 494,000 lines. Most notably, perhaps: the 2.6.37 kernel includes patches from 1,250 developers, the highest ever. The development community, clearly, is active and growing.

The most active contributors this time around were:

Most active 2.6.37 developers
By changesets
Chris Wilson2111.9%
Greg Kroah-Hartman1711.5%
Eric Dumazet1661.5%
Johannes Berg1491.3%
Thomas Gleixner1471.3%
Paul Mundt1401.2%
Mauro Carvalho Chehab1221.1%
Joe Perches1071.0%
Avi Kivity1050.9%
Mark Brown1000.9%
Hans Verkuil1000.9%
Namhyung Kim1000.9%
Dan Carpenter990.9%
Christoph Hellwig930.8%
Jean Delvare880.8%
Axel Lin880.8%
Daniel Vetter870.8%
Vasiliy Kulikov860.8%
Arnd Bergmann860.8%
Julia Lawall840.7%
By changed lines
Henry Ptasinski1433039.6%
Greg Kroah-Hartman1008616.7%
Vipin Mehta923986.2%
Luis R. Rodriguez716364.8%
Mark Brown536903.6%
David Cross481983.2%
Dmitry Kravkov471983.1%
Larry Finger403782.7%
Krishna Gudipati387122.6%
Stefan Richter294342.0%
Stephen Hemminger285041.9%
Rasesh Mody223351.5%
Prashant P. Shah150861.0%
Michael Chan141180.9%
Christian Lamparter135300.9%
Liam Girdwood133240.9%
William Hubbs129710.9%
Vinod Koul129440.9%
Marek Belisko115310.8%
Al Cho100970.7%

These lists feature a combination of old and new names. Chris Wilson got to the top of the by-changesets list by virtue of his work with the Intel graphics drivers. Greg Kroah-Hartman worked on the USB and TTY subsystems, but the bulk of his changes were made to the staging tree, and the new brcm80211 driver in particular. Eric Dumazet has been active all over the networking layer, Johannes Berg has been busy with wireless networking, and Thomas Gleixner rewrote the generic interrupt handling code (among many other things).

Looking at lines changed: Henry Ptasinski arrived at the top of the list through the addition of the brcm80211 driver which, as can be seen, is not a small piece of code. Vipin Mehta added the ath6kl driver to the staging tree, Luis Rodriguez worked on the mac80211 layer and the ath9k driver, and Mark Brown, as always, did a massive amount of work within the ALSA sound layer. It's interesting to note that five of the top ten in this column were mainly involved with the staging tree. One of the others (Krishna Gudipati) submitted a single "driver cleanup patch" which drew Linus's ire at the time - calling a nearly 40,000-line patch a "cleanup" seemed like a bit much.

A minimum of 193 employers supported work on the 2.6.37 kernel; the top supporters were:

Most active 2.6.37 employers
By changesets
(None)186416.6%
Red Hat126511.3%
(Unknown)9468.4%
Intel7466.6%
Novell6445.7%
IBM4474.0%
Oracle2722.4%
Texas Instruments2502.2%
Nokia2352.1%
Renesas Technology2101.9%
Samsung2051.8%
Broadcom1721.5%
Societe Française de Radiotelephone1661.5%
AMD1631.5%
(Consultant)1551.4%
Pengutronix1541.4%
(Academia)1461.3%
Wolfson Micro1291.1%
Google1281.1%
Fujitsu1271.1%
By lines changed
Broadcom24674916.4%
(None)18883012.6%
Atheros16569311.0%
Novell1274768.5%
Wolfson Micro1001966.7%
Brocade640124.3%
(Unknown)593254.0%
Red Hat590003.9%
Intel538933.6%
Cypress Semiconductor482413.2%
Vyatta307202.0%
Texas Instruments228741.5%
Samsung167711.1%
IBM165671.1%
Nokia147311.0%
Renesas Technology144881.0%
(Consultant)135920.9%
Slimlogic Ltd133240.9%
ST Ericsson130560.9%
Chelsio107700.7%

Looking at the by-changesets column, the situation looks mostly like business as usual. Red Hat remains, by far, the largest corporate contributor to the kernel. On the lines-changed side, instead, Red Hat had to settle for eighth place behind companies which, for the most part, have contributed a lot of driver code.

It has been some time since we looked at the reviewing and testing of code. In the 2.6.37 development cycle, the developers with the most Reviewed-by tags were:

Most active 2.6.37 reviewers
Ingo Molnar8612.6%
Christoph Hellwig375.4%
Mike Christie294.3%
Michael Chan263.8%
Josh Triplett223.2%
Daniel Vetter213.1%
Chuck Lever213.1%
H. Peter Anvin202.9%
Konrad Rzeszutek Wilk192.8%
Alex Elder172.5%
Luciano Coelho162.3%
Suresh Jayaraman162.3%
Swen Schillig162.3%
Michal Marek152.2%
Jeff Layton152.2%
Sam Ravnborg152.2%
Wu Fengguang121.8%
Francisco Jerez121.8%
KOSAKI Motohiro121.8%
Christoph Lameter111.6%

As always, there is only so much that can be learned from these numbers; the bulk of all patch reviews do not lead to the addition of a Reviewed-by tag. On the other hand, there has been some real social pressure to credit users who test patches and report bugs:

Most credited 2.6.37 reporters and testers
Reported-by credits
Stephen Rothwell244.2%
Randy Dunlap213.7%
Linus Torvalds193.3%
Ingo Molnar152.6%
Guennadi Liakhovetski101.8%
Jonathan Cameron71.2%
David Brownell71.2%
Sitsofe Wheeler61.1%
Andrew Morton61.1%
Dan Rosenberg61.1%
Jiri Slaby50.9%
Ben Greear50.9%
Eric Dumazet40.7%
Daniel Vetter40.7%
David S. Miller40.7%
Robin Holt40.7%
Andi Kleen40.7%
Dan Carpenter40.7%
Sachin Sant40.7%
Dr. David Alan Gilbert40.7%
Tested-by: credits
Wolfram Sang154.1%
Luciano Coelho113.0%
Kevin Hilman102.7%
Jeff Pieper102.7%
Will Deacon92.5%
Caglar Akyuz82.2%
Michael Williamson82.2%
Emil Tantilov71.9%
Randy Dunlap61.6%
Stephen Ko61.6%
Ben Greear61.6%
Eric Benard51.4%
Tuomas Katila51.4%
Maxim Levitsky51.4%
Ingo Molnar41.1%
Juuso Oikarinen30.8%
Jason Wessel30.8%
Kuninori Morimoto30.8%
Rabin Vincent30.8%
Ben Gardiner30.8%

All told, there were 568 Reported-by and 366 Tested-by tag lines found in patches merged for 2.6.37. We are, it seems, slowly getting better at recognizing the people who are doing this crucially important work.

In summary, the kernel development process continues to look healthy. We have a great deal of activity from an increasing number of developers, while, it seems, keeping a reasonable lid on the number of regressions introduced. Whether the high patch rate will continue into 2.6.38 remains to be seen; as of this writing, there are just under 5,000 changes in linux-next. Unless the subsystem maintainers put more work into linux-next in the near future, the next development cycle could be relatively slow.

Comments (8 posted)

Patches and updates

Kernel trees

Core kernel code

Development tools

Device drivers

Filesystems and block I/O

Kernel building

Memory management

Networking

Architecture-specific

Virtualization and containers

Page editor: Jonathan Corbet

Distributions

Openwall Linux 3.0: Linux for the security-conscious

January 4, 2011

This article was contributed by Koen Vervloesem

Openwall GNU/*/Linux (or, in short, Owl) is a security-enhanced Linux distribution, intended as a server platform. Almost five years after the (then Linux 2.4-based) 2.0 release and more than 10 years after the start of the project, the developers have now released a major update in version 3.0. It is based on a RHEL 5.5-like Linux 2.6 kernel along with optional OpenVZ container-based virtualization.

The first question most people will have is: what is so "security-enhanced" about Owl? Aren't major Linux distributions such as Red Hat Enterprise Linux, Ubuntu, openSUSE, and so on secure? Of course, they continuously patch known security vulnerabilities and some of them (Red Hat in particular) implement security features to decrease the impact of vulnerabilities, but none of them really are focused on preventing vulnerable software from getting into the distribution in the first place.

For the Owl developers, software design and code quality are the first priorities. Before they include a package in their distribution, they check whether it typically runs with elevated privileges (such as SUID/SGID programs) or whether it uses data obtained over the network as its input (such as network services). Both cases are possible attack vectors, so the Owl developers audit the source code and implement safer default configurations. They also modify the software to introduce privilege separation and to apply the least privilege principle. The developers describe their philosophy in the CONCEPTS page on the project's web site.

Since Owl 2.0 (which got security fixes and a couple of bug fixes over four years), there have been a lot of changes in the distribution. The 2.4 kernel has been swapped for OpenVZ's latest from their "RHEL5 testing" branch (currently 2.6.18-194.26.1.el5.028stab079.1), with some additional security-related patches. There is now also Ext4 filesystem support and the installer offers Ext4 by default. Xz compression support has also been added throughout the whole system: not only with commands like xz, xzcat, xzdiff, xzgrep, xzless, and so on, but also with xz support in tar, rpm, less and other tools.

Installation

Compressed ISO images for x86 and x86_64 can be downloaded from the project's home page or one of the mirrors. Alternatively, users who want to donate money to Openwall can purchase a CD. Both the ISO images and the CD contain a live system and an installer program, as well as the full source code and a build environment. There are also OpenVZ templates that can be used to run in OpenVZ containers (operating system-level virtualization). This could be useful to isolate various virtual servers, each in their own Owl OpenVZ container, on top of another Linux distribution or Owl itself, which has the necessary kernel and tools to run OpenVZ containers.

If you choose "normal" in the boot menu, the Owl CD boots into single user mode. Once you see the shell prompt, you can choose to configure the system (such as localization, timezone, network, ...) with setup and exit the shell to let the system boot into the multi-user live mode, or you can start the installer with settle. The installer has an ncurses-based bare-bones interface and doesn't hold the user's hand, but it does the job. [Owl password screen] The focus on security is particularly clear in the window where the user has to choose a root password: the text describes a handful of requirements for a secure password and shows a possible secure but easy to remember password like "While3frail8buggy". If the user fails to enter a secure password, the installer refuses the password and asks for a new one. Also, Owl 3.0 is one of the few Linux distributions that still uses LILO instead of the more complex (and hence, potentially less secure) GRUB.

No SUID programs

The announcement of Owl 3.0 specifically mentions the effort the developers have done to eliminate SUID programs:

A curious detail is that there are no SUID programs in a default install of Owl 3.0. Instead, there are some SGIDs, where their group level access, if compromised via a vulnerability, can't be expanded into root access without finding and exploiting another vulnerability in another part of the system - e.g., a vulnerability in crontab(1) or at(1) can't result in a root compromise without a vulnerability in crond(8) or in a critical system component relied upon by crond(8).

This assertion can be easily verified by a find / -perm -4000 command, which doesn't return any file with the SUID bit set in a fresh Owl install. To make this possible, the Owl developers rewrote the ping command, for example, to run as an unprivileged user. Another interesting rewrite is the passwd command. Traditionally, password hashes and password policy information of all users are stored in a single file, /etc/shadow. This forces passwd to be SUID root, which means that when a user runs the program, it has the privilege to alter all entries in the shadow file, not only the one of this user. As a result, if passwd is compromised because of an exploit, the attacker is able to change all passwords.

The Owl developers have invented an alternative mechanism for password management, which they call tcb. Each user is assigned a separate shadow file, owned by this user, e.g. /etc/tcb/root/shadow owned by the "root" user and the "auth" group, and /etc/tcb/joe/shadow owned by the user "joe" and the "auth" group. This "auth" group may be used to grant a process read access to all password hashes, but the passwd and chage commands are made SGID shadow, so both commands have only access to the user's own password hash and password policy. This move to tcb is transparent for existing applications, because they don't read the shadow file directly but rely on interfaces like PAM (in Owl handled by the PAM module pam_tcb) and NSS (handled by libnss_tcb).

It's interesting to see that other Linux distributions are also trying to remove SUID applications. For example, Red Hat's Dan Walsh wants to replace SUID in most applications by using file capabilities in Fedora 15. On the Ubuntu side, Canonical's Kees Cook is also working on using file capabilities. The Owl developers, though, have another approach, and the lead developer Alexander Peslyak describes some issues with the file capabilities approach. Also of note is what LWN.net guest author Neil Brown had to say about SUID in his article "Ghosts of Unix past, part 4: High-maintenance designs".

Security tools

Owl provides the control command to enable, disable, or configure some security-related facilities. Using the command without options lists all available facilities, their current setting, and any available settings. You can also get the current setting of a specific facility: for example, if you want to know if passwd is using the tcb or the traditional mechanism, just run control passwd. And if you want to see all available choices for the passwd setting, just run control passwd list. You can also change a setting, e.g. control passwd traditional to change the tcb default of passwd to the traditional shadow-based approach. The use of su is by default restricted to root because it has no SUID bit, but if the root user runs control su public, /bin/su gets the SUID bit so every user can run su to assume another user's identity. Under the hood, the control command uses shell scripts in /etc/control.d/facilities/ for the various services.

The Owl developers also ported several programs from OpenBSD, which is also a security-focused operating system: mtree, Vixie cron, telnet (with modifications to introduce privilege separation), netcat, and mailx. In general, software that is imported in Owl gets an average of four patch files to improve security: half of the patches from the Owl developers, the other half imported from various distributions or the BSDs.

The Owl developers have also created some useful security programs that can be used on other distributions. The famous password cracker John the Ripper, for example, is made by them, as is the password strength checker passwdqc, the port scan detection tool scanlogd, and the secure POP3 daemon popa3d.

By default, the system has a fair amount of tools installed, like vim, mutt, netcat, screen, nmap, openntpd, the OpenSSH server and client, postfix, procmail, vsftpd, lftp, and, of course, the already mentioned tools developed by the Openwall team. Owl uses the rpm package manager, but it has no repositories; instead, the user can rebuild the entire system from source with a make buildworld command and install the packages with make installworld. This is also the way to update an Owl system. If you want additional packages, the developers promise that in most cases it is possible to install packages for Red Hat Enterprise Linux, CentOS, or Fedora on Owl.

The Openwall developers have a community wiki with a lot of information about the Owl distribution and their other projects. In addition, the owl-users mailing list is the perfect place for questions about the use of Owl. The development team is rather small but dedicated, and they welcome patches, for which they publish a howto. All in all, Owl is really suited for the security-conscious Linux server administrator, but it also shows that there are alternatives to the security approaches taken by the mainstream Linux distributions.

Comments (10 posted)

Brief items

Mandriva 2010.2 released

The Mandriva 2010.2 release is out. "As announced previously, Mandriva 2010.2 is an incremental update on top of Mandriva 2010.1, incorporating all the security and bugfix updates since its release." The release is available on the Mandriva download site.

Full Story (comments: none)

Distribution News

Debian GNU/Linux

bits from the DPL: news, sprints, comm. & collaboration

These bits from Debian Project Leader Stefano Zacchiroli include a plug for RC bug squashing, sprints, communication, collaboration with others, and several other topics.

Full Story (comments: none)

Fedora

Unofficial Fedora FAQ Updated for Fedora 14!

The Unofficial Fedora FAQ has been updated for Fedora 14. "As usual, the FAQ contains useful information on playing MP3s, watching DVDs, installing proprietary 3d drivers, and handling common problems. There is a lot of other useful information in the FAQ, too, and it's all in an easy-to-read step-by-step instruction format that almost anybody should be able to follow."

Full Story (comments: none)

Fedora Board Recap 2011-01-03

Click below for the minutes of the January 3 meeting of the Fedora board. Topics include some catch up after the holidays and festivities, board goals for 2011, and several other items.

Full Story (comments: none)

Working together on Fedora Remixes

Rahul Sundaram has announced a new mailing list for the discussion of Fedora Remixes. "If you are looking for help on creating a new Fedora Remix or hoping to work together with maintainers of other Fedora Remixes, there is a new mailing list for you!"

Full Story (comments: none)

FUDCon Tempe: Gaming!

Tom "Spot" Callaway is organizing two nights of gaming at FUDCon Tempe (Jan 29-31, 2011). "This is an opportunity for FUDCon attendees to meet your fellow Fedorans and enjoy some of the geekiest board games we can find (or at least, what spot brings along from his collection)."

Full Story (comments: none)

SUSE Linux and openSUSE

openSUSE finished 2010 big

openSUSE News has a post on openSUSE's newest projects. "Since the openSUSE Conference in Nuremberg in October, the openSUSE community has been extremely active. New projects announced there have had progress, others have emerged. One example of the latter would be Project Tumbleweed, aiming to create a rolling-release repository for openSUSE. Going in the opposite direction is Project Evergreen — the Evergreen developers want to provide longer-term support for older openSUSE releases for a core set of packages. And there is the new Virtualization:Cloud project, where a team got together to create a cloud software repository. Finally, we can't forget to mention the new GNOME:Atayana project, bringing Unity to openSUSE! And those are new just since our last conference!"

Comments (none posted)

Newsletters and articles of interest

Distribution newsletters

Comments (none posted)

Red Hat Enterprise Linux 6 review (V3.co.uk)

V3.co.uk has a review of RHEL 6. "One of the most welcome changes is enhanced support for the latest multi-core processors, Red Hat claiming the ability to handle up to 4,096 cores/threads per system image in RHEL 6 - up from 64 in the previous release. Likewise, the addressable memory limit gets a boost, from 1TB to 64TB should you find a server able to support it. There's technology also to identify and quarantine defective memory areas and allow processors and RAM to be added on the fly, albeit only on hardware that allows this kind of component hot-swapping which, again, is rare."

Comments (none posted)

Page editor: Rebecca Sobol

Development

A look at VirtualBox 4.0

January 5, 2011

This article was contributed by Joe 'Zonker' Brockmeier.

Just before the holidays, Oracle pushed out the first major update to VirtualBox since it acquired Sun in January of 2010. The company has provided a steady stream of maintenance releases to the 3.2.x series, but 4.0 brings changes in the VirtualBox interface, new virtual hardware, better support for Open Virtualization Format (OVF), and a change in the way that VirtualBox's proprietary bits are distributed.

VirtualBox is described as "a general purpose full virtualizer for x86 hardware," for server, desktop, and embedded use. VirtualBox includes a GUI application for creating and managing guest machines much like VMware or Parallels, and also includes a headless mode for those who wish to use VirtualBox to manage headless guests.

New in 4.0

[VirtualBox manager]

To test VirtualBox, I installed a couple of 32-bit and 64-bit Linux distributions. In theory, VirtualBox will also allow users to run Mac OS X Server guests, though I didn't have a Mac OS X disc handy to test. The full range of OSes that VirtualBox specifically supports as guests includes Windows 3.1 through Windows 7, Solaris, FreeBSD, NetBSD, OpenBSD, a wide range of Linux distributions in 32 and 64-bit flavors, and even OS/2. Of course, you can try your luck with other OSes, but they're not specifically targeted. VirtualBox itself is also available for Windows, Mac OS X, and Solaris for those who need to run Linux under another host OS.

Current users of VirtualBox will note that there is no longer an Open Source Edition (OSE) and a proprietary ("personal use and evaluation") release. This is because VirtualBox 4.0 has been restructured to distribute proprietary bits as extension packs. The proprietary extensions are now modular, which means they can be distributed separately. It also means that VirtualBox picks up an extension architecture that third party developers can target to add new features or tools for working with VirtualBox.

Oracle has done a fine job of providing support for the most current major Linux distributions — and then some. You'll find native packages for the last five Ubuntu releases, the last three Red Hat Enterprise Linux (RHEL)/CentOS/Oracle Linux releases, Debian Lenny and Squeeze, SUSE Linux Enterprise Linux 10 and 11, openSUSE 11.1 through 11.3, Fedora 13 and 14, and even Turbolinux 11. All in 32-bit and 64-bit packages. If your distribution of choice isn't provided, Oracle provides an installer, and of course source code is available as well.

[VirtualBox settings]

By default, VirtualBox leaves out support for USB 2.0, RDP (remote desktop protocol) support, and PXE boot support for the virtual Intel NICs. The "extension pack" is distributed under a Personal Use and Evaluation License (PUEL), which is free as in beer. Installing it is simple enough. It's distributed as a single file for all architectures. Note that the GUI for VirtualBox doesn't indicate whether this extension is installed or not, and the options for the features are all visible — it's easy to imagine that some users will be confused by the fact that it seems possible to enable, say, USB 2.0 support, but not actually have it work without the extension.

As mentioned, VirtualBox includes an interface update and this one is (at least in this reporter's opinion) a bit of an improvement. It's still fairly complex, and VirtualBox throws a lot of options at the user that many users won't be prepared to answer. For instance, would you like Nested Paging with your System Acceleration? There's nothing wrong with presenting the options, but VirtualBox doesn't provide any contextual help to assist the user to making the decision. VirtualBox does come with a fairly comprehensive help guide, however, which helps provide guidance if you're willing to dig a bit.

[VirtualBox create VM]

Some of the error messages are a bit much — especially the first time a VM is launched. When configuring a Linux Mint Debian Edition guest, I received something like 5 error messages in quick succession ranging from complaints about the I/O settings and Ext4 compatibility to a mismatch in the guest drivers for VirtualBox and the 3D settings. I was able to work around them or turn off the "errors" that were simply notifications, but VirtualBox does throw a lot of messages around initially.

OVF is meant to provide an interchangeable format for virtual machines so that packaging virtual appliances is simpler for vendors. In practice, it's probably easier to provide native guest packages for each virtualization solution. I tried to test OVF import, but VirtualBox choked on a Fedora guest that I'd converted using VMware's ovftool. Whether this was a flaw on the part of VirtualBox, VMware's conversion tool, or some of both is unclear.

This release includes quite a few small changes that are likely to mitigate headaches for users. For example, 32-bit hosts now may have more than 2GB of RAM. New virtual hardware includes an Intel HD Audio interface for newer guest OSes, a new motherboard (Intel ICH9) with virtual PCI Express, and a number of other hardware improvements. Linux and Solaris guests should now be able to support multiple screen configurations if they're using X.org 1.3 or later, though I haven't had a chance to test this.

VirtualBox's performance is adequate if not particularly impressive. I mostly tested desktop guests with between 1GB and 4GB of RAM, and one or two virtual CPUs, and then went about my normal routine — browsing the Web, installing packages, chatting on IM, using Vim and xterms, and generally light desktop usage. Nothing too grueling. The test machine was a Dell Core i7 laptop with 8GB of RAM. In some cases a single guest with 4GB of RAM allocated was actually fairly sluggish. Having run similar guests in VMware Workstation on the same machine, the disparity was somewhat surprising.

VirtualBox and the community

Compared to VMware or Parallels, VirtualBox is a bit rough around the edges. The UI is much more complex, and it can be tricky find out how to do simple things — like provide a ISO image to create a new guest OS. It doesn't provide "wizards" for installing common guests like Windows 7 or Ubuntu, which VMware and Parallels do. It does, however, have the advantage of being (mostly) free software, so it is open to community improvements — if the community is willing to work on Oracle's terms, of course.

According to the VirtualBox site, contributors are required to submit patches to Oracle employees (the site says Sun employees, but they're all Oracle employees now) and sign the contributor agreement to assign joint copyright ownership. Again, this hasn't been updated since Oracle took over, so it's still the old Sun Microsystems agreement which gives the company the right to relicense anything it likes, though it does guarantee that any contributions the company makes available will also be released under a FSF or OSI approved license. Note that it doesn't promise to make all of VirtualBox available under one of those licenses — just the contributions that it has received.

Alternately, contributors can choose to submit patches explicitly under the MIT license in lieu of signing the contributor agreement. In any case, only Oracle employees will actually be the ones making commits to VirtualBox's repository.

The move to an extension architecture is better for the community in that those who don't wish to sign the contributor agreement or license their contribution under a non-reciprocal license can in many cases simply write an extension. The company has not yet released any example code for extensions that contributors can follow but the SDK documentation [PDF] has been updated to reflect the new architecture.

Overall, VirtualBox 4.0 represents a fairly nice update. It could use a bit of improvement, but it seems to be on the right track. Though its performance is not always stellar, it's certainly good enough in most cases for users who want to test a Linux distribution before installing, or who have to run Windows for one or two applications.


Comments (5 posted)

Brief items

Quotes of the week

I think people constantly underestimate the virtue of Python and CPython simplicity. Projects that depend on a couple of genius ubergeeks die when the ubergeeks leave. The executable-pseudocode simplicity of the language makes it a favorite for scientific programming, spilling over into financial programming. The simplicity of the code allows competent students (and non-CS major adults) become developers.
-- Terry Reedy

It is no longer vital to work to keep Emacs small. Eight Megabytes Ain't Constantly Swapping any more. However, it remains desirable not to bloat the Emacs Lisp Reference Manual without some benefit.
-- Richard Stallman

Comments (none posted)

Bombono DVD

Bombono DVD 1.0 has been released. See the website for details. New features include transcoding from a variety of formats, previewing any video format, motion menus, subtitles support, bitrate calculator, and special menu actions like "Play All", "Next Video", and end actions for videos. LWN covered Bombono last May.

Comments (none posted)

Gnucash 2.4.0 released

The Gnucash 2.4.0 release is out at last. The biggest change in this release is the ability to store its data in an SQL database; SQLite, MySQL, and PostgreSQL are supported. LWN looked at Gnucash 2.4 last May.

Full Story (comments: none)

KDE Software Compilation 4.6 RC2

The KDE Community has released the second release candidate for KDE SC 4.6. This release includes the Plasma desktop, applications and the development platform.

Comments (none posted)

Linux Desktop Testing Project (LDTP) 2.1.0 released

The Linux Desktop Testing Project aims to produce a high quality test automation framework for the Linux desktop. Version 2.1.0 adds documentation files from LDTPv1 and updated accordingly, search object name as unicode character and multiline, plus performance enhancements and bug fixes.

Full Story (comments: none)

Spamassassin Newsletter

Warren Togami has announced a low traffic Spamassassin mailing list. The list will be announcements only, sort of like a Spamassassin Weekly News, except that posts are likely to be less than weekly. The list is hosted on fedoraproject.org and will be somewhat Fedora/Red Hat-centric. There's also a new blog, Spamassassin Tips. Although somewhat distribution-centric, the content is likely to be of interest to anyone setting up or running Spamassassin.

Comments (none posted)

Newsletters and articles

Development newsletters

Comments (none posted)

Indamixx 2, Music-Focused Tablet Powered by Linux, Unveils Beta Program (Create Digital Music)

The Create Digital Music blog has a look at the MeeGo-based Indamixx 2 audio tablet; one of the first MeeGo tablets available. "The software bundle is the main source of value here, since the tablet you could buy separately. The beta includes various commercial, proprietary software, including file exchange support for Ardour, full copies of Renoise, energyXT, and superb plug-ins from LinuxDSP. There’s also software that, while free, could take a significant investment of time to set up, even for someone with some familiarity with Linux. That includes customization, tweaking, and configuration of the MeeGo Linux operating system, and packages for things like JACK setup. The beta also includes extras like access to a streaming server, accessories, and pre-installation of a multi-boot configuration. As Trinity has pushed before, one audio output option is HDMI, which provides multichannel outs without the need for a dedicated card (provided you have something to which you can connect HDMI on the other end)."

Comments (1 posted)

Karlitschek: Beta of the Qt Creator Buildservice Plugin released (Project Bretzn)

Over on his blog, Frank Karlitschek writes about Project Bretzn, which is targeted at making it easier for developers to get their applications built and made available for multiple platforms. "The plugin lets you perform all the actions required to get data sent to the various build services and publishing sites, by contacting the server part, which then distributes the information to the appropriate places. The implementation of this also prompted [amending] the Attica library with new features. As some will already know, Attica is the full featured implementation of a OCS [Open Collaboration Services] client library built by KDE which is now officially included in the MeeGo platform as well."

Comments (none posted)

Season of KDE 2010 (KDE.News)

KDE.News has a rundown on the projects that seven students worked on as part of the "Season of KDE" (SoK) initiative. Now in its fourth year, SoK provides mentoring for students who were unable to get into the Google Summer of Code. "Finally, Yuvraj Tomar worked on analyzing and improving KDE startup time. The first step was to analyze what was slowing down startup. When the research and analysis was done, he had some discussions with his mentors and with KWin and kdm developers, and then started coding. His results are pretty clear: on a test machine, startup went from about 30 seconds to barely 19. That's a remarkable improvement!"

Comments (1 posted)

Marques: Kick off for GNOME:Ayatana Project…

On his blog, Nelson Marques writes about the GNOME:Ayatana project which is bringing the Ubuntu indicators and Unity UI to openSUSE via the openSUSE Build Service (OBS). "Indicator-sound has also been fixed and no longer requires the nasty hack in the previous package. Since I'm not an Ubuntu user, neither I have extensive experience on their Desktop, I'm not sure if the functionality present so far in the indicators is the one offered by Ubuntu. I plan to run a Open Beta on the Ayatana software repository during the last Milestone of Factory to all Factory users to collect more data and improve the packages, at least the indicators, as in the present since I have ATI hardware I don't have FireGL enabled on Factory, so I can't really push much on Unity and test it for the time being."

Comments (5 posted)

Remnant: The Importance of Being Tested

On his blog, Upstart developer Scott James Remnant looks at Upstart's test suite and how it has found bugs in other parts of the Linux system. "One day these test cases started failing without warning. Investigation showed that they passed fine under older kernels, but with the newest kernel update to Ubuntu, they failed. [...] The inotify subsystem in the kernel had undergone a radical overhaul and rewrite. Rather than being its own code, it was completely rebased onto the new fsnotify system. Fortunately I was aware of this, and after careful checking that it was indeed the kernel behaviour that was now incorrect (and that it wasn't incorrect before), I got in touch with the Eric Paris, the author of the new code, and was able to give him minimal example code to replicate the problem."

Comments (9 posted)

Page editor: Jonathan Corbet

Announcements

Brief items

Crowdfunding software development

Fundry is a new project aimed at connecting developers and users. "In a nutshell, users can propose and collaboratively fund features for software projects. If the developer(s) decide to complete the feature request then they get paid the money."

Full Story (comments: none)

Protecode Joins Linux Foundation

The Linux Foundation has announced that Protecode is its newest member. "Protecode is a provider of products and services for open source software licensing and copyright management, software Intellectual Property (IP) management, code portfolio mapping, and for carrying out IP due diligence of software companies. The company is joining The Linux Foundation to participate in the pan-industry initiative, the Open Compliance Program."

Full Story (comments: none)

New Books

Designing Interfaces, Second Edition--New from O'Reilly

O'Reilly Media has released "Designing Interfaces, Second Edition" by Jenifer Tidwell.

Full Story (comments: none)

Resources

FSFE Newsletter - January 2011

The January edition of the Free Software Foundation Europe newsletter covers: Robots, Football, and Education; Public institutions - hares or snails?; and several other topics.

Full Story (comments: none)

Articles of interest

Ext4 filesystem hits Android, no need to fear data loss (ars technica)

Ars technica reports that Google's new Nexus S smartphone will be the first Android device to use the Ext4 filesystem. "Most Android devices currently use YAFFS, a lightweight filesystem that is optimized for flash storage and is commonly used in mobile and embedded devices. The problem with YAFFS, [Ted] T'so explained in his blog entry, is that it is single-threaded and would likely "have been a bottleneck on dual-core systems." Concurrency will be important on next-generation Android devices that use multi-core ARM processors. We expect to see dual-core Android devices, including tablets, announced as early as CES."

Comments (77 posted)

Paul Allen revises patent suit, targets Android, Apple iTunes (Computerworld)

Computerworld reports that Microsoft co-founder Paul Allen's suit against Google and ten other technology companies is on again, after Interval Licensing (owned by Allen) revised its complaint in response to the December 28 deadline imposed by a judge who dismissed the original complaint. The revision lists spectacular innovations such as: "Patent 6,034,652, dubbed 'Attention Manager for Occupying the Peripheral Attention of a Person in the Vicinity of a Display Device,' spells out a way to notify users of additional information. [...] 'Devices containing the Android Operating System and associated software infringe by displaying information including, e.g., text messages, Google Voice messages, chat messages, and calendar events, to a user of a mobile device in an unobtrusive manner,' claimed the lawsuit."

Comments (15 posted)

Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)

Over at Free Software Magazine, Tony Mobily muses about free software "app stores". His view of what they would look like is decidedly different than the usual ways that free software applications get distributed. "Just to make it clear: the current way of installing software in GNU/Linux distro is not going to make a good app store possible. Having a nice interface to deal with a million dependencies behind the scenes is like putting lipstick on a pig. The limitations imposed by the current "spread the app across the filesystem" are too far-fetching. In the GNU/Linux eco-system, having a distro-dependent app store means further fragmentation and less adoption. Having only system-wide installation implies that every user needs to be an administrator to install apps."

Comments (102 posted)

Garrett: Android tablet GPL summary

Matthew Garrett has announced his list of Android-based tablets. The list includes information about the chipset used and whether the vendor is supplying source for its kernel (as required by the GPL).
I've written a summary page here so you have:
  • Some idea of whether you're funding the theft of sweets from innocent children
  • Some idea of whether there's any realistic chance of you getting further updates once the vendor has decided that last year's devices are, well, last year
  • Some idea of just how bad the situation is

Comments (19 posted)

Kuhn: Conservancy Activity Summary, October-December 2010

Bradley M. Kuhn blogs about his work as Executive Director of the Software Freedom Conservancy. "We excitedly announced in the last few months two new Conservancy member projects, PyPy and Git. Thinking of PyPy connects me back to my roots in Computer Science: in graduate school, I focused on research about programming language infrastructure and in particular as virtual machines and language runtimes. PyPy is a project that connects Conservancy to lots of exciting programming language research work of that nature, and I'm glad they've joined."

Comments (2 posted)

MeeGo tablet specializes in audio recording (LinuxForDevices)

LinuxForDevices looks forward to an interesting upcoming MeeGo device. "The Indamixx 2 ships with a new version 5.0 release of Transmission, says Trinity Audio. For the first time, Transmission runs on the MeeGo Linux mobile operating system instead of Ubuntu, says the company. As before, Transmission supports multi-track audio production, providing a host of mostly open source packages that let users record, edit, equalize, audition, and mix audio at claimed rates of up to 32-bit/96Khz."

Comments (none posted)

MeeGo's Community Woes: Improvement in 2011? (Linux Magazine)

Joe "Zonker" Brockmeier criticizes the MeeGo project on several fronts, and hopes the project will do better in 2011. "First, Intel and Nokia stepped in it fairly badly when deciding to merge Maemo and Moblin. Not the decision itself, necessarily, but the way it was done. That is to say — Intel and Nokia decided to combine forces, but sort of forgot to consult with the vendors and community contributors to Moblin and Maemo beforehand. Maemo, in particular, had a fairly enthusiastic community building around it — that wasn't really consulted about the plan to become MeeGo. Oops."

Comments (10 posted)

Vladimir Putin Orders Russian Government to Switch to Free Software by 2015 (Mashable)

Mashable.com reports that a government order for federal bodies and agencies to transition to free software has been signed by Russian Prime Minister Vladimir Putin. "Each point of the document names the specific action that must be taken, the agency responsible for implementing that order, the time frame for implementation, and the expected result. For example, one point instructs Russia's Ministry of Communications to form "the base package of free software solutions for typical problems of the federal executive bodies," with the expected result a free package of software that includes operating systems, drivers and application software for servers." (Thanks to Sven-Thorsten Dietrich)

Comments (29 posted)

Understanding the Open Invention Network (NetworkWorld)

Joe "Zonker" Brockmeier takes a look at the Open Invention Network (OIN). "After seeing comments about OIN and talking to other FOSS folks, I realized many folks (including yours truly) weren't entirely clear on what OIN does and doesn't protect. Specifically, there seemed to be an idea that OIN covers a lot more than Linux, or anything that's open source, or anything between member companies."

Comments (none posted)

PlayStation 3 code signing cracked (The Register)

The Register is reporting that a group called "fail0verflow" has demonstrated that it has Sony's private key for signing PlayStation 3 code. "The hackers uncovered the hack in order to run Linux [on] PS3 consoles, irrespective on the version of firmware the games console was running. By knowing the private key used by Sony the hackers are able to sign code so that a console can boot directly into Linux. Previous approaches to running the open source OS on a games console were firmware specific and involved messing around with USB sticks. [...] The same code signing technique might also be used to run pirated or counterfeit games on a console. That isn't the intention of the hackers even though it might turn out to be the main practical effect of the hack."

Comments (5 posted)

Firefox, Linux and the future of the web (TechRadar)

Jono Bacon talks with Tristan Nitot, president of Mozilla Europe. "The Mozilla community is a very energetic, passionate group. It seems to be getting bigger all the time: every year we need bigger facilities for our meetups! Like most communities, there is an international element, where people communicate in English, and sometimes French or Spanish - at least in Europe - and there are local communities who are especially active in their own region, have their own site, and their own meetups, and will usually drive localisation for their language or locale. Equally, there are many people involved at Mozilla who probably don't feel an affiliation to a particular regional community, but to the global project. That's the beauty of the internet. The community covers quite a range of interests."

Comments (none posted)

Tiemann: OSI asks German Federal Cartel Office to investigate CPTN transaction

On the Open Source Initiative's (OSI's) blog, Michael Tiemann reports that OSI has asked the German competition authorities to investigate the Microsoft-led acquisition of Novell's 882 patents. "The fact that Microsoft was leading the takeover of Novell's patents was itself alarming to the open source community, but when it was revealed that Microsoft had recruited Oracle, Apple, and EMC to be co-owners of the patents, the OSI Board felt compelled to request that competition authorities take a closer look at the proposed transaction. We found that the German Federal Cartel Office was open to receive comments from the public about this transaction during the month of December, and so we drafted and sent a letter (see attached [PDF]), outlining our concerns and requesting that they investigate this transaction thoroughly. We have received an acknowledgement of receipt by the department in charge, and we stand ready to offer any additional assistance that may be required by investigators should they ask for such help."

Comments (none posted)

Upcoming Events

conf.KDE.in: First KDE Conference in India

KDE.News has some information about conf.KDE.in which takes place March 9-11, 2011 in Bangalore, India. The conference will be followed by a code sprint.

Comments (none posted)

Linux Users' Group of Davis, January meetings

The Linux Users' Group of Davis (LUGOD) will be holding two special meetings this month: "LINUX IN SPAAAAAACE!" on January 11, and "If Tux the Penguin offered you Kool-Aid, would you drink it?" on January 17, in Davis, California.

Full Story (comments: none)

Events: January 13, 2011 to March 14, 2011

The following event listing is taken from the LWN.net Calendar.

Date(s)EventLocation
January 16
January 22
PyPy Leysin Winter Sprint Leysin, Switzerland
January 24
January 29
linux.conf.au 2011 Brisbane, Australia
January 27 Ubuntu Developer Day Bangalore, India
January 27
January 28
Southwest Drupal Summit 2011 Houston, Texas, USA
January 29
January 31
FUDCon Tempe 2011 Tempe, Arizona, USA
February 2
February 3
Cloud Expo Europe London, UK
February 5 Open Source Conference Kagawa 2011 Takamatsu, Japan
February 5
February 6
FOSDEM 2011 Brussels, Belgium
February 7
February 11
Global Ignite Week 2011 several, worldwide
February 11
February 12
Red Hat Developer Conference 2011 Brno, Czech Republic
February 25
February 27
Southern California Linux Expo Los Angelos, CA, USA
March 9
March 11
conf.kde.in 2011 Bangalore, India
March 9
March 11
ConFoo Conference Montreal, Canada
March 11
March 13
PyCon 2011 Atlanta, Georgia, USA

If your event does not appear here, please tell us about it.

Page editor: Rebecca Sobol

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