LWN.net Weekly Edition for November 17, 2011

On the Android 4.0 release

It took a while and some questioned whether it would ever happen at all, but, on November 14, Google announced the availability of the source for version 4.0.1 ("ice cream sandwich") of the Android open source project. This news has been received with a fair amount of celebration, but also with a certain amount of criticism. Now might be a good time to think a bit about how Android interacts with the open source community and whether all of our expectations are where they should be.

What is there not to like about this release? One obvious problem is that it was so long in coming; there has not been a major Android release since 2.3 came out in December, 2010. Since then, the Android code (with the exception of the relatively small parts covered by the GPL license) has been developed and kept behind closed doors. Google's reasons for withholding the source have been explained and examined many times; some find them reasonable, while others do not. But it seems clear that the end result - no Android releases for almost a year - was not a good thing.

Complaints have also been heard about Google's refusal to provide tags for the "Honeycomb" release that was shipped on a handful of devices. The official reasoning is that Honeycomb was "a little incomplete" and that Google would rather see people focusing on the 4.0 release. A focus on the current code seems likely to happen naturally; it is hard to imagine that a whole lot of people will be interested in going through the pain of turning an old and "incomplete" version of the source into something that actually runs on a device when something newer is available. But there may well be people who want to reproduce something like the current binary installation on their devices before proceeding to something newer. Removing the tags and forcing those people to dig through the history for an appropriate commit does seem like a bit of gratuitous obnoxiousness.

On the other hand, if Google had really wanted to be difficult, it could have squashed out that history altogether.

People often complain that Android is not a real open source project. Such assertions are hard to argue against. Android's governance is very much controlled by its owning company. Releases of source are routinely withheld, albeit not usually for as long as was the case for 4.0. To gain access to the current source - to build a new product, for example - requires being a Friend of Google and agreeing to its requirements. The code contains certain antifeatures, such as applications that cannot be uninstalled and the inability to use cell-tower-based location services without reporting back to the mothership, that would probably not exist in a truly free project. And so on; Android clearly works differently than most true, community-oriented free software projects.

It is worth pointing such things out so that we are all clear on exactly what the Android project is. It can even make sense to grumble about them occasionally in the hopes that gentle pressure might cause some things to change over time. But there also comes a time to simply accept Android for what it is and make the best of it.

Let us remember that Android represents a gift of a vast amount of code that is truly free software. That code has become the basis for more open projects like CyanogenMod, where people have done some very fun things with it. The advent of Android has coincided with the arrival of a whole range of devices that are far more open than their predecessors. We now carry powerful computers with broadband network connections in our pockets, and we actually have some control over what runs on those computers. Anybody who wants to build a new platform with Android's capabilities has the software available to them, free of charge and free to modify.

Linux was doing well in the embedded world before Android; now it is pushing toward a point of world dominance. Manufacturers design devices with the idea that they will run Linux from the outset, and, increasingly, their work is flowing back into the mainline kernel as well. Android may be far from a traditional Linux distribution, but it's a base that is entirely capable of running real Linux applications for those who want to do so.

If Android had shoved aside a viable "real Linux" platform in the handset and tablet space, there might be at least a small basis for complaint. But it would be hard to argue that platforms like OpenMoko or MeeGo would have succeeded if Android had not come along and hogged the spotlight. For better or for worse, nobody has managed to put together an alternative Linux-based platform that has seen any adoption by the hardware vendors, and that's not Android's fault.

In fact, even now, there would appear to be space for another mobile platform. Admiration for Android is not universal, and manufacturers would love to have another viable option for their products; it should be possible to establish another contender. There are plenty of Linux-based projects trying to become that contender; the GNOME and KDE projects both have their eyes on that market, and Canonical evidently does as well. Whether any of them (or somebody else) can pull together an offering that succeeds there remains to be seen. Let us hope they can; it would be a shame if that space were to be occupied by another fully proprietary system instead.

Meanwhile we do have Android, and Android, for all its faults, is a gift of great value. It often seems that, as a community, we behave most harshly toward those who contribute the most to us. Let's not stop talking about how Android could be a better project from the community's point of view, but let's also not forget to say "thank you" for all that it is. With the 4.0 release, we once again have a whole bunch of code that we can do great things with; that merits a big "thanks!" from us all.

Comments (10 posted)

Safeguarding GNOME.org with an upload lockdown

Some effects of the kernel.org break-in were immediate, but others have rippled out more slowly. One example of the latter is the GNOME project's system administration team taking a hard look at the security of its own infrastructure. The team is drafting a plan to tighten down access to its servers and looking at the development processes of the project — starting with the module upload process.

Olav Vitters sent an email to the GNOME desktop-devel list on November 10 that outlines a plan to preemptively secure the master.gnome.org server against some preventable compromise paths. His root concern was that more than 350 GNOME developers have shell access, which provides a large attack surface even though most (if not all) of those accounts are used only to upload tar packages — a process that could be more securely performed in other ways. Considering the lengthy process that the kernel.org team had to undertake to restore the server after its compromise, the concern is a very real one.

The GNOME project maintains a variety of public-facing services on different machines (Bugzilla, mailing lists, wikis, web sites, etc.), which are managed by one full-time system administrator paid by the GNOME Foundation, and assisted by a small team of volunteers. Vitters is one of those volunteers. His message to the list, which he styled as an IETF-like "request for comments" (RFC), targeted just one service: the FTP server used to distribute GNOME tarballs.

In the current FTP release process, package maintainers upload tarballs to a GNOME project server using SCP, then log in over SSH and execute an "install-module" script. The script calculates the checksum(s) of the newly-uploaded package(s), copies them to the proper location in the public FTP directory, and triggers another script that starts an FTP sync between the GNOME project server and the "real" master FTP server (which is located off-site) and the official mirrors.

Restricted SSH and DOAP

Due to the interactive SSH step, Vitters said, if any of the 350-or-so package maintainers has their personal machine compromised, an attacker could gain shell access to the GNOME project FTP server. That was the path used by the kernel.org attackers, who then presumably used a local privilege escalation to completely compromise the machine. It is very probable that one or more of the GNOME user's machines has been compromised, but that has evidently not led to unauthorized access to the GNOME servers.

Vitters proposed a replacement module-upload plan, in which the initial file transfer would be performed with rrsync (the Perl-based program that restricts rsync to a pre-determined subdirectory) over an SSH tunnel. The user would then call a revised version of the install-module script remotely over SSH, where the SSH daemon on the server was configured to only permit execution of that script, rather than a full shell.

The server-side scripts already in use would also be modified to check the user account that uploaded the new file against a list of approved uploaders for the module, taken from the module's Description of a Project (DOAP) file. DOAP is an RDF format used to define the semantics of a project and its team; GNOME already stores DOAP files for each module in the project's Git repository.

The primary benefit of the plan is that it eliminates the need for the 350+ shell accounts. Even if a module maintainer's home machine is compromised, keeping the server locked down so that remote shell access is unavailable makes it more difficult to wreak large-scale havoc. It would still be possible to replace a package, but the identity check performed against DOAP would, in theory, mean that the attacker could only replace a small subset of packages for the majority of accounts. This is an improvement, because currently anyone with a shell account on the server can upload any package.

Vitters posed several questions for the list, starting with whether or not the proposed process was so much more arduous than the existing system that it would meet with resistance. But he also pointed out potential technical hurdles such as uncertainty over the reliability of rsync, whether rsync could be used to delete files, and the fact that although most GNOME modules have a DOAP file in Git, those GNOME modules that are not tracked using Git do not.

Reaction and feedback

Maciej Marcin Piechotka asked whether scp might be preferable to rsync, and suggested that the Git DOAP files are not secure, because anyone with Git access could upload a new DOAP file — a change less likely to be noticed by others than is the upload of a new tarball. Vitters replied that he considered, but ruled out, scp and sftp for the upload step because both permitted more file operations than rsync alone. In the interest of "just allowing exactly what is needed," he said, rsync was the better fit. "I don't want people to be able to modify anything [other] than uploading a tarball." He confirmed the vulnerability of the DOAP file in Git, and proposed modifying the upload scripts to notify existing maintainers whenever the DOAP file is modified.

Ray Strode then weighed in against restricting uploads to individuals in the DOAP file on the grounds that there are a lot of less-actively-maintained modules, and an unpredictable set of users who periodically need to make releases of them. "I think the lack of fine grained ACLs for this sort of thing is one part of GNOME that work better than projects that try to lock things down more aggressively," he said. Matthias Clasen and Bastien Nocera added that they were two such users, who occasionally update maintenance-mode modules when a change in such a module is mandated by an update to one of their own modules.

Vitters then suggested that the allowed-user-list could include the maintainers of each module plus all members of the release team, since both Clasen and Nocera are on the release team. Clasen and Nocera seemed happy with that adjustment, but Strode did not:

Strode's concern is not easily reconcilable with the overall plan, because it boils down to a philosophical, not a technical question: how locked-down is too locked-down. A lax security policy towards the less-frequently-updated modules simplifies the work for the administrators and allows more people to contribute, but the less-active modules are an easier target for attackers. Inserting malicious code into an actively-developed module is likely to get noticed in short order; by instead inserting it into a nearly-forgotten Makefile that is still pulled in and executed when building GNOME, one accomplishes the same goal with less risk of getting caught.

Alan Cox suggested that the team take a look at the tools used by the kernel.org team, which went through much the same locking-down process in September and October in response to the August break-in.

Lessons from kernel.org

The kernel.org lockdown began with the same concern as Vitters' RFC: eliminating the several-hundred shell accounts used mainly for uploading. Since the break-in, H. Peter Anvin has developed a suite of utilities for kernel.org that implement much the same process that Vitters is pursuing for the GNOME FTP server. Namely, allowing secure uploads, with access control measures limiting what individual users can upload, and without requiring shell access on the receiving machine. Anvin's work is the kernel.org upload tool, or "kup." It includes an upload client called kup and a server-side script called kup-server.

The kup-server script needs to be modified for each user account, to specify the pathnames for allowable uploads, Git trees, lock files, and the user's public keyring. The keyring file is read-only, and is used to verify signatures; kup-server checks that uploads are signed with a trusted OpenPGP key. Establishing the trust between the identities and keys was one of the lengthiest parts of bringing kernel.org back online.

Beyond simply utilizing a custom client instead of rsync, there are other differences, between kup and the GNOME.org proposal. The kup client contains multiple levels of sanity checks, even dry-running the requested commands in order to trap errors. It also supports other file operations in addition to uploads, including deletion, moving/renaming files, and creating links.

In addition, David Woodhouse said that he has set up a two-factor authentication scheme for kernel.org that has not yet been rolled out. It requires that users have both an SSH key and a one-time-password (OTP) generated by Google Authenticator. Google Authenticator includes a PAM module to secure applications, and a collection of OTP generators for various mobile phone OSes.

As of press time, Vitters told the list that he had gotten in touch with Anvin to follow-up about kup, but has not yet announced any alterations to the GNOME FTP proposal based on those conversations. The kernel.org team learned the hard way how much hassle a break-in on an upload server can produce. Although other, somewhat lower-profile projects may not present nearly as enticing an objective for attackers, they can learn from its example, and it is good to see GNOME undertaking a preventative lock-down. One hopes that the project is also taking steps to ensure that its infrastructure is not already compromised as well.

Ultimately a more secure infrastructure may inconvenience package maintainers, system administrators, and developers that (like Strode) prefer a less formal structure, but for a project of any size, what other choice is there? Package uploading and verification requires a security policy; it is too inviting of a target to not lock it down.

Comments (3 posted)

Awesome: A window manager that gets out of the way

Sabayon Linux, the easy-to-use Linux distribution built on top of Gentoo Linux, recently announced three new experimental editions that supplement their previous GNOME, KDE, Xfce, and Core releases. Two of the new experimental editions are equipped with unsurprising desktop environments: LXDE and E17 (Enlightenment). The third desktop choice, however, is surprising: the awesome window manager.

Awesome is no stranger to me: I have been using it for three years as the window manager on my main work computer because it's highly configurable and visually minimalistic, so I can focus on my work without any distractions. It's not so surprising that awesome isn't popular, as it's going up against modern desktop environments like GNOME 3, KDE 4 and Unity. In contrast to those desktop environments, awesome doesn't want to appeal to non-expert users, doesn't offer an Apple-like experience, and doesn't come with all kinds of bells and whistles. This makes it even more interesting that a mainstream distribution like Sabayon chose to include an edition with awesome.

A framework window manager

Awesome is called "a highly configurable, next generation framework window manager for X" by its developers. By "framework window manager" they mean that users actually build their own window manager with awesome: while it's usable with the default configuration, it is meant to be extended and configured by the user. Because of this, awesome is primarily targeted at power users, developers, and anyone who wants to have fine-grained control over their graphical environment. In contrast, if you don't like tweaking your system or if you like out-of-the-box bells and whistles, awesome probably isn't for you.

Awesome has a small code base and memory footprint and is fast. Because it's using the asynchronous XCB library instead of the synchronous Xlib, it also promises less latency than other window managers, at least according to the home page. It prides itself on implementing many Freedesktop standards, such as EWMH (Extended Window Manager Hints) that allows programs to give hints to the window manager about the type of their windows, Desktop Notification to provide popup notifications on the desktop, System Tray to display small icons provided by running applications, and D-Bus for interprocess communication. And it even supports multiple monitors in XRandR, Xinerama, and Zaphod mode. So while it's a minimalist window manager, it doesn't fall short in its features.

Everyday working with awesome

By default, awesome has a simple but already quite usable configuration that will even support multiple monitors. When you start an awesome X session, you'll see a minimalist desktop with a status bar on top of the screen. Awesome can be controlled completely with the keyboard, so you'll have to memorize some keyboard shortcuts to become proficient at it. For instance, Win+Enter opens a new terminal window (Win is the key with the Windows logo, called Mod4 in awesome's documentation and configuration file), Win+j cycles through the windows, Win+h or l resizes a window (but Win+right-click and dragging with the mouse is a bit more convenient), Win+Shift+j or k moves a window (as does Win+left-click and dragging with the mouse). With Win+Shift+c you close the focused window. Starting a program is simple: enter Win+r, after which you see a "Run:" prompt in the status bar and you can type a program name (with tab completion). It pays to read ~/.config/awesome/rc.lua a bit to get to know all these keyboard shortcuts. When you're used to them, awesome lets you really manage your windows in a very efficient way.

By default, awesome behaves like a regular stacking window manager, but it started as a tiling window manager and I still find this mode the most efficient to use. Just click on the icon in the upper right to use the tiled layout. When you open your first window, it covers the whole screen, and subsequently opened windows are tiled automatically alongside the other windows, so the available screen real estate is always covered completely unless you have no windows open. By default, the most recent window is shown at the entire left part of the screen and the other ones are automatically rearranged on the right side. You don't have to juggle with your windows to get the most out of your screen; awesome does the job for you. By the way, there are no title bars attached to the windows by default, although you can change that in the configuration file.

The status bar at the top of the screen shows nine numbers by default at its leftmost part. If you click on one of them, you get a completely empty screen, ready to contain some new windows. Superficially, this looks like the workspace concept in many other desktop environments, but in awesome they are called tags and the relationship is backwards: while a workspace contains windows, in awesome tags belong to a window. This means that a single window can have multiple tags, but you can also view multiple tags together by right-clicking on another tag in the status bar. The nine tags can be reconfigured to have more descriptive names, although you probably should keep them short. For instance, I have tags "read", "talk", "surf", "type", "file", "hear" and "root". All in all, the concept of tags is much more flexible than traditional workspaces.

To the right of the tag list comes the task list, which is the list of windows on the currently visible tag(s). To the right of that, there's the clock, and at the rightmost part of the status bar is the layout box which we already mentioned earlier. If you click on it, the way in which awesome arranges all visible windows changes. You can cycle through all available layouts with left-click (forward) and right-click (backward) or by using Win+Space. There's a spiral layout, a maximized layout (which only shows the focused window), a fullscreen layout (which even covers the status bar), a magnifier layout (which shows the focused window in the middle and the other ones on the background) and a floating layout, which shows all windows free-floating and covering each other, like you're used to from stacking window managers.

You can also toggle the floating/tiled status of the focused window with Win+Ctrl+Space and you can configure awesome to automatically force specific programs (like GIMP) to always float. You can also set the default layout programmatically in the configuration file. For instance, I have set the layout of my left screen to tiled and the layout of my right screen (which stands in portrait mode) to tiled.bottom, which tiles the windows vertically. This kind of personalization is very easy to do in awesome.

Tuning your desktop environment

Awesome is just a window manager, so, by default, a lot of functionality offered by a complete desktop environment will be missing. But most of this functionality can be added to the configuration file or supplemented by external programs. The upside is that you can pick your components: you can for instance choose lightweight alternatives. The downside is that you have to configure a lot of things that come out-of-the-box with a desktop environment such as GNOME or KDE and you have to add many programs to your awesome key bindings or to your ~/.xinitrc before you have a working desktop environment with things like an automounter, a file manager, a network applet or a screen shot program. You can also add widgets to the status bar, e.g. a systray, graphs of the memory or CPU usage, and so on.

If you like the complete desktop environment that GNOME or KDE is offering and you just want to swap their default window manager for awesome, that's also possible. This gives you your familiar desktop environment, but with the much more flexible window management functionality of awesome. Have a look at the wiki on how to set up awesome with GNOME or with KDE.

Some programs have to be tuned to be able to use them well with awesome. For instance, if someone mentions you on IRC when you're using the irssi client, the tag associated with your irssi client can become orange (or whatever color you have configured in your awesome theme) by setting up a couple of things. There are also some problems with Java programs when you use a Java virtual machine older than version 1.7, but most issues can be overcome.

Development

Awesome began in September 2007 as a fork of dwm, an extremely minimalist window manager which can only be customized through editing its source code (all options meant to be user-configurable are contained in a single header file). Debian developer Julien Danjou liked dwm's minimalism, but wanted it to have an external configuration file. In version 3.0, he decided to use the programming language Lua for the configuration file format.

Danjou is still the primary author of awesome, but there are a lot of other contributors, and Uli Schlachter maintains awesome now. After a frantic development speed the first two years, development has slowed down now, with the latest release, 3.4.10, being made on May 16 along with a rather low number of commits in the project's repository. In an email interview, Danjou said that the reason for the slowdown is simple:

Although one could say awesome is finished now, there's an active community of users and the wiki is a goldmine for resources, including some user configuration files, themes, user-contributed widgets, and example screenshots. Awesome is available in the repositories of a lot of Linux distributions (but surprisingly not in Fedora), and also in the BSDs. Some of these distributions have their own wiki pages with a guide and distro-specific information, such as Arch Linux and Gentoo.

Tune it now

Although awesome is not an easy program to learn, the framework window manager invites you to experiment with and tune your desktop environment. For instance, you can modify your rc.lua file and restart awesome for these changes to have effect with a simple Win+Ctrl+r. To get some idea of the possibilities, have a look at all the signals awesome emits, to which you can hook your own handler functions. If you dislike the way how GNOME, KDE, and Unity are evolving and you want a window manager that you can tune to get out of your way, you definitely should take a look at awesome. For a quick glance, try the new Sabayon 7 Awesome edition.

Comments (52 posted)

Page editor: Jonathan Corbet

Security

Security response: how are we doing?

Linux, as a whole, has a pretty good security record. But software has bugs, and some of those are security-related bugs, so there will always be a need for security fixes. When a security problem arises, most of us are entirely dependent on our distributors to package those fixes and push them out; the number of users who can learn about security problems and build their own replacement packages is relatively small. Security response is, thus, an important point to consider when choosing a distribution for a specific task.

The following table looks at a number of vulnerabilities that were disclosed, or which prompted the issuance of advisories, in recent months. In each case, the response time for a set of distributions is listed. Before reading this table, though, it is important to understand how the choices were made and what the implications are. In particular:

• The distributions considered are CentOS 5, Debian stable ("squeeze"), Fedora 15, openSUSE 11.4, Red Hat Enterprise Linux 5, Scientific Linux 5 and Ubuntu 11.04. The idea was to pick a recent release of each that is likely to have a significant number of users. The choice of RHEL 5 (and variants) could easily be questioned, but it is still likely to be in much heavier use than RHEL 6. Given that CentOS is still not issuing updates for CentOS 6, choosing that distribution would have led to an ugly column for CentOS below.

• The vulnerabilities were chosen in an entirely non-rigorous way with an eye toward those that might pose a real threat.

In the table below, a numeric entry gives the number of days since the initial disclosure, if known, or (most often) the earliest distribution advisory. An entry of "NV" indicates that the distribution was not vulnerable to the indicated problem and, thus, did not need to issue an update. If the entry reads "none," instead, the distribution is vulnerable but has not yet pushed an update.

Vuln	C5	Debian	F15	openSUSE	RH5	SL5	Ubuntu	Notes
apache	16	0	17	3	2	2	3
crypt_blowfish	60	80	7	0	59	59	60	Debian only partially fixed
freetype	5	3	20	none	4	4	none
kdelibs	8	none	16	6	8	8	14	No Fedora advisory sent
kernel	43	0	NV	none	42	42	34
krb5	NV	NV	29	6	NV	NV	0
libpng	66	10	0	30	10	10	8
mod_proxy	42	none	none	57	42	42	64
openjdk	1	none	2	10	0	1	none
openssl	NV	NV	0	40	NV	NV	NV
pam	0	none	1	367	0	none	210
pam	NV	0	NV	9	NV	NV	0
php	127	0	81	110	126	126	111
quagga	none	7	20	20	none	none	46
rpm	0	none	2	31	0	0	none	Debian/Ubuntu do package RPM
Xorg	15	none	NV	none	15	15	27	2010 CVE; F14 still vulnerable

Before launching into conclusions, your editor would like to point out that distributors have made it much easier to obtain this type of information in recent years. In many cases, it is possible to go directly to a distribution-specific page or bug-tracker entry for a given CVE number. For the most part, distributors are quite open about their exposure to specific vulnerabilities; that is exactly how it should be.

Ideally, a table like the above should have no "none" entries at all. There was no distributor without unpatched vulnerabilities, but some clearly have more than others. It is, in particular, sad to see so many missing updates in the Debian column. One could argue that, say, a lack of urgency to fix an rpm vulnerability on Debian's part is understandable, but one could also argue that, if the package is not worth fixing, it probably should not be shipped in the first place. Despite being based on Debian, Ubuntu has a more complete set of updates, but the smallest number of missing updates can be found in the Red Hat and Fedora columns; Red Hat continues to be relatively serious about getting fixes out there.

The best way to deal with a vulnerability, of course, is to not be vulnerable to it in the first place. It is interesting to note that the distributions with the most "not vulnerable" entries are the oldest ones (RHEL, Debian stable) and the newest ones. Distributions based on older software get to miss out on more recently introduced bugs, but they also miss the most recent fixes, some of which unknowingly close security holes. There are limits to the conclusions that can be drawn from such a small sample, but there does appear to be a difficult "middle age" for distributions where they are subject to the largest number of known vulnerabilities.

Finally, we still are clearly not doing well enough. There are too many vulnerabilities in the first place, and too many of them sit unfixed for too long. The security situation is not getting any more friendly or forgiving; we cannot afford to sit back and think that the security problem is even close to being solved. A lot has been accomplished in this area, but quite a bit remains to be done.

Comments (11 posted)

Brief items

Security quotes of the week

-- Bruce Schneier

-- Mozilla on the "Stop Online Piracy Act" (SOPA)

-- Harvey Anderson, general counsel for Mozilla

-- Google adds a privacy option that many access point owners may find challenging to use

Comments (43 posted)

New vulnerabilities

acroread: multiple vulnerabilities

Package(s):	acroread	CVE #(s):	CVE-2011-1353 CVE-2011-2441
Created:	November 15, 2011	Updated:	November 21, 2011
Description:	From the CVE entries: Unspecified vulnerability in Adobe Reader 10.x before 10.1.1 on Windows allows local users to gain privileges via unknown vectors. (CVE-2011-1353). Multiple stack-based buffer overflows in CoolType.dll in Adobe Reader and Acrobat 8.x before 8.3.1, 9.x before 9.4.6, and 10.x before 10.1.1 allow attackers to execute arbitrary code via unspecified vectors. (CVE-2011-2441)
Alerts:	SUSE SUSE-SA:2011:044 2011-11-16 SUSE SUSE-SU-2011:1239-1 2011-11-15 Gentoo 201201-19 2012-01-30

Comments (none posted)

cacti: SQL injection/cross-site scripting

Package(s):	cacti	CVE #(s):
Created:	November 14, 2011	Updated:	November 16, 2011
Description:	Cacti version 0.8.7h fixes SQL injection issue with user login and cross-site scripting issues. The Cacti release notes provides few details.
Alerts:	Fedora FEDORA-2011-15071 2011-10-29 Fedora FEDORA-2011-15110 2011-10-29 Fedora FEDORA-2011-15032 2011-10-28

Comments (none posted)

flash-plugin: abandon all hope

Package(s):	flash-plugin	CVE #(s):	CVE-2011-2445 CVE-2011-2450 CVE-2011-2451 CVE-2011-2452 CVE-2011-2453 CVE-2011-2454 CVE-2011-2455 CVE-2011-2456 CVE-2011-2457 CVE-2011-2459 CVE-2011-2460
Created:	November 11, 2011	Updated:	November 17, 2011
Description:	From the Red Hat advisory: Multiple security flaws were found in the way flash-plugin displayed certain SWF content. An attacker could use these flaws to create a specially-crafted SWF file that would cause flash-plugin to crash or, potentially, execute arbitrary code when the victim loaded a page containing the specially-crafted SWF content. (CVE-2011-2445, CVE-2011-2450, CVE-2011-2451, CVE-2011-2452, CVE-2011-2453, CVE-2011-2454, CVE-2011-2455, CVE-2011-2456, CVE-2011-2457, CVE-2011-2459, CVE-2011-2460)
Alerts:	SUSE   2011-11-15 openSUSE openSUSE-SU-2011:1240-2 2011-11-16 openSUSE openSUSE-SU-2011:1240-1 2011-11-15 Red Hat RHSA-2011:1445-01 2011-11-11 SUSE SUSE-SU-2011:1244-1 2011-11-15

Comments (4 posted)

graphite2: unspecified vulnerabilities

Package(s):	graphite2	CVE #(s):
Created:	November 14, 2011	Updated:	November 16, 2011
Description:	From the Mandriva advisory: Unspecified vulnerabilities were discovered in graphite2 concerning specially crafted TTF fonts and which has unknown impact. As a preemptive measure the new 1.0.3 version is being provided where this is fixed.
Alerts:	Mandriva MDVSA-2011:174 2011-11-14

Comments (none posted)

lightdm: privilege escalation

Package(s):	lightdm	CVE #(s):	CVE-2011-3153 CVE-2011-4105
Created:	November 15, 2011	Updated:	March 13, 2012
Description:	From the Ubuntu advisory: It was discovered that Light Display Manager incorrectly handled privileges when reading .dmrc files. A local attacker could exploit this issue to read arbitrary configuration files, bypassing intended permissions. (CVE-2011-3153) It was discovered that Light Display Manager incorrectly handled links when adjusting permissions on .Xauthority files. A local attacker could exploit this issue to access arbitrary files, and possibly obtain increased privileges. In the default Ubuntu installation, this would be prevented by the Yama link restrictions. (CVE-2011-4105)
Alerts:	Ubuntu USN-1262-1 2011-11-15

Comments (none posted)

mozilla: multiple vulnerabilities

Package(s):	mozilla	CVE #(s):	CVE-2011-3651 CVE-2011-3652 CVE-2011-3654 CVE-2011-3655
Created:	November 10, 2011	Updated:	July 23, 2012
Description:	From the Mandriva advisory: Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox 7.0 and Thunderbird 7.0 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors (CVE-2011-3651). The browser engine in Mozilla Firefox before 8.0 and Thunderbird before 8.0 does not properly allocate memory, which allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unspecified vectors (CVE-2011-3652). The browser engine in Mozilla Firefox before 8.0 and Thunderbird before 8.0 does not properly handle links from SVG mpath elements to non-SVG elements, which allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unspecified vectors (CVE-2011-3654). Mozilla Firefox 4.x through 7.0 and Thunderbird 5.0 through 7.0 perform access control without checking for use of the NoWaiverWrapper wrapper, which allows remote attackers to gain privileges via a crafted web site (CVE-2011-3655).
Alerts:	openSUSE openSUSE-SU-2011:1290-1 2011-12-01 Ubuntu USN-1282-1 2011-11-28 Ubuntu USN-1277-2 2011-11-23 Ubuntu USN-1277-1 2011-11-23 openSUSE openSUSE-SU-2011:1243-1 2011-11-15 SUSE SUSE-SU-2011:1256-2 2011-11-21 SUSE SUSE-SU-2011:1256-1 2011-11-18 Mandriva MDVSA-2011:169 2011-11-09 openSUSE openSUSE-SU-2012:0567-1 2012-04-27 Mageia MGASA-2012-0176 2012-07-21 Gentoo 201301-01 2013-01-07

Comments (none posted)

ocsinventory: cross-site scripting

Package(s):	ocsinventory	CVE #(s):	CVE-2011-4024
Created:	November 14, 2011	Updated:	September 24, 2012
Description:	From the CVE entry: Cross-site scripting (XSS) vulnerability in ocsinventory in OCS Inventory NG 2.0.1 and earlier allows remote attackers to inject arbitrary web script or HTML via unspecified vectors.
Alerts:	Fedora FEDORA-2011-15007 2011-10-27 Fedora FEDORA-2011-14963 2011-10-27 Mandriva MDVSA-2012:053 2012-04-04 Mageia MGASA-2012-0275 2012-09-23

Comments (none posted)

openssl: provides updated library

Package(s):	openssl0.9.8	CVE #(s):
Created:	November 14, 2011	Updated:	November 16, 2011
Description:	From the Mandriva advisory: On Mandriva Linux 2010.2 we provided the old openssl 0.9.8 library but without a source RPM file. This could pose a security risk for third party commercial applications that still uses the older OpenSSL library, therefore the latest stable openssl 0.9.8r library is being provided.
Alerts:	Mandriva MDVSA-2011:173 2011-11-12

Comments (none posted)

proftpd: remote code execution

Package(s):	proftpd-dfsg proftpd	CVE #(s):	CVE-2011-4130
Created:	November 16, 2011	Updated:	February 13, 2012
Description:	ProFTPD suffers from a use-after-free bug that may be exploitable by a remote attacker for arbitrary code execution.
Alerts:	Mandriva MDVSA-2011:181 2011-12-07 Fedora FEDORA-2011-15741 2011-11-11 Fedora FEDORA-2011-15740 2011-11-11 Fedora FEDORA-2011-15765 2011-11-11 Debian DSA-2346-1 2011-11-15 Slackware SSA:2012-041-04 2012-02-10

Comments (none posted)

python-django-piston: remote code execution

Package(s):	python-django-piston	CVE #(s):	CVE-2011-4103
Created:	November 14, 2011	Updated:	November 16, 2011
Description:	From the Debian advisory: It was discovered that the Piston framework can deserialize untrusted YAML and Pickle data, leading to remote code execution.
Alerts:	Debian DSA-2344-1 2011-11-11

Comments (none posted)

wireshark: multiple vulnerabilities

Package(s):	wireshark	CVE #(s):
Created:	November 15, 2011	Updated:	November 16, 2011
Description:	Wireshark 1.6.3 fixes several security bugs. See the release notes for details.
Alerts:	Fedora FEDORA-2011-15328 2011-11-03 Fedora FEDORA-2011-15338 2011-11-03 Fedora FEDORA-2011-15290 2011-11-02

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel is 3.2-rc2, released on November 15. "And for being an -rc2 release of a pretty large merge-window, it seems to be quite reasonably sized. In fact, despite this having been the largest linux-next in a release in our linux-next history (I think), rc2 has the exact same number of commits since rc1 as we had during the 3.1 release." There are lots of fixes and a couple of ktest improvements.

Stable updates: the 3.0.9 and 3.1.1 stable kernels were released on November 11. Both contain a very long list of important fixes.

Comments (none posted)

Quotes of the week

-- Andrew Morton

-- Matthew Garrett maybe fixes a serious power problem

Comments (none posted)

Kernel development news

Huge pages, slow drives, and long delays

It is a rare event, but it is no fun when it strikes. Plug in a slow storage device - a USB stick or a music player, for example - and run something like rsync to move a lot of data to that device. The operation takes a while, which is unsurprising; more surprising is when random processes begin to stall. In the worst cases, the desktop can lock up for minutes at a time; that, needless to say, is not the kind of interactive response that most users are looking for. The problem can strike in seemingly arbitrary places; the web browser freezes, but a network audio stream continues to play without a hiccup. Everything unblocks eventually, but, by then, the user is on their third beer and contemplating the virtues of proprietary operating systems. One might be forgiven for thinking that the system should work a little better than that.

Numerous people have reported this sort of behavior in recent times; your editor has seen it as well. But it is hard to reproduce, which means it has been hard to track down. It is also entirely possible that there is more than one bug causing this kind of behavior. In any case, there should now be one less bug of this type if Mel Gorman's patch proves to be effective. But a few developers are wondering if, in some cases, the cure is worse than the disease.

The problem Mel found appears to go somewhat like this. A process (that web browser, say) is doing its job when it incurs a page fault. This is normal; the whole point of contemporary browsers sometimes seems to be to stress-test virtual memory management systems. The kernel will respond by grabbing a free page to slot into the process's address space. But, if the transparent huge pages feature is built into the kernel (and most distributors do enable this feature), the page fault handler will attempt to allocate a huge page instead. With luck, there will be a huge page just waiting for this occasion, but that is not always the case; in particular, if there is a process dirtying a lot of memory, there may be no huge pages available. That is when things start to go wrong.

Once upon a time, one just had to assume that, once the system had been running for a while, large chunks of physically-contiguous memory would simply not exist. Virtual memory management tends to fragment such chunks quickly. So it is a bad idea to assume that huge pages will just be sitting there waiting for a good home; the kernel has to take explicit action to cause those pages to exist. That action is compaction: moving pages around to defragment the free space and bring free huge pages into existence. Without compaction, features like transparent huge pages would simply not work in any useful way.

A lot of the compaction work is done in the background. But current kernels will also perform "synchronous compaction" when an attempt to allocate a huge page would fail due to lack of availability. The process attempting to perform that allocation gets put to work migrating pages in an attempt to create the huge page it is asking for. This operation is not free in the best of times, but it should not be causing multi-second (or multi-minute) stalls. That is where the USB stick comes in.

If a lot of data is being written to a slow storage device, memory will quickly be filled with dirty pages waiting to be written out. That, in itself, can be a problem, which is why the recently-merged I/O-less dirty throttling code tries hard to keep pages for any single device from taking too much memory. But writeback to a slow device plays poorly with compaction; the memory management code cannot migrate a page that is being written back until the I/O operation completes. When synchronous compaction encounters such a page, it will go to sleep waiting for the I/O on that page to complete. If the page is headed to a slow device, and it is far back on a queue of many such pages, that sleep can go on for a long time.

One should not forget that producing a single huge page can involve migrating hundreds of ordinary pages. So once that long sleep completes, the job is far from done; the process stuck performing compaction may find itself at the back of the writeback queue quite a few times before it can finally get its page fault resolved. Only then will it be able to resume executing the code that the user actually wanted run - until the next page fault happens and the whole mess starts over again.

Mel's fix is a simple one-liner: if a process is attempting to allocate a transparent huge page, synchronous compaction should not be performed. In such a situation, Mel figured, it is far better to just give the process an ordinary page and let it continue running. The interesting thing is that not everybody seems to agree with him.

Andrew Morton was the first to object, saying "Presumably some people would prefer to get lots of huge pages for their 1000-hour compute job, and waiting a bit to get those pages is acceptable." David Rientjes, presumably thinking of Google's throughput-oriented tasks, said that there are times when the latency is entirely acceptable, but that some tasks really want to get huge pages at fault time. Mel's change makes it that much less likely that processes will be allocated huge pages in response to faults; David does not appear to see that as a good thing.

One could (and Mel did) respond that the transparent huge page mechanism does not only work at fault time. The kernel will also try to replace small pages with huge pages in the background while the process is running; that mechanism should bring more huge pages into use - for longer-running processes, at least - even if they are not available at fault time. In cases where that is not enough, there has been talk of adding a new knob to allow the system administrator to request that synchronous compaction be used. The actual semantics of such a knob are not clear; one could argue that if huge page allocations are that much more important than latency, the system should perform more aggressive page reclaim as well.

Andrea Arcangeli commented that he does not like how Mel's change causes failures to use huge pages at fault time; he would rather find a way to keep synchronous compaction from stalling instead. Some ideas for doing that are being thrown around, but no solution has been found as of this writing.

Such details can certainly be worked out over time. Meanwhile, if Mel's patch turns out to be the best fix, the decision on merging should be clear enough. Given a choice between (1) a system that continues to be responsive during heavy I/O to slow devices and (2) random, lengthy lockups in such situations, one might reasonably guess that most users would choose the first alternative. Barring complications, one would expect this patch to go into the mainline fairly soon, and possibly into the stable tree shortly thereafter.

Comments (39 posted)

Reverting disk aliases?

Back in June, we looked at a proposed mechanism for adding aliases to device names, disks in particular. Since then, the patch has been merged into the mainline, but some kernel developers are not happy with that and have asked that it be reverted. Part of the complaint is that the functionality adds to the kernel ABI, which will need to be maintained "forever", but there are other solutions to the problem that don't require kernel changes. So far, the patch has not been reverted, but there is an underlying question: who gets to decide when and where to extend the kernel's ABI?

The alias patch was authored by Nao Nishijima and came into the mainline (for 3.2-rc1) by way of James Bottomley's SCSI tree. The patch allows administrators to associate an alias name for a particular disk by writing to the /sys/block/<disk>/alias sysfs file. That way, certain log messages can be made using the user-supplied disk name rather than the raw name of the disk, which may change on each boot.

Tejun Heo requested that the patch be reverted, noting that it "has been nacked by people working on device driver core, block layer and kernel-userland interface and shouldn't have been upstreamed". That request was quickly acked by several people (Greg Kroah-Hartman, Kay Sievers, Jens Axboe, and Jeff Garzik), with Axboe explicitly noting that it should be done soon: "We need to revert it before 3.2 rolls out, otherwise we are stuck with it."

As might be guessed, though, Bottomley disagreed that it should be reverted, saying that it solved a real problem:

Several folks pounced on the "hack" admission in Bottomley's note, but both Kroah-Hartman and Sievers believe that there is no need for a kernel-side solution at all. As Sievers put it:

Furthermore, Kroah-Hartman pointed out that Nishijima recognizes that it can be solved in user space: "Again, this is fixable in userspace, the author of the patch agrees with that, yet refuses to make the userspace changes despite having a few _years_ in which to so so". As with the others commenting, Sievers is also concerned about adding to the user-space interface: "Such hacks are not supposed to get in, and its really hard to get them out again."

While the patch has not been reverted, Nishijima may be anticipating that outcome with a post that looks at changes to udev: "I understood why this patch is not acceptable and would like to solve the problem of the device name mismatch in *user space* using udev". Kroah-Hartman suggests posting udev patches that implement the changes to the linux-hotplug mailing list as a good starting point.

It would seem that Bottomley made something of an end-run around the objections of various maintainers by pulling the change into his tree. His reasons for doing so make sense, because there are customers asking for the change, but it still routes around the usual paths. Heo's request certainly indicates that he doesn't believe it came in via the proper path, and Kroah-Hartman is blunt about that as well: "Also, you should have gotten this through the block layer maintainer...". It is a hack as everyone seems to agree, but it's a hack that leaves behind an ABI for the kernel to maintain forevermore. It is not surprising that a number of core developers would like to see it reverted.

Comments (3 posted)

Reworking the DMA mapping code (especially on ARM)

Direct memory access (DMA) I/O is a simple-sounding concept: devices are able to access memory directly and transfer data without involving the CPU. In practice, of course, it turns into a complex problem when confronted with the real world and its strange architectural differences, problematic devices, and varying I/O needs. The DMA mapping API was created as a way to minimize the amount of DMA-related complexity that drivers have to deal with, a goal it has achieved fairly well. Changing needs, and increasing hardware complexity are driving some changes in this area, though, with the side benefit that the ARM architecture should get a nice cleanup as well.

As is the case in many areas, the ARM architecture has its own implementation of the DMA API, despite the fact that there is quite a bit of architecture-independent code available to be used. The usual reasons apply here: a combination of developers only working in the ARM tree and peculiarities specific to that architecture. It is a pattern that has been seen in many other places; it is certainly not specific to ARM.

One of the first things done by Marek Szyprowski's ARM DMA redesign patch set is to hook ARM into the common DMA mapping framework. That enables the deletion of a certain amount of duplicated code and its replacement with common code. Among other things, this work simplifies the handling of differences within the ARM architecture itself. Through the use of the common struct dma_map_ops, an architecture can provide a set of mapping operations specific to a given situation - different devices can have different DMA operations, for example.

But there is more to ARM's DMA implementation than the common interface; ARM's API has special functions like:

    void *dma_alloc_writecombine(struct device *dev, size_t len, 
				 dma_addr_t *dma_addr, gfp_t flags);

This function allocates a DMA buffer with "write combining" attributes, meaning that data written to that memory (by the CPU) may be delayed by the memory hardware and flushed out in batches. Use of write-combining memory can yield significant performance improvements for some device types, but this memory clearly has to be handled carefully so that deferred writes don't get mixed up with accesses by the device. A number of drivers use this function, but only one other architecture (avr32) provides it.

ARM also has special functions for mapping DMA buffers into user space:

    int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
			  void *cpu_addr, dma_addr_t dma_addr, size_t len);

On most architectures, memory-mapping a coherent buffer requires no special handling, so the generic DMA code does not provide any special support for this operation; only one other architecture (PowerPC) has felt the need to add this function.

Clearly, bringing the ARM DMA API into line with common code will require some way of handling these special functions. The fact that, for each of the above functions, one other architecture has added an implementation indicates that ARM, as strange as it is, is not alone in needing an expanded API. So the logical thing to do is to move support for these functions into the common DMA core implementation.

That could be done by adding new alloc_writecombine() and mmap_coherent() functions (and, yes, mmap_writecombine() too) to struct dma_map_ops. As the number of combinations of operations and memory attributes grows, though, the size of that structure will grow as well. Marek decided to take a different approach; his patch removes the existing alloc_coherent() and free_coherent() members, replacing them with:

    void* (*alloc)(struct device *dev, size_t size, dma_addr_t *dma_handle, 
		   gfp_t gfp, struct dma_attrs *attrs);
    void (*free)(struct device *dev, size_t size, void *vaddr,
		 dma_addr_t dma_handle, struct dma_attrs *attrs);
    int (*mmap)(struct device *dev, struct vm_area_struct *vma, void *cpu_addr,
		dma_addr_t dma_addr, size_t size, struct dma_attrs *attrs);

As it happens, struct dma_attrs already exists in current kernels. It is not heavily used, though; there are currently only two attributes defined (described in Documentation/DMA-attributes.txt) that seem to only be implemented in the ia64 and PowerPC/Cell architectures. Only one of them (DMA_ATTR_WRITE_BARRIER) seems to actually be used, and in only one place (the InfiniBand code). But the mechanism already exists, so adding more attributes seems like a better approach than adding a new way to express things like "write combining." Marek's patch adds the convention that a null attrs pointer means "coherent," then adds attributes for noncoherent and write-combining mappings. The various allocation functions can then be replaced with:

    void *dma_alloc_attrs(struct device *dev, size_t size, 
			  dma_addr_t *dma_handle, gfp_t flag, 
			  struct dma_attrs *attrs);

This function can be used to request a mapping with any set of attributes that the underlying platform may support; similar functions exist for freeing and memory-mapping DMA buffers. Marek's patch does not extend this functionality into other architectures - even those that have added functions similar to those used by ARM - but that seems like an obvious next step.

Once that is done, Marek can get to what was perhaps his real goal: adding support for per-device I/O memory management units (IOMMUs) to the ARM DMA API. Some hardware has a separate IOMMU built into it that cannot be used for other devices, so the IOMMU cannot be made available to the system as a whole. But it is possible to attach a device-specific dma_map_ops structure to such devices that would cause the DMA API to use the IOMMU without the device driver even needing to know about it. And that, of course, leads to simpler and more reliable code.

Prior to this work, IOMMU awareness had been built into specific drivers directly. But that caused opposition at review time; drivers written in that way cannot really be merged into the mainline. When he talked about this work at LinuxCon Prague, Marek passed on a few lessons that he had learned from the experience. The first of those is that one should always use existing APIs whenever possible. Every developer thinks they can do something better; that may or may not be true, but using the common code works out better in the long run. But, he said, developers should not be afraid of extending core interfaces when the need arises. That is how problems get solved and how the core gets better. The final lesson was "expect it to take some time" when one has to solve problems of this nature.

On the subject of time: it is not clear when this work might make it into the mainline. It has not yet really been submitted for inclusion; the current patches have some obvious work that needs to be done before they are ready. But Marek, after a number of tries, appears to have gotten past the serious technical objections and is now working on getting the details right. So, while one should follow his advice and expect it to take some time, the value of "some time" should be approaching a reasonably small number.

Comments (none posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 3.2-rc2 . (November 15, 2011)

• Thomas Gleixner: 3.2-rc1-rt1 . (November 14, 2011)

• Thomas Gleixner: 3.2-rc1-rt2 . (November 15, 2011)

• Greg KH: Linux 3.1.1 . (November 11, 2011)

• Greg KH: Linux 3.0.9 . (November 11, 2011)

• Thomas Gleixner: 3.0.9-rt25 . (November 14, 2011)

Core kernel code

• Pavel Emelyanov: Introduce the cloning with pids functionality . (November 10, 2011)

• Srikar Dronamraju: Uprobes patchset with perf probe support . (November 10, 2011)

• Thomas Gleixner: timekeeping: Decouple xtime_lock from xtime seqcount . (November 14, 2011)

• Glauber Costa: Provide cpuacct functionality in cpu cgroup . (November 15, 2011)

Development tools

• Gleb Natapov: KVM in-guest performance monitoring . (November 10, 2011)

• Johannes Berg: tracing: add trace console . (November 16, 2011)

• Alessandro Rubini: debugfs: add tools to printk 32-bit registers . (November 16, 2011)

Device drivers

• Ricardo Ribalda Delgado: Add spi support for CMA3000 driver . (November 10, 2011)

• Lin Ming: ata port runtime power management support . (November 10, 2011)

• oskar.andero@sonyericsson.com: input: add driver support for Sharp gp2ap002a00f proximity sensor . (November 10, 2011)

• Rafael J. Wysocki: PM / Domains: Per-device callbacks and PM QoS . (November 14, 2011)

• Linus Walleij: pinctrl: add a generic pin config interface . (November 14, 2011)

• j.glisse@gmail.com: ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator . (November 14, 2011)

• Tomasz Stanislawski: v4l: introduce selection API . (November 14, 2011)

• Patrick Dickey: Add PCTV-80e Support to v4l . (November 14, 2011)

• Manjunath Hadli: RFC for Media Controller capture driver for DM365 . (November 14, 2011)

• Harini Jayaraman: spi: QUP based bus driver for Qualcomm MSM chipsets . (November 14, 2011)

• Jesse Barnes: drm: add plane support v2 . (November 16, 2011)

• Jayachandran C.: i2c: Support for Netlogic XLR/XLS I2C controller. . (November 16, 2011)

Filesystems and block I/O

• Mandeep Singh Baines: dm: verity target . (November 10, 2011)

• Amerigo Wang: tmpfs: add fallocate support . (November 15, 2011)

Memory management

• Christoph Lameter: slub: irqless/lockless slow allocation paths . (November 14, 2011)

Networking

• Neil Horman: net: Add network priority cgroup . (November 14, 2011)

• Jiri Pirko: net: introduce ethernet teaming device . (November 14, 2011)

Architecture-specific

• Fenghua Yu: x86: BSP or CPU0 online/offline . (November 14, 2011)

• Catalin Marinas: ARM: Add support for the Large Physical Address Extensions . (November 14, 2011)

• Mahesh J Salgaonkar: fadump: Firmware-assisted dump support for Powerpc. . (November 15, 2011)

Security-related

• Lukasz Sowa: cgroup: syscalls limiting subsystem . (November 14, 2011)

Virtualization and containers

• Michael S. Tsirkin: virtio-spec: flexible configuration layout . (November 14, 2011)

• Krishna Kumar: [ver3 PATCH 0/6] Implement multiqueue virtio-net . (November 14, 2011)

Page editor: Jonathan Corbet

Distributions

Fuduntu: A small distribution making it big

The Fuduntu distribution is just over a year old, and its first release had a modest but respectable ten thousand downloads. However, with the growing interest in alternatives to GNOME 3 and Ubuntu's Unity, the new 14.12 release is receiving more notice. It's easy to see why: using borrowed tools, Fuduntu tweaks a GNOME 2 desktop to roughly resemble both GNOME and Unity, while offering an unusual but highly serviceable selection of applications and customization tools. The result is a distribution that, although designed for netbooks, works well on larger screens as well.

With the motto "Punning Name, Serious Distro," Fuduntu was founded by Andrew "fewt" Wyatt on November 7, 2010. "The very first version," Wyatt told Distrowatch recently, "was nothing more than Fedora 14 with a few tweaks and packages that I normally installed on my computer(s) wrapped up into a live DVD for me to use to install everything on my second computer."

Since then, Fuduntu has matured dramatically. From Wyatt's private convenience, it has grown to a project with a regular team of eight, each of whom has a voice in development decisions. It now has an end user's license agreement similar to Red Hat's, a three-server system for rolling out security and regular package releases, and a quarterly release cycle. Recently, too, it has started hosting its own repositories, instead of relying on Fedora 14's.

Looking back on the previous year with obvious satisfaction in the release announcement, Wyatt declared: "We have grown astronomically both in terms of the community, and in terms of mindshare."

Taking the middle road

Asked by LWN what is implied by the name, Wyatt replied:

What Wyatt did not say (but is obvious from the design), is that Fuduntu's middle way includes avoiding the radical and sometimes controversial changes introduced by GNOME 3.x and Ubuntu's Unity shells.

Fuduntu uses Fedora's Anaconda installer and, until recently, the Fedora 14 repositories, but its default appearance is all its own. Specifically, Fuduntu uses GNOME 2.32 with the already existing Avant Window Navigator in place of a bottom panel. A combination of a Favorites menu and a task manager, this dock is reminiscent of both GNOME 3's dash and Unity's launcher, and can even be configured to give the illusion of a 3-D appearance via a combination of perspective, spotlighting, and shadows.

The difference is that, unlike its counterparts on other desktops, Avant is highly configurable. Like the classic GNOME panel, its position and size are adjustable. So, too, are its icons, theme, auto-hide capabilities, and other behaviors. In addition, Avant supports its own set of applets, some similar in function to the ones on the panel, and others unique, such as the media player buttons.

Other standard features, such as virtual workspaces, are available from panel applets, but are not enabled by default. The overall effect is an incremental improvement in the classic GNOME 2 series. The result is an appealing simplicity that might leave you wondering why so much effort was invested in GNOME 3 or Unity when a similar result could be achieved simply by creative borrowing.

Rethinking applications and configuration

Besides the appearance, the other factor that makes Fuduntu stand out is the selection of default applications. Like a number of distributions, Fuduntu licenses Adobe Flash and the Fluendo MP3 codec, neither of which costs anything, but requires yearly approval from their manufacturers before distributing. However, unlike most distributions derived from a major one, Fuduntu does not simply dump the standard GNOME applications into its default installation. It includes a few GNOME standards, such as Banshee, Nautilus, and Tomboy, but other choices suggest a thoughtful awareness of the range of alternative possibilities.

For instance, network applications are represented by the Chromium browser and a link to GoogleDocs in place of an office suite, as well as the DejaVu backup tool and Dropbox, the cloud storage system. Others you might have only heard of (if at all), such as the screen capture application Shutter, or Remmina, the remote desktop client.

However, where Fuduntu's selection is most welcome is the configuration options. One of its default applications is Ailurus, a combination package installer and graphical GNOME configuration tool. Scan through the System menus, and you soon discover more, including tools for selecting Nautilus scripts and Nautilus Actions to enhance the file browser. You can also use the Bottom Panel Chooser to select the type of panel you want, or Jupiter to control power and hardware.

All these controls add up to the most configurable default GNOME desktops that I have ever encountered. Yet, because of the simplicity of Fuduntu's appearance, the impression is not one of clutter, but of a desktop that appeals — unlike recent versions of Fedora and Ubuntu — to all levels of users. The advanced tools are in the menus if you can appreciate them, but you can just as safely ignore them if you prefer.

Viability

With an update of the familiar GNOME 2 series and a high degree of configurability, Fuduntu has a simple, yet powerful formula for success. Yet, like all small distributions, Fuduntu raises some basic questions — namely, can it survive? Just as importantly, what are its future plans?

In the best sense of the word, Fuduntu could still be called an amateur's distribution, in that Wyatt describes the motivation of the project members as "to have fun and to build a fantastic desktop that works for us." However, the price of popularity is increased costs, including new dedicated build hosts.

Coping with its unexpected popularity, the Fuduntu team tries to minimize costs by hosting the project on SourceForge and by what Wyatt calls a "lights out policy," explaining that "there is a script that runs on each of the build hosts, and, if certain criteria are met (no users or screen sessions, [or an] idle processor), it will automatically power off after testing for the conditions three times over a period of 15 minutes."

These efforts, Wyatt says ensure that "My monthly out of pocket spending is reasonable. The project expenses are mostly covered through Google AdSense, and project donations."

Having just switched from relying on Fedora 14's repositories to hosting its own, Fuduntu's immediate priority is to add source packages to its offerings. However, in the longer term, the distribution's policy seems to consist of "wait and see", as Wyatt described:

In other words, Fuduntu seems, both financially and philosophically, likely to continue much as it has been for the immediate future. Although its long term development is less clear, for now Fuduntu seems to be delivering what both its contributors and users want.

Comments (2 posted)

Brief items

Distribution quotes of the week

-- Thomas Vander Stichele

-- Mark Rushing

Comments (14 posted)

Android 4.0 source released

It has happened: the source for Android 4.0.1 ("ice cream sandwich") is being pushed to the repositories. "This release includes the full history of the Android source code tree, which naturally includes all the source code for the Honeycomb releases. However, since Honeycomb was a little incomplete, we want everyone to focus on Ice Cream Sandwich. So, we haven't created any tags that correspond to the Honeycomb releases (even though the changes are present in the history.)" Anxious downloaders should try to wait, though, until the Android folks have signaled that the push is complete.

Comments (52 posted)

Mandriva Linux Powerpack 2011

Mandriva has released Mandriva Powerpack 2011. Included in the announcement is the news that Mandriva is now aiming for a one-year period between major releases, with updated versions released every 6 months. "Quicker, easier and more secure than ever, Mandriva Linux offers new functionalities which revolutionize the desktop. Mandriva Linux Powerpack 2011 is the most advanced Linux Operating System to date, a genuine concentration of technologies and innovations. It supports a wide panel of hardware configurations, making it a stable base for users. It combines simplicity with conviviality in an intuitive, high performing environment. It is the ideal distribution for all users, from the beginner to the most advanced."

Comments (none posted)

openSUSE 12.1 released

openSUSE 12.1 has been released. There's a lot of new stuff, much of which has the "cloud" label attached to it, but also including the Go programming language, GNOME 3.2, color management in both GNOME and KDE, and more. "openSUSE 12.1 includes Snapper, a new and unique tool that employs the snapshot functionality in btrfs to allow users to view older versions of files and revert changes. The integration of Snapper into the zypper package manager allows users to roll back system updates and configuration changes." Some more information can be found on the openSUSE 12.1 page and the product highlights page.

Full Story (comments: none)

Oracle Solaris 11

Oracle has announced the release of Oracle Solaris 11. "Oracle Solaris 11 is designed to meet the security, performance and scalability requirements of cloud-based deployments allowing customers to run their most demanding enterprise applications in private, hybrid, or public clouds." See the release notes for more information.

Comments (2 posted)

First release candidate for UCS 3.0 is now available

Univention Corporate Server (UCS) 3.0 RC, a distribution based on Debian squeeze, is available for testing. "UCS 3.0 will be the first commercial product to integrate "Samba 4", the next generation of Open Source software for the provision of Microsoft-compatible services for Windows clients. With UCS 3.0, it is even possible to construct more complex Active Directory domains and provide the services required for the operation of new Microsoft Windows operating systems such as Kerberos authentication and the assignment of group policies. Alternatively, the domain services already included in UCS 2.x based on Samba 3.x can also continue to be used."

Full Story (comments: none)

Distribution News

Debian GNU/Linux

bits from the DPL for October 2011

October has been a busy month for Debian Project Leader Stefano Zacchiroli. Highlights include the New Member process, Ubuntu Developer Summit, and "Easy Hacks" and Google Code-In. "Another interesting evolution on [the Ubuntu] front is that Ubuntu is going to deprecate their (universe) package review platform (REVU) and converge with us on mentors.d.n."

Full Story (comments: none)

Fedora

Cooperative Bug Isolation for Fedora 16

The Cooperative Bug Isolation Project (CBI) is now available for Fedora 16. "CBI is an ongoing research effort to find and fix bugs in the real world. We distribute specially modified versions of popular open source software packages. These special versions monitor their own behavior while they run, and report back how they work (or how they fail to work) in the hands of real users like you. Even if you've never written a line of code in your life, you can help make things better for everyone simply by using our special bug-hunting packages."

Full Story (comments: none)

Elections update and town hall meetings schedule

Fedora elections for seats on FAmSCo, FESCo, and the Fedora Board are underway. Candidate answers the election questionnaire have been posted and Town Hall meetings have been scheduled.

Full Story (comments: none)

openSUSE

Continuous Integration testing for openSUSE

Development of Open Build Service (OBS) is test-driven and major parts are covered by a comprehensive test-suite. These tests have, in the past, been run by a custom shell-script on a local machine that wasn't publicly available. The OBS-team has introduced a new public interface for Continuous Integration (CI) testing. "Behind the scenes, we are using Jenkins, probably the most prominent open source CI tool available. Currently, the OBS and osc/osc2 code bases are tested, but we would like to see more openSUSE projects utilize ci.opensuse.org. In the future, we also want to test the RPMs (and appliances) for new OBS releases."

Comments (none posted)

Newsletters and articles of interest

Distribution newsletters

• DistroWatch Weekly, Issue 431 (November 14)
• Maemo Weekly News (November 14)
• openSUSE Weekly News 201 (November 12)
• Ubuntu Weekly Newsletter, Issue 240 (November 6)
• Ubuntu Weekly Newsletter, Issue 241 (November 13)

Comments (none posted)

Hertzog: 20 Things to Learn About APT

A free chapter of the Debian Administrator's Handbook is available. This chapter covers the APT family of tools: apt-get, aptitude, synaptic, update-manager, etc. As previously reported, a fundraising campaign is underway to translate the book into English and to make it freely available online. "Thanks to everybody, we have reached our first target and the book translation will happen. But this story is not yet over and we still need your support to reach the second goal, the liberation of the book."

Comments (none posted)

openSUSE 12.1 Arrives: What's New and What Happened to 12.0? (Linux.com)

Joe 'Zonker' Brockmeier takes a look at openSUSE 12.1. "openSUSE is also getting smarter about managing kernel upgrades. With 12.1, Poortvliet told me that Zypper now has an option (which isn't yet the default) to keep an older kernel until the system has successfully booted into an upgraded kernel. This solves the problem of systems being rendered unbootable because of a new kernel that has a hardware conflict of some sort. Right now, it's not the default, but users can enable this so that they can delete the old kernel after a successful boot - or keep up to two old kernels indefinitely. Speaking of kernels, openSUSE 12.1 comes with Linux 3.1. It also features a new init system pioneered by Fedora, systemd."

Comments (3 posted)

Get an Early Taste of Linux Mint 12 (PCWorld)

PCWorld looks at new features coming in Linux Mint 12, due for release later this month. "Linux Mint 12 will ease the transition to the controversial new GNOME 3 desktop by adding a layer on top that lets you use GNOME 3 in a traditional way. MGSE, or Mint GNOME Shell Extensions, is the name of that layer, and it gives users numerous options with respect to GNOME 3. For a full-fledged GNOME 3 experience, for instance, users can disable all MGSE components; conversely, by enabling all of them you'll get a GNOME 3 desktop that's similar to what you've been using before. Alternatively, users can also pick and choose which components they want to enable for a custom-designed "middle of the road.""

Comments (none posted)

Page editor: Rebecca Sobol

Development

Raw photo manipulation with Darktable

The Darktable project released the latest update to its photo editor on November 8. Version 0.9.3 is a minor update to the stable 0.9 series, but I had not spent much time with the application since the 0.7 cycle, so I took a fresh look. There are few surprises in this series; the developers continue to add features designed to enable photographers to develop creative images. As in past releases, there is particular emphasis placed on darkroom styles and techniques that hearken back to pre-digital days — which gives Darktable its own niche, but may not be what the majority of digital camera owners are looking for.

Defining Darktable

Darktable is a self-described "photography workflow application" and raw converter. Even within photography, the term workflow application means different things to different people. To some it means using a single application to perform every step from importing images from the camera, to sorting and editing them, to exporting final images for print or online publication. To others it just means the process of sorting, grading, and batch-processing images. To still others, it is little more than a catchword to draw a line between "professional" and "hobbyist" class programs.

Darktable includes camera offloading and image collection management features, so it can handle most if not all of the steps a photographer might use to turn a shooting session into a finished product (in fact, it is one of the few open source applications that can do tethered shooting using a USB-attached digital camera). Nevertheless, it places far more emphasis on the editing and creative interpretation features than on other steps of the process, which makes it feel like more of a super-powered raw editor than anything else. By comparison, Digikam has significantly more features on the collection-management front, including geolocation, facial recognition, and powerful search capabilities. Darktable will import your image metadata into an internal database, but provides only a rule-based filter to narrow down how much of your collection is visible in the "light table" view at once. Currently Exif is the only metadata format supported, while many other open source tools are now also supporting XMP.

It also provides little in the way of batch-processing, which I consider to be a key workflow feature. In other raw editors, such as Rawstudio, you can mark individual images for batch export as you edit, and when finished start the processing queue with one click. Currently in Darktable, you still need to return to the light table view, select the images you wish to export with the cursor, and use the "export selected" widget. You can work around this restriction slightly by using the tagging or star-rating features to flag the images you wish to batch process later, but that limits your ability to use tags or ratings for other purposes.

Even on fast systems, the multiple sets of image transformations required to export each photo can add up with even a small handful of high-resolution images. Being able to queue these operations for later — ideally even with distinct export parameters and destination folders — is a time saver. Darktable, like most raw converters, shows you a preview image of each correction you make in the editor, but it does not perform the full-size operations until file export time.

Still, none of that is to say that Darktable is not a capable application — it just provides more power to the image-creation pipeline than it does to other steps. But if you have a very large collection of photos to manage, you will probably prefer to use Digikam to juggle them until Darktable beefs up its suite of library-management tools.

The grand tour

I have not found an explicit history of the application's name, but it is clearly a portmanteau of darkroom and light table, which are its two primary modes (and, of course, the inverse of Adobe's "Lightroom"). Light table mode is used to sort images, including importing them from camera or disk (thankfully, Darktable does not attempt to copy images already on disk into its own special folder, rather it scans them and ingests the metadata for its database), tagging and editing image metadata, and exporting to common output formats like TIFF and JPEG. It can export in 16-bit-per-channel mode to formats that support it, and includes support for the OpenEXR high dynamic range file format, as well as direct export to Flickr, Picasa Web Albums, and HTML galleries.

Minimal editing capabilities (such as rotation and applying pre-defined "styles") are available in the light table mode; all serious editing is done in the darkroom mode. Both modes use a custom dark, neutral-gray UI theme rather than the system GTK+ color scheme. This is a growing trend among photo and creative applications, enough so that GTK+ implements a prefer-dark-theme property that applications can use to automatically request a dark variant. Darktable implements its own color scheme, however.

Switching to darkroom mode is done by double-clicking on an image thumbnail or by clicking on the mode text-label in the upper-right corner. This is where Darktable begins to diverge from the UI conventions followed by most other raw editors. The others tend to provide a long, scrollable column of image-adjustment tools down the left- or right-hand side of the editor, and you can adjust any of the settings exposed or leave them as-is. Darktable uses a plugin system instead; each of the adjustment tools is a separate plugin that you must activate in order to manipulate it.

The available plugins appear in a grid at the bottom of the right-hand column; when activated each plugin's controls appear in the main tool strip, but in order to apply the plugin to the selected image, you must also click on a "power button"-style icon next to the plugin name. That is more steps than should really be necessary, and I think it reflects the underlying design of the code base more than it does a particular UI theory. Darktable has a fast image-processing core, but all of the editing features are implemented as separate plugins. That makes for faster development, but in this case it complicates things for the end user.

What is more frustrating is that Darktable has several more peculiar UI quirks that make its features hard to discover. First, all of the aforementioned plugins are shown in an unlabeled grid, one in which each icon is a slick-looking minimalist logo, and all of which look virtually indistinguishable. You will have to hover the mouse over every icon long enough for its tooltip label to materialize. It would be simpler to list all of the plugins in a menu, but Darktable (deliberately?) has no menus. That has its own side-effects, such as making the preferences dialog the only place to discover keybindings (more on that below...). In other parts of the interface, Darktable uses text labels instead of icons (such as the selection buttons), which makes me suspect that the symbolic plugin icons are a purely cosmetic choice.

The Darktable window also uses triangular "expander" buttons on the top, bottom, left, and right edges to selectively show or hide sub-panes (such as the tool strip or navigation/image-info box). That is not bad in and of itself, but the triangles stay on the edge of the screen whether the pane they control is collapsed or not. As a result, it was about an hour before I discovered that the arrow at the bottom edge did not control the filmstrip widget also on the bottom of the screen, but instead toggled the visibility of a one-line color-selector tool which, at the bottom of the window, is nowhere near the other tools. The filmstrip can be hidden, but only by opening the preferences dialog. The preferences dialog, though, is only accessible through an unlabeled "gear" icon placed next to the image-sort-field selector, which itself is only visible when you expand the top-edge window pane.

A good UI-review or sprint with some usability experts would fix a lot of these issues and make Darktable significantly easier to navigate. On the other hand, some of the actual image-adjustment tools have very perplexing interfaces of their own that I am less sure how to fix, because I am still not sure I understand them. Most are normal sliders, spinboxes, or selection menus, but a few head in different directions. For example, the color-correction widget is a square grid of colors, into which the tooltips tell you to "draw a rectangle to give a tint." It is clear that whatever colors you catch with your rectangle somehow affect the tint, but exactly what they do is a mystery (a shift? a rotation? remapping the entire color space?) — and because the grid is unlabeled, you do not have precise control over the effect. Furthermore, because of the grid's fixed orientation it is impossible to draw rectangles around certain color combinations, such as blue-to-orange.

The "color zones" plugin's widget is arguably more confounding. It has three separate grids, one each for lightness, saturation, and hue, all unlabeled, and each incorporating a flexible adjustment curve, a set of control points bound to the bottom edge, a circle that hovers around the cursor, and a fluttering gray polynomial curve that surrounds the circle but changes in size and shape depending on some combination of the circle's diameter and the shape of the adjustment curve. Confused? You are not alone. Neither the online documentation nor the PDF manual explain the design at work; you can learn that the circle is a "virtual color filter" and that you can control it's diameter with the mouse scroll wheel, but little else. Simply labeling the UI elements used in these widgets would be a good start, but the lack of clear documentation makes them unusable.

Image is everything

All user interface issues aside, I do like Darktable, both for what it can do, and how quickly it can do it. It provides tools that allow you to focus on creating the look that you want in the output image, rather than exposing only low-level adjustments. Other raw editors give you control of de-noising and exposure; Darktable does, too, but it also has a zone system plugin and the ability to do split-toning (which Photoshop veterans will recognize as "duotones").

Among the effects plugins are several common photographic tools, such as a graduated neutral-density filter. In the on-camera world, this is a lens filter that darkens one part of the image, then fades naturally out — it is what people routinely use to bring the too-bright midday sky back into the same range as the ground. There are also composition guides (golden ratio, rule-of-thirds), lensfun-based distortion corrections, grain simulation, and a "fill light" plugin. For the most part, the controls are easy to use and the changes are rendered on the preview image with little noticeable lag.

The application also provides more control than its competition over common tasks like converting an image from color to grayscale. Other programs do this with a simple switch to monochrome — sometimes offering the choice between using the slightly-different luminosity or brightness value of each pixel to determine its final tone. Darktable tries to emulate the control provided by shooting in black-and-white in the first place, using various filters to alter the light. In his demonstration videos, developer Pascal de Bruijn said that he used actual black-and-white film to calculate the characteristic curves used in the presets (although he did not specify the type of film).

Granted, to a non-photographer, some of the plugins implemented in Darktable may not mean much at first, but they are still valuable. For example, there is a "Velvia" plugin which is intended to emulate the distinctive look of Fujichrome Velvia film, which pulled extra saturation out of normally neutral scenes. You could achieve the same effect by manually manipulating the saturation settings, but doing so without blasting-out cartoon-like colors is difficult. People who have never shot Velvia film and never care to start will probably just be happy to have a simple-to-use saturation preset.

The list of actual changes in the 0.9.3 series is modest; there is an "invert" plugin specifically built for scanning and converting film negatives, a new de-noising filter, and new presets for several of the existing tools (such as the "real world" black-and-white film conversion). Two new file import features will save obsessive photographers some time: a checkbox to recursively import a tree of directories, and a checkbox to ignore JPEG files and only import raw images.

There is also a new row of buttons above the existing plugin categories (which were generic groupings like "color," "correct," and "effect"). The "active" button shows you only the plugins that are currently activated, which can help if you turn on too many and get lost, and the "favorite" button allows you to mark your own custom set of plugins for quick access. As the number of plugins continues to grow, this will only be more valuable. Minor enhancements have landed for other tools, such as the crop/rotate plugin, which now works more like other image editors, allowing you to draw a line on the screen that should be horizontal and have Darktable automatically make the proper adjustment.

This release will probably not shake off Darktable's reputation as a tool tailored for photography geeks. The image manipulation functions are maturing, which you can see in the accumulation of carefully crafted presets. They allow users to quickly apply effects without having to understand the complex curves built in to the tools themselves. However, if the application is ever going to break into mainstream acceptance, it will have to undertake a serious attempt to fix its user interface. The tool grids, menu-free design, and everything-in-a-single-window approach may look slick, but they slow down the user's actual completion of tasks, which is an unforgivable sin among GUIs.

Every raw converter on the market struggles with the problem of how to fit a dozen adjustment widgets onto the screen along with the image they affect. Sure, none of them has solved the puzzle outright, but going-it-alone in user interface design rarely works either. Even Blender — which for years argued that everyone would eventually adapt to its strange conventions if they only sat down and used it long enough — finally undertook a redesign in the 2.5x series. Like Blender, Darktable offers a unique set of features, they just aren't as easy to utilize as they should be. Some work on that front would grow the user base, and hopefully allow the team to build out other areas of photography workflow, such as collection management and batch processing.

Comments (3 posted)

Brief items

Quotes of the week

-- Dan Williams

-- Alan Cox

-- Tom Christiansen

Comments (none posted)

IMAPClient 0.8 released

Version 0.8 of IMAPClient, the "easy-to-use, Pythonic and complete IMAP client library with no dependencies outside the Python standard library" has been released. New features include OAUTH support, full NOOP support, IDLE support, Sphinx-based documentation, folder renaming, and more.

Full Story (comments: none)

Introducing Mozilla Conductors

Many projects have grappled with the problem of improving the quality of communications on their mailing lists, IRC servers, and so on. The latest effort in this area is "Mozilla Conductors," an effort introduced by Mitchell Baker and to be headed up by Stormy Peters. "How do we improve our ability to disagree vehemently and simultaneously remain civil and productive? As in so many things, the answer is to empower people who are already doing some of this and to explicitly make this a valued contribution."

Full Story (comments: none)

Open64 5.0 released

Open64 is a GPLv2-licensed compiler for the x86 and Itanium architectures with a long history; the project has just announced the 5.0 release. Much of the development work going into this release seems to be aimed at the exploration of interesting optimization techniques, but there doesn't appear to be a lot of information out there on how Open64 compares to other open compilers. The Open64 wiki has some more information about the project.

Comments (21 posted)

SciPy 0.10.0 released

SciPy, a collection of mathematics, scientific, and engineering tools for Python has released version 0.10.0. " SciPy 0.10.0 is the culmination of 8 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation." Some of the new features include a new build system (Bento), sparse eigenvalue problem solver functions, support for simulating discrete-time linear systems, and more.

Full Story (comments: none)

Tomahawk 0.3

Version 0.3 of the Tomahawk media player is now available. New features include a "one-click" resolver gallery, various types of popularity charts, "lazy lists," and more.

Comments (none posted)

Valgrind-3.7.0 is available

Version 3.7.0 of the Valgrind runtime analysis tool is now available. New features include preliminary support for Android on ARM, support for IBM z/Architecture (s390x) running Linux, MacOSX 10.7 and XCode 4 support, better memcheck tests, increased performance in Helgrind, and more. See the release notes for all the details.

Full Story (comments: none)

Newsletters and articles

Development newsletters from the last week

• Caml Weekly News (November 15)
• Perl Weekly (November 14)
• PostgreSQL Weekly News (November 13)

Comments (none posted)

Federico Mena-Quintero talks about the Document-Centric Desktop (der Standard)

der Standard interviews GNOME co-founder Federico Mena-Quintero. "The latest thing is that now things have to go through the design team first, and I don't think that is a good thing; there should not be a central body of control that decides how things are done, because that simply doesn't scale. And it also doesn't teach people in how to do design properly. I really would like to move to a model where, instead of having a central body of people who can veto things in or out, we can have a shared understanding of what constitutes good design and implementation. And then, we can evaluate proposals on all their merits and modify them instead of just saying, 'Oh no, I don't like this, because it doesn't follow my design criteria'."

Comments (9 posted)

Introduction to Kdenlive (opensource.com)

Opensource.com has posted a lengthy introduction to kdenlive (a video editor) as the beginning of a series of articles on this tool. "A good video editor is one that is suitable for anyone wanting to edit video, with powerful features that enable the video professional to do any task required of the job, yet with the simplicity that allows a hobbyist to quickly cut together footage off of a phone or point-and-click camera. Kdenlive can be both of those things, but regardless of the scope of your video project, there are right and wrong ways of doing things. Over the course of five articles, we will review the practical usage and the common set of best practices that will ensure your projects are successful."

Comments (none posted)

Page editor: Jonathan Corbet

Announcements

Brief items

Court rejects AVM's claims opposing third party modifications of GPL software

The gpl-violations.org web site has the news that the court ruled against AVM in its bid to restrict Cybits (and anyone else) from modifying the GPL-covered code in home routers. "Although the written reasoning of the decision is not available yet, it is clear that the court rejected AVM's claims according to which no third party shall be permitted to alter their products' firmware, even if the GNU GPL components are concerned. Thus, Cybits or anyone else may perform such modifications. Furthermore, under the judgement, Cybits is not prohibited from distributing its software that assists users in making and installing modifications to GNU GPL licensed software (Linux kernel used in the Fritz!Box device)." LWN recently covered a talk about the case.

Comments (10 posted)

FSFE: Swedish activist receives Nordic Free Software Award 2011

The Free Software Foundation Europe (FSFE) reports that Erik Josefsson is the winner of the Nordic Free Software Award 2011. "From a career as a professional double-bass player, Josefsson gradually moved to full-time activism for freedom in the information society. He founded the Swedish Foundation for a Free Information Infrastructure (FFII Sweden) in 2004. Listed among Sweden's 30 most influential people during the European debate about software patents in 2005, Josefsson is among Europe's foremost defenders of software freedom."

Full Story (comments: 6)

Articles of interest

W3C privacy workgroup issues first draft of Do Not Track standard (ars technica)

Ars technica reports on the availability of W3C's first draft of a Web standard that addresses online privacy. "Mozilla originally introduced the DNT setting in Firefox 4 earlier this year. The feature consists of a simple HTTP header flag that can be toggled through the browser's preference dialog. The flag tells website operators and advertisers that the user wants to opt out of invasive tracking and other similar practices that have become pervasive with the rise of behavioral advertising. Of course, the mechanism just indicates a preference and doesn't actively block tracking activity. The success and efficacy of the DNT header is predicated on voluntary compliance from the Internet advertisers that will have to take steps to implement support for the feature."

Comments (4 posted)

EFF: Hollywood's new war on software freedom and Internet innovation

Here's a release from the Electronic Frontier Foundation on the latest bit of silliness from the US Legislative branch. "No longer content to just blacklist entries in the Domain Name System, this version targets software developers and distributors as well. It allows the Attorney General (doing Hollywood or trademark holders' bidding) to go after more or less anyone who provides or offers a product or service that could be used to get around DNS blacklisting orders. This language is clearly aimed at Mozilla, which took a principled stand in refusing to assist the Department of Homeland Security's efforts to censor the domain name system, but we are also concerned that it could affect the open source community, internet innovation, and software freedom more broadly." US citizens who are concerned about this bill might want to consider communicating those concerns to their congresscritters.

Comments (56 posted)

Barnes & Noble Exposes Microsoft's "Trivial" Patents and Strategy Against Android (Groklaw)

Barnes & Noble has started speaking out about its experience with the patent system in a big way; Groklaw has the full set of documents. "Instead of focusing on innovation and the development of new products for consumers, Microsoft has decided to invest its efforts into driving open source developers from the mobile operating systems market. Through the use of offensive licensing agreements and the demand for unreasonable licensing fees, Microsoft is hindering creativity in the mobile operating systems market."

Comments (31 posted)

Hughes: Introducing the ColorHug open source colorimeter

For everybody who has been thinking that they need to color-calibrate their monitors, but who have not gotten around to getting access to a colorimeter: Richard Hughes has announced the "ColorHug". "This is hardware that measures the colors shown on the screen and creates a color profile. Existing hardware is proprietary and 100% closed, and my hardware is open source. It has a GPL bootloader, GPL firmware image and GPL hardware schematics and PCBs. It's faster than the proprietary hardware, and more importantly a lot cheaper." He is currently seeking enough pre-orders to make an initial run of the hardware. (See this article to learn more about color profiles and how Linux systems can use them). (Thanks to Paul Wise).

Comments (27 posted)

New Books

Making Embedded Systems--New from O'Reilly Media

O'Reilly Media has released "Making Embedded Systems" by Elecia White.

Full Story (comments: none)

New Programmer's Survival Manual--New from Pragmatic Bookshelf

Pragmatic Bookshelf has released "New Programmer's Survival Manual" by Josh Carter.

Full Story (comments: none)

Calls for Presentations

FOSDEM 2012: 2nd call for talks

FOSDEM 2012 will take place February 4-5, 2012 in Brussels, Belgium. The deadline for submissions is December 22, 2011. This announcement is solicting talks for the two cross-distribution devrooms. "Acceptable sessions can be any wide range of things, including talks, BoF sessions, and round tables. Note that for BoFs and round table sessions, the submitter will be considered the 'speaker', who will be expected to introduce the subject and serve as moderator."

Full Story (comments: none)

Upcoming Events

The Linux Foundation Announces Program for Automotive Linux Summit

The Linux Foundation has announced the program for the Automotive Linux Summit taking place November 28, 2011 in Yokohama, Japan. "This one-day event is packed with six keynote presentations from major car manufacturers and the Linux kernel community. It also includes 15 breakout sessions, which will cover best practices for Linux in automotive, HTML5 technology in cars, compliance, and In-Vehicle-Infotainment, among other topics."

Comments (none posted)

SCALE: Design Contest winners named

The Southern California Linux Expo (SCALE) team has announced the winner of the design contest. The winning design, by Brian Beck, will be featured on t-shirts, attendee bags, and other conference materials. Brian will get a free pass to SCALE 10X including airfare and a three-night stay at the Hilton Los Angeles Airport. SCALE 10X takes place January 20-22, 2012.

Full Story (comments: none)

Events: November 24, 2011 to January 23, 2012

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

Date(s)	Event	Location
November 24	verinice.XP	Berlin, Germany
November 28	Automotive Linux Summit 2011	Yokohama, Japan
December 2 December 4	Debian Hildesheim Bug Squashing Party	Hildesheim, Germany
December 2 December 4	Open Hard- and Software Workshop	Munich, Germany
December 4 December 7	SciPy.in 2011	Mumbai, India
December 4 December 9	LISA ’11: 25th Large Installation System Administration Conference	Boston, MA, USA
December 27 December 30	28th Chaos Communication Congress	Berlin, Germany
January 12 January 13	Open Source World Conference 2012	Granada, Spain
January 13 January 15	Fedora User and Developer Conference, North America	Blacksburg, VA, USA
January 16 January 20	linux.conf.au 2012	Ballarat, Australia
January 20 January 22	Wikipedia & MediaWiki hackathon & workshops	San Francisco, CA, USA
January 20 January 22	SCALE 10x - Southern California Linux Expo	Los Angeles, CA, USA

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

Page editor: Rebecca Sobol