LWN.net Weekly Edition for October 13, 2011

Major releases for two financial applications

Long-time LWN readers will be aware that your editor has an ongoing interest in financially-oriented applications. This is only natural: in the end, purveyors of beer can rarely be convinced to purvey without receiving some sort of financial compensation in return. The simple task of coming up with some beer money leads inexorably to the rather more complicated problems of dealing with banks, tracking that money, running a company, and so on. Until beer is free, one will need financial tools to help with the process of earning, spending, and managing money.

Long-suffering readers will also be aware that your editor has not always been entirely pleased with the state of the art of free software in this area. Two projects working on financial tools have recently announced major releases, so it seems like a good time to have another look at where things stand with free financial applications.

LedgerSMB 1.3.0

The LedgerSMB project began as a fork of SQL-Ledger in 2006; the two projects have since diverged significantly. SQL-Ledger seems to have settled into a slow release pattern with occasional bug fixes and little else. LedgerSMB seems rather more active, with an ambitious roadmap that calls for rewriting almost everything by the time a future 2.0 release comes out. As of the just-announced 1.3.0 release, that process is well advanced but incomplete. Much of the work that was done for this release is aimed at increasing the security of the system, but there are many feature improvements as well.

LedgerSMB is not packaged by many distributions; in any case, it is a sufficiently complex system that some manual installation and setup will be required regardless. It depends on PostgreSQL and a big pile of Perl modules; there is, at least, a helper script to collect the required pieces from CPAN. Setup requires configuring the database, naturally; there is a script to do some of that work, but it did not work without some manual editing. There is also some Apache setup to do; fortunately, the generated configuration file worked pretty well in this case. Once all that was in place, pointing a web browser at the local server yielded a login screen. Once the proper credentials were supplied (they were not what the installation document said they would be) LedgerSMB revealed itself in its full glory.

At its core, LedgerSMB appears to be a relatively complete and capable accounting system. It has all the features one would expect, including support for point-of-sale transactions, employee tracking, fine-grained permissions and separation of duties, check printing, and complicated product descriptions. Once everything is set up, LedgerSMB is undoubtedly adequate to the needs of a number of small businesses. But it still falls short.

LWN, tragically, still keeps one Windows machine around, powered off almost all the time. It exists to access the two remaining IE-only web sites that running the business requires and to run a proprietary small-business accounting system. Replacing that accounting system has been on the "to do" list for years; it is mostly a matter of finding a system that can readily do the same work. LWN cannot possibly be the only small business in this position; the first open-source accounting system that makes replacing QuickBooks easy seems like an almost guaranteed success.

LedgerSMB still cannot do that, for a number of reasons. The first is that there is no way to import data from an existing accounting application; in fact, there is no ready way to import data from financial institutions either. The database schema is available, of course, so one could write tools to do this work. When dealing with tools like QuickBooks, that might mean a painful account-at-a-time process using exported files, but at least it would be possible. The people who make money supporting LedgerSMB may well have scripts to do that kind of work, but they have not contributed them to the program itself.

The web-based interface often feels clunky; nice features like name completion are not provided. Hopefully users remember exactly how every vendor and customer's name was entered; the program will not help them. It is easy to run into obscure error messages that give no clue of how to proceed; see the screenshot to the right for an example. The program can track vendors that need to receive (for example, in the US) 1099 forms at the end of the tax year, but it cannot generate those forms. Report generation is minimal, and there is no provision for exporting data. And so on.

Your editor's conclusion is that LedgerSMB was designed to be - and is being maintained as - a base on which support services can be sold. In other words, companies selling LedgerSMB support are the real users for this project. For them, it seems nearly ideal: a solid platform on which a company's accounting system can be built, or which can be used to implement hosted accounting services. But actually getting the system to a functional point in an existing business will require somebody who knows what they are doing. It thus differs significantly from QuickBooks, which, for all of its many (many!) faults, can be set up and operated with little or no outside assistance at all. LedgerSMB might be suitable as a supported next step for a company that is outgrowing QuickBooks, but it is not, at this time, a good substitute.

Skrooge

Your editor has looked at a number of personal finance applications, but, somehow, had never stumbled across Skrooge before the recently-announced 1.0 release. Skrooge is not a business application; it is meant for personal financial management much like GnuCash, Grisbi, or KMyMoney. Like KMyMoney, it is a KDE application; it offers a surprising degree of slickness, but will not, at this point, become your editor's new tool of choice.

Once again, the first step is importing data; Skrooge is able to import accounts in a number of formats, including the formats often used by banks and the GnuCash on-disk format. In the GnuCash case, though, one needs to ensure that the file name has a .gnucash extension, or Skrooge will fail to import it with mysterious error messages. Once past that little obstacle, the import process works well; it is easy to get started with Skrooge using existing financial records.

Unlike GnuCash, Skrooge is not a double-ledger accounting system. Most users are unlikely to care, but, for those who are concerned about what is going on underneath the GUI, that may be a concern. It provides the operations that one would expect: entry of transactions, scheduled transactions, budgeting, forecasting, reconciliation, portfolio tracking, and so on. The reports are slick, with all the pie charts one could ever want. Pretty much all of the functionality expected from a personal finance program is there.

Your editor found that entry of transactions was a slow process. Skrooge does not remember transactions the way GnuCash does, so every payment to the same vendor requires specifying the amount and category. Payments and deposits are not separated, so payments must be entered explicitly as negative numbers. The handy shortcut of hitting "+" to get the next check number does not work. It does not appear to be possible to enter a transaction without using the mouse. There are also performance issues: when run on data imported from a multi-year GnuCash file, Skrooge required a few seconds to actually enter each transaction. For those with a lot of transactions to enter (all payments, alas, in your editor's case), this all adds up to a slower, less pleasant process.

Some other details are missing as well. For example, when importing transactions, Skrooge is unable to detect duplicates - though it does have a facility for manually merging duplicates after the fact. It also suffers from the scourge of "tooltipitis" - it can be difficult to actually see what is going on in the window because there are always tooltips in the way.

In summary, Skrooge just doesn't seem to have benefited from years of optimization for everyday use like some other programs have. That said, it seems to be a capable tool that will be more than adequate for the needs of a large group of users. Once upon a time, Linux users had no real choice when it came to capable personal finance managers; at this point, there are several entirely acceptable options. At this level, at least, free software developers have managed to scratch this itch in an entirely satisfying way.

Comments (18 posted)

Another solid CyanogenMod release

It's been a while in coming, but CyanogenMod (CM) has released an update to its alternative firmware for Android devices. CM 7.1 doesn't contain a huge number of new features—though it has some, along with a few bug fixes—but it does add support for two dozen new devices, along with experimental support for a half-dozen more. While the project (and its users) may lament the six-month gap between 7.0 and 7.1, just the sheer amount of work to build and test the code for a total of 68 devices had to eat up a fair chunk of that time.

CM 7.1 is based on the Android 2.3.7 ("Gingerbread") source code, which is the latest version that Google has released. Android 2.3.7 is, itself, a fairly minor upgrade from the 2.3.3 that was incorporated into CM 7.0. Big changes to the Android core can't really be expected until Google releases the 4.0 ("Ice Cream Sandwich") code. 4.0 is expected to be announced soon and will merge the phone-oriented functionality of 2.3.x with the tablet-oriented features of Android 3.0 ("Honeycomb"). It is also expected that Google will release source code for 4.0 sometime (hopefully, shortly) thereafter. It will be interesting to see how quickly CM comes out with a release that incorporates that code.

In the meantime, though, there are a number of interesting things to try in CM 7.1. One feature that may not be so important to regular users is a real boon for reviewers: a screen shot option in the power-button menu. Screen shots could be taken using the SDK in previous releases, but this is much more convenient. Holding the power button for a second or so brings up the usual CM menu choices for things like power down, reboot, airplane mode, and so on, but it now has a screen shot option as well. Choosing that option will take a shot a second or two later (after the power-button menu has disappeared).

A more generally useful feature, at least for privacy-conscious users, is the ability to revoke individual permissions for apps. Android has a set of permissions that apps can request, but the user only has a choice to either approve them all or not install the app. CyanogenMod has taken a different approach that allows users to individually revoke permissions from installed applications.

In order to do that, one must enable the "Permission management" option in the CyanogenMod application settings dialog. Doing so brings up a scary warning about apps malfunctioning and exiting. Additionally, the warning is very clear that CM doesn't want to hear bug reports about misbehaving apps when their permissions have been revoked. Clicking through the warning allows a user to manage the permissions granted to an app via "Manage applications" in the Applications settings menu.

The actual interface is a little non-obvious. Permissions are listed with a check mark next to them, which would seem to indicate whether they are on or off, but touching the check mark doesn't do anything. Instead, touching the actual text of the permission will put a strike-through line over the text (seen at right) and turn off the corresponding permission. Turning off "Network communication" and "Your location" for Angry Birds didn't cause any noticeable problems—unless one misses the ads. It's not at all clear why the game needs location information, anyway (though one might guess it is for geo-targeting the ads). Likewise, turning off the location permission for a Rugby World Cup app seemed completely benign.

One can imagine that turning off permissions for storage or things like contacts might make some apps misbehave. But it would seem that apps already need to deal with the possibility that networking and location information may not be available. K-9 Mail, for example, just gives an error when checking for mail with its network permission revoked. Apps can certainly be written to be robust in the face of errors, but, based on the warning, it would seem that many are not. Perhaps that's not surprising since those errors are "impossible" given the assumption that the permissions requested are always granted.

One of the main "selling" points of CM is its customizability. Lots of new things have been added to the "Settings" app, beyond just permissions revocation, but it can be a little difficult to figure out what's new. The change log for the release (scroll down a ways) can help. Coupling that with a Google search for the features mentioned there can also shed some light on how to actually use the new settings. A depth-first search through the settings tree is always an eye-opening experience as well.

Some of the new settings were immediately, and obviously, useful to me. Those include hiding the "hold" button in phone calls (so that it can't be inadvertently ear-activated), some new lockscreen widgets and options, and binding the up and down swipe gestures to particular actions. The new ADWLauncher transitions when switching between desktops are amusing, but hardly mission-critical. The LED notification system has been completely overhauled for CM 7.1, which allows users very detailed control over which apps can use the LED, which color it should use, the blink rate of the LED, and more.

Some additions to the camera app are likely to be popular, including the addition of a self-timer. The touch-to-focus feature is one that has appeared and disappeared in the CM 7.0.x series, with numerous requests to see it return, and it has. Both of those features can be accessed from the settings button in the camera app. Muting the shutter-click sound is another new option, but it is accessed from the "Sounds" menu in the "CyanogenMod" section of the settings app. Doing so does bring up a warning about the feature's possible illegality in some jurisdictions, however.

Installing CM 7.1 on a Nexus One and a Nook Color was quite simple using the Rom Manager app, but it can also be done by placing a zip file on the SD card (after backing things up using the ClockworkMod recovery tool, of course). The release has proved quite stable over a few days use on both devices, and it would seem that some annoying audio bugs I had experienced with CM 7.0 on the phone were excised as well. Though swiping notifications to remove them seems to be working better than it did before, it still doesn't work consistently for me, which starts to make me suspect a dexterity problem with the user rather than a bug.

CM 7.1 is a nice incremental update for folks that are using CM 7 and definitely makes a good replacement for those still running stock Android—though one has to guess that the only Android-using LWN readers doing that are stuck with phones that can't be jailbroken, or aren't supported by CM. What CM (and Android) users are really waiting for, though, is a version that incorporates the latest code from Google. Once that code drops—if it doesn't, Google will really need to admit that Android is not open source—folks will be waiting with bated breath for CM 8.0 (or whatever it is called). That clock hopefully starts soon ...

Comments (24 posted)

GNU adopts a healthcare project

The GNU project officially gave its blessing to GNU Health at the end of August. The application (which was formerly known only as "Medical") is a free software environment designed to run a medical clinic or small hospital — including patient records, administration, and resource management. It is the flagship application of the Argentina-based GNU Solidario effort.

At the front desk

In terms of scope, GNU Health focuses on two key areas of hospital or clinical practice: electronic medical records (EMR), and hospital information systems (HIS). The site also lists "health information system" as one of its bullet points, although this term does not have as clear of a definition. Generally speaking, GNU Health focuses on what it calls "family and preventative medicine," which includes treatment for ongoing conditions, nutrition and immunizations, basic lab tests and screening, and prenatal and newborn care. Support for advanced functions one might find in a large hospital (such as drug trials or medical imaging) is spottier.

In the early days, Medical was based on OpenERP, a modular GPL-licensed enterprise resource planning (ERP) package. When OpenERP released its 6.0 update, however, the project changed its licensing terms to adopt a custom OpenERP Public License modeled on the Mozilla Public License. At that point, the GNU Health team determined that the new license was not compatible with the GPL, and switched over to the Tryton framework for further development. Tryton is based on an earlier (4.2) release of OpenERP, but the two frameworks have diverged significantly since the fork in 2008.

Tryton is written in Python and uses PostgreSQL as its database layer. Although for a while both OpenERP and Tryton were supported, the latest release of GNU Health (1.3.3) runs only on Tryton, and requires Tryton 2.0.x. Tryton (and, thus, GNU Health) provides separate client and server packages; the only client option at the moment is a Python and GTK+ GUI, although a web front end is in development.

Getting and installing the latest GNU Health release is a bit of a headache, in large part because the project is only halfway finished with its transition from its previous hosting platform to the Savannah servers provided by GNU. The documentation is split between the GNU site, the old "Medical" project at SourceForge, and the GNU Solidario project site (which includes an ominous-looking banner warning that the underlying hosting service, Amazee.com, will shut down on December 23).

There are directions on the wiki, however, both for installing the latest Tryton release and adding in the GNU Health modules. The GNU Health package includes a configure script which did not work for me, but manually installing the modules seemed sufficient. Best of all, there is a demo data set in the GNU Health package, which allows you to explore the system even if you do not have an actual medical practice handy.

On the record

GNU Health's EMR side encompasses everything that could be called patient records: personal and family medical history, physical condition, prescription and treatment records, genetic and hereditary records, and test results. It can function as a "paperless chart" for office visits, and the administrators can perform statistical analysis on the population as a whole, for use in tracking historical trends or in epidemiology. The system does not directly incorporate test results from medical imaging scans (X-rays, etc.), although users can attach them as external files.

As far as the format of the records themselves is concerned, there is not an agreed-upon standard for EMRs, which can make exchanging records between institutions difficult. The closest thing to an interchange format is the Health Level 7 message format (HL7), which has been developed in the US since the 1980s and has been adopted in several other countries. GNU Health does not yet produce or consume HL7 messages, although lead developer Luis Falcón said it can export records in several output formats (XML included) which can be transformed into HL7.

GNU Health does take care to conform to existing data standards for potentially tricky information types such as diagnoses and disease names. It builds in the International Classification of Diseases (ICD-10) for coding diseases and symptoms, GeneCards for genetics, World Health Organization Essential Medicines for medicine, and various other standardized scales and prediction rules (for example the Glasgow Coma Scale for assessing a patient's level of consciousness) to normalize input. Thus, even if GNU Health's data format is not based on an established standard, the hope is that at least its semantic data is.

Taking care of business

The system's HIS functions cover basic office management tasks and connecting to a billing system. For patients, this means scheduling appointments and tests, for doctors it means making schedules and alerting them to test results, and for staff it means scheduling the use of examination rooms or other facilities and managing inventory. GNU Health can track prescriptions, although it does not automatically place orders or send notifications for refills.

On the billing side, GNU Health can create invoices, but it does not yet include a full-fledged accounting program. Likewise (and for those in the US, more importantly), it can associate basic insurance plan information with a patient record, but the claims process must still be navigated manually. Human resources (i.e., managing employees and schedules) is supported, because it is a common enough ERP task to be included in Tryton by default.

In short, GNU Health fills out a solid system for running a small-to-medium-sized clinic or hospital, but might not meet the needs of very high-traffic or long-term care facilities. The insurance and billing systems are probably better suited for regions with less complicated medical/insurance industries, but this is certainly well in line with GNU Solidario's concern with building tools to serve underprivileged communities. The site maintains a list of institutions using GNU Health in the field, including hospitals in the Philippines, Tanzania, Argentina, and Indonesia.

At this point, what the project has the greatest need for is documentation and translators. Making the project-hosting-transition is undoubtedly a time-consuming task, but I learned of several key features of GNU Health only through an email conversation with Falcón. For example, the system is designed to peer multiple sites together, in a single database, and he said that remote nodes are able to cope with unreliable upstream connections. Both are extremely useful features, particularly in rural or under-served areas of the world where power is unreliable, but neither feature is documented (at least that I was able to find).

Falcón funds his development work on the code with a GNU Health consulting service called Thymbra. In addition to Thymbra, there is a Tryton development company which also offers support to businesses using GNU Health.

Relationship to other free tools

My initial reaction upon reading the GNU Health announcement was confusion, because I remembered the existence of the similar-sounding GNUmed project, which is also still active, and also built with Python and PostgreSQL.

The two are different, however. GNU Health is designed to serve as a full practice-management suite, rolling the appointment scheduling, tests, prescriptions, and on up through invoicing into a single system. GNUmed is focused entirely on building an EMR system alone. Of course, there are always gray areas — because GNUmed is aware of clinic staff members (primarily for tracking tests and messages), it also has a very basic HR module. But many of the other practice-management tasks that GNU Health builds in directly — such as maintaining an appointment calendar — GNUmed hands off to external calendaring applications. In exchange, you do get a more complex EMR system from GNUmed, with health risk calculators, document sign-off, and direct import of imaging data.

At the other end of the spectrum is a high-end system like the US Department of Veterans Affairs' VistA, which we covered in March. VistA is a complete multi-site hospital-management system that incorporates far more than GNU Health, including inpatient care, electronic prescriptions, and much more. But it comes at the price of significantly higher IT overhead. In contrast, almost anyone who can install a web server can install Tryton and GNU Health.

Although it would be nice to see regular cooperation (or at least communication) between partially-overlapping projects like GNUmed and GNU Health, what is more important is that both are installable today, by people for whom the proprietary software alternatives are far out of reach.

Comments (3 posted)

Page editor: Jonathan Corbet

Security

Enforcing password strength

There have been a lot of high-profile site compromises of late (kernel.org, Linux.com, MySQL, WineHQ, ...), most or all of which have led to password disclosure. Hopefully all of the disclosed passwords were stored as hash values, but, even so, sufficiently motivated attackers may well be able to crack some of the passwords via brute force or other means. Because passwords are often reused between sites, these compromises have made projects and others concerned about the security of the passwords granting access to their sites.

That concern led Kevin Fenzi of the Fedora infrastructure team to put out a message noting that all Fedora Account System (FAS) users are required to change their password (and SSH public keys, more about that below). As Fenzi said, the password change is not because of any known compromise of the Fedora infrastructure, but is, instead, a reaction to the recent compromises: "due to the large number of high profile sites with security breaches in recent months, that this is a great time for all Fedora contributors and users to review their security settings and move to 'best practices' on their machines." Part of those "best practices" is to have a strong password, so Fedora is enforcing some rules on the new passwords:

I asked Fenzi in an email where the rules came from, and he pointed me to a Fedora infrastructure bug ticket and the report [PDF] from the University of Amsterdam that it references. That report looks at various password cracking methods and estimates that using those guidelines (actually just the first three) will result in passwords that will take ten years or more to crack at 2 billion guesses per second. That rate was an average of what the researchers found that a modern GPU-equipped system could guess for several different hash algorithms.

As Przemek Klosowski points out, the number of possibilities for each kind of password differ widely. There is a math error in the length-12 case (should be (24+10)^12), and evidently Klosowski is only considering 24 letters, rather than the 26 in English, but his conclusion still stands: the number of possibilities are ten orders of magnitude apart from the first to the last rule. In the end, that doesn't really matter, as long as the weakest choice is sufficient.

Most who commented on the requirement were not particularly annoyed by the password change mandate, but the same cannot be said about the SSH key requirement. SSH users may tend to be more security savvy and are thus less likely to have lost control of their private SSH key than they are to have an easily cracked password—though of course that's no guarantee. But if the private SSH key that corresponds to the public key installed on the FAS servers has been compromised, it's likely that's because the owner's system has been breached. If that's the case, generating a new SSH key on a compromised system will likely only result in another compromised key. In addition, a massive SSH key flag day has its own dangers as Simo Sorce points out:

There is a strong belief that the kernel.org compromise was done via a compromised SSH key, however, so the infrastructure team is requiring folks to change their keys. Many are not happy about it, including Sorce who goes on to say:

Sorce's complaint is a reasonable one. Unfortunately, it's hard to know whose keys may have been compromised (or, indeed, if any have been compromised at all) as several folks mentioned. By bringing it up and requiring everyone to change their keys, it may result in better security—and will at least raise the awareness level of the problem, which could result in better security practices by some who were being lax. It is undoubtedly annoying to those who have been careful with their keys, but it isn't that hard to generate and use a new key, even if it is only used for FAS.

Raising the level of awareness of these issues is perhaps the only good thing that has come from these high-profile break-ins. It is pretty easy to get complacent about security, reuse passwords on many sites, have password-less SSH keys, and so on. Events like the kernel.org breach can help break us all of our lax security habits. Certainly many sites, projects, and organizations—even those who haven't suffered a breach—are looking at their security practices; it's a good time for individuals to do so as well.

Passwords are only part of the story, of course, but they tend to be on the "front-line" of the security of our systems, so it is a good place to start. As xkcd so eloquently put it, the time for relatively short but "hard" to guess passwords may well be behind us: pass phrases are more easily remembered and less easily cracked. It's good to see that Fedora is not enforcing a limit on the password length, it's likely that many other sites do have a fairly short limit that will make using pass phrases harder. The Fedora rules do provide some good guidelines to follow when creating passwords or phrases.

Having too many passwords is almost as bad as having too few, because managing them securely can be quite a headache. One suggestion that Fenzi made is to use a password manager program like "revelation, gnome-keyring, seahorse, or keepassx". Looking more closely at those kinds of applications is on my to-do list, for both personal and professional reasons. Look for an article on that topic to appear on your virtual doorstep in the near future.

Comments (36 posted)

Brief items

Security quotes of the week

-- Wired reports on a virus infecting US drone aircraft

-- Marcus J. Ranum

-- Evgeny Morozov reviews Susan Landau's Surveillance or Security? (via Bruce Schneier)

Comments (none posted)

An analysis of alleged German governmental malware

The Chaos Computer Club claims to have analyzed a rootkit used by the German government. "The malware can not only siphon away intimate data but also offers a remote control or backdoor functionality for uploading and executing arbitrary other programs. Significant design and implementation flaws make all of the functionality available to anyone on the internet."

Comments (25 posted)

WineHQ database compromised

Codeweavers has announced that access to the WineHQ database has been compromised. "On the one hand, we saw no evidence of harm to any database. We saw no evidence of any attempt to change the database (and candidly, using the real appdb or bugzilla is the easy way to change the database). Unfortunately, the attackers were able to download the full login database for both the appdb and bugzilla. This means that they have all of those emails, as well as the passwords. The passwords are stored encrypted, but with enough effort and depending on the quality of the password, they can be cracked." Anybody who has reused a password stored there probably wants to make some changes fairly soon.

Comments (29 posted)

New vulnerabilities

apache: mod_proxy reverse proxy exposure

Package(s):	apache	CVE #(s):	CVE-2011-3368
Created:	October 10, 2011	Updated:	November 10, 2011
Description:	From the Mandriva advisory: The mod_proxy module in the Apache HTTP Server 1.3.x through 1.3.42, 2.0.x through 2.0.64, and 2.2.x through 2.2.21 does not properly interact with use of (1) RewriteRule and (2) ProxyPassMatch pattern matches for configuration of a reverse proxy, which allows remote attackers to send requests to intranet servers via a malformed URI containing an initial @ (at sign) character.
Alerts:	Ubuntu USN-1259-1 2011-11-11 CentOS CESA-2011:1392 2011-11-09 openSUSE openSUSE-SU-2011:1217-1 2011-11-04 SUSE SUSE-SU-2011:1215-1 2011-11-04 SUSE SUSE-SU-2011:1229-1 2011-11-09 Scientific Linux SL-http-20111020 2011-10-20 Scientific Linux SL-http-20111020 2011-10-20 CentOS CESA-2011:1392 2011-10-20 Red Hat RHSA-2011:1391-01 2011-10-20 Red Hat RHSA-2011:1392-01 2011-10-20 Mandriva MDVSA-2011:144 2011-09-08 Debian DSA-2405-1 2012-02-06 openSUSE openSUSE-SU-2012:0248-1 2012-02-09 openSUSE openSUSE-SU-2012:0212-1 2012-02-09 Slackware SSA:2012-041-01 2012-02-10 Red Hat RHSA-2012:0128-01 2012-02-13 CentOS CESA-2012:0128 2012-02-14 Oracle ELSA-2012-0128 2012-02-14 Scientific Linux SL-http-20120214 2012-02-14 Fedora FEDORA-2012-1598 2012-02-21 Red Hat RHSA-2012:0323-01 2012-02-21 Fedora FEDORA-2012-1642 2012-03-06 Scientific Linux SL-http-20120306 2012-03-06 Oracle ELSA-2012-0323 2012-03-09 Gentoo 201206-25 2012-06-24 openSUSE openSUSE-SU-2013:0243-1 2013-02-05 openSUSE openSUSE-SU-2013:0248-1 2013-02-05

Comments (none posted)

cups: arbitrary code execution

Package(s):	cups	CVE #(s):	CVE-2011-3170
Created:	October 10, 2011	Updated:	October 12, 2011
Description:	From the Mandriva advisory: The gif_read_lzw function in filter/image-gif.c in CUPS 1.4.8 and earlier does not properly handle the first code word in an LZW stream, which allows remote attackers to trigger a heap-based buffer overflow, and possibly execute arbitrary code, via a crafted stream, a different vulnerability than CVE-2011-2896 (CVE-2011-3170).
Alerts:	Debian DSA-2354-1 2011-11-28 Mandriva MDVSA-2011:147 2011-10-11 Gentoo 201207-10 2012-07-09

Comments (none posted)

cyrus-imapd: access restriction bypass

Package(s):	cyrus-imapd-2.2	CVE #(s):	CVE-2011-3372
Created:	October 7, 2011	Updated:	October 14, 2011
Description:	From the Debian advisory: CVE-2011-3372: Stefan Cornelius of Secunia Research discovered that the command processing of the NNTP server implementation (nttpd) of cyrus-imapd is not properly implementing access restrictions for certain commands and is not checking for a complete, successful authentication. An attacker can use this flaw to bypass access restrictions for some commands and, e.g. exploit CVE-2011-3208 without proper authentication.
Alerts:	Scientific Linux SL-cyru-20111201 2011-12-01 Oracle ELSA-2011-1508 2011-12-01 Oracle ELSA-2011-1508 2011-12-01 Oracle ELSA-2011-1508 2011-12-01 CentOS CESA-2011:1508 2011-12-01 CentOS CESA-2011:1508 2011-12-01 Red Hat RHSA-2011:1508-01 2011-12-01 openSUSE openSUSE-SU-2011:1170-1 2011-10-24 Mandriva MDVSA-2011:149 2011-10-14 Debian DSA-2318-1 2011-10-06

Comments (none posted)

kdelibs: certificate spoofing

Package(s):	kdelibs	CVE #(s):	CVE-2011-3365 CVE-2011-3366
Created:	October 11, 2011	Updated:	November 10, 2011
Description:	From the KDE advisory: When displaying a security dialog with a certificate, KSSL does not properly force its QLabels to use QLabel::PlainText. As a result, if given a certificate containing rich text in its fields, it will render the rich text. Specifically, a certificate containing a common name (CN) that has a table element will cause the second line of the table to be displayed. This can allow spoofing of the certificate's common name.
Alerts:	CentOS CESA-2011:1385 2011-11-09 Mandriva MDVSA-2011:162 2011-11-01 Ubuntu USN-1248-1 2011-10-25 Scientific Linux SL-kdel-20111019 2011-10-19 CentOS CESA-2011:1385 2011-10-19 Red Hat RHSA-2011:1385-01 2011-10-19 openSUSE openSUSE-SU-2011:1135-1 2011-10-17 Scientific Linux SL-kdel-20111011 2011-10-11 Red Hat RHSA-2011:1364-01 2011-10-11

Comments (none posted)

kernel: two information leaks

Package(s):	kernel	CVE #(s):	CVE-2011-1161 CVE-2011-1162
Created:	October 6, 2011	Updated:	November 28, 2011
Description:	According to the Red Hat bugzilla entry, both of these are information leaks of some kind in the TPM driver.
Alerts:	Ubuntu USN-1311-1 2011-12-19 Ubuntu USN-1303-1 2011-12-13 Ubuntu USN-1299-1 2011-12-13 Ubuntu USN-1294-1 2011-12-08 Scientific Linux SL-kern-20111129 2011-11-29 CentOS CESA-2011:1479 2011-11-30 Oracle ELSA-2011-1479 2011-11-30 Red Hat RHSA-2011:1479-01 2011-11-29 Oracle ELSA-2011-1465 2011-11-28 Oracle ELSA-2011-2033 2011-11-28 Oracle ELSA-2011-2033 2011-11-28 Scientific Linux SL-kern-20111122 2011-11-22 Red Hat RHSA-2011:1465-01 2011-11-22 Fedora FEDORA-2011-13809 2011-10-05 Ubuntu USN-1318-1 2012-01-05 Ubuntu USN-1319-1 2012-01-05 Red Hat RHSA-2012:0010-01 2012-01-10 Ubuntu USN-1325-1 2012-01-11 Ubuntu USN-1323-1 2012-01-11 Ubuntu USN-1332-1 2012-01-13 Ubuntu USN-1337-1 2012-01-23 Ubuntu USN-1341-1 2012-01-23 Ubuntu USN-1345-1 2012-01-24 Oracle ELSA-2012-0150 2012-03-07

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2011-2521 CVE-2011-2898
Created:	October 6, 2011	Updated:	October 12, 2011
Description:	From the Red Hat advisory: A flaw was found in the Linux kernel's Performance Events implementation. It could falsely lead the NMI (Non-Maskable Interrupt) Watchdog to detect a lockup and panic the system. A local, unprivileged user could use this flaw to cause a denial of service (kernel panic) using the perf tool. (CVE-2011-2521, Moderate) Flaws were found in the tpacket_rcv() and packet_recvmsg() functions in the Linux kernel. A local, unprivileged user could use these flaws to leak information to user-space. (CVE-2011-2898, Low)
Alerts:	Scientific Linux SL-kern-20111005 2011-10-05 Red Hat RHSA-2011:1350-01 2011-10-05 Red Hat RHSA-2012:0010-01 2012-01-10 Debian DSA-2389-1 2012-01-15 openSUSE openSUSE-SU-2012:0206-1 2012-02-09 openSUSE openSUSE-SU-2012:0236-1 2012-02-09

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2011-3353
Created:	October 10, 2011	Updated:	November 28, 2011
Description:	From the SUSE advisory: In the fuse filesystem, FUSE_NOTIFY_INVAL_ENTRY did not check the length of the write so the message processing could overrun and result in a BUG_ON() in fuse_copy_fill(). This flaw could be used by local users able to mount FUSE filesystems to crash the system.
Alerts:	Oracle ELSA-2011-1465 2011-11-28 Oracle ELSA-2011-2033 2011-11-28 Oracle ELSA-2011-2033 2011-11-28 Scientific Linux SL-kern-20111122 2011-11-22 Red Hat RHSA-2011:1465-01 2011-11-22 openSUSE openSUSE-SU-2011:1222-1 2011-11-08 openSUSE openSUSE-SU-2011:1221-1 2011-11-08 SUSE SUSE-SA:2011:041 2011-10-17 SUSE SUSE-SU-2011:1101-1 2011-10-10 SUSE SUSE-SU-2011:1100-1 2011-10-10 Ubuntu USN-1319-1 2012-01-05 Red Hat RHSA-2012:0010-01 2012-01-10 Ubuntu USN-1325-1 2012-01-11 Ubuntu USN-1329-1 2012-01-13 Debian DSA-2389-1 2012-01-15 Ubuntu USN-1361-1 2012-02-13 Ubuntu USN-1362-1 2012-02-13 Ubuntu USN-1386-1 2012-03-06 Ubuntu USN-1387-1 2012-03-06 SUSE SUSE-SU-2012:0364-1 2012-03-14

Comments (none posted)

libxml2: denial of service

Package(s):	libxml2	CVE #(s):	CVE-2011-2821 CVE-2011-2834
Created:	October 10, 2011	Updated:	September 27, 2012
Description:	From the Mandriva advisory: Double free vulnerabilities in libxml2 allows remote attackers to cause a denial of service or possibly have unspecified other impact via a crafted XPath expression and via vectors related to XPath handling (CVE-2011-2821, CVE-2011-2834).
Alerts:	Scientific Linux SL-libx-20111206 2011-12-06 Red Hat RHSA-2011:1749-03 2011-12-06 Gentoo 201111-01 2011-11-01 Gentoo 201110-26 2011-10-26 Mandriva MDVSA-2011:145 2011-10-09 Red Hat RHSA-2012:0016-01 2012-01-11 Red Hat RHSA-2012:0017-01 2012-01-11 CentOS CESA-2012:0016 2012-01-11 CentOS CESA-2012:0017 2012-01-11 openSUSE openSUSE-SU-2012:0073-1 2012-01-12 Oracle ELSA-2012-0016 2012-01-12 Scientific Linux SL-libx-20120111 2012-01-11 Scientific Linux SL-libx-20120112 2012-01-12 Oracle ELSA-2012-0017 2012-01-12 Ubuntu USN-1334-1 2012-01-19 Debian DSA-2394-1 2012-01-26 Oracle ELSA-2012-0324 2012-03-09 Fedora FEDORA-2012-13820 2012-09-26 Fedora FEDORA-2012-13824 2012-09-27 Red Hat RHSA-2013:0217-01 2013-01-31 CentOS CESA-2013:0217 2013-02-01 Oracle ELSA-2013-0217 2013-02-01 Scientific Linux SL-ming-20130201 2013-02-01

Comments (none posted)

openswan: denial of service

Package(s):	openswan	CVE #(s):	CVE-2011-3380
Created:	October 6, 2011	Updated:	October 14, 2011
Description:	From the Red Hat advisory: A NULL pointer dereference flaw was found in the way Openswan's pluto IKE daemon handled certain error conditions. A remote, unauthenticated attacker could send a specially-crafted IKE packet that would crash the pluto daemon. (CVE-2011-3380)
Alerts:	Fedora FEDORA-2011-13862 2011-10-05 Fedora FEDORA-2011-13864 2011-10-05 Scientific Linux SL-open-20111005 2011-10-05 Red Hat RHSA-2011:1356-01 2011-10-05

Comments (none posted)

php: arbitrary code execution

Package(s):	php	CVE #(s):	CVE-2011-3379
Created:	October 10, 2011	Updated:	May 10, 2012
Description:	From the Red Hat bugzilla: It was reported that due to changes in the is_a() function PHP 5.3.7 and 5.3.8 became vulnerable to remote arbitrary code execution when is_a() is used in certain ways. Due to the __autoload() implementation, if a user were able to upload a crafted file, it could be possible to pass the contents of the file as an argument to the __autoload() function which could in turn use that argument as a file to include(). If there was no adequate checking or enforcement of the file to load being, local, this could lead to including a remote script from a remote web site.
Alerts:	Mandriva MDVSA-2011:166 2011-11-03 Fedora FEDORA-2011-13458 2011-09-29 Fedora FEDORA-2011-13446 2011-09-29 Mandriva MDVSA-2012:071 2012-05-10 Gentoo 201209-03 2012-09-23

Comments (none posted)

xorg-x11-server: multiple vulnerabilities

Package(s):	xorg-x11	CVE #(s):	CVE-2010-4818 CVE-2010-4819
Created:	October 7, 2011	Updated:	February 28, 2012
Description:	From the Red Hat advisory: Multiple input sanitization flaws were found in the X.Org GLX (OpenGL extension to the X Window System) extension. A malicious, authorized client could use these flaws to crash the X.Org server or, potentially, execute arbitrary code with root privileges. (CVE-2010-4818) An input sanitization flaw was found in the X.Org Render extension. A malicious, authorized client could use this flaw to leak arbitrary memory from the X.Org server process, or possibly crash the X.Org server. (CVE-2010-4819)
Alerts:	CentOS CESA-2011:1360 2011-11-09 Ubuntu USN-1232-3 2011-10-20 Ubuntu USN-1232-2 2011-10-19 Ubuntu USN-1232-1 2011-10-18 Scientific Linux SL-xorg-20111006 2011-10-06 Scientific Linux SL-xorg-20111006 2011-10-06 CentOS CESA-2011:1359 2011-10-06 Red Hat RHSA-2011:1359-01 2011-10-06 Red Hat RHSA-2011:1360-01 2011-10-06 openSUSE openSUSE-SU-2012:0307-1 2012-02-27

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel remains 3.1-rc9; no prepatches have been released over the last week. The final 3.1 release can be expected in the near future, once Linus returns from vacation.

Numerous subsystem trees have returned to kernel.org over the last week; things should be back to something resembling normal by the time the 3.2 merge window opens.

Stable updates: none have been released in the last week. The 3.0.7 update is in the review process as of this writing; the release can be expected sometime on or after October 13.

Comments (1 posted)

Quotes of the week

-- Why Matthew Garrett prefers UEFI

-- Andrew Morton

Comments (2 posted)

A Plumber's Wish List for Linux

Kay Sievers, Lennart Poettering, and Harald Hoyer have put out a "wish list" of features they (and other plumbers) would like to see added to Linux. The list covers wishes for a bunch of different areas including filesystems, capabilities, control groups, module loading, Unix domain sockets, and more.

Full Story (comments: 100)

Kernel development news

Running distributions in containers

One of the requests in the recently posted "Plumber's Wish List" was for a way for a process to reliably detect that it isn't in the root PID namespace (i.e. is in a "container", at least by some definition). That wish sparked an interesting discussion on linux-kernel about the nature of containers and what people might use them for. Some would like to be able to run standard Linux distributions inside a container, but others are not so sure that is a useful goal.

A container is a way to isolate a group of processes from the rest of a running Linux system. By using namespaces, that group can have its own private view of the OS—though, crucially, sharing the same kernel with whatever else is running—with its own PID space, filesystems, networking devices, and so on. Containers are, in some ways, conceptually similar to virtualization, with the separate vs. shared kernel being the obvious user-visible difference between the two. But there are straightforward ways to detect that you are running under virtualization and that is not true for containers/namespaces.

Lennart Poettering—one of the wishing plumbers—outlined the need for detecting whether a process is running in a child PID namespace:

He goes on to list a number of different things that are not "virtualized" by namespaces, including sysfs, /proc/sys, SELinux, udev, and more. Standard Linux distributions currently assume that they have full control of the system and the init process will do a wide variety of unpleasant things when it runs inside a container. Distributions could make use of a reliable way of detecting containerization to avoid (or change) actions with effects outside the container. Poettering went on to point out that "having a way to detect execution in a container is a minimum requirement to get general purpose distribution makers to officially support and care for execution in container environments".

Eric W. Biederman, who is one of the namespace developers, agreed with the idea: "I agree getting to the point where we can run a standard distribution unmodified in a container sounds like a reasonable goal." He suggested two possible solutions for a straightforward detection scheme (either putting a file into the container's root directory or modifying the output of uname), but also started looking at all of the different areas that will need to be addressed to make it possible to run distributions inside containers. Much of that depends on finishing up the work on user (i.e. UID) namespaces.

But Ted Ts'o is a bit skeptical of the need to run full distributions inside a container. The advantage that containers have over virtual machines (VMs) is that they are lighter weight, he said, and adding multiple copies of system services (he mentions udev and D-Bus) starts to remove that advantage. He wonders if it makes more sense to just use a VM:

In a second message, Ts'o expands on his thinking, particularly regarding security. He is not optimistic about using containers that way: "given that kernel is shared, trying to use containers to provide better security isolation between mutually suspicious users is hopeless". The likelihood that an "isolated" user can find a local privilege escalation is just too high, and that will allow the user to escape the container and compromise the system as a whole. He is concerned that adding in more kernel complexity to allow distributions to run unchanged in containers may be wasted effort:

Biederman, though, thinks that there are situations where it would be convenient to be able to run distribution images "just like I find it [convenient] to loopback mount an iso image to see what is on a disk image". But, firing up KVM to run the distribution may be just as easy, and works today, as Ts'o pointed out. There are more platforms out there than just those that KVM supports, however, so Biederman believes there is a place for supporting containerized distributions:

In the end, Biederman is not convinced that there is a "good reason to have a design that doesn't allow you to run a full userspace". He also notes that with the current implementation of containers (i.e. without UID namespaces), all users in the container are the same as their counterparts outside the container, and that includes the root user. Adding UID namespaces would allow a container to partition its users from those of the "external" system, so that root inside the container can't make changes that affect the entire system:

UID namespaces are still a ways out, Biederman said, so problems with global sysctl settings from within containers can still cause weirdness, but "once the user namespaces are in place accessing a truly global sysctl will result in EPERM when you are in a container and everyone will be happy. ;)". There are some interesting implications of UID namespaces that may eventually need to be addressed, he said, including persistent UIDs in filesystems:

Interesting indeed. One might wonder whether there will be some pushback from other kernel hackers about adding mapping layers to filesystems (presumably in the VFS code so that it works for all of them). Since virtualization can solve many of the problems that are still being worked on in containers (at least for some hardware platforms), there may be questions about adding further kernel complexity to support full-scale containerization as envisioned by Biederman (and others). That is essentially the argument that Ts'o is making, and one might guess that others have similar feelings.

In any case, no patches have yet appeared for detecting that a process is running in a container, but it may not require any changes to the kernel. Poettering mentioned that LXC containers set an environment variable that processes can use for that purpose, and Biederman seemed to think that might be a reasonable solution (and wouldn't require kernel changes as it is just a user-space convention). Making a new UTS namespace (and changing the output of uname) as Biederman suggested would be another way to handle the problem from user space. That part seems like it will get solved in short order, but the more general questions of containers and security isolation are likely to be with us for some time to come.

Comments (7 posted)

Securely deleting files from ext4 filesystems

Deleting a file is sufficient to make it go away as far as the directory structure is concerned; that important, not-backed-up document is gone before the careless user has even removed a repentant finger from the "enter" key. On the underlying storage device, though, parts or all of the doomed file can live on indefinitely. A suitably determined person can often recover data from a file that was thought to be deleted and gone. In some situations, this persistence of data can be most unwelcome. Paper shredders exist for situations where recovery of a "deleted" paper document is undesirable; there is clear value in a similar functionality for filesystem-based files.

A look at the chattr man page indicates that "secure delete" functionality can be enabled for a file by setting the right attribute flag. The only problem is that most filesystems do not actually honor that flag; it's a sort of empty security theater. Even the TSA does a better job. The ext4 secure delete patch set from Allison Henderson may fill that particular gap for the ext4 filesystem, but a few things will need to be fixed up first.

The core part of the patch is relatively straightforward: if part or all of a file is being deleted, the relevant blocks will be overwritten synchronously as part of the operation. By default, the blocks are overwritten with zeroes, but there is an option to use random bytes from the kernel's entropy pool instead. A bit of care must be taken when the file involved contains holes - it wouldn't do to overwrite blocks that don't exist. There is also some logic to take advantage of the "secure discard" feature supported by some devices (solid-state disks, primarily) if that feature is available. Secure discard handles the deletion internally to the device - perhaps just by marking the relevant blocks unreadable until something else overwrites them - eliminating the need to perform extra I/O from the kernel.

The job does not stop there, though. The very existence of the file - or information contained in its name - could be sensitive as well. So the secure delete code must also clear out the directory entry associated with the file (if it is being deleted, as opposed to just truncated, obviously). Associated metadata - extended attributes, access control lists, etc - must also be cleaned out in this way.

Then there is the little issue of the journal. At any given time, the journal could contain any number of blocks from the deleted file, possibly in several versions. Clearly, sanitizing the journal is also required, but it must be done carefully: clearing journal blocks before the associated transaction has been committed could result in a corrupted filesystem and/or the inability to recover properly from a crash. So the first thing that must happen is a synchronous journal flush.

Once any outstanding transactions have been cleared, the (now old and unneeded) data in the journal can be cleaned up. The only problem is that the journal does not maintain any association between its internal blocks and the files they belong to in the filesystem. The patch addresses that problem by adding a new data structure mapping between journal blocks and file blocks; the secure deletion code then traverses that structure in search of blocks in need of overwriting.

The journal cleanup code drew some complaints from developers; the first problem is that directory and metadata blocks are not cleared from the journal. The deeper complaint, though, was that it represented an excessive mixing of the two layers; the filesystem really should not have an overly deep understanding of how the journal works. The end result is that some of this cleanup work is likely to move into the jbd2 journaling layer; as an added benefit, other filesystems should then be able to take advantage of it as well.

Darrick Wong also pointed out that this block mapping is not, itself, written to the journal; if the system were to crash before the journal could be cleaned, that cleanup would not happen after a reboot. He suggested that filesystems should mark blocks in need of secure deletion when they are first added to a journal transaction; the journal code could take care of things from then on. It seems like a cleaner solution, but there is, naturally, a catch.

That catch is that there is no way to create a file with the "secure delete" attribute set; that attribute must be added after the fact. One would assume that users would ask for secure delete before actually writing any data to the file, but associated information (the file name, for example) must exist before the file can be so marked. So the journal may well contain blocks for "secure delete" files that will not be marked for overwriting. There is no way to fix that within the existing POSIX API.

Darrick suggested a few ways to deal with this problem. One is to just give up and tell developers that, if even the name of the file is important, they should create that file under a temporary name, set the "secure delete" attribute, then rename the file to its real name. An alternative would be to mark the blocks for all newly-created files as needing overwriting; that would eliminate the race to get the attribute set at the cost of slowing down all file creation operations. Or, he said, the journal could track the mapping between blocks and files, much as Allison's patch does. One other option would be to mark the entire filesystem as needing secure delete; that feature, evidently, is already in the works, but enabling it will have an obvious performance cost.

The end result is that there are a few details to be worked out yet. The feature seems useful, though, for users who are concerned about data from their files hanging around after the files themselves have been deleted. Perhaps, around the 3.3 kernel or thereafter, "chattr +s" on ext4 will be more than bad security theater.

Comments (24 posted)

Whither btrfsck?

The btrfs filesystem was merged into the mainline in January, 2009 for the 2.6.29 kernel release. Since then, development on the filesystem has accelerated to the point that many consider it ready for production use and some distributions are considering using it by default. The filesystem itself is nearly functionally complete and increasingly stable, but there is still one big hole: there is no working filesystem checker for Btrfs. As user frustration over the lack of this essential utility grows, an interesting question arises: is some software too dangerous to be released early?

This tool (called "btrfsck") has been under development for some time, but, despite occasional hints to the contrary, it has never escaped from Chris Mason's laptop into the wild. This delay has had repercussions elsewhere; Fedora's plan to move to btrfs by default, for example, cannot go forward without a working filesystem checker. Most recently, Chris said that he hoped to be able to demonstrate the program at the upcoming LinuxCon Europe event. That, however, was not enough for some vocal users who have started to let it be known that their patience has run out. Thus we've seen accusations that Oracle really intends to keep btrfs as a private, proprietary tool and statements that "It's really time for Chris Mason to stop disgracing the open source community and tarnishing Oracle's name." Those are strong words directed at somebody who has done a lot to create a next-generation filesystem for Linux.

Your editor would like to be the first to say that both the open source community and Oracle benefit greatly from Chris's presence. The cynical might add that Oracle has delegated the task of "tarnishing its name" to employees who are more skilled in that area. That said, it is worth examining why btrfsck remains under wraps; had the tool been put out in the open - the way the filesystem itself was - chances are good that others would have helped with its development. One could argue that the failure to release btrfsck in any form has almost certainly retarded its development and, thus, the adoption of btrfs as a whole.

According to Chris, the early merging of btrfs was important for the creation of the filesystem's development community:

But, he says, the filesystem checker ("fsck") is a bit different, and is not ready yet even for the braver users:

Josef Bacik expressed the fears that keep btrfsck out of the community more clearly:

He went on to say "Release early and release often is nice for web browsers and desktop environments, it's not so nice with things that could result in data loss." This is a claim that raises some interesting questions, to say the least.

One could start by questioning the wisdom of running a new filesystem like btrfs in production with no backups and no working filesystem repair tool. How is it that releasing the filesystem itself is OK, but releasing the repair tool presents too much of a risk for users? How does that tool really differ from a web browser, especially given that the browser is exposed to all the net can throw at it and bugs can easily lead to exposure of users' credentials or the compromise of their systems? There is no shortage of software out there that can badly bite its users when things go wrong.

That said, there are some unique aspects to the development of filesystem repair tools. They are invoked when things have already gone wrong, so the usual rules of how the filesystem should be structured are out the window. They must perform deep surgery on the filesystem structure to recover from corruptions that may be hard to anticipate and correct; one could paraphrase Tolstoy and say that happy filesystems are all alike, but every corrupted filesystem is unhappy in its own way. As the checker tries to cope with a messed-up filesystem, it works in an environment where any change it makes could turn a broken-but-recoverable filesystem into one that is a total loss. In summary, btrfsck will not be an easy tool to write; it is a job that is almost certainly best left to developers with a lot of filesystem experience and who understand btrfs to its core. That narrows the development pool to a rather small and select group.

And, in the end, no responsible developer wants to release a tool which, in his or her opinion, could create misery for its users. Those users will run btrfsck on their filesystems regardless of any blood-curdling warnings that it may put up first; if it proceeds to destroy their data, they will not blame themselves for their loss. If Chris does not yet believe that he can responsibly release btrfsck for wider use, it is not really our place to second-guess his reasoning or to tell him that he should release it anyway. Anybody who feels they cannot trust him to make that decision probably should not be running the filesystem he designed to begin with.

Releasing software early and often is, in general, good practice for free software development; keeping code out of the public eye often does not benefit it in the long run. Perhaps btrfsck has been withheld for too long, but that is not our call to make. The need for the tool is clear - if nothing else, Oracle has decided to go with btrfs by default in the near future. There can be no doubt that this need is creating a fair amount of pressure. The LinuxCon demonstration may or may not happen, but btrfsck seems likely to make its much-delayed debut before too much longer.

Comments (69 posted)

Patches and updates

Kernel trees

• Thomas Gleixner: 3.0.6-rt17 . (October 7, 2011)

Core kernel code

• Kirill A. Shutemov: Introduce timer slack controller . (October 12, 2011)

Development tools

• jim.cromie@gmail.com: dynamic_debug: add pending queries, etc (~resend) . (October 7, 2011)

• David Howells: Add assertion support with annotated oopsing . (October 12, 2011)

Device drivers

• G, Manjunath Kondaiah: Driver Probe Deferral Mechanism . (October 7, 2011)

• Javier Martinez Canillas: Input: Cypress TTSP device driver . (October 10, 2011)

• Rajendra Nayak: Device tree support for regulators . (October 10, 2011)

• Klaus Schwarzkopf: usb: add new usb gadget for ACM and mass storage . (October 10, 2011)

• Jonathan Cameron: IIO: Proof of concept in kernel interface. . (October 11, 2011)

• Peter Ujfalusi: ASoC/MFD/Input: twl6040: Support for audio driven vibra . (October 12, 2011)

Filesystems and block I/O

• Darrick J. Wong: ext4: Add metadata checksumming . (October 10, 2011)

• Allison Henderson: Ext4 secure delete . (October 10, 2011)

• Christoph Hellwig: RFC: ->make_request support for virtio-blk . (October 10, 2011)

• Arne Jansen: btfs: Subvolume Quota Groups . (October 11, 2011)

Memory management

• Marek Szyprowski: Contiguous Memory Allocator . (October 6, 2011)

• Mel Gorman: Swap-over-NBD without deadlocking V7 . (October 6, 2011)

• Pavel Emelyanov: Slab objects identifiers . (October 11, 2011)

• Sumit Semwal: Introduce dma buffer sharing mechanism . (October 11, 2011)

Networking

• Glauber Costa: per-cgroup tcp memory pressure handling . (October 10, 2011)

• Luis R. Rodriguez: wireless: add DFS master support . (October 12, 2011)

Architecture-specific

• gdavis@mvista.com: [RFC/PATCH v3 0/7] ARM11 MPCore: preemption/task migration cache coherency fixups . (October 11, 2011)

Page editor: Jonathan Corbet

Distributions

Ubuntu's new App Developer site

Ubuntu launched its renovated developer portal at the end of September, consolidating a number of application development tools and documentation resources under one banner: developer.ubuntu.com. The new site still merges a few discrete tasks — such as searching for applications (an end-user activity), developing and distributing applications (a developer activity, naturally), and writing third-party tutorials (a non-developer contributor activity) — but it presents a cleaner, global view of the application development process, particularly for those new to the community.

The announcement (which was written by Ubuntu translations coordinator David Planella) describes the site as the "central point of reference for any topics related to application development. […] a site that should grow organically to provide the tools, share the knowledge and act as the springboard to foster app proliferation and developer community growth." The layout splits the content into four parts: "Get Started," "Resources," "Publish," and "Community" — although the main page also includes several unrelated items, such as a rotating menu of free software and commercial applications that users can find in the Ubuntu Software Center (USC), which is the distribution's new name for its built-in application directory and one-click installer.

The prominence of USC should help clarify exactly who the site is for: this App Developer portal is a resource for people writing third-party applications that they wish to offer to Ubuntu users. It is not, by and large, aimed at people who are interested in learning how to contribute to the distribution itself, or to get their application into one of the official Ubuntu repositories. Ubuntu has run smaller initiatives for independent application developers in the past, including tools such as the templating system Quickly and the GUI revision control utility Ground Control. The App Developer site represents a consolidation of these earlier efforts, with a heavy dose of documentation linked in for good measure.

The nickel tour

Much of the documentation content on the App Developer site consists of links to upstream "official" sources, which can seem a bit confusing when the official source is a page hosted at a different ubuntu.com subdomain. The layout, however, does a good job of splitting up a wide range of topics and organizing them coherently. The "Get Started" section introduces the development environments recommended for writing Ubuntu-compatible applications. Quickly (and with it, PyGTK) comes first, but there are separate sections for Qt Creator, Eclipse, and MonoDevelop. At the moment, the non-Quickly IDEs are sparse in their documentation, relying on external links, but there are some on-site resources, so perhaps the library will expand over time. There also seems to be an unspoken emphasis on developing GUI applications, which is perhaps to be expected for a desktop-oriented distribution.

The "Resources" section is much larger; it encompasses documentation for the current Ubuntu architecture, plus language references (ranging from C to QML to Vala), help for project maintenance tasks (such as hosting and packaging), and tutorials. By volume alone, this is probably the most useful portion of the site. Some of the material is little more than links to projects' external home pages, but even then, the mere act of categorizing and listing the official sites is helpful. After all, above the Linux kernel and low-level toolkits, it may not be obvious to a third-party developer how the various distributions differ from one another. The Resources section lays out precisely what APIs and toolkits ship with (presumably the current version of) Ubuntu, including widespread offerings like OpenGL and D-Bus, but Ubuntu's original projects as well: Application Indicators, the Unity shell, uTouch, etc.

The project maintenance tools section focuses on two of Ubuntu's official choices, Launchpad and Bazaar, which is to be expected, but also includes a variety of other tools created elsewhere, such as Glade and Qt Designer. The thinnest content section is tutorials, which consists of just three original resources right now (four if you count the Quickly tutorial), although the project is soliciting for new submissions in multiple spots around the site. There are a few places where the various categories appear to overlap with each other (for example, the Ubuntu Developer Stack and Ubuntu Platform view repeat a lot of information). On the whole, though, it does not take long to navigate to anything, and there do not seem to be any large pieces overlooked. There are some APIs and frameworks that clearly need more information, for example there does not seem to be any Xine framework documentation on the site, but then again there does not seem to be any Xine documentation anywhere else to which one could link. Even the "official" hacker's guide describes itself as "a pretty free-form document containing a loose collection of articles describing various aspects of xine's internals."

"Publish" is the most specialized section, because it focuses on the process of getting an application reviewed and approved for distribution through USC. Within Ubuntu, USC presents a categorized application directory to users in a GUI installer and is meant to provide a simpler interface to searching for and installing distribution-supplied applications than a full-featured Apt front-end. It is also meant to handle the installation and removal of one-off .deb packages. The USC service provides a way for third-party developers to get their work into the USC application, while keeping it distinct from the official Ubuntu project repositories. As outlined on the site, the process involves registering an account (which is subsequently accessible via the "My Apps" tab on the App Developer site), uploading installable packages and metadata, and (if desired), setting a price. Many of the for-pay offerings seem to be cross-platform games, although not all. All of the submissions are reviewed by an Applications Review Board. The Ubuntu wiki outlines the review process in greater detail, and the board itself will be maintaining a public mailing list and holding open meetings.

Finally, the "Community" section of the site links together a set of development community resources, including lists, IRC channels, and blogs, plus information on application developer events, and an invitation to join the Applications Review Board. Notably, this section of the site is for the application developer community, not the broader Ubuntu user or contributor communities. As such, it does not deal with users' questions, installation or help topics, or many of the other Ubuntu project lists and IRC outlets.

Chapter two

As of press time, a few short weeks after its initial launch, there are areas of the App Developer site that need fleshing-out, but the effort has done an excellent job of building a tightly-focused resource for independent software developers — a task that could easily succumb to feature-creep. For example, although I would like to see the site offer more support resources for non-coding tasks like translation, that subject is already covered in Launchpad. As is, the App Developer site defers to existing documentation, and adding in a discussion of translation tools would duplicate information. Similarly, many community-based translation efforts are coordinated by Ubuntu's LoCos. While linking the "Community" section of the App Developer site directly to those groups might put them in touch, it would also begin to blur the line between developing an independent application and working on the Ubuntu distribution itself.

In its present, streamlined form, the site reaches out to an audience for whom — as far as I am aware — the other large distributions are not building resources. Fedora's only developer documentation is geared towards becoming a contributor to the distribution; there are tidbits that would be helpful to independent application developers, but they are scattered across the project's massive wiki. OpenSUSE comes closer, as it discusses the setup of private projects (particularly in the context of using the Open Build Service), but it is still primarily aimed at distribution collaborators. This is not to suggest that providing contributor portals is bad, it is simply a different group. As the Ubuntu site shows, there are a number of paths that new developers may be on: some may not have extensive experience developing for (or even using) desktop Linux, others may be new to development altogether. Even the simple architecture block diagram provided on the platform overview page helps orient a new developer.

I noticed that GNOME recently added a similar architecture diagram to its developer site (and went one better by making it clickable); KDE's is much wordier, but it, too is reaching out to developers unfamiliar with its stack. As David Nelson recently argued on the Document Foundation mailing list, global design documentation is essential to making a free platform complete: "I would like to put it to you that no software source code is truly open until it has been rendered as understandable as possible to as many people as possible." One of the many reasons that is true is because it lowers the barrier to entry — even if the newcomer is working on a stand-alone application, not contributing to the project core.

Planella described the App Developer site as part of the distribution's ongoing effort at "making Ubuntu a target for app developers." Of course, Canonical does use USC's ability to offer paid applications as one of its revenue sources — the company charges developers a 20 percent cut of the revenue collected for paid application sales. That is cheaper than the 30 percent cut charged by both Apple and Amazon (not including the annual fee both of those companies charge to join their developer programs). A detailed FAQ explains the commercial application process in more detail. For free applications, the primary benefits of distributing a package through USC (rather than, say, a PPA) are the discoverability of USC's application directory and its simplified installation.

But the site is not geared solely towards getting more applications into USC. The Canonical Design Team's blog post about the launch emphasized more of the community-oriented features, which is presumably of greater interest to those writing open source applications. Whether a visitor is writing open or closed applications, the bulk of the site consists of informational resources.

I hope that the site does continue to "grow organically" as Planella suggested, with much-needed tutorials, but also encompassing more tools. Naturally, Launchpad is the best fit for developers looking to deliver typical applications on Ubuntu desktops (if for nothing else than the single sign-on and simplicity of personal package archives), but a strong argument could be made that the App Developer site ought to include resources for Gitorious or GitHub as well, and perhaps explore server-side applications. I would not venture to suggest how best the site can attract high-quality tutorial-writers, but I suspect that inserting "send in your tutorial" banners on the pages will not be sufficient on its own. Ultimately, then, the App Developer site is a good model for other distributions and large projects to look toward with an eye on how they can tailor the idea to their target developers.

Comments (1 posted)

Brief items

Distribution quotes of the week

-- Ben Cotton

-- Stephen Smoogen

Comments (none posted)

CyanogenMod 7.1 released

The CyanogenMod 7.1 release is out. It includes support for a lot of new devices, along with the ability to revoke permissions from applications, touch-to-focus and timer support in the camera application, and a ton of new configuration options. "As we continue to grow and improve CM, we are starting to see support from the industry grow- something that was unheard of previously. Recently, Sony Ericsson assisted our developers by providing over 20 devices, technical assistance, and compatible hardware drivers. CM-7.1 now has support for all recent SEMC devices thanks to this effort. Various other vendors have reached out to us, but we understand that it is still somewhat of a difficult situation. We will soon be providing a porting guide and some information on how vendors can get involved with the project and how/why it will benefit them."

Comments (9 posted)

Debian 5.0.9 released

The Debian project has announced the 5.0.9 point release for its oldstable distribution, Debian GNU/Linux 5.0 (lenny). "Please note that this update does not constitute a new version of Debian GNU/Linux 5.0 but only updates some of the packages included. There is no need to throw away 5.0 CDs or DVDs but only to update via an up-to-date Debian mirror after an installation, to cause any out of date packages to be updated."

Comments (none posted)

openSUSE announces first public release of openQA

The openSUSE project has announced the release of openQA 1.0, an automated testing framework. "openQA is the only comprehensive testing tool which can run tests on every level of the OS, from core functionality like the bootloader and booting the kernel up to testing applications like Firefox and LibreOffice. It shows the results in a convenient web interface and allows testers to see screenshots and even videos of the issues found. openQA is used to run nightly tests of the 'Factory' development repository for the upcoming openSUSE 12.1 release. openQA is available under the GPL version 2 or later." There are two software pieces to openQA: OS-autoinst and the web interface. OS-autoinst right now supports Fedora, Ubuntu, Debian, FreeBSD and even OpenIndiana. The web interface is openSUSE specific right now, but work is underway to make the entire tool distribution agnostic.

Full Story (comments: 10)

Distribution News

Debian GNU/Linux

bits from the DPL for September 2011

Stefano Zacchiroli presents an update on his Debian Project Leader activities during the month of September. Topics include the Wheezy release (scheduled for June 2012), upcoming sprints, trademark policy and other legal issues, various discussions on maintainers/porters responsibilities, length of the DPL term, and much more.

Full Story (comments: none)

Fedora

Results of the voting for the Fedora 17 release name

The Fedora project has announced the results of the election regarding the release name for Fedora 17: for better or worse, it will be called "Beefy Miracle." Suffice to say that the reaction on the mailing lists is not entirely positive. For those wanting to learn more, a page with the history of the name has been posted.

Full Story (comments: 30)

Ubuntu family

Ubuntu Chromium repository note

Sitsofe Wheeler notes that the Ubuntu Chromium repositories hosted on Ubuntu's launchpad are not getting updated. "It raises the eternal question about where to get your software when it is packaged by volunteers and the issues that surround branding (should most users be using a 3rd party repo rather than Google's repositories? Is the rapid pace of updates too much for distros to keep up with? How should expectations be managed?)."

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

• DistroWatch Weekly, Issue 426 (October 10)
• Maemo Weekly News (October 10)
• openSUSE Weekly News, Issue 196 (October 9)
• Ubuntu Weekly Newsletter, Issue 236 (October 9)

Comments (none posted)

Neary: What community?

Dave Neary takes a look at Tizen in terms of its goals for the "Tizen community". He is concerned that the project is setting itself up for failure. "For Tizen, I see between three and five different types of community, each with different needs, and each of which can form at different stages in the life-cycle of the project. Trying to "sell" the project to one type of community before the project is ready for them will result in disappointment and frustration all round — managing the expectations of people approaching Tizen will be vital to its long-term success, even if it opens you up to short-term criticism. Unless each of these communities is targeted individually and separately, and at the right time, I am sceptical about the results."

Comments (none posted)

Sabayon Linux 7 arrives with experimental Fusion kernel (The H)

The H takes a look at the release of Sabayon Linux 7. "Sabayon Linux 7.0 is based on the 3.0 Linux kernel and includes a choice of either GNOME 3.2, KDE 4.7 or Xfce 4.8 as the desktop environment; the Xfce edition of Sabayon has been promoted to a non-experimental release. An experimental Fusion kernel is available as an option after install. The developers say that it is similar to Zen Linux kernel sources, calling it their "Sabayon-flavoured Linux kernel sources on steroids". It includes the Brain Fuck Scheduler (BFS), the BFQ I/O scheduler, experimental patches for DRM and Btrfs, Reiser4 and new wireless-next drivers."

Comments (none posted)

Page editor: Rebecca Sobol

Development

openSUSE introduces openQA

Writing software, at least for most open source contributors, is the fun part. Testing, on the other hand, is often seen as boring and repetitive work. The openSUSE project is hoping that openQA will take some of the drudgery out of testing and boost the quality of released software.

The openQA project has been in the works for some time, but the openSUSE project officially unveiled the 1.0 release of openQA on October 11. According to the release notes from openSUSE community manager Jos Poortvliet, "openQA is the only comprehensive testing tool which can run tests on every level of the OS, from core functionality like the bootloader and booting the kernel up to testing applications like Firefox and LibreOffice."

The problem

The problem that openQA creator Bernhard Wiedemann and others in the openSUSE community are trying to solve is the chicken-and-egg problem with testing distributions. That is, users complain that early pre-releases are too buggy to even test. Developers complain that users don't start testing (and therefore, filing bugs) until release candidates — which is too late to fix some bugs. This has been a problem for openSUSE releases, as well as for other distributions. openQA, on the other hand, lets the computers do much of the work so that when users enter the picture they're not discouraged from testing by bugs that prevent even installing the distribution.

That, and the fact that frequent and in-depth testing of software is "difficult, time-consuming and boring." Lots of QA tools exist, but Poortvliet says that openQA is the first of its kind for comprehensive testing of a full operating system. openSUSE has been using openQA to test the openSUSE Factory (development) distribution for quite some time. Wiedemann mentioned it in a post in January, pointing users to the openQA overview page that shows testing results for the latest Factory release.

Using openQA, openSUSE has been able to provide tested Factory releases that can guarantee a few minimum requirements. For example, users should be confident that the installer works and X11 will start, at least in a KVM virtual host. (It is, of course, impossible to automate testing for all physical hardware users might have.) Users should also find that the Zypper package manager is capable of installing software on the system.

What openQA is

The openQA project is actually two parts, OS-autoinst and the openQA web interface. The OS-autoinst project is operating system-independent, and Wiedemann says that it should work with just about any OS that can be run under KVM or VirtualBox. The supported OSes for OS-autoinst are openSUSE, Fedora, Debian, SUSE Linux Enterprise Server, FreeBSD, and OpenIndiana. Currently, the openQA web interface is openSUSE-specific and integrated with the Open Build System, though both projects are GPLv2-licensed and any project could take the pair and adapt them for testing another operating system.

OS-autoinst can be used to test everything from operating system components like the bootloader, installer, and kernel to the end-user applications like Firefox or office suites. Test modules are written in Perl. A simple example of an OS-autoinst module is on the site, with a line-by-line explanation. The OS-autoinst system spins up a virtual machine of the test system and compares screenshots of the system to reference images to determine if tests are passed or not.

The openQA web site provides test overviews with full test results, and movies and screenshots captured during testing. The test results show how many tests passed with an "OK", "unknown", or "fail" result. Users can also view the testing scripts in the web interface to see what was tested. It's also worth noting that openQA has an IRC notification bot, so users can send test notifications to an IRC channel. The openSUSE project is using that to send test results to #opensuse-openqa on Freenode.

Limitations

The openQA project can do a lot of automated testing, but it still can't test everything. For one thing, if new artwork comes in or the resolution changes for a testing scenario, Wiedemann says that tests will come back with an "unknown" result instead of failing or passing a test. Then users will have check it manually. "This can be done over the openQA web interface in a matter of seconds." However, he notes that with openSUSE "console tests and tests in xterm hardly ever change (approximately once since 11.1 was released ~3 years ago)."

He also notes that "there is a quasi infinite number of inputs even to something as simple as 'a+b' and thus, to keep things simple, openQA just tests the core/base/default-case of important programs." In other words, there's only so much automated testing will get you before actual user-testing is required. Another limitation for openQA is that hardware and driver testing is limited to KVM-supported drivers. Wiedemann says that 99% of drivers can't be tested with openQA, so that will also be left to users to try.

openQA is also not going to work well with programs that have "things that vanish quickly" like pop-ups that close themselves. Then again, discouraging developers from having a pop-up that closes itself automatically might not be a bad thing. Programs that change themes or UI elements a lot can cause problems as well. Wiedemann singled out Firefox and LibreOffice as difficult programs to test with openQA. Finally, Wiedemann says that mouse-only input is difficult to test with openQA due to a qemu bug. Perhaps that will change if the bug is fixed.

Apart from that, Wiedemann says "nearly everything is testable."

The future

The idea, of course, is not only to use the openQA project for openSUSE, but to provide it to other projects as well. Wiedemann says that he's talked to Debian and Fedora project members, but hasn't heard of it being used by either project. He also says that the most interest shown so far, outside of openSUSE, has come from people developing antivirus software or doing QA for antivirus software. "Which surprised me at first, but they certainly do OS-level software with potential of wrecking people's lives, so they could profit from automated testing at the OS level."

Developers who want to pitch in or start using OS-autoinst for themselves can check out the code from Gitorious and consult the short user guide or install guide. The web-based interface is also on Gitorious. Some of the items on the to-do list for now include adding stress-tests for btrfs, Ext4, and XFS. Also planned is to add audio tests for Amarok and Banshee, and to add more application tests.

Overall, the openQA project looks fairly impressive. It seems to be working well for the openSUSE project, one hopes that it might find use in other projects as well.

Comments (2 posted)

Brief items

Quotes of the week

-- Matt Mackall

-- Colin McMillen et al

-- Jesús Corrius

-- Michael Meeks

Comments (15 posted)

LedgerSMB 1.3.0 released

Version 1.3.0 of the LedgerSMB accounting system has been released. "This is the most significant release to date in many ways. It is the most secure release, and it performs the best under heavy load. At the same time, it also provides the most features that many businesses rely on heavily. This means that LedgerSMB 1.3.0 is suitable for a much larger businesses and installations than previous versions." There are many new features beyond the security enhancements; see the announcement for details.

Full Story (comments: 2)

Owncloud 2 released

Owncloud is a system for the creation and management of personal cloud resources; the Owncloud 2 release is now available. It includes support for file access and sharing, network music streaming, calendar management, contact management, and more. (LWN looked at Owncloud in 2010).

Comments (2 posted)

pgwatch 1.0

Pgwatch is a monitoring tool for PostgreSQL 9.x databases; the 1.0 release is now available. See the pgwatch page for details, downloads, and lots of screenshots. (Note that the announcement claims that pgwatch is under "the Creative Commons License," but the actual license is Artistic 2.0).

Full Story (comments: none)

Plasma Active One released

The KDE project has announced the first release of the Plasma Active interface for tablets and other touchscreen-oriented devices. "Plasma Active One's touchscreen interface is more than just an application launcher. As soon as the device is turned on, rather than the traditional grid of applications, you see the Activities view showing your current project, task or idea. With Activities, you can collect all of the documents, people, web sites, media and widgets related to a topic in one place, building personalized and interactive views of your life."

Comments (9 posted)

Samba now accepts corporate-copyrighted code

The Samba project has changed its longstanding policy and will now accept code contributions owned by corporations. They have adopted a kernel-inspired "certificate of origin" which must be filed with the project; after that, corporate-owned code can go in with a simple Signed-off-by line. See the announcement (click below) for the details of how it works.

Full Story (comments: none)

Sphinx 1.1 released

Version 1.1 of the Sphinx documentation system (reviewed in LWN in 2010) has been released. Significant changes include Python 3 support, easier inline index entries, and a number of new builders (texinfo, gettext, and websupport).

Full Story (comments: none)

Subversion 1.7.0 released

Version 1.7.0 of the subversion source code management system is out. New features include centralized metadata storage, better HTTP support, a new remote dump tool, a new "svn patch" command and more; see the release notes for details.

Full Story (comments: 9)

Newsletters and articles

Development newsletters from the last week

• Caml Weekly News (October 11)
• GCC 4.7.0 status report (October 11)
• Perl Weekly (October 10)
• PostgreSQL Weekly News (October 9)

Comments (none posted)

Novacut delivers distributed collaboration in HD-SLR video editing (Opensource.com)

Opensource.com has a review of the Novacut video editor. "In other words, Novacut creates a truly agile environment for the creative process. While this may not be a feature that a one-man show would need for a personal film project, it's something that only the most expensive editing solutions even begin to touch. For a free, GPLv3 video editor to be based on such a paradigm is not just unique; it's a game-changer."

Comments (14 posted)

Oracle works on Dtrace for Linux (The H)

The H reports on Oracle's plans to bring DTrace to (Oracle) Linux. "There is no word on what the Linux port of 'Dynamic Tracing Facility' (also known as Dtrace) will look like, but it is considered a major function in newer versions of Solaris. A blog post by Dtrace co-inventor Adam Leventhal indicates that few details are known, though he does say that it will be interesting to see how Oracle clears up licensing issues."

Comments (23 posted)

Time zone database shut down (The Daily Parker)

The Daily Parker reports on the shut down of the Olson time zone database (used by most Unix-like systems) due to a copyright infringement lawsuit. Evidently, an astrology company bought the rights to The American Atlas, which was used (and credited) for some of the historical time zone information, and now the company is suing for infringement of something that looks an awful lot like facts (which are not supposed to be copyrightable). "What's even stupider about this lawsuit is that comments in the database encourage people to buy the book. So even if Astrolabe owns the copyright to the facts about time zone rules—a troubling proposition—their republication in the Olson database increases the likelihood that they'll make money off it." (Thanks to Dirkjan Ochtman for the heads up.)

Comments (74 posted)

Page editor: Jonathan Corbet

Announcements

Brief items

The annual State of Mozilla report

Mitchell Baker has announced the availability of the annual State of Mozilla report and associated 2010 financial statements. "As the Internet experience is changing, Mozilla, too, is changing. The products and tools that we use to advance our mission are expanding and evolving. A browser is necessary but not sufficient. Equally important is expanding the number of people who understand our values and identify as Mozillians. Mozilla has both the challenge and the opportunity to expand our reach dramatically. We have the ability to bring our values to life in new ways. Embracing these opportunities means embracing change, embracing hope and embracing determination."

Comments (31 posted)

Articles of interest

Intellectual Ventures Files Patent Suit Against Motorola Mobility (The Wall Street Journal)

Noted patent troll Intellectual Ventures (IV) has filed a patent suit against Motorola Mobility, according to The Wall Street Journal. Evidently IV has been successful in getting other handset makers to license the patents, but there is an interesting twist in this particular suit: "The lawsuit also creates a potentially awkward scenario, with a firm partly backed by Google now presenting a Google acquisition target with a new legal headache. Intellectual Ventures disclosed Google's investment in the firm in May. [...] Bellevue, Wash.-based Intellectual Ventures filed its new suit in Delaware, alleging that Motorola Mobility has infringed on six patents related to transferring files among computers and technology used in an 'entertainment device,' according to the complaint."

Comments (14 posted)

Education and Certification

LPI Announces Academic Training Partners in Malaysia

The Linux Professional Institute (LPI) and its affiliate, LPI-Asia Pacific have announced new LPI-Approved Academic Partners in Malaysia. ""Malaysia has long been a leader in the adoption of Open Source technology within their public sector and LPI is pleased to be part of that effort. In particular, these two new LPI training partners from Malaysia's leading academic institutions is indicative of the efforts of our affiliate in the region, LPI-APAC, to reach out to that country's IT training organizations," said Jim Lacey, president and CEO of LPI."

Full Story (comments: none)

Calls for Presentations

Automotive Linux Summit 2011

The Linux Foundation has announced the launch of the Automotive Linux Summit (ALS). "The Automotive Linux Summit is the premier vendor-neutral business and technical conference for companies and developers using or looking to use Linux and open-source technologies in automotive applications ranging from in-vehicle on-board system to cloud solutions for vehicle-to-vehicle and vehicle-to-infrastructure communications." The Call For Participation closes October 21.

Comments (none posted)

Upcoming Events

buildroot + crosstool-NG Developers' Day

The developers of buildroot and crosstool-NG will be holding a Developers' Day on October 29, 2011 in Prague, Czech Republic. That's the day after the Embedded Linux Conference/LinuxCon which will also be held in Prague.

Full Story (comments: none)

Zentyal Summit 2011

The Zentyal Summit will be held November 11-12 in Zaragoza, Spain. "Zentyal Summit is a free event that offers an opportunity for current and potential Zentyal users, community members and developers share experiences, meet and discuss with each other as well as learn more about the server distribution."

Full Story (comments: none)

Draw your way to LA and SCALE 10X

The folks behind the Southern California Linux Expo (SCALE) are holding a logo design contest for the January 2012 event. "The designer of the winning submission will win a free pass to SCALE 10x, including airfare within the continental United States, as well as a three-night stay at the Hilton Los Angeles Airport."

Full Story (comments: none)

LAC 2012: coming in April

The Linux Audio Conference 2012 will be held April 12-15, 2012 at the Center for Computer Research in Music and Acoustics (CCRMA), Stanford University, California. Additional details should be available soon.

Full Story (comments: none)

Events: October 20, 2011 to December 19, 2011

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

Date(s)	Event	Location
October 18 October 21	PostgreSQL Conference Europe	Amsterdam, The Netherlands
October 19 October 21	13th German Perl Workshop	Frankfurt/Main, Germany
October 19 October 21	Latinoware 2011	Foz do Iguaçu, Brazil
October 20 October 22	13th Real-Time Linux Workshop	Prague, Czech Republic
October 21	PG-Day Denver 2011	Denver, CO, USA
October 21 October 23	PHPCon Poland 2011	Kielce, Poland
October 23 October 25	Kernel Summit	Prague, Czech Republic
October 24 October 25	GitTogether 2011	Mountain View, CA, USA
October 24 October 25	GStreamer Conference 2011	Prague, Czech Republic
October 24 October 28	18th Annual Tcl/Tk Conference (Tcl'2011)	Manassas, Virgina, USA
October 26 October 28	Embedded Linux Conference Europe	Prague, Czech Republic
October 26 October 28	LinuxCon Europe 2011	Prague, Czech Republic
October 28 October 30	MiniDebConf Mangalore India	Mangalore, India
October 29	buildroot + crosstool-NG Developers' Day	Prague, Czech Republic
October 31 November 4	Ubuntu Developer Summit	Orlando, FL, USA
October 31 November 4	Linux on ARM: Linaro Connect Q4.11	Orlando, FL, USA
November 1 November 3	oVirt Workshop and Initial Code Release	San Jose, CA, USA
November 1 November 8	2011 Plone Conference	San Francisco, CA, USA
November 4 November 6	Fedora Users and Developer's Conference : India 2011	Pune, India
November 4 November 6	Mozilla Festival -- Media, Freedom and the Web	London, United Kingdom
November 5 November 6	Technical Dutch Open Source Event	Eindhoven, The Netherlands
November 5 November 6	OpenFest 2011	Sofia, Bulgaria
November 7 November 11	ApacheCon NA 2011	Vancouver, Canada
November 8 November 12	Grace Hopper Celebration of Women in Computing	Portland, Oregon, USA
November 10 November 12	Clojure/conj 2011	Raleigh, NC, USA
November 11 November 12	Zentyal Summit	Zaragoza , Spain
November 11 November 13	Free Society Conference and Nordic Summit 2011	Gothenburg, Sweden
November 12	London Perl Workshop 2011	London, United-Kingdom
November 12	Emacsforum 2011	Copenhagen, Denmark
November 14 November 17	SC11	Seattle, WA, USA
November 14 November 18	Open Source Developers Conference 2011	Canberra, Australia
November 17 November 18	LinuxCon Brazil 2011	São Paulo, Brazil
November 18	LLVM Developers' Meeting	San Jose, CA, USA
November 18 November 20	Foswiki Camp and General Assembly	Geneva, Swizerland
November 19 November 20	MediaWiki India Hackathon 2011 - Mumbai	Mumbai, India
November 20 November 22	Open Source India Days 2011	Bangalore, India
November 24	verinice.XP	Berlin, Germany
November 28	Automotive Linux Summit 2011	Yokohama, Japan
December 2 December 4	Debian Hildesheim Bug Squashing Party	Hildesheim, Germany
December 2 December 4	Open Hard- and Software Workshop	Munich, Germany
December 4 December 7	SciPy.in 2011	Mumbai, India
December 4 December 9	LISA ’11: 25th Large Installation System Administration Conference	Boston, MA, USA

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

Page editor: Rebecca Sobol