LWN.net Weekly Edition for April 12, 2012

LFCS 2012: Trademarks for free software projects

When last we covered a trademark talk by Karen Sandler, she was a lawyer on staff at the Software Freedom Law Center (SFLC), and part of her job was to deal with trademark issues for free software projects. She is still a lawyer, of course, but has switched her focus now that she is the executive director of the GNOME Foundation, and that gives her some new perspectives on trademarks. She came to the Collaboration Summit to talk about "Real World Trademark Management for Free Software Projects" on April 4.

By way of an introduction, Sandler gave the usual disclaimers (I am not your lawyer and this is not legal advice), while noting that lawyers are also known for saying "it depends". While it can be somewhat annoying to get that answer from a lawyer, she said, it really is true. Lawyers can tell you what the "general situation is in the law", but each case is different.

Beyond her work for GNOME, she is also a pro bono counsel for SFLC and the Software Freedom Conservancy (SFC). She is an advisor for the Ada Initiative, as well as a mentor for the GNOME outreach program for women. She noted that the latter had recently dropped the GNOME from its name when the SFC joined the project. She is also a self-described cyborg and interested in software transparency for medical devices.

What are trademarks?

There are a lot of misunderstandings in the community about trademarks, but it is a fairly straightforward idea. A trademark is bound up in branding and identity so that consumers can recognize the brand at a glance. A trademark can be words, pictures, or both, but it needs to be incorporated into the product itself (packaging, etc.) in order to make the association in a consumer's mind.

Unlike copyright, which is granted as soon as the work is "fixed in a tangible medium", a trademark actually needs to be used. If you make a logo in your room, don't associate it with any product, and don't show it to anyone, it's not really a trademark, while doing the same things will get you a copyright on that logo. Even if you don't register a trademark, you still get some protection based on it being used on a product of some kind. Patents, of course, are completely separate as they cover ideas and inventions.

There is an inherent tension between protecting trademarks and the ideals of free software. Free software is all about remixing and building on top of the work of others, and our licenses are very clear on that point. But trademarks are different, and projects need to think about the ways they want to allow their trademark to be used.

Trademarks and identity

Everything about trademarks is connected to identity. If someone repackaged some parts of GNOME, with other, possibly proprietary or malicious code, would there be confusion if it used the GNOME trademarks? The tricky part is to allow all of the things that the project wants to allow without letting people abuse the trademark. It is "really tough" to draw that line, so her suggestion is that a project make policies that explicitly say what is a permissible use of the trademark.

It is important to note that there are some trademark concepts that need to be considered. One is the idea of "naked licensing", which comes into play if a mark holder allows it to be used too widely. The example she gave was a wine company that allowed other winemakers to use its name, without having any real connection to its brand—in fact the trademark holder never even sampled the wine in question. If that happens, one can lose control of the trademark.

A related idea is that of "generic-izing" a name. If a brand becomes too popular and the brand name is used to refer to a number of different products in the same category, control over the trademark can be lost. The classic examples of this (at least in the US) are Kleenex for facial tissue and Xerox for photocopiers. In both cases, consumers and others started using the trademark name generically ("xerox that document" rather than copy or photocopy it), which meant that they were no longer associating it with the brand. You can be "too successful and consequently lose your mark", Sandler said.

Policies

Whatever policies a project devises, they will get tested "all the time". There will be questions that live on the boundaries of the policy. She handled some of that at SFLC and now does a lot of work on that for GNOME. It is difficult to anticipate all of the ways that people might want to use a trademark. She said that she is an optimist by nature, but has been trained to be a pessimist when it comes to trademarks and other legal matters.

It is best to have a policy with as many parameters as possible. Start by stating exactly what can be done with the mark and different projects will have their own ideas about usage of trademarks. For example, it might state that one can use "based on GNOME" when it is substantially unmodified from the upstream code. If it is modified, the policy may want to say that the mark should not be used at all.

Another common problem is whether it is permissible to use the mark in another name, like fooPlus or DifferentFoo. That's a particularly problematic question she said, because you generally want to err on the side of restricting the use of the mark, but you also want to ensure that the software is freely usable. Another area that any policy should address is merchandise (T-shirts, hats, stickers, etc.); can the logo or name be used on those? It is good to put a kind of "catch-all" phrase in the policy as well ("so long as there is no likelihood of confusion" for example), which can catch a lot of edge cases.

GNOME trademarks

For GNOME, both the name and footprint logo are trademarked. Each is a separate registration and only applies in a certain field of use, which is software for GNOME. The project cannot prevent all uses of the term "gnome", like for garden gnomes or the band mr. Gnome, only for things in the software realm. Again, the key is not confusing consumers.

Sandler gets all kinds of requests to use the GNOME trademarks, for stickers, papers, web sites, domain names, and so on. She handles them on a case-by-case basis and tries to work with the requester to find a mutually agreeable solution. In the end, most of the people are excited about GNOME, which is why they are asking, so it's important not to dampen their enthusiasm while still protecting GNOME's mark.

One web site wanted to put the GNOME logo next to its own on the site, but the GNOME logo was huge and all the way at the top, so it dwarfed the site's logo. She suggested they make their own logo bigger, to put it above GNOME's, and to add a disclaimer that it wasn't an official site. Domain names are messy, she said, and she has not really seen a situation where it made sense for a non-official site to have GNOME as part of its domain name. Usually, once she outlines the problem, the domain owner turns it over as a gift to the foundation.

With sites and domains, the problem is whether someone new to the community will be confused when they land on the site. Once that's explained, people are generally understanding, she said. But, once in while, she does have to put "nastygrams" in the mail.

One of her favorite stories about the GNOME logo is when she heard from a contributor about a company that had modified the logo and was using it on their mobile pedicure-by-fish (having small fish eat dead skin from the feet) van. The main part of the footprint was replaced by a fish (seen at right with the GNOME logo from Sandler's slides [PDF]) The logo itself has a free copyright license, so it is not a copyright violation to use it, and it is clearly outside of the software world. It is exactly the kind of use that should be (and was) allowed. No one will be confused that GNOME has suddenly veered off into the fish-pedicure world.

Companies often say that they are "forced" to defend their trademark. She heard it frequently at the SFLC, but now that she is with the GNOME Foundation, she can see the problem. The law itself is fairly simple, with simple concepts, but there are some requirements to uphold. Most problems are handled fairly easily; she asks someone to stop using the mark in an inappropriate way and they do.

Another interesting situation arose from a combination of the Debian and GNOME logos (seen at right). It is a "really cool" logo, she said, but is a violation of the GNOME trademark policy. The problem is that it's difficult for those who are unfamiliar with the communities to parse out what it means. If you do know the communities, it's completely clear what it means, but that's not the problem. There is also a question as to whether it reduces the brand for both Debian and GNOME by combining things that way. So far, that situation has not been resolved, she said.

Key factors

There are some key factors that are usually considered when deciding whether a trademark is being violated. The Debian GNOME logo is complicated under those factors, while the fish pedicure logo is bit more obvious. The first factor is the similarity of the marks, which is clear in the fish pedicure example, but less so for Debian GNOME. The markets for Debian and GNOME are quite similar at some level, while fish pedicure clearly isn't, which is another factor to consider. Like the "similarity" test, there is another for "overall impression", which for both of these cases it is fairly clear that the overall impression is similar to the GNOME logo.

Another factor that can be considered is whether there has been actual confusion for consumers or in the market because of the possibly infringing use. One can ask if there is evidence of real confusion. For trademarks, there is also a notion akin to the "fair use" of a copyright: nominative use, that is using the mark to identify a product. For example, it is perfectly reasonable to take a photo of an Apple laptop, which shows the Apple logo, and post it on web page to sell the laptop. You can also use the name "Apple" in the text of your ad. Those are nominative uses.

Trademarks are not "just some legal detail" to avoid or ignore, even though that's an attitude she finds in the community—and sometimes in herself. Dealing with trademarks is an opportunity to recognize issues with the brand of your project, and to clearly delineate the values that your project holds. The Debian GNOME logo question is a perfect example of that; the projects generally hold similar values, but neither wants to lose its brand identity. In general, free software projects will want it to be permissible and easy to use our software and brands, but we have to be careful that some bad actor doesn't misrepresent our projects.

Community non-profits should band together to work on these kinds of problems, she said. There should be more cross-communication between projects. One area for collaboration might be an organization to hold trademarks for projects, especially those that are newly formed.

In answer to a question from the audience earlier in the talk, Sandler said that she thinks it's important to register trademarks early on in a project's life. But, it is also important that those marks be held by a neutral organization of some kind, as we have seen project disputes because one party holds the trademark (often the founder) and wants to use it in ways that other project members find objectionable. An organization that held the mark and helped form and enforce policies on those marks could be beneficial.

Comments (9 posted)

Bug reports: information or spam?

The Debian project recently debated the inherent trade-offs between making a bug reporting tool easy to use and turning it into a firehose that puts out more volume than the developers and maintainers can process. The impetus this time was false-positives caught by the Debian bug tracking system's (BTS) spam filter, but it is a question that the distribution — and indeed most distributions — grapple with regularly.

Why we foo

Michael Welle raised the issue on the Debian-devel mailing list, reporting that he had attempted to file a bug and was surprised when the BTS rejected his report because it contained a blacklisted URL. The surprise was that describing the bug in question required him to use a URL, and he had chosen what he thought was a general-purpose example: www.foo.org. But evidently the foo.org domain is on the blacklist of the uribl.com filtering service, which the BTS uses to strain out incoming spam. "Interesting user experience, bug reporters will like that big time..." Welle said.

Martin Krafft and Andrey Rahmatullin quickly replied that only RFC 2606-defined example URLs should be used in bug reports, to which Welle asked whether it was unreasonable to expect users to read an RFC before reporting a bug. Rahmatullin responded that users should "try not to use suspicious URLs."

At that point, Russ Allbery said that the root of the problem "is that foo.org is a real domain, and one that appears to be owned by one of those domain parking companies that quite likely could be doing lots of grey things with the domain. A lot of those companies are at the least spammers." In all likelihood, he added, foo.org really was used for spam at some point, although he conceded that it could be a false positive, due to others, like Welle, choosing it for its placeholder meaning (ironically, "foo" is documented as a placeholder in RFC 3092).

Getting practical

To that, Welle replied that he found the reliance on a real-time blacklist managed by a third party problematic. Fernando Lemos asked whether there was really any way to fix it. "We certainly can't disable spam filters or we'll be flooded with spam." Also, he added, because the BTS returns an error message explaining what blocked the bug from being accepted, in all likelihood real users will be able to correct the problem and resubmit. Anyone who cannot decipher the message and fix it is probably "not very tech-savvy," which decreases the odds that the report would be particularly useful. "I'm not saying it's good that we miss reports like this," he concluded, "but we must put things into perspective."

Interestingly, Ben Pfaff chimed in with the suggestion that the BTS could weed out spam by inspecting the report's metadata, looking for valid package names and versions. No one replied to that comment, though; instead the focus of the discussion turned to the acceptable threshold for rejecting otherwise valid bug reports.

Welle responded by saying that he was trying to raise the URL-filtering issue from bug reporters' perspective; people who "simply want to report a bug without being interested in external blacklist and stuff." He compared the bug report rejection with a company telling customers "we don't like you, go away." Russell Coker replied:

Welle replied that he tended to "to look for role models above me, not below me. Why imitate people or companies that do a bad job? We can do better. And of course, to come back to my initial email, I doubt that using the blacklist service makes anything easier for Debian." Debian Project Leader Stefano Zacchiroli concurred with that sentiment, saying that one of the project's role models is "people who report bugs and attach patches to them," and suggesting that Welle submit a report against the lists.debian.org pseudo-package in order to continue the discussion there.

Reporting culture

Welle agreed with Zacchiroli's assessment of the situation, although as of yet he does not appear to have filed a new bug on the subject. From outside the project, Welle's concern raises two distinct issues: how to deal with false-positives in the BTS's spam-filtering system, and the user-friendliness of the BTS as a whole (particularly where error messages are concerned).

It is hard to imagine that there are more than a handful of URL patterns that are both likely to be spontaneously chosen as examples by a bug reporter and be on uribl.com or a similar service's blacklist. RFC 2606 only offers three example URLs: example.com, example.net, and example.org. Perhaps exceptions could be made, or other techniques to filter out spam (such as Pfaff's suggestions) could be incorporated.

But, while it is undeniable that the BTS does require sturdy anti-spam measures, bug 635940 from July 2011 also questions the uribl.com blacklist. In that report, Blars Blarson responded that even with the URL filter, BTS still gets several hundred spam messages every day, and that before it, the daily count was in the tens of thousands, often totaling more than a gigabyte. The blacklist works by sending an SMTP 550 error code, which indicates that the requested mailbox does not exist; this explicit rejection is supposed to winnow out repeat offenders that simply dropping the messages would not.

Many distributions struggle with making their bug submission process easier to use, but Debian has extra challenges because it is in that small minority which (1) does not offer any sort of web-based bug submission form and (2) crucially, allows bug reports to be filed via email. The preferred method of reporting a bug is the reportbug command-line utility, which collects information from the user and the OS, and dispatches its report via email. Email reports can also be filed manually, if the correct formatting is used.

The other large distributions offer web bug-reporting tools, but increasingly the standard practice requires registering an account with email verification. Ubuntu does this through Launchpad, Fedora does the same in Red Hat's Bugzilla, and openSUSE uses the same technique with Novell's Bugzilla. Those systems may attract their fair share of spam (automated or otherwise), but the BTS bug-submission email address is well-publicized, which ensures that it is in the hands of every self-respecting spammer, and has been for years. Launchpad does have an email gateway, but it requires OpenPGP; Bugzilla supports email reporting gateways, but that feature does not appear to be in use by major projects.

The goal of the reportbug tool is generate more useful reports by gathering specifics. One downside, of course, is the exposure to email spam. But, given that the proper format for email bugs is unlikely to be present in run-of-the-mill spam, one would guess that a fairly simple filter might weed out the vast majority of spam sent to the bug-reporting address.

As Pedro Larroy pointed out in May 2011, however, the absolute dependence on SMTP can also be a problem, given that users may find themselves on a network that filters out SMTP (or on a private network with no access to the outside world). Larroy suggested that Debian add an HTTP transport mechanism for reportbug to fall back on; there was general agreement on the value of such a fallback, but many (including Ian Jackson) also argued that HTTP was a slippery slope, and that if such a gateway to the BTS was built, someone would (perhaps with the best of intentions) write a web-submission-form easily exploited by spammers and other attackers.

Of course, the uncomfortable truth is that Debian, like most large projects, knows that making bug reports harder to file reduces the number of reports, which reduces the time burden shouldered by developers, package maintainers, and bug triagers. Josselin Mouette said as much in the 2011 discussion, observing:

Not everyone agreed; Patrick Strasser argued that "artificially throttling" reports is bad, and that user education needs to be integral to the reporting process. But Allbery countered that no one has the time to engage in user education, and consequently, making reporting less convenient "doesn't *fix* the problem, but it does weed out a lot of users who don't know how to file good bug reports (and some users who do, which is indeed a drawback)."

Ultimately, a collaborative project is going to include people with differing views on whether bug reports "serve" the users (by improving the software) or "serve" the developers (by providing information). MBA programs might classify this as a question over who is the customer and who is the supplier — the customer being the party whose needs are ultimately more important. Debian has veered into that debate before, as in the "What bugs reports are for" thread from March 2011, when Jesús Navarro cautiously suggested to Jackson that point four of the Debian Social Contract establishes users as the first priority. No one in the project seems to disagree about that principle — the thorny problem is that maintaining a balance between the ease of bug reporting and the demands placed on developers requires constant attention and adjustment.

Comments (19 posted)

LFCS 2012: The kernel panel

On the first day of this year's Linux Foundation Collaboration Summit, several kernel developers sat down with moderator Greg Kroah-Hartman for another edition of the kernel panel. The developers covered a wide range of kernel subsystems, from graphics and memory management, to storage and networking. As is usual, a lively discussion ensued, covering a number of topical and longtime kernel concerns.

Audience questions for the panel are eagerly sought, Kroah-Hartman said, noting that a similar panel at LinuxCon Japan had turned into an entertaining argument between the kernel hackers onstage and those in the audience. He then had the panel introduce themselves.

Mel Gorman said that he works for SUSE Labs on memory management along with fixing bugs in various SLES and openSUSE kernels. John Linville of Red Hat is the maintainer for the wireless LAN subsystem, which is, he said, not about writing "cool code" unfortunately, but is more of an administrative role shepherding others' patches and features. James Bottomley is the CTO for server virtualization at Parallels as well as maintaining the SCSI subsystem for the kernel. In addition, he "mucks about at the edges" trying to make kernel development better, which is often as much a social problem as anything else, he said. Keith Packard works for the Intel Open Source Technology Center on graphics and window systems, as well as doing kernel DRM (direct rendering manager) work.

Summit report

Kroah-Hartman then queried Bottomley and Gorman about what went on at the recently completed Linux Storage, Filesystem, and Memory Management Summit (LWN coverage: day one and day two). Bottomley rattled off a few different topics that came up in the storage and filesystems tracks including new "weird and wild" SCSI commands that are coming down the pipe. He joked that it was necessary to keep Christoph Hellwig gagged while that talk was going on so that everyone could actually hear about the commands. The summit is becoming one of the more important kernel development meetings, he said, and it is one that, unlike some kernel summits, actually has arguments; it's "definitely not boring".

Gorman also mentioned a number of different topics that were discussed in the memory management track including the two NUMA migration schemes that are currently floating around (Peter Zijlstra's sched/numa and Andrea Arcangeli's AutoNUMA), as well as containers and control groups. He said that kernel hackers are now concerned about how quickly the containers and control groups code runs, rather than whether it will run, which was the concern in the past. The discussions were "quite civil" at the summit, which contrasts with how they sometimes go on the mailing list. The meetings were definitely a success, he said, as even if a decision went against a developer's idea or plan, they got a good idea of why the others objected to it.

Wireless and graphics

Things are clearly getting much better in the wireless area, Kroah-Hartman noted; it "used to be a nightmare", but, he asked Linville, is it a solved problem now? Wireless in Linux has matured quite a bit over the last few years, Linville said, and there are a number of companies that are now participants in developing free Linux drivers, including Broadcom and Qualcomm/Atheros. It really helps to have people available "who know how the hardware works", he said.

But, wireless technology continues to evolve with things like 802.11ac coming along (Linville called it "[802.]11n on steroids") that require support and drivers for Linux. Bottomley asked about 802.11n compliance, which Linville said is going well, though there are still "things to be ironed out". The code is in place and drivers are using it, but there is still some development to be done. All of that is helped by better support from the bigger players, but some of the second-tier wireless hardware providers are working on free kernel drivers as well.

Moving on to Packard and graphics, Kroah-Hartman asked about X and mobile phones. In the past, phones shipped using X, but that really is no longer the case, he said, and wondered why. Packard said that the last six years had been spent "radically restructuring" graphics on Linux. The idea was to have kernel drivers that could support more window systems, beyond just X, because X is "not what people want anymore", he said. Today, most are interested in compositing-based models.

Compositing is a totally different windowing system model, he said, which is simpler. After all the work that was done, the existing kernel DRM layer is capable of supporting all of the different options, including Wayland, Android, and X. Android usually uses different drivers, but the idea is similar. We are, Packard said, moving away from X as the fundamental graphics layer for Linux, instead the Linux kernel now serves that purpose.

From the audience, Bdale Garbee asked Linville about the state of Broadcom drivers, noting that performance and stability of those drivers on laptops recently was "not so great". Linville said that he assumes it will get better, that the Broadcom drivers have not been in the kernel that long, and that those drivers getting exposure in distributions should help. That will lead to more bug reports, which will be beneficial. The Broadcom developers have been working well with Linville and are being diligent about looking at bug reports and fixing the problems reported there.

There is always going to be a certain amount of lag, Linville said, because some distributions are faster or slower about updating to the latest kernel. But, it is the "same old story", he said, if you find bugs, report them, and respond to the questions that are asked.

That led to a discussion of the stable kernel tree, with Bottomley noting that some distributions are more attuned to stable than others. Kroah-Hartman said that he tries to do a stable release each week, but that it is rare for Broadcom bug fixes to be sent to the stable tree. Linville said that he should remind developers to CC stable on the bug fix patches, but that there is a somewhat tricky balance there, which requires judgment calls on which fixes are appropriate.

Gorman said that it is common in memory management development to get "slapped" if thing aren't marked for stable that should be. But, he said, each subsystem deals with things differently. Bottomley said that nobody likes getting the email reminding them to send fixes to the stable maintainers but that it is important to get those patches into the stable trees.

Pet peeves

Next up was a question for all about their "pet peeves" in Linux kernel development. We often see the same problems over and over, Kroah-Hartman said, which ones are particularly irksome? Packard said that his biggest pet peeve was outside the graphics area. He uses Bluetooth a lot and is annoyed that every time an -rc1 kernel is released, Bluetooth breaks. It is good, in some ways, he guesses, because now he can debug and bisect Bluetooth problems in the kernel. But the basic problem seems to be that it is common for Bluetooth kernel development to break all of user space. Every time he has ever suggested that for graphics work, he got "flamed to a crisp". If your patch breaks the user-space interface, he said, please don't bother submitting the patch.

Bottomley is unhappy with changelogs that don't say why the change is being made. Changelogs often say what is being done, but they don't say what the user-visible effects are. Well-written changelogs should not describe the change itself, he said, because that's what the C code is for. "Almost all kernel developers can read C", he said, to a hearty laugh from the audience. When Linville suggested that he didn't really have a pet peeve, Bottomley immediately asked if he would be willing to swap subsystems with him.

On further reflection, Linville echoed some of Bottomley's complaints, noting that it is sometimes difficult to determine where a particular patch should be sent. Because the changelogs don't clearly indicate whether the patch is a fix or a new feature, he is left guessing whether it belongs in the next tree, or needs to applied more urgently. It is particularly problematic during a merge window, he said, so the changelogs need to say where the patch is bound.

Since he doesn't "have to maintain anything", Gorman is in a different position. He joked that he gets to "rag on maintainers and make their life miserable". More seriously, he pointed to mistakes that are made again and again as a pet peeve of his. He mentioned writeback causing long delays when writing to USB sticks as an example. That has been fixed "at least eight times", he said, only to be broken again in the next release. We need to do a better job checking to see that those kinds of bugs stay fixed, he said.

More audience participation

A member of the audience asked about the future of proprietary loadable kernel modules, and Kroah-Hartman immediately said that he really didn't see a future for them. The kernel developers have provided ways to operate hardware from user space that can be used for proprietary drivers. As an example, he pointed to "laser welding robots" that are driven from user space with a 3D application that uses lots of floating point math.

If companies look at the business case, Bottomley said, it is rare that closed drivers make sense. If a company produces standard hardware that lots of people will require a driver for, there is no real business value in a closed driver. For more specialized devices, user-space drivers may make sense, he said.

Structured logging was the topic of another audience question. The idea has been around since at least 2004, the audience member said, and some solutions have started to appear. The problem is that users are now supporting larger numbers of systems and "cannot manage a datacenter by hand". Where is structured logging in the kernel headed?

Kroah-Hartman mentioned that a patch had just been merged that builds atop dev_printk() and brings some structure to logging. There have been recent proposals, including one at last year's kernel summit that got derailed by a "spat over UUIDs", Bottomley said. Packard said that there is a fear of top-down proposals for structured logging, especially if driver writers have to specify their messages ahead of time. Some proposals remind him of the VMS error message documentation that came in a large binder. What's needed is a way for driver writers and others to get the benefits of structured logging without all the problems, he said.

SCSI and bufferbloat

The new SCSI commands that Bottomley mentioned at the start formed the basis of the next question. Kroah-Hartman noted that there are more high-speed storage devices these days that are avoiding SCSI because they can't get the I/O operations/second (IOPS) rates that they need, so, he asked, is SCSI dead for high speed? Bottomley said that it is really two different questions. There is a need for storage that acts like memory, and some of these efforts are intermediate steps that are being taken when "what we really need is more memory".

As far as whether SCSI will survive, Bottomley was willing to bet that it would be around for quite some time. There is a need for standards-based storage devices so that users can purchase storage at Fry's or other stores and know that they will work with their systems. Whether it will be SATA, SAS, SCSI, or something else is not clear, but he believes that SCSI will be in the mix.

Throughput used to be an important measure for storage, but that is moving to IOPS. SCSI used to sacrifice latency for throughput, but the reverse is happening because of the focus on IOPS. Linville spoke up at that point to note the parallels with bufferbloat in the networking world. Latency was de-emphasized in networking devices for throughput and then people started wondering why their interactivity had gone down.

That led to a question to Linville about bufferbloat and the patches that had recently gone into the kernel to try to address some of those problems. It is a "complicated topic", Linville said, and wireless is part of the problem, though it is seen on both wired and wireless networks. Some of the problems are inherent in wireless technologies because the available bandwidth changes over short periods of time, which can lead to high latency. There are also problems with wireless that aren't bufferbloat-related but sometimes look like bufferbloat.

Unfortunately, no "magic solution" has presented itself to fix the general bufferbloat problem. There needs to be an adaptive queue management algorithm, but none is known that solves the problem. Something that works well for wired networks is "random early discard" (RED), but that requires lots of tuning. A recent change to measure queues in bytes, rather than packets, helps, because queue length limits are set by the aggregate size of the packets being sent. But there are still questions of what the length of the byte queues should be, whether they should change, and, if so, how often. The problem is not specific to Linux, and there are some political issues surrounding it because not everyone believes it is a problem—or that it is their problem.

A grab bag of questions and answers

As the panel time slot wound down, there were a number of other audience questions and kernel hacker discussions. An audience question about participation by Linux developers in standards committees noted that it takes money and some amount of insanity to participate in those. Kroah-Hartman pointed out that the Linux Foundation has worked on standards participation in the past, while Bottomley asked why there was a perception that Linux developers and companies are not involved. He noted that in the storage area there is a "tireless Dane" (Martin Petersen) who works on standards. It isn't the money or doing what's needed to get on the committees that is the problem, Bottomley said, but instead it is finding the right people to do so. The T10, T13, and UEFI committees all have Linux representatives, he said. If there are standards committees where Linux is not represented, we want to know about that, Kroah-Hartman said.

Grant Likely asked about the progress of the Android patches into the mainline; when is that job "done"? Once Android is using mainline kernels was the answer Bottomley gave. Kroah-Hartman noted that the real problem is on the user-space side. Kernel hackers can't do anything about changing the Android user space, but companies like Linaro and Samsung are making some progress in doing so. The 3.3 kernel can boot an Android user space, but it will "eat your battery alive", he said. We are making progress, but it will require teamwork to get there.

What are kernel hackers doing to measure power consumption was the next audience question. Packard said that there is a lot of focus on that in the graphics arena. They are using wall power meters to measure the power consumption of various devices over time and trying to correlate those measurements with active functional units in graphics devices and system-on-chips (SoCs). They measure things like joules-per-movie, which is a critical measure for users. There is an effort to balance the "race to idle" with voltage and frequency scaling, he said, especially for latency-sensitive applications like displaying movies. In addition to just the graphics hardware, they are trying to measure memory power utilization and bus power utilization, he said.

The problem is bigger than graphics, Bottomley said. In the storage world, the speed of the buses has been "jacked up", which increases the power usage. On a netbook SATA link, a half-watt of power can be used just to power the bus. Power saving for SATA buses is coming, he said.

The last topic covered was that of "hardware bypass", which are devices that take on some of the tasks that are normally handled by the kernel in the interests of performance. Gorman pointed out that bypass is often done to drive some "artificial metric" and that kernel developers need to know what the metric is in order to make proper decisions. The question for those proposing bypass should be "Why are you trying to do that?", he said. The problem is not just for SCSI (or storage), but for all of the various bypass (or offload) proposals.

The CPU isolation feature, which allows an administrator to remove a CPU from those managed by the kernel to run a particular workload unperturbed by the rest of the system, is one that Gorman mentioned. One of the reasons that people give for wanting the feature is to avoid the inter-processor interrupt (IPI) "storms" that can occur. But a better way to approach that problem is to figure out why those storms are happening and to address that instead, he said. That's "ultimately the right thing to do" whenever bypass is suggested.

Linville noted that TCP offload engines provided a boost for some users, but that CPU improvements have "largely erased the gains" that were made. Bottomley said that the question should not be how to avoid the kernel code, but instead should be how to take advantage of the work that the kernel developers do. Essentially, the consensus was that bypass or offload technologies are not only bypassing the kernel, but are also ignoring the collective knowledge and abilities of the Linux kernel community.

Once again, the kernel panel gave a nice glimpse inside the heads of kernel developers. It provided some insight into how they approach problems, and where they think solutions generally lie. It was nice to have a mix of some "fresh blood" as well as "old hands" on the panel, which definitely led to an interesting discussion.

Comments (3 posted)

Page editor: Jonathan Corbet

Security

SELinuxDenyPtrace and security by default

The Unix process model gives each process its own address space and isolates processes from each other; one process cannot access another's memory unless the two have explicitly agreed to share it. This boundary should enable one process to keep secrets from another, but there is an exception: the walls between process can be breached with the ptrace() system call. With the goal of improving security, distributors have been making changes to make that wall harder to penetrate. But, as a discussion regarding security options in the upcoming Fedora 17 release shows, there is an ongoing tension between the goals of improving security and making a distribution that is useful to its users.

ptrace() exists primarily to facilitate debugging; it is used by debuggers like gdb to stop and start a process, set breakpoints, and to examine and change memory contents. Other useful commands, like strace, also need ptrace() to function properly. The rules for ptrace() were designed in the era of relatively isolated, multi-user systems; their primary intent is to protect users from each other. So an unprivileged user is unable to use ptrace() on a process owned by a different user. But any user can employ ptrace() freely on his or her own processes.

As Dan Walsh has noted, the effects of this policy can be surprising for contemporary users:

In other words, anybody who can run code as a given user (through an exploit, say, or via a browser plugin) can use ptrace() to examine (and change) the behavior and memory of any other process owned by that user. The potential for the compromise of personal information is clear. How to solve that problem is, perhaps, a bit less so.

Dan's answer is a Fedora feature called SELinuxDenyPtrace. As one might expect from the name, this feature uses SELinux policy to disable access to the ptrace() command for all users. When Fedora's engineering steering committee (FESCO) approved this feature for the Fedora 17 release, most of its members were apparently under the impression that the feature would be turned off by default; indeed, the feature page still says:

Given that, a number of early testers of the upcoming Fedora 17 beta release have been surprised to discover that the feature is, instead, turned on by default. As a result, commands like gdb and strace fail to work. The KDE "DrKonqi" crash reporter is also broken by this setting. Needless to say, software development on such a system is a less enjoyable task. The resulting behavior is also simply surprising; as Mark Wielaard put it when he raised the issue:

Dan responded that "if you understand what ptrace or gdb are, you probably can figure out how to turn this feature off." Others, however, have argued that a Fedora install should be useful to developers by default and that forcing developers to figure out how to toggle an SELinux setting is a step in the wrong direction. As of this writing, it appears that this argument has prevailed and that ptrace() will be enabled by default in the Fedora 17 final release.

Should that happen, though, the question is likely to return in the Fedora 18 cycle. And Fedora is not alone in this quest; Ubuntu, too, has disabled the use of ptrace() by default, though the mechanism used in this case (the Yama security module) is different. Various other attempts to restrict the capabilities of running processes exist; these include Android's "every program gets its own user ID" model, reducing the set of available system calls with seccomp, and more. There appears to be little disagreement with the idea that we are surrounded by security threats and that our systems need to become more secure as a result. Protecting a single user's processes from each other is one way (out of many) to address those threats.

On the other hand, there is disagreement over the extent to which becoming more secure should inconvenience or disrupt the work of users. A powered-down machine is quite resilient against online attacks, but users tend to complain about how long it takes to get their work done on such a system. Security developers naturally tend to see the costs of their work as small, easily borne, and more than justified by the benefits; users, for whom the costs are much more immediate, tend to disagree. The result is a lot of tension surrounding security-related decisions.

To an extent, this tension can be a good thing; it can, in the long term, motivate the development of more useful and less intrusive security technologies. But it can frustrate users, who may feel that functionality is being taken from them for no good reason; it can also frustrate security developers who find their efforts to protect those users thwarted. Unfortunately, there is often no easy answer; security is a trade-off with both costs and benefits. So, while the default setting for deny_ptrace in Fedora 17 may have been pushed in the "convenience for users" direction, we can expect the wider discussion to be with us for some time.

Comments (31 posted)

Brief items

Security quote of the week

-- Ruth Curry

Comments (36 posted)

Remote root hole in Samba

The Samba team has announced the release of versions 3.6.4, 3.5.14 and 3.4.16 containing a fix for a remote code execution vulnerability. "As this does not require an authenticated connection it is the most serious vulnerability possible in a program, and users and vendors are encouraged to patch their Samba installations immediately." Distributor updates should start showing up in the near future.

Update: the Samba 4 alpha releases are vulnerable as well; 4.0alpha19 has been released with a fix.

Full Story (comments: 70)

AT&T Microcell FAIL (FailOverflow)

The FailOverflow site has an amusing look inside an AT&T microcell box which, naturally, runs Linux. "The backdoor uses simple UDP packets to transmit requests and receive responses. There are a number of operations supported, but the most useful one is called ‘BackdoorPacketCmdLine’. Yes. It’s actually called ‘Backdoor’. This command lets you execute any linux command. Execution is performed using the backticksh function." This port turns out to be globally accessible. (Thanks to Paul Wise).

Comments (16 posted)

Wheeler: Insecure open source software libraries?

David A. Wheeler cautions against the practice of using bundled libraries. This is probably is not news to many LWN readers, but it does serve as a reminder. "An advantage of OSS is that many people can review the software, find problems (including vulnerabilities), and fix them… but this advantage is lost if the fixed versions are not used!"

Comments (116 posted)

Medical device hack attacks may kill, researchers warn (BBC News)

GNOME foundation executive director Karen Sandler makes an appearance in a BBC News article about the security risks of medical implants:

LWN has covered several talks (1, 2) that Sandler has given on this topic as well.

Comments (9 posted)

New vulnerabilities

chromium: multiple vulnerabilities

Package(s):	chromium	CVE #(s):	CVE-2011-3066 CVE-2011-3067 CVE-2011-3068 CVE-2011-3069 CVE-2011-3070 CVE-2011-3071 CVE-2011-3072 CVE-2011-3073 CVE-2011-3074 CVE-2011-3075 CVE-2011-3076 CVE-2011-3077
Created:	April 11, 2012	Updated:	October 26, 2012
Description:	Versions of the chromium browser prior to 18.0.1025.151 suffer from multiple information disclosure, code execution, and denial of service vulnerabilities.
Alerts:	Gentoo 201204-03 2012-04-10 Ubuntu USN-1524-1 2012-08-08 Ubuntu USN-1617-1 2012-10-25 Mageia MGASA-2012-0324 2012-11-06

Comments (none posted)

drupal7-ctools: cross-site scripting

Package(s):	drupal7-ctools	CVE #(s):
Created:	April 9, 2012	Updated:	April 11, 2012
Description:	From the Drupal advisory: This suite is primarily a set of APIs and tools to improve the developer experience. It also contains a module called the Page Manager whose job is to manage pages. In particular it manages panel pages, but as it grows it will be able to manage far more than just Panels. The module doesn't appropriate filter user signatures when rendering comments. This vulnerability is mitigated by the fact that an attacker must have a role with the permission "post comments" and a site must use Chaos tool suite to render comments. Versions affected: Chaos tool suite 7.x-1.x versions prior to 7.x-1.0. Drupal core is not affected.
Alerts:	Fedora FEDORA-2012-5078 2012-04-08 Fedora FEDORA-2012-5094 2012-04-08

Comments (none posted)

inspircd: code execution

Package(s):	inspircd	CVE #(s):	CVE-2012-1836
Created:	April 10, 2012	Updated:	April 11, 2012
Description:	From the CVE entry: Heap-based buffer overflow in dns.cpp in InspIRCd 2.0.5 might allow remote attackers to execute arbitrary code via a crafted DNS query that uses compression.
Alerts:	Debian DSA-2448-1 2012-04-10 Gentoo 201204-02 2012-04-10

Comments (none posted)

openstack-keystone: denial of service

Package(s):	openstack-keystone	CVE #(s):	CVE-2012-1572
Created:	April 9, 2012	Updated:	April 11, 2012
Description:	From the Red Hat bugzilla: A vulnerability in how Keystone handles extremely long passwords was discovered. When Keystone is validating a password, glibc allocated space on the stack for the entire password. If the password is long enough, stack space can be exhausted which will lead to a crash. A remote attacker could use this to cause a crash in Keystone by submitting a long password when attempting to log into an existing account; an attacker must know an existing account name to attempt the login with for this attack to be successful.
Alerts:	Fedora FEDORA-2012-4960 2012-04-08

Comments (none posted)

puppet: multiple vulnerabilities

Package(s):	puppet	CVE #(s):	CVE-2012-1906 CVE-2012-1986 CVE-2012-1987 CVE-2012-1988 CVE-2012-1989
Created:	April 11, 2012	Updated:	August 15, 2012
Description:	Puppet contains a set of vulnerabilities that can enable arbitrary file overwrite via Mac OS X package files (CVE-2012-1906), enable reading of arbitrary files (CVE-2012-1986), perform denial of service attacks (CVE-2012-1987), execute arbitrary code (CVE-2012-1988), or overwrite arbitrary files via symbolic links (CVE-2012-1989).
Alerts:	Ubuntu USN-1419-1 2012-04-11 Debian DSA-2451-1 2012-04-13 Fedora FEDORA-2012-5999 2012-04-27 Fedora FEDORA-2012-6055 2012-04-27 openSUSE openSUSE-SU-2012:0608-1 2012-05-10 openSUSE openSUSE-SU-2012:0835-1 2012-07-04 Gentoo 201208-02 2012-08-14

Comments (none posted)

python-paste-script: insecure root GID accessible files

Package(s):	python-paste-script	CVE #(s):	CVE-2012-0878
Created:	April 9, 2012	Updated:	August 28, 2012
Description:	From the Red Hat bugzilla: A security flaw was found in the way Paster, a pluggable command-line frontend, when started as root (for example to have access to privileged port) to serve a web based application, performed privileges dropping upon startup (supplementary groups were not dropped properly regardless of the UID, GID specified in the .ini configuration file or in the --user and --group CL arguments). A remote attacker could use this flaw for example to read / write root GID accessible files, if the particular web application provided remote means for local file manipulation.
Alerts:	Fedora FEDORA-2012-2418 2012-04-06 Fedora FEDORA-2012-2413 2012-04-06 Red Hat RHSA-2012:1206-01 2012-08-27 CentOS CESA-2012:1206 2012-08-27 Oracle ELSA-2012-1206 2012-08-27 Scientific Linux SL-pyth-20120827 2012-08-27

Comments (none posted)

samba: remote code execution

Package(s):	samba	CVE #(s):	CVE-2012-1182
Created:	April 11, 2012	Updated:	March 11, 2013
Description:	All versions of samba prior to 3.6.3 or 4.0alpha19 contain a vulnerability whereby an unauthenticated attacker can execute remote code as the root user. See this advisory for more information.
Alerts:	Red Hat RHSA-2012:0465-01 2012-04-10 Red Hat RHSA-2012:0466-01 2012-04-10 CentOS CESA-2012:0466 2012-04-10 CentOS CESA-2012:0465 2012-04-10 CentOS CESA-2012:0465 2012-04-10 Mandriva MDVSA-2012:055 2012-04-11 Scientific Linux SL-samb-20120411 2012-04-11 Scientific Linux SL-samb-20120411 2012-04-11 Red Hat RHSA-2012:0478-01 2012-04-13 Oracle ELSA-2012-0465 2012-04-12 Oracle ELSA-2012-0465 2012-04-12 Oracle ELSA-2012-0466 2012-04-12 Debian DSA-2450-1 2012-04-12 Ubuntu USN-1423-1 2012-04-12 Fedora FEDORA-2012-5843 2012-04-13 SUSE SUSE-SU-2012:0500-1 2012-04-14 SUSE SUSE-SU-2012:0501-1 2012-04-14 SUSE SUSE-SU-2012:0502-1 2012-04-14 SUSE SUSE-SU-2012:0504-1 2012-04-14 SUSE SUSE-SU-2012:0501-2 2012-04-14 openSUSE openSUSE-SU-2012:0507-1 2012-04-16 openSUSE openSUSE-SU-2012:0508-1 2012-04-16 SUSE SUSE-SU-2012:0515-1 2012-04-17 Oracle ELSA-2012-0478 2012-04-17 Fedora FEDORA-2012-5805 2012-04-22 Fedora FEDORA-2012-6349 2012-05-03 Fedora FEDORA-2012-6382 2012-05-15 Gentoo 201206-22 2012-06-24 Red Hat RHSA-2013:0506-02 2013-02-21 Red Hat RHSA-2013:0515-02 2013-02-21 Oracle ELSA-2013-0515 2013-02-28 Oracle ELSA-2013-0506 2013-02-28 Scientific Linux SL-samb-20130304 2013-03-04 Scientific Linux SL-open-20130304 2013-03-04 CentOS CESA-2013:0515 2013-03-09 CentOS CESA-2013:0515 2013-03-09 CentOS CESA-2013:0506 2013-03-09

Comments (none posted)

sectool: privilege escalation

Package(s):	sectool	CVE #(s):	CVE-2012-1615
Created:	April 9, 2012	Updated:	April 11, 2012
Description:	Installing sectool will grant users new permissions. See the Red Hat bugzilla for details.
Alerts:	Fedora FEDORA-2012-5432 2012-04-06

Comments (none posted)

taglib: multiple vulnerabilities

Package(s):	taglib	CVE #(s):	CVE-2012-1108 CVE-2012-1107 CVE-2012-1584
Created:	April 9, 2012	Updated:	June 25, 2012
Description:	From the Red Hat bugzilla [1], [2], [3]: 1) It was reported that, when parsing an Ogg file, a specially crafted Ogg file with control over the "vendorLength" field could cause a string allocation with that size. Control over the "commentFields", which is the number of times that "commentLength" is read, would allocate a string of size "commandLength", which could cause an application linked to taglib to crash. This has been fixed in upstream git. (CVE-2012-1108) 2) It was reported that a specially crafted ape media file with the sampleRate set to "0" could lead to an application crash due to a division by zero error. This has been fixed in upstream git. (CVE-2012-1107) 3) It was reported that taglib suffers from an integer overflow flaw when parsing file header fields. A file with a crafted header could cause a large allocation and crash the application. This has been corrected in git. (CVE-2012-1584)
Alerts:	Fedora FEDORA-2012-4291 2012-04-06 Fedora FEDORA-2012-4268 2012-04-06 openSUSE openSUSE-SU-2012:0490-1 2012-04-12 Gentoo 201206-16 2012-06-22

Comments (none posted)

tiff: code execution

Package(s):	tiff libtiff	CVE #(s):	CVE-2012-1173
Created:	April 5, 2012	Updated:	April 23, 2012
Description:	An integer overflow bug in the TIFF library is possibly exploitable (via a crafted image file) for the execution of arbitrary code.
Alerts:	Debian DSA-2447-1 2012-04-04 Mandriva MDVSA-2012:054 2012-04-05 Ubuntu USN-1416-1 2012-04-04 Red Hat RHSA-2012:0468-01 2012-04-10 CentOS CESA-2012:0468 2012-04-10 CentOS CESA-2012:0468 2012-04-10 Scientific Linux SL-libt-20120411 2012-04-11 Oracle ELSA-2012-0468 2012-04-12 Oracle ELSA-2012-0468 2012-04-12 Fedora FEDORA-2012-5406 2012-04-18 Fedora FEDORA-2012-5410 2012-04-22 Gentoo 201209-02 2012-09-23

Comments (none posted)

virtualbox: multiple unspecified vulnerabilities

Package(s):	virtualbox	CVE #(s):	CVE-2010-4414 CVE-2012-0105 CVE-2012-0111
Created:	April 10, 2012	Updated:	October 10, 2012
Description:	From the CVE entries: Unspecified vulnerability in Oracle VM VirtualBox 4.0 allows local users to affect confidentiality, integrity, and availability via unknown vectors related to Extensions. (CVE-2010-4414) Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization 4.1 allows local users to affect confidentiality, integrity, and availability via unknown vectors related to Windows Guest Additions. (CVE-2012-0105) Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization 4.1 allows local users to affect confidentiality and integrity via unknown vectors related to Shared Folders. (CVE-2012-0111)
Alerts:	Gentoo 201204-01 2012-04-09 openSUSE openSUSE-SU-2012:1323-1 2012-10-10

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel is 3.4-rc2, released on April 7. It includes a lot of fixes; Linus also decided to pull the DMA mapping rework preparatory patches. That should be the end of the significant merges for this development cycle, though: "I'm going to be stricter about pulls from here on out, there was a lot of 'noise', not just pure fixes." The short-form changelog can be found in the announcement.

Stable updates: there have been no stable updates released in the last week. The 3.0.28, 3.2.15, and 3.3.2 updates are in the review process as of this writing. Each contains a long list of fixes; the final release can be expected on or after April 13.

Comments (2 posted)

2.4 kernel releases come to an end

More than eight years after the 2.6.0 release, Willy Tarreau has announced that he will no longer be releasing updates to the 2.4 series. For those who really are unable to move on, he may maintain a git tree with an occasional fix, "but with no guarantees."

Full Story (comments: 4)

A new security subsystem wiki

The kernel security developers have stopped waiting for the kernel.org wiki system to return to service. So kernel-related security development information can now be found on kernsec.org. Restoring the kernel.org wiki content there may be an ongoing process for a little while.

Comments (1 posted)

SCHED_DEADLINE returns

Deadline scheduling has been discussed on these pages a number of times. In short: rather than using priorities, a deadline scheduler characterizes each process with a maximum CPU time required and the deadline by which it must receive that CPU time. A properly-written deadline scheduler can ensure that every process meets its deadlines while refusing to take work that would cause any deadlines to be missed. Patches adding a deadline scheduler to Linux have existed for a few years, but their progress toward the mainline has been slow; recently that progress has been very slow since the principal developer involved has moved on to other projects.

The deadline scheduler patches now have a new developer in the form of Juri Lelli; Juri has posted a new version of the patches to restart the discussion. The changes from the last time around are mostly minor: review comments addressed and an improved migration mechanism added. The plan is to continue to fill in the gaps required to make the deadline scheduler production-worthy and, eventually, to get it into the mainline. To that end, there is a new git repository, an application designed to test deadline scheduling, and a new mailing list. One assumes Juri would be most appreciative of testing and patches.

Comments (6 posted)

Kernel development news

A new approach to user namespaces

"Containers" can be thought of as a lightweight form of virtualization. Virtualized guests appear to be running on their own dedicated hardware; containers, instead, run on the host's kernel, but in an environment where they appear to have that kernel to themselves. The result is more efficient; it is typically possible to run quite a few more containerized guests than virtualized guests on a given system. The cost, from the user's point of view, is flexibility; since virtualized guests can run their own kernel, they can run any operating system while containerized guests are stuck with what the host is running.

There is another cost to containers that is not necessarily visible to users: their implementation in the kernel is, in many ways, far more complex. In a system supporting containers, any globally-visible resource must be wrapped in a namespace layer that provides each container with its own view. There are many such resources on a Linux system: process IDs, filesystems, and network interfaces, for example. Even the system name and time can differ from one container to the next. As a result, despite years of effort, Linux still lacks proper container support, while virtualization has been a solid feature for a long time.

Work continues on the Linux containers implementation; the latest piece is a new set of user namespace patches from Eric Biederman. The "user namespace" can be thought of as the encapsulation of user/group IDs and associated privilege; it allows the owner of a container to run as the root user within that container while isolating the rest of the system from the in-container users. The implementation of a proper user namespace has always been a hard problem for a number of reasons. Kernel code has been written with the understanding that a given process has one, globally-recognized user ID; what happens when processes can have multiple user IDs in different contexts? It is not hard to imagine developers making mistakes with user IDs - mistakes leading to serious security holes in the host system. Fears of this kind of mistake, along with the general difficulty of the problem, have kept a full user namespace out of the kernel so far.

Eric's patch takes a bit of a different approach to the problem in the hope of making user namespaces invisible to most kernel developers while catching errors when they are made. To that end, the patch set creates a new type to represent "kernel UIDs" - kuid_t; there is also a kgid_t type. The kernel UID is meant to describe a process's identity on the base system, regardless of any user IDs it may adopt within a container; it is the value used for most privilege checks. A process's kernel IDs may (or may not) be equal to the IDs it sees in user space; there is no way for that process to know. The kernel IDs exist solely to identify a process's credentials within the kernel itself.

In the patch, kuid_t is a typedef for a single-field structure; its main reason for existence is to be type-incompatible with the simple integer user and group IDs used throughout the kernel. Container-specific IDs, instead, retain the old integer (uid_t and gid_t) types. As a result, any attempt to mix kernel IDs with per-container IDs should yield an error from the compiler. That should eliminate a whole class of potential errors from kernel code that deals with user and group ID values.

The kuid_t type, being an opaque cookie to in-kernel users, needs a set of helper functions. Comparisons can be done with functions like uid_eq(), for example; similar functions exist for most arithmetic tests. For many purposes, that's all that is needed. Regardless of its namespace, a process's credentials are stored in the global kuid_t space, so most ID tests just do the right thing.

There are times, though, where it is necessary to convert between a kernel ID and a user or group ID as seen in a specific namespace. Perhaps the simplest example is a system call like getuid(); it should return the namespace-specific ID, not the kernel ID. There is a set of functions provided to perform these conversions:

    kuid_t make_kuid(struct user_namespace *from, uid_t uid);
    uid_t from_kuid(struct user_namespace *to, kuid_t kuid);
    uid_t from_kuid_munged(struct user_namespace *to, kuid_t kuid);
    bool kuid_has_mapping(struct user_namespace *ns, kuid_t uid);

(A similar set of functions exists for group IDs, of course.) Conversion between a kernel ID and the namespace-specific equivalent requires the use of a mapping stored within the namespace, so the namespace of interest must be supplied when calling these functions. For code that is executing in process context, a call to current_user_ns() is sufficient to get that namespace pointer. make_kuid() will turn a namespace-specific UID into a kernel ID, while from_kuid() maps a kernel ID into a specific namespace. If no mapping exists for the given kernel ID, from_kuid() will return -1; for cases where a valid ID must be returned, a call to from_kuid_munged() will return a special "unknown user" value instead. To simply test whether it is possible to map a specific kernel ID into a namespace, kuid_has_mapping() is available.

Actually setting up the mapping is a task that must be performed by the administrator, who will likely set aside a range of IDs for use within a specific container. The patch series adds a couple of files under /proc/pid/ for this purpose; setting up the mapping is just a matter of writing one or more tuples of three numbers to /proc/pid/uid_map:

	first-ns-id  first-target-id  count

The first-ns-id is the first valid user ID in the given process's namespace. It is likely to be zero - the root ID is valid and harmless within user namespaces. That first ID will be mapped to first-target-id as it is defined in the parent namespace, and count is the number of consecutive IDs that exist in the mapping. If multiple levels of namespaces are involved, there may be multiple layers of mapping, but those layers are flattened by the mapping code, which only remembers the mapping directly to and from kernel IDs.

Establishing mappings clearly needs to be a privileged operation, so the process performing this operation must have the CAP_SETUID capability available. A process running as root within its own namespace may well have that capability, even though it has no access outside of its namespace. So processes in a user namespace can set up their own sub-namespaces with arbitrary mappings - but those mappings can only access user and group IDs that exist in the parent namespace. As an additional restriction, the namespace ID mapping can only be set once; after it has been established for a given namespace, it is immutable thereafter.

These mapping functions find their uses in a number of places in the core kernel. Any system call that deals in user or group ID numbers must include the conversions to and from the kernel ID space. The ext* family of filesystems allows the specification of a UID that can use reserved blocks, so the filesystem code must make sure it's working with kernel IDs when it does its comparisons. So the patch is, like much of the namespace work, mildly intrusive, but Eric has clearly worked to minimize its impact. In particular, he has taken care to ensure that the runtime overhead of the ID-mapping code is zero if user namespaces are not configured into the kernel, and as close as possible to zero when the feature is used.

The user namespace feature, he says, now has a number of nice features to offer:

As of this writing, there have been few comments from reviewers, so it is not yet clear whether other developers agree with this assessment or not. The nature of the namespace work means that it can be difficult to get it accepted into the mainline, where developers tend to be concerned about the overhead and relatively uninterested in the benefits. But, with years of persistence, much of this work has gotten in anyway; chances are that user namespaces, in some form, will eventually find their way in as well.

Comments (5 posted)

Finding the right evolutionary niche

It has been observed that "Linux is evolution, not intelligent design". Evolution may seem to be an effective way to allow many developers to work in parallel to produce a coherent whole, but it does not necessarily produce a well structured elegant orthogonal design. While the developers do try to limit the more overt duplication of functionality there are often cases where functionality overlaps, as the ongoing reflections on RAID unification bear witness.

A different perspective on the challenges associated with this tendency to concurrent evolution can be seen if we examine the "timed gpio" piece of the various attempts to bring Android closer to mainline. The Android developers appear to have made a deliberate decision to add functionality as completely separate drivers rather than modifying existing drivers. This undoubtedly makes it easier for them to forward-port to newer versions of the kernel, and also provides the setting for a simple case study when the attempt is made to merge the functionality upstream.

The "timed gpio" driver is really more than just a driver. Firstly it includes a new "device class" named "timed output" which can drive an arbitrary output for a set period of time (in milliseconds). Secondly it includes a driver for this class which drives a given GPIO (General Purpose Input/Output) line according to the rules for the class. So we should really be thinking of "timed output" as the required functionality. The primary purpose for this functionality is apparently to control a vibrator, as used in mobile phones to alert the owner to conditions such as an incoming call. On the hardware side, the vibrator is connected to some GPIO line, and can be turned on or off by asserting or de-asserting that line.

The first query that would be raised about such a possible submission (after checking for white-space errors of course) is whether the Linux kernel really needs another device class, or whether some existing device class can be enhanced to meet the need. This is notably a different attitude to the traditional Unix "tools" approach where the preferred first step is to combine existing tools to achieve a goal, and only merge the functionality into those tools when it has been proved. With Linux driver classes there is no general mechanism for combining existing drivers - there is no equivalent of the "pipe" or the standard data format of "new-line separated lines of text" to aid in combining things. So the only way to avoid continually reinventing from scratch is to incrementally enhance existing functionality.

When casting around for existing device classes the first possibility is clearly the "gpio" class. This allows direct control of GPIO lines and can (when the device is suitably configured) drive lines as outputs, sample them as inputs, and even detect level changes using poll(). A simple solution for a vibrator would be to use "gpio" as it is, and leave the timing up to user space. That is, some daemon could provide a service to start the vibrator and then stop it shortly afterward.

One problem with this approach is that it is not fail-safe. User-space programs are generally seen as less reliable than the kernel. The daemon could be killed while the vibrator is left on and it would then stay on, wasting quite a lot of battery capacity and irritating the user. How much this is a serious issue is unclear, but it does seem to have been important enough to the Android engineers to justify writing a new driver so it should not be quickly dismissed.

Adding a timer function to the "gpio" class might be possible, though is probably a bad choice. Timing is not intrinsic to the concept of GPIOs and, if it were allowed into the class, it would be difficult to justify not letting all sorts of other arbitrary features in. So it seems best to keep it out, and in any case there is another class which already supplies a very similar concept.

The "leds" class already performs a variety of timed output functions. It is intended for driving LEDs and can set them or "on" or "off" or, where supported, a range of brightness values in between. "leds" has a rich "trigger" mechanism so that an LED can be made to flash depending on the state of various network ports, the activity of different storage devices, or the charge status of different power supplies. They can also be triggered using a timer. This class already can drive a GPIO on the assumption that it applies power to an LED, and could easily be used to apply power to a vibrator as well (maybe we would have to acknowledge that it was a Lively Energetic Device to get past the naming police).

There is a precedent for this, as the original Openmoko phones - the Neo and the Freerunner - use a "leds" driver to control the vibrator, as does the Nokia N900. Unfortunately the "leds" class doesn't actually meet the need, as it is not possible to start the timer without passing through a state where a user-space crash would leave the vibrator running endlessly. When the "timer" trigger is enabled it starts with default values of 500ms for "on" and 500ms for "off" which can then be adjusted. If the application fails before resetting the "off" time, the vibrator will come back on shortly. So for the purposes of failing safe it is no better than the "gpio" class.

In the hope of addressing this - which could be seen as a design bug in the "leds" class - Shuah Khan recently posted a patch to add a "timer-no-default" trigger and also to allow the "off" time to be set to "forever". This would enable using the "leds" timer mechanism to drive a vibrator with no risk of it staying on indefinitely.

Out of the discussion on the linux-kernel list arose the observation - not mentioned before in the discussions on mainlining Android - that there is another class that can be and is being used to drive vibrators. This is, somewhat surprisingly, the "input" subsystem.

Choosing a name for a subsystem that will not go out-of-date is a recurring problem, which can be seen in, for example, the "scsi" subsystem of Linux; that subsystem now also drives SATA disks and USB attached storage. Similarly the "input" subsystem is also used for some outputs such as the LEDs on a keyboard (those that light "caps lock" or "num lock"), the speaker in the PC platform that is used for "beeping", and, more recently, for the force-feedback functionality of some joysticks and other game controllers. As Dmitry Torokhov (current maintainer of the "input" class) suggests, it is better to think of it as an "hid" (Human Interface Device) class which happens to be named "input".

The force feedback framework in the input class provides for a range of physical or "haptic" signals to be sent back to the user of the device, one of which is the "rumble" which is really another name for a vibration. This effect can be triggered in various ways and importantly can be set to be activated for a fixed period of time. That is, it can operate in a fail-safe mode. So it seems that a device class suitable for vibrators already exists. It isn't able to drive simple GPIO lines yet, however that is unlikely to be far away. Dmitry has already posted a patch to create a rumble-capable input device from PWM (pulse width modulation) hardware, and doing the same for a GPIO is a very small step.

It is interesting that, though this question has been raised at various times in various forums over the last year or so, this seems to be the first time that using an input device with a rumble effect has been suggested in the same context. It highlights the fact that there is so much functionality in Linux that nobody really knows about all of it, and finding the bit that meets a particular need is not always straightforward. It also highlights the observation, which has been made many times before, that sometimes the best way to get a useful response is to post a credible patch. People seem to be more keen to take a patch seriously than to enter into a less-focused discussion.

Whether the Android team will come on board with the rumble effect and drop their timed gpio patch is not yet known. What is known is that finding the right niche for new functionality does require persistence.

Comments (2 posted)

LTTng 2.0: Tracing for power users and developers - part 1

The recently released Linux Trace Toolkit next generation (LTTng) 2.0 tracer is the result of a two-year development cycle involving a team of dedicated developers. Unlike its predecessor, LTTng 0.x, it can be installed on a vanilla or distribution kernel without any patches. It also performs combined tracing of both the kernel and user space, and has many more features that will be detailed in this article and its successor.

Why LTTng 2.0?

The main motivation behind LTTng 2.0 is that we identified a strong demand for user-space tracing, and we noticed that targeting a user base broader than developers required a lot of work focusing on usability. Moving forward toward these goals led us to the unification of the tracer control and user interface (UI) for both kernel and user-space tracing.

Some might wonder why we did not go down the Perf or Ftrace path for our development. Perf does not meet our performance needs, and is in many ways designed specifically for the Linux kernel (e.g. the trace format is kernel-specific). As for Ftrace, its performance is similar to that of LTTng, but its main focus is on simplicity for kernel debugging use-cases, which means a single user, single tracing session, and single set of buffers. It also has a trace format specifically tuned for the Linux kernel, which does not meet our requirements.

LTTng 2.0 features

LTTng 2.0 is pretty much a rewrite of the older 0.x LTTng versions, but now focusing on usability and end-user experience. It builds on the solid foundations of LTTng 0.x for data transport, uses the existing Linux kernel instrumentation mechanisms, and makes the flexible CTF (Common Trace Format) available to end users. For example, that allows prepending arbitrary performance monitoring unit (PMU) counter values to each traced event.

LTTng provides an integrated interface for both kernel and user-space tracing. A "tracing" group allows non-root users to control tracing and read the generated traces. It is multi-user aware, and allows multiple concurrent tracing sessions.

LTTng allows access to tracepoints, function tracing, CPU PMU counters, kprobes, and kretprobes. It provides the ability to attach "context" information to events in the trace (e.g. any PMU counter, process and thread ID, container-aware virtual PIDs and TIDs, process name, etc). All the extra information fields to be collected with events are optional, specified on a per-tracing-session basis (except for timestamp and event id, which are mandatory). It works on mainline kernels (2.6.38 or higher) without any patches.

The Common Trace Format specification has been designed in collaboration with various industry participants to suit the tracing tool interoperability needs of the embedded, telecommunications, high-performance, and Linux kernel communities. It is designed to allow traces to be natively generated by the Linux kernel, Linux user-space applications written in C/C++, and hardware components. One major element of CTF is the Trace Stream Description Language (TSDL) which flexibly enables description of various binary trace stream layouts. It supports reading and writing traces on architectures with different endian-ness and type sizes, including bare metal generating trace data that is addressed in a bitwise manner. The trace data is represented in a native binary format for increased tracing speed and compactness, but can be read and analyzed on any other machine that supports the Babeltrace data converter.

In addition to specifying the disk data storage format, CTF is designed to be streamed over the network through TCP or UDP, or sent through a serial interface. The storage format allows discarding the oldest pieces of information when keeping flight-recorder buffers in memory to support snapshot use cases. The flexible layout also enables features such as attaching additional context information to each event, and the layout acts as an index that allows fast seeking through very large traces (many GB).

LTTng is a high-performance tracer that produces very compact trace data, with low overhead on the traced system. A somewhat dense overview of the LTTng 2.0 architecture can be seen at right, click through for a larger view.

Tracer strengths overview

The diversity of tracing tools available in Linux today can baffle users trying to pick which one to use. Each has been developed with different use cases in mind, which makes the motto "use the right tool for the job" very appropriate. In this section, we present the strengths of the major Linux kernel tracing tools. Please keep in mind that the authors tried to keep an objective perspective when writing this section, which is based on information received during the past years' conferences.

LTTng 2.0

The targeted LTTng audience includes anyone responsible for production systems, system administrators, and application developers. LTTng focuses on providing a system-wide view (across software stack layers) with detailed combined application and system-level execution traces, without adding too much overhead to the traced system.

One downside of LTTng 2.0 is that it is not provided by the upstream kernel: it requires that either the distribution, or the end user, install separate packages. LTTng 2.0 is also not geared toward kernel development: it currently does not support integration with kernel crash dump tools, nor does it support kernel early boot tracing.

LTTng is best suited to finding performance slowdowns or latency issues (e.g. long delays) in production or while doing development when the cause is either unknown or comes from the interaction between various software/hardware components. It can also be used to monitor production systems and desktops (in flight recorder mode) and trigger an execution trace snapshot when an error occurs, which provides detailed reports to system administrators and developers. (Note: flight recorder support was available in LTTng 0.x, but is not fully supported by the LTTng 2.0 tracing session daemon. Stay tuned for the 2.1 release currently in preparation.)

Perf

Perf is very good at sampling hardware and software counters. The key feature around which it has been designed is per-process performance counter sampling for the kernel and user space. It targets both user space and kernel developer audiences. Perf is multi-user aware, although it allows tracing from non-root users for per-process information only.

Perf's event header is fixed, with extensible payload definitions. Therefore, although new events can be added, the content of its event header is fixed by its ABI. Its tracing infrastructure resides at kernel-level only. That means tracing user space requires round-trips to the kernel, which causes a performance hit. Tracing features have been added using the same infrastructure developed for sampling.

In development environments, Perf is useful as a hardware performance counter and kernel-level software event sampler for a process (or group of processes). It can give insight into the major bottlenecks slowing down process execution, when the cause of the slowdown can be pinpointed to a particular set of processes.

Ftrace

Ftrace has been designed with function tracing as primary purpose; it also supports tracepoint instrumentation and dynamic probing. It has efficient mechanisms to quickly collect data and to filter out information that is not interesting to the user. Ftrace targets a kernel developer audience, including console output integration that allows dumping tracing buffers upon a kernel crash. Its event headers are fixed by the ABI, with extensible event payload definitions. Its ring buffer is heavily optimized for performance, but it allows only a single user to trace at any given time. Its tracing infrastructure resides at kernel-level only. Therefore, similar to Perf, tracing user space requires a round-trip to the kernel, which causes a performance hit.

In development environments, Ftrace is suited for kernel developers who want to debug bugs and latency issues occurring at kernel-level. One of the major Ftrace strengths over Perf is its low overhead. It is therefore well-suited for tracing high-throughput data coming from frequently hit tracepoints or from function entry/exit instrumentation on busy systems.

LTTng 2.0 usage examples

LTTng 2.0 can be installed on a recent Linux distribution without requiring any kernel changes. The individual package README files contain the installation instructions and dependencies. When using lttng for kernel tracing from the tracing group, the lttng-sessiond daemon needs to be started as root beforehand. This is usually performed by init scripts for Linux distributions.

The user interface entry point to LTTng 2.0 is the lttng command. The same actions can also be performed programmatically through the lttng.h API and the liblttng library.

1. Kernel activity overview with tracepoints

Tracing the kernel activity can be done by enabling all tracepoints and then starting a trace session. This sequence of commands will show a human-readable text log of the system activity (run as root or a user in the tracing group):

    # lttng create
    # lttng enable-event --kernel --all
    # lttng start
    # sleep 10	      # let the system generate some activity
    # lttng stop
    # lttng view
    # lttng destroy

Here is an example of the event text output (with annotation), generated by using:

    # lttng view -e "babeltrace -n all"

to show all field names:

    timestamp = 18:27:42.301503743,	# Event timestamp
    delta = +0.000001871,		# Timestamp delta from previous event
    name = sys_recvfrom,		# Event name
    stream.packet.context = {		# Stream-specific context information
	cpu_id = 3	      		# CPU which has written this event
    },
    event.fields = {			# Event payload
	fd = 4,
	ubuf = 0x7F9C100AD074,
	size = 4096,
	flags = 0,
	addr = 0x0,
	addr_len = 0x0
    }

To get the list of available tracepoints:

    # lttng list --kernel

Specific tracepoints can be traced with:

    # lttng enable-event --kernel irq_handler_entry,irq_handler_exit
    # this can be followed by more "lttng enable-event" commands.

2. Dynamic Probes

This second example shows how to plant a dynamic probe (kprobe) in the kernel and gather information from the probe:

    # lttng create
    # lttng enable-event --kernel sys_open --probe sys_open+0x0
    # lttng enable-event --kernel sys_close --probe sys_close+0x0
    	    	      # run "lttng enable-event" for more details
    # lttng start
    # sleep 10        # let the system generate some activity
    # lttng stop
    # lttng view
    # lttng destroy

Example event generated:

    timetamp = 18:32:53.198603728,	# Event timestamp
    delta = +0.000013485,		# Timestamp delta from previous event
    name = sys_open,			# event name
    stream.packet.context = {		# Stream-specific context information
	cpu_id = 1			# CPU which has written this event
    },
    event.fields = {
	ip = 0xFFFFFFFF810F2185		# Instruction pointer where probe was planted
    }

All instrumentation sources can be combined and collected within a trace session.

To be continued ...

LTTng 2.0 (code named "Annedd'ale") was released on March 20, 2012. It will be available as a package in Ubuntu 12.04 LTS, and should be available shortly for other distributions.

Only text output is currently available by using the Babeltrace converter. LTTngTop (which will be covered in part 2) is usable, although it is still under development. The graphical viewer LTTV and the Eclipse LTTng plugin are currently being migrated to LTTng 2.0. Both LTTngTop and LTTV will re-use the Babeltrace trace reading library, while the Eclipse LTTng plugin implements a CTF reading library in Java.

Part 2 of this article, will feature more usage examples including combined user space and kernel tracing, adding PMU counter contexts along with kernel tracing, a presentation of the new LTTngTop tool, and a discussion of the upstream plans for the project.

[ Mathieu Desnoyers is the CEO of EfficiOS Inc., which also employs Julien Desfossez and David Goulet. LTTng was created under the supervision of Professor Michel R. Dagenais at Ecole Polytechnique de Montréal, where all of the authors have done (or are doing) post-graduate studies. ]

Comments (none posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 3.4-rc2 . (April 8, 2012)

• Thomas Gleixner: 3.4-rc2-rt1 . (April 10, 2012)

• Thomas Gleixner: 3.4-rc2-rt2 . (April 11, 2012)

• Thomas Gleixner: 3.2.14-rt24 . (April 10, 2012)

• Steven Rostedt: 3.0.27-rt46 . (April 6, 2012)

Core kernel code

• Juri Lelli: sched: SCHED_DEADLINE v4 . (April 6, 2012)

• John Stultz: [RFC] Volatile Ranges (v6) . (April 7, 2012)

• Eric W. Biederman: Completing the user namespace . (April 9, 2012)

• Peter De Schrijver: cpuidle: allow per cpu latencies . (April 9, 2012)

Development tools

• Frederic Weisbecker: tools: Unify perf and trace-cmd trace event format parsing v2 . (April 6, 2012)

• Hui Zhu: KGTP (Linux Kernel debugger and tracer) 20120406 release(hotcode analyzer hotcode.py can output html) . (April 7, 2012)

• Luming Yu: [RFC PATCH] a simple hardware detector for lattency as well as throughput . (April 11, 2012)

Device drivers

• Stephen Warren: regmap: introduce fast_io busses, and use a spinlock for them . (April 6, 2012)

• Tomasz Stanislawski: Integration of videobuf2 with dmabuf . (April 9, 2012)

• Chris Boot: firewire-sbp-target: FireWire SBP-2 SCSI target . (April 11, 2012)

• Sascha Hauer: DRM helpers for embedded systems . (April 11, 2012)

Documentation

• Michael Kerrisk (man-pages): man-pages-3.38 is released . (April 11, 2012)

Filesystems and block I/O

• Miklos Szeredi: vfs: atomic open v3 . (April 6, 2012)

• Evgeniy Polyakov: pohmelfs: call for inclusion . (April 9, 2012)

• Jim Kukunas: lib/raid6: SSSE3 optimized recovery functions v2 . (April 11, 2012)

Memory management

• Aneesh Kumar K.V: memcg: Add memcg extension to control HugeTLB allocation . (April 6, 2012)

• Mel Gorman: Removal of lumpy reclaim V2 . (April 11, 2012)

Networking

• John Fastabend: Managing the forwarding database(FDB) . (April 10, 2012)

• Ian Campbell: skb paged fragment destructors . (April 10, 2012)

Architecture-specific

• Chris Metcalf: arch/tile: provide tilegx networking support . (April 9, 2012)

• Chris Metcalf: arch/tile: provide PCIe support for tilegx . (April 9, 2012)

• Thierry Reding: Add NVIDIA Tegra DRM support . (April 11, 2012)

Miscellaneous

• Luis R. Rodriguez: module: Clarify GPL-Compatible is OK . (April 7, 2012)

• Paul Moore: ANN: libseccomp . (April 9, 2012)

Page editor: Jonathan Corbet

Distributions

Webconverger 12

The Webconverger project released its latest update on April 7. The distribution is targeted at web kiosk usage, providing only a minimal OS and the packages required to run a modern browser. Version 12.x includes several significant changes, however, including support for installing to disk (rather than offering live-mode only), a commercial configuration and update service, and hosting the entire OS in a Git repository.

Webconverger in a nutshell

By "kiosk" usage, the project means something rather specific. It is designed to support intermittent, anonymous users in an environment where system administrators are hard to come by. The examples listed on the project's commercial support page include unrestricted environments like libraries and public gathering spots, plus businesses with more specific needs (like retail banks or doctors' offices). In all cases, it is important that the user's private information be wiped as soon as the session ends, and that the kiosk cannot be altered to change browser or OS settings. The expectation is that with any sort of problem, from a power loss to a browser crash, the system will reboot quickly into a known good state.

Historically that has meant running only in live-mode, from a read-only medium such as a CD or a USB flash drive that is physically inaccessible to the user. The OS uses DHCP to configure networking, and boots into a session running the minimalist dwm window manager along with a version of Firefox customized with kiosk-oriented extensions. The underlying OS is based on Debian Live, and is compiled to run on 486 processors to offer maximum compatibility with older hardware.

The freely available version of Webconverger offers no persistent customization; it will boot to a pre-configured home page inviting you to sign up for the Webconverger remote configuration service. The service allows subscribers to choose a custom start page, adjust or disable the length of the session-resetting timeout, and to remove the address bar chrome to prevent users from navigating off into the wild. The service is Webconverger founder Kai Hendry's mechanism for supporting development; it works by contacting the the Webconverger configuration server at boot time and sending a machine ID code (generated from the BIOS UUID and network interface MAC address), then retrieving the customization details if the account is paid up.

However, you can also specify a range of options at the boot prompt, including the all of the aforementioned customizations available for subscribers, plus display settings, WiFi configuration, internationalization, and debug mode. These options do not survive an unattended reboot, though. If you want your kiosk to start up in something other than the default configuration (including the Webconverger sign-up form as a home page), then your choices are manually rebuilding the ISO and changing the default bootloader options, or signing up for the paid configuration service. You might find other users on the mailing list who have walked down the manual-rebuild road, but the project offers no support for this option.

Firefox is currently the only browser offered (technically, the package is Debian's Iceweasel, but the Webconverger documentation is not strict about the name). The kiosk-mode features are implemented in a suite of open source extensions authored by the Webconverger team: webconverger removes the menu bar and disables keyboard access to many of the Firefox configuration tools, while webcnoaddressbar and webcfullscreen simply remove the address bar and start the browser in full-screen mode, respectively.

A few add-ons and auxiliary packages round out the "web experience" — including the Adobe Flash plug-in and a PDF reader. Although Webconverger attempts to preserve user privacy by disabling browsing history and wiping all private data after each session, it is obviously possible for users to visit unsafe sites, recklessly avoid SSL, or expose themselves to attack by other means. The distribution attempts to guarantee security by having no superuser account and running from read-only media, but the guarantee is essentially machine-level security; a privacy tool like HTTPS Everywhere is not part of the experience.

What's new

The April 7 release is numbered 12.3, and is a minor update to the 12.x series that debuted at the end of March. Downloadable ISO images weigh in at 450MB. The biggest change in this release series is the addition of a hard-disk install option. Obviously such an option dramatically shifts the security profile, since flipping the reset switch and rebooting from read-only media is no longer the simple recovery option.

The project's strategy for securing the system under these circumstances is to maintain the entire OS in a GitHub-hosted Git repository. On an installed system, there is a .git directory (in /) pointing to the official repository. An updater script periodically checks for commits in the repository with a specific tag, and fetches them. At the next reboot, the updated files are merged into the filesystem.

The state of update verification is a little unclear, though. A blog post from April 9 indicates that for now the updater does not verify signatures on the commits, but that the feature has been added to development builds. However, the 12.3 release notes (from April 7), say that the updater runs signed code, and that it checks to see that the signing keys have not been revoked before doing so. Whatever the exact state of the security retooling is, the project does attempt to make it clear that a hard disk install cannot be regarded as being as secure as a live system, and warns concerned users to stick with the live option.

The other noteworthy change in 12.x is that Firefox has been updated to the 10.0.3 Extended Support Release (ESR) version. The ESR versions of Firefox are Mozilla's attempt to designate certain releases for one full year of security and critical updates — in contrast to the now six-week lifespan of Firefox releases for everyone else. The program is the result of Mozilla's Enterprise Working Group, a forum the project established to cooperate with enterprise IT and other large-deployment users who were unhappy with cost and headaches that the rapid-release-cycle was predicted to generate.

Many web kiosks might fall under the same IT rules as large enterprises; they are designed to run unattended, and re-installing a browser every six weeks certainly means more work. The interesting wrinkle is that Webconverger itself has historically released several updates per year. In an email, Hendry said that Webconverger is shifting its focus to following the ESR releases — although, he added, that plan hinges on what happens with the upstream distribution. "We do not have a fixed position really, we are looking for a stable, secure and up-to-date HTML5 browsing experience ultimately."

Kiosk mode is not for everyone; the browser-only OS model envisioned by Mozilla's Boot-to-Gecko and Google's ChromeOS is for a lightweight, persistent environment that centers on the browser. Webconverger is for institutions who need to make the web accessible to strangers for a few minutes at a time. It has its limitations — for example, although it is possible to manually tweak and rebuild the ISO (such as to add new or different add-ons), the project offers no support for such endeavors. It is focused solely on the boot-it-and-forget-it model, with an eye towards attracting paying customers. Perhaps some users will put a peculiar new spin on the primary use-case, such as deploying it as an instant-on option for a secondary OS.

But for the most part, web kiosks are likely to remain an island unto themselves. At least they have a free software project devoted to their care. It is regrettable that the project does not support customization, though — it is certainly within Webconverger's rights to push everyone towards its paid service, and other distributions (such as RHEL) do exactly the same thing. But the project may want to look over its shoulder now and then; RHEL has clones and competitors picking up business from those who don't care for Red Hat's corporate pricing, and kiosk customization is a lot simpler to duplicate than an enterprise support service.

Comments (6 posted)

Brief items

Distribution quote of the week

-- Justin B. Rye

Comments (1 posted)

Debian's diversity statement

After a fairly typical Debian-style discussion, the project appears to have settled on the wording of a diversity statement for the project:

Stefano Zacchiroli has declared an apparent end to the discussion, but is holding off until after the project leader election to give the new leader (assuming it's somebody different) a chance to express an opinion.

Full Story (comments: 77)

Fedora 17 schedule slips

The obligatory Fedora release schedule slip has been announced. Due to some upgrade difficulties, the Fedora 17 beta has been pushed back to April 17; the final release is now expected on May 22.

Full Story (comments: 6)

Kubuntu to be sponsored by Blue Systems

The Kubuntu project recently lost its sponsorship from Canonical, which is pursuing its fortunes in other areas. The project has now announced that it will be sponsored by Blue Systems instead. "Blue Systems sponsors a number of KDE projects and will encourage Kubuntu to follow the same successful formula as it has always had - community led, KDE focused, Ubuntu flavour." The actual extent of this sponsorship is not clear at this time.

Comments (19 posted)

Ubuntu 10.10 (Maverick Meerkat) end-of-life

Ubuntu 10.10 reached its end of support on April 10, 2012. There will be no further updates, including security updates. The supported upgrade path is through Ubuntu 11.04.

Full Story (comments: none)

Distribution News

Fedora

Fedora 17 for Power Alpha Announcement

David Aquilina has a report on the status of Fedora's Power (PPC) port as it approaches an alpha release. "Due to lack of developer time and hardware, Apple hardware support is at this point completely untested. Especially with the switch to grub2 we rely on community feedback and participation to make this work for this release. So if you have the hardware and want it to work, patches welcome! :)"

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

• DistroWatch Weekly, Issue 451 (April 9)
• Maemo Weekly News (April 9)
• Ubuntu Weekly Newsletter, Issue 260 (April 8)

Comments (none posted)

ClearOS,the Missing Link LAN Server (Linux.com)

Carla Schroder showcases ClearOS. "ClearOS used to be named ClarkConnect. It was built on Red Hat Enterprise Linux and CentOS. The current stable release is 5.2, which tracks RHEL 5.2. There are no point releases after that, even though RHEL has had multiple point releases (5.3, 5.4 and so on) leading up to the 6.0 release. RHEL 6.2 was released in December 2011. ClearOS 6.2 beta 3 came out February 29. So what's up? A lot. The maintainers have given it a major overhaul, which will be revealed in all of its glory in the final 6.2 release, which is scheduled for "soon"."

Comments (5 posted)

DoudouLinux: A Starter Distro Where Baby Linux Gurus are Born (Linux.com)

Carla Schroder looks at DoudouLinux, a Debian derivative aimed at children and adult beginners. "Linux is now 20-plus years old and overdue for a third wave that got their start in Linux and Free software. So where will these people come from? An overlooked, obvious, and valuable user demographic is children. Microsoft and Apple know this: capture the children and you capture your future customers. A second valuable user demographic to woo is adult beginners, people who are not very experienced with computers. Children-oriented distributions like DoudouLinux are great for adults because they teach the fundamental skills that we take for granted. It's all abstract, and it's intimidating. We know it's not hard to learn, and that the main barrier for adults is disbelief in their ability to learn how to use computers. It's not a technical problem but a social problem." (LWN reviewed DoudouLinux in 2011).

Comments (2 posted)

Luedecke: openSUSE guide for Ubuntu users

Roger Luedecke has written a guide to openSUSE. "I made mention that our installer is part of something called YaST. Yet another Setup Tool (YaST) is in my opinion the heart of what makes openSUSE unique. Mandriva and Mageia have a similar tool, but it wasn't built with an Enterprise distribution in mind. And though YaST was built with the enterprise user in mind, it still manages to be excellent even for a naïve home user. Part of that is simply the help button. If you go clicking through the modules in YaST, you'll always see a help button. And lo and behold it is in fact actually helpful! It clearly explains what each module and each page of a module does. YaST is ideal for the new user learning about Linux due largely to this. YaST is immensely powerful despite being user friendly, and once again I recommend reading the documentation so that you can truly grasp the GUI goodness and power that is YaST. What more, is that YaST gives you a graphical tool to help you manage and fix issues that Ubuntu would always require you fiddle on a command line terminal, which is something even I am not very comfortable with. "

Comments (none posted)

Interview with Fabio Erculiani of Sabayon Linux (Unixmen)

Unixmen has an interview with Fabio Erculiani of Gentoo based Sabayon Linux. "Gentoo is a meta-distribution that you can bend and shape to your likes. Bringing Gentoo to the masses has always been my dream, making it simple is what Sabayon tries to do everyday. You can see it as a layer on top of Gentoo that handles the hard part for you."

Comments (none posted)

Page editor: Rebecca Sobol

Development

LFCS 2012: X and Wayland

Keith Packard has been working on the X window system since the early days, but more recently has been doing lots of work to enable its replacement. X has long held the position as the way that graphics is done on Linux (and other Unix) systems, but that is changing. He came to the Linux Foundation Collaboration Summit, which was held April 3-5 in San Francisco, to talk about the Wayland protocol and the Weston server, and how they could interoperate with X. Wayland looks to be an interesting change for desktop graphics on Linux.

Wayland is an alternative window system, and is part of long-term effort to integrate more modern technology into the Linux desktop. But there are lots of existing X applications out there that need a migration path so that they don't have to be rewritten. That's part of the plan too, Packard said.

Supporting X in Wayland

The current architecture of X has it rendering via the kernel and getting input from the kernel. The X server handles the geometry of the screen. Packard said that X isn't doing anything other than multiplexing output to the screen, while demultiplexing input. These days, X is generally run with a compositing window manager, so applications create graphics that get sent to the X server, which sends it to the window manager that does the OpenGL rendering, before handing it back to the X server, which then gives it to the kernel to actually get it on the screen.

That is a complicated path that can be simplified by merging the compositor into the window manager. That gets rid of the extra compositor process, which simplifies things considerably. For Wayland, the Weston server is the merger of the two separate pieces in X.

From an application's perspective, there aren't that many changes. It still talks to the server for geometry handling and still talks to the kernel or server to create its graphics. But the protocol is different, which will save a bunch of time, system complexity, and memory, Packard said.

Some applications will still need to talk X, however. One way to do that would be to make Wayland talk X too, but that would violate one of the goals of the project, which is to be lightweight. Weston is currently around 10,000 lines of code, so gluing in "half a million lines of X code" is not the right approach.

Instead, a new xwayland component was created. The X server will still be running, and applications will talk to it as they do now, but that server will talk to the xwayland hardware backend that will in turn talk to Weston. This is similar to what is done to support X on Mac OS X and Windows, which normally "sucks for performance", but the Wayland developers have come up with a way around that problem.

An application can do OpenGL or VAAPI (Video Acceleration API) rendering via the kernel in a buffer that is owned by the X server. The server passes that buffer to Weston via xwayland, but it is just a handle that is passed, not the actual data. The handles are just "tiny little names", he said, so there is very little bandwidth required to transfer them. It does require an extra context switch, but shouldn't add any latency compared to existing X.

X vs. Wayland

There are really only a few differences between X and Wayland; Packard was only able to come up with three. First, X has an external compositor, while Wayland's is internal. X deliberately put the compositor into a separate process because people wanted to experiment with compositing. In addition, the X server generally runs as root, so pushing the compositing code out of the server itself was safer. It has been a successful experiment overall, but it does add some latency and requires that identical state information is held by both the X server and compositor. Both have all of the information about all of the windows on the screen, and the compositor has to mirror the X server data structures and do incremental updates to those based on damage events.

Second, X has external window management, and Wayland internalizes that. The reason X did that originally was because of a lack of shared libraries in 1987 when window management was added. In order to share common user interface (UI) elements between applications, they had to be centralized in an external window manager. One nice bonus of that decision is that an application's window can still be managed (e.g. minimized) even if the application itself locks up. That is a side effect of having a common UI for all the applications on the screen.

Lastly, X applications do not paint their window decorations, while Wayland applications will need to. This is why a Qt application today in a Gtk environment gets Gtk window decorations. In Wayland, clients will need to do their own decorations, but the toolkits (e.g. Qt, Gtk) already know how to do so. Toolkits have been using window manager hints to get the window manager to decorate the way they want for years, now the toolkits will just do it themselves.

We own the stack

One nice benefit of working on free software is that "we own the whole stack", so whatever changes are needed can just be made. The last seven years have been spent moving things out of the X server and into the kernel. Things like PCI mappings, mode setting, rendering, and more are all in the kernel now so they can be shared by all window systems and applications. In addition, any window system can use OpenGL just by using the libraries that are available. The same OpenGL library can be used by both X and Wayland.

Several large barriers to entry for new window systems have been removed. OpenGL support is just one of those. The VAAPI code is "window system agnostic" now as well. Mode setting, which was a "huge barrier to entry" is now available to any window system because it lives in the kernel. Similarly, Wayland can just use the kernel execution management code to get accelerated graphics rendering. In addition, because they had the ability to fix both X and Wayland, they could make performance improvements like using handles instead of passing buffers around.

The performance of X typically becomes "abysmal" when it runs on top of another window system like Windows or Mac OS X because the server has to do a lot of bulk memory copies. But, because Wayland is cooperating with X, you get "full speed 2D rendering" while direct rendering is unchanged. Buffer swaps will happen every 16ms, when the X server tells xwayland it has new content and Weston tells the kernel to display it. Putting X atop Wayland will actually "reduce the context switches to once every 16ms", which may make it perform better than native X, Packard said. He doesn't have any numbers, and the effect will likely be imperceptible, but it could be faster. From the audience, Greg Kroah-Hartman also noted that it may result in power savings.

"It's not all ponies and rainbows", he said, as there are still some problems that need to be addressed. One is that X atop Wayland will still require an X window manager. The current plan is to have a Wayland-specific window manager that will translate from the X domain to the Wayland domain. It will take size hints, for example, and talk to Weston using the Wayland protocol to handle the hints. It will also have to provide window decorations, which is an "opportunity for more confusion on the Linux desktop", Packard said. Because desktop environments have enforced a particular style of decorations via their window manager, all applications on the desktop had the same decorations regardless of the toolkit used, but that will no longer be true when each toolkit does its own decorations.

It took around 50 patches to the X server to make it work with Wayland, which is "much much easier" than it was to get X working on Windows, he said. The patches were rebased on the 1.12 server code and mostly cover changing the input handling so that it comes from Weston. X video drivers also had to change, once again mostly to defer things like mode setting and acquisition of the DRM master to Weston. In addition, some "ugly hacks" for window moving and resizing were replaced by the X/Wayland window manager.

Window management

The window manager that is part of Weston needs client-side window decorations so that they can be painted into the same buffer as the rest of the application's output. That way, scaling or rotating the output will properly handle the window decorations as well. In addition, it simplifies Weston by not requiring a lot of UI code to handle the decorations, and the applications (or toolkits) can respond appropriately to events from the decorations.

For example, resizing windows in X is currently "messy" and that causes "ugly output". But that will be fixed with Wayland. In addition, with client-side decorations, those decorations no longer need to be rectangular, so applications are free to create decorations of their own size and shape. There are some acceleration features in Weston so that applications can tell it to move a window following the mouse, or indicate a place for users to click to minimize a stuck application.

The X/Wayland window manager will have to handle decorations as well as dealing with ICCCM (inter-client communications conventions manual) and EWMH (extended window manager hints). That means it will need to "implement all the bugs in X", but it stops there, he said, and the X/Wayland window manager will talk "nice stuff" to Wayland. For example, there is a huge amount of ICCCM that deals with installing and managing color maps that no one uses anymore, which will be handled directly by the window manager.

X was created before there was MIME or Unicode, so there are many pages expended in the X specifications to do things that are more easily handled with MIME types and UTF-8 these days. For cut-and-paste and drag-and-drop, Wayland uses MIME-labeled UTF-8 encoded objects. For client-to-client data transfer, one client just hands a file descriptor to Weston which hands it to the other client. That eliminates another ten pages of ICCCM which "reimplemented TCP on top of X properties".

The X server could be started automatically at session initialization time, but that would slow down session startup and add extra memory overhead. It could be started manually by the user instead, but a better way is for Weston to listen on the X socket. When a client connects, Weston will launch X and pass the sockets to the X server. When the last X client closes, the X server can then exit. Kroah-Hartman asked about using systemd to start X, but Packard said that Lennart Poettering indicated that systemd cannot start X, though he's not sure why that is. In any case, it is only 20 lines of code in Weston.

Remaining issues

There are, of course, some remaining issues to be worked on. For one thing, Wayland input handling is still in flux. There are questions surrounding keyboard support, as well as lots of code needed to support touchscreens and touch pads. There has been a lot of work on gestures and global system-wide touch support that will come to the Wayland environment with Xinput 2.2 support.

Another area that needs to be worked on is remote Wayland applications. The X community has had this capability for a long time and would like to be able to continue to use it. Supporting remote Wayland applications is not fundamentally different from local applications, he said. Applications will still create a new image and deliver it to the window server. In the local case, though, the pixels don't need to be transferred, but over the network, there is no shared memory between application and server.

There are "lots of nice network image transports", Packard said, that could be used to transfer the image data. That data could be compressed, perhaps even using a lossy compression, then sent to the server. Both sides could use any available hardware assistance (e.g. MPEG encode/decode), which would help with performance. Wayland avoids one of the major sources of latency in X, which is round-trips, so remote Wayland may actually have better performance than remote X. There are still lots of things to try, he said, but that's the current plan of attack.

The xwayland X server backend is working today. It redirects windows correctly and is started automatically. The synthetic keyboard and mouse that use the current Wayland keyboard handling is also working. The Intel video drivers bypass mode setting to work in Wayland environments. The X/Wayland window manager, cut-and-paste and drag-and-drop, as well as Xinput 2.2 support (for things like scroll wheels and touchscreens) are all things that he listed as still needing to be done. But it is clear that we are well on our way to having Wayland-based desktops that can still support the vast array of legacy X applications. It will be an interesting transition to watch.

Comments (180 posted)

Brief items

Quotes of the week

-- John Gilmore

-- "⚛" on avoiding out-of-memory problems in 32-bit Go programs

-- Kyle Lemons

Comments (46 posted)

DEAP 0.8 released

DEAP is a library for the development of distributed evolutionary algorithms in the Python language. It provides two major components: a task manager for distributing work across a cluster of machines, and the EAP library which provides support for a wide variety of evolutionary algorithms. The 0.8 release adds Python 3 support, a new generate-update algorithm, lots of new examples, and more.

Full Story (comments: none)

Pan 0.136 released

Version 0.136 of the Pan newsreader is available. New features include support for uploading attachments, PGP encryption and signature support, TLS 1.0 support, GNOME keyring support, and more.

Full Story (comments: 5)

PostGIS 2.0.0 released

Version 2.0.0 of the PostGIS geographical database system is out. There is a long list of new features, including raster data and raster/vector analysis support, the ability to handle objects with shared boundaries, 3D and 4D indexing, and more.

Comments (none posted)

Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 security release

The Python project has released updated versions of Python 2.6, 2.7, 3.1, and 3.2; in each case, the objective is to close the hash collision denial of service vulnerability. It's worth noting, though, that the fix needs to be enabled explicitly: "Historically, dict iteration order has not changed very often across releases and has always remained consistent between successive executions of Python. Thus, some existing applications may be relying on dict or set ordering. Because of this and the fact that many Python applications which don't accept untrusted input are not vulnerable to this attack, in all stable Python releases mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT." It can be enabled with a command-line option or through an environment variable.

Full Story (comments: 42)

The state of Wayland

For those following the development of the Wayland display system, a new, concise summary of the state of Wayland has been posted. "GTK+ 3.4.1 and Qt5 appear to have complete Wayland support except for client side decorations (CSD). EFL and Clutter appear to have complete support. So any application should work with Wayland as long as it uses one of these four toolkits, and it doesn't call any Xlib functions. Unfortunately a number of GTK+ applications do call Xlib, through gdk_x11_* functions, and they need to be wrapped in build-time and run-time backend checks."

Comments (39 posted)

Newsletters and articles

Development newsletters from the last week

• Caml Weekly News (April 10)
• What's cooking in git.git (April 10)
• Perl Weekly (April 9)
• PostgreSQL Weekly News (April 8)
• Ruby Weekly (April 5)
• Tahoe-LAFS Weekly News (April 7)

Comments (none posted)

Page editor: Jonathan Corbet

Announcements

Articles of interest

A report from the Peru OLPC deployment

For those in a hurry, the Economist has a brief and mostly negative summary of a report on the benefits of the One Laptop Per Child program in Peru. "An evaluation of the laptop programme by the Inter-American Development Bank (IDB) found that the children receiving the computers did not show any improvement in maths or reading. Nor did it find evidence that access to a laptop increased motivation, or time devoted to homework or reading."

For those with more time, the actual report is more nuanced. "Results indicate limited effects on academic achievement but positive impacts on cognitive skills and competences related to computer use. Cognitive abilities may arise through using the programs included in the laptops, given that they are aimed at improving thinking processes. However, to improve learning in Math and Language, there is a need for high-quality instruction. From previous studies, this does not seem the norm in public schools in Peru, where much rote learning takes place."

Comments (16 posted)

Linux for Your Electric Car: Techies Create Open Source EVs (txchnologist)

The Tumanako Project aims to provide open hardware and software to drive and recharge electric vehicles. Author Morgen E. Peck covers the project and talks with developer Philip Court. "The main offering of the Tumanako project is a drive package and inverter for a 200kW induction motor. This includes all of the software necessary to take a “go” command from a driver and the calculations for how much power to feed to the motor. Court says his code works but will not be fully open source — meaning there are still snippets of proprietary code — for another 6 months to a year."

Comments (4 posted)

AOL Unloads Patents to Microsoft (Wall Street Journal)

The Wall Street Journal is running a short article about a patent deal between AOL and Microsoft. "AOL Inc. agreed Monday to sell more than 800 patents and related products to Microsoft Corp. for $1.1 billion, as the struggling online company looks to raise fresh cash while fighting a boardroom showdown with an activist shareholder." (Thanks to Martin Jeppesen)

Update: this article has more information, including a list of some of the patents involved.

Comments (8 posted)

FSFE Newsletter - April 2012

The April edition of the Free Software Foundation Europe Newsletter looks at projects and initiatives, warns European Parliament staff not to accept gifts from Microsoft, welcomes Nikos Roussos from Greece as a member of the Fellowship, and covers several additional topics.

Full Story (comments: none)

New Books

Build Awesome Command-Line Applications in Ruby--New from Pragmatic Bookshelf

Pragmatic Bookshelf has released "Build Awesome Command-Line Applications in Ruby" by David Bryant Copeland.

Full Story (comments: none)

Upcoming Events

Events: April 12, 2012 to June 11, 2012

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

Date(s)	Event	Location
April 10 April 12	Percona Live: MySQL Conference and Expo 2012	Santa Clara, CA, United States
April 12 April 13	European LLVM Conference	London, UK
April 12 April 15	Linux Audio Conference 2012	Stanford, CA, USA
April 12 April 19	SuperCollider Symposium	London, UK
April 13	Drizzle Day	Santa Clara, CA, USA
April 16 April 18	OpenStack "Folsom" Design Summit	San Francisco, CA, USA
April 17 April 19	Workshop on Real-time, Embedded and Enterprise-Scale Time-Critical Systems	Paris, France
April 19 April 20	OpenStack Conference	San Francisco, CA, USA
April 21	international Openmobility conference 2012	Prague, Czech Republic
April 23 April 25	Luster User Group	Austin, Tx, USA
April 25 April 28	Evergreen International Conference 2012	Indianapolis, Indiana
April 27 April 29	Penguicon	Dearborn, MI, USA
April 28	Linuxdays Graz 2012	Graz, Austria
April 28 April 29	LinuxFest Northwest 2012	Bellingham, WA, USA
May 2 May 5	Libre Graphics Meeting 2012	Vienna, Austria
May 3 May 5	Utah Open Source Conference	Orem, Utah, USA
May 7 May 9	Tizen Developer Conference	San Francisco, CA , USA
May 7 May 11	Ubuntu Developer Summit - Q	Oakland, CA, USA
May 8 May 11	samba eXPerience 2012	Göttingen, Germany
May 11 May 12	Professional IT Community Conference 2012	New Brunswick, NJ, USA
May 11 May 13	Debian BSP in York	York, UK
May 13 May 18	C++ Now!	Aspen, CO, USA
May 17 May 18	PostgreSQL Conference for Users and Developers	Ottawa, Canada
May 22 May 24	Military Open Source Software - Atlantic Coast	Charleston, SC, USA
May 23 May 25	Croatian Linux Users' Convention	Zagreb, Croatia
May 23 May 26	LinuxTag	Berlin, Germany
May 25 May 26	Flossie 2012	London, UK
May 28 June 1	Linaro Connect Q2.12	Gold Coast, Hong Kong
May 29 May 30	International conference NoSQL matters 2012	Cologne, Germany
June 1 June 3	Wikipedia & MediaWiki hackathon & workshops	Berlin, Germany
June 6 June 8	LinuxCon Japan	Yokohama, Japan
June 6 June 10	Taiwan Mini DebConf 2012	Hualien, Taiwan
June 7 June 10	Linux Vacation / Eastern Europe 2012	Grodno, Belarus
June 8 June 10	SouthEast LinuxFest	Charlotte, NC, USA
June 9 June 10	GNOME.Asia	Hong Kong, China

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

Page editor: Rebecca Sobol