LWN.net Weekly Edition for March 31, 2011

Android and Honeycomb

There's been a lot of press—and hand-wringing—about Google's decision to withhold the source code for the latest Android 3.0 release. There have been claims that Google is (or will be) violating various licenses by doing so. While that claim is overblown, there are still reasons to be unhappy about the choice being made here, while recognizing that it is Google's choice to make.

Business Week broke the story that, unlike previous releases, Android 3.0 ("Honeycomb")—targeted at tablet devices—would not be released for several months, possibly not until the next version ("Ice Cream") is completed. The article quoted Andy Rubin, Google's VP for engineering and head of the Android group, as saying that Honeycomb may not be suitable for phones:

The concern seems to be that vendors might take Honeycomb, put it on phones (or other small-screen devices), and create "a really bad user experience". There has certainly been a number of vendors who took previous non-tablet-oriented releases and put them on tablets with varying degrees of success. Google appears to be worried that the Android brand is being tainted by low quality implementations. That may be true, but there are other ways that problem could be prevented.

One obvious choice is the Android trademark, which Google could use to require devices to meet some minimum standards. Google already exercises some control via its Google-branded Android applications (like Market, Maps, and Gmail) that have to be licensed from the company. In order to do that, a device must fulfill the Android Compatibility Definition. But plenty of low-end phone and tablet makers were willing to forgo those applications, take the source code, and run with it—sometimes with less-than-stellar results.

So, Google has found a different way to enforce its will on device makers that do not directly license code from the company: stop providing the source. Since one of the goals of the project was to "keep the GPL out of user space", that means that the Android user space is licensed under non-copyleft terms. But even if it were all covered by the GPL, Google, as the copyright holder, would not be obligated to release the code. Copyright holders are not beholden to the license they provide to others for using their code.

As it is, most of the code is under the Apache Software License or similar terms, which means there is no requirement for anyone to provide source. The big exception, of course, is the Linux kernel, and one would expect that Google is GPL-savvy enough to not withhold that code. For the kernel, though, the interesting parts are not necessarily in Google's kernel tree, as it is the device makers that add support and drivers for their platforms. As we've seen, GPL compliance in Android tablets is rather spotty, at best, so that's where any license problems are likely to be found.

Part of the uproar about Google's decision is based on the somewhat faulty belief that Android was ever a real open source project. There were high hopes early on that it might become one, and, up until now, Google kept throwing its code over the wall to—more or less—continue the open source spirit of the project. But, unlike real open source projects, there were only limited attempts to build a developer community around Android itself, instead, for the most part, there were just the periodic code drops. Much of the effort was aimed at cultivating application developers, which has worked out quite well. It's hard to say for sure, but one might guess that the openness of the Android code played a role in how quickly the platform was embraced by application developers.

One could argue that Google needed to keep Android development in-house, so that it could keep up with the incredibly fast-paced smartphone market—and that may be true. One could certainly point to MeeGo as a counterexample of sorts, and one that has yet to really produce any tangible results in the form of products for sale. MeeGo clearly has a development community slowly growing around it, even though it is dominated by two (now one, really) companies. While MeeGo is much more upstream-oriented than Android, its governance has been largely top-down. So far, Google's model has been much more successful, but MeeGo is really only a year old at this point.

Google has made a lot of noise about how "open" Android is, including things like Rubin's famous tweet in response to Steve Jobs: "The definition of open: 'mkdir android ; cd android ; repo init -u git://android.git.kernel.org/platform/manifest.git ; repo sync ; make'" For Honeycomb, at least for the next few months, that will no longer be true, which is enough to sour some folks on the Android platform as a whole.

Google has evidently weighed the benefits that it gets from opening the Android code—bug fixes, enhancements, good public relations—and found that it was not enough to overcome its concerns. It is unfortunate that we won't be able to see what the CyanogenMod folks (and others in the "mod" community) might have done with Honeycomb, at least for a while yet. There are likely some low-cost tablet makers that could have done interesting things with it as well. While Google claims to be concerned about "user experience", it's pretty hard to read this move as anything other than a tightening of control over the platform. Hopefully, this is just a blip, and things will return to "normal" with "Ice Cream", but the damage may have already been done by then.

Over the last few weeks, we have defended the behavior of several companies (Red Hat and Google) when they have been faced with accusations of license violations. In all of these cases, though, one does not have to like what the company is doing to recognize that it isn't a violation of any licenses. Once again, we would much rather see Google keep the Android project open—or make it even more open—but recognize that it is well within its rights not to do so. With any luck, other open source projects will show the way such that Google finds it in its interests to open up Android further. Time will tell ...

Comments (24 posted)

Here be dragons: PostGIS 2.0 adds 3D, raster image, and topology support

The PostGIS geographic database system is nearing its 2.0 release, a major update that adds several significant new capabilities. PostGIS is an extension to the PostgreSQL database manager that implements GIS-specific data types and functions. Equally important, though, is the fact that a wide range of other open source geographic information system (GIS) projects can use PostGIS as a back-end data source, including GUI applications and servers. This 2.0 release is poised to be an important milestone not just for speed and stability reasons, but because it extends the database into three new areas: raster data, topology, and 3D.

PostGIS adds support for geometric primitives (points, lines, polygons, as well as "collections" and other data structures of all three), plus reading, transforming, and writing a vast array of standard geospatial data formats. GIS applications often require special operators for calculating distances and areas, unions, intersections, and other set functions, along with specialized types of searches.

PostGIS implements this functionality by adhering to the Open Geospatial Consortium's Simple Feature Access for SQL standard, although the project does not pay for the compliance testing necessary to advertise itself as an official implementation. PostGIS has been in active development since 2001, and built up a notable library of supporting GIS applications, including GRASS GIS, gvSIG, and MapServer; there are even commercial connectors available to tie proprietary GIS products into PostGIS databases.

Still, in all this time, PostGIS has focused on what you might call traditional, vector-based, 2D geometry. One should not see this as a weakness; the majority of GIS applications are 2D and vector-based. Vector-based data encodes geographic features as shapes: points and polygons on a map projection, lines connecting features, and so on.

Raster

There is, however, a lot of data available as raster imagery, too — aerial and satellite photographs, for example, which can be geocoded so that they can be properly aligned and transformed to fit onto a map. In recent years, the PostGIS community worked on raster support via an add-on package originally named WKT Raster, which was later renamed PostGIS Raster.

With 2.0, its functionality will be fully integrated into the main application. Raster images are supported in special raster tables, which can be loaded from any format supported by the Geospatial Data Abstraction Library (GDAL), and exported to any GDAL-supported format. The list of supported formats is constantly growing, but at the moment the GDAL project lists more than 120.

Naturally, loading and exporting is not the real work of supporting raster images in addition to vectors, so PostGIS 2.0 adds a slew of functions for analyzing and operating on the data inside the pixels. Rasters can be "extruded" into geometry (for example, turning regions of one color in the raster image into a polygon), averaged, and otherwise inspected. Rasters can be operated on with existing functions (such as calculating where they intersect with vector geometric shapes). It will also be possible to edit imported rasters in-place in the database, which opens the door to all sorts of transformations.

The third dimension

There is also no shortage of 3D data that could prove interesting to examine, if the data types to store it and the functions to transform it are available. PostGIS 2.0 adds extensive support for 3D, starting with two geometry types: polygonal surfaces and triangular irregular networks (TINs). Polygonal surfaces are just what you imagine them to be: three-dimensional surfaces defined by connected polygons. TINs define surfaces entirely with triangles, but the size of the triangles is flexible — somewhat like a multi-resolution mesh in a 3D modeling program. A TIN can use very few triangles to describe flatter areas of the map, and more to describe important features. In both cases, support for the new geometry consists not just of the basic data types, but the support operators to do recurring tasks like finding areas (and volumes) of regions in the new format.

In addition to the new geometry types, the existing spatial indices have been made 3D-aware, and a library of 3D-functions added. This will allow GIS users to calculate distances in three dimensions, find 3D intersections of lines and shapes, and return 3D bounding-boxes or calculate complex things like 3D shortest-paths.

The most straightforward application of 3D in GIS is to model landscape features in three dimensions, but there are more. Many other kinds of geo-coded data could be imported into a 3D PostGIS database for modeling and analysis. Consider calculating line-of-sight visibility between buildings, radio wave propagation, or flight vectors, for example. All involve familiar GIS operations, in 3D, even though they are not strictly "mapping"-related tasks.

How best to output 3D data is a question that remains largely the domain of the front-end application (more on that a bit later...), but PostGIS 2.0 is adding support for direct output of 3D data to the XML-based X3D format. X3D is defined by the Web3D Consortium, which is working hard to get the format accepted into HTML5. Whether or not HTML5 ever allows the inclusion of in-line X3D scenes within page content, however, the format is likely to get supported in <canvas> elements or as embedded objects.

Topology

The last major extension of PostGIS functionality in the 2.0 release is support for topology. In GIS terms, topology is not a reference to topographical maps. Rather, it means supporting data types and functions that implement mathematical graphs. In other words, instead of points, lines, and polygons, topology uses nodes, edges, and faces — potentially even directed and/or weighted edges.

Transforming vector geometry into topology data makes what was a collection of shapes into a mathematical representation of the scene, including how nodes and regions are connected. The human eye can make those connections instantaneously, but the database requires explicit support for expressing them. Incorporating the topological version of a map layer in the database allows the application to perform path finding, routing, and flow analysis that cannot be done on raw geometry.

The canonical example of this distinction is the Königsberg bridge problem: a human mathematician (say, Euler, to pick one at random...) can look at a drawing of the city and its seven famous bridges and work out its graph as nodes and edges implicitly. A PostGIS application cannot do the same with just the shapes of the river and landmasses. The data must be converted first.

PostGIS 2.0 will be able to transform standard geometry into topological data, validate topology, and edit nodes and edges. Topology can also be converted to standard Geography Markup Language (GML) for output.

This step represents the beginning of topology support in PostGIS. The future applications include network flow (such as traffic modeling), crisis management for disaster planning (such as minimum spanning trees and shortest paths for logistics), auto-map-coloring, "covering" problems, and considerably more. Those of us not in the GIS field may tend to think of GIS work at the national-mapping scale, for instance, but consider how valuable topology support would make PostGIS for network flow analysis, or for routing utilities within a building.

Application support and additional enhancements

Features like topology and 3D are of limited value without support in the applications that use PostGIS. On that front, GRASS and gvSIG are the first to include topology, with others expected to follow. MapServer and QGIS, on the other hand, have raster layer support already. There may be more in the raster data support category that inherit their raster functionality from earlier support of the PostGIS Raster plug-in; the documentation is not always clear.

For 3D data, the only application that appears to be readying support at present is gvSIG, which is scheduled to include it in the next release. This will reportedly be 3D viewing support only. Several of the open source GIS blogs are excited about the possibilities of 3D, though, including its potential for integration with virtual reality or augmented reality. That seems to be a few steps away, however, as does the possibility of combining topology and 3D data.

The raster, 3D, and topology support slated for PostGIS 2.0 are not the database system's only new features. The blogs and mailing lists repeatedly mention the improvements to the TIGER geocoder, which imports data from the public domain map data gathered by the US Census Bureau, and broke when TIGER changed its format in 2010. There is also a new "reverse geocoder" function that takes a map point and returns nearby address data or street intersections, and a revamped GUI shape-file loader that for the first time can load several files at once. Finally, there are experimental builds for Windows for the very first time — in previous releases, Windows users had to compile PostGIS from scratch. The project has a complete list of new, enhanced, and deprecated functions in its online documentation.

There may still be more enhancements to come; PostGIS reportedly has not yet declared its final feature freeze, and there are funded contractors working on some important areas, 3D included. The final release is officially expected in (northern hemisphere) "early spring," which of course is only a few days old at this point. In the meantime, the suitably daring can get test packages from the PostGIS site. With this many substantial new features, it may be worth taking an early look.

Comments (2 posted)

Supporting CentOS

There are rumors suggesting that the CentOS 5.6 release is imminent - though that is something we have heard before. This release will certainly be welcome to numerous CentOS users, but there can be no doubt that its tardiness - and, in particular, the absence of CentOS 5 security updates caused by its delay - has been a bit of a wakeup call for those users. If this much-used distribution is to remain viable into the future, some important changes will need to be made and those who depend on it will have to step up their support.

There will be no shortage of CentOS users who would like to get their hands on the improvements and added hardware support to be found in the RHEL 5.6 and 6.0 releases. But the real problem is not delayed gratification; it is that there have been no CentOS 5 security updates since January 6, and only one since December 14, 2010. During this time, RHEL 5, on which CentOS 5 is based, has seen updates for dbus, exim, firefox (twice), gcc, hplip, java-openjdk, kernel (thrice), krb5, libtiff, libuser, mailman, openldap, pango, php, postgresql, python, samba, subversion (twice), tomcat5, vsftpd, and wireshark (twice). Since these updates are based on the 5.6 release, CentOS cannot easily pass them on to its users until they, too, have a 5.6 base. Since that base has been slow in coming, all those security updates have been blocked.

Some of these vulnerabilities are more severe than others, but there can be no contesting the fact that every CentOS 5 system out there is currently running with a significant set of known holes. That is not the sort of solidity and support that CentOS users will have been hoping for. Many of those users will, by now, be wondering whether CentOS is the right distribution to base their systems on.

The CentOS mailing list has been filled with users asking when updates would start flowing and why things have bogged down for so long. Some say that there are too many RHEL repackaging projects out there, and that CentOS should join forces with a distribution like Scientific Linux. Others blame the 6.0 release for distracting the project from its 5.x-based users - causing security updates for installed systems to languish in favor of a shiny new distribution that nobody is running yet. Still others complain that the project is insular, secretive, and hostile to new contributors. All of these claims may or may not be true, but they are not the subject of this article: there is another aspect to the problem that is unambiguous and clear.

Many people benefit from the work of the CentOS project, but at the top of the list must be managed hosting providers. Those companies get, for free, a solid platform which they can install on thousands of servers and sell to their customers. A site called tophosts.com maintains a list of the top 25 hosting companies; a look at that list leads to some interesting conclusions. Of those 25 companies:

• One is a Windows-only provider.

• Two offer "Linux" with no way, short of actually renting a server, of determining what flavor of Linux is involved.

• Three appear to offer Red Hat Enterprise Linux only.

• All of the rest (19 providers) offer CentOS.

(As an aside, it is amazing how hard many of these companies make it to find out what it is that they are offering to sell. Hosting provider web sites seem to all be designed by the same person; they are twisty mazes of little JavaScript functions, all alike.)

Represented on this list are the largest hosting providers in existence - though it must be said that the list is US-centric. Together, they account for many hundreds of thousands of systems, a significant percentage of which are running CentOS. That's a lot of business - a lot of revenue - which is being generated by CentOS-based systems.

The failure of CentOS - or even a significant tarnishing of its reputation - would reduce the value of the services offered by these providers. Other free Linux distributions exist, and some are entirely suitable for stable deployment situations, but many customers want a distribution which is compatible with RHEL. So said providers have a significant stake in keeping the perceived value of CentOS high. Perhaps it is time that some of them put some resources into supporting that value.

Said resources could certainly take the form of monetary donations to the project. But far better would be for these companies to hire somebody to work directly with CentOS and make it better. In return, they would reap all of the benefits that come with open source participation: they would have a better distribution to offer to their customers, they would get more influence over the direction of the project, their participation would enhance their reputation, and, crucially, they would improve their in-house expertise which could then be used to support their customers. All of the motivations for supporting free software development in other parts of the economy apply just as strongly to hosting providers.

A look at the CentOS Sponsors Page shows that quite a few hosting companies - including a handful of the big ones from the list described above - are supporting the project. In many cases, it seems, that support takes the form of a donated server. CentOS certainly needs servers and bandwidth, but those, alone, will not keep the distribution strong. Even the strongest contributor gets a bargain from Linux - nobody puts in as much as they get out. But one suspects that the hosting industry is getting a better deal than many. Now would be a good time for the top beneficiaries of the CentOS project to roll up their sleeves and put some serious time into making it better.

Comments (78 posted)

Page editor: Jonathan Corbet

Security

Fallout from the fraudulent SSL certificates

In last week's edition, we looked into a late-breaking disclosure of some fraudulent SSL certificates that had been issued. Due to problems with certificate revocation, it was necessary for Mozilla, Google, and other browser makers to release updates that blacklisted the certificates in question. Since that article was published, we have learned some more about the incident via postings from some of those involved. An update would seem indicated, along with some ideas of possible ways to deal with these kinds of problems in the future.

An attack from Iran?

Perhaps the most interesting update came from Comodo, which is the certificate authority (CA) that is responsible for the fraudulent certificates. Based on the information Comodo gathered from the attack, it would appear that the attacker was based in Iran. The set of domain names for which fraudulent certificates were issued (mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org, and login.live.com) strongly point to a government-sponsored attack. A "regular" criminal attacker would seem more likely to go after certificates for banks and payment sites, but that is circumstantial evidence at best.

Another interesting, if unconfirmed, update is the message from the "Comodo hacker". That message indicates that the Comodo partner (the InstantSSL.it registration authority) had some alarmingly lax security. It also claims that the attack was not sponsored by the "Iranian Cyber Army", and was, instead, just the work of single person. The message contains fairly convincing sounding details of the attack, but there has been speculation that it could have come from the Iranian government as it tries to cover its tracks. We may never know the truth of the matter, as there are interests on all sides with reasons to obfuscate. Authentic or not, the lack of security attributed to the registration authority unfortunately rings true.

Mozilla also followed up its earlier message about the certificates with a recognition that the project should have been more forthcoming. Withholding information about the existence of the fraudulent certificates was really only helpful to the attacker. Knowledge of the certificates would have allowed users to make their own decisions about mitigating the threat posed by a man-in-the-middle (MITM) attack that used them.

Mitigating the risks

MITM attacks are, by their very nature, focused on a small subset of the internet—or a small subset of its users—as the risk of detection rises as a function of the number of users affected. That means that checking certificates from multiple locations in the internet will be quite successful in detecting a local MITM attack. That is exactly what the Perspectives project is working on.

The project provides multiple "network notaries" that are located in different places, both physically and based on internet routing, which monitor the certificates presented by different sites. These notaries store the certificate fingerprint, along with a date and time, so that they have a history of the certificates presented by a given site. When a client wishes to connect to a domain using SSL, it can compare the certificate fingerprint it gets with those stored by several notaries. If they all match, the chances are extremely low that there is some kind of MITM attack going on.

Rather than doing all of that checking manually, though, the project has a Firefox extension that will do that checking, and alert the user if it detects something has gone awry. In addition, the Perspectives extension can override the Firefox error page that comes up for self-signed certificates if it finds that multiple notaries have all recently seen the same certificate.

Obviously, clients must make secure connections to the notaries, so that the attacker can't just spoof their response, so the notary list includes each notary's public key. In addition, notaries could keep track of the responses of other notaries so that malicious notaries could be detected. Each notary would act as a "shadow server" for several other notaries, and clients could check with the shadow server to ensure that the information it received is consistent with what the notary has reported in the past. The shadow server idea is described in the Perspective paper [PDF], but does not seem to be implemented yet. If and when notaries that are not under the control of the project are added, one would imagine that shadow server functionality would be added.

Detecting changed certificates

A simpler mechanism for detecting possible MITM attacks is embodied in the Certificate Patrol Firefox add-on. Essentially, it locally keeps track of which certificate has been seen for a given domain, and alerts the user if that certificate changes. The idea behind it is "trust on first use" (aka TOFU), which means that the first time a valid certificate is seen, it should be trusted. Certificate Patrol (CP) does display the certificate information it receives on first use so that the user can potentially note any red flags. If ever the certificate changes down the road, though, the user will be alerted to that change.

There are plenty of valid reasons why a site might change its certificate, however, so there could be various false positives from CP. When a certificate changes, CP will examine the new certificate and rate the likelihood that it indicates some kind of attack. For example, CP tries to detect certificates that were replaced because they were near to their expiration, and rates that change appropriately. It also tracks the CA used to sign the certificate, as a new certificate from the same CA as the old is less likely to have been issued fraudulently.

One good outcome of the attack

One good thing that resulted from these fraudulent certificates is that folks are thinking and talking about better ways to handle problems like that in the future. Some would claim that the CA model is broken, but we have to have something to replace it before we can even consider dumping it, or reducing its role. Neither Perspectives nor Certificate Patrol are targeted at that particular problem, but may provide reasonable stopgap measures for now.

Toward the end of Jacob Appelbaum's post outlining his detective work in discovering that there were fraudulent SSL certificates floating around "in the wild", he mentions a number of proposals and projects that might offer some alternatives to the current system. We looked at one of those, Monkeysphere, early last year. The others he mentions, DANE, CAA, and HASTLS seem worthy of a look at some point as well. There were already plenty of grumbles about the CA system before this particular incident, but the volume of those complaints is growing, so thinking about alternative solutions is certainly useful.

Comments (8 posted)

Brief items

Security quotes of the week

-- Dave Aitel

-- Charles V. Wright, et al. abstract for "Uncovering Spoken Phrases in Encrypted Voice over IP Conversations"

-- "A message from Comodo hacker" — supposedly anyway

Comments (4 posted)

McGee: The real story behind Arch Linux package signing

On his blog, Arch Linux developer (and Pacman lead) Dan McGee strongly disagrees with an LWN article on the lack of Arch Linux package signing (from this week's Security page). In the posting, he covers the history of the feature in great detail. "You can imagine at this point, a year down the road from the first patches, none of the primary pacman developers are very interested in implementing this themselves. Perhaps this is true, with the ironic twist that more than half of the patches on our long-lived gpg branch are from the three main contributors. I think the most truthful statement is that no one wanted to take the lead on this and finish it by themselves. At this point, the work is nearly where it stands today, as most of the additional work I merged in the last few days was simply bitrot cleanups (aside from pacman-key). However, nowhere have you seen any sense of 'even if you produce good work and get things finished we won't take it' attitudes from Allan [McRae] or I."

Comments (29 posted)

Mozilla's followup on the Comodo certificate issue

Mozilla has sent out a followup laying out what it knows about the Comodo certificate compromise and evaluating its own response. "Mozilla did not publish the information we received prior to shipping a patch. In early discussions, we were concerned that any indication that we knew about the attack would lead to attackers blocking our security updates as well. We also recognized that the obvious mitigation advice we might offer (to change Firefox's security preferences to require a valid OCSP response in all cases, or to remove trust from Comodo's certificates, or both) risked causing a significant portion of the legitimate web to break as well... In hindsight, while it was made in good faith, this was the wrong decision. We should have informed web users more quickly about the threat and the potential mitigations as well as their side-effects."

Comments (2 posted)

Microsoft kills Hotmail HTTPS access in several countries

The EFF is reporting that Microsoft has disabled HTTPS access to its Hotmail service for users in Bahrain, Morocco, Algeria, Syria, Sudan, Iran, Lebanon, Jordan, Congo, Myanmar, Nigeria, Kazakhstan, Uzbekistan, Turkmenistan, Tajikistan, and Kyrgyzstan. "The good news is that the fix is very easy. Hotmail users in the affected countries can turn the always-use-HTTPS feature back on by changing the country in their profile to any of the countries in which this feature has not been disabled."

[Update: Microsoft has acknowledged and fixed the problem, which was due to a bug and not done deliberately.]

Comments (27 posted)

New vulnerabilities

apache2: privilege escalation

Package(s):	apache2	CVE #(s):	CVE-2011-1176
Created:	March 24, 2011	Updated:	March 31, 2011
Description:	From the Debian advisory: A configuration parsing flaw has been found in MPM_ITK. If the configuration directive NiceValue was set, but no AssignUserID directive was specified, the requests would be processed as user and group root instead of the default Apache user and group.
Alerts:	Ubuntu USN-1259-1 2011-11-11 Mandriva MDVSA-2011:057 2011-03-31 Debian DSA-2202-1 2011-03-23

Comments (none posted)

conga: privilege escalation

Package(s):	conga	CVE #(s):	CVE-2011-0720
Created:	March 29, 2011	Updated:	April 20, 2011
Description:	From the Red Hat advisory: A privilege escalation flaw was found in luci, the Conga web-based administration application. A remote attacker could possibly use this flaw to obtain administrative access, allowing them to read, create, or modify the content of the luci application.
Alerts:	CentOS CESA-2011:0394 2011-04-20 Red Hat RHSA-2011:0394-01 2011-03-28 Red Hat RHSA-2011:0393-01 2011-03-28

Comments (none posted)

flash-player: arbitrary code execution

Package(s):	flash-player	CVE #(s):	CVE-2011-0609
Created:	March 29, 2011	Updated:	April 1, 2011
Description:	From the CVE entry: Unspecified vulnerability in Adobe Flash Player 10.2.154.13 and earlier on Windows, Mac OS X, Linux, and Solaris and 10.1.106.16 and earlier on Android, and Authplay.dll (aka AuthPlayLib.bundle) in Adobe Reader and Acrobat 9.x through 9.4.2 and 10.x through 10.0.1 on Windows and Mac OS X, allows remote attackers to execute arbitrary code or cause a denial of service (application crash) via crafted Flash content, as demonstrated by a .swf file embedded in an Excel spreadsheet, and as exploited in the wild in March 2011.
Alerts:	Gentoo 201110-11 2011-10-13 SUSE SUSE-SR:2011:005 2011-04-01 openSUSE openSUSE-SU-2011:0239-1 2011-03-29

Comments (2 posted)

gdm: privilege escalation

Package(s):	gdm	CVE #(s):	CVE-2011-0727
Created:	March 29, 2011	Updated:	April 8, 2011
Description:	From the Red Hat advisory: A race condition flaw was found in the way GDM handled the cache directories used to store users' dmrc and face icon files. A local attacker could use this flaw to trick GDM into changing the ownership of an arbitrary file via a symbolic link attack, allowing them to escalate their privileges.
Alerts:	Mandriva MDVSA-2011:070 2011-04-08 SUSE SUSE-SR:2011:006 2011-04-05 Fedora FEDORA-2011-4335 2011-03-29 openSUSE openSUSE-SU-2011:0275-1 2011-04-01 Ubuntu USN-1099-1 2011-03-30 Debian DSA-2205-1 2011-03-28 Red Hat RHSA-2011:0395-01 2011-03-28

Comments (none posted)

gnash: symlink attack

Package(s):	gnash	CVE #(s):	CVE-2010-4337
Created:	March 28, 2011	Updated:	March 31, 2011
Description:	From the CVE entry: The configure script in gnash 0.8.8 allows local users to overwrite arbitrary files via a symlink attack on the (1) /tmp/gnash-configure-errors.$$, (2) /tmp/gnash-configure-warnings.$$, or (3) /tmp/gnash-configure-recommended.$$ files.
Alerts:	Fedora FEDORA-2011-3662 2011-03-19 Fedora FEDORA-2011-3658 2011-03-19 Debian DSA-2435-1 2012-03-20

Comments (2 posted)

imp4: cross-site scripting

Package(s):	imp4	CVE #(s):	CVE-2010-3695
Created:	March 28, 2011	Updated:	March 30, 2011
Description:	From the Debian advisory: Moritz Naumann discovered that imp4, a webmail component for the horde framework, is prone to cross-site scripting attacks by a lack of input sanitizing of certain fetchmail information.
Alerts:	Debian DSA-2204-1 2011-03-27 Mageia MGASA-2012-0239 2012-08-26

Comments (none posted)

libtiff: arbitrary code execution

Package(s):	libtiff	CVE #(s):	CVE-2011-1167
Created:	March 29, 2011	Updated:	June 27, 2011
Description:	From the Red Hat advisory: A heap-based buffer overflow flaw was found in the way libtiff processed certain TIFF files encoded with a 4-bit run-length encoding scheme from ThunderScan. An attacker could use this flaw to create a specially-crafted TIFF file that, when opened, would cause an application linked against libtiff to crash or, possibly, execute arbitrary code.
Alerts:	Debian DSA-2210-2 2011-06-25 openSUSE openSUSE-SU-2011:0409-1 2011-04-29 CentOS CESA-2011:0392 2011-04-14 Slackware SSA:2011-098-01 2011-04-12 Fedora FEDORA-2011-3827 2011-03-22 Fedora FEDORA-2011-3836 2011-03-22 Ubuntu USN-1102-1 2011-04-04 Debian DSA-2210-1 2011-04-03 Mandriva MDVSA-2011:064 2011-04-04 CentOS CESA-2011:0392 2011-03-31 Red Hat RHSA-2011:0392-01 2011-03-28 Fedora FEDORA-2011-5962 2011-04-25 Fedora FEDORA-2011-5955 2011-04-25 SUSE SUSE-SR:2011:008 2011-05-03 openSUSE openSUSE-SU-2011:0405-1 2011-04-29 SUSE SUSE-SR:2011:009 2011-05-17 Oracle ELSA-2012-0468 2012-04-12 Gentoo 201209-02 2012-09-23

Comments (none posted)

mahara: cross-site scripting and cross-site request forgery

Package(s):	mahara	CVE #(s):	CVE-2011-0439 CVE-2011-0440
Created:	March 30, 2011	Updated:	March 30, 2011
Description:	The "mahara" social networking system suffers from cross-site scripting and cross-site request forgery vulnerabilities which, among other things, can allow an attacker to force the deletion of weblogs.
Alerts:	Debian DSA-2206-1 2011-03-29

Comments (none posted)

postfix: TLS plaintext injection

Package(s):	postfix	CVE #(s):	CVE-2011-0411
Created:	March 24, 2011	Updated:	October 2, 2012
Description:	From the Postfix advisory: The flaw allows an attacker to inject client commands into an SMTP session during the unprotected plaintext SMTP protocol phase (more on that below), such that the server will execute those commands during the SMTP-over-TLS protocol phase when all communication is supposed to be protected. See this LWN article for more information.
Alerts:	SUSE SUSE-SR:2011:010 2011-05-31 Ubuntu USN-1113-1 2011-04-18 CentOS CESA-2011:0422 2011-04-14 CentOS CESA-2011:0422 2011-04-08 Red Hat RHSA-2011:0422-01 2011-04-06 Red Hat RHSA-2011:0423-01 2011-04-06 Fedora FEDORA-2011-3349 2011-03-15 SUSE SUSE-SR:2011:008 2011-05-03 Fedora FEDORA-2011-3394 2011-03-15 Fedora FEDORA-2011-3355 2011-03-15 SUSE SUSE-SR:2011:009 2011-05-17 Debian DSA-2233-1 2011-05-10 Pardus 2011-68 2011-04-07 openSUSE openSUSE-SU-2011:0389-1 2011-04-22 Gentoo 201206-33 2012-06-25

Comments (none posted)

rsync: arbitrary code execution

Package(s):	rsync	CVE #(s):	CVE-2011-1097
Created:	March 29, 2011	Updated:	May 17, 2011
Description:	From the Red Hat advisory: A memory corruption flaw was found in the way the rsync client processed malformed file list data. If an rsync client used the "--recursive" and "--delete" options without the "--owner" option when connecting to a malicious rsync server, the malicious server could cause rsync on the client system to crash or, possibly, execute arbitrary code with the privileges of the user running rsync.
Alerts:	Fedora FEDORA-2011-4427 2011-03-30 Fedora FEDORA-2011-4413 2011-03-30 Mandriva MDVSA-2011:066 2011-04-05 Red Hat RHSA-2011:0390-01 2011-03-28 SUSE SUSE-SR:2011:009 2011-05-17 Ubuntu USN-1124-1 2011-04-27 openSUSE openSUSE-SU-2011:0441-1 2011-05-06

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel is 2.6.39-rc1, released by Linus on March 29. "So 2.6.39-rc1 is out there, and the merge window is closed. I still have to look over the cleancache pull request (which I got in plenty of time, but decided that I want to review after the merge window craziness is over), but other than that, we're done." Significant changes in 2.6.39 will include the open by handle system calls, CLOCK_BOOTTIME, an option to force all interrupt handlers to run as threads, ipset, the transcendent memory core, the media controller subsystem, the CHOKe flow scheduler, and much more; see the long-format changelog for details.

Stable updates: the 2.6.32.36, 2.6.33.9, 2.6.37.6, and 2.6.38.2 stable kernel updates were released on March 28. Each contains another long list of important fixes; note that the 2.6.37.6 update will be the last for the 2.6.37 series.

Previously, 2.6.32.35 was released on March 24 with a single build fix.

Comments (none posted)

Quotes of the week

-- Paul McKenney

-- Constantine Shulyupin

-- Andrew Morton

Comments (7 posted)

Jump label reworked

The jump label mechanism was last seen here in October, 2010. In short, jump label allows the optimization of "highly unlikely" code branches to the point that their normal overhead is close to zero. This speedup is done with runtime code patching; that is also the cost: enabling or disabling the unlikely case is an expensive operation. Thus, jump label is best used for code which is almost never enabled; tracepoints and dynamic debugging statements are obvious cases.

There were a number of complaints about the initial jump label implementation, including the fact that it was somewhat awkward to use. In response, a reworked version has been posted which changes the interface considerably. One starts by declaring a "jump key":

    #include <linux/jump_label.h>

    struct jump_label_key my_key;

Enabling and disabling the key is a simple matter of calling:

    jump_label_inc(struct jump_label_key *key);
    jump_label_dec(struct jump_label_key *key);

And using the key to control the execution of rarely-needed code becomes:

    if (static_branch(&my_key)) {
	/* Unlikely stuff happens here */
    }

In the absence of full jump label support, a jump key is represented by an atomic_t value. jump_label_inc() becomes atomic_inc(), jump_label_dec() becomes atomic_dec(), and static_branch() is implemented with atomic_read(). If jump label is configured into the kernel, enabling and disabling a jump key become heavier operations, while static_branch() becomes nearly free. For the intended use cases for jump labels, that is a worthwhile tradeoff.

As of this writing, these changes have not been merged for 2.6.39. There is always a possibility that they could be pulled in before -rc2, but chances are that, at this point, the new jump label will have to jump into 2.6.40.

Comments (3 posted)

Powering down APM

The APM power management interface has never been much loved - even ACPI was seen as a better alternative. There has been little or no hardware made which depends on APM for some years; Windows evidently stopped supporting it in 2006. Linux does still support APM, though, and that support has a cost, so it is perhaps not surprising that Len Brown would like to remove that support as of 2.6.40.

Removal of APM support on that schedule is almost certainly not going to happen; a number of developers have expressed concerns that there may still be hardware out there in use which would then be unable to run new kernels. In general, the Linux kernel tries not to abandon users running older hardware. So APM may stay for a while, but there is a problem: keeping APM support, it seems, conflicts with some needed changes to the cpuidle code. The need to keep APM working, in other words, threatens to hold back improvements for the majority of users who have more current hardware.

The solution to this conflict may take the form of a partial removal of APM support. The most important APM feature for users of old systems is likely to be the ability to power-off the system; other features may be less important. As Andi Kleen noted, idle support probably matters less to such users:

So APM support, as such, may stick around for a while, but it may begin to lose features as the kernel moves on.

Comments (25 posted)

Kernel development news

The 2.6.39 merge window concludes

There have been just over 2,200 non-merge changesets pulled into the mainline since the second installment in this series; that makes 8,757 total changes for this development cycle. The 2.6.39 merge window is now closed, so the feature set for this kernel development cycle should be complete. User-visible changes merged in the final part of the merge window include:

• Beginning user namespace support has been merged. User namespaces are a sort of container where processes can safely be given root access within the container without being able to affect the rest of the system. Full container support is a long-term project, but the user namespace patches get the kernel one step closer.

• It is now possible for a suitably privileged process to write to a processes /proc/pid/mem file.

• The "group isolation" tunable for the CFQ I/O scheduler has been removed; group isolation is always provided now that the performance issues associated with that mode have been fixed.

• There is a new "mtdswap" block device which allows swapping directly to memory technology devices.

• New hardware support includes:
  • Processors and systems: Samsung Laptop SABI interfaces, WMI Hotkeys for Dell All-In-One series, Intel Medfield platform thermal sensors, and Asus Notebook WMI interfaces.

  • Miscellaneous: MSM chipset SMD packet ports, Texas Instruments TWL4030 hardware monitoring controllers, ST-Ericsson AB8500 voltage monitors, Maxim Semiconductor MAX8997/8966 PMICs, Maxim 8997/8966 regulators, Texas Instruments TPS61050/61052 boost converters, Ricoh R5C592 card readers, and OLPC XO-1.5 ebook switches.

  • Video4Linux: Technisat USB2.0 DVB-S/S2 receivers, Silicionfile NOON010PC30 CIF camera sensors, DiBcom 9000 tuners, 3com homeconnect "ViCam" cameras, OmniVision OV9740 sensors, ST Microelectronics STV0367 demodulators, OMAP3 camera controllers, Divio NW80x-based camera controllers, and ITE Tech IT8712/IT8512 infrared transceivers.

Changes visible to kernel developers include:

• The dma64_addr_t type is no longer used in the kernel; it has been removed.

• The videobuf framework in the Video4Linux2 subsystem has been replaced by a newer "videobuf2" version.

• The media controller subsystem, intended to allow the system to export information about the topology of complex media subsystems to user space, has been merged.

• printk() and friends have a new "%pB" format specifier which prints a backtrace symbol and its offset.

• The m68k and m68knommu architectures have been merged in the kernel source tree.

• A support library for BCH (Bose-Chaudhuri-Hocquenghem) encoding and decoding has been added.

• Some low-level interrupt-related functions have changed names:

  Old	New
  get_irq_chip()	irq_get_chip()
  get_irq_chip_data()	irq_get_chip_data()
  get_irq_msi()	irq_get_msi_desc()
  irq_data_get_irq_data()	irq_data_get_irq_handler_data()
  set_irq_chained_handler()	irq_set_chained_handler()
  set_irq_chip()	irq_set_chip()
  set_irq_chip_and_handler_name()	irq_set_chip_and_handler_name()
  set_irq_data()	irq_set_handler_data()
  set_irq_handler()	irq_set_handler()
  set_irq_nested_thread()	irq_set_nested_thread()
  set_irq_noprobe()	irq_set_noprobe()
  set_irq_type()	irq_set_irq_type()
  set_irq_wake()	irq_set_irq_wake()

  The prototypes for these functions are otherwise unchanged.

The 2.6.39 kernel now goes into the stabilization phase of the development cycle. If the usual pattern holds, we can expect to see on the order of 2000 fixes merged between now and the final release, which is likely to happen in early June.

Comments (10 posted)

Dynamic devices and static configuration

Linux users in the Good Old Days were treated to a number of experiences which are denied to newcomers; one of those was the tiresome task of figuring out where peripheral devices had chosen to put their I/O ports and interrupt lines and communicating that information to the kernel. Contemporary, self-describing hardware had taken a lot of the fun away in the name of making things Just Work. This kind of joy can still be had at the embedded level, though, where the trend toward discoverable hardware has not caught on in the same way. Recent discussions show that there is not, yet, a consensus among kernel developers regarding how such hardware should be configured.

The OMAP-based PandaBoard is a popular platform for those who are interested in experimenting with embedded applications. It comes with a dual-core processor, high-definition video capability, wireless networking, Bluetooth, an HDMI output, and the sadly standard closed graphics usually associated with these devices. It also has a "USB-attached" network port which is actually soldered to the board; it looks like a USB device, but it's not something the user could unplug without an act of significant violence.

This network port has moved developers toward violence for other reasons as well. It is recognizable as a network device, but there is no way to know that it is wired down. The board developers, in a move which is common in this area, also left out the small EEPROM which would normally contain the MAC address for this interface. In response to these design decisions, a standard Linux kernel booting on this board will call its network interface usb0 (a name normally used for USB point-to-point connections), and will generate a random MAC address for it. Anybody who might depend on a MAC address which is stable across boots will be out of luck.

This kind of non-discoverable hardware is common in the embedded sphere, so a number of techniques have been developed to allow the kernel to run on the resulting systems. The traditional approach is through the creation of "board files"; see board-msm7x30.c as an example. These files are meant to provide the kernel with enough information to understand the topology of the hardware it is running on; information related to specific devices is typically passed through a set of static platform_device structures, and through that structure's platform_data pointer in particular. As the driver initializes the device, it can refer to the platform_data pointer (which points to some sort of device-specific structure) for any information which it cannot get from the hardware itself.

The current platform_data implementation will not work for the PandaBoard, though, because platform_data is not passed to USB devices. These devices are meant to be entirely discoverable and self-describing, so it was thought that there would be no need for external configuration data in the kernel. The fact that these devices are dynamic means that their existence cannot be known or guaranteed when the board file is written, so trying to create static platform data for them would seem to make little sense.

The problem with this reasoning is that the PandaBoard's network interface is not fully discoverable and it is not dynamic. It is a sort of platform device disguised as a USB device. So Andy Green thought it would be reasonable to use platform data as a way of configuring this device; in particular, he would like to pass the device name (eth0 instead of usb0) and a MAC address via a platform_data pointer. What he got was an extended discussion making it clear that (1) the platform data mechanism is not universally loved, and (2) there is not a complete consensus on how this kind of problem should really be solved.

There are a couple of perceived problems with platform data; first of those is that it encodes the information about a specific hardware configuration in the kernel itself. That leads to a proliferation of board files in the kernel source - each of which is controlled by its own configuration option - and makes it hard to build kernels which can run on multiple boards. The platform_data pointer itself, being a void pointer, is seen as not being type-safe: there is no way for the compiler to ensure that every board file is passing the right type of pointer to every device driver. For these reasons, there is strong opposition to expanding the platform data mechanism.

What are the alternatives? One of those is to do everything in user space, using udev rules. This approach appeals to those who want to see no policy in kernel space, but it is hard to implement in this case; there is no information available to distinguish this wired-down network controller from the traditional USB variety. Some developers are also unconvinced that replacing in-kernel board files with fragile-looking (to them) user-space configuration files which must be pushed to distributors is the way toward a more robust solution. It is also argued that the device naming policy (usb0, in this case) is already in the kernel; the discussion is about the details of what that policy should be.

The other approach would be to use device trees, which are meant for just this type of application. A device tree would allow the passing of configuration-specific information into drivers without the need to put board-specific hacks into the drivers themselves. As more components show up in both consumer and deep embedded situations, this capability will only become more useful. For these reasons, Arnd Bergmann thought that this problem would be an ideal place to demonstrate the use of device trees:

The problem with the device tree approach is that its adoption, in general, is slow, especially in the ARM architecture which, arguably, has the most need of it. It does not seem like a solution for people who have a PandaBoard now and would like it to work; it is also not immediately applicable to all of those systems which are currently described by board files and platform data. While many people seem to see a transition to device trees as something which will happen eventually, few of them are holding their breath in anticipation of an immediate changeover.

So what is a PandaBoard owner to do? There are, it seems, a couple of short-term solutions which will fix this particular board without waiting for longer-term answers. One is a patch from Arnd which will cause USB-attached Ethernet devices to carry an ethN name unless they are known to be point-to-point connections. For the MAC address problem, Alan Cox has suggested a hack which would allow the board file to take control of the address assignment for a specific interface. Neither of these solutions addresses the real problem, but they will give some breathing room while the proper fix is debated.

Comments (2 posted)

Fighting fork bombs

Unix-like systems tend to be well hardened against attacks from outside, but more vulnerable to attacks by local users. One of the softer spots in most systems has to do with "fork bombs" - processes which madly fork() until they run the system out of resources. These attacks are difficult to defend against and difficult to stop without a reboot; they can also, at times, be created inadvertently. If Hiroyuki Kamezawa has his way, fork bombs will be less of a problem in the future.

The problem with fork bombs is that they are moving targets; by the time a system administrator notices a rapidly-forking process, it may have created vast numbers of children and exited. Killing processes individually in a fork bomb situation is not really an option; even a program written especially for this task can be hard put to keep up with the stream of new processes. There is just no way to get a handle on the entire tree of offending processes from user space. So it is not surprising that the best response in this situation can be to hit the Big Red Button and start over. Even if, as in Kamezawa-san's case, hitting the button involves walking to another building where the afflicted system is housed.

Indeed, it can be hard to get a handle on this tree from kernel space as well. The process tree only exists, as such, as long as the parent processes remain alive; once a process exits, all of its children are reparented to the init process. That causes a flattening of the tree structure and makes it hard to identify all of the processes involved in the attack. So Kamezawa-san's patch starts with the addition of a new process tracking structure. It is organized as a simple tree reflecting the actual family structure of the processes on the system. It differs from existing data structures, though, in that this "history tree" persists even when some processes exit. That allows the kernel to view the entire tree of processes involved in a fork bomb even if those which launched the attack have long since gone away.

Keeping the entire history of all processes created over the lifetime of a Linux system would be a costly endeavor. Clearly, there comes a point where history needs to be discarded. Every so often (30 seconds by default), the kernel will try to determine whether there might possibly be a fork bomb attack in process; if no signs of an attack are detected, any tracking history which has existed for more then 30 seconds will be deleted.

How does the kernel decide whether it might be under attack? The way fork bombs incapacitate a system is usually through memory exhaustion, so the code looks for signs of memory stress: in particular, it looks to see if there have been any memory allocation stalls or kswapd runs since the last check. It also looks at whether the total number of processes on the system has increased. If none of those checks shows any reason for concern, the older history data will be removed from the system. If, instead, memory allocations are getting harder to come by or the number of processes is growing, the tracking structure will be kept around.

If a fork bomb runs the system out of memory, the kernel's first response will be to fire up the out-of-memory (OOM) killer. Given time, the OOM killer might manage to clean up the mess, but the fact of the matter is that the OOM killer is designed around finding the one process which is creating the problem and killing it. The OOM killer cannot identify a whole tree of rapidly-forking processes and do away with all of them.

Enter the fork bomb killer, which is invoked by the OOM killer. The fork bomb killer will perform a depth-first traversal of the process history tree, filling in each node with information on the total number of processes below that node and the total memory used by those processes. At the end, the process with the highest score is examined; if there are at least ten processes in the history below the high scorer, it is deemed to be a fork bomb; that process and all of its descendants will be killed. Problem solved - hopefully.

There are a couple of control knobs which have been placed under /sys/kernel/mm/oom. History tracking will only be performed if mm_tracking_enabled is set to "enabled" (which is the default setting). The value in mm_tracking_reset_interval_msecs controls how often the process tracking tree is cleaned up; the default value is 30,000 milliseconds. A possibly surprising omission is the lack of a knob controlling how many descendants a process must have before it is declared to be a fork bomb; the hardcoded value of ten seems low.

The reception for this patch has not been entirely favorable; commenters worry about the runtime cost of maintaining the tracking structure and suggest that user-space solutions may be better. Kamezawa-san seems resigned that the patch may not go in, saying "To go to other buildings to press reset-button is good for my health." Other administrators, who may not be within easy walking distance of their systems, may feel their health is better served by some extra fork bomb protection, though.

Comments (18 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Merge window closed - 2.6.39-rc1 out . (March 29, 2011)

• Greg KH: Linux 2.6.38.2 . (March 28, 2011)

• Con Kolivas: 2.6.38-ck1 . (March 24, 2011)

• Greg KH: Linux 2.6.37.6 . (March 28, 2011)

• Greg KH: Linux 2.6.33.9 . (March 28, 2011)

• Greg KH: Linux 2.6.32.35 . (March 24, 2011)

• Greg KH: Linux 2.6.32.36 . (March 28, 2011)

Core kernel code

• KAMEZAWA Hiroyuki: forkbomb killer . (March 24, 2011)

• Mauro Carvalho Chehab: [PATCH RFC 2/2] events/hw_event: Create a Hardware Anomaly Report Mechanism (HARM) . (March 28, 2011)

• Mike Travis: bitmap, irq: Add smp_affinity_list interface to /proc/irq . (March 30, 2011)

Development tools

• Akihiro Nagai: perf: Introduce branch sub commands . (March 24, 2011)

Device drivers

• Peter Hsiang: ASoC: Add max98095 CODEC driver . (March 24, 2011)

• MyungJoo Ham: power_supply: Add driver for MAX8903 charger . (March 29, 2011)

• Jamie Iles: Support for OTP memory . (March 24, 2011)

• Richard Cochran: ptp: IEEE 1588 hardware clock support . (March 28, 2011)

• Huang Shijie: add the GPMI controller driver for IMX23/IMX28 . (March 28, 2011)

• Par-Gunnar Hjalmdahl: staging: Add ST-Ericsson CG2900 driver . (March 29, 2011)

• vooon341@gmail.com: mmc: Add MPC512x SDHC driver. . (March 29, 2011)

• Alan Cox: GMA500 updates . (March 30, 2011)

• Christopher Heiny: input/touchscreen: Synaptics RMI4 Touchscreen Driver . (March 30, 2011)

• Marek Szyprowski: FrameBuffer emulator for V4L2/VideoBuf2 . (March 30, 2011)

Filesystems and block I/O

• Li Dongyang: Btrfs: batched discard support for btrfs . (March 28, 2011)

• Miao Xie: btrfs: implement delayed inode items operation . (March 28, 2011)

Janitorial

• Len Brown: APM: delete APM in Linux-2.6.40 . (March 28, 2011)

Memory management

• Michal Hocko: Implementation of cgroup isolation . (March 28, 2011)

• Michel Lespinasse: idle page tracking / working set estimation . (March 28, 2011)

• Balbir Singh: Unmapped page cache control (v5) . (March 30, 2011)

Architecture-specific

• Rafael J. Wysocki: ARM: Use syscore_ops for "core" power management . (March 28, 2011)

Security-related

• Roberto Sassu: eCryptfs: added support for the encrypted key type . (March 29, 2011)

• Mimi Zohar: EVM . (March 29, 2011)

Benchmarks and bugs

• Rafael J. Wysocki: 2.6.38-git18: Reported regressions from 2.6.37 . (March 28, 2011)

Miscellaneous

• Stephen Hemminger: bridge-utils 1.5 . (March 29, 2011)

Page editor: Jonathan Corbet

Distributions

Moving toward nirvana with Enlightenment distributions

There are not that many mainstream Linux distributions that come with Enlightenment E17 as their default desktop environment. There's Elive (we looked at its 2.0 release last year), which is a Debian derivative with Enlightenment, but users have to pay to install it to a hard drive and it's already rather dated. OpenGEU, another Enlightenment-based distribution, seems to have stalled. But in the last few months, two new Enlightenment-based Linux distributions have appeared: the Ubuntu-based Bodhi Linux and the openSUSE derivative Petite Linux. We'll take a look at both distributions and their contrasting approaches to bring an Enlightenment desktop to users.

Bodhi Linux: enlightened Ubuntu

Bodhi Linux ("bodhi" is the Buddhist term for "enlightenment") claims to be "a minimalistic, enlightened, Linux desktop". The system requirements are modest: a 300 MHz x86 processor with 128 MB RAM and 1.5 GB disk space should suffice. Bodhi Linux, which published its 1.0.0 release on March 25, is built on top of Ubuntu 10.04 with some packages backported from Ubuntu 10.10, such as the 2.6.35 kernel and the newer Ubiquity installer. For now, there's only a 32-bit release.

The developers promise that Bodhi Linux will follow the release cycle of Ubuntu LTS, which means that there will be a new main release every two years. So the 2.0.0 release will be based on Ubuntu 12.04 LTS and is aimed at mid-late 2012. There will also be minor point releases roughly every three months with current software packages. For instance, Bodhi Linux 1.1.0 will have a 2.6.38 kernel and is expected toward the end of May. Because Enlightenment is still under heavy development, new Enlightenment updates are pushed out to the Bodhi repository at least once a week.

This all sounds very professional for such a small distribution, but there's an important security issue in the way Bodhi Linux uses its repository: the packages in the Bodhi repository are not signed (apt-get warns you about this when you're on the verge of installing such a package), so its users are vulnerable to a man in the middle attack. For now, the main developer Jeff Hoogland doesn't seem to think this is a serious issue, as his reaction to a question from a user shows:

After starting the live CD (which is only 380 MB), it gives you the choice from six different profiles: Bare, Desktop, Ecomorph, Fancy, Laptop, and Tablet/Netbook. If you click on a profile, Bodhi gives you some information about the use cases it is meant for. For instance, Bare is for advanced users that want to create their own customized Enlightenment configuration. Most users will want to install the Desktop or Laptop profile, or the Ecomorph if they want Compiz effects enabled (which may require proprietary graphics drivers). The Desktop profile will get you something KDE-like, to try to make those coming from KDE feel at home, by moving the default shelf (actually, a panel) to the bottom for example. In the next step, users can choose a desktop theme. If you click on one of these themes, Bodhi shows you a preview. After this, the live environment starts up with your chosen profile and theme, so that you can give Bodhi Linux a try.

To install, just click on the install icon in the quick launcher at the bottom of the screen. This will fire up Ubuntu's familiar Ubiquity installer. After the installation, a reboot is required. It's immediately clear that Bodhi Linux starts up fast, and the user's session starts up blazingly fast after login as well. The first time, you have to choose the profile and theme you want for your session. After this, you can choose which applications to add to the quick launcher at the bottom, but this can also be done later.

Your author didn't undertake an extensive benchmark, but his gut feel says that even applications start up significantly faster than on plain Ubuntu (with GNOME). In his review at TechRepublic, Jack Wallen experienced the same and did some measurements on two different but equally equipped machines: on the machine with Bodhi Linux, GIMP started two times faster than on a standard Ubuntu 10.10 machine. Exactly why this is happening is uncertain, but the cause could be that E17 just uses much less resources than GNOME and that Bodhi Linux is running fewer services in the background than a stock Ubuntu install.

While the first focus of Bodhi Linux is creating a minimalistic Enlightenment desktop, its second core idea is that user choice is paramount. The only pre-installed applications are the web browser Midori (a lightweight Webkit-based browser), the editor Leafpad, LXTerminal, the file browser PCManFM, Synaptic, and, of course, some system configuration tools. So after installing Bodhi Linux, your system is not cluttered with applications that you'll never use, and you can make your own decisions about which software you want to install.

Installing software can be done with apt-get or with the Bodhi Software Center. The latter is a web site that lists some popular packages and lets you install them directly from the browser. Furthermore, if you click on the download button of an application, you get a package that includes the application and all of its dependencies, so you can install it easily on another machine without an internet connection.

On a side note: the developers are really serious about user choice. They are even considering an RPM-based Bodhi version. At this moment, they have been working on a Fedora disc using the Enlightenment desktop as a side project, and they even plan a version based on Arch Linux. It will probably take some time, but Hoogland has already assembled a small but growing team, with, for example, Chris Bolton who will build an Arch Linux based Bodhi.

But this user choice doesn't mean that Bodhi Linux leaves its users in the dark after installation: there's a wiki with installation instructions, a quickstart (which will be opened the first time you launch Midori), and some tips and tricks. Because Bodhi Linux is quite minimalistic after installation, these online documents are really helpful to make some things work that other distributions already do by default or that they have a GUI for. There are also some introductions to get up to speed with Enlightenment.

Petite Linux: enlightened openSUSE

Petite Linux takes a completely opposite approach, which is easy to see when you start it up: it boots much slower than Bodhi. Petite Linux is built with SUSE Studio, so the minimum hardware requirements are the same as openSUSE: a Pentium III 500 MHz processor with 512 MB RAM and 3 GB available disk space. Version 1.0.0, based on openSUSE 11.3, was released in February, and apparently can only be downloaded as a torrent (the ISO file is 651 MB). An openSUSE 11.4-based Petite Linux should be right around the corner.

While Bodhi Linux is all about choice, the idea behind Petite Linux is to "just work". So it makes a lot of decisions for you, with the result that it's not as minimal as Bodhi Linux is. For instance, it installs a lot of applications, like GIMP, OpenOffice.org Base, Impress, Calc, Writer, and Draw, the Eye of GNOME image viewer, the instant messenger Empathy, the Transmission BitTorrent client, the Google Chrome web browser, the media player SMPlayer, the CD/DVD burning program TkDVD, GNOME Terminal, Wine, and some system configuration tools. However, that doesn't mean that Petite Linux is bloated. For instance, with respect to Enlightenment, it only includes the default modules, which are known to be stable, and for each type of work there's only one application installed. CUPS is not installed by default, nor are the proprietary graphics drivers for Nvidia and ATI.

Petite Linux installs Wine primarily for playing Windows games. The online HOWTO page about games even explains how to run Windows games in Wine and lists some games that are known to work. For more information about compatibility issues, the web page refers to the Wine Application Database. The HOWTO also lists some steps to install Steam in Wine, and even how to re-use the Steam games you have already downloaded in Windows on the same computer, so you don't have to download them again in Petite Linux. Of course there are also Linux games: Petite Linux refers to openSUSE's Games repository for this.

Although Petite Linux shows you a nice Enlightenment desktop, you should take the idea that everything "just works" with a big grain of salt. This begins on the live CD: there's not even an icon in the menu or on the desktop to install the distribution. Users have to read the online HOWTO to know that they should hit Alt+Esc for the "run command" window, then type "live" and choose the live installer. This opens openSUSE's YaST2 live installer. Users should also know that the live CD comes with a root password "linux", which they will need to run the live installer.

But even after installation, the distribution shows a lot of quirks. The first is that Petite Linux automatically logs in the user, although your author explicitly unchecked that option in the installer. Moreover, it didn't honor his settings for the user and the keyboard layout: Petite Linux does an auto-login with the user "alfa" (the same user as the live CD runs). The HOWTO page gives some explanation about how you change the autologin user and copy the Enlightenment configuration, but even this explanation is incomplete and won't "just work" for the distribution's target users. In addition, if you want to install extra Enlightenment modules, you need to check out the module code from the Enlightenment Subversion repository and compile the code yourself, which is not so user-friendly and certainly not very maintainable.

From enlightenment to nirvana

Enlightenment proves that users can have a nice looking desktop without eating up all of their computer's resources. While there exist other lightweight desktop environments like LXDE and Xfce, Enlightenment does the same but with more style. So if you have an older computer or a slow netbook that you'll want to make use of as efficiently as possible, an Enlightenment distribution could be the way to go.

If you're an experienced user and want to have your own choice, Bodhi Linux is currently the best candidate, but if you'd like an Enlightenment distribution that makes decisions for you, have a look at Petite Linux. Unfortunately, both distributions still have some issues: due to the lack of package signing, Bodhi Linux will make security-conscious users wary, and Petite Linux is not polished enough to deserve the status of a "just works" distribution. As well-meant as both projects are, both 1.0 releases show that it takes much more than slapping a desktop environment on top of a base operating system to create a new distribution. Of the two, Bodhi Linux seems the most promising distribution: with some work on the package signing, it could find a niche and reach the nirvana of Enlightenment distributions.

Comments (4 posted)

Brief items

Distribution quote of the week

-- Steve Langasek

-- Tom Sorensen

Comments (1 posted)

Announcing the release of Foresight Linux 2.5.0

The Foresight project has announced the release of Foresight 2.5.0. "Foresight is a Linux distribution for your desktop that features a rolling release schedule that always keeps your desktop up to date; a revolutionary package manager, Conary; the latest GNOME, KDE and Xfce desktop environment and an innovative set of excellent, up to date software applications."

Full Story (comments: 9)

openSUSE Edu Li-f-e 11.4 is out

The openSUSE Education team has announced the release of openSUSE-Edu Li-f-e (Linux for Education) based on openSUSE 11.4. "This release includes the latest carefully selected softwares for students, educators as well as parents. The software selection encompasses everything required to make computers productive for either home or educational use without having to install anything additional."

Full Story (comments: none)

Slackware RC pi

Slackware rc 3.14159265358979323846264338327950288419716 was announced in March 27, 2011 changelog entry (x86, x86_64). "There have been quite a few changes so we will have one more release candidate: Slackware 13.37 RC 3.14159265358979323846264338327950288419716. Very close now! But we'll likely hold out for 2.6.37.6."

Comments (none posted)

Ubuntu 9.10 reaches end-of-life on April 30 2011

Ubuntu 9.10 (Karmic Koala) will reach its end-of-life on April 30, 2011. "Ubuntu announced its 9.10 release almost 18 months ago, on October 29, 2009. As with the earlier releases, Ubuntu committed to ongoing security and critical fixes for a period of 18 months. The support period is now nearing its end and Ubuntu 9.10 will reach end of life on Friday, April 29, 2011. At that time, Ubuntu Security Notices will no longer include information or updated packages for Ubuntu 9.10."

Full Story (comments: none)

Introducing /run

Lennart Poettering has sent out a note warning Fedora users that they will see a new top-level /run directory soon. "In the past weeks key people from the Debian, Suse, Ubuntu and Fedora camps (and others, too) discussed the whole issue forth and back, to find a solution to stop the misuse of /dev before it becomes even more widespread. Various solutions have been suggested, but in the end it all boiled down to the fact that /var/run does not belong beneath /var and what we really want is a top-level directory /run, and that that is the only really clean solution. The only reason why nobody dared to actually implement such a directory was unwillingness to deal with the political backlash, especially messy discussions on mailing lists like this one." The ensuing discussion has not entirely disappointed, but it looks like /run will carry the day.

Full Story (comments: 188)

Distribution News

Debian GNU/Linux

Bits from the Release Team - Kicking off Wheezy

The Debian release team presents a few bits about the next release, dubbed "Wheezy". Topics include a retrospective of the squeeze release, time based freezes, transitions, release goals, a release team sprint, and 0-day NMU policy. "As we are at the beginning of the wheezy cycle, there are a number of changes which have been pending for some time as they were unable to be considered during the squeeze freeze and the period leading up to it. The combination of toolchain changes and some larger transitions which have become entangled are at times making the day-to-day work of updating packages in unstable more complicated than we would prefer and an overview of upcoming changes allows us to better manage those issues."

Full Story (comments: none)

Nicaragua to host Debian Developer Conference 2012

DebConf12 will take place in Managua, Nicaragua in 2012. "In a two-and-a-half hour meeting on Tuesday evening, the Managua bid narrowly won over the bid from Belo Horizonte, Brazil. Teams had been preparing their bids since mid-2010, seeking venues and local sponsors in their respective cities and countries."

Full Story (comments: none)

Fedora

Fedora 15 schedule to slip an additional week

Jared K. Smith reports a slip in the Fedora 15 release schedule. "The Fedora 15 development cycle is well under way, and making good progress. Yesterday I met with Release Engineering, QA, the Fedora Program Manager, and we decided that in order to accommodate some late-breaking changes, we're going to need to slip the Fedora 15 release schedule by a week in order to have adequate time to do proper testing of the candidate images before the Beta."

Full Story (comments: none)

Ubuntu family

Ubuntu technical board: no non-free software by default

The short report from the March 24 meeting of the Ubuntu Technical Board carries this conclusion: "The Technical Board voted unanimously against (0 for, 5 against) including non-free software in the distribution, agreeing that checking a box in the installer by default is equivalent to simply including the software in the default installation. This would have gone against Ubuntu's long standing policy that the only concession is for hardware drivers..." The issue at hand was this bug report requesting that Flash be installed by default.

Full Story (comments: 22)

Newsletters and articles of interest

Distribution newsletters

• Debian Project News (March 28)
• DistroWatch Weekly, Issue 398 (March 28)
• Fedora Weekly News Issue 268 (March 23)
• openSUSE Weekly News, Issue 168 (March 26)

Comments (none posted)

Zenwalk Linux 7.0+ (ZDNet)

Jamie Watson takes Zenwalk 7.0 for a test drive. "Zenwalk includes a good selection of utilities and applications. It uses the GNU IceCat browser, which the Help box explains "was made by making small changes in Mozilla Firefox". The changes are primarily in the areas of branding and licensing. It also includes IceDove, which is similarly derived from Mozilla Thunderbird. It has LibreOffice 3.3, including Writer, Calc, Draw and Impress, and it also has Orage Calendar and Globaltime. If you haven't tried those last two, they are worth a look, I find them quite handy."

Comments (none posted)

Page editor: Rebecca Sobol

Development

Let the Crabgrass bloom: Software Libre for social networking

Looking for a social networking stack that's free software and ready to use today? The latest release of Crabgrass from Riseup Labs looks to be almost ready for prime time. Though targeted at "activist" groups, Crabgrass could be useful to any project or organization.

What's Crabgrass? If you haven't heard of it, then odds are that you're not a hard-core activist in the Seattle area. Crabgrass is a Ruby on Rails application for social networking, group collaboration, and network organizing licensed under the Affero GPLv3. The name was chosen because crabgrass is "subversive" (grows nearly anywhere), "diverse" (lots of species of crabgrass), and "hard to kill" (which should be self-explanatory to anyone who's tried to rid a lawn of crabgrass).

The development is largely being driven by Riseup.net's Riseup Labs. Riseup.net is "an autonomous body based in Seattle with collective members world wide" with a mission statement to "aid in the creation of a free society, a world with freedom from want and freedom of expression, a world without oppression or hierarchy, where power is shared equally" by "providing communication and computer resources to allies engaged in struggles against capitalism and other forms of oppression." The organization provides hosting services, mailing lists, and other services and support (like Tor exit nodes) to facilitate organizations collaborating online and to thwart monitoring and surveillance. The group claims 50 hosted servers, more than 13,000 lists, and two million list subscribers.

Riseup Labs is a 501c3 organization billed as the "research arm" of the Riseup Collective. It does work on Crabgrass as well as Monkeysphere, Backupninja, and the Debian Grimoire.

The first alpha release of Crabgrass was in 2009, but development really picked up after the Riseup Collective brought on developers to focus on Crabgrass. Crabgrass provides a host of collaboration tools like task lists, meeting scheduling, wikis, file hosting, discussion pages, surveys, image galleries, and much more. Crabgrass also offers real-time chat, a tagging system for content, and a search system for finding what's stored in Crabgrass (assuming one has access to the material). What's missing? So far, Crabgrass lacks calendaring, but it's fairly complete otherwise.

The tools also have fairly fine-grained privacy controls, with defaults that require users to consciously share materials with others rather than a site like Facebook which starts from the assumption of sharing with anyone and requiring users to take steps to lock down content. The hosted version of Crabgrass from Riseup.net only allows communication over SSL/HTTPS, and data is stored in an encrypted format. For the most part, it appears to be up to the administrator to secure Crabgrass if they choose to run their own install.

Crabgrass is sort of a blend between tools like 37 Signals' Suite of collaboration tools, Facebook, and Meetup.com. The difference, of course, being that it's AGPL'ed and designed with user privacy and security in mind. The rationale for Crabgrass is that social movements need better tools to work on the Web, and the existing Web services do not suit "the complexity of relationships that activist organizations face in the real world."

Oddly enough, Crabgrass has gotten very little attention as an alternative to Facebook or other proprietary social networking/organizing platforms. Though it's not a one-to-one replacement for Facebook, exactly, it does offer most of the features that users would want — and then some. Then again, it may not be too surprising, given that the Riseup Collective is not what one might consider a mainstream organization — or one that pursues the mainstream even a little.

The bent of Crabgrass is not towards frivolity and chattiness that one finds on Facebook, Twitter, or MySpace. Though Crabgrass is being released as open source, it seems that it's mostly being used by Riseup to "facilitate active, confederal, and directly democratic social change networks." But it is available for anyone who'd like to run it themselves, if you're willing to do some digging. The documentation on the Crabgrass site is primarily targeted at developers or end users. If installation instructions are available online, they're carefully hidden.

If one downloads the Crabgrass package, though, install instructions are found nestled under the docs directory and are fairly straightforward. Again, the instructions are primarily targeted at developers — the install will provide a running instance of Crabgrass running on WEBrick, a Ruby library that provides a single-threaded Web server that's suitable for development use but unsuitable for a real-world deployment of any size.

In short, Crabgrass is not a trivial install and will require a bit more care and feeding than, say, a WordPress or Drupal installation.

Since the production release is being used on Riseup.net, I decided to create an account and test-drive the software in use rather than setting up a test version that would only have a single user. Over the last few years, I've used Facebook extensively, 37 Signals tools lightly, and Meetup.com quite heavily in the last few months. Crabgrass is not quite as intuitive as other social media tools, nor quite as easy on the eyes as Meetup.com or 37 Signals' tools. In this users' opinion, it's far preferable to the Facebook interface.

In terms of actual features, though, Crabgrass seems to be on par with other services. It's easy to use, seems to provide most if not all the features one would want for organizing activities for a group — or coordinating a free software project. For privacy minded folks, there's no reason that Crabgrass couldn't be used to set up a Facebook-like service with a privacy friendly bent running on FOSS.

The only potential problem for Crabgrass is that the politics of the group may alienate even moderate political types, to say nothing of conservative or libertarian FOSS contributors. When this reporter finds himself more than a little to the right of an organization, it's saying something. There have also been complaints that Crabgrass development is less than transparent. That said, Crabgrass is a very valuable project and it would be a shame if it were not adopted by more projects. If you're interested in becoming involved, there is a developer's network for active Crabgrass contributors. However, to participate in the discussions and editing pages, etc., you must request access first. The mailing lists, however, are open and have a public archive.

Despite the low version number, Crabgrass appears to be fairly mature software and to be used already by a fairly large network of users. Free and open source projects looking for a social networking/organization platform should look into it.

Comments (3 posted)

Brief items

Quotes of the week

-- Chicken Dance License v0.1

-- Laura Creighton

Comments (2 posted)

GCC 4.6.0 released

The GCC 4.6.0 release announcement has gone out. There is a long list of changes for this release, including support for the Go language, improved C++0x support, many optimization improvements including a "scalable whole program optimizer" which is said to be stable enough to use, a new -Ofast option, and more.

Comments (97 posted)

GNOME Tweak Tool 2.91.93 released

The "GNOME Tweak Tool" is a handy gadget which allows the adjustment of a number of configuration settings that the GNOME developers felt would not be of interest to ordinary users. That includes things like the fonts used in user interface elements. The 2.91.93 release puts the code under GPLv3 and adds some clock-tweaking options.

Full Story (comments: none)

LibreOffice celebrates six months

The LibreOffice project is celebrating its six-month birthday. "What we have seen now is just the beginning of something very big. The Document Foundation has a vision, and the creation of the foundation in Germany is about to happen soon. LibreOffice has been downloaded over 350,000 times within the first week, and we just counted more than 1,3 million downloads just from our download system - not counting packages directly delivered by Linux distributors, other download sites or DVDs included in magazines and newspapers - supported by 65 mirrors from all over the world, and millions already use and contribute to it worldwide."

Full Story (comments: 2)

Monotone 1.0 released

The venerable monotone distributed source code management system has finally seen its 1.0 release. "This is a major milestone, and a lot of effort has been made to make this release a reality. It contains quite a number of bug fixes, changes and new features."

Full Story (comments: 4)

2011 Python Language Summit report

Brian Curtin has posted a summary of the 2011 Python Language Summit, held on March 10. There is a lot of information on where the language can be expected to go. "With the start of development on CPython 3.3, the moratorium on language changes has been lifted. While the flood gates are open, language changes are expected to be conservative while we try to slow the rate of change and continue to allow alternative implementations to catch up. Although no one caught up to the 3.x line thanks to the moratorium, PyPy and IronPython recently reached 2.7 compatibility, and IronPython is beginning down the road to 3.x." This summary is one of the inaugural posts on the new "Python Insider" weblog.

Comments (1 posted)

SeaMonkey 2.0.13 Security Update

SeaMonkey 2.0.13 has been released. This version includes an update to the HTTPS certificate blacklist. "We strongly recommend that all SeaMonkey and old suite users upgrade to this latest release."

Full Story (comments: none)

Newsletters and articles

Development newsletters from the last week

• Caml Weekly News (March 29)
• PostgreSQL Weekly News (March 27)
• Tcl-URL! (March 29)

Comments (none posted)

Fellowship interview with Dan Leinir (FSFE)

The FSFE interviews Dan Leinir Turthra Jensen, who develops GamingFreedom.org, which is a social networking site devoted to free culture and the Gluon gaming framework. "Gluon Player is then the collective name for a set of applications on a bunch of different platforms and form factors: Gluon Player Touch for tablets and the like, Gluon Player for the desktop, Gluon Player Mobile for touch based smartphones. These apps all connect to GamingFreedom.org and let you both download and play the games uploaded there, but also comment on them, rate them, even donate to the people who made the game if you think that they’re deserving."

Comments (none posted)

Kleckner: Unladen Swallow Retrospective

Unladen Swallow developer Reid Kleckner has posted a look back at the project (which was working on an LLVM-accelerated Python implementation) and why it ended up so fiercely pining for the fjords. "Finally, the signals we were getting from python-dev were not good. There was an assumption that if Unladen Swallow were landed in py3k, Google would be there to maintain it, which was no longer the case. If the merge were to have gone through, it is likely that it would have been disabled by default and ripped out a year later after bitrot. Only a few developers seemed excited about the new JIT."

Comments (6 posted)

Using Google's WebP Image Format with Open Tools on Linux (Linux.com)

Nathan Willis investigates Linux tools for using the WebP image format over at Linux.com. WebP is a lossy image format (like JPEG) that was introduced by Google back in September. "WebP compression is essentially an adaption of a single frame of WebM video. It, too, breaks the image into blocks (although 4-by-4 in size, rather than 8-by-8), but in place of JPEG's DCT [Discrete Cosine Transform] and high-frequency bit-chopping step, it uses the intra-frame coding algorithm from WebM. Intra-frame coding is the coding down within a single frame, as opposed to between two consecutive frames, and WebM's method involved constructing a prediction for each block based on the blocks adjacent to it. The encoder saves the predictions and the differences between the predictions and the real input blocks in the output file — if prediction is going well, as it should for most continuous-tone images like photos, the output is smaller than the raw input — and the result compressed with lossless techniques."

Comments (8 posted)

Page editor: Jonathan Corbet

Announcements

Articles of interest

Google Holds Honeycomb Tight (Business Week)

Business Week reports that Google will be holding back the source to the Android "Honeycomb" release until it's "ready." "Google says it will delay the distribution of its newest Android source code, dubbed Honeycomb, at least for the foreseeable future. The search giant says the software, which is tailored specifically for tablet computers that compete against Apple's iPad, is not yet ready to be altered by outside programmers and customized for other devices, such as phones."

Comments (50 posted)

How Amazon could loosen Google's iron grip on Android (ars technica)

Ryan Paul speculates on the ramifications of the new Amazon Appstore for Android. "The Amazon Appstore for Android launched last week. Although the online retail giant's new software storefront still has some rough edges, it could eventually have significant ramifications for the entire Android ecosystem. If Amazon's Appstore proves to be a viable alternative to Google's own Android Market, it could weaken the search giant's control over the Android platform and shift the balance of power in a direction that favors hardware makers-opening the door for forks and deeper differentiation. This could prove to be especially significant right now, because Google's decision to withhold the Android 3.0 source code for the foreseeable future has created a need for Android hardware vendors to pursue more autonomy and insulate themselves from Google's increasingly dictatorial control over the operating system."

Comments (38 posted)

New Books

Learn You a Haskell for Great Good!--New from No Starch Press

No Starch Press has released "Learn You a Haskell for Great Good!", by Miran Lipovaca.

Full Story (comments: 2)

Two New Arduino Books from O'Reilly Media

O'Reilly Media has released "Arduino Cookbook" by Michael Margolis and "Arduino Bots and Gadgets" by Tero Karvinen and Kimmo Karvinen.

Full Story (comments: none)

Education and Certification

LPI Hosts Exam Labs at Flourish and Southeast LinuxFest

The Linux Professional Institute (LPI) has announced promotional exam labs for their Linux Professional Institute Certification (LPIC) at the Flourish Conference, April 1-3 in Chicago, Illinois, and the Southeast LinuxFest, June 10-12 in Spartanburg, South Carolina.

Full Story (comments: none)

Calls for Presentations

Linux Plumbers Conference Call For Working Sessions Submissions

The Planning Committee for the Linux Plumbers Conference (LPC) has announced that submissions to the "micro-conferences" portion of the conference is now open. You may also propose additional micro-conferences by selecting the "Microconference Proposals" track in the proposals form, but please also see the "responsibilities of a working session leader". The topics that will actually have working sessions scheduled at the LPC will depend on the submissions to the Microconference and on the ability of its respective community to organize a successful working session.

As noted earlier, the call for presentations (not associated with a micro-conference) is open through April 30.

Comments (none posted)

Call for Papers: Conference on Domain-Specific Languages (DSL 2011)

The Conference on Domain-Specific Languages will be held September 6-8, 2011, in Bordeaux, France. "Papers will be judged on the depth of their insight and the extent to which they translate specific experience into general lessons for software engineers and DSL designers and implementers. Where appropriate, papers should refer to actual languages, tools, and techniques, provide pointers to full definitions, proofs, and implementations, and include empirical results." Abstracts are due April 18.

Full Story (comments: none)

Upcoming Events

Camp KDE updates

Camp KDE 2011 will be held April 4-5, 2011 in San Francisco, CA. "The finalized speaker schedule has been released at http://camp.kde.org. This year's event features keynotes from Jim Zemlin, Executive Director of The Linux Foundation, and Carol Smith, the program administrator for Google Summer of Code."

Full Story (comments: none)

Events: April 7, 2011 to June 6, 2011

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

Date(s)	Event	Location
April 6 April 8	5th Annual Linux Foundation Collaboration Summit	San Francisco, CA, USA
April 8 April 9	Hack'n Rio	Rio de Janeiro, Brazil
April 9	Linuxwochen Österreich - Graz	Graz, Austria
April 9	Festival Latinoamericano de Instalación de Software Libre	,
April 11 April 13	2011 Embedded Linux Conference	San Francisco, CA, USA
April 11 April 14	O'Reilly MySQL Conference & Expo	Santa Clara, CA, USA
April 13 April 14	2011 Android Builders Summit	San Francisco, CA, USA
April 16	Open Source Conference Kansai/Kobe 2011	Kobe, Japan
April 25 April 26	WebKit Contributors Meeting	Cupertino, USA
April 26 April 29	OpenStack Conference and Design Summit	Santa Clara, CA, USA
April 28 April 29	Puppet Camp EU 2011: Amsterdam	Amsterdam, Netherlands
April 29	Ottawa IPv6 Summit 2011	Ottawa, Canada
April 29 April 30	Professional IT Community Conference 2011	New Brunswick, NJ, USA
April 30 May 1	LinuxFest Northwest	Bellingham, Washington, USA
May 3 May 6	Red Hat Summit and JBoss World 2011	Boston, MA, USA
May 4 May 5	ASoC and Embedded ALSA Conference	Edinburgh, United Kingdom
May 5 May 7	Linuxwochen Österreich - Wien	Wien, Austria
May 6 May 8	Linux Audio Conference 2011	Maynooth, Ireland
May 9 May 10	OpenCms Days 2011 Conference and Expo	Cologne, Germany
May 9 May 11	SambaXP	Göttingen, Germany
May 9 May 13	Linaro Development Summit	Budapest, Hungary
May 9 May 13	Ubuntu Developer Summit	Budapest, Hungary
May 10 May 12	Solutions Linux Open Source 2011	Paris, France
May 10 May 13	Libre Graphics Meeting	Montreal, Canada
May 11 May 14	LinuxTag - International conference on Free Software and Open Source	Berlin, Germany
May 12	NLUUG Spring Conference 2011	ReeHorst, Ede, Netherlands
May 12 May 14	Linuxwochen Österreich - Linz	Linz, Austria
May 12 May 15	Pingwinaria 2011 - Polish Linux User Group Conference	Spala, Poland
May 16 May 19	PGCon - PostgreSQL Conference for Users and Developers	Ottawa, Canada
May 16 May 19	RailsConf 2011	Baltimore, MD, USA
May 20 May 21	Linuxwochen Österreich - Eisenstadt	Eisenstadt, Austria
May 21	UKUUG OpenTech 2011	London, United Kingdom
May 23 May 25	MeeGo Conference San Francisco 2011	San Francisco, USA
June 1	Informal meeting at IRILL on weaknesses of scripting languages	Paris, France
June 1 June 3	Workshop Python for High Performance and Scientific Computing	Tsukuba, Japan
June 1 June 3	LinuxCon Japan 2011	Yokohama, Japan
June 3 June 5	Open Help Conference	Cincinnati, OH, USA

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

Audio and Video programs

CeBIT Open Source Forum 2011 videos

Videos from the CeBIT Open Source Forum are available at LinuxProMagazine.

Comments (none posted)

Page editor: Rebecca Sobol