LWN.net Weekly Edition for September 13, 2012

The coming robot apocalypse

Avid science fiction readers will have run across the "robot takeover" concept more than once. In short, the human race succeeds in building robots that are smart and powerful enough to take charge; the results are rarely presented as being pleasant or desirable. Science fiction occasionally has a habit of becoming reality; while it may be a bit early to proclaim the robot apocalypse, recent events make it clear that some concern is not out of place.

Ironically, one of those events involved a science fiction convention — arguably the most important one on the genre's annual calendar. As Neil Gaiman took the stage to accept a Hugo award at WorldCon, an automated copyright enforcement system at UStream disconnected the network feed, claiming that copyrights were being infringed. That turns out not to be the case; the offending Dr. Who segments had been provided by the studio for the purpose of being run before the talk, but the robot involved was not interested in such details. Remote fans who wanted to watch the live stream were denied the privilege in the name of protecting copyright.

Shortly after that, the national convention of the US Democratic party was hit by a similar episode; Mars lander footage has also been denounced by the robots in the past. Perhaps more importantly, there is a growing list of people who lack the prominence of a major author, politician, or interplanetary probe who have run into similar difficulties. Needless to say, these lower-profile publishers tend to have a harder time drawing attention to the problem or getting it fixed. Increasingly, the right to publish is subject to the will of anonymous, semi-autonomous software that is given veto power over any material it does not like. This does not seem like a viable path toward greater freedom.

The free software community, arguably, does not pay as much attention to copyright issues as it should. Copyright infringement is relatively easy to avoid while developing software, and, as the SCO Group so kindly made clear to the world, we are quite good at avoiding infringement. Related issues, like ever-lengthening copyright terms, are mostly of academic interest; whether coverage lasts for 50 or 70 years (or longer), it is hard to imagine that today's software will be of much interest when it finally makes its way into the public domain. So it is natural for us to worry about things that look like more immediate threats: software patents or new init systems, for example.

But the rise of autonomous enforcement bots raises a whole new set of threats. If there is anything that is clear about the "intellectual property" industry, it is that industry's willingness to use every tool and technique available — and to try to force others into doing the same. UStream almost certainly did not set out to be a copyright enforcer as part of its business plan; that role was forced upon it by the entertainment industry. There has been great pressure on internet service providers to do the same. It is not hard to imagine aggressive enforcement bots moving outward from the source of traffic (UStream or YouTube, say) into the transmission path and, eventually, into the endpoints where content is consumed.

It is also not hard to imagine that, as these bots spread across the network, their mission will expand as well. Why be satisfied with interfering with video distribution when there is so much more that could be done? Certainly these bots could be charged with stopping anything that looks like a "circumvention tool" — jailbreak kits or alternative images for locked-down phone handsets, for example. Software that has been deemed to infringe somebody's patents — Android, say — could be blocked. Electronic book readers already phone home with their users' reading habits; it would not be hard at all to block access to reading material that lacks a commercial paper trail or that offends whatever powers are in charge in any given area.

Much of the infrastructure for this kind of regime already exists. There is monitoring software for central nodes, and DRM-enforcement systems for the end nodes. And if your particular system lacks the appropriate hooks, there are companies like FinFisher that are happy to put monitoring and control software in place without concern for niceties like whether the user actually wants it.

In other words, there is little that is new about what is going on except, perhaps, the increasing role of autonomous software agents. These bots have little concern for issues like authorized use, much less fringe details like fair use or inappropriate copyright claims. Their use is on the increase; more stories of ridiculous bot-driven shutdowns in the future seem certain. It may not be the robot apocalypse, but it sure looks like the beginning of a large amount of robot-driven obnoxiousness at the very least.

Naturally, free software can help. We need not implement interfaces for the use of our robot overlords in our software; indeed, we have shown little interest in doing that in the past. When combined with true control over our hardware, free software can, at least, give us some assurance that our endpoints are not acting against our interests. Control over the hardware is far from guaranteed, but the situation could have been far worse than it actually is at the present. With luck and continued attention and pressure, we may be able to avoid a completely locked-down world.

Fixing the rest of the system will be harder. It is time to pay more attention to the copyright maximalist agenda and push back. Fair use rights must be asserted where they exist and created where they don't. The business concerns of the entertainment industry should not drive the design of our systems, our networks, and our international agreements. Perhaps there should be penalties for false assertions of copyright. And so on.

The free software community interacts deeply with the copyright system. We make full use of it in our software licenses; even permissive licenses have requirements that are backed up by copyright law. But the system we use to ensure the freedom of our software can also take away our freedom on other fronts if we do not pay attention. A world where our right to express ourselves is moderated by somebody else's software — usually very proprietary software — is not what we have been working for.

Comments (22 posted)

LinuxCon: Open hardware for open hardware

Open hardware platforms like the Arduino have turned device development into a hobbyist enterprise in recent years, but the $20 price tag of a microcontroller board seems a lot less tantalizing when one adds in the costs of testing and debugging it. At LinuxCon 2012 in San Diego, David Anders addressed this issue and offered some guidance on finding and selecting tools for open hardware development, the majority of which are open hardware themselves.

Openness and tools

"Open hardware" can mean a variety of things, from expensive commercial products with published schematics and chip designs all the way down to one-off experiments and home-brewed devices built from cheap parts like the Arduino microcontroller board. What the various definitions have in common, however, is the sharing of information, which in turn lowers the barrier to entry for participants in the community. But despite the "maker" movement's popularity of late, the tools problem that accompanies it is rarely discussed. Reality is that the hardware to build rapid-prototyping and one-off projects may be cheap and plentiful — but the tools required to test and debug that hardware is expensive, specialized, and proprietary.

For example, bench-top oscilloscopes start at $250 and can go up well into the hundreds of thousands of dollars. Logic analyzers start at around $1000. Even sticking with the low end, Anders said, buying a tool that costs ten or one hundred times the price of the device you are building takes some of the shine off of the process, particularly for someone who only needs to make hardware on infrequent occasions. Furthermore, the commercial versions of tools like the oscilloscope are designed for use by people like electrical engineers, and have a difficult learning curve.

On the subject of occasional use, Anders noted that although the maker and open hardware movements are often associated with non-professional settings (such as teaching young people about electronics or scratching one's own project-itch), they are proving to be a disruptive force in software circles as well. He spoke mostly about Arduinos and similar microcontroller boards, since they are the most popular flavor of amateur hardware development, but he made it clear that the same issues apply to most other projects, from sensors to embedded systems. Furthermore, he said, even if open hardware devices are not the issue at hand, most Linux and open source software developers will find themselves needing to build or debug a hardware device at some point.

Despite the high sticker prices of these devices in the commercial world, Anders said, science in general has a long history of developing and sharing open tools — dating at least as far back as Robert Bunsen's 1854 invention of the Bunsen burner, which he licensed for others to make as long as they adhered to his guidelines. Scientists have often documented their tools because their experiments require specialized equipment, he said, and sharing that part of the process is important for peer review and the ability to reproduce others' results.

In some ways, he said, open source software is a continuation of the same principle: developers build and share the tools needed to get work done. As open hardware has become more popular, a number of projects have started to develop the tools needed to analyze and debug devices — even if most of them are still under the radar.

Oscilloscopes

The first tool Anders looked at was the oscilloscope. The earliest versions of the tool drew graphs on paper tape, until CRT-based oscilloscopes took over in the 1950s — and the tool remained essentially unchanged for the next 50 years. It reads analog voltage signals, and displays the result as time-series data for analysis. Recent innovations have introduced updates, he said, like LCD screens, better portability, and built-in storage and analytics. But the core feature set remains the primary selling point; more expensive oscilloscopes justify their higher prices by supporting multiple inputs, higher sample rates, higher sample resolution, and larger frequency ranges.

With those factors in mind, Anders described three tiers of open hardware oscilloscopes to consider. The mid-range are based on PIC microcontrollers. There are about ten vendors on the market, he said, with the cheapest selling kits for $60. A typical example from Sparkfun offers 8-bit sample resolution, 1MHz bandwidth, and memory to store 256 samples. The device can grab screen captures of the signals it reads, and export them as bitmap images.

An even cheaper option is Atmel AVR-based oscilloscopes, which can be had for less than $30. Some AVR-based designs are assembled from off-the-shelf components, and are intended to be plugged directly into a breadboard. Consequently, at that price point they do not contain storage memory or an attached display, but both could be added. At the high end of the spectrum is the Nano-DSO, for around $100. The Nano-DSO is a commercial project, but it has open source firmware that can be modified and re-flashed. It offers a higher sampling resolution (12-bit) than the PIC-based units, but a narrower bandwidth (200KHz). However, it also includes a color LCD display, battery power, and a built-in signal generator.

Dedicated hardware is not the only option, however. Anders showed two open source software oscilloscopes, xoscillo and OsciPrime. Xoscillo runs on Linux, Windows, and Mac OS X, and can use commercial USB oscilloscope dongles or an Arduino (which has analog input pins built-in) to read signals. OsciPrime is an Android application, and can read signals from probes connected to the Android device's microphone port.

Logic analyzers

The logic analyzer is a tool that evolved from the oscilloscope, Anders said. Its purpose is not to monitor the shape of signals, but to analyze their timing — particularly to capture and decode digital signals. For that usage, they typically offer far more probes than an oscilloscope, which increases the cost. Commercial models cost thousands of dollars, an amount most people cannot see investing in their home projects.

The most do-it-yourself friendly option is the Open Bench Logic Sniffer, which can read 32 simultaneous input channels at up to 70MHz. The Open Bench Logic Sniffer can be found for around $50. The same company also offers the Logic Shrimp, a more modest model with four input channels and a 20MHz maximum sampling speed. The lower specifications make the Logic Shrimp a $35 tool, Anders said, but it is more than adequate for sampling I2C, SPI, RS-232, and other low-speed connections. Both are USB peripherals designed to be compatible with the open source SUMP analyzer software.

There are also several open hardware logic analyzer boards based on microcontrollers, including FX2-based models ranging in price from $20 to $150, MSP430-based models ranging from $25 to $35, and AVR-based models ranging from $35 to $50. Some of these latter options include built-in displays, but for the most part the open hardware logic analyzer community relies on PC-based software to display the signals and to decode the protocols within them.

The major player in open source logic analysis software is Sigrok, Anders said. It supports a wide range of hardware devices and is growing by leaps and bounds, he said, so it is worth keeping on the radar even if your hardware is not supported at the moment. One of Sigrok's major selling points is that it is easily extended. It provides an API for writing protocol decoders in Python, and the project maintains a lengthy list of protocols it understands. Even those protocols for which there is no decoder can still be captured as raw signals, of course.

In addition to Sigrok, the Logic Sniffer application is the other major open source software option. It was written to support the Open Bench Logic Sniffer (extending SUMP's feature set), but has expanded to cover additional hardware devices.

Other tools

Anders concluded the talk with a question-and-answer session that covered several other hardware tool topics. The Bus Pirate, for example, is a device designed to provide a serial port interface to a variety of chips, and even program serial ROMs. Anders said that he omitted the Bus Pirate from his main discussion because it is not primarily designed to perform oscilloscope or logic analyzer functions. It can be used to perform some of the same tasks, but it makes those tasks more difficult than do the other tools.

Similarly, when another audience member asked about JTAG tools, Anders observed that the are several open tools on the market. In addition, the Bus Pirate hardware can even be re-flashed with different firmware so that it functions as a JTAG interface.

Anders also alluded to support for automotive communication buses as a feature of Sigrok. Another member of the audience asked whether that support included Controller Area Network (CAN) bus, one of the leading automotive buses, and one for which PC interfaces are expensive. CAN bus uses differential logic, Anders explained, which requires a transceiver module to convert the signal into generic GPIO. However, the actual parts involved are not expensive, he said, so amateurs can build an interface that allows them to read CAN bus traffic with Sigrok.

Ultimately, Anders's talk only had enough time to conduct a survey of the available options for hardware development tools, rather than provide in-depth comparisons. But it was still a valuable session; most of the attendees at an event like LinuxCon come from the software realm — but as Anders said, most of them will (at one time or another) need to build or debug a hardware device. Having an alternative to the high prices of professional equipment is nice, but having an alternative that respects the same ideals as Linux and open source software is even better.

Comments (9 posted)

Engine Yard transitions to PostgreSQL

PostgreSQL version 9.2 was released on September 10th, with many enhancements that web application developers—and companies who host web applications—are excited about. One of the most excited is Ruby on Rails and PHP application host Engine Yard, who recently switched its default database option from MySQL to PostgreSQL. Combined with recent data on database migrations, Engine Yard's switch of databases signifies a sea change in the long rivalry between PostgreSQL and MySQL, as well as in Ruby on Rails development.

For coverage of the PostgreSQL 9.2 features, see the LWN article on PostgreSQL 9.2 Beta.

For information about the switch, I interviewed Engine Yard Lead Data Engineer Ines Sombra. But first, some background. Readers who are already familiar with Rails, MySQL, and PostgreSQL can skip down to the interview.

Ruby on Rails and MySQL

Ruby on Rails is a full-stack web framework, based on automated code generation. Rails is implemented in Ruby, a programming language which existed for ten years before Rails was introduced in 2004. It's "full stack" because it handles all parts of a web application above the database and operating system level, including querying the database, generating HTML pages, and responding to HTTP requests.

Rails has become one of the top five web development platforms because of its rapid and beginner-friendly web application building. The centerpiece of this is a code-generation engine, which creates the initial "scaffolding" for the web application developer, using the Model-View-Controller (MVC) design pattern, saving the developer a lot of time by handling many of the repetitive tasks that are normally required. The simplest Rails applications perform what is known as CRUD, for Create, Read, Update, and Destroy records in a database.

Early Rails supported only the MySQL database system, since it was regarded as the simplest, most developer-friendly SQL database available. That allowed developers to focus on keeping all of the application logic inside Rails. While there were early attempts to introduce PostgreSQL support, none of them really caught on until Rails 3.0 was released, so the vast majority of Rails developers used only MySQL through 2010.

Rails hosting, Engine Yard, and Heroku

While Rails made creating and developing a web application much easier than before, it did nothing to reduce the difficulty of hosting a web application. If anything, the highly dynamic nature of Rails makes it one of the most resource-consumptive web frameworks, requiring skill and experience in deployment, scaling, and uptime maintenance. Recognizing this dichotomy in 2006, Tom Mornini, Lance Walley, and Ezra Zygmuntowicz founded Engine Yard, a "fully managed web host" or "cloud host" for Rails projects. Engine Yard allowed the developer to just write code, and leave installation, scaling, and uptime to others — for a monthly hosting fee.

Initially, Engine Yard supported only MySQL for data storage, and hired a large, expert MySQL team to manage thousands of MySQL databases. Engine Yard built a sophisticated "database as a service" infrastructure on MySQL to support its customers. As the number one Rails hosting option, this meant that the majority of hosted Rails applications were not just on MySQL, but on Engine Yard's MySQL.

However, a year after Engine Yard launched, another team of entrepreneurs founded a competing Rails hosting service: Heroku.com. Heroku introduced a Git-centric model of application deployment that appealed to startups practicing agile development, and by 2010 it had grown into a strong competitor to Engine Yard for Rails users. Unlike Engine Yard, Heroku used PostgreSQL as its default—originally its only—database for customers. Heroku began promoting PostgreSQL among Rails developers and its user base, culminating with the introduction of a PostgreSQL cloud hosting service this year.

Today, both Engine Yard and Heroku support additional platforms, such as PHP, Python, and Java, in addition to Rails.

Migrations from MySQL to PostgreSQL

In April of this year, Engine Yard introduced PostgreSQL 9.1 as an option for its users. In August, Engine Yard announced that, with the release of PostgreSQL 9.2, it would become the default database option for new applications.

Engine Yard's users are not alone in migrating from MySQL to PostgreSQL. 451 Research recently released a subscription-only study, called "MYSQL VS. NOSQL AND NEWSQL: 2011-2015", that looked at tech sector MySQL users and their plans two years after the Oracle acquisition. For the one out of six MySQL users planning to migrate away from MySQL, the most popular option is PostgreSQL. In the Rails community, Planet Argon found that 60% of Rails developers now preferred PostgreSQL, up from 14% just three years ago.

Interview with Ines Sombra

To fill us in on the details of Engine Yard's move from MySQL to PostgreSQL, I interviewed Ines Sombra. Ines, who was born in Argentina, became a Rails developer and enthusiast while working at Engine Yard.

Josh: What's your role at Engine Yard?

Josh: What was the primary motivation for Engine Yard to offer PostgreSQL support?

Josh: Do you expect Engine Yard customers currently using MySQL to migrate to the new PostgreSQL databases?

Josh: What was the timeline of this change? How long did it take?

Josh: What were the biggest technical obstacles you encountered in deploying a PostgreSQL infrastructure, and how did you solve them?

Josh: Which 9.2 features are Engine Yard users most interested in, and why?

[Josh Berkus is a member of the PostgreSQL Core Team.]

Comments (14 posted)

Page editor: Jonathan Corbet

Security

LSS: Secure Boot

Matthew Garrett gave the opening keynote at the 2012 Linux Security Summit on his new "favorite" topic: UEFI Secure Boot. Up until about a year ago, he was working on power management for the Linux kernel, but at LinuxCon in Vancouver he found out about the requirement that systems shipping with the Windows 8 logo would be required to have Secure Boot enabled. He "ended up drinking quite a lot that week", he said, but things are not quite as bad as he had thought at first. Contrary to his initial fears, users will be able to boot Linux on hardware certified for Windows 8.

UEFI Overview

Garrett began with an overview of UEFI, noting that it is a replacement for the legacy PC BIOS. Its role is to initialize the hardware and to provide services to the bootloader for tasks like discovering hardware. It is the "least relevant 16MB of code you will ever encounter", he said. The code is mostly open and available from Intel under a BSD license. There is also some proprietary, machine-specific code to program memory controllers. The firmware vendors add their own code for "3D UIs"; those vendors also "add bugs of course". There is a surprisingly good compatibility suite and there are regular plugfests to ensure that the UEFI implementations can boot a variety of operating systems.

There are some relevant differences between UEFI and BIOS. To start with, UEFI firmware can read filesystems. The standard only requires VFAT support—and Microsoft grants a patent license for UEFI implementations. The bootloader is now an executable in PE/COFF format like Windows binaries. There is also non-volatile flash storage available where things like the location of the bootloader and parameters to pass to it can be stored.

When a computer is turned on, the firmware runs first, followed by a bootloader, which loads the operating system (OS). Traditionally, malware has targeted the OS, but vendors, particularly Microsoft, have gotten very aggressive at cutting down the OS as a target. Windows 8, for example, will load a virus checker very early on, before even some of the drivers are loaded, Garrett said.

Given that, we are seeing malware move away from the OS. Instead of "rootkits" we are starting to see "bootkits". For BIOS-based systems, the easiest way to install boot-time malware is to replace the master boot record (MBR). Once that's done, the bootloader can no longer be trusted (as the MBR will point to a malicious version), and the bootloader can change the OS when it loads it. The malware can then intercept attempts to verify the MBR by returning a "clean" copy, making it difficult to detect the compromise.

The key thing to note, Garrett said, is that if you are running untrusted code at any level, you can't trust the code at a higher level. UEFI Secure Boot is an attempt to fix the problem of bootkits. A header section is added to bootloaders (or other binaries) to contain signed hashes of the contents. The firmware will only launch binaries with a valid hash signed by a trusted key. It uses the same cryptographic algorithms that are used by Secure Sockets Layer (SSL), so there is no reason to believe that Secure Boot is insecure, other than the fact that it will be implemented by firmware vendors, he said.

Key management

For managing the keys, there are four databases in the firmware's flash. With UEFI, it will no longer be possible to write to that flash directly, instructions from x86 system management mode (SMM) will need to be used instead. The first database, "dbx", will contain keys and hashes that will always be rejected by the firmware. If a binary's hash is in dbx or if the key used to sign that hash is present, the firmware will not run it.

The "db" database contains keys and hashes that will be accepted, but entries in dbx override those in db. After the October launch of Windows 8, standard systems will contain the manufacturer's key and Microsoft's key in db. Vendors will want to enable Secure Boot so that they can access marketing money from Microsoft for promoting the hardware as "Windows 8 compatible". The margins on a laptop are "pennies", Garrett said, so the marketing money makes a big difference.

Being able to blacklist keys is an important part of the design of Secure Boot. Keys that have been used to sign malware or to sign other, non-malicious software that can be exploited can be disabled.

The other two databases are the "kek" (key exchange key), which stores keys that can be used to sign updates to db or dbx, and the "pk" (platform key) which can sign kek updates. Installing a pk causes the transition from "setup mode" to Secure Boot mode. Normally, the pk will be a hardware vendor key, which will be used to sign the update to the kek, which is where the Microsoft key will reside. This protects the vendor from Microsoft losing control of its key, because they could (in some unspecified way) have their customers update the kek using their key. If the private half of the key in the pk leaks, Secure Boot is no longer secure on those systems.

The UEFI specification defines the technical details of Secure Boot, but does not specify any particular policy with regard to how it is used. But Microsoft has specified policies for systems that want to get Windows 8 certification. For those, Secure Boot must be enabled by default, and the Microsoft key must be present. In January, Microsoft added the requirement that a physically present user must be able to disable Secure Boot and install their own keys—but only for x86-based systems, not those that are ARM-based.

An audience member asked if there was "any hope" of that requirement changing for ARM. Right now, Garrett said, ARM systems with Windows 8 certification must not allow disabling Secure Boot or adding user-specified keys. Whether ARM-based system vendors will actually pursue that certification is an open question since the Windows on ARM market "doesn't exist" at this point.

Linux on Secure Boot

To boot Linux on a Secure Boot system, there needs to be a signed bootloader. "Distasteful though it might be", the only sensible way to do that is to get Microsoft to sign it. One can set up an account with Verisign, pay some money, and get access to the Microsoft signing system. From there, you upload a binary, and a get a signed object back a day later. Because of the way headers are added with the signatures, you can still verify that it is your binary, rather than something that has been modified by Microsoft.

Once that signed bootloader has been run, it could do anything. But there are or could be consequences if it does. The signed bootloader stops malware from being inserted between the firmware and the bootloader. But, there is no way for code to determine if it is really running in Secure Boot mode. That is one difference between Secure Boot and Trusted Boot; the latter adds attestations that can prove the running code is what it says it is. In Secure Boot, one can ask the firmware if it is enabled, but there is no way to trust the answer unless the code at each level can be trusted.

In order to be able to extend trust to the higher-levels, those pieces (e.g. kernel, drivers) must be signed as well. But there is more to it than that, whatever signed kernel that runs must not be usable to run unsigned privileged code.

One of the problem areas is kexec(), which allows replacing a running kernel with a new kernel. It is like booting the new kernel, but without going through the hardware initialization (thus Secure Boot) step. But, kexec() could be used to boot Windows instead, which would allow an attacker to create a malicious Windows that boots on Secure Boot hardware. It would use the signed Linux bootloader and kernel, but kexec() into the mal-Windows. If that were to happen, Garrett said, Microsoft would blacklist the bootloader. "Apparently, our management was not enthusiastic" about that possibility, he said.

So, signed kernels require some changes to support Secure Boot. That means doing things like disallowing kexec() and restricting the ability of user space programs to cause hardware devices to perform direct memory access (DMA). The latter mostly affects graphics hardware that does not have support for kernel mode setting (KMS).

In the past, there was this idea of a separation between regular users and root. The idea was to prevent people from elevating their privileges to those of the root user, and protecting the kernel from root was not particularly important. That is no longer the case in the Secure Boot world. Root is no longer trusted, only the physically present user, who may not be the same as root, is trusted.

There are other things that will need to be handled to avoid signed kernels from "attacking" Windows. Garrett said that Kees Cook mentioned hibernation images recently as a vector for attack. When a user resumes from a suspend-to-disk, memory contents are read from disk. A crafted hibernation image could subvert the protections, so unless some other solution is found, hibernation will need to be disabled. That's fine, "because it doesn't really work in Linux anyway", he said.

Plan of attack

The plan is to create a trusted first-stage "shim" bootloader that will be signed with the Microsoft key. Because free software tends to change frequently, and it is desirable to avoid getting things signed all the time, having the shim, which should change infrequently, makes sense. The full bootloader is then signed with a distribution-specific key. Kernels and modules would also be signed with that key, or with a key already in the firmware key databases. If a user wants to sign their own kernels or modules, they can put their own key in the firmware.

Instead of adding keys to the four databases established by UEFI, SUSE came up with a way to add keys from the bootloader (which cannot access the key databases) to a secure location in the firmware. There are UEFI boot services variables that are only available to the boot environment. Using those to store keys will allow the bootloader to update them, when prompted by physically present users. Doing so from the bootloader avoids the problem of having to try to figure out and document how to add keys using the vendor-specific UEFI firmware set up tools. So far, that code does not exist, but SUSE is working on it, he said.

The management of thousands of systems requiring physically present users is "not a solved problem", he said in response to a question. There is the belief that those who are buying many systems will be able to convince vendors to ship their hardware in setup mode (with no keys) or to put custom keys into the firmware.

There are still some outstanding questions, including how to handle third-party module signing (e.g. for NVIDIA drivers). There could be some kind of Linux certificate authority (CA), but no one has stepped up to run such a thing. It would cost "at least millions" to set up and run, plus probably more than a year to get going, so "no one is jumping up and down to do this", he said. There is the possibility that third parties could have their modules signed by Microsoft or there could be some way to have the bootloader prompt for the installation of third party keys. Red Hat and other vendors are not inclined to sign third-party modules because of licensing issues and that it could be seen as an endorsement of binary-only modules.

Early on in the process of sorting out Secure Boot issues, there was concern that GPLv3 (which is the license for the GRUB2 bootloader) would require the signing keys to be disclosed. Garrett said that he and others had worked with the FSF on that problem. The conclusion that was reached is that the signing keys are not required to be disclosed as long as users can install their own keys, which they will be able to do.

In the final analysis, Secure Boot is "much less bad than it could be", Garrett said. It will increase the security of Linux "somewhat", but is mostly for increasing the security of Windows. As long as we are careful not to get our keys blacklisted (by allowing signed kernels to attack Windows), it won't seriously impede Linux in the future.

Comments (92 posted)

Brief items

Security quotes of the week

-- Juliette Kayyem

-- Mark Vanhoenacker

-- Lauren Weinstein

Comments (8 posted)

Tinnes: Introducing Chrome's next-generation Linux sandbox

Julien Tinnes describes the new sandbox mechanism for the Chrome browser under Linux. "In a similar, but very limited, fashion, this is what we have now in Chrome: we stacked the seccomp-bpf sandbox on top of the setuid sandbox. The setuid sandbox gives a few easy to understand semantic properties: no file system access, no process access outside of the sandbox, no network access. It makes it much easier to layer a seccomp-bpf sandbox on top."

Comments (5 posted)

New vulnerabilities

beaker: information disclosure

Package(s):	beaker	CVE #(s):	CVE-2012-3458
Created:	September 10, 2012	Updated:	September 12, 2012
Description:	From the Debian advisory: It was discovered that Beaker, a cache and session library for Python, when using the python-crypto backend, is vulnerable to information disclosure due to a cryptographic weakness related to the use of the AES cipher in ECB mode. Systems that have the python-pycryptopp package should not be vulnerable, as this backend is preferred over python-crypto.
Alerts:	Debian DSA-2541-1 2012-09-07

Comments (none posted)

dnsmasq: DNS proxy is wrongly created

Package(s):	dnsmasq	CVE #(s):	CVE-2012-3411
Created:	September 12, 2012	Updated:	March 11, 2013
Description:	David Woodhouse reports: It seems that your dnsmasq instance is listening on that address, but *not* correctly discarding packets which come from a different interface. Even though the --bind-interface option is set. See the Red Hat bugzilla for more information.
Alerts:	Fedora FEDORA-2012-12598 2012-09-12 Mageia MGASA-2012-0273 2012-09-18 Fedora FEDORA-2012-20531 2013-01-03 Red Hat RHSA-2013:0276-02 2013-02-21 Red Hat RHSA-2013:0277-02 2013-02-21 Oracle ELSA-2013-0277 2013-02-25 Oracle ELSA-2013-0276 2013-02-28 Scientific Linux SL-dnsm-20130228 2013-02-28 Scientific Linux SL-libv-20130228 2013-02-28 CentOS CESA-2013:0277 2013-03-09 CentOS CESA-2013:0276 2013-03-09 Mandriva MDVSA-2013:072 2013-04-08

Comments (none posted)

freeradius: code execution

Package(s):	freeradius	CVE #(s):	CVE-2012-3547
Created:	September 12, 2012	Updated:	January 14, 2013
Description:	From the Debian advisory: Timo Warns discovered that the EAP-TLS handling of freeradius, a high-performance and highly configurable RADIUS server, is not properly performing length checks on user-supplied input before copying to a local stack buffer. As a result, an unauthenticated attacker can exploit this flaw to crash the daemon or execute arbitrary code via crafted certificates.
Alerts:	Debian DSA-2546-1 2012-09-11 openSUSE openSUSE-SU-2012:1200-1 2012-09-18 Ubuntu USN-1585-1 2012-09-26 Red Hat RHSA-2012:1326-01 2012-10-02 Red Hat RHSA-2012:1327-01 2012-10-02 Scientific Linux SL-free-20121003 2012-10-03 Oracle ELSA-2012-1326 2012-10-02 CentOS CESA-2012:1327 2012-10-03 CentOS CESA-2012:1326 2012-10-03 Mandriva MDVSA-2012:159 2012-10-03 Scientific Linux SL-free-20121003 2012-10-03 Oracle ELSA-2012-1327 2012-10-03 Fedora FEDORA-2012-15743 2012-10-18 Fedora FEDORA-2012-15397 2012-10-23 Mageia MGASA-2012-0304 2012-10-29 Oracle ELSA-2013-0134 2013-01-12 Mandriva MDVSA-2013:038 2013-04-05

Comments (none posted)

ghostscript: code execution

Package(s):	ghostscript	CVE #(s):	CVE-2012-4405
Created:	September 12, 2012	Updated:	April 10, 2013
Description:	From the Red Hat advisory: An integer overflow flaw, leading to a heap-based buffer overflow, was found in Ghostscript's International Color Consortium Format library (icclib). An attacker could create a specially-crafted PostScript or PDF file with embedded images that would cause Ghostscript to crash or, potentially, execute arbitrary code with the privileges of the user running Ghostscript.
Alerts:	Red Hat RHSA-2012:1256-01 2012-09-11 CentOS CESA-2012:1256 2012-09-11 CentOS CESA-2012:1256 2012-09-11 Scientific Linux SL-ghos-20120911 2012-09-11 Oracle ELSA-2012-1256 2012-09-11 Oracle ELSA-2012-1256 2012-09-11 Mandriva MDVSA-2012:151 2012-09-12 SUSE SUSE-SU-2012:1222-1 2012-09-19 Ubuntu USN-1581-1 2012-09-24 Fedora FEDORA-2012-13846 2012-09-28 Fedora FEDORA-2012-13839 2012-09-28 openSUSE openSUSE-SU-2012:1289-1 2012-10-04 openSUSE openSUSE-SU-2012:1290-1 2012-10-04 Mandriva MDVSA-2012:151-1 2012-10-05 Mageia MGASA-2012-0301 2012-10-20 Debian DSA-2595-1 2012-12-30 Mandriva MDVSA-2013:089 2013-04-09 Mandriva MDVSA-2013:090 2013-04-09

Comments (none posted)

GraphicsMagick: denial of service

Package(s):	GraphicsMagick	CVE #(s):	CVE-2012-3438
Created:	September 7, 2012	Updated:	March 26, 2013
Description:	From the Red Hat advisory: "As this function stands, it invisibly does the wrong thing for any request over 4GB. On big-endian architectures it very possibly will do the wrong thing even for requests less than that. So the reason why the hard-wired 4GB limit prevents a core dump is that it masks the ABI mismatch here." So basically we have memory allocations problems that can probably lead to a denial of service.
Alerts:	Fedora FEDORA-2012-12366 2012-09-07 Fedora FEDORA-2012-12352 2012-09-07 Mageia MGASA-2012-0267 2012-09-13 Mandriva MDVSA-2012:165 2012-10-12 openSUSE openSUSE-SU-2013:0536-1 2013-03-26

Comments (none posted)

mahara: cross-site scripting

Package(s):	mahara	CVE #(s):	CVE-2012-2237
Created:	September 10, 2012	Updated:	September 12, 2012
Description:	From the Debian advisory: Emanuel Bronshtein discovered that Mahara, an electronic portfolio, weblog, and resume builder, contains multiple cross-site scripting vulnerabilities due to missing sanitization and insufficient encoding of user-supplied data.
Alerts:	Debian DSA-2540-1 2012-09-07

Comments (none posted)

pnp4nagios: information disclosure

Package(s):	pnp4nagios	CVE #(s):	CVE-2012-3457
Created:	September 12, 2012	Updated:	September 12, 2012
Description:	From the CVE entry: PNP4Nagios 0.6 through 0.6.16 uses world-readable permissions for process_perfdata.cfg, which allows local users to obtain the Gearman shared secret by reading the file.
Alerts:	Fedora FEDORA-2012-13244 2012-09-12

Comments (none posted)

rpmdevtools: symlink attack

Package(s):	rpmdevtools	CVE #(s):	CVE-2012-3500
Created:	September 12, 2012	Updated:	April 10, 2013
Description:	From the Red Hat bugzilla: A TOCTOU race condition was found in the way 'annotate-output' (used to execute a program annotating the output linewise with time and stream) tool of rpmdevtools, a suite of scripts and (X)Emacs support files to aid in development of RPM packages, performed management of its temporary files used for standard output and standard error output. A local attacker could use this flaw to conduct symbolic link attacks, possibly leading to their ability in an unauthorized way to alter files belonging to the user running the 'annotate-output' tool.
Alerts:	Fedora FEDORA-2012-13234 2012-09-12 Fedora FEDORA-2012-13263 2012-09-12 Debian DSA-2549-1 2012-09-15 Ubuntu USN-1593-1 2012-10-02 Mageia MGASA-2012-0316 2012-10-29 openSUSE openSUSE-SU-2012:1437-1 2012-11-05 Mandriva MDVSA-2013:123 2013-04-10

Comments (none posted)

trousers: denial of service

Package(s):	trousers	CVE #(s):	CVE-2012-0698
Created:	September 7, 2012	Updated:	November 23, 2012
Description:	From the Red Hat advisory: This update closes a small security issue where a remote user could crash tscd if it were enabled for networking. This update also has improved init scripts which should make it load quicker.
Alerts:	Fedora FEDORA-2012-12973 2012-09-07 Debian DSA-2576-1 2012-11-23

Comments (none posted)

ubiquity-slideshow-ubuntu: code injection

Package(s):	ubiquity-slideshow-ubuntu	CVE #(s):	CVE-2012-0956
Created:	September 10, 2012	Updated:	September 12, 2012
Description:	From the Ubuntu advisory: Paul Mutton discovered that ubiquity-slideshow-ubuntu incorrectly handled the Twitter feed displayed during system installation. A remote attacker could use this flaw to inject code into the Twitter feed and read arbitrary files off the filesystem during system installation. This flaw has been resolved in the Ubuntu 12.04.1 LTS installation images by disabling the Twitter feed.
Alerts:	Ubuntu USN-1561-1 2012-09-10

Comments (none posted)

Xen: multiple vulnerabilities

Package(s):	Xen	CVE #(s):	CVE-2012-3494 CVE-2012-3495 CVE-2012-3496 CVE-2012-3498 CVE-2012-3516
Created:	September 7, 2012	Updated:	September 18, 2012
Description:	From the SUSE advisory: A malicious guest could cause a crash on the host which leads to a Denial of Service (CVE-2012-3494). A memory corruption related to PHYSDEVOP_get_free_pirq function could lead to a Denial of Service of the host or potentially to execution of arbitrary code (CVE-2012-3495). A BUG can be triggered via calling functions with invalid flags which causes a Denial of Service (host crash) (CVE-2012-3496). A malicious guest kernel could crash the host or potentially read hypervisor or guest memory (CVE-2012-3498). Unspecified vulnerability (CVE-2012-3516).
Alerts:	SUSE SUSE-SU-2012:1133-1 2012-09-07 Debian DSA-2544-1 2012-09-08 SUSE SUSE-SU-2012:1135-1 2012-09-07 openSUSE openSUSE-SU-2012:1174-1 2012-09-14 openSUSE openSUSE-SU-2012:1172-1 2012-09-14 SUSE SUSE-SU-2012:1162-1 2012-09-13 Fedora FEDORA-2012-13443 2012-09-17 openSUSE openSUSE-SU-2012:1572-1 2012-11-26 openSUSE openSUSE-SU-2012:1573-1 2012-11-26

Comments (none posted)

xen-qemu: privilege escalation

Package(s):	xen-qemu-dm-4.0	CVE #(s):	CVE-2012-4411
Created:	September 10, 2012	Updated:	November 20, 2012
Description:	From the Debian advisory: The qemu monitor was enabled by default, allowing administrators of a guest to access resources of the host, possibly escalate privileges or access resources belonging to another guest.
Alerts:	Debian DSA-2543-1 2012-09-08 Fedora FEDORA-2012-13434 2012-09-17 Fedora FEDORA-2012-13443 2012-09-17 SUSE SUSE-SU-2012:1486-1 2012-11-16 SUSE SUSE-SU-2012:1487-1 2012-11-16 SUSE SUSE-SU-2012:1503-1 2012-11-19 openSUSE openSUSE-SU-2012:1572-1 2012-11-26 openSUSE openSUSE-SU-2012:1573-1 2012-11-26

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel is 3.6-rc5, released on September 8. "So 3.6-rc5 is out there, and everything is looking fairly calm. Too calm, in fact, I'm waiting for the other shoe to drop, when Greg finally crawls his way out from under his mailbox after the kernel summit and kayaking. I suspect a few other developers may also have been quiet because of the kernel summit and related travel."

Stable updates: 3.2.29 was released on September 12 with the usual set of important fixes.

Comments (none posted)

Quotes of the week - the view from outside

— Bryan O'Sullivan

— Rich Felker

Comments (none posted)

Kernel development news

KS2012: Improving the maintainer model

Trond Myklebust led a discussion on day one of the 2012 Kernel Summit on how to improve the kernel maintainer model. He started with a comment from Thomas Gleixner that for 21 years the kernel development community has focused on scaling Linus, but has been rather slower in scaling the subsystem maintainer role. By this time, Linux is no longer a hobbyist project, and after 21 years it's probably time to focus more on scaling the maintainer role.

Trond noted that the kernel maintainer role is a mishmash that includes software architect, developer, reviewer, patch monkey, and software maintainer. In the context of a corporate project, these roles are typically held by multiple people. Trond noted that the maintainer role is to some extent already informally split, since we have reviewers, bug fixers, developers, and so on. However, he was interested to know whether it makes sense to give maintainers greater freedom to (formally) split out some of these roles, and if so, he requested that there should be a mechanism for formally recognizing this in the community (for example, via suitable annotation in the MAINTAINERS file).

One of the participants asked: what barriers keep somebody from taking on some of a maintainer's work? In response, Ted Ts'o indicated that there is no simple answer to that question, noting that kernel developers tend to set a higher bar for people with whom they have no history, whereas they set a lower bar (in terms of the kinds of changes that they permit) for people who have demonstrated a longer-term commitment to the code. "It's a human nature thing."

The conversation meandered over various topics. Along the way, Paul Gortmaker noted that the Documentation/SubmittingDrivers file could do with an update to align with current practices. Dave Jones noted that, likewise, REPORTING-BUGS could do with an update. In amongst the other discussion Linus noted that code that needs to go into two subsystems should be placed in a tree of its own that both subsystems can pull from, since the alternative (placing the code in one of the trees) create confusion when dealing with patches.

The discussion did not reach any definite conclusions about the maintainer role. However, it's clear that several maintainers are conscious that just as there was a need to improve Linus's scalability several years ago, the ever-increasing scale of the Linux kernel project means that now the subsystem-maintainer role could do with some scalability improvements of its own.

Comments (none posted)

KS2012: Stable kernel management

In a short session toward the close of day one of the 2012 Kernel Summit, Greg Kroah-Hartman, the maintainer of the stable kernel series, relayed one of his concerns about the stable kernel and sought questions and feedback from those present.

Greg stated that he had just one thing to complain about: subsystems that are not marking patches for stable. Here, Greg mentioned a few of those subsystems, and at the same time singled Dave Miller out for praise, noting that Dave was doing a lot of "heavy lifting" for networking. Greg then opened the session for feedback from others about stable kernel management.

Ted Ts'o noted "I'd love to be able to mark some less urgent patches as 'stable-deferred', so that if people discover regressions, I have a chance to pull them back." Greg said that that he would try to implement this functionality, as it is a good idea.

A few people wanted to understand more clearly the criteria that determine whether a patch should be sent for the stable series, and others noted that there seemed to be some latitude as to what Greg considered to be an acceptable patch. Greg acknowledged the latter point, with the statement that he trusted subsystem maintainers to make the call about what patches should be sent to stable@vger.kernel.org. As far as choosing which patches should be sent into stable, people were of course reminded of Documentation/stable_kernel_rules.txt and the summary rationale for stable: if the patch would be of interest for distributions aiming to produce a stable kernel for a distribution release, then that patch should be submitted to stable.

James Bottomley stated that he got a lot of patches for SCSI that don't apply to the stable kernel, so he strips the stable tag from them. He asked: "what should be done in that case?" Greg answered that he should leave that tag on, and then respond to the automated email he will get when the patch fails to apply to the stable kernel tree with the correct patch for that older kernel tree.

Greg concluded by asking whether the current release pace of the stable series was okay. There was general agreement that the pace—a release every one to two weeks—was good, and many people expressed appreciation for the excellent job Greg is doing on the stable kernel.

Comments (none posted)

KS2012: Improving tracing and debugging

Day one of the 2012 Kernel Summit saw a discussion on improving kernel tracing and debugging, led by Jason Wessel and Steven Rostedt. Jason's particular interest was how to get better tracing information from users who send in reports for kernel crashes.

Most of the session focused on Jason's proposal for kernel changes that would allow source line numbers to be displayed as part of the backtrace that is provided in the event of a kernel crash, so as to allow easier diagnosis of the source of the crash. The proposed technique is implemented by including ELF tables with the necessary symbol information in the compiled kernel. With Jason's patches, use of this feature is straightforward: the kernel is configured with CONFIG_KALLSYMS_LINE_LOCATIONS enabled and built with debugging information included. Once that is done, then events such as kernel panics will generate a call trace that includes source file names and line numbers:

    Call to panic() with the patch set
    ----------------------------------
    Call Trace:
     [<ffffffff815f3003>] panic+0xbd/0x14 panic.c:111
     [<ffffffff815f31f4>] ? printk+0x68/0xd printk.c:765
     [<ffffffffa0000175>] panic_write+0x25/0x30 [test_panic] test_panic.c:189
     [<ffffffff8118aa96>] proc_file_write+0x76/0x21 generic.c:226
     [<ffffffff8118aa20>] ? __proc_create+0x130/0x21 generic.c:211
     [<ffffffff81185678>] proc_reg_write+0x88/0x21 inode.c:218
     [<ffffffff81125718>] vfs_write+0xc8/0x20 read_write.c:435
     [<ffffffff811258d1>] sys_write+0x51/0x19 read_write.c:457
     [<ffffffff815f84d9>] ia32_do_call+0x13/0xc ia32entry.S:427

The improved call-tracing information that is provided by these patches would undoubtedly make life somewhat easier for diagnosing the causes of some kernel crashes. However, there is a cost: the memory footprint of the resulting kernel is much larger. During the session, a figure of 20 MB was mentioned, although in a mail that he later sent to the kernel summit discussion list, Jason clarified that the figure was more like 10 MB.

The large increase in kernel memory footprint that results from Jason's technique immediately generated some skepticism on its usefulness. As someone pointed out, such a large increase in kernel size would be unwelcome by users running kernels in cloud-based virtual machines such as Amazon EC2, where the available memory might be limited to (for example) 0.5 GB. Others suggested that it's probably possible to achieve the same result via a suitably built kernel that is loaded by kexec() in the event of a kernel crash. (However, there was some questioning of that idea also, since that technique might also carry a significant memory overhead.)

Linus then weighed in to argue against the proposal altogether. In his view, kernel panics are a small enough part of user bug reports that the cost of this approach is unwarranted; an overhead of something like 1 MB for the increase in memory footprint would be more reasonable, he thought. Linus further opined that one can, with some effort, obtain similar traceback information by loading the kernel into GDB.

Although Jason's proposed patches provide some helpful debugging functionality, the approach met enough negative response that it seems unlikely to be merged in anything like its current form. However, Jason may not be ready to completely give up on the idea yet. In his mail sent soon after the session, he hypothesized about some modifications to his approach that might bring the memory footprint of his feature down to something on the order of 5MB, as well as other approaches that could be employed so that the end user had greater control over when and if this feature was deployed for a running kernel. Thus, it may be that we'll see this idea reappear in a different form at a later date.

Comments (6 posted)

KS2012: Improving development processes: linux-next

The final session of day one of the 2012 Kernel Summit considered the linux-next tree and a possible complementary tree.

Steven Rostedt stated that he'd like to have a "linux-devel" tree, which would serve a similar purpose to that once served by Andrew Morton's "-mm" tree: it would be a place where reasonably stable code sits for a while for longer testing. He noted that such a tree might be useful for an API that hasn't yet stabilized, for example. Steven asked whether others would also be interested in something like this.

Chris Mason questioned whether such a tree could work in practice. "When your work and my work are together, people blame me for your bugs and vice versa." Based on experience with a similar approach in another project, Ben Herrenschmidt noted another problem: people started developing against that code base instead of the designated development base (i.e., the creation of a "linux-devel" might cause some people to develop against that tree instead of linux-next). Tony Luck noted that the value of a "linux-devel" tree would depend greatly on how much testing it received, and the sense was that such a tree would likely see less testing than linux-next, which itself could do with more testers.

Of course, even if a "linux-devel" tree was considered worthwhile, the tree would need a maintainer. In response to the question of how much work was required to maintain linux-next, the maintainer, Stephen Rothwell, said it required between four and ten hours per day, depending on the stage in the kernel-release cycle. In the end, as Steven Rostedt himself noted, the overall response to the proposal of a "linux-devel" tree was unenthusiastic.

Attention then briefly turned to the linux-next tree. Ted Ts'o asked: are people happy with how the tree was working? The overall consensus seemed to be that it was working well. H. Peter Anvin seemed to sum up the mood, in stating his overall contentment with linux-next while noting that "the imperfections of linux-next are reflections of the fact that it is a real-world creation". Ted asked in a tone that seemed to expect a negative answer, "does anyone run linux-next in anger on their development system?", and was a little surprised to see that quite a number of kernel developers indicated that they do eat their own dog food, living pretty much continuously on linux-next as the booted kernel on the work system that they use on a daily basis. After more than three years, it's clear that linux-next is by now an essential part of the kernel-development model.

Comments (2 posted)

KS2012: Kernel Summit feedback

Ted Ts'o led the final session of this year's Kernel Summit (KS), which was targeted at discussing the summit itself. Over the years, there have been various changes to the format and this year was no exception. The summit was co-located with and overlapped one day of the Linux Plumbers Conference (LPC); the minisummits were moved into the middle of the summit as well. Ts'o and others wondered how well that worked and looked for input on how the meetings should be structured in the future.

Putting the minisummits on day two (Tuesday August 28) turned that day into an "all-day hallway track" for those who weren't participating, Ts'o said. That had both good and bad points, but was in general well-received. The all-day hallway track and minisummits both got a boost from the early arrival of LPC attendees.

The topic choices for day one were good, according to H. Peter Anvin and others. A little more notice of the schedule would have been useful, Anvin said, so that participants could prepare for the discussions. Mel Gorman said that the summit was "sedate" overall, though he thought the topics were well selected. It was not very "entertaining", though, because there wasn't any fighting. Christoph Hellwig noted that the people "we fight with" weren't invited.

James Bottomley wondered if it would have been better to have a "cage fight" on the first day over the two competing NUMA scheduling approaches. Linus Torvalds noted that some may have avoided the memcg minisummit (where that discussion took place), even though they were interested in NUMA scheduling, so they "didn't have to hear about memcg". But Gorman said that particular problem may have been best handled "relatively privately" in the smaller memory-management-focused group at the memcg minisummit. Opening the discussion up to larger participation might have "made a bad situation a hell of lot worse".

Torvalds had his own complaint about the minisummits: their schedules. He would rather have had shorter sessions, rather than all-day meetings, because it made it harder to switch between them. He sat in on the PCI minisummit but felt like he would have been coming into the middle of the ARM minisummit by switching to attend the AArch64 discussion. He would rather see two-hour pre-announced BoF-like sessions.

Ts'o said some of the minisummit schedules came out quite late, which left no time to negotiate changes to reduce conflicts. Hellwig said that what Torvalds was suggesting, perhaps, was the elimination of the minisummits and instead to roll those discussions into longer LPC sessions. That might mean that KS and LPC should always be combined, Bottomley said. But, Arnd Bergmann was not convinced that the influx of LPC attendees was helpful for the ARM minisummit, which was already too big, he said, and got overrun with the additional people.

Others saw few problems in the overlap with LPC, to the point where juxtaposing KS and LPC each year was discussed. One problem with that is that LPC is a North American conference, whereas KS moves around the globe. Next year, LPC will be co-located with LinuxCon in New Orleans, while KS will either be in Edinburgh with LinuxCon Europe or somewhere in Asia, possibly Hong Kong. But, it doesn't matter what the conference is called, Hellwig said, but that the format remains and the same types of attendees are present. Anvin cautioned against tying LPC to KS, noting that it can be bad for the other conference in the long run, citing the KS/Ottawa Linux Symposium combination as an example.

It might be possible to see if LPC had any interest in moving to locations outside of North America, or setting up meetings like LPC wherever KS is being held. Chris Mason noted that KS can be a draw for plumbing layer developers no matter where it is held. Dirk Hohndel thought that the same kind of KS/LPC meetings could be set up anywhere and draw in developers from afar as well as those nearby, noting that Korea or Japan would be good candidates. Ts'o agreed that these kinds of meetings bring new people into the community. He said that Hong Kong is under consideration to draw in more Chinese developers, for example.

While the co-location with LPC was seen to be mostly beneficial, the addition of LinuxCon and CloudOpen was a bit much. Those conferences started on Wednesday, which resulted in a large influx of people. That led to some confusion: the rooms where meetings had been held the previous two days were no longer available, it was unclear where to get the lunch available for KS attendees (and there was confusion over who was allowed to eat), and so on. Most in the room were not in favor of doing quite that much overlap in the future. Hohndel noted that the Linux Foundation staff were going "insane" trying to make it all work, so it is unlikely something like that will happen again.

In answer to a question from Bottomley, most present were in favor of moving the KS location each year, and there were suggestions of other possible venues down the road. Some were less likely (e.g. Cuba), while others seem quite possible (e.g. South America, Korea, or Japan again). Changing the usual (northern hemisphere) summer to fall dates for KS was discussed, but the logistics of moving to spring were considered difficult. It would have to be done in stages so that the distance between summits was kept to roughly a year. That also means, for example, that co-locating with linux.conf.au sometime (which was suggested) would be hard to do because it is held in January.

The largely minor complaints aside, the general sense from the discussion was that this year's summit had served its purpose. It got kernel hackers together to discuss areas where the kernel development process could be improved. There will undoubtedly be more tweaks to the format over the years, but the summit itself—like the kernel development process—is working pretty well.

Comments (none posted)

LPC: The realtime microconference

Thomas Gleixner (Linutronix) led the 2012 Linux Plumbers Realtime Microconference in San Diego this year. This session went from 9:00 AM until noon on Friday morning and continued the highly civilized tone prevalent across the sessions of the various co-located conferences this year.

Thomas took a moment while opening the session to reflect on the passing of Dr. Doug Niehaus and his contributions to real-time operating systems.

Paul E. McKenney (IBM) kicked things off with his presentation on "Getting RCU Further Out of the Way" (reducing the overhead of RCU). Introducing no-callbacks CPUs (no-CBs) allows the RCU callbacks as well as the grace period processing to be offloaded to other CPUs. The callbacks are queued to new lists which require atomic operations and memory barriers to allow for concurrent access (as they are no longer created and executed on the same CPU). The prototype is limited by requiring at least one CPU to handle RCU callbacks in order to wait for the grace period and ensure the callbacks are run. It supports both polling mode as well explicit wake-up by call_rcu(). Peter Zijlstra suggested offloading only the callback processing by leaving the grace period processing on each CPU and moving the callbacks to the atomic list. Paul acknowledged it to be a good intermediate step, but also indicated that offloading the grace period processing should not be overly difficult. Several people indicated interest in the improvements.

Steven Rostedt (Red Hat) presented on the challenges of working PREEMPT_RT into mainline in his presentation, "The Banes of Mainline for RT". He discussed interrupt handling in the PREEMPT_RT kernel, which has periodically swung back and forth between more and fewer threads in an attempt to balance lowest latency with lowest overhead as well as maintainability and upstream acceptance. Per-device interrupt handlers are considered ideal as they allow for finer control of priorities for handlers on all-too-common shared interrupt lines.

He also spent some time discussing common livelock scenarios from mainline that the PREEMPT_RT kernel has to work around. Firstly, the use of a nested trylock defeats priority boosting. The solution is to drop the conflicting locks, acquire the lock and immediately release it, then attempt the lock sequence again. This approach ensures the priority boosting takes place and the possible inversion becomes bounded. The practice of __do_softirq() raising its own softirq in the event of a failed spin_trylock() can lead to a livelock in PREEMPT_RT where ksoftirqd is run at realtime priority and all softirqs are run as preemptable threads. The solution here is to simply acquire the spinlock for PREEMPT_RT, where the spinlock is converted into a mutex, allowing the lock holder to be scheduled and complete its critical section. Steven threatened getting rid of softirqs entirely.

Peter Zijlstra (Red Hat) briefly discussed the SCHED_DEADLINE scheduler, including a request for would-be users to provide details of their use cases which he can use to justify the inclusion of the code upstream. While he is in favor of pushing the patches, apparently even Peter Zijlstra has to provide convincing evidence before pushing yet another scheduling policy into the mainline Linux kernel. It was reiterated that many media applications for Mac OSX use the Mac EDF scheduler. Juri Lelli noted that Scuola Superiore Sant'Anna has "toy" media players that use SCHED_DEADLINE. Contacting the JACK community was suggested as well. As SCHED_DEADLINE requires the application to specify its periodicity and duration, adoption may be slow. Fortunately, there are straightforward methods of determining these parameters.

Frank Rowand (Sony) prepared some material on the usage of PREEMPT_RT with an emphasis on the stable trees. He also presented some wishlist items collected from users. While Thomas produces patch tarballs for the development PREEMPT_RT tree, Steven currently releases stable PREEMPT_RT as a git branch. While interest remains for the git branches, Steven has agreed to also release the stable trees as patch tarballs (including previous releases). Some confusion was noted regarding the development process for the stable trees, such as which mailing lists to use, as well as the difference between Steven's stable branches and the "OSADL Latest Stable" releases. It was agreed to add this information in a README, and include that in-tree along with the PREEMPT_RT releases.

Some sort of issue tracker was requested. Darren Hart (Intel) and Clark Williams (Red Hat) agreed to work with bugzilla.kernel.org to get one setup for the PREEMPT_RT tree.

Frank continued to lead a lengthy discussion on the stable real-time release process. The two areas of concern were the amount of testing these trees receive and which versions to continue supporting (including the number of concurrent trees). While Steven's stable trees are widely used by numerous organizations, they do not receive much testing outside his machines before they are released. It should be noted, however, that any patches to his stable trees must have first spent some time in Thomas's development tree, and have therefore seen some testing before they are pulled in.

Carsten Emde's (OSADL) long-term load systems, on the other hand, perform sequential long-running cyclictest runs, one of which recently completed one year of uptime without violating real-time constraints in 160 billion cycles. Carsten, who was not present, defines the OSADL Latest Stable criteria as: "all our development systems in the QA Farm must be running this kernel for at least a month under all appropriate load scenarios without any problem." Thomas has agreed to add Steven's trees to his automated testing to help improve the level of testing of the stable releases.

As for the longevity of the long-term stable releases (3.0, 3.2, 3.4, ...) Steven drops support for a stable release when Greg Kroah-Hartman does. Ben Hutchings's stable tree appears to be the sole exception. Steven will continue to support one Hutchings stable tree at a time, so long as time permits.

Darren brought up longer term support and alignment with the Long-Term Support Initiative as the Yocto Project supports both PREEMPT_RT as well as LTSI, and alignment here significantly reduces the support effort. If an LTSI PREEMPT_RT tree is to be maintained, someone will need to volunteer for the task. Darren indicated the Yocto Project is likely to do so.

Following Frank, Luis Claudio Goncalves (Red Hat) discussed the joys of working with customers on real-world use-cases. Customers often push the boundaries of what has been tested by running on much larger systems than you might expect. They also frequently run into performance issues or livelocks with programming mechanisms that more or less work in mainline, but definitely do not when running with real-time priority. CPU-bound threads, including busy loops to avoid latency via polling, can starve the system when run as a high-priority realtime threads, resulting in large latency spikes or system freezes. Running a single process with 1000 threads leads to heavy contention on mmap_sem; large changes would be required for PREEMPT_RT to deal with this scenario well.

The concept of CPU isolation has its own pitfalls. An "isolated" CPU still runs several kernel threads and requires housekeeping, while users may expect the CPU to run only the isolated application. In these scenarios, the application is commonly set to SCHED_FIFO at priority 99, resulting in severe latencies and system freezes as the lower priority kernel threads are prevented from running. A list of the current work that must be performed by the kernel on an isolated CPU is documented in Gilad Ben-Yossef's Linux wiki. Some of the issues listed there have been fixed or at least minimized. Paul's presentation addressed two of them. Additionally, Luis has volunteered to work on some best practices documentation, but has asked for people to help review.

In closing, Thomas noted that there would not be a 3.5-rt release, but that he would be looking at 3.6 for the next PREEMPT_RT release. The further refinement of IRQ handling was mentioned as one of the most noteworthy changes planned for the 3.6-rt release.

Thanks to all the presenters, participants, and reviewers, as well as Paul E. McKenney, whose notes helped to show that two note-takers are better than one.

Comments (1 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 3.6-rc5 . (September 9, 2012)

• Ben Hutchings: Linux 3.2.29 . (September 12, 2012)

Core kernel code

• Alexandre Courbot: Runtime Interpreted Power Sequences . (September 12, 2012)

Development tools

• Mel Gorman: MMTests 0.05 . (September 7, 2012)

• Soren Sandmann: Announce: Sysprof 1.2.0; system-level profiler for Linux . (September 10, 2012)

• Anton Vorontsov: KGDB/KDB FIQ (NMI) debugger . (September 10, 2012)

Device drivers

• Ming Lei: driver core: driver probe asynchronously . (September 10, 2012)

• Kim, Milo: iio: adc: add new lp8788 adc driver . (September 10, 2012)

• Sebastian Hesselbarth: pinctrl: mvebu: pinctrl driver . (September 10, 2012)

• wei_wang@realsil.com.cn: Add modules to support realtek PCIE card reader . (September 12, 2012)

• Damian Hobson-Garcia: Add UIO device supporting dynamic memory allocation . (September 12, 2012)

• Hideki EIRAKU: Renesas IPMMU driver for sh7372 . (September 12, 2012)

• Philipp Zabel: Initial i.MX5/CODA7 support for the CODA driver . (September 12, 2012)

Filesystems and block I/O

• Jeff Layton: vfs: getname/putname overhaul . (September 7, 2012)

• Jeff Layton: vfs: add the ability to retry on ESTALE to several syscalls . (September 10, 2012)

• Kent Overstreet: Prep work for immutable bio vecs . (September 10, 2012)

• zwu.kernel@gmail.com: VFS: hot data tracking . (September 12, 2012)

• Paolo Bonzini: block: add queue-private command filter, editable via sysfs . (September 12, 2012)

• Cyrill Gorcunov: auxiliary fdinfo, new round . (September 12, 2012)

Memory management

• Lai Jiangshan: memory,numa: introduce MOVABLE-dedicated node and online_movable for hotplug . (September 10, 2012)

• Kirill A. Shutemov: Introduce huge zero page . (September 12, 2012)

Architecture-specific

• Lee Jones: First HREF Device Tree enablement patch-set . (September 7, 2012)

• Catalin Marinas: AArch64 Linux kernel port . (September 10, 2012)

• Rob Herring: Initial multi-platform support . (September 10, 2012)

• Arnd Bergmann: Per sub-architecture SMP operations . (September 12, 2012)

Security-related

• Jeff Layton: audit: overhaul audit_names handling to allow for retrying on path-based syscalls . (September 7, 2012)

Miscellaneous

• Lucas De Marchi: kmod 10 . (September 7, 2012)

Page editor: Jonathan Corbet

Distributions

Bedrock Linux

The Linux ecosystem does not lack for distributions; there are hundreds of them catering to almost any need that one might think of. But where does that leave the poor user who is unable to decide between the virtues of two or more different distributions? Distribution choice tends to be all-or-nothing: there is no easy way to obtain the benefits from multiple distributions at the same time on a single machine. That is a situation that the folks at Bedrock Linux are trying to change — but the result is unlikely to be suitable for everybody.

The design goal of Bedrock Linux is to allow users to mix and match pieces from multiple distributions at will. If one wants something that looks mostly like openSUSE, but with the ability to source-install a bleeding-edge LibreOffice from Gentoo next to tried-and-stable PostgreSQL server from CentOS, Bedrock Linux will make that possible. If one wants to fall back to Emacs from Debian stable because the latest Rawhide update broke it again, one can. As the project web site says: "Packages feel disposable, like toothpicks. No need to fret over one breaking; just use another." The end result should be a world where users never have to commit to a specific distribution because all distributions of interest to them will be available simultaneously.

The Bedrock Linux core exists mostly to boot the system and facilitate the running of applications from multiple "client" distributions. As such, it is a bit of a strange and minimal beast. The syslinux bootloader is used to keep things as simple as possible. The kernel is Linux, of course; the Bedrock user space is based on Busybox, so there is not a lot to it. It is all intended to be robust and to function even if an important client distribution breaks; to that end, the core Bedrock binaries are all statically linked. Static linking is also needed to ensure that those utilities will work regardless of the client distribution context they might be run in.

The client distributions are installed under /var/chroot, so /var/chroot/fedora would host a Fedora installation. Users can run a command out of any distribution, but the work that must be done under the hood to make that happen is significant. As might be guessed from the directory names, Bedrock Linux uses the chroot() system call to run programs in the distribution context they expect. The brc command makes all this happen; typing:

    brc fedora firefox

would use chroot() to restrict the process's view to /var/chroot/fedora, then run the firefox binary from there.

The idea is conceptually simple, but it quickly runs into complications. What if that firefox binary wants to run a helper program from a different distribution? That requires the ability to break out of the restricted root, somehow. Bedrock makes this happen with a combination of setuid binaries and bind mounts. From the outside, it looks like it might have been better to make use of namespaces to reshape each process's view of the filesystem, but that is not the direction Bedrock took.

The result is that everything that must be visible to any distribution-specific program must be bind-mounted into the restricted root. That is, to begin with, how commands get access to the user's home directory. Regardless of which distribution context a process is running in, /home will be properly mounted to be visible there. In the current alpha release (1.0alpha2, known as "Momo"), every process has all of the directories for all distributions bind-mounted into it. This mounting is done on the fly as commands are run, leading to some complex topologies.

That complexity turns out to be a bit of a problem; as the Bedrock developers say in the notes for the upcoming 1.0alpha3 release:

Performance is at the top of the list of "down sides," but it's clear that a system configured like this can be unwieldy in a number of ways. So it will be replaced in 1.0alpha3 with a new version of the brc command that, when a distribution boundary is to be crossed, will simply break out of the restricted root and enter a new one for the new distribution. That eliminates the need to set up lots of new bind mounts at every command invocation, at the cost of needing to run a setuid breakout program instead.

Given that initialization systems have been a hot topic recently, one might well wonder what Bedrock does in this area. Can one easily switch from, say, OpenRC to systemd? The answer is that Bedrock literally does nothing:

Setting up Bedrock, thus, is not a task for users wanting a one-click installation experience. Especially since Bedrock does not really have an installer of its own at all. The FAQ entry on why there is no installer is amusing reading, to say the least. Suffice to say that Bedrock, for now, is for users who want to do a lot of their own setup and tweaking. It may be especially well suited for those users who have gotten frustrated with the way distributions like Gentoo do everything for them.

It is also not for users who want something in a hurry; 1.0alpha3 is planned for release by "end-of-summer 2013." And that will still be an alpha release.

Whether Bedrock Linux will ever get past the alpha stage is anybody's guess. It has the look of an ambitious project with a relatively small amount of developer time available to it. It also looks a little bit insane. But, then, what is free software for if somebody can't take an insane idea and run with it? Some interesting ideas may well come out of the Bedrock Linux project; it will be fun to watch.

Comments (7 posted)

Brief items

Distribution quotes of the week

-- Scott Kitterman

-- Lennart Poettering (Thanks to Matthew Miller)

Comments (8 posted)

Ubuntu 12.10 (Quantal Quetzal) Beta 1 Released

The first beta release of Ubuntu 12.10 "Quantal Quetzal" is now available. Desktop, Server, Cloud, and Core images are available, but this release does do away with the separate CD, DVD, and "alternate" desktop images provided for previous releases, in favor of a single consolidated ISO. Updated packages include xserver 1.13, Python 3, and KDE 4.9.

Full Story (comments: 10)

Distribution News

Debian GNU/Linux

bits from the DPL: August 2012

Debian Project Leader Stefano Zacchiroli reports on his August activities. Topics include trademark policy, DebConf infrastructure, a vacancy on the technical committee, new hardware, and more.

Full Story (comments: none)

Bits from the FTPTeam, upcoming meeting

Debian's FTPTeam presents a few bits, including a team introduction, a call for volunteers, some expected archive outages during the sprint (September 14-21), and a wrap up of this year's GSoC project.

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

• DistroWatch Weekly, Issue 473 (September 10)
• Maemo Weekly News (September 10)
• Ubuntu Weekly Newsletter, Issue 282 (September 9)

Comments (none posted)

Page editor: Rebecca Sobol

Development

Bazaar on the slow track

The Bazaar (or "bzr") version control system lacks the visibility of systems like Git or even Mercurial. That is not to say that it is an insignificant project: it has a dedicated following of its own, it is the system used internally at Canonical, and it has been designated as an official GNU project (meaning that other GNU projects are expected to use it). So one would not think that Bazaar was a project in danger of running out of steam and grinding to a halt. But that, it seems, is exactly the scenario that some of its users are worried about.

Stefan Monnier kicked off the discussion by noting that the number of commits to Bazaar has been dropping and that bugs are not getting fixed. The departure of lead developer Martin Pool from Canonical (and from the Bazaar project) has certainly not helped the situation. So, Stefan said:

Some participants questioned whether there was a problem, noting that commits continue to flow into the Bazaar repository. But Matthew Fuller ran the numbers and came to a fairly clear conclusion:

This slowdown has happened despite the fact that a new major release (2.6) was expected in August. When that release does happen, the list of new features seems unlikely to knock the socks off many users. Bazaar, as a project, may not be dead, but it shows signs of going into a sort of maintenance mode.

What is going on?

Once one accepts that development on Bazaar is slowing, it is natural to wonder why that is and what can be done about it. One possibility is that the distributed version control problem has been solved and that there is little need for more development. After all, significant projects like bash and make have not shown blistering rates of development; there simply is no need at this point. In the distributed version control system area, though, it would be hard to say that there are no challenges remaining. Projects like Git and Mercurial continue to evolve at a high rate. So, in a general sense, it would be hard to say that Bazaar is slowing down because there's nothing more to do.

That doesn't mean that Canonical, which has sponsored most of the work on Bazaar, sees more that needs to be done. Indeed, according to John Arbash Meinel (Martin Pool's replacement as Bazaar lead developer), Canonical is happy with the current state of affairs:

He added that Bazaar wasn't in danger of disappearing anytime soon. "It is still being actively maintained, though a little less actively than last year." That statement was seen by some as an oblique way of saying that Bazaar is now in maintenance mode — a prospect that was not seen as particularly reassuring by Bazaar users.

Of course, Bazaar is free software, licensed under the GPL, so anybody is free to step up and carry it forward. Thus far, though, that has not happened. Once again, it is worthwhile to think about why that might be. Possibly Bazaar users got comfortable with Canonical carrying the load of Bazaar development and have not, yet, felt the need to help out. Over time, some of these users might decide that it is time to pick up some of that load going forward. Or they might just switch to another system with a more active community.

One possibility, raised by Ben Finney, is that Canonical's much-maligned contributor agreement is a part of the problem. This reasoning says that, since Canonical reserves the right to release contributions to Bazaar under proprietary licenses, many potential contributors have voted with their feet and gone elsewhere. It's far from clear that the contributor agreement is really part of the problem, though. If there were really a community of developers who would contribute if only the terms were more fair, an agreement-less Bazaar fork would almost certainly have emerged by now. The fact that nobody has even attempted such a fork suggests that Canonical's agreement is not really holding things back.

Stephen Turnbull had an interesting alternative explanation for what is going on. Bazaar, he says, is a tool aimed at users who want their version control system to "just work" without them having to think about it much. Git, he says, is a different matter:

Some participants saw this suggestion as a sort of insult against Bazaar users, saying that they lacked the ability or the drive to improve the tool. But that is not what Stephen was saying; his point is that, by appealing to users who don't want to have to think about their version control system, Bazaar has created a user community that is relatively unlikely to want to put their time into making the system better.

There is an alternative that nobody has mentioned in this discussion: perhaps Bazaar has simply lost out to competing projects which have managed to advance further and faster. For sheer functionality, Git is hard to compete with. For those who are put off by the complexity of Git, Mercurial offers a gentler alternative without compromising on features. Perhaps most potential users just do not see anything in Bazaar that is sufficiently shiny to attract them away from the other tools.

If that is the case, it is hard to imagine what can be done to improve the situation from the point of view of Bazaar users, especially given that Canonical has lost interest in adding features to Bazaar. Perhaps, as Ben suggested, another corporate sponsor could be found to take up the Bazaar banner. Failing that, Bazaar seems likely to stay in maintenance mode indefinitely; it will remain a capable tool, but will find itself increasingly left behind by the other free alternatives.

Comments (118 posted)

Brief items

Quotes of the week

— Greg Raiz

— Will Stephenson

Comments (none posted)

GSRC 2012.09.06 released

A new version of the GNU Source Release Collection (GSRC) is available. GSRC is a utility to "fetch, build and install the latest GNU software from source via a BSD Ports-like system." This release supports 271 GNU project packages.

Full Story (comments: none)

PostgreSQL 9.2 released

The PostgreSQL 9.2 release is available. "Since the beta release was announced in May, developers and vendors have praised it as a leap forward in performance, scalability and flexibility. Users are expected to switch to this version in record numbers." LWN ran a detailed look at this release in May.

Full Story (comments: 14)

GNU patch version 2.7 released

Version 2.7 of the GNU patch utility — the first release in almost three years — is out. It offers various improvements to the accepted patch format including nearly full support for the "diff --git" format, a number of security-related fixes, nanosecond-precision timestamp support, and more.

Full Story (comments: 3)

The Opus codec becomes an IETF standard

The Mozilla Hacks blog announces that the Opus codec is now an official IETF standard; it is RFC6716. "Opus is the first state of the art, free audio codec to be standardized. We think this will help us achieve wider adoption than prior royalty-free codecs like Speex and Vorbis. This spells the beginning of the end for proprietary formats, and we are now working on doing the same thing for video."

Comments (24 posted)

SyncEvolution 1.3 released, hosting at freedesktop.org

Version 1.3 of the SyncEvolution data synchronization framework is available. This release adds support for syncing with KDE's Akonadi or Microsoft's ActiveSync, and for synchronizing CalDAV tasks and memos. The project has also moved its infrastructure from meego.com to freedesktop.org.

Full Story (comments: none)

Newsletters and articles

Development newsletters from the last week

• Caml Weekly News (September 11)
• What's cooking in git.git (September 7)
• What's cooking in git.git (September 10)
• What's cooking in git.git (September 11)
• Haskell Weekly News (September 5)
• Mozilla Hacks Weekly (September 6)
• OpenStack Community Weekly Newsletter (September 7)
• Perl Weekly (September 10)
• PostgreSQL Weekly News (September 10)
• Ruby Weekly (September 6)
• Tahoe-LAFS Weekly (September 10)

Comments (none posted)

Study for US Congress outlines options against patent trolls (The H)

The H takes a look at a report from the US Congressional Research Service about patent trolling and potential fixes to the system. "According to the researchers, it is worth considering whether to generally shorten the periods of protection for software patents because the trolls file most of their litigation claims in the last three years of the 20-year term. A patent could also be invalidated if it hasn't been practised for a number of years, they added."

Comments (23 posted)

Rodriguez: All 48 Liberated Pixel Cup entries reviewed

On his blog, Juan "Nushio" Rodriguez has been systematically reviewing all of the entries in the OpenGameArt project's Liberated Pixel Cup (LPC) free software game contest in recent weeks. Reviews of all 48 games are now available. Note that these are personal assessments, not the results of LPC's official judges. Note also that Rodriguez is an LPC contestant, so he had someone else review his own entry, presumably to add a bit more suspense.

Comments (none posted)

Cinelerra 4.4 released with new audio processing features (Libre Graphics World)

Libre Graphics World reports on the release of version 4.4 of the venerable Cinelerra video editing system. "The amount of changes is quite modest, and half of them are in the audio department. the developer claims better live audio processing, as well as audio gaps removal effect and audio oscilloscope. Apart from that, you are likely to experience faster startup, more responsive interface, better recording from webcams, and you definitely get a new Bright UI theme."

Comments (none posted)

Meeks: Linux on the (consumer) Desktop

Here's a lengthy posting from Michael Meeks on the state of the desktop market. "The economics of an excessively cheap product are a difficult fit for the consumer market, and drain money from the ecosystem necessary to invest in development. The relentless drive to a zero cost-point to gain market share in Linux Desktop pre-loading helps to further sterilize the space." He suggests that the business desktop may be a better target for a Linux-based solution.

Comments (92 posted)

Page editor: Nathan Willis

Announcements

Brief items

FSFE: Unitary patent threatens innovation in Europe

The European Parliament's Legal Affairs committee will be discussing a proposal for an EU-wide patent. The Free Software Foundation Europe (FSFE) will be following the discussion which takes place September 17-18, 2012.

Full Story (comments: none)

Linux Scholarship Winners

The Linux Foundation has announced the winners of its 2012 Linux Training Scholarship Program. "More than 500 submissions were received during the second year of this program, which is more than double the number of submissions reviewed in 2011. The Linux Training Scholarship Program awards five scholarships to computer science students and Linux developers or systems administrators who show incredible promise for helping to shape the future of Linux but do not otherwise have the ability to attend Linux Foundation training courses."

Full Story (comments: none)

Calls for Presentations

LCA2013 Sysadmin Miniconf CFP

The call for papers is out for the System Administration miniconf at the 2013 linux.conf.au (LCA). "Topics for presentations could include (but are not limited to): Systems Administration, Backups, Security, Dealing with "Bring Your Own Device", Troubleshooting, Buying Decisions, Virtualisation and Cloud Computing, DevOps, Enterprise Monitoring and Management, Identity Management, Two Factor Authentication, Web and Email management, Wiki, Clustering and High Availability, Log Management, Spam and Virus Filtering, VOIP, Ticketing systems, Bootstrapping and automated installation, Configuration Management, Packaging and Provisioning, Keeping legacy systems functioning." The deadline for early submissions is October 1, 2012. November 1 is a hard deadline for all submissions. LCA2013 will take place January 28-February 2 in Canberra, Australia.

Full Story (comments: none)

SCALE 11x Call for Papers starts

The call for papers for the Southern California Linux Expo SCALE 11x is open until December 10, 2012. SCALE 11x will be held February 22-24, 2013 in Los Angeles, California.

Full Story (comments: none)

Upcoming Events

PostgreSQL Conference Europe 2012 Schedule out

The schedule for the PostgreSQL Conference (October 23-26 in Prague, Czech Republic) is available. "In addition to [Joe] Celko's keynote, other luminaries of the open source community and the business and public sectors including Bruce Momjian, co-founder of the PostgreSQL Global Development Group, EnterpriseDB, Magnus Hagander, Redpill Linpro, and Josh Berkus, PGExperts, all members of the PostgreSQL Core Team, as well as Simon Riggs, CTO of 2ndQuadrant and Guillaume Lelarge, CTO of Dalibo, both long-time contributors to the PostgreSQL community, will address topics ranging from database internals to end-user case studies for small companies, large multinational corporations and government organisations. The conference offers multiple parallel tracks and sessions in English and Czech. There will be PostgreSQL training sessions on October 23, the day prior to the opening day, with half and full day sessions on a range of topics."

Full Story (comments: none)

PyCon DE 2012 - Detailed program online

The program for PyCon DE is available online and registration is open. Registration is also open for the barcamp, code retreat, and sprints. PyCon DE will take place October 29-November 3, 2012 in Leipzig, Germany.

Full Story (comments: none)

Registration Open for Tcl'2012

Registration is open for the 19th Annual Tcl/Tk Conference (Tcl'2012), which will take place November 12-16 in Chicago, Illinois.

Full Story (comments: none)

Events: September 13, 2012 to November 12, 2012

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

Date(s)	Event	Location
September 10 September 13	International Conference on Open Source Systems	Hammamet, Tunisia
September 14 September 16	Debian Bug Squashing Party	Berlin, Germany
September 14 September 16	KPLI Meeting Indonesia Linux Conference 2012	Malang, Indonesia
September 14 September 21	Debian FTPMaster sprint	Fulda, Germany
September 15 September 16	PyTexas 2012	College Station, TX, USA
September 15 September 16	Bitcoin Conference	London, UK
September 17 September 19	Postgres Open	Chicago, IL, USA
September 17 September 20	SNIA Storage Developers' Conference	Santa Clara, CA, USA
September 18 September 21	SUSECon	Orlando, Florida, US
September 19 September 20	Automotive Linux Summit 2012	Gaydon/Warwickshire, UK
September 19 September 21	2012 X.Org Developer Conference	Nürnberg, Germany
September 21	Kernel Recipes	Paris, France
September 21 September 23	openSUSE Summit	Orlando, FL, USA
September 24 September 25	OpenCms Days	Cologne, Germany
September 24 September 27	GNU Radio Conference	Atlanta, USA
September 27 September 28	PuppetConf	San Francisco, US
September 27 September 29	YAPC::Asia	Tokyo, Japan
September 28	LPI Forum	Warsaw, Poland
September 28 September 30	PyCon India 2012	Bengaluru, India
September 28 September 30	Ohio LinuxFest 2012	Columbus, OH, USA
September 28 October 1	PyCon UK 2012	Coventry, West Midlands, UK
October 2 October 4	Velocity Europe	London, England
October 4 October 5	PyCon South Africa 2012	Cape Town, South Africa
October 5 October 6	T3CON12	Stuttgart, Germany
October 6 October 8	GNOME Boston Summit 2012	Cambridge, MA, USA
October 11 October 12	Korea Linux Forum 2012	Seoul, South Korea
October 12 October 13	Open Source Developer's Conference / France	Paris, France
October 13	2012 Columbus Code Camp	Columbus, OH, USA
October 13 October 14	Debian Bug Squashing Party in Utrecht	Utrecht, Netherlands
October 13 October 14	Debian BSP in Alcester (Warwickshire, UK)	Alcester, Warwickshire, UK
October 13 October 14	PyCon Ireland 2012	Dublin, Ireland
October 13 October 15	FUDCon:Paris 2012	Paris, France
October 15 October 18	Linux Driver Verification Workshop	Amirandes,Heraklion, Crete
October 15 October 18	OpenStack Summit	San Diego, CA, USA
October 17 October 19	MonkeySpace	Boston, MA, USA
October 17 October 19	LibreOffice Conference	Berlin, Germany
October 18 October 20	14th Real Time Linux Workshop	Chapel Hill, NC, USA
October 20 October 21	PyCarolinas 2012	Chapel Hill, NC, USA
October 20 October 21	PyCon Ukraine 2012	Kyiv, Ukraine
October 20 October 21	Gentoo miniconf	Prague, Czech Republic
October 20 October 21	LinuxDays	Prague, Czech Republic
October 20 October 23	openSUSE Conference 2012	Prague, Czech Republic
October 22 October 23	PyCon Finland 2012	Espoo, Finland
October 23 October 25	Hack.lu	Dommeldange, Luxembourg
October 23 October 26	PostgreSQL Conference Europe	Prague, Czech Republic
October 25 October 26	Droidcon London	London, UK
October 26 October 27	Firebird Conference 2012	Luxembourg, Luxembourg
October 26 October 28	PyData NYC 2012	New York City, NY, USA
October 27	pyArkansas 2012	Conway, AR, USA
October 27	Central PA Open Source Conference	Harrisburg, PA, USA
October 27	Linux Day 2012	Hundreds of cities, Italy
October 27 October 28	Technical Dutch Open Source Event	Eindhoven, Netherlands
October 29 November 1	Ubuntu Developer Summit - R	Copenhagen, Denmark
October 29 November 2	Linaro Connect	Copenhagen, Denmark
October 29 November 3	PyCon DE 2012	Leipzig, Germany
October 30	Ubuntu Enterprise Summit	Copenhagen, Denmark
November 3 November 4	MeetBSD California 2012	Sunnyvale, California, USA
November 3 November 4	OpenFest 2012	Sofia, Bulgaria
November 5 November 7	LinuxCon Europe	Barcelona, Spain
November 5 November 7	Embedded Linux Conference Europe	Barcelona, Spain
November 5 November 8	ApacheCon Europe 2012	Sinsheim, Germany
November 5 November 9	Apache OpenOffice Conference-Within-a-Conference	Sinsheim, Germany
November 7 November 8	LLVM Developers' Meeting	San Jose, CA, USA
November 7 November 9	KVM Forum and oVirt Workshop Europe 2012	Barcelona, Spain
November 8	NLUUG Fall Conference 2012	ReeHorst in Ede, Netherlands
November 9 November 11	Python Conference - Canada	Toronto, ON, Canada
November 9 November 11	Mozilla Festival	London, England
November 9 November 11	Free Society Conference and Nordic Summit	Göteborg, Sweden
November 10 November 16	SC12	Salt Lake City, UT, USA

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

Page editor: Rebecca Sobol