LWN.net Logo

LWN.net Weekly Edition for May 27, 2010

The road forward for systemd

By Jonathan Corbet
May 26, 2010
At the end of April, Lennart Poettering announced the initial availability of systemd, a new system initialization and session management daemon. This announcement caused a bit of surprise and concern for those who didn't know it was coming. Lennart's work with PulseAudio remains a bit of a difficult memory for some users (though it seems to be working well for most people now), and some people had thought that the initialization problem was solved with the growing adoption of upstart. Systemd is a different approach, though, which may yet prove sufficiently compelling to motivate another big change.

There are many new features in systemd, but the core change is a concept stolen from the MacOS launchd daemon - and from others that came before launchd. There are (at least) two ways to ensure that a service is available when it is needed: (1) try to keep track of all other services which may need it and be sure to start things in the right order, or (2) just wait until somebody tries to connect to the service and start it on demand. Traditional Linux init systems - and upstart too - use the first approach. Systemd, instead, goes for the second. Rather than concern itself with dependencies, it simply creates the sockets that system daemons will use to communicate with their clients. When a connection request arrives on a specific socket, the associated daemon will be started.

This approach simplifies the system configuration process because there is no longer any need to worry about dependencies between services. It holds out the promise of a faster bootstrap process because nothing is started before it is actually needed (plus a fair amount of other work has been done to improve boot time). The systemd approach to managing daemons allows a fair amount of boilerplate code to be removed, at least under the difficult assumption that the daemon no longer needs to work with other initialization systems. Lennart clearly thinks that it is a better way to manage system processes, and a number of others seem to agree.

That said, there are some obstacles to the widespread adoption of systemd by distributors. To begin with, a number of them are just now beginning to use upstart in its native mode; the idea of jumping into another transition is not necessarily all that appealing. Daemons must be patched to work optimally with systemd; otherwise the socket-based activation scheme is not available. The patching is a relatively simple task, but it must be done with a number of daemons and the result accepted back upstream. There are also concerns about how well some types of services (CUPS was mentioned) will work under systemd, but Lennart seems to think there will not be troubles there.

Another area of concern, strangely enough, is the use of control groups (cgroups) by systemd. Cgroups are a Linux-specific feature initially created for use with containers; they allow the grouping of processes under the control of one or more modules which can restrict their behavior. Systemd uses cgroups to track daemon processes that it has created; they allow these processes to be monitored even if they use the familiar daemon tricks for detaching themselves from their parents. So if systemd is told to shut down Apache, it can do a thorough job of it - even to the point of cleaning up leftovers of rogue CGI scripts and such.

Cgroups would also make it easy for system administrators to set up specialized sandboxes for daemons to run in. The problem there is that there is no easy way for systemd to pick up a cgroup setup already created by somebody else; there is no transparent inheritance for cgroups now. So Lennart is asking for that type of inheritance to be added.

Beyond that, though, some people have concerns about the use of cgroups in the first place. Peter Zijlstra worries about adding yet another feature which must be built into the kernel for the system to even boot. The Debian community does not like the use of the "debug" group, which is not currently configured into its kernels. Systemd may eventually get a more appropriately-named cgroup subsystem for its use, but it is not going to work without the cgroup feature at all. So people wanting to boot systems with systemd will need to have cgroups built in. Lennart has this message for people who don't like that:

Next time something is added to the kernel please mark it as "Hey, please don't use it, this is only here so that you don't use it. Thanks!" Maybe then dumb-ass folks like me will notice and refrain from using it.

There are also claims that work on systemd is primarily motivated by antipathy toward Ubuntu and, especially, its copyright assignment policies. There can only be a bit of truth in some of that; hearing early talk about the work which became systemd is part of what inspired this article on assignment policies back in October. That said, Lennart insists that the motivations behind systemd are technical, and he asks that it be judged on its technical merits.

So where do things stand with regard to adoption of systemd?

  • There is an intent to package bug filed for Debian; the packager plans to make it easy to switch between sysvinit and systemd at boot time.

  • Lennart plans to have a systemd package ready for Fedora 14, saying "whether we can have it as default is to be seen". Given that the Fedora 14 cycle has already begun, even thinking about adding a change that fundamental as the default seems ambitious. So it may be a hard sell, but Lennart would like to see it: "It would certainly be a shame though if other distros would ship systemd by default before we do."

  • Gentoo has an experimental systemd package available, but it has not found its way into the main distribution yet.

  • openSUSE is apparently (according to Lennart's original announcement) discussing it internally, but, as is often the case with openSUSE, there is no public indication that it is being considered.

  • Ubuntu seems unlikely to consider a change anytime soon.

So it is not clear that any distribution will make the jump to systemd. But, then, even the above is a fair amount of attention for a project which has been public for less than one month. This program has reopened the discussion on how our systems should initialize themselves, and things may go on from there: there is talk of using systemd to take over the tasks of processes like cron and gnome-session. Regardless of who ends up running systemd, the ideas it expresses are likely to influence development for some time.

Comments (200 posted)

Interesting times for Linux Flash support

May 26, 2010

This article was contributed by Koen Vervloesem

Although many proponents of free software and an open web don't like Flash, the multimedia platform has become so ubiquitous that it is difficult to imagine the web without it. However, Flash support has always been a challenge for Linux distributions. Adobe has had a proprietary Linux release of its Flash player software for years now, but only for the x86 processor architecture. Meanwhile, open source projects trying to recreate Flash functionality are lagging behind and struggling with lack of manpower. Luckily, there are also some interesting new technical developments in the open source Flash world. One that sparked our interest recently is Lightspark, which was written from scratch based on the SWF documentation Adobe published in June 2009 as part of the Open Screen Project.

The official Flash player

For years, Adobe treated Linux as a second-class citizen. As recently as 2007, Linux users had to wait six months after the Windows release for their version of Adobe Flash 9. At the end of 2008, that changed: with the release of Flash Player 10, Adobe released versions for Windows, MacOS X and Linux on the same day. However, that's not to say there are no problems with the proprietary Flash player. 64-bit support is still a sore point: although it's possible to use Adobe Flash player on a x86_64 Linux system using a 32-bit emulation layer such as nspluginwrapper, native 64-bit support is only available as an alpha version that was first released in November 2008.

In hindsight, it's ironic that, as late as it may come to the party, Linux is the first platform that gets a peek at a 64-bit Adobe Flash player. In its FAQ for the 64-bit prerelease, Adobe writes:

We chose Linux as our initial platform in response to numerous requests in our public Flash Player bug and issue management system and the fact that Linux distributions do not ship with a 32-bit browser or a comprehensive 32-bit emulation layer by default. Until this prerelease, use of 32-bit Flash Player on Linux has required the use of a plugin wrapper, which prevents full compatibility with 64-bit browsers. With this prelease [sic], Flash Player 10 is now a full native participant on 64-bit Linux distributions.

Open source approaches to Flash

But x86 and preliminary x86_64 support for Flash obviously isn't enough in the open source world. Granted, Adobe is or has been working with some mobile phone manufacturers to offer a version for ARM (for example on MeeGo or Android), but people running a Linux desktop system on a non-Intel processor are left in the cold. Until last year, your author was in exactly this position, running Debian on a PowerMac G5. If non-Intel users want to run the official Flash player they have to use ugly solutions such as running Flash in an x86 emulator.

Luckily there are some open source programs recreating Flash functionality, of which the most well-known is Gnash ("GNU Flash"), which also runs on PowerPC, ARM and MIPS processors. It's not even limited to Linux: Gnash also supports FreeBSD, NetBSD, and OpenBSD, so it pleases a lot of people that don't want to run proprietary software on their open source operating system but have to be able to see Flash content. In March we looked at the current state of affairs of Gnash when project lead Rob Savoye talked about the project at SCALE 8x.

Although Gnash has been progressing well, the nature of the project means that it will always be chasing Adobe. Moreover, Gnash is facing some manpower challenges. The Open Media Now! foundation was started in 2008 to fund Gnash development, but, because of the economic crisis, the four full-time developers were cut back to zero, Gnash developer Bastiaan Jacques said last year. Recently, another issue appeared: a growing disagreement between the two top contributors Benjamin Wolsey and Sandro Santilli on the one hand, and Rob Savoye on the other hand.

Different development styles

It all started with a message by Benjamin Wolsey to the Gnash-dev mailing list on Friday 21 May:

Recently there have been several commits to Gnash that break the testsuite, make Gnash unstable, and have serious issues with code quality.

Unfortunately this means that I have to spend considerable time reverting faulty changes, reimplementing things properly, and fixing the testsuite just to stop the damage spreading.

At the end of his message, Benjamin announced that he would start his own stable branch of Gnash if another commit of this sort appeared, implicitly threatening a fork. Benjamin's accusations seemed to be primarily aimed at Rob, who answered that the usual policy of free software projects is that frequent checkins are good. However, Sandro Santilli added that this policy would only work if the checkins are small and do not break the test suite. Then the discussion became somewhat nasty with general accusations thrown back and forth, but Rob soon pinpointed the central point of disagreement:

We have very different coding styles. I prefer to work very publically, checking code in frequently, and then fixing it over the next few checkins. This is the way most all free software projects I've been involved in for 20 years operate.

Rob also defended himself against the accusation that he doesn't consider testing important: "Remember, I wrote the majority of our testsuite, so I think it's fair to say I consider testing important." But he also wants to focus on new features and he has the impression that this doesn't work when the "stable branch" has to remain stable all the time:

Instead I get endless rewrites of existing code, all aimed towards "code quality". This does not advance Gnash at all, which is why our funding evaporated.

John Gilmore tried to get the two parties back together behind their common cause ("We need each other, guys"), and Sandro suggested to use an experimental branch for code that breaks things.

However, because Benjamin reverted one of Rob's commits and threatened to do it again in the future, Rob removed Benjamin's commit rights to the Savannah repository for Gnash, because he doesn't want to "allow a power-hungry developer to continue to reverting my changes." In the meantime, Sandro worked on some improvements and asked where he should commit the code: to the Gnash trunk where Benjamin couldn't review it and Rob maybe wouldn't accept the changes, or to a fork, which would make the project diverge? Sandro obviously still cares for the Gnash project and rightly fears that a fork will not be good for the common cause.

After a few nights of sleep, Benjamin, Sandro, and Rob seem to acknowledge that they have different development, project management, and communication styles, that they all made mistakes, and were too rude in their responses at some times. At the time of this writing, they were still on speaking terms on the #gnash irc channel on Freenode and were actively trying to reach a consensus and drafting some new commit rules (including "Commits shall not be reverted except as a last resort." and "No code shall be committed that causes failures in existing tests."), so this whole crisis may well result in a better development process for the project.

The death of Swfdec

Another Flash decoder, Swfdec, has silently stopped development a while ago. The last stable release, 0.8.4, is from December 2008, and the last commits are from December 2009. Swfdec has been primarily run by one person, Benjamin Otte, but he seems to have lost interest, although he is still occasionally answering questions on the Swfdec mailing list. In response to a question by Puppy Linux developer Barry Kauler in January of this year, Benjamin announced the death of his project in one sentence:

That said, active Swfdec development has pretty much stopped, so you'll likely not see any new features in the near future anyway.

The fact that Benjamin started a new job in Red Hat's desktop team in January of this year is surely no coincidence: it should remind us that a project with just one core developer always has a fragile future because big changes in the developer's life can result in less time to work on the project.

A new open source Flash player

Development of Gnash and Swfdec was done using reverse engineering because Adobe only offered the SWF specification with a license that forbids the use of the specification to create programs that play Flash files. In June 2009, Adobe launched the Open Screen Project which made the SWF specification available without these restrictions. This made it possible for Alessandro Pignotti to work on a new open source Flash player, entirely based on this official SWF documentation. A part of this project is based on his bachelor's thesis at the university of Pisa, called An efficient ActionScript 3.0 Just-In-Time compiler implementation [PDF].

The result is Lightspark, which includes OpenGL-based rendering, a mostly complete implementation of Adobe's ActionScript 3.0 using the LLVM compiler, and a Mozilla-compatible browser plug-in. Because Lightspark has been designed and written from scratch based on Adobe's documentation, it promises a clean code base optimized for modern hardware.

By using OpenGL instead of XVideo, Lightspark allows for hardware-accelerated rendering using OpenGL shaders. Moreover, this opens the path for supporting blur and other effects that are implemented by efficient shaders. Another possibility is using OpenGL textures to display video frames, which is less efficient than XVideo but more flexible. For example, it makes it possible to implement the overlay and transformation effects that Flash supports.

For ActionScript 3.0 (introduced in Flash 9), Lightspark has both an interpreter and a JIT compiler that uses LLVM to compile ActionScript to native x86 code. However, because the previous ActionScript versions run on a completely different virtual machine, Alessandro has decided to not support them. This means that currently it's not really possible to compare the performance of Lightspark with that of Gnash: while Lightspark only supports ActionScript 3.0, Gnash only supports previous versions of the scripting language.

For people that want to try Lightspark in their browser, Alessandro has released a Mozilla-compatible plug-in. When encountering an unsupported Flash file, the plug-in should fail gracefully. For now, there's only a PPA (Personal Package Archive) for Ubuntu users, but packages are being created for Arch Linux and Debian. In this alpha phase of development, the current release is more of a technological demo. Alessandro is currently the only developer, although some external contributions have started trickling in.

After the first wave of testing, Alessandro published some information on the plan for the next releases. A stability release with no new features is planned for the first week of June, while release 0.5.0 will be focused on YouTube support. He also clarified that his current implementation only works on x86/x86_64 because of some assembly code, but he welcomes ports to other architectures:

The code is build using standard technologies, such as pthreads and STL and should be quite portable, but some critical code paths has been written in assembly to guarantee atomicity or improve performance. I've very little experience with anything beside x86/x86-64, so I prefer not to port such critical code. However I will gladly accept any contributions for other platforms, such as PPC and ARM. The good news is that a contributor managed to compile lightspark on FreeBSD/x86 with minimal changes to the build system and a windows port is also planned.

The Gnash developers have been talking with Alessandro about joining their efforts, but he decided to work on Lightspark because it was very difficult to include an optimizing JIT compiler into the existing Gnash architecture. That said, code sharing or even a closer collaboration between the two projects certainly seems possible. Alessandro has already said that Lightspark's code could be integrated with Gnash in time when it's good enough, and Rob would like to add support for using Lightspark in Gnash to handle AVM2, the ActionScript virtual machine that Adobe introduced in Flash 9. If this idea is implemented, Gnash could essentially hand off all ActionScript 3 functionality to Lightspark.

Conclusion

Although most free and open source proponents agree that Flash is a bad thing and that it should be replaced by open web technologies such as HTML 5, the transition to an open web will happen slowly as all evolutions in the computer world do. Moreover, we are stuck with a lot of existing Flash content that should remain accessible. Therefore, open source Flash projects like Gnash and Lightspark will remain important for many Linux users for years. There is hope that the Gnash developers will reach a consensus on their development model and hopefully Lightspark will not face the same fate as Swfdec. For something as critical as Flash is to many users, more developers for both projects could certainly help.

Comments (15 posted)

Swift and predictable reactions to WebM

May 25, 2010

This article was contributed by Nathan Willis

On May 19, Google unveiled something that many in the open source community had been expecting (and which the Free Software Foundation asked for in March): it made the VP8 video codec available to the public under a royalty-free, open source BSD-style license. Simultaneously, it introduced WebM, an HTML5-targeted open source audio-and-video delivery system using VP8, and announced a slew of corporate and open source WebM partners supporting the format, including web browsers and video sites such as its own YouTube property.

Dueling assessments, interested parties

The move was not unexpected. Google began trying to acquire VP8's creator, the codec shop On2, months ago, and speculation began even before the acquisition was final. The public reaction to the WebM launch was not unexpected, either. MPEG-LA, the commercial sellers of license for the competitor H.264 codec, suggested that anyone who used VP8 would get sued for patent infringement. An independent H.264 hacker quickly attacked VP8 as inferior on all technical counts, and surely in violation of multiple H.264 patents as well. H.264 proponents and general news sites began circulating that blog post, more so when Apple's Steve Jobs allegedly forwarded a link to it in response to an email asking his opinion on VP8.

Responses from the open source community itself have come in two flavors. The first was a long line of multimedia projects and companies announcing support for VP8 and WebM; some (like Mozilla and Collabora) were in the know before the deal was made public and working on their code, while others just reacted swiftly following the unveiling.

The second took on the opposition, rebutting both the MPEG-LA's public statements and the attacks of the H.264 hacker, Jason Garrett-Glaser. Many pointed out Garrett-Glaser's vested interest in H.264 being regarded as the technically best codec, given that he develops the x264 encoder project, and suggested that he was prejudiced against VP8 before even examining the release. StreamingMedia.com compared the codecs side-by-side, encoding the same source media at the same audio and video data rates, which Garrett-Glaser did not do, and concluded that there was no noticeable difference for most applications. Theora hacker Gregory Maxwell addressed the technical issues in an email to the Wikitech list, arguing that the initial release of Google's VP8 encoder represents a starting point ripe for optimization.

Other naysayers dismissed VP8 on the grounds that H.264 is already widely supported in hardware devices. That may be true, but most of this hardware support is in the form of embedded digital signal processor (DSP) code, and DSP ports of Theora were already in the works. Considering that Google has already funded ARM optimizations of Theora, there is grounds to believe it will push DSP playback of VP8 as well, and the company's Android platform is a likely place for it to make an appearance.

Patents and ambiguity

More important than the current (or even the potential-future) technical performance of VP8 is the question of whether it can legally be used under the terms spelled out in the WebM license and patent grant. It is clearly a technical improvement over Theora, but if the competition proved a genuine instance of patent infringement, the codec would need to be changed before it could be safely used.

On this point, again, there are two main threads of discussion. The first boils down to debate over the belief that VP8 must surely infringe on patents used in H.264 because the codecs share such a similar structure. Garrett-Glaser takes this stance, pointing out similarities in the algorithms. Xiph.org's Christopher "Monty" Montgomery dismissed that assessment as "serious hyperbole," and others in web article comment threads pointed out that all discrete cosine transform (DCT)-based codecs utilize the same basic steps; those steps are not what video codec patents cover.

Maxwell rebuffs the similarity argument as well, saying that Garrett-Glaser "has no particular expertise with patents, and even fairly little knowledge of the specific H.264 patents" due to the fact that x264 ignores them when implementing H.264 itself. He continued:

Codec patents are, in general, excruciatingly specific — it makes passing the examination much easier and doesn't at all reduce the patent's ability to cover the intended format because the format mandates the exact behavior. This usually makes them easy to avoid.

The second discussion thread amounts to divining whether H.264's patent licensor MPEG-LA will actually sue over a patent infringement charge against VP8. Here again, the public debate is dominated by assumptions: surely Google did a patent search that completely exonerated VP8; surely On2's patent lawyers knew what they were doing as they developed VP8 — and, alternatively, surely VP8 infringes somewhere, because there are just so many patents in H.264; surely VP8 infringes somewhere, because H.264 was created by the best codec authors using the best technologies.

To get out of the "surely" mire, consider the actual possibilities case by case. It is logical to suggest that if MPEG-LA has a genuine case, it will sue. If it does not have a genuine case, the question is whether the consortium will sue anyway to cause market confusion and buy time to continue selling H.264 patent licenses. But either way, the risks in filing a lawsuit are extraordinarily high — because Google could easily counter-sue.

Despite MPEG-LA's promotional material suggesting that blanket rights to use H.264 come with a license, the actual guarantee of the patent pool is quite weak:

No assurance is or can be made that the License includes every essential patent. The purpose of the License is to offer a convenient licensing alternative to everyone on the same terms and to include as much essential intellectual property as possible for their convenience. Participation in the License is voluntary on the part of essential patent holders, however.

Clarity, please

In other words, submarine patents and patent trolls can threaten H.264 — and in theory, On2 and Google may hold such patents. So what will MPEG-LA do? CEO Larry Horn already suggested, without directly claiming, that it believes it has a genuine case against VP8. Whether it does or doesn't, actually filing an infringement lawsuit could gamble away the H.264 cash cow. The far safer route is to make noise in public, pursue licensing deals with software and hardware vendors as long as possible, and work on the next codec licensing bundle. For its part, Google has done little in public other than express its confidence that there is no patent issue.

That sounds unsatisfying to the left-brained software developer, who would prefer a clear, bright line to be drawn with VP8 either on the "safe" or "unsafe" side. Unfortunately, the modern patent game does not work that way. In practice, patents are hidden weapons that can be used to sue (and threaten to sue) opponents. All commercial players hold them, and due to the vast number of patents granted — as well as the unknown reach of those patents — many are effectively hidden away until used in an attack.

Still, some have already suggested that Google can and should provide some level of increased clarity by publicly and transparently documenting the patents it now owns on VP8, and the patent search process it used to determine that nothing in VP8 infringed on a competitor's patents. Florian Mueller of FOSS Patents commented:

At the very least I think Google should look at the patents held by the MPEG LA pool as well as patents held by some well-known 'trolls' and explain why those aren't infringed. Programmers have a right to get that information so they can make an informed decision for themselves whether to take that risk or not. It's not unreasonable to ask Google to perform a well-documented patent clearance because they certainly have the resources in place while most open source developers don't.

Rob Glidden, formerly of Sun, contrasted Google's one-shot announcement of VP8 with the process Sun used when working on the now-shuttered Open Media Stack video codec project, which "based their work on identifiable IPR [intellectual property rights] foundations, documented their patent strategy, and [was] willing to work with bona-fide standards groups to address and resolve IPR issues." By choosing to "go on their own," he added, Google actually undermines the open standards process the web relies on.

On the other hand, Google might consider it to be to its own advantage to keep the company's VP8 patent research secret, in order to force potential attackers to do more work looking for an infringement. No one does (nor should they) expect MPEG-LA to act with the clarity being asked of Google. At times MPEG-LA likes to present itself as if it is a standards body — one that produces technical work reflecting the consensus of industry, and ratifying the best possible ideas into global specifications. But that simply is not true. MPEG-LA is a for-profit business, selling its products and marketing them on behalf of its members and against all competitors.

Since its product is protection from a lawsuit by MPEG-LA itself, it gains nothing by drawing clear, bright lines. Even Horn's comment about creating a VP8 patent pool is couched in qualifiers and vague language: "there have been expressions of interest" and "we are looking into the prospects of doing so."

Of course, this is all really about HTML5 ... and money

Behind this entire fight is the availability of a free-to-implement video codec for HTML5. MPEG-LA and its pool members fought against Theora, and they will now do the same against VP8. Do not expect MPEG-LA to change its tune and support a completely free codec, ever; if it did the organization would have no reason to exist. MPEG-LA wants H.264 to win, not because it is better technically, but because it is their product.

Open source software is in a weird position in relation to MPEG-LA's licensing model. Even though it is the end users who infringe on the patents by watching H.264 content, the MPEG-LA requires anyone distributing codecs, like browser vendors, to pay for a license. That's just not possible for free software.

MPEG-LA has pushed back the date at which it will start charging royalty fees for streaming H.264 on the Internet until 2015, and even then there is a chance that they will push it back again. It does not explicitly care about the open source browser market itself; it has simply set up a fee structure that puts free software in an awkward position. The real money comes from video production and editing suites, and from large video hosting sites that transcode millions of videos.

Consequently, the real battle for VP8 adoption may be there as well. Google put out a long list of WebM-supporting partners when it unveiled the project, including several important proprietary software companies like creative-application-juggernaut Adobe and Quicktime's former star Sorenson. While MPEG-LA has more to lose than to gain by suing Google over VP8 today, that could change if these video production pipeline players start to shift over to WebM in a big way. If that happens, it might be the final straw which causes MPEG-LA to resort to the courtroom.

Comments (58 posted)

Page editor: Jonathan Corbet

Security

Redirecting browser tabs via "tabnabbing"

By Jake Edge
May 26, 2010

A new type of phishing vulnerability, which relies on users' expectations that browser tabs don't change once loaded, was recently reported by Aza Raskin, Mozilla's creative lead for Firefox. Dubbed "tabnabbing" (also tabjacking and tabnapping among others), the vulnerability is one that could potentially even catch those who are generally security-conscious because it exploits a common trend: having many open tabs and scanning for the "favicon" and title for a web page of interest. If an attacker can cause a tab to appear to be Gmail, for example, they may well be able to trick users into entering their credentials.

The technique used by tabnabbing is not particularly new, but Raskin has combined these techniques into a plausible attack. The basic idea is that a user navigates to an attacker-controlled site—or a site vulnerable to some form of cross-site scripting—and then switches away from that tab. The page has some code that detects when it loses focus and hasn't been used in a while. When it detects that, it switches the title, favicon, and contents of the page to something else entirely.

That "something else entirely" will be a phishing site—one that looks and acts exactly like a real site, but captures credentials, credit card numbers, or other sensitive information instead. Users are likely to choose that tab if they are looking for an open tab corresponding to the spoofed site. As Raskin puts it: "As the user scans their many open tabs, the favicon and title act as a strong visual cue—memory is malleable and moldable and the user will most likely simply think they left a Gmail tab open." The user is likely to just log in without thinking twice about it, and once that happens, the attacker's code can send the credentials off to their site and redirect the browser tab to the real Gmail.

One thing tabnabbing can't do is to spoof the browser address bar, so alert users may notice that their Gmail tab has a dodgy, non-Gmail address associated with it. But how many users actually look after switching to a tab that they half-expect to be open anyway? While spoofing valid addresses directly may not be possible, using Unicode domain names may be a way for the address to look legitimate, as Raskin notes.

Combining tabnabbing with the CSS browser history leak could produce a list of sensitive sites the user has visited—exactly those which might be phished successfully. It is a fairly insidious attack and one that works in all major browsers. Those who use the NoScript Firefox extension are not vulnerable to the standard attack, but they aren't completely invulnerable either.

Brian Krebs wrote about Raskin's report on his blog and noted that NoScript stopped tabnabbing. But in an update, he pointed to Aviv Raff's proof-of-concept that uses:

    <META HTTP-EQUIV="refresh" ...>
to change the contents of a tab after a timeout expires. That newly loaded page can have a different favicon and title, which replicates much of the standard attack.

NoScript author Giorgio Maone comments on Krebs's blog that he is considering adding functionality to NoScript to disallow tabs to refresh themselves from locations other than the current one. He also notes that Firefox has an option: "Advanced/[General/]Accessibility/Warn me when web sites try to redirect or reload the page" that can be enabled to combat this behavior.

For the future, Raskin points to Firefox Account Manager as a way to help protect users against this kind of attack. It will take a more active role in protecting users from logging into lookalike sites.

It is instructive to try out the demos, both at Raskin's and Raff's sites. Neither does anything actively harmful, but certainly give a good idea of how a phishing attack using the technique might work. Even the most wary might be caught by this one.

Comments (11 posted)

Brief items

Quotes of the week

TSA Officer: A beloved name from the blogosphere.

Me: And I always thought that I slipped through these lines anonymously.

TSA Officer: Don't worry. No one will notice. This isn't the sort of job that rewards competence, you know.

-- Bruce Schneier

Typically, adware authors install their software on as many machines as possible. But Typhoid adware comes from another person's computer and convinces other laptops to communicate with it and not the legitimate access point. Then the Typhoid adware automatically inserts advertisements in videos and web pages on the other computers. Meanwhile, the carrier sips her latté in peace — she sees no advertisements and doesn't know she is infected — just like symptomless Typhoid Mary.

-- ScienceDaily

Comments (2 posted)

New vulnerabilities

barnowl: arbitrary code execution

Package(s):barnowl CVE #(s):CVE-2010-0793
Created:May 24, 2010 Updated:May 26, 2010
Description: From the Debian advisory:

It has been discovered that barnowl, a curses-based tty Jabber, IRC, AIM and Zephyr client, is prone to a buffer overflow via its "CC:" handling, which could lead to the execution of arbitrary code.

Alerts:
Debian DSA-2049-1 2010-05-23

Comments (none posted)

cacti: SQL injection and cross-site scripting

Package(s):cacti CVE #(s):
Created:May 26, 2010 Updated:May 26, 2010
Description: Versions of cacti prior to 0.8.7f contain an SQL injection vulnerability, a cross-site scripting issue, and a second SQL injection problem.
Alerts:
Fedora FEDORA-2010-9036 2010-05-25
Fedora FEDORA-2010-9047 2010-05-25
Fedora FEDORA-2010-9062 2010-05-25

Comments (none posted)

dovecot: denial of service

Package(s):dovecot CVE #(s):CVE-2010-0745
Created:May 21, 2010 Updated:May 26, 2010
Description: From the Mandriva advisory:

Unspecified vulnerability in Dovecot 1.2.x before 1.2.11 allows remote attackers to cause a denial of service (CPU consumption) via long headers in an e-mail message.

Alerts:
Gentoo 201110-04 2011-10-10
Mandriva MDVSA-2010:104 2010-05-21

Comments (none posted)

ghostscript: arbitrary code execution

Package(s):ghostscript CVE #(s):CVE-2010-1869
Created:May 20, 2010 Updated:August 30, 2010
Description:

From the Mandriva advisory:

Stack-based buffer overflow in the parser function in GhostScript 8.70 and 8.64 allows context-dependent attackers to execute arbitrary code via a crafted PostScript file (CVE-2010-1869).

Alerts:
MeeGo MeeGo-SA-10:13 2010-08-03
SUSE SUSE-SR:2010:015 2010-08-17
SUSE SUSE-SR:2010:014 2010-08-02
openSUSE openSUSE-SU-2010:0425-2 2010-08-02
Debian DSA-2080-1 2010-08-01
openSUSE openSUSE-SU-2010:0425-1 2010-07-23
Ubuntu USN-961-1 2010-07-13
Mandriva MDVSA-2010:102 2010-05-19

Comments (none posted)

glibc: integer overflow

Package(s):glibc, eglibc CVE #(s):CVE-2008-1391
Created:May 26, 2010 Updated:October 28, 2010
Description: The GNU C library suffers from an integer overflow vulnerability, which, it is said, can be exploited to crash applications.
Alerts:
SUSE SUSE-SA:2010:052 2010-10-28
Mandriva MDVSA-2010:111 2010-06-08
Ubuntu USN-944-1 2010-05-25
Debian DSA-2058-1 2010-06-10
Mandriva MDVSA-2010:112 2010-06-08

Comments (none posted)

glibc: privilege escalation

Package(s):glibc, eglibc CVE #(s):CVE-2010-0296 CVE-2010-0830
Created:May 26, 2010 Updated:April 15, 2011
Description: The GNU C library suffers from two privilege escalation vulnerabilities: newline injection in the "mntent" function family, and an input validation problem related to ELF headers.
Alerts:
CentOS CESA-2011:0412 2011-04-14
Red Hat RHSA-2011:0412-01 2011-04-04
Gentoo 201011-01 2010-11-15
SUSE SUSE-SA:2010:052 2010-10-28
MeeGo MeeGo-SA-10:17 2010-08-03
Ubuntu USN-944-1 2010-05-25
Debian DSA-2058-1 2010-06-10
Mandriva MDVSA-2010:112 2010-06-08
Mandriva MDVSA-2010:111 2010-06-08
Pardus 2010-66 2010-06-04
Red Hat RHSA-2012:0126-01 2012-02-13
Red Hat RHSA-2012:0125-01 2012-02-13
CentOS CESA-2012:0125 2012-02-14
CentOS CESA-2012:0126 2012-02-14
Oracle ELSA-2012-0125 2012-02-14
Oracle ELSA-2012-0126 2012-02-14
Scientific Linux SL-glib-20120214 2012-02-14
Scientific Linux SL-glib-20120214 2012-02-14

Comments (none posted)

gnustep-base: multiple vulnerabilities

Package(s):gnustep-base CVE #(s):CVE-2010-1457 CVE-2010-1620
Created:May 21, 2010 Updated:May 26, 2010
Description: From the CVE entries:

Tools/gdomap.c in gdomap in GNUstep Base before 1.20.0 allows local users to read arbitrary files via a (1) -c or (2) -a option, which prints file contents in an error message. (CVE-2010-1457)

Integer overflow in the load_iface function in Tools/gdomap.c in gdomap in GNUstep Base before 1.20.0 might allow context-dependent attackers to execute arbitrary code via a (1) file or (2) socket that provides configuration data with many entries, leading to a heap-based buffer overflow. (CVE-2010-1620)

Alerts:
Fedora FEDORA-2010-8554 2010-05-15
Fedora FEDORA-2010-8575 2010-05-15

Comments (none posted)

html2ps: directory traversal

Package(s):html2ps CVE #(s):
Created:May 26, 2010 Updated:October 8, 2012
Description: The html2ps package suffers from a directory traversal vulnerability which could lead to arbitrary file content disclosure.
Alerts:
Fedora FEDORA-2010-7844 2010-05-04
Fedora FEDORA-2010-7803 2010-05-04
Mandriva MDVSA-2012:161 2012-10-06

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):kernel CVE #(s):CVE-2010-1162 CVE-2010-1173 CVE-2010-1187 CVE-2010-1437 CVE-2010-1446 CVE-2010-1451
Created:May 25, 2010 Updated:April 18, 2011
Description: From the Debian advisory:

CVE-2010-1162: Catalin Marinas reported an issue in the tty subsystem that allows local attackers to cause a kernel memory leak, possibly resulting in a denial of service.

CVE-2010-1173: Chris Guo from Nokia China and Jukka Taimisto and Olli Jarva from Codenomicon Ltd reported an issue in the SCTP subsystem that allows a remote attacker to cause a denial of service using a malformed init package.

CVE-2010-1187: Neil Hormon reported an issue in the TIPC subsystem. Local users can cause a denial of service by way of a NULL pointer dereference by sending datagrams through AF_TIPC before entering network mode.

CVE-2010-1437: Toshiyuki Okajima reported a race condition in the keyring subsystem. Local users can cause memory corruption via keyctl commands that access a keyring in the process of being deleted, resulting in a denial of service.

CVE-2010-1446: Wufei reported an issue with kgdb on the PowerPC architecture, allowing local users to write to kernel memory. Note: this issue does not affect binary kernels provided by Debian. The fix is provided for the benefit of users who build their own kernels from Debian source.

CVE-2010-1451: Brad Spengler reported an issue on the SPARC architecture that allows local users to execute non-executable pages.

Alerts:
SUSE SUSE-SA:2011:017 2011-04-18
openSUSE openSUSE-SU-2011:0346-1 2011-04-18
SUSE SUSE-SA:2011:015 2011-03-24
openSUSE openSUSE-SU-2010:0664-1 2010-09-23
Mandriva MDVSA-2010:188 2010-09-23
MeeGo MeeGo-SA-10:15 2010-08-03
CentOS CESA-2010:0474 2010-08-27
CentOS CESA-2010:0474 2010-08-23
Red Hat RHSA-2010:0631-01 2010-08-17
Ubuntu USN-966-1 2010-08-04
Mandriva MDVSA-2010:198 2010-10-07
Red Hat RHSA-2010:0474-01 2010-06-15
Fedora FEDORA-2010-9183 2010-05-28
Debian DSA-2053-1 2010-05-25
MeeGo MeeGo-SA-10:01 2010-07-07
openSUSE openSUSE-SU-2010:0397-1 2010-07-19
CentOS CESA-2010:0504 2010-07-02
SuSE SUSE-SA:2010:027 2010-07-02
Pardus 2010-64 2010-06-04
SUSE SUSE-SA:2010:031 2010-07-20
Red Hat RHSA-2010:0504-01 2010-07-01
Fedora FEDORA-2010-9209 2010-05-28
Ubuntu USN-947-2 2010-06-04
Ubuntu USN-947-1 2010-06-03

Comments (none posted)

kolab-horde-framework: unspecified vulnerability

Package(s):kolab-horde-framework CVE #(s):CVE-2009-4824
Created:May 26, 2010 Updated:May 26, 2010
Description: From the singularly unhelpful CVE entry: Unspecified vulnerability in Kolab Webclient before 1.2.0 in Kolab Server before 2.2.3 allows attackers to have an unspecified impact via vectors related to an "image upload form."
Alerts:
Mandriva MDVSA-2010:108 2010-05-26

Comments (none posted)

moin: access control bypass

Package(s):moin CVE #(s):CVE-2009-4762
Created:May 20, 2010 Updated:May 26, 2010
Description:

From the Ubuntu advisory:

It was discovered that MoinMoin incorrectly handled hierarchical access control lists. Users could bypass intended access controls under certain circumstances.

Alerts:
Ubuntu USN-941-1 2010-05-20

Comments (none posted)

mysql: multiple vulnerabilities

Package(s):mysql CVE #(s):CVE-2010-1848 CVE-2010-1849 CVE-2010-1850
Created:May 26, 2010 Updated:November 16, 2010
Description: MySQL suffers from an authentication bypass vulnerability (CVE-2010-1848), a denial of service problem (CVE-2010-1849), and a vulnerability to code injection by an authenticated user (CVE-2010-1850).
Alerts:
SUSE SUSE-SR:2010:021 2010-11-16
CentOS CESA-2010:0824 2010-11-05
Red Hat RHSA-2010:0824-01 2010-11-03
SUSE SUSE-SR:2010:019 2010-10-25
openSUSE openSUSE-SU-2010:0731-1 2010-10-18
openSUSE openSUSE-SU-2010:0730-1 2010-10-18
Ubuntu USN-950-1 2010-06-09
CentOS CESA-2010:0442 2010-05-28
Fedora FEDORA-2010-9053 2010-05-25
Red Hat RHSA-2010:0442-01 2010-05-26
Mandriva MDVSA-2010:107 2010-05-25
Fedora FEDORA-2010-9061 2010-05-25
Fedora FEDORA-2010-9016 2010-05-25
Debian DSA-2057-1 2010-06-07
Gentoo 201201-02 2012-01-05
Ubuntu USN-1397-1 2012-03-12

Comments (none posted)

openssl: information disclosure

Package(s):openssl CVE #(s):
Created:May 24, 2010 Updated:May 26, 2010
Description: From the rPath advisory:

A flaw in previous versions of OpenSSL could allow a malicious client to force a ciphersuite not supported by the server to be used for a session between the client and the server, which can result in disclosure of sensitive information.

Alerts:
rPath rPSA-2010-0039-1 2010-05-23

Comments (none posted)

postgresql: denial of service

Package(s):postgresql CVE #(s):CVE-2010-0733
Created:May 24, 2010 Updated:August 2, 2010
Description: From the Red Hat advisory:

An integer overflow flaw was found in the way PostgreSQL used to calculate the size of the hash table for joined relations. An authenticated database user could create a specially-crafted SQL query which could cause a temporary denial of service (postgres daemon crash) or, potentially, execute arbitrary code with the privileges of the database server.

Alerts:
Gentoo 201110-22 2011-10-25
SUSE SUSE-SR:2010:014 2010-08-02
CentOS CESA-2010:0429 2010-05-28
CentOS CESA-2010:0428 2010-05-22
CentOS CESA-2010:0427 2010-05-22
openSUSE openSUSE-SU-2010:0371-1 2010-07-14

Comments (none posted)

postgresql: privilege escalation

Package(s):postgresql CVE #(s):CVE-2010-1975
Created:May 21, 2010 Updated:August 2, 2010
Description: From the CVE entry:

PostgreSQL 7.4 before 7.4.29, 8.0 before 8.0.25, 8.1 before 8.1.21, 8.2 before 8.2.17, 8.3 before 8.3.11, and 8.4 before 8.4.4 does not properly check privileges during certain RESET ALL operations, which allows remote authenticated users to remove arbitrary parameter settings via a (1) ALTER USER or (2) ALTER DATABASE statement.

Alerts:
Gentoo 201110-22 2011-10-25
SUSE SUSE-SR:2010:014 2010-08-02
Pardus 2010-74 2010-06-04
Debian DSA-2051-1 2010-05-24
Mandriva MDVSA-2010:103 2010-05-20
openSUSE openSUSE-SU-2010:0371-1 2010-07-14

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The 2.6.35 merge window is still open, so there is no development kernel release as of this writing. See the separate article below for a summary of the merge window to date.

Stable updates: the 2.6.27.47, 2.6.32.14, and 2.6.33.5 stable updates were released on May 26. Note that there's only likely to be one more 2.6.33 update before support for that kernel stops.

Comments (none posted)

Quotes of the week

I tried to measure this to show that you were wrong, but I was only able to show that you're right. How annoying.
-- Rusty Russell

The whole API feels wrong to me. It's breaking rule #1 of technology "You cannot solve a social problem with technology". In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying "App XYZ is using all your battery" and red-amber-green powermeter scores in app stores.
-- Alan Cox

Comments (3 posted)

Slab reduction

By Jonathan Corbet
May 26, 2010
LWN took a brief look at the new SLEB memory allocator last week. Since then, Christoph Lameter has posted a second revision of the patch, but subsequent discussion suggests that SLEB is not likely to find its way into the mainline.

The main detractor at the outset was Nick Piggin, author of the unmerged SLQB allocator. Nick saw SLEB as a step forward from SLUB, which he suggests should never have been merged:

I don't think SLUB ever proved itself very well. The selling points were some untestable handwaving about how queueing is bad and jitter is bad, ignoring the fact that queues could be shortened and periodic reaping disabled at runtime with SLAB style of allocator. It also has relied heavily on higher order allocations which put great strain on hugepage allocations and page reclaim (witness the big slowdown in low memory conditions when tmpfs was using higher order allocations via SLUB).

What Nick would like to see at this point is not another in-kernel slab allocator (not even SLQB), but, instead, an effort to improve slab itself, which, he says, is already pretty close to optimal. And, regardless, Linus has made it clear that he's not interested in merging more allocators:

I'm not going to merge YASA that will stay around for years, not improve on anything, and will just mean that there are some bugs that developers don't see because they depend on some subtle interaction with the sl*b allocator.

Nick's plan is to start by cleaning up the slab allocator to make the code more approachable than it is now. Then, any performance problems can be carefully fixed up, with an emphasis on not causing performance regressions elsewhere. Over time, he says, we should get farther with a single allocator that is used (and tested) by everybody than by ripping out code with a long development history and replacing it with something new and untried.

Comments (none posted)

Suspend blocker suspense

By Jonathan Corbet
May 26, 2010
As of last week's article on the Android suspend blocker mechanism, the conversation appeared to be slowing down. Such blessings, it seems, are never permanent; many electrons have been perturbed to continue this discussion since then. The end result is that the late entrance into the discussion by people with names like Alan Cox, Thomas Gleixner, and Peter Zijlstra has made the merging of this feature more unlikely.

Alan's dissent was arguably the most coherent and constructive of just about any that have been posted thus far. He thinks that the problem being addressed by suspend blockers (misbehaving applications) is real, but the solution is wrong. He suggests, instead, the addition of a setpidle() system call which indicates the extent to which a process can prevent the system from going into an idle state. If the process is running an untrusted application, the system would be able to go idle (or suspend) even if that process is runnable at the time. More trusted processes (the ones which would be able to use suspend blockers in the Android scheme) would have a higher priority and would be able to run at any time.

The other piece of the solution, according to Alan, is to put pressure on the authors of badly-written applications. Thomas agrees:

We have already proven that the social pressure on crappy applications works. When NOHZ was merged into the kernel we got no effect at all because a big percentage of user space applications just used timers at will and without any thoughts, also it unveiled busy polling and other horrible coding constructs. So what happened ? Arjan created powertop which lets the user analyse the worst offenders in his system. As a result the offending apps got fixed rapidly simply because no maintainer wanted to be on top of the powertop sh*tlist.

A number of developers have expressed the fear that trying to mitigate the impact of badly-written applications in the kernel will only serve to take the pressure off developers, leading to more bad applications over time.

Meanwhile, Rafael Wysocki has sent a pull request for suspend blockers to Linus, saying:

Some alternative approaches have been proposed during the on-going discussion, but they are general ideas rather than specific technical propositions, and until someone actually tries to implement them it's not really known whether or not they are suitable for Android. For this reason I don't think we can realistically expect Google to implement any of them. Thus, in my view, we have a choice to either accept or reject this feature altogether.

As of this writing, Linus has not said what he intends to do. Given the way the conversation has gone, though, it would not be surprising to see the merge window end with no suspend blockers in the mainline. Merging a user-visible feature like suspend blockers is a move which cannot be undone after the 2.6.35 release; when there is this much disagreement, letting another development cycle go by may seem like the prudent thing to do.

Comments (7 posted)

Kernel development news

2.6.35 merge window part 2

By Jonathan Corbet
May 26, 2010
Much code - some 6300 non-merge changesets - has gone into the mainline kernel since last week's article. Listing all of the changes would be an impossible task, even for the KernelNewbies folks who seem to get close, but an overview can be given. The most interesting user-visible changes are:

  • The receive packet steering and receive flow steering mechanisms have been added to the networking subsystem.

  • The memory compaction patch set has been merged. This should lead to less memory fragmentation and higher success rates for large allocations.

  • A loophole which would, in some circumstances, allow a security module to be registered at runtime has been closed; security modules must be present at boot time.

  • The network traffic control subsystem is now namespace-aware.

  • The "Communication CPU to Application CPU Interface" (CAIF) protocol, used to speak with ST-Ericsson modems, is now supported in the network stack. Also supported in version 3 of the Layer Two Tunneling Protocol (L2TP - RFC 3931).

  • "FunctionFS" is a mechanism by which user-space USB drivers can create USB gadgets with composite functionality. The "f_uvc" driver builds on this feature to create a video capture device driven by data from user space.

  • There is now support for the "restricted access regions" mechanism built into Intel "Moorestown" processors. RAR can be used to block devices (including processors) out of specific regions of memory.

  • The cpuidle "menu" governor now features idle pattern detection which tries to be smarter about sleep-state selection based on recent system history.

  • The slab allocator has gained memory hotplug support.

  • Extended attributes are now supported in the squashfs filesystem.

  • The size of the in-kernel buffer used to hold data for a pipe can be queried with the new F_GETPIPE_SZ fcntl() command, and changed with F_SETPIPE_SZ. As of this writing, the units used by this command are page-sized buffers, but that will almost certainly change to bytes in the near future.

  • Lots of new drivers:

    • Input: Analog Devices AD714x capacitance touch sensors, Hampshire serial touchscreens, TI TCA6416 keypads, Cando dual touch panels, Minibox PicoLCD devices, Prodikeys PC-MIDI Keyboard devices, and Roccat Kone mice.

    • Network: Atheros HTC based wireless cards, USB-connected Agere Orinoco wireless cards, and SBE wanPMC-C[421]E1T1 WAN adapters. The ath5k driver has also gained adaptive noise immunity support, a feature which is said to nearly double throughput in noisy situations.

    • Sound: USB Audio Class v2.0 compliant devices, Wolfson Micro WM1133-EV1 on i.MX31ADS systems, Wolfson Micro WM9090 amplifiers, TI TWL6040 codecs, Texas Instruments SDP4430 audio devices, Zipit Z2 WM8750 audio devices, and AudioScience ASI sound cards.

    • Storage: devices with the SmartMedia/xd flash translation layer, Ricoh R5C852 xD card readers, MPC5121 built-in NAND flash controllers, Denali NAND controller on Intel Moorestown systems, Samsung OneNAND controllers, and QLogic PCIe QLE InfiniBand host channel adapters.

    • Systems and processors: much of the support code for the ARM "MSM" architecture, as found in the G1/ADP1 handset, has been merged. Additionally: OMAP3 SBC STALKER boards and PowerPC 476 processors.

    • Video4Linux: Trident TV Master tm5600/tm6000 chips, SuperH VOU video output devices, AK8813/AK8814 video encoders and DataTranslation DT3155 frame grabbers.

    • Miscellaneous: RDMA and iWARP on Chelsio T4 1GbE and 10GbE adapters, viafb-based i2c and GPIO devices, SuperH IrDA devices, Altera UARTs, GSM MUX line discipline support (in the TTY layer), Niagara2 stream processing units, ACX565AKM (Nokia N900) panels, Analog Devices ADIS16255 low power gyroscopes, Analog Devices ADIS16300 and ADIS16400/5 inertial sensors, Analog Devices ADIS16240 programmable impact sensors, Analog Devices ADIS16260/5 digital gyroscope sensors, Analog Devices ADIS16209 dual-axis digital inclinometer and accelerometer devices, Timberdale FPGA DMA engines, ST-Ericsson DMA40 DMA controllers, Texas Instruments ADS7871 A/D converters, Freescale IMX2 hardware watchdogs, Freescale MPC512x PSC SPI controllers, and Cirrus EP93xx SPI controllers.

      Additionally, "g_hid" is a USB gadget driver implementing the human interface device class specification, g_webcam is a gadget-side USB video device, and g_ffs allows the creation of USB composite functions.

Changes visible to kernel developers include:

  • There is a new variant of request_irq():

        request_any_context_irq(unsigned int irq, irq_handler_t handler,
    			    unsigned long flags, const char *name, 
    			    void *dev_id);
    

    This function connects the interrupt handler in the usual way. The difference is that it looks at how the interrupt line itself was set up (by architecture-specific code) and decides whether to establish a traditional hard interrupt handler or a threaded handler. The return value on success is either IRQC_IS_HARDIRQ or IRQC_IS_NESTED.

  • Also related to request_irq(): the IRQF_DISABLED flag now does nothing; it will be removed entirely in 2.6.36. All interrupt handlers are now called with interrupts disabled; see this article for details on the change.

  • The timer slack mechanism has been merged. Timer slack (which applies to old-style timers, not hrtimers) allows the system to defer timer expiration by a bounded amount in order to get timers to expire at the same time, thus minimizing system wakeups.

  • The new function ktime_to_ms() converts a kernel time value to milliseconds.

  • A number of unused security module hooks (task_setuid, sb_post_remount, sb_post_pivotroot, sb_umount_close, acct, inode_delete, sb_umount_busy, task_setgid, task_setgroups, sb_post_addmount, cred_commit, and key_session_to_parent) have been removed.

  • The power management quality of service (pm_qos) system API has been significantly changed; see this article for details.

  • "Tagged directory support" has been added to sysfs. This feature allows namespace-specific tags to be added to sysfs directories; these tags then control which version of a directory (if any) is visible within any given namespace.

  • kref_set() has been removed after a determination that none of its three users were correct.

  • The read(), write() and mmap() methods in struct bin_attribute have gained a new struct file pointer argument.

  • The "kdb" low-level kernel debugger has been joined with kgdb and merged into the mainline.

  • The checkpatch script will now complain if kernel configuration options are added with fewer than four lines of help text.

  • There is a bunch of new infrastructure in the Video4Linux2 subsystem, including a framework for supporting memory-to-memory devices (video processing engines), a mechanism for reporting asynchronous events to user space, and a new core subsystem for infrared controllers.

In a normal merge window, changes would continue to flow into the mainline until the end of the month. Linus has made it clear that he no longer guarantees "normal" merge windows, though, so the window could close sooner than that. Regardless, tune in next week for a summary of the final changes to be merged for 2.6.35.

Comments (1 posted)

2.6.35 Video4Linux2 enhancements

By Jonathan Corbet
May 25, 2010
The 2.6.35 development cycle has been a busy one for the Video4Linux2 subsystem, with quite a bit of new infrastructure and some new drivers merged. This article will provide an overview of some of the new capabilities in V4L2.

Memory-to-memory devices

Video hardware often includes subsystems which are capable of processing video streams in various ways. The VIA chipset that your editor has recently been working with, for example, has a "high quality video" (HQV) engine which can be used to change video formats, rotate frames, convert between color spaces, perform deinterlacing, and more. It is not uncommon for video drivers to make use of an engine like this to make a wider range of formats and options available to applications. When used in this mode, the processing engine is hidden from user space; it looks like a part of the video input or output device.

But there can be value in making the video processing engine available as a device in its own right; applications will then be able to use it to accelerate operations on video data. The kernel has made other data-transformation engines available through various interfaces, the "dmaengine" API in particular. Simple DMA engines can move data around and possibly perform a transformation - exclusive-or with a value, for example. More complex engines can perform cryptographic transformations, and, indeed, are used for this purpose within the kernel's cryptographic code.

The dmaengine API has not been used for video processing engines, though. Your editor has not been told the reasons for that decision, but there are a couple of obvious guesses, starting with the fact that video engines might, in fact, not do DMA. For example, the VIA HQV engine requires that the relevant data be present in framebuffer memory. Perhaps more telling, though, is the complexity of the transformations which might be performed. Video data streams have an appalling number of formats and parameters; it takes a fairly complex API to allow applications to describe the sort of stream they want to deal with. Such an API could certainly be created for a new video processing facility, but that API already exists in the form of the V4L2 specification. It makes far more sense to reuse that API than to try to create it anew. Reusing the API happens naturally if the video processing engine looks like a V4L2 device in its own right.

So the new memory-to-memory (m2m) infrastructure is designed to enable the creation of V4L2 devices which move video frames from one memory buffer to another, performing some sort of transformation on the way. Frames are fed to the device as if it were an ordinary video output device, with all of the appropriate configuration done to describe the format of those frames. The video input side is, instead, configured with the format the application would like to have. The driver takes frames written to the device by applications, runs them through the processing engine, then makes them available for reading as if it were an ordinary video capture device.

The m2m API will only be discussed in the most superficial way here; see <media/v4l2-mem2mem.h> for more details. Drivers start by defining a set of callbacks:

    struct v4l2_m2m_ops {
	void (*device_run)(void *priv);
	int (*job_ready)(void *priv);
	void (*job_abort)(void *priv);
    };

The device_run() callback will be called when there is work for the engine to do; job_abort(), instead, is called when the engine must be stopped as quickly as possible. The optional job_ready() function should return a nonzero if the driver could currently start a job without sleeping.

The callbacks are registered with:

    struct v4l2_m2m_dev *v4l2_m2m_init(struct v4l2_m2m_ops *m2m_ops);

When the device is opened, the driver should make a call to:

    struct v4l2_m2m_ctx *v4l2_m2m_ctx_init(void *priv, 
                        struct v4l2_m2m_dev *m2m_dev,
			void (*vq_init)(void *priv, struct videobuf_queue *,
					enum v4l2_buf_type));

The priv value will be passed through to the above-described callbacks. Two calls to vq_init() will be made, one each for the input and output buffer queues; vq_init() should, in turn, make a call to the appropriate videobuf initialization function.

There is a whole set of helper functions meant to be used to implement many of the V4L2 operations: v4l2_m2m_reqbufs(), v4l2_m2m_qbuf(), v4l2_m2m_streamon(), v4l2_m2m_mmap(), etc. They handle most of the heavy lifting of implementing a memory-to-memory driver, calling the device_run() callback when there is work to do and buffers are available. As the driver fills buffers with processed frames and passes them back to the videobuf system, they will, in turn, be handed back to the application.

Once again, most of the details have been glossed over, but that's the core of what this API does. As of this writing, there are no drivers for real hardware using this API in the mainline, though some have been posted for review. A sample user can be seen in drivers/media/video/mem2mem_testdev.c.

Events

The V4L2 API is dominated by the description of video streams and the actual movement of frames. There are other things of interest, though, which may happen in an asynchronous manner. To support the passing of asynchronous events to user space, a new set of events operations has been added. The initial use of this code is to allow applications to request notification for vertical sync events or the loss of the video stream.

At the user-space API level, there are a few additions to the seemingly endless list of V4L2 ioctl() commands: VIDIOC_SUBSCRIBE_EVENT, VIDIOC_UNSUBSCRIBE_EVENT, and VIDIOC_DQEVENT. Once an application has subscribed to one or more events, it can learn about them in the usual ways, including signals and poll(); a VIDIOC_DQEVENT call allows the application to see what actually happened.

Within the kernel, the event API starts with a new mechanism for the management of file handles associated with a device. Each new open file must be set up with:

    #include <media/v4l2-fh.h>

    int v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev);
    void v4l2_fh_add(struct v4l2_fh *fh);

That sets up the connections which allow V4L2 drivers to associate things (like events) with specific open files.

A driver which supports events should start with a call to:

    #include <media/v4l2-event.h>

    int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n);

This call will try to ensure that storage is available for at least n events on this file handle. Actual events are signaled with:

    struct v4l2_event {
	__u32				type;
	union {
		struct v4l2_event_vsync vsync;
		__u8			data[64];
	} u;
	/* ... */
    };

    void v4l2_event_queue(struct video_device *vdev, 
                          const struct v4l2_event *ev);

In addition, there is the usual set of helper functions (v4l2_event_dequeue(), v4l2_event_subscribe(), ...) meant to be called from the driver's V4L2 callbacks.

Currently, events are only supported by the IVTV driver, so that is the place to look for a usage example.

The infrared core

Back in December, LWN looked at the state of infrared receiver drivers in the kernel - or, in the case of the long out-of-tree LIRC subsystem, out of the kernel. That discussion has long since died down, but the hacking did not stop. The result is that, with 2.6.35, the V4L2 subsystem has a new framework for IR receivers. There is support for a number of controllers at this point. The IR core also includes an interface where drivers (or user space) can feed simple "mark" or "space" timing information which is then decoded in software; that should make it possible to hook a number of user-space LIRC drivers into the system.

Documentation on the new IR core is sparse; basic kernel API information can be found in include/media/ir-core.h and ir-common.h.

In conclusion

It has been a busy merge window for one of the most active subsystems in the kernel. Over the last few years, the V4L2 subsystem has built up an impressive amount of infrastructure and has reached the point where it supports almost all of the available hardware. That said, there is still quite a bit of work in progress; traffic on the mailing list is concerned with multi-plane video buffer support, a new control framework, and more. So future merge windows are likely to be busy in this part of the tree as well.

Comments (none posted)

One ring buffer to rule them all?

By Jake Edge
May 26, 2010

One of the outcomes from the Collaboration Summit in April was a plan to create a tracing ring buffer implementation that would work for both Ftrace and LTTng. There was also hope that perhaps the separate ring buffer added for perf could be folded in as well, so that the vision of a single ring buffer implementation in the kernel—from the 2008 Kernel Summit and Linux Plumbers Conference—could come to fruition. To that end, Steven Rostedt posted an RFC for a unified ring buffer, but before that conversation could really get going, it was diverted. It seems that Ingo Molnar thinks there are much bigger issues to resolve in the world of Linux tracing.

A ring buffer is a circular data structure that is often used to hold data that is produced and consumed by separate processes without synchronization. For tracing, the data is produced by the kernel outside of any specific process's context, but the consumer is in user space. The kernel needs to hand out pages from the head of the ring buffer to user space for consumption, while ensuring that it doesn't overwrite that data as it writes to the tail of the buffer.

In his RFC, Rostedt recounts the history of tracing ring buffers, noting that the Ftrace ring buffer did not become lockless until after perf came along. Since perf needed to be able to record events in non-maskable interrupt (NMI) contexts, it couldn't use the Ftrace ring buffer; instead, it used one of its own, written by Peter Zijlstra. Eventually, Rostedt changed the Ftrace ring buffer to be lockless, but at that point, it was too late for perf. In addition, the perf ring buffer allows user space to mmap() its pages, while the Ftrace ring buffer was geared to in-kernel users and splice().

So the kernel already has two tracing ring buffers, but there is also an out-of-tree ring buffer to consider, which is the one used by LTTng. That ring buffer has seen a lot of use in production Linux shops as well as being integrated into various embedded Linux distributions. In addition, much as was done with RCU, LTTng project lead Mathieu Desnoyers did a formal proof of the correctness of that ring buffer algorithm.

At the Collaboration Summit, there was a belief that the LTTng ring buffer could be extended to support all of the Ftrace use cases. It would seem that since then, Desnoyers has come up with ways to support the perf ring buffer use cases as well. Both Rostedt and Desnoyers would like to nail down all of the requirements for (at least) tracing ring buffers and put together a single implementation that works for all of them. Desnoyers has put together a git tree that includes a bare bones ring buffer as a starting point.

But Andi Kleen is not convinced of the need for a unified ring buffer, at least one that encompasses other non-tracing uses. The Ftrace ring buffer is very complex and "too clever"; plenty of other subsystems use kfifo:

In fact there are far more users of it than of your ring buffer. And it's really quite simple and easy to use. And it works fine for them.

He goes on to ask "If perf's current ring buffer works for it why not keep using it?". Rostedt more or less agrees with the complexity argument, but notes that there tends to be a misconception when people first look at the problem:

You also bring up a point that I try very hard to get across. When people think of a ring buffer, they think of the ones that they created in CS101, not realizing that when you are dealing with production systems, handling the requirements makes the buffering much more complex.

Desnoyers also points out that tracing has some requirements that other ring buffer users may not have:

One requirement seems to be shared for most tracing heavy users: it has to be blazingly fast. This is a requirement that is commonly overlooked by the "very simple" implementations.

There are advantages to sharing a ring buffer implementation among the different tracing solutions beyond just fulfilling Linus Torvalds's mandate from the 2008 Kernel Summit. High-performance ring buffer implementations tend to be more complex than standard code according to Desnoyers, "so it's good if we can focus our review efforts on a single ring buffer". In addition, if there is a common implementation, any performance tweaks will help all of its users.

There is another underlying reason for a single ring buffer, though. Molnar would like to see Ftrace phased out, with its functionality moved into perf. Rostedt is not necessarily opposed, but in order to do that, there needs to be some ring buffer implementation that supports both. The question is: how to get there?

Rather than directly commenting on the idea of a unified ring buffer itself, Molnar posted a request for discussion on "Future tracing/instrumentation directions". In it, he makes the case for moving Ftrace functionality to perf and suggests that Rostedt and Desnoyers help Zijlstra with "performance and simplification work" of the perf ring buffer:

[...] The last thing we need is yet another replace-everything event.

If we really want to create a new ring buffer abstraction i'd suggest we start with Peter's, it has a quite sane design and stayed simple and flexible [...]

Molnar believes that the performance of the current ring buffers "sucks, in a big way. I've recently benchmarked it and it takes hundreds of instructions to trace a single event". He also thinks that the current "ftrace/perf duality" is hurting developers and users. One of the main things he would like to eliminate is the debugfs interface for Ftrace, but that will take some time:

The main detail here to be careful of is that lots of people are fond of the simplicity of the /debug/tracing/ debug UI, so when we replace it we want to do it by keeping that simple workflow (or best by making it even simpler). I have a few ideas how to do this.

There's also the detail that in some cases we want to print events in the kernel in a human readable way: for example EDAC/MCE and other critical events, trace-on-oops, etc. This too can be solved.

Thomas Gleixner and Ted Ts'o both spoke up in favor of the kernel events and tracepoints being discoverable from user space. Currently, that is well-supported by Ftrace using its debugfs interface, and both would like to see that continue. Gleixner wants simple tracing tools for embedded devices—eventually made a part of BusyBox—that don't have to change when new tracepoints or events are added. Ts'o on the other hand wants to be able to have bash-completion scripts that can figure out tracepoint names. Molnar agreed that it is important to maintain that ability going forward.

There is some debate about how badly the Ftrace ring buffer performs. Molnar is quite critical of its performance, but Rostedt disputes some of those findings. In the end, there doesn't seem to be much disagreement that a better performing ring buffer could be created, there is just a question of how it should be approached.

Rostedt does not think that starting with the perf ring buffer is the right approach: "The current ring buffer in perf is very coupled with the perf design." Molnar, though, is leery of bringing yet another ring buffer implementation into the picture:

We've got two ring buffer implementations right now, one has to be replaced.

It doesnt mean we should disrupt _two_ implementations and put in a third one, unless there are strong technical reasons for doing so.

Those strong technical reasons may be found in the performance numbers for the various implementations. If Rostedt and Desnoyers can produce a ring buffer that works for Ftrace and perf, while performing better than either existing implementation, it seems likely that it would find a clear path into the kernel. As the discussion has trailed off, one gets the sense that the participants are now benchmarking and tweaking their implementations to try to achieve that.

The ring buffer implementation is at the heart of any Linux tracing solution; its capabilities and performance will largely dictate how intrusive tracing is on the rest of the system, which in turn impacts how useful the tracing output is. The fact that several smart developers have yet to come up with a super-low-impact solution speaks volumes about the difficulty of the problem. With all of the work that is currently going on, though, it seems likely that one way or another a high-performance ring buffer—with lower overall complexity—will come about.

Another interesting outcome from this discussion, short though it may have been, is that we are likely to see Ftrace fade away over time. The functionality won't disappear, it and much of the Ftrace code would be moved into perf, but Ftrace itself—which really started the (relatively) recent mainline tracing push—might well be gone sometime in the next few kernel development cycles.

Comments (1 posted)

Patches and updates

Kernel trees

Core kernel code

Development tools

Device drivers

Documentation

Filesystems and block I/O

Memory management

Architecture-specific

Virtualization and containers

Miscellaneous

Page editor: Jonathan Corbet

Distributions

News and Editorials

De-bashing Debian

By Jake Edge
May 26, 2010

A report that a thousand or more Debian packages will no longer build from source would be a cause for concern at any time, but when the project is trying to button up for a release, it is especially unwelcome. It turns out that the initial estimates were overblown, but that a change in the dash shell to make it POSIX-compliant, exposed a number of "bash-isms" that had crept into the Debian build scripts. In the process of tracking things down, various problems with checkbashisms were found as well.

As reported to debian-devel by Raphael Geissert, the dash shell recently changed:

dash recently added support for the magic variable $LINENO, which was the last piece to make it POSIX compliant. However, this change made the autoconf-generated configure scripts use dash to execute the script's code. Without support for LINENO, configure scripts exec to bash automatically.

That caused multiple Debian packages to "fail to build from source" (FTBFS). Geissert's estimate for the number of packages affected was a rather eye-opening 1504. That led Petter Reinholdtsen to ask:

What about reverting this change in dash until after Squeeze is released? Now [seems] like a bad time to make thousand of packages in Debian fail to build from source. :)

Several folks pointed him at the bug report, where that plan was being put into action. The newer dash was put into the experimental release tree, while the unstable—eventual Squeeze—tree got a dash without the POSIX upgrade.

The original move to dash was done for performance and POSIX-compliance reasons. At the time, it broke various things because scripts that specified /bin/sh were really written to run with bash and did not conform to the POSIX shell standard. The checkbashisms script was developed to help find these problems so that they could be fixed. Unfortunately, as the Debian folks just found, checkbashisms produces a lot of false positives as well as some false negatives.

As it turns out, building the archive with both the old and the new dash yielded a list of "only" 124 packages that failed to build. Still a concern, but not one that merited the outcry that the first message elicited. Neil Williams was rather annoyed both at the dash change and the original report: "(I've heard of off-by-one errors but off-by-one-order-of-magnitude is a stretch.) [...] Please, let's get some accurate figures before raising things like this." But as David Weinhall points out, the underlying problem is not with dash at all:

You're getting things the wrong way around. The version of dash that will be put in experimental will be the correct one, the one in unstable will be the crippled one. The reason things [fail] isn't because of dash, but because of sloppy programming on behalf of people that still believe that bash is the say all and end all when it comes to shell scripts.

But Lucas Nussbaum, who ran the comparative archive builds, wondered about the whole exercise of removing bash-isms from the Debian build scripts. He is concerned that a lot of work is being done for POSIX-compliance which "only a minority of users care" about and to shave a few seconds from boot time.

Was is really the right path to follow? Wouldn't it have been easier to work on bash to make sure that it supports everything POSIX requires, and to improve its performance a bit?

Now we are going to patch configure scripts to make sure that they can run correctly with dash. What's next? Rewrite C programs that use GCC-specific extensions?

There is quite a list of commonly used bash-isms on the page about the dash move linked above. For good or ill, bash is the shell that many folks use and test under. The fact that it will happily run /bin/sh scripts that have used bash extensions is perhaps unfortunate in some ways, but it's also something that isn't going to change. In order for Debian to stay dash-pure, it will require an ongoing effort to patch the build scripts that come from upstream. It may be that there are better uses of Debian developers' time.

Comments (24 posted)

New Releases

CyanogenMod 5 for the G1/ADP1

The CyanogenMod hackers have announced the availability of CyanogenMod 5.0.7 for "Dream" and "Magic"-series phones. This release makes Android 2.1 available for these handsets, along with a long list of additional features. "There is some new ground being broken here, and a few bugs to still shake out but I believe that it should be pretty stable as a daily driver."

Comments (24 posted)

Debian GNU/Linux 4.0 updated

The Debian project has announced the ninth and final update of its oldstable distribution Debian GNU/Linux 4.0 (codename etch). "This update incorporates all security updates which have been released for the oldstable release since the previous point release, with one exception which it was unfortunately not possible to include, together with a few adjustments to serious problems."

Comments (none posted)

Fedora 13 released

The Fedora 13 release is out. "Fedora is a leading edge, free and open source operating system that continues to deliver innovative features to many users, with a new release about every six months. We bring to you the latest and greatest release of Fedora ever, Fedora 13!" The list of new features is quite long; click below for the details.

Full Story (comments: 6)

Community Fedora Remix 13.1 "Lucky 13"

Community Fedora Remix 13.1 "Lucky 13" is available. "There are two basic guiding principle behind this Fedora Remix, first one is "beyond upstream" and "multimedia out of the box", you can also think of it like Pimp My Ride version of Fedora"

Comments (none posted)

Announcing Sugar on a Stick v.3 (Mirabelle)

Sugar on a Stick v.3, code-named Mirabelle, is available. Sugar on a Stick has been accepted as an official Fedora Spin. "Changes in Sugar on a Stick since the last release (v.2 Blueberry): Sugar version 0.88. The most recent release of the Sugar Learning Platform features support for 3G connections, increased accessibility, and better integration with our Activity Portal (http://activities.sugarlabs.org) allowing students and teachers to update their sticks with additional Activities."

Full Story (comments: none)

Mandriva Linux 2010 Spring RC

Mandriva has announced the last development release for Mandriva 2010.1. See the release notes for detailed information.

Comments (none posted)

MeeGo v1.0 core software platform released

The 1.0 release of the MeeGo "core software platform" has been announced; also available is the "Netbook User Experience" code. There is a handset user experience in the works as well; it will be released in June. "We are now releasing the MeeGo API which includes Qt 4.6, the MeeGo SDK with an integrated application development environment, and various other operating system tools. Currently, the MeeGo SDK is focused on Netbooks, but the next version of the MeeGo SDK, an early developer release in June, will support touch-based devices, such as Handsets and Tablets."

Comments (3 posted)

openSUSE 11.3 Milestone 7: Preparing for RC Phase

The seventh and last milestone release of openSUSE 11.3 is available for testing. "Compared to M6, this milestone brings many bug fixes, an update to Linux kernel 2.6.34 and the integration of software translations and new artwork."

Full Story (comments: none)

openSUSE Build Service 2.0 Beta1 Release Brings New User Interface

The first beta of openSUSE Build Service 2.0 has been released. "Version 2.0 is planned to be released on June 10th. We have updated the public server http://build.opensuse.org with the current code stream as part of our testing. We invite others running a build service to test the code and give feedback via the opensuse-buildservice mailing list and report bugs in bugzilla."

Full Story (comments: none)

Slackware 13.1 released

The Slackware 13.1 release is out. "Slackware 13.1 brings many updates and enhancements, among which you'll find two of the most advanced desktop environments available today: Xfce 4.6.1, a fast and lightweight but visually appealing and easy to use desktop environment, and KDE 4.4.3, a recent stable release of the new 4.4.x series of the award-winning KDE desktop environment."

Comments (4 posted)

Distribution News

Debian GNU/Linux

bits from the DPL: RFH, comm., derivatives, delegates, newbies

Debian Project Leader Stefano Zacchiroli has a few bits about the Release Team's request for help, Communication, Derivatives, Delegations, and more.

Full Story (comments: none)

Parallel booting enabled by default

Petter Reinholdtsen has an update on the status of parallel booting in Debian. "Another small step in the improvement of the Debian boot system was taken last weekend, when sysvinit version 2.88dsf-5 was uploaded. It concluded an almost 8 year effort to get the Debian boot system to run boot scripts in parallel. Parallel booting is enabled by default in unstable at the moment, and will enter testing in some days, unless a serious problem is found."

Full Story (comments: none)

Recent changes in dpkg

Raphaël Hertzog covers some recent changes in dpkg versions 1.15.6 and 1.15.7.

Full Story (comments: none)

Fedora

ATrpms for Fedora 13; upcoming EOL for Fedora 11

ATrpms has officially launched Fedora 13 support and also announced the end of support for F11 is about a month away.

Full Story (comments: none)

Cooperative Bug Isolation for Fedora 13

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

Full Story (comments: none)

SUSE Linux and openSUSE

News about openSUSE Strategy

The openSUSE Board has been holding a series of strategy sessions about the future of openSUSE. "We discussed the role of openSUSE as a community and project and looked at data from a variety of sources, including the recent openSUSE Survey to identify and build a strategy of strength and empowerment within our community, with a goal of establishing a common unified ground for answering the question to ourselves and to the world... "Why openSUSE?" and openSUSE's role in the operating system market, both today and in the future."

Full Story (comments: none)

Distribution Newsletters

DistroWatch Weekly, Issue 355

The DistroWatch Weekly for May 24, 2010 is out. "As the network of Fedora download mirrors synchronises with the main server to provide us with a speedy delivery of "Goddard" later this week, it's time to take a look at the new version of one the most prominent Linux distributions available today. A full review of Fedora 13 is scheduled for next week; in the meantime take a look at the news section where a linked article discusses some of the best features of this release. Also in the news, a new version of OpenSolaris is rumoured to arrive before the end of the month, PCLinuxOS community releases a "FullMonty" edition with thematic virtual desktops, Debian announces further delays in freezing "Squeeze", and Ubuntu hints at some of the innovations in the upcoming "Maverick Meerkat". This week's feature story is a first look at NimbleX, a live CD that allows you to customise the system before downloading it, accompanied by an interview with the project's founder, Bogdan Radulescu. Other topics covered in today's issue include an explanation about SELinux, the usual recap of the distribution releases of the past week, and an introduction to FuguIta, an OpenBSD-based live CD developed in Japan. Happy reading!"

Comments (none posted)

Fedora Weekly News 226

The Fedora Weekly News May 19, 2010 is out. "This week's issue kicks off with announcements from the Fedora Project, including details on the third Community Gaming Session, news of Jon Stanley joining the Fedora Project Board, and a series of upcoming Town Hall meetings for Fedora elections. In news from the Fedora Planet, a trip report from the Linux Audio Conference 2010 in Utrecht, news from Greg DeKoenigsberg's exciting new opportunities, and a continuation of discussion of target audiences for Fedora. We have lots to offer in Fedora In the News, including several more Fedora 13 reviews and experience pieces in the trade press and an exclusive interview with Paul W. Frields. Translation gets us up to date on Fedora 13 activities including a review of upcoming tasks, documentation translation and a new version of Publican. From the Design Team, updates on Fedora 14 supplemental wallpapers, discussion of Fedora 13 release party posters, and discussion of an archive for the Fedora Project media. This week's issue is complete with Security Advisories, overviewing the security-related software packages released during the past week."

Full Story (comments: none)

openSUSE Weekly News, Issue 124

The openSUSE Weekly News for May 22, 2010 is out. "Now the twentieth Week goes to the End, and we are pleased to announce our new issue. One of the important things in this week was the Milestone 7 release from 11.3. I've just tried it out, and it is very good. If you have some Space on your HD and you would like to test, it would be great. You can make a full Installation or you test it via VirtualBox. If you find a Bug, you can report it to bugzilla.opensuse.org. Through that you can help us to make OUR Distribution better. So we're hoping, that you like the new Weekly News. We wish you many joy by reading it..."

Comments (none posted)

Ubuntu Weekly Newsletter #194

The Ubuntu Weekly Newsletter for May 22, 2010 is out. "In this issue we cover Ubuntu Mentioned on CBS's The Big Bang Theory, Audio from UDS Sessions Now Available, Taking a Long Term View of the Release, Next Americas Regional Membership Board Meeting Announced, Why Launchpad Rocks, Kubuntu Maverick All Planned Out at UDS, Ubuntu Stats, Ubuntu Uruguay Approved Team, Ubuntu-my (Malaysia) Workshop Monash University, Ubuntu-my (Malaysia) Lucid Release Party, Ubuntu Catalan LoCo Team Release Party, Ubuntu Brazil Release Party Pictures, Ubuntini Recipe Released, LoCo Items for Ubuntu Weekly Newsletter, Debian and Ubuntu, Archive / Permissions Reorg confusion, Ubuntu Maverick UDS Group Photo made with the Hugin Panorama Creator, Melissa Draper: UW World Play Day 2010 Competition: The Movie, In The Press, In the Blogosphere, In Other News, Upcoming Meetings and Events, Updates and Security, and much much more!"

Full Story (comments: none)

Distribution reviews

Speedy Android 2.2 hits with tethering, push framework, more (ars technica)

ars technica covers the release of Android 2.2. "At the Google I/O developer conference today in San Francisco, the search giant unveiled Android 2.2, codenamed Froyo. The new version introduces some impressive performance improvements and much-needed feature enhancements."

Comments (19 posted)

Seven Reasons to Upgrade to Fedora 13 (Linux.com)

Joe 'Zonker' Brockmeier looks at Fedora 13. "Fedora users typically don't like to get behind the curve. One of the watchwords for the Fedora project is "first," and that means (in part) being fast to put the latest software from upstream in the hands of users with each release. Fedora 13 is no exception. The latest Fedora release comes with KDE 4.4 and GNOME 2.30 desktops, Firefox 3.6.3, OpenOffice.org 3.2, the 2.6.33 Linux kernel, and hundreds of other package updates. Each of these upstream updates brings improvements that you won't want to miss."

Comments (none posted)

Linux Mint 9: Solid, Simple, Shiny (Linux.com)

Linux.com has a review of Linux Mint 9. "Linux Mint shares quite a bit with its upstream distro. Ubuntu is in turn based on Debian, which I suppose makes Mint sort of a grandchild to Debian. But it's not an Ubuntu clone. It has its own look and feel and several useful tools that the Mint community has developed on their own. Starting with the look and feel: Mint is very green. It also saves a bit of screen space by featuring only one GNOME panel and uses a menu similar to the "slab" layout that was developed by Novell for SUSE. It combines the system, places and applications menu into one."

Comments (none posted)

Linux Mint 9 (Isadora)

Desktop Linux Reviews takes a look at Linux Mint 9. "I happily recommend Linux Mint 9 to beginner, intermediate and advanced Linux users. This is probably the best Linux distro for beginners. It's extremely easy to install and includes plenty of software. It includes most codecs necessary for multimedia and it has an enthusiastic community, ready to lend support and guidance to newbies."

Comments (none posted)

Puppy Linux 5.0 "Lucid Puppy" Released (Linux Journal)

Linux Journal reviews Puppy Linux 5.0 "Lucid Puppy". "As you might have guessed from the name, this version represents a break from the past as it is now based on packages from the latest version of Ubuntu Linux. As Ubuntu itself is better known as a popular choice for well specified desktop computers, one might wonder if Ubuntu + Puppy could result in a conflict of design interests. Let's take a look."

Comments (none posted)

SimplyMEPIS 8.5 (Desktop Linux Reviews)

Desktop Linux Reviews takes a look at SimplyMEPIS 8.5. "SimplyMEPIS 8.5 is a nice alternative for KDE users. It's obviously not going to appeal to the GNOME crowd, and that's fine. The SimplyMEPIS assistants provide some real configuration value and help set this distro apart from some of the others."

Comments (none posted)

Page editor: Rebecca Sobol

Development

Diaspora: toward free social networking

May 26, 2010

This article was contributed by Joe 'Zonker' Brockmeier.

At this point it should be wholly unnecessary to explain why an open and privacy friendly alternative to Facebook, and other closed social networks, is necessary. The question, then, is how to provide alternative that meets the criteria and has a low barrier of entry to boot. The developers behind Diaspora Project have proposed exactly that, and have asked the community to help fund its development.

The Diaspora team comprises four young developers from New York University's Courant Institute. The developers, Dan Grippi, Maxwell Salzberg, Raphael Sofaer, and Ilya Zhitomirskiy, put out call for funding to raise a modest $10,000 for the team to work on Diaspora through the summer. To date, with more than a week until the pledge drive ends on June 1st, Diaspora has racked up more than $180,000 from more than 5,300 backers. Nearly half have chipped in between $25 and $49, and five donors have pledged $1,000 or more. The group has been profiled in The New York Times and Wired as an open alternative to Facebook.

All of that comes without a line of code having been made public, and on a relatively vague description of what Diaspora will be. The only incentives, aside from the promise of code release at the end of summer, are some assorted perks like free t-shirts or (at the top end) access to the Diaspora build server for those donating $1,000 or more. Diaspora will be made public under the Affero GPLv3 at the end of the summer, but the specifics of the release are uncertain.

The Diaspora folks have not focused on individual servers, but on giving users control of their data and decentralizing services that are similar to Facebook's. The project claims inspiration from Eben Moglen's speech to the New York branch of the Internet Society on February 5th. The topic of the talk was Freedom in the Cloud, and rather than pointing fingers at Bill Gates, Steve Jobs, or other computing figureheads that have embraced proprietary software, Moglen called out Mark Zuckerberg for doing "more harm to the human race than anybody else his age." Rather than suggesting legal solutions to the problem of Facebook, Moglen suggested that Facebook should be made obsolete, and to implement social services using "wall wart servers" where people control their own data.

So what is Diaspora? According to the project page, the initial design of Diaspora includes GPG encryption, the ability to scrape Twitter and Flickr, and the beginnings of a way for Diaspora instances to "friend" one another. Each user will have their own "seed", which will aggregate information. A seed runs on a computer hosted by the user or on a shared service. Seeds will pull data from various services and be able to distribute it to other services. The example given by Salzberg is uploading a picture to Flickr and having the seed automatically generate a tweet using the caption and link. Diaspora will handle services via a plugin interface, so that it's easy to add new services.

A service that only ties together existing networks, however, is not very useful. So Diaspora would also allow friends to connect their seeds over an encrypted connection and share content privately. The long-term capabilities hinted at include instant messaging, VoIP, and being an OpenID provider.

After hearing of the project, Luis Villa posed several questions about the design, technical solutions, and social problems involved with creating a successful social network. This prompted a more complete description of the features and framework for Diaspora. Specifically, it says it plans to "build less" and focus on four specific features.

The first is the protocol to communicate between Diaspora servers, which would be encrypted between nodes. The team has not decided whether this will be a new protocol, or if it would be possible to use the Extensible Messaging and Presence Protocol (XMPP). The next feature is the data store that would hold users' data. The Diaspora team says it's considering the MongoDB database for the first iteration, but may look at the Tahoe-LAFS distributed filesystem.

Another focus for Diaspora will be an extension framework. The developers promise a "service-agnostic" and "content-agnostic" framework that is easy to import or export any kind of data from any Web service. Finally, they plan to integrate OpenID and OAuth. Users should be able to use their own Diaspora seed as an OpenID provider, and to allow other services to access their Diaspora service through OAuth.

What won't be in Diaspora v1.0? For one thing, the developers don't intend to support all services out of the gate. Instead, Diaspora will be a framework that is "well tested and documented."

We will write backend interfaces for some services, but I think the community will be able outperform us in bandwidth and quality on this one. It is fundamental to the success of the project that the code be 100% free, or the project will fail. End of story.

It will also not be a community project, at least not until the end of the summer. The Diaspora team has indicated that, while they may engage in discussions about protocols with the community, they prefer to work as a foursome this summer. "We want to be an independent code base because the four of us work fast and well as a team. Our arguments are short and solved by someone writing better code."

They are also not guaranteeing that Diaspora will be easy to install in its first iteration. Despite that, the team does seem to understand the necessity of Diaspora being easy for non-technical users. According to the Kickstarter page, the goal is "for everyone to have full control over their data and to empower people in to become responsible, secure, and social Internet dwellers." The project also promises a turnkey hosted service similar to WordPress.com, to allow users who have no interest in managing their own server the ability to simply run a Diaspora instance.

The idea of an open source, distributed social network is not new. The DiSo Project, for example, attempted to use WordPress as a building block for a distributed social network through plugins. That project still has some signs of life, but after three years, it still hasn't generated much traction, but has succeeded in having several founders hired by Google. Red Hat's Mugshot sank without a trace.

The only libre social networking tool that has generated any serious traction is StatusNet, and its flagship Identi.ca service, which has emerged as a viable alternative to Twitter. Even that has seen limited success reaching a mainstream audience, as Villa points out. The fact that the project has overshot its funding goals by such a wide margin suggests that it will have an interested audience on launch. That, of course, does not equal success. As Villa points out, it's not only important that Diaspora be easy to use, it also needs to appeal to a wider audience. Having harnessed mainstream press attention may help, but that's a far cry from delivering a user-friendly social networking service that excites a mainstream audience.

But it seems to have most of the necessary pieces, at least in theory. One thing that Diaspora doesn't address, at least thus far, is applications. A lot of Facebook's popularity can be attributed to applications like Farmville, and fan pages for causes, celebrities, and random things. While those may not appeal overmuch to many LWN readers, it's one of the hooks that draws in many non-technical (and less privacy-conscious) users. In turn, those users help generate the network effect that has helped Facebook become one of the more popular sites on the Web.

Following the attention and onslaught of funding, the Diaspora team is plowing through feedback and offers of help and advice. The team has also largely gone silent publicly and has not responded to questions I sent to the "press" email address about how they planned to handle the overabundance of funding. This is, perhaps, less ominous than it sounds. Give four college-age developers, who asked the community to come up with $10,000 to work on their dream project, ten or twenty times that amount and it may take some time for them to adjust and refocus. Still, it is concerning that Kickstarter apparently has no safeguards for this sort of windfall or to help ensure that users get their money's worth. The money is disbursed when the funding period ends and it's entirely up to the project to deliver what it promises.

One hopes that the developers will be able to live up to the trust the community has placed in them. As Moglen has said, it's up to technologists to make closed social networks obsolete. The Diaspora team now has a long runway to work towards this, and clear interest from the community to succeed.

Comments (9 posted)

Brief items

Development Quotes of the week

We could have declared Parrot more or less "complete" some time ago and shipped a program that was known to have some serious flaws. Instead what we've been doing, and what I think is the more responsible course of action: fix it until it is correct. So to answer the first question: yes it's been 10 years, but Parrot isn't perfect yet and we are going to continue working on it until it is, however long that takes.
-- Andrew Whitworth

public static int wtf (String tag, String msg)

What a Terrible Failure: Report a condition that should never happen. The error will always be logged at level ASSERT with the call stack.

-- Android API reference manual

Comments (4 posted)

KDE considering signing of tarballs

The KDE project is considering the adoption of a mechanism for adding signatures to its source tarballs. There are still a lot of unanswered questions, but the proposed process (click below) is a start. "The biggest organizational challenge would probably be how to choose the 'master key admins', i.e. the people that have unlimited access to the master signing private key. To chose such people, we should ask a question who really leads the KDE project? Who has the power to e.g. modify the front WWW website, who accepts the long-term development road-map, etc. Perhaps the community could vote to choose, say three, people that would become the master key admins?"

Full Story (comments: 1)

ktorrent 4.0 released

Ktorrent 4.0 is out. The headline features are support for the magnet and µTP protocols, but there are a number of other additions as well.

Full Story (comments: none)

MySQL Community Server 5.1.47 and 5.0.91 released

MySQL Community Server versions 5.1.47 and 5.0.91 have been released. Active maintenance of the 5.0 series has ended so this update only contains fixes for security bugs. MySQL 5.1.47 is recommended for use on production systems.

Comments (2 posted)

MyTracks source released

MyTracks is an excellent Android application for anybody wanting to record GPS tracks; your editor uses it to monitor just how slow his bike rides are. MyTracks is also now free software. "This means you can now contribute code directly to My Tracks - to fix that annoying bug, improve some part of the app or add a new feature. We don't promise that all changes will become a part of My Tracks, and we have a code review process to keep the code consistent (again, see the wiki), but we'll try to be reasonable."

Comments (10 posted)

The Paparazzi project loses its founder

Paparazzi is a combined hardware and software project aimed at the creation of autonomous flying vehicles. It has reached a point where vendors are selling autopilot systems based on Paparazzi and universities are using it for teaching and research. The founder of the project, Pascal Brisset, recently died in a climbing accident; the project is now trying to figure out how to regroup and continue his work. People who knew Pascal are posting their feelings on this wiki page. Condolences to all.

Comments (1 posted)

VoltDB launches

The VoltDB in-memory database management system has announced its existence. "Under the leadership of Postgres and Ingres co-founder, Mike Stonebraker, VoltDB has been developed as a next-generation, open-source DBMS that has been shown to process millions of transactions per second on inexpensive clusters of off-the-shelf servers. It has outperformed traditional OLTP database systems by a factor of 45 on a single server, and unlike NoSQL key-value stores, VoltDB can be accessed using SQL and ensures transactional data integrity (ACID)." The code is licensed under GPLv3; annual support subscriptions start at a mere $15,000.

Comments (23 posted)

Newsletters and articles

Development newsletters from the last week

Comments (none posted)

Damian Conway on Perl and its future (O'Reilly)

The O'Reilly GMT site has an extensive interview with Damian Conway on the future of Perl. "The evidence is that most major new programming languages take about a decade to reach a stable and useful design. C++ did, Java did, Perl 5 did, Haskell did, Python 2.0 did, Standard ML did. ANSI C arguably took two decades to get right, and Lisp took either two or four (depending on whether you think Scheme or Common Lisp Scheme was the final 'correct' incarnation). So when people point to the fact that the Perl 6 design process has taken 10 years, I consider that to be a sign that we did it right."

Comments (36 posted)

Page editor: Jonathan Corbet

Announcements

Non-Commercial announcements

End Software Patents collecting names of on-the-fence decision makers

End Software Patents is anticipating the US Supreme Court decision in the Bilski case and is collecting names of people that would be good to send a copy of Patent Absurdity to. End Software Patents executive director Ciarán O'Riordan writes: "Sending it to people firmly on one side or the other won't do anything, so Gates and Stallman won't get a copy, but who are the politicians, company decision makers, professors, and organisation representatives who either haven't taken a stance, or who lean in our direction and might do some internal lobbying if they got some encouragement?"

Comments (1 posted)

Commercial announcements

ADempiere Business Consultants announced

The leading implementers of the free and open source ERP application ADempiere have announced the launch of ADempiere Business Consultants (ABC). "A limited partnership, ADempiere Business Consultants LLP, has been established in the England, United Kingdom (www.adempiereconsultants.com). The partnership will act as a hub for the accelerated development of partner shared knowledge including best practise in evaluation, implementation and support."

Full Story (comments: none)

Articles of interest

Google pounds the open standards drum during I/O keynote (ars technica)

Ars technica reports in from Google's developer conference, Google I/O. "Sundar Pichai, Google VP of product management, discussed the growing importance of the Web as an application platform. HTML5 is gaining traction swiftly, he said, and is poised to bring a multitude of rich new capabilities to the Web. Pichai showed graphs that quantified the increasing support for HTML5 features in mainstream browsers, including Google's own Chrome. Web APIs for multimedia, filesystem interaction, geolocation, and support for hardware accelerated rendering have arrived, bringing the promise of a new generation of more sophisticated Web applications."

Comments (none posted)

Newly open source BitTorrent protocol aims to unclog tubes (ars technica)

ars technica covers the open source release of BitTorrent's uTorrent Transport Protocol (uTP). "uTP, which is used today in the popular uTorrent BitTorrent client, is designed to reduce network congestion by allowing other traffic to take precedence. This reduces the overall load that BitTorrent puts on networks, both locally and at the ISP level. The developers contend that the new protocol will remove the need for ISPs to throttle or block BitTorrent traffic and could also potentially boost download performance in some cases."

Comments (9 posted)

WebM: Missing The Assurances Open Source Needs? (ComputerWorld)

Simon Phipps expresses some concerns about WebM in ComputerWorld UK. "Firstly, the new license Google is using for the project is one that's not been submitted to the Open Source Initiative for approval. As it stands it possibly can't be approved due to Google's ironic inclusion of a 'field of use' restriction in the patent grant (which is restricted to 'this implementation of VP8' rather than the more general grant in the Apache license from which the text started). That means WebM is not currently open source, despite using a license based on the BSD and Apache licenses."

Comments (71 posted)

Is Android fragmented or is this the new rate of innovation? (Engadget)

Engadget takes on the "Android fragmentation" issue. "Android isn't summer camp for handset vendors and not everyone gets get a trophy for showing up. Google is treating partners equally, but will not slow the rate of innovation so weaker players can keep up. By constantly raising the bar, both in terms of reference devices and software, Google aims to keep innovating and drive that innovation as a differentiator."

Comments (3 posted)

Hacking through the Software Patent Thickets (The H)

The H looks at patent thickets and why they are a problem for free software. "Probably the vast majority of patents are granted for very specific aspects of a given field. On their own, they do nothing; to be useful, they must be employed alongside many other patented ideas. But that is only possible if all of the relevant patent-holders agree: if even one element is missing, the machine or process might fail. As technology becomes more complex, it becomes dependent on an increasing number of patent-holders, all of which must license their inventions for the system to function."

Comments (none posted)

Open source robot is all eyes (LinuxDevices)

LinuxDevices looks at Qbo robot. "A startup called TheCorpora is readying an open source Linux robot based on a Mini-ITX board with an Intel Atom and an Nvidia Ion GPU. The foot-and-a-half tall Qbo lacks arms or legs, but is mobile, can be controlled via WiFi, and offers stereoscopic face, object, and gesture recognition, plus speech synthesis and voice recognition."

Comments (3 posted)

Mueller: German high court declares all software potentially patentable

Florian Mueller looks at a decision of the highest German appeals court that overrules a lower patent court ruling that struck down a patent. This ruling—about a Siemens patent, not the recent upholding of a Microsoft FAT patent—was made on April 22 and the decision has now been made public. "This ruling has very general implications and ramifications. It's not just about that one case. This decision has the effect that in Germany, a country in which software patents were previously only considered valid under relatively strict criteria, all software ideas are now potentially patentable as long as they are innovative from a purely formal point of view, meaning they're at least marginally different from how a technical problem was solved before. There are many such patents that the European Patent Office and national patent offices have granted, and those are now more enforceable than ever." (Thanks to Max Hyre.)

Comments (28 posted)

Bids for Novell Expected This Week (WSJ)

The Wall Street Journal has a brief article stating that Novell is entertaining offers from potential buyers. "As many as 20 companies have expressed interest in Novell, according to people familiar with the matter. Most, if not all, of the companies expected to lodge serious bids are private equity firms."

Comments (10 posted)

Glaxo Tries a Linux Approach (Wall Street Journal)

The Wall Street Journal looks at an effort by pharmaceutical giant GlaxoSmithKline to "open source" 13,500 chemical compounds that may inhibit the malaria parasite. "Glaxo and others hope that sharing information and working together will lead scientists to come up with a drug for treating the mosquito-borne disease faster than the company could on its own. Other researchers 'may look at these structures in quite a different way and see something that we don't,' said Nick Cammack, head of Glaxo's Medicines Development Campus in Spain. [...] The move is one of the largest experiments yet by the pharmaceutical industry to apply techniques of open-source development to drug discovery, based on the idea that collaboration by volunteers will create products that aren't owned by a single company." Of course, the fly in the ointment (so to speak) may still be something that open source software is struggling with: patents.

Comments (16 posted)

Interviews

Fedora's Paul Frields: Leadership, trust, fail early and often (opensource.com)

Opensource.com talks with Paul Frields. "Being a community leader means being willing to give away all credit, shoulder all blame, and generally suffer the slings and arrows of outrageous fortune. It also means you have to actively look for the many success stories happening every day, especially in a large community effort. Telling those stories to a wider audience rightfully gives community members a greater sense of ownership and pride in what they do, and it can be both motivating and energizing for the right people."

Comments (none posted)

Education and Certification

LPI at LinuxTag 2010, Berlin, Germany: "Jobcorner", Exam labs and Workshops

The Linux Professional Institute (LPI) has announced its participation in this year's LinuxTag conference (June 9-12, 2010 in Berlin, Germany). LPI will be hosting a Jobcorner, exam labs and workshops.

Full Story (comments: none)

Calls for Presentations

Linux Security Summit 2010 - Announcement and CFP

The Linux Security Summit will take place August 9, 2010, in Boston, MA. The call for presentations closes June 4, 2010. "The Linux Security Summit is a technical forum for collaboration between Linux developers, researchers, and end users. Its primary aim is to foster community efforts in analyzing and solving Linux security challenges."

Full Story (comments: none)

Upcoming Events

The Linux Foundation Announces LinuxCon 2010 Program and Schedule (EarthTimes)

EarthTimes has the Linux Foundation's press release announcing new keynote speakers and the full conference schedule for LinuxCon North America. The event takes place August 10-12, 2010 in Boston, MA, USA.

Comments (none posted)

Events: June 3, 2010 to August 2, 2010

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

Date(s)EventLocation
June 1
June 4
Open Source Bridge Portland, Oregon, USA
June 3
June 4
Athens IT Security Conference Athens, Greece
June 7
June 9
German Perl Workshop 2010 Schorndorf, Germany
June 7
June 10
RailsConf 2010 Baltimore, MD, USA
June 9
June 11
PyCon Asia Pacific 2010 Singapore, Singapore
June 9
June 12
LinuxTag Berlin, Germany
June 10
June 11
Mini-DebConf at LinuxTag 2010 Berlin, Germany
June 12
June 13
SouthEast Linux Fest Spartanburg, SC, USA
June 15
June 16
Middle East and Africa Open Source Software Technology Forum Cairo, Egypt
June 19 FOSSCon Rochester, New York, USA
June 21
June 25
Semantic Technology Conference 2010 San Francisco, CA, USA
June 22
June 25
Red Hat Summit Boston, USA
June 23
June 24
Open Source Data Center Conference 2010 Nuremberg, Germany
June 26
June 27
PyCon Australia Sydney, Australia
June 28
July 3
SciPy 2010 Austin, TX, USA
July 1
July 4
Linux Vacation / Eastern Europe Grodno, Belarus
July 3
July 10
Akademy Tampere, Finland
July 6
July 9
Euromicro Conference on Real-Time Systems Brussels, Belgium
July 6
July 11
11th Libre Software Meeting / Rencontres Mondiales du Logiciel Libre Bordeaux, France
July 9
July 11
State Of The Map 2010 Girona, Spain
July 12
July 16
Ottawa Linux Symposium Ottawa, Canada
July 15
July 17
FUDCon Santiago, Chile
July 17
July 18
Community Leadership Summit 2010 Portland, OR, USA
July 17
July 24
EuroPython 2010: The European Python Conference Birmingham, United Kingdom
July 19
July 23
O'Reilly Open Source Convention Portland, Oregon, USA
July 21
July 24
11th International Free Software Forum Porto Alegre, Brazil
July 22
July 23
ArchCon 2010 Toronto, Ontario, Canada
July 22
July 25
Haxo-Green SummerCamp 2010 Dudelange, Luxembourg
July 24
July 30
Gnome Users And Developers European Conference The Hague, The Netherlands
July 25
July 31
Debian Camp @ DebConf10 New York City, USA
July 31
August 1
PyOhio Columbus, Ohio, USA
August 1
August 7
DebConf10 New York, NY, USA

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

Page editor: Rebecca Sobol

Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds