User: Password:
Subscribe / Log in / New account Weekly Edition for March 3, 2011

SCALE: Understanding Unity

March 2, 2011

This article was contributed by Nathan Willis

Canonical's Ted Gould presented a session about the Ubuntu project's Unity interface on February 27 at SCALE 9x. It would be a tad inaccurate to refer to the session as a "talk," though — Gould spent a few minutes touring Unity via slideshow and describing the goals of the project, but he reserved close to 45 minutes of the allotted hour for audience questions. That turned out to be a wise move: the audience filled the available Q&A time with a steady stream of questions about Unity's design, features, place in the desktop stack, distinction from GNOME Shell, and deployment in Ubuntu. For a high-visibility project nearly two release cycles old, it seems there is a noticeable user-confusion issue still to be solved. Partly that may just be the lot of all interface redesigns — after all, GNOME Shell certainly shares the challenge, as did KDE 4.

Unity basics unmasked

[Ted Gould]

Gould's session was entitled "Unity: Why Does It Matter?," and it started with an account of the goals of the project. First, he said, Unity began as an attempt to integrate design with "soft skills" like psychology, sociology, and art, more directly into the software development process. This is the user-centric design paradigm, which is not historically the way open source software is shaped. Most often, open source fills the values important to enthusiasts (technical superiority, ability to tinker, power, and freedom), but lags on other values important to the "everybody else" crowd, such as predictability, discoverability, and look-and-feel enjoyability.

The headline changes in Unity's design stem from regular usability tests performed every six weeks at Canonical's offices in London. The process involves selecting volunteers and asking them to perform real-world tasks that they regularly undertake on their own computers, then observing and interviewing them on the results. Gould gave an example of someone who responded that they spent a lot of time uploading personal photos to Facebook, and would be asked to bring in a camera or flash drive with their photos and do the same thing on the test machine. He added that it is important that the developers and designers be present at the test sessions to talk to and get feedback from the volunteers, rather than just watch video or read quantitative results.

The biggest change in Unity is the redefining of the way the top panel functions. Users expressed trepidation about clicking on icons and menus in the panel because over the years, Windows and Linux systems have devolved the space into a catch-all for unrelated functions: menus that reveal selections when clicked, buttons that perform actions, useless eye-candy, and so on. Unity implements a strict menu-functionality-only policy referred to as application indicators. Any application can place an indicator in the menu, but clicking on it cannot itself perform an action; it can only reveal a drop-down menu.

The second piece of the system is the left-hand side launcher panel, which like many dock interfaces, holds large launcher buttons for favorite applications as well as icons for running applications, and shortcut buttons for the file browser, application browser, trash, and workspace switcher. Here, too, Unity implements a strict display policy, grouping all windows from the same application into one icon, allowing drag-and-drop reordering only within the application launcher segment, and presenting an API developers can use to add right-click functions.

Unity also presents a searchable "quicklist" application browser rather than a text-driven menu. The visual presentation is almost identical to GNOME Shell's (including categories), but it uses Zeitgeist on the back-end to search through recently-used applications, and the full descriptions in application .desktop files, not just the short name. Also like GNOME Shell, Unity places a number of common functions (including IM or presence options) in a "user menu," although unlike GNOME Shell, Unity uses a separate "system menu" for maintenance tasks and shutdown/reboot functions. Finally, Unity preserves the multiple workspaces/virtual desktop feature that has become a desktop mainstay, but implements it with a non-optional zoom-out/zoom-in effect that Gould said was found in testing to reduce confusion for first-time users.

Unity itself is a plug-in for the Compiz window manager, and relies on Compiz's existing functionality (or other plug-ins) for window stacking, focus, and transition effects. Although he described making it "beautiful" as one of the design goals, Gould said Ubuntu regards Unity as a "picture frame" designed to put emphasis on applications, not the desktop environment itself. Canonical's program of integrating testing and design in the development process, he said, is intended to inspire other projects to adopt a similar approach, and hopefully to take advantage of the new indicator and launcher APIs.

Questions and concerns

When the tour was complete, the questions started coming in from audience members. They fell into two major categories: first, questions about Unity's technical implementation, and second, questions about the changes it brings to user workflow when compared to the GNOME 2.x panel.

In the first category, it was clear that many users thought that Unity either implemented a new window manager, replaced core parts of the GNOME desktop stack other than the panel, or simply lived outside the rest of the desktop environment. For example, one audience member thought that Unity removed the ability to save files or application shortcuts onto the desktop; Gould explained that the desktop was untouched by Unity, and handled by Nautilus as it is today.

Several audience members asked about customization features, including whether the menu bar and launcher could be themed, resized, or moved. Gould explained that the background color, icons, and font used were inherited from the user's GTK+ theme, and would follow any custom theme choices made by the user, including accessibility settings like high-contrast colors or larger font sizes. Application indicators are single-color "symbolic" icons, but the menu bar tries to pick up whether the background color is "light" or "dark" and choose the appropriate icon color for visibility. The size of the menu bar and launcher cannot be changed in the current version, he said, but there is a patch in development. Similarly, a patch is in development to move the launcher to the right-hand side of the screen, which is a feature asked about by right-to-left language users.

Others asked about customizing window management features like focus behavior and window stacking or tiling. Here, Gould explained several times that Unity is a plug-in for Compiz, and relies on Compiz's existing features for that sort of function. As he put it, if you have a plugin that animates closing windows by burning them down with OpenGL-rendered flames, then they will burn down with OpenGL-rendered flames in Unity. By default, however, Ubuntu's version of Compiz will only ship with a basic set of Compiz plug-ins, and it is possible for users to install others that interfere with how Unity works. Similarly, Unity does not have its own "Expose"-like function to show thumbnails of all the open windows, because Compiz has its own function to do so.

There were multiple questions about accessing applications not permanently docked in the launcher. Gould's slide tour showcased the Zeitgeist-backed search function, which several seemed to interpret as meaning that there was no "browse" function (which there is), and that searching for an application by name was the only way to find it. That confusion might have been averted by highlighting the "Applications" button on the launcher during the tour.

Several thought that searching for an application by name was slower than using GNOME 2's application menu — particularly when you know where the application is. One person said that "docks" like the Unity launcher are historically used only for favorites, and asked whether there was any positive benefit to removing the application menu. Gould replied that the GNOME 2.x application menu suffered from overly broad categories (such as "Internet") and that in testing, users tended to know the name of the application that they wanted to use, but not where to find it among the categories. Thus, hitting the search button and typing the application name was faster than browsing through a menu or grid of application launchers. Also, he added, the search feature returns results based not only on the application name, but the long description in its .desktop file, which makes it possible to narrow down a search query further than an application category alone can.

The user workflow questions tended to be more personal. One audience member expressed concern over the lack of GNOME 2.x-style panel applets because she preferred to use them for rapid-access tasks like taking screenshots. Gould replied by saying that she could add the same screenshot application to the Unity launcher, and for convenience, move it to the bottom of the button list, away from the "favorites" launchers and nearer to the Workspace and Applications buttons.

Another audience member, who installs Linux for new converts, asked about assigning alternate names to applications (such as "Word" for Abiword or OpenOffice Writer), and another asked about custom application categories. Gould answered that there was not a built-in facility to do either, but because the search feature indexes .desktop files, adding alternate names or additional categories to the .desktop file would implement the same behavior.

Finally, there were several people under the impression that the 11.04 Ubuntu release that includes Unity would force them to use it. Gould replied that it was a login session option, and users who wanted to use the 2.x-style panels could choose to do so.


After the talk, I asked Gould briefly about how he thought the Q&A session went. He expressed surprise at some of the questions, most of all the concern about using search to launch applications, instead of a menu, saying that he thought Google had conditioned everyone to search for things as the default way to access content. He also speculated that UI changes are always met with concern because of their potential to disrupt comfortable working patterns.

That is almost certainly true when you look at the "workflow" set of questions. Most of them trace back to audience members being concerned that the new interface will slow down common, repetitive tasks. GNOME Shell, which adopts many of the same features implemented in Unity, has met with a strikingly similar set of concerns. But in both cases, it is very rare that the new interface actually removes any functionality — it just rearranges where its features are located. Communicating those changes looks like an area where both projects could use some improvement.

For example, the features of the GNOME 2.x panel has been split into two separate pieces in Unity. Some applets that behave more like menus already (e.g., Tomboy), can easily use the application indicator API to present the same functionality. Others that behave more like buttons (e.g., the screenshot applet), can offer the same functionality in the launcher. Although Gould did not explicitly say so, the hit-search-and-type-the-application-name sounds like the same basic paradigm as GNOME Do. When he answered the audience questions, the questioners generally seemed relieved. Perhaps that sort of point-by-point comparison ought to be a standard part of Unity and GNOME Shell's introductory documents.

On the other hand, it seems like Canonical has not gotten the message out about what pieces of the GNOME desktop experience Unity does and does not change, and there is no obvious solution to that problem. People were confused about its affect on the desktop, its window management behavior, its inheritance from GTK+, and other core functions. Perhaps part of that is due to the choice of wording — such as referring to Unity as an "environment," rather than as a panel and launcher. But it may also stem from its origin in the Ubuntu netbook edition, which carries with it the suggestion of a "stripped down" environment. Consider the current Wikipedia article on Unity, which highlights Unity's "more efficient use of space" in the first paragraph, and contrasts it with the "full" GNOME environment below. I would never suggest that anyone take Wikipedia as authoritative, but it is good for assessing the current general-consensus-viewpoint.

Because open source software is almost always developed by remote teams (in Canonical's case, often working from home), maybe it will always struggle to consistently introduce major new features. Most of what Gould explained in his answers is documented somewhere on the web, either on a wiki page or in blog posts syndicated on Planet Ubuntu, and yet even those users dedicated enough to spend their weekend at SCALE had misconceptions and questions. GNOME recently held an IRC "user day" where core developers and designers met to answer questions about GNOME 3.0 and GNOME Shell, and had a similar experience: even those users experienced enough to be comfortable with IRC had an endless barrage of questions.

It is always enlightening to see developers interact face-to-face with end users, and that is one of the best services offered by community shows like SCALE. In my estimation, the take-away message for the Unity team is the disconnect between the lay-person's understanding of Unity and what it actually is and can do. How to improve on that, though, is not so obvious. Come up with the answer to that one, and I guarantee you will draw a packed house at SCALE or any other open source software event.

Comments (17 posted)

Replacing regexps

By Jonathan Corbet
March 2, 2011
Regular expressions are a pain. Their power cannot be doubted; a regular expression can describe complicated text patterns in an exceedingly concise manner. Using regular expressions, a program can perform all kinds of string parsing and recognition tasks. But they are also difficult to write, difficult to read, difficult to understand, and difficult to debug. Any but the most trivial of regular expressions are quite likely to contain errors. So it is not surprising that developers would think about replacing them with something better. But, as a recent discussion in the Python community shows, that replacement, like regular expressions themselves, may be difficult.

The compactness of the regular expression syntax is part of their power, but also part of the problem. Consider even a very simple expression:


A reader familiar with this syntax will recognize that this expression matches the HTML <A> tag and sets aside the anchor text for later processing. But even experienced regular expression developers must look at that expression for a moment and think about how the various metacharacters affect each other before being able to say for sure what it does. It takes even longer to notice the subtle bug: this expression will be confused by the presence of multiple <A> tags in the text being searched.

So how might one do better? That was Mike Meyer's question as he sought a more "pythonic" way of doing text matching. Needless to say, he is not the first to ask that kind of question; there are a number of attempts at better string matching out there. The first of those is arguably not "pythonic" at all: it is SnoPy, a port of the venerable SNOBOL language to Python.

SNOBOL was developed during the 1960's; it included pattern matching as a core feature of the language. Unlike regular expressions, SNOBOL was anything but concise. Concatenation of strings was explicit, "[abc]" was "Any("abc")", and so on. Nonetheless, SNOBOL was highly influential in this area, and one can see echoes of the language in current regular expressions. That said, SNOBOL is not heavily used now, and the Python SNOBOL module seems to have suffered the same fate; its last release was in 2002.

Another approach is the module by Ka-Ping Yee. This module, posted in 2005, creates a new, relatively verbose but relatively readable language for the creation of patterns. Using this language, the regular expression shown above would look something like:

    <A + any(wordchars + whitespace)> + label(1, anychars) + </A>

(Note to readers; the above is totally untested and should not be relied upon for production use). This module, too, has not seen a great deal of use.

Various other packages are out there. For example, one can try to use Icon-style pattern matching with Python. For something completely different, there is the eGenix mxTextTools module, which allows the creation of text-matching programs in an assembly-like language, complete with goto constructs. mxTextTools is intimidating and not necessarily any easier to read than regular expressions, but it is said to be powerful and fast, and there are a number of real users.

Still, none of these seem likely to replace regular expressions as the first tool Python programmers reach for when they need to perform string matching. Python creator Guido van Rossum thinks things will stay that way:

I fear that regular expressions have this market cornered, and there isn't anything possible that is so much better that it'll drive them out.

Pushing aside an established incumbent is always hard, and regular expressions are well established indeed. It is never enough to simply be better in this situation; the proposed replacement has to be a lot better. As Guido noted, nothing seems to have come along which is that much better, and it may be that nothing ever will. For some medium-term value of "ever," anyway.

But, then, one also should not underestimate the ingenuity of free software developers. Or their persistence. People will almost certainly continue to throw themselves against this problem, and, maybe, somebody will come up with something interesting. Until then, we'll have to continue beating our heads against our desks as we try to figure out why our expressions don't work as intended.

Comments (42 posted)

SCALE: Honeywell on Hackerspaces

March 2, 2011

This article was contributed by Joe 'Zonker' Brockmeier.

This year's Southern California Linux Expo (SCALE) ventured into non-Linux territory with one of its keynotes. The kick-off keynote from Leigh Honeywell, Hackerspaces and Free Software, delved into the seemingly new trend of Hackerspaces. I say seemingly, because it turns out that hackerspaces have been around for decades — they've just become much more noticeable recently, particularly in North America.

[Leigh Honeywell]

For those not familiar with hackerspaces, and it seemed that quite a few in the audience were not, Honeywell described them as a "third space" intended to foster "a certain kind of creativity." The term third space comes from Ray Oldenburg, who used the term to describe community spaces where people gather for creative interaction. (A first space being the home, and second space being work.) To that end, hackerspaces act as "sort of a library for stuff" where you will find all manner of equipment that members may not be able to invest in individually — such as laser cutters and 3D printers.

Hackerspaces have been in operation, though perhaps not under that particular name, for 20-plus years in Europe. The Chaos Computer Club (CCC), Metalab, and others have been around for decades. If you haven't heard of CCC in reference to hackerspaces, you still may have heard of its brainchild Project Blinkenlights and/or its role in fighting biometrics in Germany. Honeywell recounted the story of CCC lifting German interior minister Wolfgang Schauble's fingerprints and publishing them in Die Datenschleuder after he supported collecting biometrics from German citizens to fight terrorism.

But if you haven't heard of them recently, perhaps you haven't been paying attention — even the Wall Street Journal took notice of the trend in 2009.

Hackers on a plane

How did hackerspaces make the leap across the pond? Honeywell said that it started in North America with Hackers on a Plane. The "wild trip" was organized in 2007 by Hacker Foundation founder Nick Farr, and took about 40 North American hackers through European hackerspaces to try to spread the idea. According to Wired's coverage, Farr said: "This is expensive, but I think the good works we'll see over the next few years will justify the trip. We're hoping that this trip winds up being a watershed moment for the U.S. scene." Apparently, it not only kickstarted the U.S. scene but overshot to Canada and inspired, Honeywell's home hackerspace. was founded in July of 2008 with 35 members and has about 200 people on a public mailing list. You'll find much more than a 3D printer and laser cutter at The about page lists most of their tools for public use. Those include glue guns and glue sticks, a sewing machine, hand tools, a Tektronix Digital Storage Oscilloscope, and a Van de Graaff generator — and, of course, a fire extinguisher and first aid kit.

The space also has goodies for computer geeks: a hefty server and storage capacity, with a 1TB NAS, and PXE Boot environment so members can drop in and do PXE installs of things like Ubuntu. The space also has two laptops, and a workstation for members to use while they are there.

Members get a storage bin at the space, the option to bring in guests and organize events at the space, and access to the WiFi network, private wiki, and mailing lists. ( also has a public lists, and Honeywell recommends that other hackerspaces do so as well.) Honeywell says that one of the interesting questions about hackerspaces is whether they serve as physical extensions for Internet groups, or whether the mailing lists, IRC, and wiki are extensions of the physical space.

But it's not all hack, hack, hack. The space also has "food tools," including a stove, fridge, dishwasher, and the requisite pots, pans, dishes, and glassware. The space is open 24/7. Access is controlled by RFID and a PIN-based deadbolt. When members come in, the access is announced on IRC. (The site also says that access is announced on Twitter, but it must not be the main account.)

Honeywell described some of the events and projects that members have worked on at — including refurbishing the laser cutter, and creating an Arduino-based device that dispenses candy when a member runs the dishwasher. Honeywell noted that it's a continual challenge to get people to wash their dishes, just like any shared space.

The other advantage of a shared space, says Honeywell, is that you'll usually find someone to help you do something that you want to do "like in-person IRC." Honeywell says that the people are an equally important part of a hackerspace.

One near you: No excuses

Honeywell said that if you live in a reasonably large city, there's a good chance there's already a hackerspace near you. The Hackerspaces site has an extensive list of spaces all over the world. The United States has more than 140 listed, including my home hackerspace Arch Reactor.

But if there is no hackerspace nearby, Honeywell advised the audience to create their own rather than packing bags for a city that has its own. Honeywell says that there are "no excuses" not to start a hackerspace of your own if your chosen city lacks one. If you live in a small town, then rent should be cheap and require fewer members. You don't need to start with a 3D printer or laser cutter — the important thing is to start a space and see what it cultivates.

While Honeywell maintained that there was no excuse not to start a hackerspace, there are challenges — some of which may be familiar to participants in open source projects, others specific to working together in meatspace. As with any business, there's the question of money: How much will dues be? How are memberships structured?

Just like instructions for creating your own gadgets from an Arduino, there are design patterns for creating your own hackerspace. Honeywell said that the patterns are just that — patterns. They can be adjusted or ignored in some cases, but provide a set of guidelines that can be useful. Some examples:

  • Meet every week on Tuesdays.
  • Don't let people sleep there (too often).
  • Don't bother with plants, they will die.
  • Set up a mailing list, wiki, and IRC channel.

Why Tuesdays? Honeywell says that every day sucks — Tuesdays work just as well as any other day, because any day of the week will be a problem for someone. You will need to set up a set of rules that fit your hackerspace. Honeywell pointed out that one rule at is "no food, no humans in laser." This is a good rule, but not necessary until your space actually has a laser.

Honeywell said one common misconception is that hackerspaces are all about hardware. While there is a lot of hardware hacking that takes place, she said that hackerspaces can also be a good place for software hacking or joint hardware/software projects, as well as classes for learning new skills. The community is a good example of this, with Arduino workshops, LaTeX workshops, and collaborating with other hackerspaces on a "Cupcake Challenge" to mail a cupcake at least 1,600 kilometers in "pristine condition."

Which brought around the last topic of the talk — recruiting people who are not like you. Honeywell said that a hackerspace should "bait newbies," and have open days and events that bring in new blood. She also mentioned that people drop in and out of hackerspaces depending on what's going on in their lives, so there needs to be a continual effort to recruit new members. For example, Honeywell is leading a Soldering Workshop for Women at Hacklab on March 14 to encourage more women to get involved.

One of the things that is particularly interesting about the hackerspace movement is that it's an excellent opportunity for free and open source folks to rub elbows with people who may not (yet) be FOSS proponents. Hackerspaces can attract all manner of "hackers" who may or may not be software-oriented, and provide opportunities to meet people who may know nothing about open source but all about re-wiring a laser cutter. But it is a good opportunity for collaborating on free software as well, especially if your area has user groups or enough people interested in hacking on a project.

Comments (15 posted)

Page editor: Jonathan Corbet


Seunshare, /tmp directories, and the "sticky" bit

By Jake Edge
March 2, 2011

The /tmp directory has been an unceasing source of security problems going back decades; there are still regular reports of vulnerabilities from insecure usage of temporary files. Part of the problem is that /tmp (and /var/tmp) are shared resources that can be written to by any process, which allows attackers to use various race conditions (typically time-of-check-to-time-of-use (TOCTTOU) races) in insecurely written programs to elevate their privileges. It is a bit ironic, then, that a utility specifically geared toward running a program with a private /tmp directory (for application sandboxing) would run afoul of a somewhat different kind of temporary file vulnerability—one that was long-ago excised by the advent of "sticky" directories. But that is just what Tavis Ormandy found.

The basic problem is that insecure programs often open files in /tmp after checking to see whether the file exists. In the window between the time that the test is done and the time that the file is opened, a malicious program can swap in a file of its choosing (or, more likely, a symbolic or hard link to a file of its choosing). When that happens, the buggy program is operating on a file that it does not expect and that can cause all manner of mayhem. For normally privileged programs, that mayhem is largely restricted, but for setuid programs, it can lead to full system compromise.

Long ago, attackers could use the world-writable attribute of /tmp to delete files that were created by setuid programs. The attacker could then replace the file with a link, and when a privileged program re-opened the file—something that is, in general, a bad practice with temporary files—it would be opening a file of the attacker's choice. But, the advent of the "sticky" bit as applied to directory permissions closed that loophole by only allowing the file owner (or root) to delete a file in a sticky directory. Since that time, lots of code has been written with a sticky /tmp directory in mind.

As part of its efforts to use SELinux to provide application sandboxes, Red Hat created the seunshare utility. That utility will run a command with alternate /tmp and home directories, along with a given SELinux context. seunshare will "unshare" the default mount namespace (so that the command has its own view of the filesystem hierarchy), mount the specified directories over top of /tmp and the home directory, and instruct the kernel to execute the command in the (optionally) given SELinux context. Since the temporary directory specified is under the control of the user, it doesn't necessarily have the sticky bit set, which leads to the vulnerability.

In Ormandy's example, he uses ksu to show how the /etc/passwd file could be overwritten by running ksu under seunshare. There are likely other setuid programs that make the assumption that their temporary files are in sticky directories, and quite possibly some where the consequences could be more severe than just trashing the password file. So a mechanism that was meant to provide more security actually left a hole behind. Unfortunately, this is not an uncommon occurrence in the security realm.

This particular case also shows the value of disclosing security vulnerabilities. Ormandy reported the bug back in September and, though there was a flurry of discussion about it, that discussion died off in late November (at least in the bug report). Things didn't pick up again until Ormandy posted a request for an update, along with notice that he was ready to publish an advisory, on February 18. Hearing no complaint, he did so on February 23.

After that, the discussion picked up again, with solutions being proposed, though no fix is yet available for Fedora or RHEL. One has to wonder how long this potential local privilege escalation might have languished had Ormandy not released his advisory. As a temporary mitigation, Ormandy suggests removing the setuid bit from seunshare or restricting access to it. The solution that Dan Walsh has proposed removes the -t tmpdir argument to seunshare and instead mounts a tmpfs on /tmp (with the sticky bit set). Presumably that will be released in the near future.

There has been an attempt to harden the behavior of sticky directories to try to avoid some of the longstanding /tmp directory problems—though that would not have thwarted this particular vulnerability because it relies on the directory being sticky. There has been resistance to that effort because it is seen as something of an ugly hack to work around badly written code, so it has not made it into the mainline (though Ubuntu and other kernels do have that hardening). But temporary file vulnerabilities of various sorts still rear their head with depressing frequency. We will undoubtedly see others crop up in the future.

Comments (6 posted)

Brief items

Security quotes of the week

Sometimes, when I'm in a fanciful mood, I enjoy devices like brain-scanning lie detectors, and hi-tech sniffer dogs, because their appeal speaks to our desire for simple mechanical explanations in a complex world, and for machines to aggrandise intuition, or make it more sciencey. But I enjoy them mostly because - like the ridiculous new porno-scanners in US airports, that give staff a view of your breasts and penis - they show how much of security is about theatre rather than reality.
-- Ben Goldacre (Thanks to Felipe Sateler.)

The constitutionality of state and federal information privacy laws have historically and consistently been called into question, and things would be no different if—and it's a big if—Congress grants the FTC [Federal Trade Commission] authority over online tracking. When considering technical standards and what "tracking" means, it's worth keeping in mind the possible constitutional challenges insofar as state action may be involved, as some desirable options to curb online tracking may only be possible within a voluntary or self-regulatory framework.
-- Harlan Yu in the Freedom to Tinker blog

While "scare 'em and snare 'em" may be business as usual in the IT security industry, other HBGary Federal skunk works projects clearly crossed a line: a proposal for a major U.S. bank, allegedly Bank of America, to launch offensive cyber attacks on the servers that host the whistle blower site Wikileaks. HBGary was part of a triumvirate of firms that also included Palantir Inc and Berico Technologies, that was working with the law firm of the U.S. Chamber of Commerce to develop plans to target progressive groups, labor unions and other left-leaning non profits who the Chamber opposed with a campaign of false information and entrapment.
-- Paul Roberts at

Comments (1 posted)

Wallach: Things overheard on the WiFi from my Android smartphone

Over at the Freedom to Tinker blog, Dan Wallach reports on an experiment he did with his undergraduate security class: using Wireshark and Mallory to listen in on what his Android phone was sending. He describes what was found for a number of different applications including Gmail, Google Voice and Calendar, Facebook, Twitter, Angry Birds, and more. "What options do Android users have, today, to protect themselves against eavesdroppers? Android does support several VPN configurations which you could configure before you hit the road. That won't stop the unnecessary transmission of your fine GPS coordinates, which, to my mind, neither SoundHound nor ShopSaavy have any business knowing. If that's an issue for you, you could turn off your GPS altogether, but you'd have to turn it on again later when you want to use maps or whatever else. Ideally, I'd like the Market installer to give me the opportunity to revoke GPS privileges for apps like these."

Comments (21 posted)

Firefox and Thunderbird security updates

Mozilla has released Firefox 3.6.14 and 3.5.17 and Thunderbird 3.1.8, each of which fix some security vulnerabilities, including some that are marked "critical". Mozilla strongly recommends that all users upgrade to the new releases. Each Firefox release fixes eight critical, one high, and one moderate vulnerability (3.6.14, 3.5.17), while the Thunderbird release fixes two critical, and one moderate flaw (3.1.8).

Comments (1 posted)

New vulnerabilities

abcm2ps: multiple vulnerabilities

Package(s):abcm2ps CVE #(s):CVE-2010-4743 CVE-2010-4744
Created:March 1, 2011 Updated:November 21, 2011
Description: From the Red Hat bugzilla:

Abcm2ps upstream has released latest v5.9.13 version, fixing "yet more multiple unspecified vulnerabilities":

Gentoo 201111-12 abcm2ps 2011-11-20
Fedora FEDORA-2011-1851 abcm2ps 2011-02-20

Comments (none posted)

acroread: multiple vulnerabilities

Package(s):acroread CVE #(s):CVE-2011-0562 CVE-2011-0563 CVE-2011-0565 CVE-2011-0566 CVE-2011-0567 CVE-2011-0585 CVE-2011-0586 CVE-2011-0587 CVE-2011-0589 CVE-2011-0590 CVE-2011-0591 CVE-2011-0592 CVE-2011-0593 CVE-2011-0594 CVE-2011-0595 CVE-2011-0596 CVE-2011-0598 CVE-2011-0599 CVE-2011-0600 CVE-2011-0602 CVE-2011-0603 CVE-2011-0604 CVE-2011-0606
Created:February 24, 2011 Updated:May 13, 2011

From the Red Hat advisory:

A specially-crafted PDF file could cause Adobe Reader to crash or, potentially, execute arbitrary code as the user running Adobe Reader when opened. (CVE-2011-0562, CVE-2011-0563, CVE-2011-0565, CVE-2011-0566, CVE-2011-0567, CVE-2011-0585, CVE-2011-0586, CVE-2011-0589, CVE-2011-0590, CVE-2011-0591, CVE-2011-0592, CVE-2011-0593, CVE-2011-0594, CVE-2011-0595, CVE-2011-0596, CVE-2011-0598, CVE-2011-0599, CVE-2011-0600, CVE-2011-0602, CVE-2011-0603, CVE-2011-0606)

Multiple security flaws were found in Adobe reader. A specially-crafted PDF file could cause cross-site scripting (XSS) attacks against the user running Adobe Reader when opened. (CVE-2011-0587, CVE-2011-0604)

Gentoo 201201-19 acroread 2012-01-30
Gentoo 201110-11 adobe-flash 2011-10-13
openSUSE openSUSE-SU-2011:0492-1 flash-player 2011-05-13
SUSE SUSE-SA:2011:011 acroread 2011-03-07
openSUSE openSUSE-SU-2011:0156-1 acroread 2011-03-07
Red Hat RHSA-2011:0301-01 acroread 2011-02-23

Comments (none posted)

avahi: denial of service

Package(s):avahi CVE #(s):CVE-2011-1002
Created:February 24, 2011 Updated:September 12, 2011

From the Mandriva advisory:

avahi-core/socket.c in avahi-daemon in Avahi before 0.6.29 allows remote attackers to cause a denial of service (infinite loop) via an empty (1) IPv4 or (2) IPv6 UDP packet to port 5353. NOTE: this vulnerability exists because of an incorrect fix for CVE-2010-2244 (CVE-2011-1002).

Gentoo 201110-17 avahi 2011-10-22
Fedora FEDORA-2011-11588 avahi 2011-08-26
CentOS CESA-2011:0436 avahi 2011-04-14
Red Hat RHSA-2011:0436-01 avahi 2011-04-12
Pardus 2011-64 libcgroup pam_cgroups 2011-04-07
SUSE SUSE-SR:2011:005 hplip, perl, subversion, t1lib, bind, tomcat5, tomcat6, avahi, gimp, aaa_base, build, libtiff, krb5, nbd, clamav, aaa_base, flash-player, pango, openssl, subversion, postgresql, logwatch, libxml2, quagga, fuse, util-linux 2011-04-01
Red Hat RHSA-2011:0779-01 avahi 2011-05-19
Ubuntu USN-1084-1 avahi 2011-03-07
openSUSE openSUSE-SU-2011:0149-1 avahi 2011-03-02
Debian DSA-2174-1 avahi 2011-02-26
Mandriva MDVSA-2011:037 avahi 2011-02-24
Pardus 2011-67 avahi 2011-04-07

Comments (none posted)

clamav: arbitrary code execution

Package(s):clamav CVE #(s):CVE-2011-1003
Created:March 1, 2011 Updated:April 1, 2011
Description: From the Ubuntu advisory:

It was discovered that the Microsoft Office processing code in libclamav improperly handled certain Visual Basic for Applications (VBA) data. This could allow a remote attacker to craft a document that could crash clamav or possibly execute arbitrary code.

Gentoo 201110-20 clamav 2011-10-23
SUSE SUSE-SR:2011:005 hplip, perl, subversion, t1lib, bind, tomcat5, tomcat6, avahi, gimp, aaa_base, build, libtiff, krb5, nbd, clamav, aaa_base, flash-player, pango, openssl, subversion, postgresql, logwatch, libxml2, quagga, fuse, util-linux 2011-04-01
openSUSE openSUSE-SU-2011:0208-1 clamav 2011-03-22
Fedora FEDORA-2011-2741 clamav 2011-03-05
Fedora FEDORA-2011-2743 clamav 2011-03-05
Ubuntu USN-1076-1 clamav 2011-02-28

Comments (none posted)

firefox: multiple vulnerabilities

Package(s):firefox CVE #(s):CVE-2010-1585 CVE-2011-0051 CVE-2011-0053 CVE-2011-0054 CVE-2011-0055 CVE-2011-0056 CVE-2011-0057 CVE-2011-0058 CVE-2011-0059 CVE-2011-0061 CVE-2011-0062
Created:March 2, 2011 Updated:May 2, 2011
Description: From the Red Hat advisory:

A flaw was found in the way Firefox sanitized HTML content in extensions. If an extension loaded or rendered malicious content using the ParanoidFragmentSink class, it could fail to safely display the content, causing Firefox to execute arbitrary JavaScript with the privileges of the user running Firefox. (CVE-2010-1585)

A flaw was found in the way Firefox handled dialog boxes. An attacker could use this flaw to create a malicious web page that would present a blank dialog box that has non-functioning buttons. If a user closes the dialog box window, it could unexpectedly grant the malicious web page elevated privileges. (CVE-2011-0051)

Several flaws were found in the processing of malformed web content. A web page containing malicious content could cause Firefox to crash or, potentially, execute arbitrary code with the privileges of the user running Firefox. (CVE-2011-0053, CVE-2011-0055, CVE-2011-0058, CVE-2011-0062)

Several flaws were found in the way Firefox handled malformed JavaScript. A website containing malicious JavaScript could cause Firefox to execute that JavaScript with the privileges of the user running Firefox. (CVE-2011-0054, CVE-2011-0056, CVE-2011-0057)

A flaw was found in the way Firefox handled malformed JPEG images. A website containing a malicious JPEG image could cause Firefox to crash or, potentially, execute arbitrary code with the privileges of the user running Firefox. (CVE-2011-0061)

A flaw was found in the way Firefox handled plug-ins that perform HTTP requests. If a plug-in performed an HTTP request, and the server sent a 307 redirect response, the plug-in was not notified, and the HTTP request was forwarded. The forwarded request could contain custom headers, which could result in a Cross Site Request Forgery attack. (CVE-2011-0059)

openSUSE openSUSE-SU-2014:1100-1 Firefox 2014-09-09
Gentoo 201301-01 firefox 2013-01-07
Pardus 2011-56 xulrunner firefox 2011-03-21
Debian DSA-2186-2 vimperator 2011-03-18
Fedora FEDORA-2011-2797 seamonkey 2011-03-07
Fedora FEDORA-2011-2796 seamonkey 2011-03-07
SUSE SUSE-SA:2011:013 MozillaFirefox,MozillaThunderbird,seamonkey 2011-03-15
openSUSE openSUSE-SU-2011:0169-1 MozillaFirefox 2011-03-14
Debian DSA-2187-1 icedove 2011-03-09
Debian DSA-2186-1 iceweasel 2011-03-09
Slackware SSA:2011-068-01 seamonkey 2011-03-09
Slackware SSA:2011-068-02 firefox 2011-03-09
Fedora FEDORA-2011-2447 gnome-python2-extras 2011-03-02
Fedora FEDORA-2011-2447 galeon 2011-03-02
Fedora FEDORA-2011-2447 perl-Gtk2-MozEmbed 2011-03-02
Fedora FEDORA-2011-2447 mozvoikko 2011-03-02
Fedora FEDORA-2011-2447 gnome-web-photo 2011-03-02
Fedora FEDORA-2011-2447 xulrunner 2011-03-02
Fedora FEDORA-2011-2447 firefox 2011-03-02
Ubuntu USN-1049-2 firefox, firefox-{3.0,3.5}, xulrunner-1.9.2 2011-03-07
Mandriva MDVSA-2011:042 mozilla-thunderbird 2011-03-07
Mandriva MDVSA-2011:041 firefox 2011-03-03
Debian DSA-2180-1 iceape 2011-03-03
Ubuntu USN-1050-1 thunderbird 2011-03-03
Ubuntu USN-1049-1 firefox, firefox-{3.0,3.5}, xulrunner-1.9.2 2011-03-03
Fedora FEDORA-2011-2444 galeon 2011-03-02
Fedora FEDORA-2011-2444 gnome-python2-extras 2011-03-02
Fedora FEDORA-2011-2444 gnome-web-photo 2011-03-02
Fedora FEDORA-2011-2444 perl-Gtk2-MozEmbed 2011-03-02
Fedora FEDORA-2011-2444 mozvoikko 2011-03-02
Fedora FEDORA-2011-2444 xulrunner 2011-03-02
Fedora FEDORA-2011-2444 firefox 2011-03-02
CentOS CESA-2011:0310 firefox 2011-03-02
CentOS CESA-2011:0312 thunderbird 2011-03-02
CentOS CESA-2011:0313 seamonkey 2011-03-02
Slackware SSA:2011-060-01 firefox 2011-03-02
Red Hat RHSA-2011:0312-01 thunderbird 2011-03-01
Red Hat RHSA-2011:0311-01 thunderbird 2011-03-01
Red Hat RHSA-2011:0313-01 seamonkey 2011-03-01
Red Hat RHSA-2011:0310-01 firefox 2011-03-01
Ubuntu USN-1123-1 xulrunner-1.9.1 2011-04-30

Comments (none posted)

fuse: denial of service

Package(s):fuse CVE #(s):CVE-2011-0541 CVE-2011-0542 CVE-2011-0543
Created:March 1, 2011 Updated:July 22, 2011
Description: From the Ubuntu advisory:

It was discovered that FUSE would incorrectly follow symlinks when checking mountpoints under certain conditions. A local attacker, with access to use FUSE, could unmount arbitrary locations, leading to a denial of service.

Mageia MGASA-2012-0339 fuse 2012-11-23
Scientific Linux SL-fuse-20110720 fuse 2011-07-20
Red Hat RHSA-2011:1083-01 fuse 2011-07-20
SUSE SUSE-SR:2011:005 hplip, perl, subversion, t1lib, bind, tomcat5, tomcat6, avahi, gimp, aaa_base, build, libtiff, krb5, nbd, clamav, aaa_base, flash-player, pango, openssl, subversion, postgresql, logwatch, libxml2, quagga, fuse, util-linux 2011-04-01
openSUSE openSUSE-SU-2011:0264-1 fuse 2011-03-31
openSUSE openSUSE-SU-2011:0265-1 fuse 2011-03-31
Ubuntu USN-1077-1 fuse 2011-02-28

Comments (none posted)

gimp: multiple vulnerabilities

Package(s):gimp CVE #(s):CVE-2010-4540 CVE-2010-4541 CVE-2010-4542 CVE-2010-4543
Created:February 28, 2011 Updated:September 28, 2012
Description: From the Pardus advisory:

CVE-2010-4540 gimp LIGHTING EFFECTS > LIGHT plugin stack buffer overflow

CVE-2010-4541 gimp SPHERE DESIGNER plugin stack buffer overflow

CVE-2010-4542 gimp GFIG plugin stack buffer overflow

CVE-2010-4543 gimp heap overflow read_channel_data() in file-psp.c

Gentoo 201209-23 gimp 2012-09-28
Debian DSA-2426-1 gimp 2012-03-06
Fedora FEDORA-2011-7397 gimp 2011-05-25
Fedora FEDORA-2011-7393 gimp 2011-05-25
CentOS CESA-2011:0837 gimp 2011-06-01
CentOS CESA-2011:0838 gimp 2011-05-31
Red Hat RHSA-2011:0838-01 gimp 2011-05-31
Red Hat RHSA-2011:0837-01 gimp 2011-05-31
Red Hat RHSA-2011:0839-01 gimp 2011-05-31
Mandriva MDVSA-2011:103 gimp 2011-05-29
Fedora FEDORA-2011-7371 gimp 2011-05-25
Ubuntu USN-1109-1 gimp 2011-04-13
SUSE SUSE-SR:2011:005 hplip, perl, subversion, t1lib, bind, tomcat5, tomcat6, avahi, gimp, aaa_base, build, libtiff, krb5, nbd, clamav, aaa_base, flash-player, pango, openssl, subversion, postgresql, logwatch, libxml2, quagga, fuse, util-linux 2011-04-01
openSUSE openSUSE-SU-2011:0162-1 gimp 2011-03-10
Pardus 2011-52 gimp 2011-02-28

Comments (none posted)

kernel: denial of service

Package(s):kernel CVE #(s):CVE-2010-4251
Created:March 2, 2011 Updated:July 5, 2011
Description: From the Red Hat advisory:

A flaw was found in the Linux kernel's networking subsystem. If the number of packets received exceeded the receiver's buffer limit, they were queued in a backlog, consuming memory, instead of being discarded. A remote attacker could abuse this flaw to cause a denial of service (out-of-memory condition).

Oracle ELSA-2013-1645 kernel 2013-11-26
openSUSE openSUSE-SU-2013:0927-1 kernel 2013-06-10
Ubuntu USN-1218-1 linux 2011-09-29
Ubuntu USN-1216-1 linux-ec2 2011-09-26
Ubuntu USN-1208-1 linux-mvl-dove 2011-09-14
Ubuntu USN-1204-1 linux-fsl-imx51 2011-09-13
Ubuntu USN-1203-1 linux-mvl-dove 2011-09-13
SUSE SUSE-SU-2011:0737-1 kernel 2011-07-05
SUSE SUSE-SU-2011:0711-1 kernel 2011-06-29
Red Hat RHSA-2011:0883-01 kernel 2011-06-21
Scientific Linux SL-kern-20110519 kernel 2011-05-19
CentOS CESA-2011:0303 kernel 2011-04-14
SUSE SUSE-SA:2011:019 kernel 2011-04-28
Red Hat RHSA-2011:0542-01 kernel 2011-05-19
openSUSE openSUSE-SU-2011:0399-1 kernel 2011-04-28
Red Hat RHSA-2011:0303-01 kernel 2011-03-01
SUSE SUSE-SA:2011:026 kernel 2011-05-20

Comments (none posted)

logwatch: privilege escalation/arbitrary code execution

Package(s):logwatch CVE #(s):CVE-2011-1018
Created:March 1, 2011 Updated:March 28, 2012
Description: From the Ubuntu advisory:

Dominik George discovered that logwatch did not properly sanitize log file names that were passed to the shell as part of a command. If a remote attacker were able to generate specially crafted filenames (for example, via Samba logging), they could execute arbitrary code with root privileges.

Gentoo 201203-20 logwatch 2012-03-28
CentOS CESA-2011:0324 logwatch 2011-04-14
SUSE SUSE-SR:2011:005 hplip, perl, subversion, t1lib, bind, tomcat5, tomcat6, avahi, gimp, aaa_base, build, libtiff, krb5, nbd, clamav, aaa_base, flash-player, pango, openssl, subversion, postgresql, logwatch, libxml2, quagga, fuse, util-linux 2011-04-01
openSUSE openSUSE-SU-2011:0242-1 logwatch 2011-03-30
Fedora FEDORA-2011-2318 logwatch 2011-03-01
Fedora FEDORA-2011-2328 logwatch 2011-03-01
Red Hat RHSA-2011:0324-01 logwatch 2011-03-07
Ubuntu USN-1078-1 logwatch 2011-03-01

Comments (none posted)

openjdk: privilege escalation

Package(s):openjdk-6 CVE #(s):CVE-2011-0706
Created:March 1, 2011 Updated:June 15, 2011
Description: From the CVE entry:

The JNLPClassLoader class in IcedTea-Web before 1.0.1, as used in OpenJDK Runtime Environment 1.6.0, allows remote attackers to gain privileges via unknown vectors related to multiple signers and the assignment of "an inappropriate security descriptor."

Gentoo 201406-32 icedtea-bin 2014-06-29
Mandriva MDVSA-2011:054 java-1.6.0-openjdk 2011-03-27
Ubuntu USN-1079-3 openjdk-6b18 2011-03-17
Ubuntu USN-1079-2 openjdk-6b18 2011-03-15
openSUSE openSUSE-SU-2011:0155-1 java-1_6_0-openjdk 2011-03-07
Ubuntu USN-1079-1 openjdk-6 2011-03-01
Debian DSA-2224-1 openjdk-6 2011-04-20

Comments (none posted)

pam-pgsql: buffer overflow

Package(s):pam-pgsql CVE #(s):
Created:February 28, 2011 Updated:March 2, 2011
Description: From the Debian advisory:

It was discovered that pam-pgsql, a PAM module to authenticate using a PostgreSQL database, was vulnerable to a buffer overflow in supplied IP-addresses.

Debian DSA-2173-1 pam-pgsql 2011-02-26

Comments (none posted)

pango: arbitrary code execution

Package(s):pango CVE #(s):CVE-2011-0064
Created:March 2, 2011 Updated:April 1, 2011
Description: From the Red Hat advisory:

It was discovered that Pango did not check for memory reallocation failures in the hb_buffer_ensure() function. An attacker able to trigger a reallocation failure by passing sufficiently large input to an application using Pango could use this flaw to crash the application or, possibly, execute arbitrary code with the privileges of the user running the application.

Gentoo 201405-13 pango 2014-05-17
SUSE SUSE-SR:2011:005 hplip, perl, subversion, t1lib, bind, tomcat5, tomcat6, avahi, gimp, aaa_base, build, libtiff, krb5, nbd, clamav, aaa_base, flash-player, pango, openssl, subversion, postgresql, logwatch, libxml2, quagga, fuse, util-linux 2011-04-01
openSUSE openSUSE-SU-2011:0221-1 pango 2011-03-24
Pardus 2011-58 pango 2011-03-21
Fedora FEDORA-2011-3194 pango 2011-03-12
Mandriva MDVSA-2011:040 pango 2011-03-03
Debian DSA-2178-1 pango1.0 2011-03-02
Ubuntu USN-1082-1 pango1.0 2011-03-02
Red Hat RHSA-2011:0309-01 pango 2011-03-01

Comments (none posted)

php: casting vulnerability

Package(s):php CVE #(s):CVE-2011-0708
Created:February 28, 2011 Updated:January 19, 2012
Description: From the Pardus advisory:

PHP Exif extension for 64bit platforms is affected by a casting vulnerability that occurs during the image header parsing.

SUSE SUSE-SU-2013:1351-1 PHP5 2013-08-16
Oracle ELSA-2012-1046 php 2012-06-30
Scientific Linux SL-php-20120130 php 2012-01-30
Oracle ELSA-2012-0071 php 2012-01-31
CentOS CESA-2012:0071 php 2012-01-30
Red Hat RHSA-2012:0071-01 php 2012-01-30
Scientific Linux SL-php-20120119 php 2012-01-19
Oracle ELSA-2012-0033 php 2012-01-18
CentOS CESA-2012:0033 php 2012-01-18
Red Hat RHSA-2012:0033-01 php 2012-01-18
Oracle ELSA-2011-1423 php53/php 2011-11-03
Oracle ELSA-2011-1423 php53/php 2011-11-03
Scientific Linux SL-NotF-20111102 php53/php 2011-11-02
CentOS CESA-2011:1423 php53 2011-11-03
Red Hat RHSA-2011:1423-01 php53/php 2011-11-02
Gentoo 201110-06 php 2011-10-10
Debian DSA-2266-1 php5 2011-06-29
Ubuntu USN-1126-2 php5 2011-05-05
Fedora FEDORA-2011-3666 maniadrive 2011-03-19
Fedora FEDORA-2011-3636 maniadrive 2011-03-19
Fedora FEDORA-2011-3666 php-eaccelerator 2011-03-19
Fedora FEDORA-2011-3636 php-eaccelerator 2011-03-19
Fedora FEDORA-2011-3666 php 2011-03-19
Fedora FEDORA-2011-3636 php 2011-03-19
SUSE SUSE-SR:2011:006 apache2-mod_php5/php5, cobbler, evince, gdm, kdelibs4, otrs, quagga 2011-04-05
openSUSE openSUSE-SU-2011:0276-1 php5 2011-04-01
Ubuntu USN-1126-1 php5 2011-04-29
Mandriva MDVSA-2011:052 php 2011-03-23
Mandriva MDVSA-2011:053 php 2011-03-23
Pardus 2011-51 php php-cli php-common 2011-02-28

Comments (none posted)

ruby: multiple vulnerabilities

Package(s):ruby CVE #(s):CVE-2011-1004 CVE-2011-1005
Created:February 28, 2011 Updated:March 8, 2013
Description: From the Pardus advisory:

A symlink race condition vulnerability was found in FileUtils.remove_entry_secure. The vulnerability allows local users to delete arbitrary files and directories. (CVE-2011-1004)

Exception#to_s method can be used to trick $SAFE check, which makes a untrusted codes to modify arbitrary strings. (CVE-2011-1005)

Gentoo 201412-27 ruby 2014-12-13
CentOS CESA-2013:0612 ruby 2013-03-09
Scientific Linux SL-ruby-20130307 ruby 2013-03-07
Fedora FEDORA-2012-15507 ruby 2012-10-14
Ubuntu USN-1583-1 ruby1.9.1 2012-09-25
Ubuntu USN-1377-1 ruby1.8 2012-02-27
CentOS CESA-2011:0908 ruby 2011-08-14
CentOS CESA-2011:0909 ruby 2011-06-30
Scientific Linux SL-ruby-20110628 ruby 2011-06-28
Scientific Linux SL-ruby-20110628 ruby 2011-06-28
Red Hat RHSA-2011:0910-01 ruby 2011-06-28
Red Hat RHSA-2011:0909-01 ruby 2011-06-28
Scientific Linux SL-ruby-20110628 ruby 2011-06-28
Red Hat RHSA-2011:0908-01 ruby 2011-06-28
openSUSE openSUSE-SU-2011:0561-1 ruby 2011-05-31
Fedora FEDORA-2011-1913 ruby 2011-02-21
Pardus 2011-49 ruby ruby-mode 2011-02-28
Mandriva MDVSA-2011:098 ruby 2011-05-23
Mandriva MDVSA-2011:097 ruby 2011-05-23

Comments (none posted)

samba: denial of service

Package(s):samba CVE #(s):CVE-2011-0719
Created:February 28, 2011 Updated:May 3, 2011
Description: From the Mandriva advisory:

All current released versions of Samba are vulnerable to a denial of service caused by memory corruption. Range checks on file descriptors being used in the FD_SET macro were not present allowing stack corruption. This can cause the Samba code to crash or to loop attempting to select on a bad file descriptor set.

Gentoo 201206-22 samba 2012-06-24
SUSE SUSE-SU-2012:0348-1 Samba 2012-03-09
Oracle ELSA-2012-0313 samba 2012-03-07
CentOS CESA-2011:0306 samba3x 2011-04-14
CentOS CESA-2011:0305 samba 2011-04-14
SUSE SUSE-SR:2011:008 java-1_6_0-ibm, java-1_5_0-ibm, java-1_4_2-ibm, postfix, dhcp6, dhcpcd, mono-addon-bytefx-data-mysql/bytefx-data-mysql, dbus-1, libtiff/libtiff-devel, cifs-mount/libnetapi-devel, rubygem-sqlite3, gnutls, libpolkit0, udisks 2011-05-03
openSUSE openSUSE-SU-2011:0403-1 samba 2011-04-28
Fedora FEDORA-2011-3120 samba 2011-03-11
Fedora FEDORA-2011-3118 samba 2011-03-11
Pardus 2011-54 samba samba-devel samba-swat 2011-03-03
CentOS CESA-2011:0305 samba 2011-03-02
Red Hat RHSA-2011:0306-01 samba3x 2011-03-01
Red Hat RHSA-2011:0305-01 samba 2011-03-01
Slackware SSA:2011-059-01 samba 2011-03-01
Ubuntu USN-1075-1 samba 2011-02-28
Debian DSA-2175-1 samba 2011-02-28
Mandriva MDVSA-2011:038 samba 2011-02-28

Comments (none posted)

wireshark: code execution

Package(s):wireshark CVE #(s):CVE-2011-0713
Created:February 28, 2011 Updated:April 19, 2011
Description: From the Pardus advisory:

An attacker can invite the victim to open a DCT3 capture with Wireshark, in order to create an overflow, leading to a denial of service or to code execution.

Gentoo 201110-02 wireshark 2011-10-09
SUSE SUSE-SR:2011:007 NetworkManager, OpenOffice_org, apache2-slms, dbus-1-glib, dhcp/dhcpcd/dhcp6, freetype2, kbd, krb5, libcgroup, libmodplug, libvirt, mailman, moonlight-plugin, nbd, openldap2, pure-ftpd, python-feedparser, rsyslog, telepathy-gabble, wireshark 2011-04-19
Debian DSA-2201-1 wireshark 2011-03-23
Red Hat RHSA-2011:0369-01 wireshark 2011-03-21
Fedora FEDORA-2011-2620 wireshark 2011-03-04
Fedora FEDORA-2011-2632 wireshark 2011-03-04
Mandriva MDVSA-2011:044 wireshark 2011-03-08
Pardus 2011-50 wireshark 2011-02-28

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel is 2.6.38-rc7, released on March 1. "There really isn't a lot to report here. Driver updates (random one-liners and some sound soc codec and smaller dri updates) and a few filesystem updates (in particular btrfs fiemap and ENOSPC handling), but most of it really is pretty tiny. Regressions fixed, hopefully none introduced." Full details can be found in the long-format changelog.

Stable updates: The stable kernel was released on February 24. The longterm kernel was released on March 2, with a note of appreciation: "Many thanks again to Maximilian Attems who dug around in a lot of different distro kernels and forwarded to me the original git commit ids that should be applied to this tree. Red Hat didn't make this very easy due to their "one giant patch" format, and his skill is helping everyone out here."

Comments (7 posted)

Quotes of the week

Also note that the btrfs community of developers is not so small these days and rivals (if not surpasses) the size of the team working on ext4.

Just to answer your last question, we do not intend to "slow it down". Rather, we hope to speed it up considerably by adding developers, testing and users.

-- Ric Wheeler

There is no point in discussing the details of new ptrace features for the benefit of the debugger on a kernel list before the debugger community has come to some consensus about what they would really make use of. It would be counterproductive to start proposing and implementing random new half-baked ideas in the kernel without first being sure that they are things the debugger actually needs and the debugger developers will actually do the work to exploit. We've had enough of that already, leading to the current morass of ill-specified features that don't help the debugger people very much.
-- Roland McGrath

Comments (5 posted)

The debloat-testing kernel tree

Various developers concerned about the bufferbloat problem have put together a kernel tree for the testing of bloat mitigation and removal patches. "The purpose of this tree is to provide a reasonably stable base for the development and testing of new algorithms, miscellaneous fixes, and maybe a few hacks intended to advance the cause of eliminating or at least mitigating bufferbloat in the Linux world." Current patches include the CHOKe packet scheduler, the SFB flow scheduler, some driver patches, and more.

Comments (31 posted)

Intel announces a BIOS Implementation Test Suite (BITS)

Intel has announced the release of its BIOS Implementation Test Suite (BITS), which can be used to check how the BIOS configured platform hardware in a system or to override the BIOS configuration using a known-good configuration. BITS is built atop a modified GRUB2 bootloader and the source for BITS (and the GRUB2 modifications) can be found on the project's download page (with a Git repository coming soon). "In addition to those changes to GRUB2 itself, BITS includes configuration files which build a menu exposing the various BITS functionality, including the test suites, hardware configuration, and exploratory tools. These scripts detect your system's CPU, and provide menu entries for all the available functionality on your hardware platform. You can also access all of the new commands we've added directly via the command line."

Full Story (comments: 28)

Red Hat's "obfuscated" kernel source

Several readers have pointed out this interview with Maximilian Attems, posted by Raphaël Hertzog. Therein, Maximilian states that, while the cross-distribution cooperation on the 2.6.32 kernel has been a great thing, Red Hat is making things harder by shipping its RHEL 6 kernel source as one big tarball, without breaking out the patches. Your editor has downloaded the 2.6.32-71.14.1.el6 source package and verified that this is the case.

One of the key points behind the RPM and Debian package formats is that source is shipped in its upstream form, with patches shipped separately and applied at build time. Red Hat has always followed this convention; the failure to do so with the RHEL 6 kernel is a new and discouraging change of behavior. Distribution in this form should satisfy the GPL, but it makes life hard for anybody else wanting to see what has been done with this kernel. Hopefully it is simply a mistake which will be corrected soon.

Comments (252 posted)

Kernel development news

Waking systems from suspend

March 2, 2011

This article was contributed by John Stultz

While the power consumption of an idle Linux system has been reduced greatly over the past few years, even more power can be saved by suspending or hibernating the system. Resume times have also gone down, increasing the usability of suspending a laptop even if you're just walking down the hallway to a meeting. And while suspend and hibernation were once features only found on portable devices like laptops, they have over the years become common on mobile embedded devices and non-portable desktops and servers. The power-saving benefits of suspend and hibernate come from the fact that most or all of the hardware is shut down, but this can be a limitation if you're expecting some functionality out of the system. It's the same reason sleeping at your desk is usually frowned upon.

But let's just say, if you were an extraordinary cat-napper, and you had some downtime between numerous kernel compiles while doing a long git-bisect: You could make it work, but first you would need a good alarm clock. The same can be said of computers.


The RTC (Real Time Clock) is a fairly minor bit of hardware on your computer. It usually keeps track of the wall-clock time while the system is off or suspended. It also can be used to generate interrupts in a number of different modes (periodic, one-shot alarm, etc). This is all fairly normal functionality for a hardware timer device. But one of the most interesting features that most modern RTCs support is that an alarm interrupt can be generated even when the system is suspended (or in some hardware hibernation) forcing the machine to wake up.

On Linux the RTC is exposed to user space via the generic RTC driver infrastructure, which creates sysfs entries and a character device which can be used to set hardware alarms, change the interrupt mode, etc. A few applications out there make use of this interface, such as MythTV DVRs, which can trigger alarms so that media computers can be suspended until the start of a TV show that needs to be recorded.

The exposed interface is very much a low-level driver interface, where the values written by the application are sent directly to the hardware. This is a limitation, as it makes it so only one application at a time can program alarm events to an RTC device. For instance, with only a single RTC device, you can't have your system wake up for a nightly backup and also have it wake up to record your favorite show, unless you have some sort of centralized process managing the wakeups on behalf of other applications. Tutorials such as this one illustrate how complex and limiting this interface can be.

One way to overcome these limitations is to allow the kernel to manage a list of events and have it program the RTC so the alarm will trigger for the earliest event in the list. This avoids the need for user space applications to coordinate in order to share the hardware. To make this sharing possible, a generic "timerqueue" abstraction has been created to manage a simple list of timers that could then be shared with other areas of the kernel, like the high-resolution timers subsystem, that also have to manage timer events. This code was merged for 2.6.38.

The next step is to rework the RTC code so that, when an alarm is set via the character device ioctl() or sysfs interface, an rtc_timer event is created and enqueued into the per-RTC timerqueue instead of directly programming the hardware. The kernel then sets the hardware timer to fire for the earliest event in the queue. In effect, this mechanism virtualizes the RTC hardware, preserving the behavior of the existing hardware-oriented interfaces, while allowing the kernel to multiplex other events using the RTC.

The question now becomes, how to expose this new functionality so it can be used?


The first approach tried was exporting the new RTC functionality to user space directly via the POSIX clocks and timers interface. With this approach, there is a "clockid" assigned to each RTC device, so a user space application can use the POSIX interfaces to access the RTC. In this approach, clock_gettime() returns the current RTC time, clock_settime() sets the RTC time, and timer_settime() sets a POSIX timer to expire when the RTC reaches the desired time.

This approach is the most straightforward method of exposing the RTC, but it does have some disadvantages. Specifically, the RTC and system time may not be the same. On many systems, the RTC is set to local time rather than universal time. Thus, applications would need to make the extra effort to read the RTC and add to that value the time between now and when they want the timer to fire. Also, the RTC, due to simple clock skew, may not increase at the exact same rate as the system time. Additionally, since there may be multiple RTCs on a system, a single static CLOCK_RTC clockid would not be sufficient. Some form of dynamic clock_id registration is needed in order to export multiple clockids for multiple RTC devices. This functionality is desired for exposing other hardware clocks via the POSIX interface, and it is currently a work-in-progress by Richard Cochran.

Android Alarm Timers

Interestingly, the developers who have been working on Android have extended the RTC to be more useful as well. After all, smartphones are optimized to save power, so they try to stay in suspend as much as possible. But smartphones still have to wake up to do things like notify the user of calendar events or to check for email. In order to do this, The Android team introduced a concept called Android Alarm Timers. These timers use a hybrid approach: when when the system is running, alarm timers trigger a high-res timer to fire when an event is supposed to run; however, when the system goes into suspend, the alarm timers code looks at the list of events and sets the RTC to fire an alarm when the earliest event is to run. This avoids making applications deal with the (possibly unsyncronized) RTC time domain and allows applications to simply set timers and have them fire when expected, whether or not the system is suspended.

While never submitted to the kernel mailing list for inclusion, the Android Alarm Timers implementation would likely meet some resistance from the kernel community. For instance, the user-space interface for applications to use the Android Alarm Timers is via ioctl() to a new special character device (/dev/alarm) instead of using existing system call interfaces. Additionally, the ioctl() interface introduces new names for existing concepts in the kernel, duplicating CLOCK_REALTIME (which provides UTC wall time) and CLOCK_MONOTONIC (which counts from zero starting at system boot, and is not modified by settimeofday() calls) via the names ANDROID_ALARM_RTC and ANDROID_ALARM_SYSTEMTIME respectively.

The Android Alarm Timers interface does introduce some new useful concepts. For instance, the CLOCK_MONOTONIC clock does not increment during suspend. This is reasonable behavior when you want suspend to be transparent to applications, but when the system spends the majority of its time in suspend and you want to schedule events that wake the system up having only CLOCK_REALTIME increment over suspend can be limiting. So Android Alarm Timers introduces the ANDROID_ALARM_ELAPSED_REALTIME clock, which is similar to CLOCK_MONOTONIC, but includes time spent in suspend. But again, it is only introduced via an ioctl() to their special character device, and is not exposed via any other standard timekeeping interface.

Posix Alarm Timers

All in all, the Android Alarm Timers are a very interesting use case, and others in the community have suggested a similar hybrid approach. Inspired by the Android Alarm Timers, I implemented a similar hybrid alarm timers infrastructure on top of the previously-described work virtualizing the RTC interface. However, these timers are exposed to user space via the standard POSIX clocks and timers interface, using the new the CLOCK_REALTIME_ALARM clockid. The new clockid behaves identically to CLOCK_REALTIME except that timers set against the _ALARM clockid will wake the system if it is suspended. Additionally, because it's built upon the virtualized rtc_timers work, this implementation doesn't prohibit applications from making use of the existing legacy RTC interfaces. This gives us all the benefits of Android Alarm Timers, such as not forcing applications to deal with the RTC time domain, while making better use of existing kernel interfaces.

The code that implements the timerqueues and reworks the generic RTC layer to allow for multiplexing of events has been included in the 2.6.38 kernel release. The POSIX alarm timers layer will likely need additional review and discussion, in hopes of making sure the Android developers are able to assess compatibility issues in the design. For instance, I've proposed a new POSIX clock (CLOCK_BOOTTIME, along with a corresponding CLOCK_BOOTTIME_ALARM id) which would provide the incrementing-in-suspend value that the Android developers introduced with ANDROID_ALARM_ELAPSED_REALTIME. Also, while not likely to be included into mainline, Android's wakelocks have some interesting semantics with regards to their alarm timer interface. These semantics are not easily satisfied by the posix timers interface, but it is to be determined if we can get equivalent functionality using modified semantics and the mainline kernel's pm_wakeup interface.

Other open questions that need to be addressed are:

  • What capabilities should applications be required to have in order to set POSIX alarm timers?

  • In order to avoid systems waking up at inappropriate times (think laptop in a bag in the overhead compartment), should there be additional policy layers added so that user-generated suspends (like closing a laptop) inhibit POSIX alarm timers?

I also can imagine some interesting future work combining this functionality with the "Wake on Directed Packet" feature of some new network cards, which wake the system up any time a packet is sent to it. This feature could be used to allow web servers to function normally, servicing requests and running jobs, while suspending and saving power during longer idle periods.

While I might not be able to sleep on the job, I look forward to my desktop system being able to snooze and save electricity while knowing that cron jobs like nightly backups, downloading package updates or running updatedb will still be done.

Comments (18 posted)

Capabilities for loading network modules

By Jake Edge
March 2, 2011

Linux capabilities are still a work in progress. They have been in the kernel for a long time—since the 2.1 days in 1998—but for various reasons, it has taken more than a decade for distributions to really start using the feature. While capabilities ostensibly provide a way to give limited privileges to processes, rather than the all-or-none setuid model, the feature has been beset with incompleteness, limitations, complexity concerns, and other problems. Now that Fedora, Openwall, and other distributions are working on actually using capabilities to reduce the privileges extended to system binaries we are seeing some of those problems shake out.

A patch that was merged for 2.6.32 is one such example. The idea behind it was that the CAP_NET_ADMIN capability should be enough to allow loading network modules, rather than requiring CAP_SYS_MODULE. The CAP_SYS_MODULE capability allows loading modules from anywhere, rather than restricting the module search path to /lib/modules/.... So, by switching to use CAP_NET_ADMIN, network utilities, like ifconfig, could be restricted to only load system modules, rather than arbitrary code.

There is one problem with that scheme, though, as Vasiliy Kulikov pointed out, because it allows processes with CAP_NET_ADMIN to load any module from /lib/modules, not just those that are networking related. Or, as he puts it:

    root@albatros:~# grep Cap /proc/$$/status
    CapInh: 0000000000000000
    CapPrm: fffffffc00001000
    CapEff: fffffffc00001000
    CapBnd: fffffffc00001000
    root@albatros:~# lsmod | grep xfs
    root@albatros:~# ifconfig xfs
    xfs: error fetching interface information: Device not found
    root@albatros:~# lsmod | grep xfs
    xfs                   767011  0 
    exportfs                4226  2 xfs,nfsd

That example deserves a bit of explanation. The first command establishes that the capabilities of the shell are just CAP_NET_ADMIN (capability number 12 of the 34 currently defined capabilities). Kulikov then goes on to show that the xfs module is not loaded until he loads it via ifconfig. That is clearly not the expected behavior. In fact it is now CVE-2011-1019 (which is just reserved at the time of this writing). For those that want to try this out at home, Kulikov gives the proper incantation in his v2 patch:

    # capsh --drop=$(seq -s, 0 11),$(seq -s, 13 34) --

Note that on not-quite-bleeding-edge kernels (e.g. Fedora 14's kernel), the 34 should be changed to 33 to account for the lack of a CAP_SYSLOG, which was just recently added. Running that command will give you a shell with just CAP_NET_ADMIN.

Kulikov's first patch proposal simply changed the request_module() call in the core networking dev_load() function to only load modules that start with "netdev-", with udev expected to set up the appropriate aliases. There are three modules that already have aliases (ip_gre.c, ipip.c, and sit.c) in the code, so the patch changes those to prefix "netdev-". But David Miller was not happy with changing those names, as it will break existing code.

There was also a bit of a digression regarding attackers recompiling modules with a "netdev-" alias, but unless that attacker can install the code in /lib/modules, it isn't a real problem. In this case, the threat model is a subverted binary that has CAP_NET_ADMIN, which is not a capability that would allow it to write to /lib/modules. But Miller's complaint is more substantial, as anything that used to do "ifconfig sit0", for example, will no longer work.

After some discussion of various ways to handle that problem, Arnd Bergmann noted that the backward compatibility problem is only for systems that are not splitting up capabilities (i.e. they just use root or setuid with the full capability set). For those, the CAP_SYS_MODULE capability can be required, while the programs that only have CAP_NET_ADMIN will be new, and thus can use the new "netdev-" names. The code will look something like:

    no_module = !dev;
    if (no_module && capable(CAP_NET_ADMIN))
	    no_module = request_module("netdev-%s", name);
    if (no_module && capable(CAP_SYS_MODULE)) {
	    if (!request_module("%s", name))
		    pr_err("Loading kernel module for a network device "
    "with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias netdev-%s "
    "instead\n", name);

That solution seemed to be acceptable to Miller and others, so we may well see it in the mainline soon. One thing to note, though, is that capabilities are part of the kernel ABI, so changes to their behavior will be difficult to sell, in general. This change is fixing a security problem—and is hopefully not a behavior that any user-space application is relying on—so it is likely to find a reasonably smooth path into the kernel. Other changes that come up as more systems start to actually use the various capability bits may be more difficult to do, though we have already seen some problems with the current definitions of various capabilities.

Comments (11 posted)

Who wrote 2.6.38

By Jonathan Corbet
March 2, 2011
As of this writing, the 2.6.38 development cycle has reached the 2.6.38-rc6 prepatch and things are beginning to settle down a little. One or two more testing releases can be expected before the final release, but we are close enough to the final shape of 2.6.38 that a look at where the code came from this time around makes sense. While this cycle has been a bit less busy than its predecessor, 2.6.38 still shows an active and engaged development community.

The 2.6.38 cycle has seen 9,148 non-merge changesets from 1,136 developers (again, as of this writing). Compared to 2.6.37 (11,446 changesets from 1,276 developers) those numbers may seem small, but they are on a par with most other recent kernel releases:


603,000 lines of code were added in this cycle, and 312,000 were removed, for a net growth of 291,000 lines of code. The most active contributors of that code were:

Most active 2.6.38 developers
By changesets
Joe Perches1992.2%
Chris Wilson1822.0%
Russell King1471.6%
Mark Brown1431.6%
Tejun Heo1071.2%
Ben Skeggs1071.2%
Alex Deucher971.1%
Eric Dumazet881.0%
Felix Fietkau881.0%
Mauro Carvalho Chehab830.9%
Thomas Gleixner790.9%
Jesper Juhl750.8%
Lennert Buytenhek720.8%
Johannes Berg700.8%
Stephen Hemminger700.8%
Al Viro680.7%
Andrea Arcangeli670.7%
Clemens Ladisch660.7%
Uwe Kleine-König660.7%
Nick Piggin650.7%
By changed lines
Vladislav Zolotarov425245.8%
Nicholas Bellinger307974.2%
Larry Finger234393.2%
Hans Verkuil209782.9%
Barry Song141741.9%
Dimitris Papastamos127941.7%
Ben Skeggs116511.6%
Rafał Miłecki111491.5%
Sven Eckelmann110811.5%
Mike Frysinger106921.5%
Sonic Zhang83601.1%
Michael Chan82801.1%
Chris Wilson81641.1%
Mark Brown76901.0%
Chuck Lever74571.0%
Joe Perches71851.0%
Shawn Guo64400.9%
Paul Walmsley56710.8%
Mark Allyn54240.7%
Nick Piggin54020.7%

Joe Perches made it to the top of the "by changesets" with a long list of patches removing excess semicolons and casts, adding "static" keywords, and other things of that nature. Chris Wilson's changes were entirely in the Intel graphics driver subsystem, Russell King remains active as the lead ARM maintainer, Mark Brown does large amounts of work in the sound driver subsystem, and Tejun Heo had patches all over the tree, most of which are related to cleaning up workqueue usage.

Vladislav Zolotarov's path to the top of the "lines changed" column ostensibly should not exist anymore; among his many bnx2x driver changes was a large firmware replacement. Nicholas Bellinger is the main author of the LIO SCSI target patches which were merged, after extensive discussion, for 2.6.38. Larry Finger added the Realtek RTL8192CE/RTL8188SE wireless network adapter to the staging tree, Hans Verkuil continues his work straightening out the Video4Linux2 subsystem, and Barry Song added a number of IIO drivers to the staging tree.

Work on 2.6.38 was supported by a minimum of 180 employers, the most active of whom were:

Most active 2.6.38 employers
By changesets
Red Hat114512.5%
Texas Instruments2903.2%
Wolfson Micro1701.9%
Analog Devices1151.3%
Renesas Tech.1071.2%
By lines changed
Red Hat565617.7%
Analog Devices410835.6%
Rising Tide Systems318694.3%
Wolfson Micro251673.4%
Texas Instruments241933.3%
ST Ericsson95211.3%
Renesas Tech.85341.2%
Oki Semiconductor70871.0%

The most significant new entry is Rising Tide Systems, a storage array company which, unsurprisingly, has an interest in the kernel's SCSI target implementation. Otherwise, the entries at the top of the table have changed little over the last few years; here is a plot showing the trends since 2.6.28:

contributions plot]

There is a certain amount of noise, but, over this entire period, non-paid contributors are at the top of the list, followed by Red Hat and Intel, in that order. The most significant trends, perhaps, are TI's steady increase over time, and IBM's slow decline.

Regardless of what individual companies do, though, the real picture that emerges from this data is that the kernel development process remains strong and active. The rate of change remains high, and the community from which those changes come remains large and diverse. There may come a time when the kernel community runs out of ideas and things to do, but it does not seem that things will slow down anytime soon.

[As always, thanks are due to Greg Kroah-Hartman for his assistance in the creation of these numbers. The tool used to calculate these statistics is "gitdm"; it can be had at git:// The associated configuration files can be downloaded here.]

Comments (8 posted)

Patches and updates

Kernel trees


Core kernel code

Development tools

Device drivers

Filesystems and block I/O

Memory management



Virtualization and containers


Page editor: Jonathan Corbet


SCALE: Projects and distribution unfriendliness

March 2, 2011

This article was contributed by Don Marti

Fedora engineering manager Tom "spot" Callaway, who actively maintains a Fedora-compatible package repository for the Chromium web browser, said Friday he has "given up" on getting the browser — which does work well on Fedora — into the distribution proper. In November 2009, he explained why Chromium is not an official Fedora package on his blog, and those issues remain. In a talk at the Southern California Linux Expo (SCALE) entitled, "This is why you FAIL," Callaway, who maintains more than 350 packages in Fedora, listed some of what he sees as "points of FAIL," or distribution-unfriendly software development practices, using Chromium as an example for many of them.

"Having your software be distribution-friendly is a key to success," he said. In the Fedora Activity Day event earlier at SCALE, users brought in systems in a variety of "states of disrepair", he said, which were caused by attempting to install third-party software. Distribution-friendliness also reflects on other channels, he said. The same "points of FAIL" that affect distribution maintainers are also problems for intermediaries who are putting the software on embedded devices or running it as a hosted service.

In the talk, which summarized his chapter, "How to tell if a FLOSS project is doomed to FAIL" from the book The Open Source Way, Callaway discussed the bundled dependency problem. It's worth FAIL points to include a private copy of a library on which a program depends, and extra FAIL points for building a modified version. A key problem, Callaway said, is that when a distribution does a security update for a library, it also has to do updates for any packages that include their own copies. (Fedora has a No Bundled Libraries policy, and Fedora package maintainers do modify the build process for software that the distribution packages, in order to make it build with a system copy of the library.) "Chromium is perhaps the worst offender I have ever seen in my entire career," Callaway said.

Chromium developer Evan Martin, who was not at the event but had posted a list of third-party code distributed with Chromium on his blog, replied to that in email:

Briefly, it's a lot of extra work to support system libraries. With a few more years of experience on it, I now see the pain of finding cases where there's been a bug or missing API in a system library or software, we've fixed the bug (and even contributed it upstream), but because distros are so slow to push out updates our users will be stuck with the old version. Like in his example in his [Callaway's] post with sqlite, the fact is that the additional sqlite API can take months to cycle out to real users' computers, which doesn't help us much.

Callaway did recognize that some versions of system libraries might not work. The build process should make the system copy the default, though. If the build configuration comes up with "I found this library and I can't use it because it has rabies or something," then it could build an alternate copy. Martin said that the Chromium team is willing to accept outside contributions to facilitate this:

We have some contributors from the open source world who write patches for things like this, so if they write a good patch we'll accept it. With some libraries we've had to switch between system and non-system as the Chrome versions of the libraries skew.

Chromium requires a copyright assignment agreement for code changes, which Callaway said he has not accepted. "After review with a lawyer, they advised me that agreeing to that would give Google a license to use my contributions under any copyright license terms that they'd like, including non-free terms," he said later. "I'd be more than willing to give them my changes under the terms of a Free license, but Google wants to continue to distribute a proprietary version of their browser (Google Chrome), and I have no interest whatsoever in helping them with that effort," he added.

Much of the advice in Callaway's talk applied not to large-scale projects like Chromium, but to new, lower-profile projects. He reserved some of the FAIL warnings for projects that don't offer basic documentation, such as how to do a build and how to begin interacting with the source control system. "Lots of programmers coming through school have never seen a source control system," he said. A project web site should include instructions for how to check out the code and how the project wants to receive incoming code changes. It also counts for substantial FAIL if "all your web site has is a picture of a marijuana leaf," as he said one small-scale open source project does.

The build and install process is another key area. "If your code forces an install into /opt or /usr/local you're probably running Oracle and I'm very very sorry," he said. Running "make install" should just work. "Make the decision that you're going to have an installable program that works outside the source directory."

Some software comes in a problematic archive format; RAR archives are a problem, he said, because the format is proprietary. A developer once asked Callaway about making Fedora packages for his new archiving tool, which came in an archive created by the same tool. "He didn't see why this was a problem and I couldn't tell him because I was crying," Callaway said.

A history of having been proprietary is worth more fail the longer it was proprietary before the initial open source release. "Red Hat has bought some real shiny turds," he said, giving Netscape's email server as an example. "We buried it in the backyard," he said.

The good news is that many of the points of FAIL are relatively easy to correct. Including a copy of the software license and setting up a mailing list are minor tasks. The bundled dependency problem, on the other hand, has turned out to require lots of skilled attention from both the project maintainers and distributions, so that one is still with us.

Both library-bundlers and library-splitters have their points. Bundling creates more long-term issues for administrators, but library-splitting takes up valuable development time, especially for cross-platform projects that need to bundle the libraries for target platforms that don't practice library splitting. But bundled libraries are a problem for many Linux distributions and one that we will likely be facing for some time to come.

Comments (7 posted)

Brief items

Fedora 13 ARM Beta Release

Paul Whalen has announced the availability of Fedora 13 ARM Beta. "There are still a number of packages that haven't been built for ARM due to build failures or missing dependencies. Because we're a little behind the primary architectures we have the ability to look at later releases to see if these failures have been fixed - thankfully a large number include support for ARM. Because of this we expect that with Fedora 14 and 15 we will be closer in line with the primary architectures." The release notes are here.

Comments (none posted)

FreeBSD 8.2-RELEASE Available

The FreeBSD Release Engineering Team has announced the availability of FreeBSD 8.2-RELEASE. This update includes improved Xen support, ZFS v15, BIND and OpenSSL updates, and much more. See the release notes for more information.

Full Story (comments: none)

Mandriva 2011 Alpha2

The second alpha of Mandriva 2011 is available for testing. "Among the most noticeable features are the simplification of the initial setup steps, both when running the image in Live mode, or before the installation, update to kernel, integration of the latest networkmanager-mdv plugin by Andrey Borzenkov, switch from scim to ibus for input framework, more indepth systemd integration into the system, and, of course, lots of packages updates all around."

Comments (none posted)

MeeGo 1.1 update 3 and MeeGo 1.0 update 7

There are two updates for MeeGo; MeeGo v1.1.3 for Core, Netbook and In-Vehicle, MeeGo v1.0.7 for Core and Netbook. These releases will "enhance the stability, compatibility, and security of your devices".

Full Story (comments: none)

OpenEmbedded Release-2011.03

OpenEmbedded 2011.03 has been released. From the release notes: "This release is currently in development. This will be tested for several combinations as listed below in the table. This does not cover all the possible combinations The list provides the information about what different DISTRO, MACHINE, IMAGE combinations were tested, along with what version of bitbake and what host distribution."

Full Story (comments: none)

openSUSE 11.4 RC2

The second release candidate for openSUSE 11.4 is available. "The recent Bug Squashing day saw 132 bugs updated so few serious issues remain. Improvements in the 'backend' work includes some tweaks to Wifi supplicant and drivers, and a host of small fixes across the distribution which enhance stability and performance. The addition of MediaCurl backend with zsync support to libzypp iut is already being noticed."

Full Story (comments: none)

PC-BSD 8.2 Released

The PC-BSD Team has announced the release of PC-BSD 8.2 (Hubble Edition), running FreeBSD 8.2-RELEASE, and KDE 4.5.5. There are a number of enhancements and improvements in this release. See the changelog for details.

Comments (none posted)

Distribution News

Debian GNU/Linux

Bits from ARM and Embedded Sprint

The Debian Project held a productive ARM and Embedded Sprint. "The sprint worked really well, with lots of input from a good range of people, with cross-pollination between people's interests, and plenty of concrete outputs in the form of useful patches and repositories. The balance between hacking an discussion worked well. ARM's facilities worked really well." Topics in the report (click below) include ARM ports, Multiarch, Bootstrapping a.k.a. Cyclic dependencies issues, FreedomBox, Flash-kernel, and Cross toolchain support.

Full Story (comments: none)

Red Hat Enterprise Linux

Red Hat Lifecycle Support for Red Hat Enterprise Linux 4

Red Hat has sent out a 1-year end-of-life notification for Red Hat Enterprise Linux 4. The company has also announced the availability of Extended Lifecycle Support (ELS) for Red Hat Enterprise Linux 4. "ELS, an optional Add-On for Red Hat Enterprise Linux, extends an existing Red Hat Enterprise Linux subscription for an additional three years over its standard seven year life-cycle. As a result, subscription customers have a choice of purchasing ELS to extend their use of Red Hat Enterprise Linux 4, or to upgrade to a more recent Red Hat Enterprise Linux 5 or 6 version."

Comments (none posted)

Newsletters and articles of interest

Distribution newsletters

Comments (none posted)

Linux Mint 11 "Katya" to use GNOME 3 (The H)

The H reports that Linux Mint 11 will feature GNOME 3, but without Unity or GNOME Shell. "[Clement] Lefebvre notes that Linux Mint users can optionally add Unity or the GNOME Shell themselves but it will not be included by default in Linux Mint 11, adding that "by default the desktop will look similar to the one we're using at the moment"."

Comments (none posted)

Shuttleworth: Mistakes made, lessons learned, a principle clarified and upheld

On his blog, Mark Shuttleworth has responded to the recent Banshee controversy to explain Canonical's position. "We know that we need a healthy and vibrant ecosystem of application developers. We think services should work for them too, and we're committed to sharing revenue with them. We want to be entirely aligned in our interests: better code means a better result for both of us, better revenue means more resources to do what we love even better. Our interests, and upstream interests, should be perfectly aligned in this. So we have consistently had the view that revenue we can attribute to a particular upstream should create a revenue share for that upstream. We support Mozilla in this way, for example. The numbers are not vast, but nor are they insubstantial, and while we are not obliged to do so, we do so happily." The comment thread on the post is interesting as well, including a lengthy explanation from Shuttleworth on his views regarding the perception of divergent interests between Canonical and the Ubuntu community.

Comments (78 posted)

Page editor: Rebecca Sobol


Choosing between portability and innovation

March 2, 2011

This article was contributed by Koen Vervloesem

Portability is a key concept in the open source ecosystem. Thanks to this killer feature, your author has migrated his desktop operating system during the last ten years from Mac OS X to Linux (various distributions) and eventually to FreeBSD, but throughout that process he could keep using most of the same applications. When you present a recent openSUSE or PC-BSD desktop system to a computer newbie, they won't notice much difference, apart from a different desktop theme, perhaps. The same applications (, Firefox, K3b, Dolphin, and so on) will be available. In many circumstances, it just doesn't matter whether your operating system is using a Linux or FreeBSD kernel, as long as it has drivers for your hardware (and that's the catch).

This portability, however, is not always easy to achieve. Now that Linux is the most popular free Unix-like operating system, it shouldn't be a surprise that some projects have begun treating non-Linux operating systems as second-class citizens. This isn't out of contempt for the BSDs or OpenSolaris, it's just a matter of limited manpower: if almost all the users of the application have a Linux operating system and if all the core developers are using Linux themselves, it's difficult to keep supporting other operating systems. But sometimes the choice to leave out support for other operating systems is explicitly made, e.g. when the developers want to implement some innovative features that require functionality that is (at least for now) only available in the Linux kernel.

Xfce 4.8 and udev

In January, version 4.8 of the Xfce desktop environment was released. In the beginning of its announcement, the developers expressed their disappointment that they couldn't offer all the new features of the release on the BSDs:

We hope that everyone will enjoy this release as much as we do. Sadly, this will not be the case as the folks using any of the BSD systems will notice a sudden loss of features. We think that this announcement is a good opportunity to express our disagreement with the recent "Linux-only" developments in the open source ecosystem, especially with regards to the utilities we need in desktop environments.

This somewhat cryptic remark was followed by a summary of the new features, but it was clear that it was aimed at the new desktop frameworks introduced in the last few years, such as udev, ConsoleKit and PolicyKit. udev is only available on Linux, but both ConsoleKit and PolicyKit are already supported by FreeBSD, so as commenter "JohnLenz" supposed correctly in a comment on the announcement, the problem is for a large part on the testing side: how many FreeBSD users are using these frameworks? And how many of them test these frameworks regularly and spend the time to report bugs?

The remark in the release announcement probably puzzled a lot of BSD enthusiasts as well, because Xfce developer Jannis Pohlmann followed up a few days later with an explanation on his personal blog. There he named udev as the culprit for the non-portability of some Xfce features:

At least udev is strongly linked to Linux and as far as I know is not available on any of the BSD flavors. Unfortunately it is now the only good way to detect storage devices, cameras, printers, scanners and other devices using a single framework. That's why we use it in Xfce now in situations where HAL provided us with device capabilities and information to distinguish between the different device types before. The consequence is that thunar-volman no longer works without udev and thus only compiles on Linux. In Thunar itself udev remains optional.

But then Pohlmann points to the broader context:

I don't know what the porting status of the other frameworks is. But I am pretty sure not all of them have been ported to other platforms yet which is why I felt the need to express our disappointment in the announcement. For 2-3 years now all this has been a big mess. New frameworks were invented, dropped again, renamed from *Kit to u* and somewhere on the way it became impossible to keep Xfce as portable as it was before. I know that this is nothing new and that BSD folks faced the same situation as they do now back when HAL was invented but I don't think it has to be this way.

Some Linux users, who may be used to six-month release cycles, might not see a problem here, as they now have all those new features. But the BSD operating systems generally have a much slower development life cycle and haven't caught up yet with the whole redesign of the desktop stack. The comments on Pohlmann's blog post are instructive in this regard (although somewhat degenerating into a flame war at the end). For example, one commenter points out that HAL did acquire BSD (and Solaris) support, but only years after it had been mainstream in the Linux world, and the BSD developers only contributed the necessary patches to make it work when Gnome and KDE started making HAL mandatory.

The problem seems to be that udev is not as easy to port to non-Linux systems as HAL was. FreeBSD has the devd daemon to handle volume mounting, but devd's author Warner Losh commented that udev is not well documented, which hampers efforts to port it. However, this didn't stop Alex Hornung from porting udev to DragonFly BSD, although it's not yet a full drop-in replacement. The FreeBSD developers could take a look at his work, as DragonFlyBSD is a FreeBSD derivative.

OpenBSD developer Marc Espie also points to license issues: udev and other software close to the Linux kernel is using GPLv2, which the BSDs don't like to use. For example, OpenBSD developers don't add a component to the base system if it's less free than the BSD license, and the GPL is such a license in their eyes. However, the current problems are also clearly a consequence of different development styles. Components like udisks are part of the Freedesktop specifications (which are supposed to keep X Window System desktops interoperable), but the BSD developers didn't seem to participate in that effort. Maybe the PC-BSD developers can play a role in this, as they want to deliver a modern desktop operating system based on FreeBSD.

All in all, there are two possible solutions to a situation like the one the Xfce 4.8 release is facing. One solution is that the Xfce developers create an abstraction layer supported by as many operating systems as possible. The problem is that currently there is no such abstraction layer for detecting devices, which makes it perfectly understandable that the Xfce developers chose udev. It is used by their major development platform, Linux, and one can't expect them to support frameworks on operating systems they don't use. So the other solution is that some BSD developers port udev to their operating system, which is non-trivial but (as the incomplete DragonFly BSD port shows) doable, or that they propose an abstraction layer that could be supported on non-Linux platforms. As many desktop applications have already been rewritten in the last few years from using HAL to using udev, the latter won't be a popular choice and isn't likely to happen.

X.Org and KMS

Another important desktop component that is becoming more and more Linux-centric in recent years is X.Org. Recent open source video drivers (such as the Nouveau driver) require kernel mode setting (KMS), which is a problem for the BSDs and OpenSolaris, as these operating systems lack kernel support for KMS and Graphics Execution Manager (GEM). So a FreeBSD user who wants to get decent performance out of an Nvidia graphics card, currently has to use the proprietary driver. Fortunately, the FreeBSD Foundation recognized the gravity of this situation and announced last year that it was willing to sponsor a developer to work on KMS and GEM support in the FreeBSD kernel. Last month, the foundation announced that it had awarded a grant, co-sponsored by iXsystems (the developers of PC-BSD) to Russian developer Konstantin Belousov to implement support for GEM, KMS, and Direct Rendering Infrastructure (DRI) for Intel hardware. Matt Olander, Chief Technology Officer at iXsystems, says in the announcement:

Adding support for GEM/KMS will allow both FreeBSD and PC-BSD to run with enhanced native graphic support on forthcoming advanced architectures with integrated, 3d accelerated graphical capabilities. FreeBSD has long been dominant in the server market and this is one more step towards making FreeBSD a complete platform for netbooks, laptops, desktops, and servers. We are very pleased to be a part of this project.

More specifically, Belousov will implement GEM, port KMS, and write new DRI drivers for Intel graphics cards, including the latest Sandy Bridge generation of integrated graphic units. After this work, users should be able to run the latest X.Org open source drivers for Intel on their FreeBSD desktop. While the project is limited to Intel graphics, porting other drivers like Nouveau to FreeBSD will become a lot easier once Belusov's work is completed. And when KMS support is in place, FreeBSD users could run the X Server without root privileges, run the Wayland display server, and get access to a lot of other features that are until now only available on Linux.

This case also shows that cutting edge development often happens with Linux primarily in mind. During the last few years, X.Org's drivers were in a constant state of flux, with new technologies like KMS, GEM, translation-table maps (TTM), DRI, Gallium3D and so on being introduced one after another. As these are low-level technologies tightly coupled to the Linux kernel, porting them to FreeBSD is no small task, but fortunately the FreeBSD Foundation and iXsystems have seen that it is very important to follow the lead of Linux here.


An entirely different case is systemd: Lennart Poettering has no problem with the fact that systemd is tightly glued to Linux features. In a recent interview for FOSDEM, Poettering sums up the Linux-specific functionality systemd relies on: cgroups, udev, the fanotify(), timerfd() and signalfd() system calls, filesystem namespaces, capability sets, /proc/self/mountinfo, and so on. And then comes this quote, explaining why he designed systemd with Linux in mind:

Not having to care about portability has two big advantages: we can make maximum use of what the modern Linux kernel offers these days without headaches -- Linux is one of the most powerful kernels in existence, but many of its features have not been used by the previous solutions. And secondly, it greatly simplifies our code and makes it shorter: since we never need to abstract OS interfaces the amount of glue code is minimal, and hence what we gain is a smaller chance to create bugs, a smaller chance of confusing the reader of the code (hence better maintainability) and a smaller footprint.

Poettering took this decision because of his experience in writing some other low-level components in the desktop stack:

Many of my previous projects (including PulseAudio and Avahi) have been written to be portable. Being relieved from the chains that the requirement for portability puts on you is quite liberating. While ensuring portability when working on high-level applications is not necessarily a difficult job it becomes increasingly more difficult if the stuff you work on is a system component (which systemd, PulseAudio and Avahi are).

He even goes further with this provocative invitation to other developers to do the same:

In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!

Poettering touches some interesting points here. We have a family of standards that are known as POSIX (Portable Operating System Interface for uniX), defining the API of a Unix operating system. However, the POSIX specifications are not carved in stone and there are few operating systems that are fully compliant (Mac OS X is one of them since the Leopard release). POSIX is really an encapsulation of some choices that various Unix systems made along the way, rather than a body of text that got standardized and then implemented. According to Poettering, Linux should use its position as "market leader" (in the market of free Unix-like operating systems) and try out some new things. If developers don't force themselves into the constraints of the POSIX API, they could develop some really innovative software, like systemd shows. When these new developments happen to turn out really interesting, other operating systems could eventually adopt them as well.

The tension between portability and innovation

These three cases clearly show that there's a constant tension between portability and innovation, which are two important qualities of open source software. In a lot of domains, Linux is taking the lead with respect to innovation, and the BSDs are forced to follow this lead if they don't want to be left behind. While the BSDs will probably not be interested in adopting systemd, implementing KMS is a must-have because one cannot imagine a modern X.Org desktop any more without it. But the biggest portability problems will be in the layers right above the kernel that don't have suitable abstraction layers, such as the Xfce case shows. Will FreeBSD implement udev or will the problem be solved another way? These kinds of questions are important and choosing when to use the POSIX or the Linux API is a delicate balancing act: choosing a Linux-centric approach for a low-level component like systemd is understandable because of the performance and maintenance gains, but most applications won't necessarily benefit from that approach.

But maybe the biggest problem these cases hint at is that Linux development is being done at such a fast pace that other operating systems just can't keep up. Linux distributions and Linux-centric developers are used to the "release early, release often" mantra, including swapping out key components and breaking APIs each release. The BSD world doesn't work that way, and this makes working together on a modern cross-platform open source desktop increasingly difficult. The innovation of Linux inevitably comes at a price: Linux is the de facto Unix platform now, and hence more and more programs will not be portable to other operating systems.

Comments (126 posted)

Brief items

Quotes of the week

Then, we have how the user interaction with the server is designed. Let me get this straight: It's 2011, it's about time to stop editing complex, error prone, plain text configuration files, don't you think? Now that we all are running fancy desktops full of powerful applications.. what sense does it make to have to open a terminal window, become root, and edit a text file, and type a new command to reload the service in order to make a little change on how your web server behaves. I'd say that none, none at all.
-- Alvaro Lopez Ortega

+ log_warning("/usr appears to be on a different file system than /. "
+             "This is not supported anymore. "
+             "Some things will probably break (sometimes even silently) "
+             "in mysterious ways.");
-- Lennart Poettering

Comments (81 posted)

Burt: Canonical's New Plan for Banshee

Gabriel Burt has posted an update on his blog regarding the default music store for Banshee on Ubuntu. The new plan is as follows:
  • Banshee's Amazon store will remain enabled, with Canonical taking a 75% cut of all affiliate revenue; 25% on Ubuntu will now go to the GNOME Foundation.
  • The Ubuntu One store for Banshee will remain enabled by default, but now Canonical will donate 25% of its revenue to GNOME. They will now do the same for Rhythmbox.
Based on the wording in the blog post, this would seem to be a unilateral decision by Canonical/Ubuntu and one that, perhaps, the Banshee developers are not completely happy with. (Thanks to Jeff Schroeder.)

Comments (20 posted)

Developments in GNU Radio

The FSF has put out a release describing recent changes to GNU Radio. "VOLK provides a way to access the vector (i.e., SIMD) instructions of general purpose processors. While there are other ways of doing this, a goal of GNU Radio is cross-platform support and an ease of programming and implementing new signal processing features. Until VOLK, adding SIMD code to GNU Radio had been a difficult, assembly-driven process. Instead, VOLK introduces the concept of a vector kernel to perform common mathematical functions in a cross-platform library. Over the next year, we will be improving many of the low-level signal processing blocks by using VOLK kernels instead of generic C++ code."

Comments (1 posted)

Mercurial 1.8 released

Version 1.8 of the Mercurial distributed version control system is available. New features include bookmarks, certificate validation for HTTPS proxies, support for git subrepositories, some performance improvements, and more. See the "what's new" page for details.

Full Story (comments: none)

SciPy 0.9.0 released

SciPy is a Python-based package of tools for science and engineering; the 0.9.0 release is now available. New features include Python 3 support, Delaunay tesselations, N-dimensional interpolation, some new large-scale nonlinear equation solvers, and more.

Full Story (comments: none)

Upstart 1.0 released

Scott James Remnant has announced the 1.0 release of the "upstart" init daemon. "The trouble with a '1.0' release is that the temptation is for that version to be the one with all the features you want when your users want it to be stable. This is a 1.0 release of the latter kind, based on the 0.6.x code that was shipped in both the most recent Ubuntu LTS and RedHat Enterprise Linux releases. If you're running Upstart anywhere right now, it's highly recommended that you update to this version, there shouldn't be any surprises!"

Full Story (comments: 6)

xorg-server 1.10.0

Version 1.10.0 of the server is out. There's a long list of patches, but, seemingly, no release notes calling out the more important changes. See the announcement (click below) for the short-form changelog.

Full Story (comments: 1)

Newsletters and articles

Development newsletters from the last week

Comments (none posted)

An Early Look at GNOME 3.0 (

Nathan Willis takes GNOME 3 for a test drive. "Plenty of low-level stuff is in there, too, even though you might not see it. GNOME is migrating away from the old gconf configuration system to GSettings, which uses dconf and will enable new features like PolicyKit. The "preferences" and "administration" menus from GNOME 2.x have been combined into a single control-panel application. There is also a new window manager named Mutter, which combines the existing WM features of Metacity with compositing like that done by Compiz."

Comments (45 posted)

Page editor: Jonathan Corbet


Brief items

The Ada Initiative Announces Advisory Board

The Ada Initiative, which is "a non-profit promoting women in open technology and culture" (and was the subject of an article in last week's LWN), has announced its advisory board. Those advisors are: Donna Benjamin, Alice Boxhall, Rachel Chalmers, Francesca Coppa, Selena Deckelmann, Sue Gardner, Leigh Honeywell, Danielle Madeley, Denise Paolucci, Kirrily Robert, Nóirín Shirley, and Matt Zimmerman. More information about the advisors can be found in the press release and on the advisors web page. "The advisory board will work closely with the Ada Initiative founders in planning and executing their projects."

Full Story (comments: none)

The Document Foundation achieves its fundraising goal

The Document Foundation has announced that its fundraising drive has been entirely successful. "The Community around LibreOffice, the free personal productivity suite, has accomplished the next major milestone in establishing The Document Foundation as a legal entity. In just eight days, some 2,000 donors from all over the world contributed €50,000 for the capital stock necessary to set-up the legal entity in Germany."

Full Story (comments: 8)

MeeBlip synthesizer in the wild

CreateDigitalMusic (CDM) looks at MeeBlip, an "open source, hackable synthesizer" that was co-produced by James Grahame of Reflex Audio and CDM. The hardware and software were both released under open source licenses, and the video-heavy review covers building MeeBlips from scratch or kits, manufacturing the MeeBlip, as well as people experimenting with the device. "But the next big improvement could come from you. Next on our plate is making it easier to use the open source software part of the MeeBlip, by providing tutorials for how to make firmware modifications yourself. [...] Of course, modding the MeeBlip isn't at all essential to enjoying the thing. I'm equally excited about those features as I am the way in which people use the MeeBlip in their music."

Comments (1 posted)

Yocto project and OpenEmbedded align

The Linux Foundation has announced that the Yocto project will "align" with OpenEmbedded to advance embedded Linux. In addition, new companies have pledged support for Yocto/OpenEmbedded, and the list of contributing companies now includes Cavium Networks, Dell, Freescale Semiconductor, Intel, LSI, Mentor Graphics, Mindspeed, MontaVista Software, NetLogic Microsystems, RidgeRun, Texas Instruments, Tilera, Timesys, and Wind River, among others. "The Yocto Project is merging technology with the OpenEmbedded community and extending governance to include OpenEmbedded representatives. In addition, the projects are planning to share a common OpenEmbedded Core consisting of software build recipes and core Linux components, preventing fragmentation and reinforcing the OpenEmbedded methodology as an open standard for embedded Linux build systems."

Comments (14 posted)

Articles of interest

DoD and Open Source Software

The DACS Software Tech News Volume 14, Number 1 has articles on the relationship of the U.S. Department of Defense (DoD) and OSS. David A. Wheeler wrote or co-wrote several of the articles and takes note of some interesting points in his weblog. Some articles are available in HTML but registration is required to download the entire issue in PDF format.

Comments (none posted)

Sony's War on Makers, Hackers, and Innovators (Make)

Make has put together a lengthy summary of Sony's actions against those who would do interesting things with its hardware. It ends with a plea to the company to adopt a friendlier attitude toward its customers. "One of the worst things a company can do is upset people whose hobby is installing Linux on things. Sony's removal of this feature brought dozens of teams around the world together, and we were all re-introduced to 'GeoHot' (George Hotz). GeoHot was best known for jailbreaking the iPhone, allowing owners to use different carriers as well as put their own software on their own devices. Jailbreaking of phones is perfectly legal in the U.S. now, and we're guessing it will eventually be fine for other devices too."

Comments (none posted)

Open source expert takes on the hardest job at Microsoft (Network World)

Network World talks with Gianugo Rabellino, director of open source communities at Microsoft. ""My role is to make sure that open source communities have a go-to person to talk to when it comes to having conversations with Microsoft," Rabellino explains. Within Microsoft, Rabellino is also there for internal product groups who want to engage with proponents of free and open source software. "My hope is that I may be able to bring the conversation to the next level.""

Comments (12 posted)

U.K. Comes out for Royalty-Free Standards for Government Procurement (The Standards Blog)

Andy Updegrove looks at a recent U.K. decision about "open standards". "The U.K. has become the latest country to conclude that for information and communications technology (ICT) procurement purposes, "open standards" means "royalty free standards." While apparently falling short of a legal requirement, a Cabinet Office Procurement Policy Note recommends that all departments, agencies, non-departmental bodies and "any other bodies for which they are responsible" should specify open standards in their procurement activities, unless there are "clear business reasons why this is inappropriate.""

Comments (12 posted)

Implementing Open Standards in Open Source (Software Tech News)

Lawrence Rosen has a lengthy article about the difficulties of implementing "open standards" as open source in the presence of patent problems; he concludes with a discussion of the Open Web Foundation's patent grant agreement. "It is not yet known whether the OWF provisions for patent licensing will overcome the resistance to change for IP policies in standards organizations in order to make both copyrights and patents freely available to open source implementers of open standards. Nor is it known what effect the Oracle v. Google lawsuit will have on the Java standards and the future expectations of implementers to be free to create software based on open standards. Intellectual property attorneys live in interesting times."

Comments (none posted)

Tom's Definitive Linux Software Roundup: Audio Production (Tom's Hardware)

Tom's Hardware takes a look at Linux applications for audio production. "This segment of Tom's Definitive Linux Application Roundup is a little different than the previous installments because it contains apps that require a good amount of audio production knowledge to use. While some of these applications are highly technical, the required knowledge is in the realm of audio production, and not Linux. In other words, readers looking into audio production using Linux are expected to have a certain level of audio know-how. But as a result of our strict standards for featured applications, little, if any, Linux experience is needed."

Comments (5 posted)

New Books

The Book of Audacity--New from No Starch Press

No Starch Press has released "The Book of Audacity", by Carla Schroder.

Full Story (comments: none)

Programming Amazon EC2--New from O'Reilly

O'Reilly Media has released "Programming Amazon EC2", by Jurg van Vliet and Flavia Paganelli.

Full Story (comments: none)

Calls for Presentations

Desktop Summit CFP announced and Registration open

The CFP for the Desktop Summit, which is a joint GNOME and KDE conference to be held August 6-12 in Berlin, Germany, is now open. Abstracts for presentations are due by March 25. Registration for the conference is open now as well. "Held annually in cities around Europe, GUADEC and Akademy are the world's largest gatherings of those involved with the free desktop or mobile user interfaces. Developers, artists, translators, community organisers, users, and representatives from government, education, and businesses and anyone else who shares an interest are welcome. GNOME and KDE are Free Software communities that drive the user interfaces of many Linux-powered devices, ranging from smartphones to laptops, or personal media centers. This year, for the second time, both communities have decided to organise a single, joint conference. We anticipate over a thousand participants, covering both projects as well as related technologies."

Full Story (comments: 6)

2011 Linux Symposium Call for Participation

The Call for Participation is open for the 2011 Linux Symposium, which will be held June 13-15 in Ottawa, Canada. "We are seeking submissions for Summits, Paper Presentations, Tutorials, Panel Discussions, Lightning Talks, and Bird of a Feather Sessions." The proposal deadline is March 15.

Comments (none posted)

13th Real Time Linux Workshop - 1st Call for Papers

The 13th Real-Time Linux Workshop will be held October 20-22, 2011 in Prague, Czech Republic. "Authors from academics, industry as well as the user community are invited to submit papers on original work related to Open Source real-time systems. Such work may deal with general topics related to Open Source based real-time systems but also with research, experiments and case studies, as well as with issues of integration of Open Source real-time and embedded systems. A special focus will be on industrial case studies and safety-related systems." The deadline for abstract submission is June 13, 2011.

Full Story (comments: none)

Upcoming Events

LibreOffice conference announced for October 12-15

The first LibreOffice conference will be held October 12 to 15 in Paris. "Carrying on the tradition of previous OOoCon conferences, the LibreOffice Conference will be the event for those interested in the development of free office productivity software, open standards, and the OpenDocument format generally."

Full Story (comments: none)

Events: March 10, 2011 to May 9, 2011

The following event listing is taken from the Calendar.

March 7
March 10
Drupalcon Chicago Chicago, IL, USA
March 9
March 11
ConFoo Conference Montreal, Canada
March 9
March 11 2011 Bangalore, India
March 11
March 13
PyCon 2011 Atlanta, Georgia, USA
March 19 Open Source Conference Oita 2011 Oita, Japan
March 19
March 20
Chemnitzer Linux-Tage Chemnitz, Germany
March 19 OpenStreetMap Foundation Japan Mappers Symposium Tokyo, Japan
March 21
March 22
Embedded Technology Conference 2011 San Jose, Costa Rica
March 22
March 24
OMG Workshop on Real-time, Embedded and Enterprise-Scale Time-Critical Systems Washington, DC, USA
March 22
March 25
Frühjahrsfachgespräch Weimar, Germany
March 22
March 24
UKUUG Spring 2011 Conference Leeds, UK
March 22
March 25
PgEast PostgreSQL Conference New York City, NY, USA
March 23
March 25
Palmetto Open Source Software Conference Columbia, SC, USA
March 26 10. Augsburger Linux-Infotag 2011 Augsburg, Germany
March 28
April 1
GNOME 3.0 Bangalore Hackfest | GNOME.ASIA SUMMIT 2011 Bangalore, India
March 28 Perth Linux User Group Quiz Night Perth, Australia
March 29
March 30
NASA Open Source Summit Mountain View, CA, USA
April 1
April 3
Flourish Conference 2011! Chicago, IL, USA
April 2
April 3
Workshop on GCC Research Opportunities Chamonix, France
April 2 Texas Linux Fest 2011 Austin, Texas, USA
April 4
April 5
Camp KDE 2011 San Francisco, CA, USA
April 4
April 6
SugarCon ’11 San Francisco, CA, USA
April 4
April 6
Selenium Conference San Francisco, CA, USA
April 6
April 8
5th Annual Linux Foundation Collaboration Summit San Francisco, CA, USA
April 8
April 9
Hack'n Rio Rio de Janeiro, Brazil
April 9 Linuxwochen Österreich - Graz Graz, Austria
April 9 Festival Latinoamericano de Instalación de Software Libre
April 11
April 14
O'Reilly MySQL Conference & Expo Santa Clara, CA, USA
April 11
April 13
2011 Embedded Linux Conference San Francisco, CA, USA
April 13
April 14
2011 Android Builders Summit San Francisco, CA, USA
April 16 Open Source Conference Kansai/Kobe 2011 Kobe, Japan
April 25
April 26
WebKit Contributors Meeting Cupertino, USA
April 26
April 29
OpenStack Conference and Design Summit Santa Clara, CA, USA
April 28
April 29
Puppet Camp EU 2011: Amsterdam Amsterdam, Netherlands
April 29 Ottawa IPv6 Summit 2011 Ottawa, Canada
April 29
April 30
Professional IT Community Conference 2011 New Brunswick, NJ, USA
April 30
May 1
LinuxFest Northwest Bellingham, Washington, USA
May 3
May 6
Red Hat Summit and JBoss World 2011 Boston, MA, USA
May 4
May 5
ASoC and Embedded ALSA Conference Edinburgh, United Kingdom
May 5
May 7
Linuxwochen Österreich - Wien Wien, Austria
May 6
May 8
Linux Audio Conference 2011 Maynooth, Ireland

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

Audio and Video programs

Allison: Geek Time with Jim Zemlin

Jeremy Allison has a video interview with Jim Zemlin, Executive Director of the Linux Foundation. "In addition to talking about the future, Jim shares insights on the history and significance of Linux."

Comments (none posted)

Page editor: Rebecca Sobol

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