LWN.net Weekly Edition for November 27, 2008

The Grumpy Editor's Asian Tour

This trip was your editor's second Japanese adventure, so it is interesting to look at what has changed over the intervening 16 months. The organization of the event remains about the same, down to the pizza-and-sushi party at the end of the first day. The agenda was more heavily oriented toward filesystems this time around, along with an overview of control group resource controllers by Hiroyuki Kamezawa. There was a big difference, though, in how the discussions went. Japanese audiences are notoriously quiet and unwilling to ask questions, but the attendees at the Japan Linux Symposium have gotten over this constraint. Questions and discussion abounded - and this is a good thing. Free software development does not work well if people are unwilling to ask questions or raise concerns. The fact that Japanese developers seem to be becoming more willing to participate in this way bodes well for their participation in the process as a whole.

How much are these developers participating now? Your editor did a quick and unscientific pass over the changes merged for the 2.6.28 kernel. It appears that a full 5% of those patches came from Japanese developers. If we exclude the work of one prolific developer who currently lives in Europe, it can be said that about 4% of 2.6.28 came from Japan itself. There has been a distinct increase in the amount of kernel code coming from that part of the world, and that can only be a good thing. The Linux Foundation's events in Japan (which began in the OSDL days and have been occurring regularly for a few years now) are, perhaps, producing the intended result.

Partly in recognition of the larger role now played by Japan in the free software community, the Japan Symposium will be taken to a higher level next year. The 2009 Kernel Summit will be held in Tokyo in October, followed by an expanded, three-day Symposium hosting talks by developers from all over the world. Planning for this event is just getting underway; expect the call for papers to come out early next year. It should be an interesting gathering in a fun city; your editor is already looking forward to attending.

The Korea Technical Jamboree was a lower-key gathering, held for a single afternoon on the 25th floor of a Seoul skyscraper. It lacked some of the infrastructure of the Japan Symposium (simultaneous translation, for example), but made up for it in enthusiasm. Your editor found a highly-engaged group of developers interested in talking about the technology. While much of the discussion was, surprisingly enough, in Korean, your editor was able to figure out that virtualization is high on the list of topics that this group was interested in.

There was also talk of business models and more. What there was less of, though, was talk of working with the community. From this brief encounter, your editor can guess that the Korean community is still working through the stage of figuring out what it can get from free software. Developers there seem to have, for the most part, not yet reached the point of sharing control of our free operating system and driving it in directions which better suit their needs. By their own admission, Korean developers are a little behind their Japanese counterparts in this regard, but that situation may not last for long.

One event your editor was not able to attend was FreedomHEC Taipei, held at the same time. Harald Welte was there, though, and posted a brief report:

Harald concludes that a higher Linux awareness in Taiwan should lead to better hardware support worldwide. With any luck at all, events like FreedomHEC, like those in neighboring regions, will help to create that awareness and expand our global development community.

Your editor was also unable to attend FOSS.in this year, despite a desire to return to that part of the world. FOSS.in is experimenting with a new event plan which is strongly oriented toward the production of tangible results; it has clearly been influenced by the success of the Linux Plumbers Conference. India has vast numbers of capable developers, relatively few of whom actively participate in our community now. That number has been growing, though, and events like FOSS.in have a lot to do with that change.

Finally: while your editor saw a lot of people expressing enthusiasm for Linux, many of them seemed to be doing it with Windows laptops. It seems that the value of Linux has not yet made itself felt in the desktop setting, even among those whose job it is to develop for or promote Linux. It would be interesting to know why more of this work can't move off of proprietary platforms.

Some of the answer may be related to episodes like this: your editor had rashly upgraded his laptop to a new stable distribution release (we'll call it Incredibly Irritating for the purposes of this discussion) just prior to traveling. The obligatory check to ensure that video projection still worked got forgotten this time; it had always worked before, what could go wrong this time? But it seems that this "upgrade" moved the tools needed to interface with RandR into a separate package, which it did not bother to install. So it was not possible to tell the laptop to send video out the external port.

Suffice to say that, five minutes prior to giving a talk, while disconnected from the network, one does not want to hear "you need to install this package before I'll turn on your external video port" from one's computer. Your editor will accept the blame for not having verified this functionality before traveling, but, still: things like this should Just Work, especially with a distribution which claims to have invested much energy into making such things Just Work. The presenters using Windows laptops were not having to contend with this kind of challenge.

That little glitch notwithstanding, this trip was a big success. The hospitality was amazing, interest was high, and there is always value in seeing how other groups are approaching free software. Our community continues to grow; many good things will come from that.

Comments (12 posted)

ELCE: Free software strategies for business

Shane Coughlan, legal coordinator for the Free Software Foundation Europe (FSFE), spoke about the advantages of free software from a business perspective at the recent Embedded Linux Conference Europe. His talk was not necessarily directed at his audience—as most were already free software users—but, instead, at the bosses of his audience, the management of companies using or considering using free software. His approach was to use the language that management understands while making a strong case for the value that free software can bring.

Coughlan noted the obligatory analyst projections, including 4% of European GDP coming from free software by 2010 as well as 80% of commercial software projected to contain free software by 2011. These are eye-opening numbers, so Coughlan went on to explain why those numbers are that high. Businesses are created to deliver value to their investors; in order to succeed, they will need to "deliver value now and deliver more value later and that's how you are going to run a successful business". A short-term outlook is not going to deliver real success. Paraphrasing Bill Clinton, he said "it's for the long term, stupid".

Proprietary software allows businesses to "do some stuff", but free software allows them to "do more stuff". As Coughlan describes it, the correct approach is for a business to "do more and keep doing it"; using free software makes that easier. "From a business perspective, free software rocks."

The key to free software is not in the cost nor is it in the availability of source code, he said, as those do not embody the freedoms that are important. The ability to "use, study, share, and improve", known as the four freedoms, are what gives free software its edge. They allow for more flexibility and growth than other kinds of software, he said.

If free software has so many upsides, what's the catch? "Free software is powered by licenses", so businesses need to understand those licenses and, just as importantly, the reasoning behind those licenses. This is no different than any other license, but a common problem is that people don't read the licenses or follow the terms. If they do, there is no problem, though. So, there is a catch, but "the catch isn't too big".

A business must apply some management science to determine its strategy: whether to use an existing solution or work on building a new one. If it decides to build something new, does it foster some kind of community model or not? These are the kinds of questions that need to be answered as part of determining a free software strategy.

Communication with people in the community is important as is choosing licenses that are popular and compatible. There are ways to reduce any risk associated with free software by using existing best practices. That means pro-actively resolving issues, not just putting free software into a product, then "pray, and be upset when someone tells us we were naughty".

One of the resources available to help management is the FSFE's Freedom Task Force (FTF) which is set up to assist everyone in understanding free software licensing. The FTF does training and consulting for businesses to help with licensing or other issues. If one is having trouble getting management on-board, refer them to FTF, "we won't actually lock them up and brainwash them", Coughlan said.

While companies are resistant to releasing their code, "if you're doing your marketing right and you're not relying on temporary monopolies, you can probably release quite a lot" of code without any business harm. It has been estimated that the body of free software is "worth" $12 billion, so a company can reimplement it, "at an estimated cost of $12 billion, or you can share your $2-3 million [investment] and use the code". It's a matter of recognizing the immense benefits that come with free software.

Coughlan also described a legal network that the FTF is fostering in Europe, where lawyers and legal experts can discuss issues of importance to free software, especially across jurisdictional boundaries. That network can help provide businesses with legal information to help reduce risks. There is, as yet, no US equivalent, though some US lawyers are participating with the European network. "Still, I'm confident that eventually the US will catch up with us", he said.

He wrapped up with some thoughts on the GPLv3, noting that "adoption in the first year has been very, very promising". In fact, it has been adopted faster than he expected. He did note that there are some problems with license incompatibilities, but that those are probably unavoidable. The ideal situation would be for every license to be able to work with every other, but it doesn't work that way, which is a bit of an inconvenience, but not really a problem at this point.

Coughlan did not really say very much that LWN readers won't have heard before, but he did put it together in a way that should resonate with businesspeople. It was also interesting to get a look at what FSFE, and particularly FTF, are up to. There is a lot of important free software work, completely separate from development, going on in Europe. Because I am US-based—hopefully not too US-biased—that sometimes gets overlooked, so it was very nice to have a chance to hear about that work.

Comments (1 posted)

An open letter to Evgeniy Polyakov

Dear Evgeniy,

Your editor has chosen to write to you in a public manner because he hates to see talented developers get frustrated with the kernel process and storm off. We do not have an excess of capable hackers, especially those who can work at your level. Losing one hurts. Your editor hopes that this eventuality can be avoided in this case - for you, and for others who may be encountering the same sort of frustrations you are. Getting code into the kernel can be a pain, sometimes. That said, some 1160 developers have managed it since the opening of the 2.6.28 merge window in October. It is possible to get code merged with sufficient care.

You first posted your distributed storage (DST) patch back in 2007; LWN took a look at it at that time. Since then, this code has come a long way. Beyond the basic task of exporting (and accessing) storage volumes across the net, this code claims "bullet-proof memory allocations," zero-copy transport, failover recovery with full transaction support, support for IPv6 and beyond, and a number of features including encrypted data channels. And, it is said, this code is fast. In general, it looks like good stuff.

You have posted the DST code on the mailing lists a number of times - too many, apparently, for your tastes. Frustration with the process appears to have led to the behavior described in your recent weblog post:

    ass licker
    static char dst_name[] = "Successful erackliss screwing into";

So, because the fourth posting of identical code in one month received little attention, DST now risks joining Kevents, network channels, network tree memory management, asynchronous crypto, and more in that place where dusty, out-of-tree stuff lives. This would not be a good outcome. So let us look at what can be done to avoid that - for your sake, for DST users' sake, and for the sake of other developers who may follow.

One way to get more reviews for your code is to pay attention to what those reviewers are saying. Andrew Morton spent some time on DST back in October. He had a number of concrete requests - such as documenting the user-space ABI and the network protocol - which have not been satisfied. He also asked for better code documentation in general:

The November 25, 2008 version of DST still does not tell that story, and that makes it very hard for other developers to understand. Code review, as you know, is in critically short supply in most free software projects. Getting reviews for difficult-to-understand code is hard, especially when it is a large body of complex code which occupies a niche in which relatively few developers have expertise. So it's not surprising that your most recent comment involved white space - anybody can make that kind of review without any need to actually understand what's going on.

Not only does your patch not tell a story, but the individual pieces of it do not even contain changelogs. For a patch set marked "consider for inclusion," that is a fatal error. Playing along with the system on things like that can seem like a waste of time, especially if you hold out no real hope of the patch being merged, but it is a necessary sign of respect for the people you are asking to consider the patch. No maintainer will accept a patch without a changelog.

While we're on the topic of documentation, your kernel configuration help text reads, in its entirety:

You owe your users a little bit more than that. Why might they want to use DST? Where can they get the associated tools? This, too, is a fatal error for any substantive kernel change.

And, while we're still somewhat on the subject of reviews: Andrew naturally called out the generic-looking thread pool implementation buried deep within DST; shouldn't it pulled out and made more generic? Your response can be paraphrased as "I can't be bothered to get the API past the review process, which, in any case, is biased toward those who are 'closer to the high end'." But pulling out this code and merging it separately might be the ideal starting point for getting the larger patch set into the kernel. A generic thread pool hiding within a storage device driver, instead, will be an ongoing impediment to inclusion.

Then there is the issue of motivation: why should the kernel developers want to merge this patch? Who are the users of it - do you have users now? How does it compare to other distributed storage technologies already in the kernel? What's the performance like - can you post some benchmark results? As it stands, DST looks like a nice piece of technology, but its benefits are still unclear. Tell that story, and the level of interest may well go up.

Finally, your editor would like to counsel patience. Some patches just take longer than others to find their way in the kernel. That is especially true of complex patches which touch on issues like memory management and which add new user-space ABIs. As a close-to-home example, look at David Howells's FS-Cache code, recently reposted for consideration. The first LWN article on this code was published more than four years ago. David is probably getting a little tired of maintaining this code out-of-tree, but he sticks with it, responds to reviews, and appears to be getting closer to inclusion.

Evgeniy, you appear to be a brilliant and productive hacker. You charge into places that scare off most kernel developers, and you always come back out with something interesting. We need developers like you. But we need developers like you who can work with the process - no matter how frustrating it gets. The kernel process is certainly far from perfect, but it is built around a set of principles which have served us well for many years. You could easily rise up through that process to become one of the "high end" developers who, you say, have an easier time getting code merged. Or you could take your marbles and storm home, making snide comments about reviewers on the way. But that would not be good for anybody involved.

(See also: Evgeniy's response to this article.)

Comments (21 posted)

Page editor: Jake Edge

Security

Distribution advisories

Here at LWN, we get a chance to see a fair number of security advisories in the course of a week—sometimes even in just a single day—so we tend to notice the quality, or lack thereof, of these important announcements. There are a few important pieces of information that need to be a part of any security update announcement, but sadly sometimes they aren't included. Overall, the quality of advisories seems to be declining, which is something that we would like to see change. While it clearly would make collecting security advisories easier for us, that is not the primary motivation for this look at security reporting—users are not being well-served by the current state of affairs.

Distributions need to remember that the audience for their security announcements is their users. Those users require some basic information to make an informed choice about whether they need to apply the update as well as how urgently. In order to make those decisions, the following should be present in advisories:

• the package affected
• the problem that is being fixed
• the impact of the vulnerability
• some kind of unique identifier for the alert
• links to relevant additional information (CVE, bugzilla, ...)
• where and how to update the package
• consistent formatting of advisories is a definite plus

The biggest problem seen with alerts of late is a lack of information about the problem they are fixing. As an example, consider the recent Fedora advisory on kvm. It refers to a recent CVE number (CVE-2008-4539) which is "reserved", but no details are present, and says that it fixes a "cirrus vulnerability". It also references a bugzilla entry that apparently addresses a separate CVE from 2007 (CVE-2007-1320), if you follow that link in the bugzilla, you finally end up somewhere with actual information, though the connection between the two problems is not particularly obvious.

Another example of this is CentOS advisories, which suffer from a number of problems, but the most vexing for folks trying to determine whether they need to update is this lack of bug information. It is not all that hard to get the information as a typical alert has a link to the appropriate Red Hat advisory, but why make users take that step? A concise summary of the bug(s), as well as a reference to the—generally very complete—Red Hat errata, would be quite useful. There is certainly nothing wrong with linking to sources of additional information, but the basics of the problem and its impact should be available in the alert.

Unique identifiers for advisories are useful for a number of reasons: keeping track of which have been addressed, having a unique search string to use, or referring to them in conversations, bug reports, etc. When the identifier is not unique, it muddies the waters a bit, making it more difficult than it needs to be. Sometimes mistakes are made (like the spate of recent Fedora alerts with the same FEDORA-2008-10000 identifier), but there appear to be distribution policies about using identifiers multiple times. CentOS uses the same identifier on multiple advisories, one per architecture, but also shared between CentOS releases. So the same identifier will be applied to an s390 update for CentOS 4 as is applied to x86_64 for CentOS 5.

Another identifier reuse problem comes from Fedora. When mozilla (or more recently xulrunner) library vulnerabilities occur, Fedora pro-actively rebuilds and updates all of the packages that depend on those libraries. This is very much to its credit as the API is not (yet) stable, but all of the resulting alerts refer to the same identifier. For those who try to track vulnerabilities along with alerts, that results in messy listings that don't provide much in the way of helpful information. Other library bugs result in much saner listings where one could relatively easily track down—and keep straight—the advisories for various packages.

There are others problems as well. Alerts that combine unrelated fixes do "avoid flooding mailing lists", but they are a bit painful to tease apart for users that are tracking specific packages. Too much history, in the form of changelogs (example) can also be confusing. If there is only a link to provide vulnerability information, as is the CentOS way, it should probably go directly to a page about the flaw, not to some page that lists all recent upstream flaws (example). And on and on.

Certain distributions have been singled out here, but that is not really the point. These are just recent examples of problems that are regularly seen in distribution security alerts. It should be noted that the commercial distributions (SUSE, Ubuntu, Red Hat, Mandriva) seem to do a much better job overall, which is not surprising, but sometimes they fail as well. The key thing to remember is that security announcements are meant to be read by users and acted upon. If information is lacking, the communication will fail.

This is not the first time we have looked at the problem, way back in 2000 security page editor Liz Coolbaugh took a look at security advisories, and had some of the same complaints seen here. Her conclusion is still valid: it is not that distributions are not trying or that they don't care, but at times the contents of their advisories slip below the radar. After her article, things got better with security alerts, hopefully this gentle prodding will have a similar effect.

Comments (3 posted)

Brief items

A "Grey Hat" guide for security researchers

Comments (21 posted)

New vulnerabilities

cups: denial of service

Comments (none posted)

dovecot: access restriction bypass

Comments (none posted)

gvim: multiple vulnerabilities

Comments (none posted)

hf: arbitrary code execution

int main(int argc, char *argv[])
{
        // snip
        while ((c = getopt(argc, argv, "a:M:c:klhip:m:nt:s:r:Rf23")) != -1)
            switch (c) {

            // snip

                case 'k':
                    system ("killall hfkernel");

            //
}

Comments (none posted)

imlib2: buffer overflow

Comments (none posted)

imp: cross-site scripting

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

libcdaudio: buffer overflow

Comments (none posted)

mozilla: denial of service

Comments (none posted)

nagios: authorization bypass

Comments (none posted)

openoffice.org: insecure temp files

Comments (none posted)

pidgin: multiple vulnerabilities

Comments (none posted)

tog-pegasus: authentication issues

Comments (none posted)

vim: heap-based overflow

Comments (none posted)

vim: sanitization flaws

Comments (none posted)

webkit: arbitrary code execution

Comments (none posted)

yast2-backup: code injection

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current stable 2.6 kernel is 2.6.27.7, also released on November 20. It includes a fair number of fixes, including one with a CVE number attached.

Comments (none posted)

Kernel development news

Quotes of the week

+/*
+ * "Define 'is'", Bill Clinton
+ * "Define 'if'", Steven Rostedt
+ */
+#define if(cond) if (__builtin_constant_p((cond)) ? !!(cond) :		\
+	({								\
+		int ______r;						\
+		static struct ftrace_branch_data			\
+			__attribute__((__aligned__(4)))			\
+			__attribute__((section("_ftrace_branch")))	\
+			______f = {					\
+				.func = __func__,			\
+				.file = __FILE__,			\
+				.line = __LINE__,			\
+			};						\
+		______r = !!(cond);					\
+		if (______r)						\
+			______f.hit++;					\
+		else							\
+			______f.miss++;					\
+		______r;						\
+	}))

Comments (18 posted)

Ksplice and kreplace

The core idea behind Ksplice remains the same: when given a source tree and a patch, it builds the kernel both with and without the patch and looks at the differences. To that end, the compilation procedure is modified to put every function and data structure into its own executable section. That makes life a little harder for the compiler and the linker, but developers are notably insensitive to the difficulties faced by those tools. With things split up this way, it is relatively easy to identify a minimal set of changes in the binary kernel image which result from the patch. Ksplice can then, with some care, patch the new code into the running kernel. Once this work is done, the old kernel is running the new code without ever having been rebooted.

This technique works well for code changes, but different challenges come with changes to data structures. Back in April, Ksplice could not handle that kind of change. Even so, the project's developers claimed to be able to apply the bulk of the kernel's security updates using ksplice. Since then, though, the developers have applied some energy to this problem. With the addition of a couple of new techniques - which require extra effort on the part of the person preparing the patch for Ksplice - it is now possible to apply 100% of the 65 non-DOS security patches released for the kernel since 2005.

In some cases, a kernel patch will simply require that a data structure be initialized differently. The way to handle this change in an update through Ksplice is to modify the relevant data structures on the fly. To effect such changes, a patch can be modified to include code like the following:

    #include <ksplice-patch.h>

    ksplice_apply(void (*func)());

While Ksplice is applying the changes - and while the rest of the system is still stopped - the given func will be called. It can then go rooting through the kernel's data structures, changing things as needed. For example, CVE-2008-0007 came about as a result of a failure by some drivers to set the VM_DONTEXPAND flag on certain vm_area_struct structures. Ksplice is able to apply the fix to the drivers without trouble, but that is not helpful for any incorrectly-initialized VMAs present on the running system. So the modifications to the patch add some functions which set VM_DONTEXPAND on existing VMAs, then use ksplice_apply() to cause those functions to be executed. The result is a fully-fixed system.

Changes to data structure definitions are harder. If a structure field is removed, the Ksplice version of the patch can just leave it in place. But the addition of a new field requires more complicated measures. Simply replacing the allocated structures on the fly seems impractical; finding and fixing all pointers to those structures would be difficult at best. So something else is needed.

For Ksplice, that something else is a "shadow" mechanism which allocates a separate structure to hold the new fields. Using shadow structures is a fair amount of additional work; the original patch must be changed in a number of places. Code which allocates the affected structure must be modified to allocate the shadow as well, and code which frees the structure must be changed in similar ways. Any reference to the new field(s) must, instead, look up the shadow structure and use that version of the field. All told, it looks like a tiresome procedure which has a significant chance of introducing new bugs. There is also the potential for performance issues caused by the linear linked list search performed to find the shadow structures. The good news is that it is only rarely necessary to modify a patch in this way.

The Ksplice developers do not appear to be done yet; from the latest patch posting:

This is an ambitious goal; a single stable series can add up to hundreds of changes, some of which can be reasonably large. It will be interesting to see how many users are really interested in this particular sort of update; sites running critical systems tend to have older "enterprise" kernels which are no longer receiving stable tree updates. But a Ksplice which is flexible enough to handle that kind of update stream should also be useful for distributors wanting to provide no-reboot patches to their customers.

Meanwhile, Nikanth Karthikesan has posted a facility called kreplace. On the surface, it looks similar to Ksplice, but the goal is a little different: its purpose is to allow a developer to quickly try out a change on a running kernel. Kreplace works by simply patching out and replacing one or more functions in the kernel. Kreplace may have its value, but the initial reaction has not been greatly enthusiastic. Among other things, it has been pointed out that Ksplice also has a facility to allow for quick experimentation with changes - though it will be quick only if the developer is already set up to use Ksplice with the running kernel.

A final concern with either of these solutions is that they are, for all practical purposes, employing rootkit techniques. A mechanism which can be used by distributors to patch running systems can also be (mis)used by others. Vendors of binary-only modules could, for example, use Ksplice or kreplace to get around GPL-only exports and other inconvenient features of contemporary kernels. Crackers could also use it, of course, but they already have their own rootkit tools and gain no real benefit from an officially-supported runtime patching mechanism. Whether this aspect of Ksplice is of concern to the development community may be seen in the coming months as this code gets closer to mainline inclusion.

Comments (4 posted)

Character devices in user space

There is a lot of functionality—things like filesystems and device drivers—that are normally considered to be kernel tasks, but have, over time, been allowed to move into user space. The UIO user space driver framework came along in 2.6.23, while filesystems in user space (FUSE) have been around since 2.6.14. Tejun Heo would like to see this idea broadened even further with the character devices in user space (CUSE) patches.

At first blush, the uses for a character device implemented in user space are not obvious. Looking a bit deeper, though, one finds numerous programs—both open and closed source—that rely on legacy character drivers. Those drivers are currently in the kernel, but need not be if there were a way to implement them in user space. In addition, older, deprecated interfaces, such as Open Sound System (OSS) can be better supported without constantly fiddling with the in-kernel emulation.

Providing better OSS support is one of the prime motivators for CUSE as Heo announced in a linux-kernel posting introducing the OSS proxy. The proxy uses CUSE to implement the /dev/dsp, /dev/adsp, and /dev/mixer devices that programs using OSS expect. Adrian Bunk didn't necessarily see this as a good thing:

But Heo sees the current state of OSS emulation as a rather complicated mess that, for better or worse, needs cleaning up:

But there are other uses for CUSE too. Greg Kroah-Hartman notes that legacy software for talking to Palm Pilots, much of which is binary-only, expects to talk to a /dev/pilot serial port. The kernel carries around a driver, but "a libusb userspace program can handle all of the data to the USB device instead". So CUSE could be used to eventually remove another crufty driver from the kernel, while still maintaining compatibility with old user space code.

CUSE is implemented on top of FUSE as there is a fair amount of overlap between them. Character devices and filesystems implement many of the same file operations—things like open(), close(), read(), and write()—which makes them a good match. Heo has a separate patchset for FUSE that implements additional operations for filesystems some of which will be used by CUSE.

The additional FUSE operations include an implementation of ioctl() that is necessarily rather ugly. Because an ioctl implementation can access memory in unpredictable ways—and those data structures can be arbitrarily deep—there needs to be a mechanism for user-space CUSE devices to read and write that memory. The CUSE server does not have direct access to the caller's memory, so a multi-step ioctl() with retries must be implemented. This particular bit of ugliness is only allowed for in-kernel use, so that CUSE (or other things like it) can allow "unrestricted" ioctl() implementations. All FUSE filesystems are still required to have "restricted" ioctls where the kernel can determine the direction and amount of data that is transferred. poll() support has also been added to FUSE, which, in turn, requires a separate patch that allows poll() callbacks to sleep (described in this article).

Once the FUSE changes are in place, the actual implementation of CUSE is relatively small, weighing in around 1000 lines plus some housekeeping to rename and export FUSE symbols. At its core, it collects up a FUSE-mounted filesystem that connects to the user-space implemented device along with the kernel-exported character device, binding the two together. FUSE handles the interaction with the user-space code, in the same way that it does for a filesystem.

CUSE creates a device for commands, /dev/cuse, which is opened by a program that wants to implement a particular character device. CUSE queries the opener to determine which device it is implementing and then creates the device node. For most operations, CUSE just hands off to FUSE, but for open() it, instead, opens a file from the FUSE mount, storing the file handle for use by later operations.

In many ways, CUSE is a kind of impedance matching layer that creates something that acts like a character device, but has no hardware directly behind it. This allows CUSE to ignore things like hardware interrupts; those would need to be handled by something else, typically a downstream driver—the soundcard driver in the OSS proxy case. This is one of the big differences between UIO and CUSE. UIO is much more like a regular kernel device driver that requires kernel code to handle interrupts. CUSE drivers, on the other hand, can be created without ever touching kernel space.

The only objection so far seems to be Bunk's complaint about supporting OSS when it has been deprecated for so long. As Heo points out, though, there are still many applications that only support OSS. In addition, all of the code that has been submitted is "way smaller than the in-kernel ALSA OSS emulation which is somewhat painful to use these days", Heo says. Since there are other potential users of CUSE, not just the OSS proxy, it would seem that, absent any major objections, CUSE could make it into 2.6.29.

Comments (5 posted)

Driver API: sleeping poll(), exclusive I/O memory, and DMA API debugging

poll()

Most of the functions in the file_operations structure are concerned with I/O. So it is not surprising that these functions are allowed to sleep. Except that, as it turns out, one of them - poll() - cannot. There is nothing inherent in the poll() or select() system calls which would require the driver poll() callback to be nonblocking; this requirement is, instead, a result of the implementation. In essence, the core poll() implementation looks like this:

    for (;;)
        set_current_state(TASK_INTERRUPTIBLE)
    	for each fd to poll
	    ask driver if I/O can happen
	    add current process to driver wait queue
        if one or more fds are ready
	    break
 	schedule_timeout_range(...)

The problem is relatively straightforward: if a specific driver chooses to sleep in its poll() callback, the current task state will get set back to TASK_RUNNING and schedule_timeout_range() will return immediately. So a sleeping driver turns the main loop into a busy-wait.

The solution, as developed by Tejun Heo, is also straightforward. His patch causes sys_poll() to define a custom wakeup function which, in turn, sets a new triggered flag when called. That eliminates the need to put the process into TASK_INTERRUPTIBLE for the duration of the main loop; that can be done, instead, right before actually sleeping.

Most driver writers can remain unaware of this change, which looks highly likely to be merged for 2.6.29. But, for those who need it, there will be one more degree of flexibility in the implementation of poll() callbacks.

Exclusive I/O memory

For a while, developers involved in the hunt for the e1000e corruption bug thought that the X server might be the problem. The real bug turned out to be elsewhere, but the suspicion cast upon X led to the development of a new API designed to make it harder for user-space programs to interfere with the operation of an in-kernel driver.

In particular, it seemed sensible to prevent user space from manipulating I/O memory which has been allocated by device drivers. This can be achieved by not allowing an mmap() call on /dev/mem to map regions already given to drivers. If the STRICT_DEVMEM configuration option is set, the kernel will protect its own memory from mapping by user space; protecting I/O memory is really just a matter of extending that mechanism.

Arjan van de Ven has implemented that feature in his MMIO exclusivity patch. He chose, however, not to make this protection the default. Instead, drivers which want exclusive access to an I/O memory region should call one of these new functions:

    int pci_request_region_exclusive(struct pci_dev *pdev, int bar, 
                                     const char *res_name);
    int pci_request_regions_exclusive(struct pci_dev *pdev, 
                                      const char *res_name);
    int pci_request_selected_regions_exclusive(struct pci_dev *pdev,
				               int bars, 
					       const char *res_name);

There is also a new, low-level allocation macro:

    request_mem_region_exclusive(start, n, name);

In each case, these functions are equivalent to their non-exclusive cousins, except for the changed name and the resulting exclusive allocation.

There may be cases where a developer wants to be able to map a region from user space on a development system, regardless of what the driver thinks. For such situations, there is a new iomem=relaxed boot parameter. When relaxed is selected, exclusive allocations are not enforced. Clearly this is not an option which one would want to set on a production system, but it may be useful in development environments.

DMA API debugging

The last topic is not actually an API change, but it's worth a look anyway. The kernel provides a nice API for setting up DMA operations. In many cases, the associated functions do little or no work; the system they are running on does not require any additional effort. The result is that a lot of "tested" driver code may, in fact, have serious errors in its use of the DMA API. When those drivers are run on a different system - one with an I/O memory management unit (IOMMU) in particular - those errors could lead to no end of unpleasant behavior.

Kernel developers like the idea of finding bugs before they bite users on remote systems. To help make that happen with the DMA API, Joerg Roedel has posted a new DMA API debugging facility. This feature, when built into the kernel, should make it possible to find a number of previously-hidden bugs in device drivers. It has, in fact, already turned up a few problems with in-tree drivers, mostly in the networking subsystem.

Use of this facility simply requires enabling a configuration option; the API itself does not change. Once it's enabled, this code will check for a number of problems, including freeing DMA buffers with a different size than was given at allocation time, freeing buffers which were never allocated at all, mixing coherent and non-coherent functions on the same buffer, confusion over I/O directions, and more. Each of these problems might slip by on a developer's test system, but might create havoc where an IOMMU is being used. When a problem is found, a warning and stack traceback are logged.

The response to this API has been positive. The biggest complaint seems to be about the fact that this API is implemented as an x86-specific feature. So it will probably have to be made generic before merging - after all, developers on other platforms are entirely capable of introducing DMA-related bugs too. Once it goes in, this feature should probably be enabled on any system used for driver development.

Comments (none posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 2.6.28-rc6. (November 21, 2008)

• Greg KH: Linux 2.6.27.7. (November 21, 2008)

Core kernel code

• Keika Kobayashi: softirq: Introduce statistics for softirq. (November 21, 2008)

• Nikanth Karthikesan: kreplace: Rebootless kernel updates. (November 23, 2008)

• Jeff Arnold: Ksplice: Rebootless kernel updates. (November 23, 2008)

• Joe Korty: create /proc/timer-wheel-list. (November 23, 2008)

• Tejun Heo: poll: allow f_op->poll to sleep. (November 23, 2008)

• Mathieu Desnoyers: [RFC PATCH] Poll : add poll_wait_set_exclusive (fixing thundering herd problem in LTTng). (November 24, 2008)

• Andrey Mirkin: In-kernel process restart. (November 24, 2008)

• Rusty Russell: cpumask conversion patches for sched. (November 24, 2008)

• Peter Zijlstra: hrtimer: removing all ur callback modes. (November 25, 2008)

Development tools

• Catalin Marinas: Kernel memory leak detector (updated). (November 21, 2008)

• Joerg Roedel: DMA-API debugging facility. (November 23, 2008)

• Vegard Nossum: sysrq-j: emergency shell. (November 23, 2008)

• =?utf-8?q?T=C3=B6r=C3=B6k=20Edwin?=: tracing: userspace stacktraces. (November 23, 2008)

• Arjan van de Ven: ftrace: Add a C/P state tracer to help power optimization. (November 24, 2008)

• Arjan van de Ven: [PATCH] scripts: script from kerneloops.org to pretty print oops dumps. (November 24, 2008)

Device drivers

• Tejun Heo: CUSE: implement CUSE, take #2. (November 21, 2008)

• Yu Zhao: PCI: Linux kernel SR-IOV support. (November 23, 2008)

• Shane McDonald: Resurrect IT8172 IDE controller driver. (November 24, 2008)

• Rodolfo Giometti: LinuxPPS (Version 8): the PPS Linux implementation.. (November 24, 2008)

• Arjan van de Ven: resource: allow MMIO exclusivity for device drivers. (November 24, 2008)

• David Daney: ide: New libata driver for OCTEON SOC Compact Flash interface.. (November 24, 2008)

• Hardik Shah: V4L2 driver on Tomis DSS patches. (November 24, 2008)

• Antonio Ospite: gspca: ov534 camera driver. (November 24, 2008)

• hvaibhav@ti.com: TVP514x V4L int device driver support. (November 24, 2008)

• Robert Jarzmik: soc_camera: add format translation structure. (November 25, 2008)

• David Daney: libata: Cavium OCTEON SOC Compact Flash driver (v2). (November 25, 2008)

• Jaya Kumar: [RFC 2.6.27] am300/broadsheet: add E-Ink Broadsheet controller and AM300 kit. (November 26, 2008)

Documentation

• Michael Kerrisk: CLONE_NEWNET documentation. (November 21, 2008)

Filesystems and block I/O

• Gui Jianfeng: introduce bio-cgroup into io-throttle. (November 21, 2008)

• Tejun Heo: FUSE: extend FUSE to support more operations, take #2. (November 21, 2008)

• Tejun Heo: FUSE: implement direct mmap. (November 21, 2008)

• David Howells: Permit filesystem local caching [ver #41]. (November 21, 2008)

• NeilBrown: RFC: allow md devices to disappear when not in use.. (November 24, 2008)

• Evgeniy Polyakov: Distributed storage.. (November 25, 2008)

• Evgeniy Polyakov: Inotify: nested attributes support.. (November 25, 2008)

• Theodore Tso: ext4: add fsync batch tuning knobs. (November 25, 2008)

• Eric Paris: [PATCH -v3 0/8] file notification: fsnotify a unified file notification backend. (November 25, 2008)

Memory management

• Ying Han: page_fault retry with NOPAGE_RETRY. (November 23, 2008)

• Lee Schermerhorn: - support inheritance of mlocks across fork/exec. (November 25, 2008)

Networking

• Patrick McHardy: pkt_sched: add DRR scheduler. (November 24, 2008)

• Eric Dumazet: net: Convert TCP/DCCP listening hash tables to use RCU. (November 24, 2008)

• Stephen Hemminger: netdev: generate kobject uevent on network events.. (November 24, 2008)

• Inaky Perez-Gonzalez: merge request for WiMAX kernel stack and i2400m driver. (November 24, 2008)

Architecture-specific

• Dimitri Sivanich: SGI RTC: add clocksource/clockevent driver and generic timer vector. (November 24, 2008)

• Antonio R. Costa: [RFC PATCH] Support for AT572D940HF-EK [RFC PATCH]. (November 25, 2008)

Security-related

• Tetsuo Handa: TOMOYO Linux. (November 21, 2008)

• Mimi Zohar: integrity. (November 21, 2008)

Benchmarks and bugs

• Rafael J. Wysocki: 2.6.28-rc6-git1: Reported regressions from 2.6.27. (November 23, 2008)

• Rafael J. Wysocki: 2.6.28-rc6-git1: Reported regressions 2.6.26 -> 2.6.27. (November 23, 2008)

Miscellaneous

• Hans de Goede: libv4l release: 0.5.6 (The UVC release). (November 24, 2008)

• Luis R. Rodriguez: CRDA and wireless-regdb release. (November 26, 2008)

Page editor: Jake Edge

Distributions

News and Editorials

Interview with Paul Frields

To begin with, we talked about Fedora's new Special Interest Group (SIG) for servers running Fedora. Fedora is a fast-paced distribution, and therefore not suitable for all servers. There are many places Fedora makes an excellent server, though. Some of those uses are: in house, non-internet facing servers or servers with a separate firewall. It is used in server farms and home servers, and other places where the 13 month life cycle is not a problem. The roadrunner supercomputer, a hybrid cluster with both IBM PowerXCell and AMD Opteron processors runs both Red Hat Enterprise Linux and Fedora. Roadrunner holds the number 1 spot in the top500 list.

Fedora is more than a bleeding edge desktop, although it is good at that. Fedora sponsors the development of many projects through FedoraHosted.org, and provides many other contributions to upstream projects. Extra Packages for Enterprise Linux (EPEL) is a community effort by Fedora developers to provide high-quality add-on packages that complement Red Hat Enterprise Linux and its compatible spinoffs such as CentOS or Scientific Linux. Fedora also contributes to The One Laptop Per Child (OLPC) project. Fedora does serve many needs.

Including those of "remixers", the creators of derivative distributions. The new trademark guidelines, still in draft form, are designed to spell out the DOs and DON'Ts of creating a remix. Remixers can chose packages from the official Fedora repository, EPEL, RPMFusion and other repositories. Packages can also be built from source, with or without patches; to create the distribution they want.

Naturally, I asked Paul about the infrastructure/security problems that were announced last August. LWN covered the issue in August and September. We have yet to see a final analysis of what happened. Paul did say that a team of Red Hat engineers and Fedora volunteers rebuilt everything from scratch, and signed the packages with new keys. Beyond that, we were told that the investigation is ongoing and more information will be available once the investigation is complete.

Fedora 10 was announced this week, along with the RPM Fusion and ATrpms repositories, updated for Fedora 10. Here are some highlights of this release.

With Fedora 9 it became possible to create a persistent USB device, that is a key that can be updated, remember settings and store some data. With Fedora 10 you have all that, plus you can encrypt your home directory on the key.

The new NetworkManager features connection sharing to enable collaboration everywhere. PackageKit advances the software management system with its ability of using yum, apt, conary, and other existing tools. PackageKit can search for codecs, listen to dbus and communications between applications. With the long-term roadmap for PackageKit, this utility will understand what packages you need and will get it for you. F10 has faster boot times, kernel mode settings and improved virtualization with KVM.

Paul said that the number of Fedora Ambassadors doubles each year. The ambassador program is world-wide, with people who represent the Fedora Project to the wider public, help spread the word about Fedora, Linux, and Open Source, become a point of contact for local community members and channel the feedback to Fedora Project, help recruit project contributors and think of creative ways for promoting Fedora.

Fedora 10 has more official spins than ever before. These are specialized distributions that contain only packages in the main Fedora repository. A small sampling includes the Fedora Electronics Lab (FEL) Spin, Fedora KDE Desktop, Fedora Edu/Math Spin and Fedora XFCE Desktop. So check out Fedora 10, or one of the many spins and remixes that are available.

Comments (none posted)

New Releases

Fedora 10 released

Comments (32 posted)

LFS 6.4 is released

Full Story (comments: none)

Ubuntu Jaunty Alpha 1 released

Full Story (comments: none)

Distribution News

Debian GNU/Linux

Bits from the buildd.debian.org world

Full Story (comments: none)

Fedora

Fedora IRC Board Meeting Recap

Full Story (comments: none)

Gentoo Linux

The Gentoo Council

Comments (none posted)

Slackware Linux

Slackware Changelog

Full Story (comments: none)

SUSE Linux and openSUSE

openSUSE Sports a New License (Ding dong, the EULA’s dead…)

Comments (9 posted)

YaST Mascot Winner Chosen! Say Hello to Yastie!

Comments (none posted)

Other distributions

rPath Spurs Operating System Evolution with Ubuntu, CentOS Support

Full Story (comments: 8)

A New Direction for Shift Linux

Comments (none posted)

Happy Birthday sidux

Comments (none posted)

New Distributions

"INX Is Not X", Version 1.0

Comments (none posted)

Distribution Newsletters

DistroWatch Weekly, Issue 279

Comments (none posted)

Fedora Weekly News #153

Full Story (comments: 1)

openSUSE Weekly News, Issue 47

Full Story (comments: none)

PCLinuxOS Magazine, Issue 27

Comments (none posted)

Ubuntu Weekly Newsletter #118

Full Story (comments: none)

Interviews

Fedora 10: the GNU/Linux Desktop Steps Forward (Datamation)

Comments (none posted)

Defending the flame of Linux freedom (TechRadar)

Comments (14 posted)

Distribution reviews

SimplyMEPIS: The best desktop Linux you haven't tried (Linux.com)

Comments (none posted)

Page editor: Rebecca Sobol

Development

FFADO approaches the 2.0 release

The FFADO (Free Firewire Audio Drivers) project allows the support of FireWire (IEEE 1394) audio devices under Linux:

The About document explains further: "We try to support any FireWire device available out there. The FFADO codebase is a framework that has been built with this in mind. This however doesn't mean that all FireWire devices work with FFADO. In order to support a device, we need cooperation from manufacturers, or somebody that want[]s to reverse engineer the protocol. Luckily we have support from the manufacturers of the three major platforms vendors build their devices around (BridgeCo, TC Applied Technologies and ECHO). The exact devices supported (or not supported) can be found on our device list."

Release candidate 1 of FFADO 2.0 was announced this week: "This release candidate is intended to collect feedback about the library under wide-spread usage. The code should be free of major bugs. We are looking for packagers that are interested in creating packages for their favorite distribution. Please contact us if you can help us out with this." Users of FreeBoB are encouraged to try this release out.

The full change Log shows the latest changes to the software, most of the work involves bug fixing. The feature list is also found there. Capabilities include:

• Support for an unlimited number of 24-bit audio I/O channels.
• Support for all device sample rates.
• Support for an unlimited number of MIDI I/O channels.
• Support for the S/PDIF audio interface format.
• Support for the ADAT SMUX I/O format.
• Support for external synchronization.
• Support for internal mixers and other device controls.
• Support for device aggregation on an externally synced bus.

If your favorite application requires FireWire support, or you need to migrate away from the unsupported FreeBoB library, now would be a good time to give FFADO a try.

Comments (none posted)

System Applications

Database Software

PostgreSQL Weekly News

Full Story (comments: none)

SQLite release 3.6.6.1 announced

Comments (none posted)

Filesystem Utilities

e2compr for linux-2.6.27.5 announced (SourceForge)

Comments (none posted)

pam_mount: 1.4 released (SourceForge)

Comments (5 posted)

Web Site Development

Django 1.0.2 released

Comments (none posted)

Gallery 1.5.10 and 1.6-RC3 Released - Last G1 Releases from (SourceForge)

Comments (none posted)

nginx 0.6.33 is available

Comments (none posted)

Xoops Cube Project: Package_Legacy 2.1.6 released (SourceForge)

Comments (none posted)

Miscellaneous

Free-SA: 1.5.0 (SourceForge)

Comments (none posted)

Desktop Applications

Audio Applications

Ardour 2.7 released

Full Story (comments: none)

Early release of jackctlmmc announced

Full Story (comments: none)

BitTorrent Applications

Azureus: Vuze 4.0.0.4 released (SourceForge)

Comments (none posted)

Desktop Environments

GNOME Software Announcements

• Anjuta 2.24.2 (bug fixes and translation work)
• bug-buddy 2.24.2 (bug fix and translation work)
• Cheese 2.24.2 (new features, bug fixes and translation work)
• Deskbar-Applet 2.24.2 (bug fixes and translation work)
• Evince 2.24.2 (bug fixes and translation work)
• Eye of GNOME 2.24.2 (bug fixes and translation work)
• Gcalctool 5.24.2 (bug fixes and translation work)
• GLib 2.18.3 (bug fixes and translation work)
• gnome-applets 2.24.2 (bug fix, documentation and translation work)
• Gnome Games 2.24.2 (bug fixes and translation work)
• GObject-Introspection 0.6.1 (new features and bug fixes)
• GTK+ 2.14.5 (bug fixes and translation work)
• GtkImageView 1.6.3 (unspecified)
• gtkmm-utils 0.4.0 (new features)
• IcedTea 1.8 (new features and bug fixes)
• librep 0.17.2 (new features, bug fixes and code cleanup)
• libspectre 0.2.2 (bug fixes)
• LibUnique 1.0.4 (bug fixes)
• libxklavier 3.8 (new feature)
• metacity 2.25.8 (bug fixes and translation work)
• metacity 2.25.13 (new feature, bug fixes and translation work)
• mousetweaks 2.24.2 (bug fixes and translation work)
• Nemiver 0.6.4 (bug fixes and translation work)
• Orca 2.24.2 (bug fixes and translation work)
• rep-gtk 0.18.3 (bug fixes)

Comments (none posted)

KDE Software Announcements

• Amarok 2.0 RC 1 (new features and bug fixes)
• Amarok Scripts:
  • Austrian Radio Streams Service 0.1 (initial release)
  • Bulgarian Radio Stations Script 1.0 (initial release)
  • Danish Radio Streams Service 0.1 (initial release)
  • Free Music Charts 1.1.1 (update for latest Amarok)
  • German Radio Streams Service 0.1 (initial release)
  • Radio Sweden 0.1 (initial release)
  • Serbian Radio Streams Service 0.1 (initial release)
• dictconv-tool 0.1 (initial release)
• Fresh Memory 0.4-alpha (new features)
• FunEyes 1.0 Beta 2 (initial release)
• Firewall Builder 3.0.2 (new features, bug fixes and performance improvements)
• Ksshaskpass 0.5.0 (port to KDE 4)
• LilyKDE 0.6.6 (minor improvements and translation work)
• MDic Dictionary 0.6.3 (new features and bug fixes)
• Opeke 0.3.1 (bug fix)
• QTrans 0.2.1 (change from KHtml to QtWebKit)
• Soprano 2.1.64 (bug fixes and code cleanup)
• Start KeyJNote presentation 0.1 (initial release)
• Valknut 0.3.22 / 0.4.8 (bug fixes and other improvements)
• Zhu3D 4.1.6 (new features, bug fixes and code cleanup)

Comments (none posted)

Xorg Software Announcements

• xcb-util 0.3.1 (new features and bug fixes)
• xorg-server 1.5.99.1 (first beta release on the 1.6 branch, many changes)

Comments (none posted)

Desktop Publishing

Asymptote: 1.52 released (SourceForge)

Comments (none posted)

pdftools.pdfposter 0.4.5

Full Story (comments: none)

Educational Software

SchoolTool 1.0 beta released

Full Story (comments: none)

Financial Applications

LedgerSMB 1.2.17 released

Full Story (comments: none)

Graphics

G3D Engine: 7.01 Released (SourceForge)

Comments (none posted)

Interoperability

Wine 1.1.9 announced

Comments (none posted)

Mail Clients

Sylpheed 2.6.0beta2 (development) released

Comments (none posted)

Multimedia

Elisa Media Center 0.5.19 Release

Full Story (comments: none)

Music Applications

guitarix third release announced

Full Story (comments: none)

Office Suites

KOffice 2.0 Beta 3 released (KDE.News)

Comments (none posted)

Languages and Tools

Assembly Language

CorePy 1.0 released

Full Story (comments: none)

Caml

Caml Weekly News

Full Story (comments: none)

Eiffel

Gobo Eiffel Project: 3.9 released (SourceForge)

Comments (none posted)

Java

[fleXive]: 3.0.1 released (SourceForge)

Comments (none posted)

Perl

This Week on perl5-porters (use Perl)

Comments (none posted)

Python

PyEnchant 1.5.0 released

Full Story (comments: none)

Python 3.0rc3 is available

Full Story (comments: none)

Python-URL! - weekly Python news and links

Full Story (comments: none)

Sphinx 0.5 released

Full Story (comments: none)

Tcl/Tk

Fltk for Tcl/Tk 1.0

Comments (none posted)

IDEs

CodeLite: v1.0.2419 is available (SourceForge)

Comments (2 posted)

Miscellaneous

Gforth 0.7.0 released

Full Story (comments: none)

Pygments 1.0 released

Full Story (comments: none)

Page editor: Forrest Cook

Linux in the news

Recommended Reading

Observations on power management

Comments (39 posted)

Robotic arm runs Linux (LinuxDevices)

Comments (2 posted)

The SCO Problem

Final Judgment in SCO v. Novell: SCO Loses Again (Groklaw)

Comments (1 posted)

SCO Files Notice of Appeal in Novell Litigation (Groklaw)

Comments (2 posted)

Companies

Novell, Microsoft ready management pack for SUSE Linux (TechTarget)

Comments (3 posted)

Interviews

Mandrake Linux Founder Back, Virtually (Internetnews.com)

Comments (none posted)

Interview with Jokosher maintainer Laszlo Pandy (GnomeDesktop.org)

Comments (none posted)

Resources

Carrier Grade Linux 4.0 - Raising the bar (Electronics Weekly)

Comments (none posted)

GCC hacks in the Linux kernel (developerWorks)

Comments (16 posted)

Miscellaneous

Linux Guru Reiser Seeks New Murder Trial (Wired)

Comments (26 posted)

Page editor: Forrest Cook

Announcements

Non-Commercial announcements

RosettaNet reinstates free standards access

Full Story (comments: none)

Commercial announcements

A Mozilla year-end report

Comments (8 posted)

VIA releases chipset documentation

Comments (34 posted)

New Books

JRuby Cookbook - New from O'Reilly

Full Story (comments: none)

New Book, After the Software Wars

Full Story (comments: 1)

SQL in a Nutshell--New from O'Reilly

Full Story (comments: none)

Resources

TuxMobil Surpasses 8,000 Linux Installation Guides Available

Full Story (comments: none)

Education and Certification

MontaVista webinars assist with migration to embedded Linux

Comments (none posted)

Calls for Presentations

Call For Papers opens for ApacheCon US 2009

Full Story (comments: none)

CanSecWest 2009 CFP

Full Story (comments: none)

FRHACK 01 Call For Papers

Full Story (comments: none)

NLUUG spring conference CfP

Full Story (comments: none)

Upcoming Events

FTC Announces First in Series of Hearings on Evolving Intellectual Property Marketplace

Comments (10 posted)

Gran Canaria Desktop Summit 2009

Full Story (comments: none)

Events: December 4, 2008 to February 2, 2009

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

Page editor: Forrest Cook