LWN.net Weekly Edition for December 10, 2009

A look at Qt 4.6

Nokia updated its Qt application framework to version 4.6 on December 1st, adding support for several operating systems — most notably its own mobile platforms: the recently open source Symbian and the Linux-based Maemo. Qt 4.6 introduces new graphics features, new input methods, and updates to the QtScript scripting engine. Along with the framework itself, Nokia updated its cross-platform Qt integrated development environment (IDE) Qt Creator to support the new features and new target platforms.

Qt everywhere

Previous releases of Qt have supported Linux, similar X11-based Unix clones, Mac OS X, and Windows desktop operating systems, plus embedded Linux systems and the Windows smartphone platforms (Windows CE and Windows Mobile). Qt 4.6 updates the proprietary platform support to the latest offerings from Apple and Microsoft: Mac OS X 10.6 and Windows 7.

More interesting to open source users is the official addition of three mobile platforms to the line-up: Symbian S60, Maemo 5 "Fremantle," and the still-in-development Maemo 6 "Harmattan." S60 was Nokia's platform of choice for high-end smartphones for years, but its recent moves indicate it is positioning Symbian as a lower-end phone operating system and cultivating Maemo for high-end devices. "Preview" Qt releases for both S60 and Maemo 5 have been periodically released over the past year, but the platforms' official support in 4.6 is new.

Given that the first Maemo 5 device (Nokia's N900) only started shipping in November, support for Maemo 6 may sound premature. The early release is in line with Nokia's past Maemo development behavior, however. The core Nokia-developed applications in Maemo 6 will be rewritten in Qt instead of GTK+ and Hildon, and Qt will be designated the officially supported toolkit for application development. Nokia has long tried to get development tools into the hands of the open source community as early as possible to accelerate Maemo application development, and the Maemo 6 shift in toolkits is undoubtedly a disruption the company wants to minimize.

Inside the release

The headlining new features in 4.6 are the Qt Animation Framework and State Machine Framework. The two APIs work together; more generally the state machine framework allows application developers to construct their code around state graphs, in which the system reacts to stimuli such as user input by changing between pre-defined states — hopefully leading to better dynamic user interfaces. As the documentation points out, writing a state-based application is not required, and simple applications may not see the benefit. But using the state machine does open up some other useful APIs, including animation.

The animation framework allows developers to animate transitions between states, rather than defining animations as timeline-based behavior triggered by events. The animation framework automatically interpolates between the "start" and "stop" states of the animated object, and handles pausing, synchronizing multiple animations, and other details.

Two new input methods debut in 4.6, gesture input and multi-touch. Multi-touch builds on the existing touch-sensitive interface of the QTouchEvent class. Qt now handles multiple QTouchEvents simultaneously, and can send different events to different widgets, or to the same widget. The framework maintains backward-compatibility with older code by translating QTouchEvents into QMouseEvents for multi-touch unaware applications. Gestures are built on top of multi-touch, as gestures may involve multiple touch points. The QGestureEvent class provides gesture descriptions and handling.

The QGraphicsEffect class allows Qt to perform basic visual effects on arbitrary elements, including blurring, drop-shadowing, colorization, and changing opacity. There are also new classes in 4.6 to handle audio, and a Qt3D API to simplify writing 3-D applications.

Nokia highlights several changes as "performance optimizations." Some, like a new renderer for the QGraphicsView class, are enhancements to existing features. Others, such as the QContiguousCache class (which enables more efficient memory caching by keeping larger chunks of cached data in contiguous locations) and hardware-acceleration for 2-D vector graphics via the OpenVG API, qualify as new features in their own right.

Several key pieces of code for web integration made their way into 4.6. QtScript, the framework's JavaScript/ECMAScript scripting engine, has a new backend in 4.6 based on WebKit's JavaScriptCore, which is reportedly considerably faster. The QWebElement class provides an API to access and manipulate the document object model (DOM) of both web pages and XML documents.

Qt Creator and ... world domination?

The Qt Creator IDE was bumped to version 1.3 when Qt 4.6 was released and supports the new features of the toolkit. The official changelog details a long list of improvements, most of which fall under the category of regular enhancements to a still-growing IDE: improved syntax highlighting and semantic parsing, better searching, better code refactoring, and so on.

It is telling, however, that here again Nokia's press releases lead off with the fact that Qt Creator now supports Symbian as a target platform. Nokia's corporate interest is in building Qt into a cross-platform toolkit and SDK that can run on every platform available. Linux users may occasionally lose sight of that fact because of the framework's prominence in desktop projects like KDE (which will be migrating to 4.6 in version 4.4.0). But in the broader technology market, the sheer number of Symbian-powered phones (half of all smartphones, on the order of hundreds of millions) dwarfs the desktop Linux market easily.

Symbian is now open source, of course, following its 2008 acquisition by Nokia. Maemo may be the company's ace in the hole for future smartphone products, but Qt is the tool it will use to keep the programmers developing for those millions of smartphones from migrating to other platforms as Maemo matures.

Fortunately for open source users, Nokia seems to be working well with the community. In addition to its code contributions, Nokia has also opened up the Qt development process itself, accepting around 160 code contributions from outside the company, and making the source code repository and official bug tracker publicly accessible. Qt 4.6 adds some exciting new features, including multi-touch gestures and an easy-to-use animation API. But the open development process that brought it to market is just as welcome.

Comments (11 posted)

SELinux and PostgreSQL: a worthwhile union?

SELinux works by attaching labels to objects and roles to actors, then enforcing rules describing what sort of access to objects with specific labels is allowed to specific roles. It is a highly flexible system, but also highly complex; even a minimal SELinux policy can involve thousands of rules. The complexity of SELinux has almost certainly inhibited its adoption in the broader Linux community; when SELinux gets in the way of real work, figuring out how to fix it can be a nontrivial task. Over the years, many administrators have concluded, like Ted Ts'o, that "life is too short for SELinux."

That said, Fedora and Red Hat have slowly made progress in using SELinux to confine parts of the system without creating too much user pain. And there is certainly a place for more comprehensive security models in general. But once one starts protecting data at the filesystem level, it makes sense to ask whether data which is accessed through higher-level mechanisms - a relational database manager, say - should also be subject to the system's security policies. In an ideal world, the same security policy would be operative at all levels.

That is the idea behind SE-PgSQL. With this patch, a database administrator can assign labels to databases, schemas, rows, and columns, then write access control rules for them. These are SELinux rules, which are evaluated by SELinux and enforced by PostgreSQL. So access to objects within the database can be governed by the same policy as access to objects elsewhere in the system. On the surface, it is an elegant concept. It is also a concept that NEC (KaiGai's employer) sees as an important component of its future offerings based around cloud computing. For this reason, NEC has funded this work for the last couple of years.

The world is full of free software projects which are starved for developers and which would be overjoyed to accept a feature contribution at this level. The PostgreSQL hackers are somewhat more finicky, though. As is the case with a number of longstanding, successful projects, PostgreSQL developers understand that they will be maintaining any code they accept for many years, and that they cannot afford to accept code which might compromise the project's reputation for stability. So they have been balking at merging SE-PgSQL.

There would appear to be two specific objections getting in the way of this patch: (1) it's big, complicated, and hard to understand, and (2) it's not clear that the benefit of merging this functionality will be worth the costs.

To address the first qualm, KaiGai has worked to minimize the patch to the greatest extent possible, stripping out much of the functionality in the process. Among other things, the latest version of the code does not support row-level labeling. He has also written some extensive documentation which should be required reading for anybody wanting to understand how this patch should work. The end result is a patch which still weighs in at 13,000 lines - but the bulk of it is documentation and regression tests.

PostgreSQL hacker Bruce Momjian was pleased with the reduced patch, saying that is "exactly what I was hoping to see." He also noted, though:

He expressed willingness to do the review, but requested help from developers who understand SELinux better. KaiGai has offered to try to round up such a developer, so, with luck, this particular obstacle can be overcome.

That leaves the cost/benefit question. The strongest critic of this patch is almost certainly Tom Lane, who said:

On the other hand, Josh Berkus noted that he has seen interest in the feature:

This unwillingness to speak up on the part of potential users could well doom this patch. The code probably cannot be minimized much further without becoming pointless, and even a contributor as persistent and patient as KaiGai can only get discouraged eventually. It would not be surprising if this PostgreSQL development cycle were the last go-round for SE-PgSQL if it is not accepted.

Part of participating in a free software community is contributing code. But another important part is providing feedback to the developers. Otherwise, they are unlikely to know which development directions make sense for many of their users, and they might just turn down patches which their users would rather see incorporated. Companies are often reluctant to talk about their security needs and plans. But, for potential SE-PgSQL users, that kind of silence at this time could be counterproductive. If nobody shows up to express a need for SELinux integration into PostgreSQL, the developers might conclude that there is no interest in this feature and act accordingly.

Comments (22 posted)

The 2009 Linux and free software timeline - Q2

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 April-June 2009. Over the next few weeks, we will be putting out timelines of the other two quarters of the year.

First quarter timeline (Jan-Mar 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.

CentOS 5.3 released. (announcement)

Ardour, the multi-track audio editor, releases version 2.8. (announcement)

Intel turns over stewardship of Moblin to the Linux Foundation. (press release)

SGI acquired by Rackable Systems for $25 million. (press release)

Openmoko downsizes and stops work on the GTA03 to focus on the then-mysterious "Project B" (Steve Mosher email, PDF slides from Sean Moss-Pultz's presentation)

Steve McIntyre is re-elected as Debian project leader. (announcement)

Oracle buys Sun, though surely they didn't think it would be held up in the EU regulatory process until at least December. (announcement)

GCC 4.4.0 is released. (announcement, LWN coverage)

Ubuntu 9.04, "Jaunty Jackalope", is released. (announcement)

NetBSD 5.0 is released. (announcement, LWN review)

Mandriva 2009 Spring (2009.1) released. (announcement)

A patch to avoid Microsoft's VFAT patent claim, which was asserted in the TomTom lawsuit, is proposed on linux-kernel. (LWN article)

OpenBSD 4.5 is released. (announcement)

Debian announces a switch to EGLIBC, instead of glibc for its C runtime library. (announcement, LWN article)

OpenOffice.org 3.1 is released. (announcement)

AMD releases 3D programming guide for R6xx/R7xx chips. (announcement)

Slackware64 is released—based on Slackware 13.0, it is the first official 64-bit Slackware release. (announcement)

Cisco and the Free Software Foundation settle a GPL compliance lawsuit; Cisco will appoint a Free Software Director for its Linksys subsidiary. (announcement)

Linux Mint 7 ("Gloria") distribution is released (announcement, LWN review)

Wikipedia switches from the GNU Free Documentation License to the Creative Commons attribution-sharealike license. (announcement, LWN coverage)

TurboGears 2.0 is released; it is a Python-based web application framework. (announcement)

KOffice 2.0.0 is released. (announcement)

The US Supreme Court agrees to hear the Bilski case, which could change the software patent landscape. (SCOTUS Blog report)

The 2.6.30 kernel is released with the TOMOYO security module, nilfs filesystem, reliable datagram sockets, FS-Cache, and more. (announcement, KernelNewbies coverage)

Fedora 11 ("Leonidas") is released. (announcement)

Intel acquires embedded Linux vendor Wind River Systems. (press release)

KDE audio player Amarok 2.1 is released. (announcement, LWN review)

Ubuntu announces switch to the GRUB2 bootloader for 9.10 ("Karmic Koala"). (announcement, LWN coverage)

Sugar Labs announces Sugar on a Stick "Strawberry" featuring Fedora 11 and Sugar learning environment version 0.84. (announcement)

Richard Stallman warns about dependence on Mono and C#,which stirs up a lot of controversy. (RMS's warning, LWN coverage)

Firefox 3.5 is released with private browsing, HTML5 video and audio support for Ogg Theora and Vorbis, a faster JavaScript engine, and more. (announcement)

PHP 5.3 is released. (announcement)

Python 3.1 is released, focusing on the "stabilization and optimization of the features and changes that Python 3.0 introduced". (announcement)

The Ogg codecs (Vorbis and Theora) are dropped from HTML5, which means there will be no standard codecs for <video> and <audio> in HTML5. (announcement)

Comments (2 posted)

Page editor: Jonathan Corbet

Security

Pogoplug makes internet data sharing easy

A recent article in Computerworld introduced a new product, the Pogoplug, which has a number of interesting and useful-sounding features. It is also likely to be something of a security headache for network administrators. It simplifies the setup of a internet-connected storage device, but it also uses UDP in a way that may circumvent the firewall restrictions on some networks.

As a device, the Pogoplug isn't really anything particularly special. It consists of an ARM processor with a bit of memory and flash, along with some USB ports and a gigabit ethernet connector. None of the technical capabilities of the Pogoplug are terribly sophisticated, but as would be expected for a consumer device like this, it runs Linux under the covers. It is the service that is provided by CloudEngines, the company behind Pogoplug, that turns it into something beyond a simple embedded Linux box.

To use the Pogoplug, you connect it to the ethernet, a USB drive (or stick), and power it up. After that, browse to my.pogoplug.com, create an account, and wait a few minutes for an email with a link containing the magic code for your Pogoplug. Clicking that link takes you to a page that displays the contents of the USB drive attached to the Pogoplug. And you can do that from anywhere on the internet.

The Pogoplug relies on being able to send and receive UDP packets over the internet to and from port 4365. If that is true, based on the network the Pogoplug is attached to, it can be accessed from anywhere else on the internet. The device can be configured to share its data with other users via links, RSS feeds, email notifications, and so forth. It is just the kind of device that will be attractive to some internet-centric folks.

The device itself is not locked down and the OpenPogo site caters to developers. There is information on the wiki about installing various other applications such as MySQL, Django, Ruby on Rails, etc. From that perspective, it looks like a fun, hackable device. But it suffers from a number of pitfalls that might bite the unwary.

To start with, ssh is enabled with a standard root password. That makes it easy for folks that want to change things on the device, but for those who are not particularly savvy, it also leaves the device wide open to anyone else on the network. Presumably the ssh functionality is not exported in whatever UDP tunnel/encapsulation that gets established, so it is safe from ssh logins across the internet. But home users that expect their Pogoplug to be private from their siblings, parents, or roommates may be in for something of a surprise.

There is also the concern that a Pogoplug could expose data—inadvertently or maliciously—from inside a company or other supposedly secure environment. There is nothing technically new about what the Pogoplug can do, but it would have taken someone with some reasonable technical skills to set something like the Pogoplug up. Now, anyone with $129 and a 2G USB stick may be able to publish the entirety of a company's secrets on the web, in just a few minutes.

Certainly many or most corporate firewalls will not pass the Pogoplug traffic, but undoubtedly some will. Various P2P applications have caused inadvertent releases of confidential information from employees who didn't fully understand the technology; Pogoplug is likely to do the same. It is great for folks to be able to share their data with their friends, but unless they fully understand how it works, there are some holes that are pretty likely to be stepped in.

Comments (5 posted)

Brief items

Open-Source Effort to Hack GSM (IEEE Spectrum)

Comments (30 posted)

New vulnerabilities

acpid: privilege escalation

Comments (none posted)

cups: integer overflow

Comments (none posted)

expat: denial of service

Comments (none posted)

flash-plugin: multiple vulnerabilities

Comments (none posted)

gforge: symlink attack vulnerability

Comments (none posted)

gnome-screensaver: lock bypass

Comments (none posted)

grub2: authentication bypass

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

kernel: unprivileged user driver vulnerability

Comments (none posted)

kernel: null pointer dereference

Comments (none posted)

kvm: host denial of service

Comments (none posted)

nginx: denial of service

Comments (none posted)

ntp: denial of service

Comments (none posted)

perl-IO-Socket-SSL: invalid certificate checking

Comments (none posted)

pidgin: denial of service

Comments (none posted)

qemu-kvm: guest crashes

Comments (none posted)

request-tracker: session hijack vulnerability

Comments (none posted)

shibboleth-sp: cross-site scripting

Comments (none posted)

zsh: buffer overflow

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The 2.6.33 merge window is open; see the accompanying article for a summary of the most significant changes merged so far.

Stable kernel updates: 2.6.31.7, containing a very long list of fixes, was released on December 8. 2.6.27.40 was released at the same time; it was quickly followed by 2.6.27.41 to fix a build problem.

Comments (none posted)

Quotes of the week

s/DEFINE_EVENT_CLASS/FRED/g
s/DEFINE_EVENT/WILMA/g
s/TRACE_EVENT/BARNEY/g

Comments (1 posted)

Vger outage on Dec 12th and 13th

Full Story (comments: 2)

Spinlock naming resolved

One possibility was raw_spinlock_t, but that name is already used by the lockdep code. After numerous other possible names were considered, the winning suggestion was one by Linus: arch_spinlock_t. This name carries the connotation of a low-level spinlock which is implemented by architecture-specific code; in the absence of a better idea, it has carried the day.

Thomas Gleixner has posted a patch which makes the naming changes. It's worth noting that even though the new type is not a raw_spinlock_t, one still calls raw_spin_lock() to acquire an arch_spinlock_t lock. As of this writing, this patch has not been merged for 2.6.33, but chances are that it will be.

Comments (2 posted)

Kernel development news

2.6.33 merge window part 1

User-visible changes include:

• The ftrace framework has seen a number of improvements, including the ability to trace multiple processes simultaneously, regular expression support in tracing filters, tracing of big kernel lock events, and tracing of accesses and modifications to arbitrary kernel variables.

• Perhaps most significantly (for ftrace), the dynamic probes for ftrace patch set has been merged, allowing the placement of arbitrary tracepoints at run time. The "perf" tool has also been extended to be able to place and use dynamic tracepoints.

• There are many other enhancements to "perf," including a new framework for benchmark suites, a command to record and analyze kernel memory allocations, and a generic scripting language hook set.

• Eric Biederman's long quest to remove binary sysctl() support has finally made it into the mainline.

• The recvmmsg() system call has been added.

• The anticipatory I/O scheduler has been removed, in favor of CFQ which is seen as providing a superset of features.

• The new, unified block I/O bandwidth controller has been merged.

• The networking layer has gained support for TCP cookie transactions [PDF], a mechanism which allows faster, more secure, and more robust initiation of TCP connections.

• The DRBD distributed block device has been merged.

• New drivers:
  • Boards and processors: ST-Ericsson U8500 boards, Marvell Dove (88AP510) system-on-chip CPUs, Palm Centro 685 phones, and CompuLab CM-T35 boards.

  • Networking: TI High End CAN controllers, Intel Wireless MultiCom 3200 chips, Ralink rt2800 wireless chipsets, Microchip MCP251x SPI CAN controllers, Freescale MSCAN-based CAN controllers, and Solarflare SFC9000 10G Ethernet controllers.

  • Sound: miroSOUND PCM20 radio tuners, Texas Instruments TPA6130A2 stereo headphone amplifiers, TI tlv320dac33 codecs, Asahi Kasei AK4113 and AK4671 codecs, WM8580 based audio subsystems on SMDK64xx systems, Wolfson Micro WM8711/L sound devices, and Raumfeld audio adapters.

  • Miscellaneous: GRLIB APBUART serial ports, Oki MSM6242 realtime clock chips, and Ricoh RP5C01 RTCs.

Changes visible to kernel developers include:

• There is a new unreachable() macro which can be used to mark code which will never be executed. Its main application is in macros like BUG().

• New security module hooks, intended for pathname-based modules, have been added to check chmod(), chown(), and chroot().

• There is a new RCU variant, called "tiny RCU," which is meant for non-SMP situations where memory footprint must be minimized.

• printk_ratelimit() can, once again, be used in atomic context. (Note, though, that there are developers who would like to eliminate this function in favor of some sort of more local rate limiting).

• The creation of nearly-identical tracepoints has been made significantly easier. TRACE_EVENT_TEMPLATE() has a syntax identical to TRACE_EVENT(), but it creates a template which can be used by the simpler DEFINE_EVENT() macro to create specific tracepoints. The code gets simpler, and, as a side benefit, the kernel gets smaller.

The merge window should stay open for at least another week; expect quite a bit more code to be incorporated for 2.6.33 before the window closes.

Comments (8 posted)

Minimizing instrumentation impacts

Minimizing the overhead of various kernel debugging and tracing mechanisms is important for many reasons. For static instrumentation, like tracepoints, the impact when they are not enabled must be very low or they won't get used—or merged. In addition, for any kind of instrumentation, the impact when enabled needs to be as small as possible so that whatever behavior is under observation will not radically change due to the tracing. Two separate proposals, jump labels for tracepoints and kprobes jump optimization, are both trying to reduce the effect that instrumentation has on performance. In addition, they share some underlying code.

The kprobes jump optimization has been proposed by Masami Hiramatsu, and trades off a bit of extra memory for approximately one-fifth the overhead in making a kprobe call. According to Hiramatsu's posting, kprobes went from 0.68us (32-bit) and 0.91us (64-bit) to 0.06us (both) when they were optimized with this technique. kretprobes dropped from 0.95us (32-bit) and 1.21us (64-bit) to 0.30 and 0.35us respectively. All of his testing was done on a 2.33GHz Xeon processor.

Those numbers are pretty eye-opening, especially since the optimization only adds around 200 bytes per probe. The basic idea is to use a jump instruction, rather than a breakpoint, to implement probes whenever that is possible. The patch includes some fairly elaborate "safety checks" to see if it is possible to do the optimization. Before any of that is done, however, a regular breakpoint-based kprobe is inserted—if the optimization can't be done, that will be used instead.

The jump instruction that will be put at the address to be probed is longer than one byte, so the optimization step needs to look at the region of code it will be affecting. If that region straddles the boundary between functions (i.e. spills out of the probed function into the next), the optimization is not done. It then decodes the function looking for jump instructions that would—or could—jump into the region, if none are found, the optimization proceeds.

The instructions that are located at the address to be probed still need to be executed once they are replaced by a jump, of course, so a "detour" buffer is created. The detour buffer emulates an exception that contains the instructions copied from the probed location, followed by a jump back to the original execution path. This detour buffer will be used once the kprobe code itself is executed to finish the execution after the probe point.

Once the detour buffer has been created, the kprobe is enqueued on the kprobe-optimizer workqueue, where the actual jump is patched into the probe site. The optimizer needs to ensure that there are no interrupts executing and does so by using synchronize_sched() in the workqueue function. Once that completes, the text_poke_fixup() function, which is added as part of the patchset, is called to actually modify the code to patch the jump in.

The text_poke_fixup() patch is the piece that is shared with jump labels. It looks like:

    void *text_poke_fixup(void *addr, const void *opcode, size_t len,
                          void *fixup);

Essentially, text_poke_fixup() puts a breakpoint that will execute the code at fixup on addr and synchronizes that on all CPUs. It then modifies all the other bytes (except the first) of the region, once again synchronizing with the other CPUs. The next step is to modify the first byte, again requiring synchronization, and then it can clear the breakpoint. Any calls made during the modification will be routed by the breakpoint to the fixup code instead.

A jump label uses the same technique, but, since it applies to static instrumentation (tracepoints), it is meant to reduce the impact of the likely case that the tracepoint is disabled. It does that by using an assembly construct that will be available in the soon-to-be-released GCC 4.5, the asm goto, which allows branching to labels.

For a tracepoint, the idea is that the disabled case will consist of a 5-byte NOP (conveniently sized to be overwritten with a jump) followed by a jump around the disabled tracepoint code. When the tracepoint gets enabled, text_poke_fixup() is used to turn the NOP into a jump to the label in the DECLARE_TRACE() macro. That code is what the original unconditional jump skips over.

The jump labels patch then has code to manage the state of the tracepoints, including the labels and addresses, along with the current enabled/disabled status of the tracepoint. It is somewhat of a hackish abuse of the pre-processor and assembler, but according to Jason Baron, who proposed the patch, it results in "an average improvement of 30 cycles per-tracepoint on x86_64 systems that I've tested".

Jump labels eliminate the current test and jump that is done for each tracepoint, because it can dynamically enable and disable the tracepoint code. Adding the NOP and unconditional jump add "2 - 4 cycles on average vs. no tracepoint", Baron said, which is a pretty low cost for this kind of instrumentation.

Both of these techniques are likely to need some more "soaking" time before they are ready for the mainline. Jump labels is a more recent proposal and relies on features in a not-yet-released compiler, which would seem to put it a bit further behind. The reaction to both has been relatively positive, though, which probably indicates general agreement with their goals. Reducing the overhead for tracing and debugging is something that few will argue against.

Comments (1 posted)

Debugging the kernel using Ftrace - part 1

Ftrace is a tracing utility built directly into the Linux kernel. Many distributions already have various configurations of Ftrace enabled in their most recent releases. One of the benefits that Ftrace brings to Linux is the ability to see what is happening inside the kernel. As such, this makes finding problem areas or simply tracking down that strange bug more manageable.

Ftrace's ability to show the events that lead up to a crash gives a better chance of finding exactly what caused it and can help the developer in creating the correct solution. This article is a two part series that will cover various methods of using Ftrace for debugging the Linux kernel. This first part will talk briefly about setting up Ftrace, using the function tracer, writing to the Ftrace buffer from within the kernel, and various ways to stop the tracer when a problem is detected.

Ftrace was derived from two tools. One was the "latency tracer" by Ingo Molnar used in the -rt tree. The other was my own "logdev" utility that had its primary use on debugging the Linux kernel. This article will mostly describe features that came out of logdev, but will also look at the function tracer that originated in the latency tracer.

Setting up Ftrace

Currently the API to interface with Ftrace is located in the Debugfs file system. Typically, that is mounted at /sys/kernel/debug. For easier accessibility, I usually create a /debug directory and mount it there. Feel free to choose your own location for Debugfs.

When Ftrace is configured, it will create its own directory called tracing within the Debugfs file system. This article will reference those files in that directory as though the user first changed directory to the Debugfs tracing directory to avoid any confusion as to where the Debugfs file system has been mounted.

    [~]# cd /sys/kernel/debug/tracing
    [tracing]#

This article is focusing on using Ftrace as a debugging tool. Some configurations for Ftrace are used for other purposes, like finding latency or analyzing the system. For the purpose of debugging, the kernel configuration parameters that should be enabled are:

    CONFIG_FUNCTION_TRACER
    CONFIG_FUNCTION_GRAPH_TRACER
    CONFIG_STACK_TRACER
    CONFIG_DYNAMIC_FTRACE

Function tracing - no modification necessary

One of the most powerful tracers of Ftrace is the function tracer. It uses the -pg option of gcc to have every function in the kernel call a special function "mcount()". That function must be implemented in assembly because the call does not follow the normal C ABI.

When CONFIG_DYNAMIC_FTRACE is configured the call is converted to a NOP at boot time to keep the system running at 100% performance. During compilation the mcount() call-sites are recorded. That list is used at boot time to convert those sites to NOPs. Since NOPs are pretty useless for tracing, the list is saved to convert the call-sites back into trace calls when the function (or function graph) tracer is enabled.

It is highly recommended to enable CONFIG_DYNAMIC_FTRACE because of this performance enhancement. In addition, CONFIG_DYNAMIC_FTRACE gives the ability to filter which function should be traced. Note, even though the NOPs do not show any impact in benchmarks, the addition of frame pointers that come with the -pg option has been known to cause a slight overhead.

To find out which tracers are available, simply cat the available_tracers file in the tracing directory:

    [tracing]# cat available_tracers 
    function_graph function sched_switch nop

To enable the function tracer, just echo "function" into the current_tracer file.

    [tracing]# echo function > current_tracer
    [tracing]# cat current_tracer
    function

    [tracing]# cat trace | head -10
    # tracer: function
    #
    #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
    #              | |       |          |         |
                bash-16939 [000]  6075.461561: mutex_unlock <-tracing_set_tracer
              <idle>-0     [001]  6075.461561: _spin_unlock_irqrestore <-hrtimer_get_next_event
              <idle>-0     [001]  6075.461562: rcu_needs_cpu <-tick_nohz_stop_sched_tick
                bash-16939 [000]  6075.461563: inotify_inode_queue_event <-vfs_write
              <idle>-0     [001]  6075.461563: mwait_idle <-cpu_idle
                bash-16939 [000]  6075.461563: __fsnotify_parent <-vfs_write

The header explains the format of the output pretty well. The first two items are the traced task name and PID. The CPU that the trace was executed on is within the brackets. The timestamp is the time since boot, followed by the function name. The function in this case is the function being traced with its parent following the "<-" symbol.

This information is quite powerful and shows the flow of functions nicely. But it can be a bit hard to follow. The function graph tracer, created by Frederic Weisbecker, traces both the entry and exit of a function, which gives the tracer the ability to know the depth of functions that are called. The function graph tracer can make following the flow of execution within the kernel much easier to follow with the human eye:

    [tracing]# echo function_graph > current_tracer 
    [tracing]# cat trace | head -20
    # tracer: function_graph
    #
    # CPU  DURATION                  FUNCTION CALLS
    # |     |   |                     |   |   |   |
     1)   1.015 us    |        _spin_lock_irqsave();
     1)   0.476 us    |        internal_add_timer();
     1)   0.423 us    |        wake_up_idle_cpu();
     1)   0.461 us    |        _spin_unlock_irqrestore();
     1)   4.770 us    |      }
     1)   5.725 us    |    }
     1)   0.450 us    |    mutex_unlock();
     1) + 24.243 us   |  }
     1)   0.483 us    |  _spin_lock_irq();
     1)   0.517 us    |  _spin_unlock_irq();
     1)               |  prepare_to_wait() {
     1)   0.468 us    |    _spin_lock_irqsave();
     1)   0.502 us    |    _spin_unlock_irqrestore();
     1)   2.411 us    |  }
     1)   0.449 us    |  kthread_should_stop();
     1)               |  schedule() {

This gives the start and end of a function denoted with the C like annotation of "{" to start a function and "}" at the end. Leaf functions, which do not call other functions, simply end with a ";". The DURATION column shows the time spent in the corresponding function. The function graph tracer records the time the function was entered and exited and reports the difference as the duration. These numbers only appear with the leaf functions and the "}" symbol. Note that this time also includes the overhead of all functions within a nested function as well as the overhead of the function graph tracer itself. The function graph tracer hijacks the return address of the function in order to insert a trace callback for the function exit. This breaks the CPU's branch prediction and causes a bit more overhead than the function tracer. The closest true timings only occur for the leaf functions.

The lonely "+" that is there is an annotation marker. When the duration is greater than 10 microseconds, a "+" is shown. If the duration is greater than 100 microseconds a "!" will be displayed.

Using trace_printk()

printk() is the king of all debuggers, but it has a problem. If you are debugging a high volume area such as the timer interrupt, the scheduler, or the network, printk() can lead to bogging down the system or can even create a live lock. It is also quite common to see a bug "disappear" when adding a few printk()s. This is due to the sheer overhead that printk() introduces.

Ftrace introduces a new form of printk() called trace_printk(). It can be used just like printk(), and can also be used in any context (interrupt code, NMI code, and scheduler code). What is nice about trace_printk() is that it does not output to the console. Instead it writes to the Ftrace ring buffer and can be read via the trace file.

Writing into the ring buffer with trace_printk() only takes around a tenth of a microsecond or so. But using printk(), especially when writing to the serial console, may take several milliseconds per write. The performance advantage of trace_printk() lets you record the most sensitive areas of the kernel with very little impact.

For example you can add something like this to the kernel or module:

    trace_printk("read foo %d out of bar %p\n", bar->foo, bar);

Then by looking at the trace file, you can see your output.

    [tracing]# cat trace
    # tracer: nop
    #
    #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
    #              | |       |          |         |
               <...>-10690 [003] 17279.332920: : read foo 10 out of bar ffff880013a5bef8

The above example was done by adding a module that actually had a foo and bar construct.

trace_printk() output will appear in any tracer, even the function and function graph tracers.

    [tracing]# echo function_graph > current_tracer
    [tracing]# insmod ~/modules/foo.ko
    [tracing]# cat trace
    # tracer: function_graph
    #
    # CPU  DURATION                  FUNCTION CALLS
    # |     |   |                     |   |   |   |
     3) + 16.283 us   |      }
     3) + 17.364 us   |    }
     3)               |    do_one_initcall() {
     3)               |      /* read foo 10 out of bar ffff88001191bef8 */
     3)   4.221 us    |    }
     3)               |    __wake_up() {
     3)   0.633 us    |      _spin_lock_irqsave();
     3)   0.538 us    |      __wake_up_common();
     3)   0.563 us    |      _spin_unlock_irqrestore();

Yes, the trace_printk() output looks like a comment in the function graph tracer.

Starting and stopping the trace

Obviously there are times where you only want to trace a particular code path. Perhaps you only want to trace what is happening when you run a specific test. The file tracing_on is used to disable the ring buffer from recording data:

    [tracing]# echo 0 > tracing_on

This will disable the Ftrace ring buffer from recording. Everything else still happens with the tracers and they will still incur most of their overhead. They do notice that the ring buffer is not recording and will not attempt to write any data, but the calls that the tracers make are still performed.

To re-enable the ring buffer, simply write a '1' into that file:

    [tracing]# echo 1 > tracing_on

Note, it is very important that you have a space between the number and the greater than sign ">". Otherwise you may be writing standard input or output into that file.

    [tracing]# echo 0> tracing_on   /* this will not work! */

A common run might be:

    [tracing]# echo 0 > tracing_on
    [tracing]# echo function_graph > current_tracer
    [tracing]# echo 1 > tracing_on; run_test; echo 0 > tracing_on

The first line disables the ring buffer from recording any data. The next enables the function graph tracer. The overhead of the function graph tracer is still present but nothing will be recorded into the trace buffer. The last line enables the ring buffer, runs the test program, then disables the ring buffer. This narrows the data stored by the function graph tracer to include mostly just the data accumulated by the run_test program.

What's next?

The next article will continue the discussion on debugging the kernel with Ftrace. The method above to disable the tracing may not be fast enough. The latency between the end of the program run_test and echoing the 0 into the tracing_on file may cause the ring buffer to overflow and lose the relevant data. I will discuss other methods to stop tracing a bit more efficiently, how to debug a crash, and looking at what functions in the kernel are stack hogs. The best way to find out more is to enable Ftrace and just play with it. You can learn a lot about how the kernel works by just following the function graph tracer.

Comments (6 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 2.6.32 . (December 3, 2009)

• Greg KH: Linux 2.6.31.7 . (December 8, 2009)

• Greg KH: Linux 2.6.27.40 . (December 8, 2009)

• Greg KH: Linux 2.6.27.41 . (December 9, 2009)

Core kernel code

• Ben Blum: [PATCH 0/5] cgroups: support for module-loadable subsystems . (December 4, 2009)

• Jiri Slaby: pull request for writable limits for 2.6.33-rc1 . (December 8, 2009)

• KOSAKI Motohiro: Added PR_SET_PROCTITLE_AREA option for prctl() . (December 9, 2009)

• Paul E. McKenney: rcu: preemptible expedited grace periods and cleanups . (December 9, 2009)

• Thomas Gleixner: locking: name space cleanup and -rt spinlock annotation . (December 9, 2009)

• Thomas Gleixner: [patch 0/4] sched: Replace read_lock(&tasklist_lock) with RCU - the easy part . (December 9, 2009)

Development tools

• Subrata Modak: The Linux Test Project has been Released for NOVEMBER 2009 . (December 9, 2009)

• Arnaldo Carvalho de Melo: ANOUNCE: pahole & the dwarves 1.8 . (December 9, 2009)

Device drivers

• Jeff Garzik: What's in libata-dev.git? . (December 3, 2009)

• Takashi Iwai: What's in sound git tree for 2.6.33 . (December 4, 2009)

• Jes Sorensen: Toshiba Bluetooth enabler (rfkill) . (December 4, 2009)

• Rafael J. Wysocki: PM updates for 2.6.33 . (December 8, 2009)

• Antonio Ospite: leds: Add LED class driver for regulator driven LEDs. . (December 8, 2009)

• Pavel Machek: GPIO support for HTC Dream . (December 9, 2009)

• Cory Maccarrone: [MISC] Add HTC PLD driver . (December 9, 2009)

• Jani Nikula: gpiolib: gpio naming in sysfs . (December 9, 2009)

Documentation

• Jonathan Corbet: Document the videobuf layer . (December 9, 2009)

• m-karicheri2@ti.com: V4L - Digital Video Timings API documentation . (December 9, 2009)

Filesystems and block I/O

• Eric Paris: fsnotify/vfsmount: add fsnotify fields to struct vfsmount . (December 3, 2009)

• Sage Weil: ceph distributed file system client . (December 4, 2009)

• J. R. Okajima: pathconf(3) with _PC_LINK_MAX . (December 9, 2009)

• Jan Kara: Implement 64-bit quota format . (December 9, 2009)

• Benny Halevy: Initial pnfsd file layout support . (December 9, 2009)

• Nick Piggin: fs: truncate introduce new sequence . (December 9, 2009)

• Josef Bacik: Btrfs: change how we mount subvolumes . (December 9, 2009)

Memory management

• KAMEZAWA Hiroyuki: percpu mm struct counter cache . (December 9, 2009)

Architecture-specific

• Amit Kucheria: Base support for Freescale i.MX51 SoC platform . (December 4, 2009)

• Wu Zhangjin: Loongson: YeeLoong: add platform specific driver . (December 4, 2009)

• Andi Kleen: [0/31] HWPOISON 2.6.33 pre-merge posting . (December 9, 2009)

Security-related

• James Morris: Security subsystem changes for 2.6.33 . (December 3, 2009)

Virtualization and containers

• Rusty Russell: vhost_net: a kernel-level virtio server . (December 9, 2009)

Miscellaneous

• Douglas Gilbert: lsscsi-0.23 released . (December 3, 2009)

• Kay Sievers: udev 149 release . (December 9, 2009)

• Karel Zak: util-linux-ng v2.17-rc2 . (December 9, 2009)

Page editor: Jonathan Corbet

Distributions

News and Editorials

FreeBSD 8: an evolutionary release of the unknown giant

FreeBSD 8.0 is a major release of the free UNIX descendant. Support for ZFS, jails and USB have been improved, but the release also adds new features, such as NFSv4 and Xen DomU support and some new kernel-related tools. The release notes detail these and other changes that appear in the latest FreeBSD.

New kernel tools

The new textdump feature comes in handy when debugging kernel panics, as it extracts commonly needed information from the kernel memory dump. Textdump stores human-readable text files into a tar archive, and those files can then be analyzed without access to kernel source and symbols. The textdump files are also appropriate for filing a bug report. By default, kernel dumps are still generated in the machine-readable binary format, but by setting the debug.ddb.textdump.pending sysctl variable to 1 using sysctl, the next dump will be a textdump.

Another interesting utility is procstat, which displays detailed information about running processes, such as command line arguments, virtual memory mappings, thread information, file descriptor information, etcetera. FreeBSD 8 also supports Sun's DTrace (introduced in release 7.1), a dynamic tracing framework to assist in profiling the operating system and applications, e.g. to find performance bottlenecks.

FreeBSD 8's network stack has been optimized with a per-CPU flow cache, which increases network throughput on multi core systems, and improvements in the scalability of UDP and TCP. The wireless networking stack has been extended with the "Virtual Access Points (VAP)" functionality, which lets administrators define multiple wireless networks to be hosted from a single access point. This allows for example one wireless network with WPA2 encryption for access to the local network and one without encryption for basic network access for visitors. FreeBSD 8 also supports draft 802.11s mesh networks.

File systems

On the file system front, NFSv4 support has been added (both client and server side), although it is still experimental. Thanks to NFSv4, users can have better security access controls and performance improvements. NFSv4 ACL support is not yet complete: libc changes and some of the kernel changes are part of FreeBSD 8.0, but user space utilities and support for the access control lists in ZFS are expected in FreeBSD 8.1.

The ZFS file system has been upgraded from version 6 to version 13 and is deemed production ready. Also, because ZFS requires a large amount of kernel memory, the limit of kernel memory that could be allocated in FreeBSD has been increased from 2 GB to 512 GB. Two GB was a bit cramped for Sun's file system, which tends to use as much kernel memory as it can. ZFS is not recommended for 32-bit architectures: the ZFS Tuning Guide for FreeBSD reads "A 64-bit system is preferred due to its larger address space and better performance on 64bit variables, which are used extensively by ZFS. 32-bit systems are supported though, with sufficient tuning."

Virtualization

Since FreeBSD 7.2, it has been possible to assign multiple IPv4 or IPv6 addresses to a FreeBSD jail. Jails can now also be restricted to certain CPUs and they can be nested hierarchically. A child jail is always at least as restricted as its ancestors.

Another (experimental) virtualization improvement is VImage, a network virtualization system. This makes it possible to give jails their own independent packet filters and routing tables. All these features open new possibilities for FreeBSD hosting services, who use jails a lot. For example, a web server in a jail can now be assigned multiple addresses and offer virtual hosting, customers can create jails inside their own jail to secure their services, and they can use their own firewall.

The developers have also integrated experimental Xen DomU support into FreeBSD, allowing it to be used as a 32-bit guest operating system on a Xen 3.1 or higher Dom0 host. This will eventually make it possible to use FreeBSD on Amazon EC2 (which at the moment uses Xen 3.0.3). Moreover, the open source edition of VirtualBox has also been ported to FreeBSD (emulators/virtualbox in the ports collection).

Desktop

FreeBSD focuses on the server, but it can also be used as a desktop system, although its descendant PC-BSD (8.0 now in alpha release) is better suited for this purpose. The GNOME desktop environment has been updated to version 2.26.3 (x11/gnome2), and KDE to 4.3.1 (x11/kde4). In previous versions, removing a USB storage device without unmounting its file system first resulted in a kernel panic, crashing the operating system. Release 8.0 adds USB storage hot plug functionality. For desktop users, this is a visible improvement of their user experience, giving FreeBSD the stability it needs on the desktop. Under the hood, the USB stack received a significant overhaul, fixing many long standing problems.

For users that compile their software from the FreeBSD ports collection (with around 20,000 packages that can be compiled from source), there is a simple but very effective new feature. If the hardware has a multi core processor, individual software will be built in parallel on all available cores by default. This is achieved by passing the -jX flag to make, with X the number of cores in the machine. The user can override this number with MAKE_JOBS_NUMBER in /etc/make.conf. Not all software supports this, but the most popular ports do, which speeds up compilation considerably.

One thing that hasn't changed a lot (again) is the installation utility, sysinstall. Its man page even reads "This product is currently at the end of its life cycle and will eventually be replaced". However, currently there are no signs of a replacement utility. One domain where sysinstall fails is that it doesn't support ZFS yet. As a consequence, installing a ZFS-only FreeBSD system requires a lot of manual steps.

For developers

Because the GCC compiler suite was relicensed to GPLv3 after the 4.2 release, commercial users of FreeBSD have been looking into compilers with a more liberal license. One promising project is the Clang/LLVM combination, which is a BSD-licensed C/C++ compiler suite. So the FreeBSD project is intending to use Clang/LLVM as the default compiler for the base system. This is a work in progress, and Clang/LLVM will not likely replace GCC for all third party software, because many depend on GCC-specific constructs.

Last month, FreeBSD 8 also saw the addition of Grand Central Dispatch, Apple's solution for automatic thread pool management in Mac OS 10.6 ("Snow Leopard"). The FreeBSD wiki lists the status of the GCD port and some references to give it a try. Incidentally, both Clang/LLVM and Grand Central Dispatch are backed by Apple, making the Cupertino-based company an important contributor to the future of FreeBSD.

Conclusion

It is difficult to pinpoint one unique area were FreeBSD 8 shines. The release shows improvements in a lot of areas. From kernel programmers and file system lovers to developers, administrators and even end-users, everyone will find something new. From the standpoint of a Linux user, one could ask why someone might want to choose FreeBSD over Linux. This is largely a matter of taste, but your author likes the clean FreeBSD ports system which even allows you to select build options, the excellent hands-on documentation in the FreeBSD Handbook and the quality of the man pages.

Comments (8 posted)

New Releases

AV Linux 3.0 Released

Comments (none posted)

Calculate Linux 10.0 released (Examiner.com)

Comments (none posted)

Fedora 12 LXDE Spin available for download

Full Story (comments: none)

SimplyMEPIS 8.5 beta1 Release

Comments (none posted)

Distribution News

Fedora

Rawhide users: fasten your seat belts

Comments (14 posted)

Fedora Board, FESCo & FAmSCo Elections - Voting Information

Full Story (comments: none)

Fedora Board appointment

Full Story (comments: none)

Fedora Board Recap 2009-12-03

Full Story (comments: none)

Fedora 13 release name

Full Story (comments: none)

SUSE Linux and openSUSE

Announcing new openSUSE Board Members

Full Story (comments: none)

Ubuntu family

Call for nominations: Ubuntu Developer Membership Board

Full Story (comments: none)

ubuntu-distributed-devel mailing list created

Full Story (comments: none)

Distribution Newsletters

DistroWatch Weekly, Issue 332

Comments (none posted)

Fedora Weekly News 205

Full Story (comments: none)

OpenSUSE Weekly News/100

Comments (none posted)

Ubuntu Weekly Newsletter #171

Full Story (comments: none)

Interviews

Knoppix founder Klaus Knopper speaks (Linux User)

Comments (none posted)

Distribution reviews

A Linux answer to Windows SBS: ClearOS (ITworld)

Comments (none posted)

Page editor: Rebecca Sobol

Development

The Twisted networking framework version 9.0.0

The Twisted project is building a Pythonic networking engine with many uses. From the Twisted home page: "Twisted is an event-driven networking engine written in Python and licensed under the MIT license." Also: "Twisted projects variously support TCP, UDP, SSL/TLS, multicast, Unix sockets, a large number of protocols (including HTTP, NNTP, IMAP, SSH, IRC, FTP, and others), and much more." See the twisted advantage for an explanation of why one would want to use Twisted to develop network applications.

LWN last looked at the Twisted project in January, 2007 when version 2.5.0 was released, the project has matured a lot since then.

The current version of Twisted is organized into the following categories:

• Twisted core - the project's top level
• Twisted conch - implements the SSH protocol
• Twisted lore - the Twisted documentation
• Twisted mail - implements the SMTP protocol
• Twisted names - implements the DNS protocol
• Twisted trail - the twisted testing framework
• Twisted web - implements the HTTP protocol
• Twisted web2 - implements the HTTP protocol (redux)
• Twisted words - implements instant messaging

Christopher Armstrong recently announced Twisted 9.0.0: "I'm happy to announce Twisted 9, the first (and last) release of Twisted in 2009. The previous release was Twisted 8.2 in December of 2008. Given that, a lot has changed! This release supports Python 2.3 through Python 2.6, though it is the last one that will support Python 2.3. The next release will support only Python 2.4 and above. Twisted: the framework of the future!"

Looking at the release notes for version 9.0.0, one can see that a large amount of work has gone into cleaning up the code and fixing bugs, with 285 bug tickets resolved. New capabilities are summed up in the release announcement:

In the core:
- The Windows IOCP reactor now supports SSL.
- The memcache protocol implementation got some nice new features.

In Twisted Web:
- There's a new HTTP client API and protocol implementation, starting
at twisted.web.client.Agent. It's still pretty low-level, but much
more flexible than the old API.
- There were many improvements to the WSGI support.

In Twisted Conch:
- PyASN1 is now used to parse SSH keys (which means you now need to
install it to use Conch).
- SFTP servers (especially on Windows) now behave a lot better.

In Twisted Mail:
- The IMAP server and client protocol implementations had many fixes.
For example, SASL PLAIN credentials now work.

In Twisted Words:
- XMPP clients now support the ANONYMOUS SASL authentication type.
- The IRC protocol implementations had many fixes.

The Twisted project appears to be alive and thriving as it continues in its evolution. This is indicated by the numerous Success Stories and the growing list of projects that use Twisted. Congratulations to the Twisted developers for continuing to make progress on this useful framework.

Comments (4 posted)

System Applications

Audio Projects

New Music Player Daemon releases

Comments (none posted)

Clusters and Grids

Release of rsplib 2.7.0

Full Story (comments: none)

Database Software

PostgreSQL Weekly News

Full Story (comments: none)

SQLite 3.6.21 released

Comments (none posted)

Web Site Development

moin 1.8.6 released

Full Story (comments: none)

moin 1.9.0 released

Full Story (comments: none)

Miscellaneous

OpenInkpot 0.2 released

Full Story (comments: none)

Desktop Applications

Audio Applications

Audacity 1.3.10 beta released

Comments (none posted)

Desktop Environments

GNOME 2.29.3 released

Full Story (comments: none)

GNOME Software Announcements

• gnome-color-manager 2.29.1 (new features, bug fixes and translation work)
• GNOME Commander 1.2.8.4 (bug fixes)
• gnome-packagekit 2.28.2 (bug fixes and translation work)
• GNOME PackageKit 2.29.1 (new features, bug fixes and translation work)
• GNOME Power Manager 2.28.2 (translation work)
• GNOME Power Manager 2.29.1 (new features, bug fixes and translation work)
• GTK+ 2.18.5 (bug fixes)
• liboobs 2.29.1 (bug fixes)
• libvtemm 0.22.2 (documentation work)
• Nemiver 0.7.3 (new features, bug fixes and translation work)
• Sabayon 2.29.2 (documentation work)
• Sawfish 1.6.0 RC 1 (new features and bug fixes)
• tracker 0.7.10 (new features and bug fixes)

Comments (none posted)

KDE Software Compilation 4.4 Beta1 Released

Full Story (comments: 64)

KDE Software Announcements

• Acetoneiso 2.2.1 (unspecified)
• KMess 2.0.2 (bug fixes)
• Kotivox beta (beta release)
• ksoprano 0.1 (initial release)
• Mudlet 1.0.4 (unspecified)

Comments (none posted)

Xorg Software Announcements

• libdrm 2.4.16 (new features, bug fixes and code cleanup)
• liblbxutil 1.1.0 (bug fixes, code cleanup and documentation work)
• libxcb 1.5 (new features, bug fixes and documentation work)
• xorg-server 1.7.3 (bug fixes)

Comments (none posted)

Desktop Publishing

LyX 1.6.5 is released

Full Story (comments: none)

Games

Cyphesis 0.5.22 released

Comments (none posted)

GUI Packages

Qt: More, More, More (Linux Journal)

Comments (none posted)

Interoperability

Wine 1.1.34 announced

Comments (none posted)

Mail Clients

Thunderbird 3.0 released

Comments (54 posted)

Music Applications

guitarix 0.05.3-1 quick release

Full Story (comments: none)

Patchage 0.4.3 released

Full Story (comments: none)

Web Browsers

First Mobile Firefox enters home stretch (cnet)

Comments (1 posted)

Languages and Tools

C

GCC 4.5 Status Report

Full Story (comments: none)

Caml

Caml Weekly News

Full Story (comments: none)

Python

Python 2.7 alpha 1 released

Full Story (comments: none)

execnet 1.0.1 released

Full Story (comments: none)

Announcing fileutils, a UNIX inspired file system library

Full Story (comments: 1)

Wielaard: FUDCon Success – Systemtap meets Python

Comments (1 posted)

Pyro 3.10 released

Full Story (comments: none)

Python-URL! - weekly Python news and links

Full Story (comments: none)

Tcl/Tk

Tcl-URL! - weekly Tcl news and links

Full Story (comments: none)

IDEs

Pydev 1.5.2 released

Full Story (comments: none)

Test Suites

TextTest 3.16.1 released

Full Story (comments: none)

Version Control

Git 1.6.5.5 released

Full Story (comments: none)

Miscellaneous

Red Hat Bugzilla 3.4 public beta announced

Full Story (comments: 1)

Page editor: Forrest Cook

Announcements

Commercial announcements

Introducing Google Public DNS: A new DNS resolver from Google

Comments (55 posted)

Legal Announcements

Artifex launches a GPL-infringement suit against Palm

Comments (24 posted)

Kuhn: The Anatomy of a Modern GPL Violation

Comments (11 posted)

Articles of interest

Intel unveils 48-core cloud computing silicon chip (BBC)

Comments (12 posted)

Why Open Source Phones Still Fail (PC Magazine)

Comments (50 posted)

Sugar on a Stick v2 - a.k.a. Blueberry - released (The H)

Comments (none posted)

New Books

New from O'Reilly--Books on Google Ad Tools, Programming, Electronics, and Geometry

Full Story (comments: none)

Contests and Awards

Linux Foundation awards Students with free membership for the holidays

Full Story (comments: none)

Surveys

2009 Linux Graphics Survey Results (Phoronix)

Comments (11 posted)

Calls for Presentations

Registration open for DjangoSki Conference

Full Story (comments: none)

PostgreSQL@FOSDEM 2010 - Call for talks

Comments (none posted)

Upcoming Events

Django Development Sprint

Comments (none posted)

Speaker Slots still available for SCALE 8X

Full Story (comments: none)

Events: December 17, 2009 to February 15, 2010

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

Web sites

gnome.org outage: Dec 12, 13

Full Story (comments: none)

Audio and Video programs

Announcing the LAM annual Best of mix 2009

Full Story (comments: none)

First L2Ork track now available

Full Story (comments: none)

Page editor: Forrest Cook