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
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.
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.
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 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.
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
Comments (none posted)
libwmf: multiple vulnerabilities
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: |
|
Comments (none posted)
mantis: multiple vulnerabilities
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: |
|
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: |
|
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: |
|
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: |
|
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 Wilson | 211 | 1.9% |
Greg Kroah-Hartman | 171 | 1.5% |
Eric Dumazet | 166 | 1.5% |
Johannes Berg | 149 | 1.3% |
Thomas Gleixner | 147 | 1.3% |
Paul Mundt | 140 | 1.2% |
Mauro Carvalho Chehab | 122 | 1.1% |
Joe Perches | 107 | 1.0% |
Avi Kivity | 105 | 0.9% |
Mark Brown | 100 | 0.9% |
Hans Verkuil | 100 | 0.9% |
Namhyung Kim | 100 | 0.9% |
Dan Carpenter | 99 | 0.9% |
Christoph Hellwig | 93 | 0.8% |
Jean Delvare | 88 | 0.8% |
Axel Lin | 88 | 0.8% |
Daniel Vetter | 87 | 0.8% |
Vasiliy Kulikov | 86 | 0.8% |
Arnd Bergmann | 86 | 0.8% |
Julia Lawall | 84 | 0.7% |
|
By changed lines |
Henry Ptasinski | 143303 | 9.6% |
Greg Kroah-Hartman | 100861 | 6.7% |
Vipin Mehta | 92398 | 6.2% |
Luis R. Rodriguez | 71636 | 4.8% |
Mark Brown | 53690 | 3.6% |
David Cross | 48198 | 3.2% |
Dmitry Kravkov | 47198 | 3.1% |
Larry Finger | 40378 | 2.7% |
Krishna Gudipati | 38712 | 2.6% |
Stefan Richter | 29434 | 2.0% |
Stephen Hemminger | 28504 | 1.9% |
Rasesh Mody | 22335 | 1.5% |
Prashant P. Shah | 15086 | 1.0% |
Michael Chan | 14118 | 0.9% |
Christian Lamparter | 13530 | 0.9% |
Liam Girdwood | 13324 | 0.9% |
William Hubbs | 12971 | 0.9% |
Vinod Koul | 12944 | 0.9% |
Marek Belisko | 11531 | 0.8% |
Al Cho | 10097 | 0.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) | 1864 | 16.6% |
Red Hat | 1265 | 11.3% |
(Unknown) | 946 | 8.4% |
Intel | 746 | 6.6% |
Novell | 644 | 5.7% |
IBM | 447 | 4.0% |
Oracle | 272 | 2.4% |
Texas Instruments | 250 | 2.2% |
Nokia | 235 | 2.1% |
Renesas Technology | 210 | 1.9% |
Samsung | 205 | 1.8% |
Broadcom | 172 | 1.5% |
Societe Française de Radiotelephone | 166 | 1.5% |
AMD | 163 | 1.5% |
(Consultant) | 155 | 1.4% |
Pengutronix | 154 | 1.4% |
(Academia) | 146 | 1.3% |
Wolfson Micro | 129 | 1.1% |
Google | 128 | 1.1% |
Fujitsu | 127 | 1.1% |
|
By lines changed |
Broadcom | 246749 | 16.4% |
(None) | 188830 | 12.6% |
Atheros | 165693 | 11.0% |
Novell | 127476 | 8.5% |
Wolfson Micro | 100196 | 6.7% |
Brocade | 64012 | 4.3% |
(Unknown) | 59325 | 4.0% |
Red Hat | 59000 | 3.9% |
Intel | 53893 | 3.6% |
Cypress Semiconductor | 48241 | 3.2% |
Vyatta | 30720 | 2.0% |
Texas Instruments | 22874 | 1.5% |
Samsung | 16771 | 1.1% |
IBM | 16567 | 1.1% |
Nokia | 14731 | 1.0% |
Renesas Technology | 14488 | 1.0% |
(Consultant) | 13592 | 0.9% |
Slimlogic Ltd | 13324 | 0.9% |
ST Ericsson | 13056 | 0.9% |
Chelsio | 10770 | 0.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 Molnar | 86 | 12.6% |
Christoph Hellwig | 37 | 5.4% |
Mike Christie | 29 | 4.3% |
Michael Chan | 26 | 3.8% |
Josh Triplett | 22 | 3.2% |
Daniel Vetter | 21 | 3.1% |
Chuck Lever | 21 | 3.1% |
H. Peter Anvin | 20 | 2.9% |
Konrad Rzeszutek Wilk | 19 | 2.8% |
Alex Elder | 17 | 2.5% |
Luciano Coelho | 16 | 2.3% |
Suresh Jayaraman | 16 | 2.3% |
Swen Schillig | 16 | 2.3% |
Michal Marek | 15 | 2.2% |
Jeff Layton | 15 | 2.2% |
Sam Ravnborg | 15 | 2.2% |
Wu Fengguang | 12 | 1.8% |
Francisco Jerez | 12 | 1.8% |
KOSAKI Motohiro | 12 | 1.8% |
Christoph Lameter | 11 | 1.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 Rothwell | 24 | 4.2% |
Randy Dunlap | 21 | 3.7% |
Linus Torvalds | 19 | 3.3% |
Ingo Molnar | 15 | 2.6% |
Guennadi Liakhovetski | 10 | 1.8% |
Jonathan Cameron | 7 | 1.2% |
David Brownell | 7 | 1.2% |
Sitsofe Wheeler | 6 | 1.1% |
Andrew Morton | 6 | 1.1% |
Dan Rosenberg | 6 | 1.1% |
Jiri Slaby | 5 | 0.9% |
Ben Greear | 5 | 0.9% |
Eric Dumazet | 4 | 0.7% |
Daniel Vetter | 4 | 0.7% |
David S. Miller | 4 | 0.7% |
Robin Holt | 4 | 0.7% |
Andi Kleen | 4 | 0.7% |
Dan Carpenter | 4 | 0.7% |
Sachin Sant | 4 | 0.7% |
Dr. David Alan Gilbert | 4 | 0.7% |
|
Tested-by: credits |
Wolfram Sang | 15 | 4.1% |
Luciano Coelho | 11 | 3.0% |
Kevin Hilman | 10 | 2.7% |
Jeff Pieper | 10 | 2.7% |
Will Deacon | 9 | 2.5% |
Caglar Akyuz | 8 | 2.2% |
Michael Williamson | 8 | 2.2% |
Emil Tantilov | 7 | 1.9% |
Randy Dunlap | 6 | 1.6% |
Stephen Ko | 6 | 1.6% |
Ben Greear | 6 | 1.6% |
Eric Benard | 5 | 1.4% |
Tuomas Katila | 5 | 1.4% |
Maxim Levitsky | 5 | 1.4% |
Ingo Molnar | 4 | 1.1% |
Juuso Oikarinen | 3 | 0.8% |
Jason Wessel | 3 | 0.8% |
Kuninori Morimoto | 3 | 0.8% |
Rabin Vincent | 3 | 0.8% |
Ben Gardiner | 3 | 0.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.
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
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
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.
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.
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) | Event | Location |
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