LWN.net Logo

LWN.net Weekly Edition for May 21, 2009

EGLIBC: Not a fork, but a glibc distribution

By Jake Edge
May 20, 2009

The GNU C library (or glibc) is a fundamental component of the Linux operating system. It provides much of the user-space interface to the kernel as well as a sizable portion of the utility routines that are used by virtually all Linux applications. A variant of glibc—known as Embedded glibc or EGLIBC—is not very well known outside of the embedded space, but that looks to be changing with the announcement that Debian will switch from glibc to EGLIBC.

The project is quick to point out that it is not a fork of glibc as it aims for compatibility—both source and binary—with glibc. Instead, EGLIBC is like a distribution of glibc, adding patches to fix problems as well as making it easier to use for embedded applications. It also adds support for embedded architectures that are not part of the focus of core glibc development.

The project—started in 2006—is being spearheaded by CodeSourcery, which provides compilers and other development tools based on GCC to its customers. Chief Sourceror Mark Mitchell says that CodeSourcery provides administrative support for the project and "leadership, but not control". Its customers are embedded Linux distributors along with hardware manufacturers and EGLIBC arose from those customers looking for smaller C library solutions.

Mitchell said those customers were looking at uClibc as an alternative to glibc, but using uClibc has some disadvantages because it takes "real work getting applications that work with glibc to work with uClibc". Because of the universal use of glibc, "the Linux that you run on a supercomputer and the Linux that you run on a cell phone are very similar". One of the key advantages of uClibc, though, is its customizability, so that embedded developers can turn off features—Mitchell's classic example is NIS—that are not needed for the product.

That led to adding "option groups" to EGLIBC, which can be enabled or disabled, more-or-less independently to reduce the size of the library. There are roughly 30 option groups currently defined, but the project hopes that new contributors will add new ones. By using the option groups, one can disable things like networking (or just IPv6 networking), math libraries, Sun RPC, Streams, various internationalization/localization options, and more.

Working with glibc maintainer Ulrich Drepper can be difficult due, at least in part, to his blunt manner. While Mitchell is not one to contrast the EGLIBC development community with that of glibc, it is apparent that EGLIBC is trying to be a more inclusive upstream. Others, including Debian's Aurélien Jarno, who announced the switch to EGLIBC, are less reticent, pointing to the difficulty of working with Drepper as a main advantage of EGLIBC.

For his part, Mitchell would like to see a "vibrant open-source community" spring up around EGLIBC, noting that "we welcome all comers". While the project is funded by a consortium of companies: Freescale Semiconductor, MIPS Technologies, MontaVista, and Wind River; one does not need to work for those companies in order to contribute. Nor do the patches need to be focused only on embedded concerns; bug fixes and features that are not accepted by glibc will be considered. Mitchell said that EGLIBC is looking forward to contributions from anyone and, in particular, "are hopeful that Debian will contribute" to the project.

So that any contributions can be rolled back into glibc, EGLIBC requires contributors to assign their copyright to the Free Software Foundation as with a glibc patch. The intent is that the EGLIBC code never stray very far from glibc; in fact, changes to glibc are merged back into EGLIBC frequently. Core glibc development is "focused on x86 and other server-class hardware", Mitchell said, but if that changes, EGLIBC could be merged back into the upstream project. "We'd be happy to see FSF glibc pick up anything we've done, even to the point of obviating EGLIBC", he said.

Jarno is clearly frustrated with how glibc development is done, quoting from the EGLIBC mission statement as part of the announcement: "Encourage cooperation, communication, civility, and respect among developers." But that is not the only advantage to EGLIBC, he lists a number of others including the configurability, a better test suite, and better stable branch handling that makes important bug fixes available for earlier versions.

In a follow up posting to debian-devel, Jarno lists a few more reasons along with answers to some of the questions he has heard. For Debian in particular, supporting many different architectures, including multiple embedded architectures, is very important. He notes that EGLIBC is essentially a drop-in replacement for glibc in keeping with that project's compatibility goals. The common request to add strlcat() and strlcpy()—BSD string handling functions that avoid buffer overruns—will likely not be satisfied for just those compatibility reasons.

EGLIBC clearly offers some things that the standard glibc lacks—not just for embedded developers. The focus on being inclusive will likely expand the pool of C library hackers, which is something that the current glibc development community is not actively encouraging. With luck, it will also act as a test bed for fixes and features—especially as it gets more exposure and testing via Debian—that may lead to a better glibc down the road. It will be interesting to see if other distributions take the same step that Debian has, and what that might mean for glibc in the future.

Comments (42 posted)

Transmageddon and Arista pursue simple transcoding

May 20, 2009

This article was contributed by Nathan Willis

Christian Schaller's Transmageddon and Daniel Taylor's Arista are both easy-to-use video file conversion tools for GNOME, but they share more than just a vision for simple file transcoding. Rather than competing head-on (or attempting a merge), the two developers are collaborating in the middle; sharing information and utilizing the similar aims of their projects to strengthen the underlying GStreamer multimedia framework on which both code bases depend.

Schaller is a longtime GStreamer contributor; he started Transmageddon in March of 2009 for several reasons. First, as a personal exercise in developing in Python, but also as an attempt to find real-world areas of improvement for application developers using GStreamer, and to scratch a personal itch — the lack of an easy-to-use, GStreamer-based video transcoder. Said itch also prompted Taylor to start work on Arista, as a personal project in 2008, with its first public release in April of 2009. He discovered Transmageddon through Schaller's blog, and the two began discussing how best to proceed.

A variety of motives

[Arista]

That two developers independently decided to write simple GUI transcoding applications should come as no surprise. Video transcoding is increasingly in demand as more and more portable devices have the graphics hardware to support it and digital content distribution skyrockets. Command line encoders like FFmpeg and MEncoder can perform almost any conversion, but require the user to know exactly which options to enable, and, in most cases, demand that every codec switch be specified or else they fail to produce a usable result. That leads to obtuse (and extremely long) commands that are difficult to get right and even more difficult to troubleshoot. Several graphical transcoding applications have appeared for Linux desktops in recent years — Thoggen, OGMRip, K9Copy, AcidRip, dvd::rip, HandBrake, and WinFF, to name a few — but as both Taylor and Schaller commented, all have their shortcomings.

Some, like Thoggen, OGMRip, and Oggconvert, are limited to specific output codecs. Others, like dvd::rip, attempt to offer every option under the sun, making them difficult for casual users to use. "There are dozens of GUIs that are essentially the same confusing options with a nice graphical label. To me that doesn't really help," Taylor observed. "The point of Arista is not to be everything to everyone, just to be a simple way to transcode your media for various devices. That's it."

In addition, many of the existing transcoders are built as stand-alone front-ends, and offer little in the way of desktop integration. "Most of the other GUIs I've seen directly use FFmpeg (libavformat, libavcodec, etc)," said Taylor. "I wanted to make use of GNOME technologies to make a real GNOME app, which means using GTK+, GStreamer, Gconf, GIO, etc. Arista should fit into the desktop." Taylor said he has a few features in mind for future releases (such as subtitle and DVD menu support), but also hopes to add a D-Bus interface that will enable other applications to control Arista.

For Schaller, building a GUI transcoder is also a way to field test GStreamer. He mentioned the possibility in a 2008 blog post, speculating that such a small-scale application could be used to "test and make sure our muxers and encoders keep working" better than a more complex tool like a video player or editor. So far, he said, a few bugs may have been discovered, but the more important benefits are from testing GStreamer features that have not been used before — such as property presets, which allow the application to set bundles of individual encoder settings by name (either for encoder profiles like H.264 Baseline, or to target specific hardware devices).

The benefits extend beyond the existing code to other applications, Schaller added:

The other thing we are doing as part of this is to try to figure out what kind of higher level encoding and transcoding API could be useful to application developers. ... One of GStreamer's goals is to make things as easy as possible for developers, so packaging some of the steps we take in our applications into some C helper APIs is probably a good idea.

Collaboration and divergence

After Schaller and Taylor touched base, they decided to stay in close touch and share code whenever possible, but to take their respective applications on slightly different paths. Taylor would take the conservative, end-user-oriented approach, making sure that Arista would always run on the current release of Ubuntu. Schaller would try to more closely track the development version of GStreamer, including reliance on GStreamer features not yet available downstream. That way, there will always be a transcoder available for and usable by "non-techies" in Arista, and Transmageddon can serve as a test bed for new features.

[Transmageddon]

The cross-project collaboration is already reaping rewards. Schaller says that he has incorporated Arista's existing preset support into Transmageddon, and is extending it using some bleeding-edge changes from the development version of GStreamer. Once the Linux distributions are shipping the next update of GStreamer, the plan is to roll Transmageddon's improved preset support back into Arista.

The projects are also helping GStreamer. They are accumulating a collection of presets that will be valuable to other applications, have uncovered bugs in the capabilities system, and exposed that GStreamer needs a better encoder and decoder for the Adaptive Multi-Rate (AMR) audio format.

Schaller said he is also planning on turning his notes on the development process into a guide for others:

I have decided to try to use my experience with doing Transmageddon to write a series of tutorials for developing python applications with GStreamer. I think applications like PiTiVi, Jokosher, Arista and Transmageddon prove that you can do quite complex applications quite easily using Python, we just need some more basic tutorials to give more Python developers the entry point into GStreamer that they need to get started.

Test drive

You can download both applications and try them out to compare. Transmageddon is available from Schaller's web site as a source code package and as an RPM package. The latest release is 0.9, from May 3, 2009. It does require Python and a development branch of GStreamer, though, which may place it out of reach for most users.

Arista is available for download from the project's Launchpad site. The most recent version is 0.9.1, also from May 3. A source code package is provided, as is an ArchLinux build through the ArchLinux User-community Repository (AUR), and those running Ubuntu 9.04 can add Taylor's Personal Package Archive (PPA) to their Apt repositories list and install the application through the package manager. 0.9.1 also requires Python and GStreamer, but only GStreamer 0.10, which is widely available.

Arista allows the user to select source videos in any encoding and file type readable by GStreamer (including DVD content), and select an output format — including presets configured for a range of portable hardware devices. Beyond that, there is little to the interface but a progress bar estimating the time remaining in the transcoding job and a two-frame-per-second preview window useful for monitoring the output.

Other transcoders offer far more options, but at the cost of far more complexity. Users must often know the audio and video codecs, output width and height, frame rate or bit rate, and many other options. Arista and Transmageddon make the job drastically simpler merely by abstracting away all of those details in device presets — the correct settings are still chosen, but the confusion and chance for human error are not. It will be interesting to watch the projects evolve in the months ahead; the notion of a simple to use video transcoder is appealing, but even more appealing is what can happen when that functionality is available to other desktop applications through D-Bus.

Comments (15 posted)

GNOME debates Javascript bindings

May 20, 2009

This article was contributed by Bruce Byfield

Which Javascript binding should the GNOME desktop support? This is a question that the GNOME desktop-devel was debating last week. Since GNOME-Shell, the foundation of next year's GNOME 3.0, is built on Javascript, the answer is a major policy decision. However, the difficulties of making the decision are compounded because the contenders, Seed and Gjs, are both in rapid development and their final form is difficult to predict. However, that does not stop the push for a decision from the Seed community.

Both Seed and Gjs are GNOME projects. They are interpreters that allow users to write code in Javascript and have the core GNOME code use it. One of the major differences between them is the flavor of Javascript that they use, with Seed designed to work with WebKit, a Javascript engine favored by Apple and KDE, and Gjs with SpiderMonkey,a Javascript engine designed for Mozilla's applications. Since GNOME-Shell is written in Javascript (currently with Gjs) the choice of engines is a decision with far-reaching consequences. Also at stake is the prospect of tying future GNOME development to a particular dialect of Javascript whose development and adoption is still uncertain.

What makes the decision particularly hard is that, with Seed at release 0.7 and Gjs at 0.2, both are likely to change considerably before their final releases, so judging the suitability of one over the other is next to impossible. All the same, an effort at objective comparison was written by Owen Taylor, the GNOME-Shell maintainer.

Taylor notes that only Gjs currently supports "let" statements, which create variables scoped to the local block, and "const," which is used to declare a constant variable. He also refers to the fact that switching to Seed would currently mean a loss of destructuring assignment, a more flexible, multiple-assignment syntax. But he is largely unconcerned about these losses, viewing them as only temporary. He is more concerned about the choice of the widely used SpiderMonkey as opposed to the more untried JavascriptCore module behind WebKit, although he notes that Epiphany, the default GNOME browser, and Yelp, the GNOME help system, already use WebKit. Without giving particulars, Taylor also characterizes Gjs as having a limited set of well-implemented features, as opposed to Seed, which has more features. In fact, Gjs seems to exist largely to serve the needs of GNOME-Shell as they arise, while Seed is more active and independent project.

At this stage, he is not concerned with the speed of either, reasoning that it will change in coming months, but he does express concern at garbage collection — the reclamation of memory by the removal of unused objects — arguing that both SpiderMonkey's and WebKit's garbage collection is more geared to web pages than desktops. In the end, Taylor seems to be relatively indifferent to which one is used by GNOME so long as it has the tools that GNOME-Shell will require. In other words, the choice is too uncertain for even those most closely affected to have strong opinions on it.

The most that Taylor can provide is a general criterion for making a choice: "Javascript standardization is highly politicized and affected by concerns like what Microsoft can implement in IE and in general by considerations of cross-browser compatibility," Taylor wrote. "We should use whatever dialect of Javascript is supported by our engine that makes our life better."

The push for a choice

Nobody involved with Gjs has been active in this discussion, while those involved with Seed have been raising the possibility of choosing one over the other for six months. Last November, Frederick Peters, in the GNOME Commit-Digest, summarized some differences between Seed and Gjs as described by Robert Carr, Seed's maintainer. According to Peters, Carr suggested that, for the time being, "it's best for both projects to continue development at this point."

By January, as plans for GNOME 2.26's March release were being finalized, Carr was ready to propose that GNOME standardize on Seed. The proposal sparked a discussion about the relative merits of Seed and Gjs as they existed then. But the majority opinion was that it was still too early to make a choice, and the proposal was not accepted.

Four releases of Seed later, with plans being discussed for the release of GNOME 2.28 , the intended beta for GNOME 3.0 that is due for release in November, Carr renewed his proposal in May. He pointed out that Seed would require no new external dependencies, since WebKit/GTK+ and GObject Introspection, with which it interacts, are already scheduled to be included in the upcoming release. Furthermore, Seed already uses standard parts of GNOME, such as gnome-git and Bugzilla. Carr also cited the flexibility of using Seed, arguing that "at this point, most Gjs code could be prettily easily ported to Seed" while porting the other way "might be a bit more difficult" and suggesting that "it would be possible to port GNOME-Shell to Seed with no more than a few days' work." Similarly, he suggested that writing an extension to support Seed would be "around a day's work" for most applications. In passing, he also raised the possibility of a common module for both Gjs and Seed, which would preserve flexibility.

In response to a direct question from Hubert Figuiere about "what makes Seed more suitable than Gjs?" Carr admitted that, "For 2.28, it may make sense to have both Gjs and Seed as modules, and try and keep code somewhat compatible. It's still not entirely clear which Javascript engine is going to end up being better long term, so we might not want to completely commit to one yet."

Still, Carr favored Seed for a number of technical reasons. He argued that Seed's use of WebKit and GObject was more in keeping with existing tendencies in GNOME, and the Seed C API is far more intuitive than the SpiderMonkey API used by Gjs. Moreover, he described Seed as having more example code and documentation, which would make it easier to use.

What would happen to Gjs if Carr's proposal is accepted is uncertain. However, with Seed officially endorsed, Gjs would undoubtedly become a side line within GNOME if it continued at all. So far as most developers are concerned, it would probably survive largely in the code that Seed borrowed from it.

The discussion

The initial response to Carr's proposal was that having two Javascript engines was unnecessary. However, most people on the mailing list gradually seemed to agree with Vincent Untz, who argued that "we need both engines and we need them in our platform sooner rather than later," on the grounds that which one was preferable was still uncertain.

After a few remarks, the discussion turned to a question of whether GNOME-Shell's developers were prepared to use Seed, and what effort that decision would require. Carr replied that he was prepared to write a patch that would allow Gnome-Shell to use Seed. Others, though, such as Xan Lopez suggested that he was underestimating the size of the task. "Do you have any idea of how big a task adding 'let' [statements] support to JSC [Javascript Core] would be?" Lopez asked, referring to a one of Seed's greatest lacks, and implying that the task would be a big one. To this question, Carr replied that he was looking into the issue, and would report back when he had more information.

After discussing the idea of adding let statements to Javascript with the JSC project, Xan Lopez disagreed with Taylor on the grounds that the upstream JSC team was opposed to non-standard extensions. Instead, he urged that GNOME should "just stick to a [Javascript] defined in some standard widely used for all GNOME code, in order to avoid future headaches."

Carr offered to alleviate concerns by maintaining a Seed version of GNOME-Shell separately from the main branch for the next two releases. But, at this point, the unspoken consensus seems to have been that a decision could not be made.

Instead, talk turned to how to implement a common module for both Seed and Gjs. In a long post, Havoc Pennington strongly advocated this position. Pennington's "practical path" was to have both engines use the same modules and test suite, and to add support for let statements. As he saw it, the common module would also need to support disabling features that one or the other didn't support. This path was extra work, Pennington acknowledged, but he thought that the common module "could be the right decision even if GNOME includes only one of the runtimes, just to get more people hacking on the suite of [Javascript] modules."

For now, then, GNOME seems to have chosen to develop both modules together as much as possible, and to delay a final decision yet again. This approach may seem untidy and unsatisfying to many, but, it is hard to see what other decision could be made. Both the engines and Javascript itself are too unsettled for a clear choice to be made. Moreover, the undoubted pressure to advance GNOME 3.0 means that the time to make such decisions is minimal. By compromising, GNOME has allowed itself to progress while keeping as much flexibility as possible.

Comments (28 posted)

Page editor: Jonathan Corbet

Security

Enabling DRM in the kernel?

By Jake Edge
May 20, 2009

Back in April, we looked at the Linux kernel patches for Intel's Trusted Execution Technology (TXT), a mechanism to verify the integrity of the kernel before booting it. Since that time, another version of the patchset has surfaced. The relatively few comments on the feature were largely concerned that there might be opposition to its inclusion—not because of technical considerations, but instead because of ethical concerns about what TXT could enable.

Ted Ts'o had the most to say about what TXT (also known as LaGrande) enables, not necessarily in opposition to adding the feature, but outlining the concerns of those who might. He warned: "So we should expect a certain amount of controversy and people lobbying to resist the acceptance of this patch." The basic problem is that TXT can enable Digital Rights Management (DRM) systems that are largely uncrackable.

Pointing to a "Trusted Computing" FAQ from 2003, Ts'o noted that five years ago, FAQ author Ross Anderson "was able to predict the emergence of the LaGrande Technology (see question 15 in the above FAQ)." But, Joseph Cihula, author of the TXT patch noted that some of the FAQ (and other Trusted Computing complaints) had been rebutted [PDF] in an IBM whitepaper by David Safford. But, as Ts'o pointed out, much of Safford's response was specific to the Trusted Computing Platform Alliance (TCPA) technology, which is essentially broken as a DRM lockdown solution:

However, it seems to me that TXT/LaGrande's main purpose for existence was to repair the defects in TCPA that made it essentially [unusable] for DRM purposes. With TCPA, any time you changed *anything* in the boot path --- installed a new BIOS, upgraded to a new kernel to fix a security vulnerability, updated to a new Nvidia proprietary video driver slightly less likely to crash your [system] --- it would change the trusted boot measurements, and would require an exchange to "[Circuit] City DIVX hotline" (as a generic stand-in for whoever is Hollywood's current monkey paw towards trying to implement DRM) to approve a transfer of the TCPA trusted keys, which would be essentially be a consumer support nightmare, and there would be no way for "Circuit City" to know whether the kernel you are claiming was the latest update from Fedora or Novell or Canonical was really an authorized upgrade, or whether it was a custom kernel with patches to tap into video and audio paths to steal Hollywood's precious bodily fluids.

With TXT, however, all of these problems go away. What you end up booting is completely under "[Circuit] City's DIVX's" control, and may include a miniature Windows environment running in the trusted environment; it could then take over a portion of the screen for the video output, and the hardware would have special features set up to prevent the host OS from having any access to the video output of the movie player running in the TXT environment.

Ts'o's message is worth reading in its entirety, but the basic point is that TXT enables Hollywood (or another DRM-happy entity) to take away some of the basic functionality of the hardware in order to preserve their "rights". Essentially, this takes away users' rights to protect companies' perceived or actual rights. The truly nightmarish scenario is one where one cannot do anything on a computer that isn't contained in a signed (presumably proprietary and closed source) application, running on a signed operating system. TXT could enable just that kind of functionality.

But, there are some scenarios (Ts'o mentions medical record access) under which TXT could be beneficial to the user. Other devices (voting machines and ATMs are the standard example) could benefit from TXT as well. Should kernel hackers stand in the way of adding this code to the kernel simply because it can be used for ill? The consensus, from the extremely limited subset of the kernel development community participating in the discussion, seems to be "no".

James Morris notes Linus Torvalds's famous "Flame Linus to a crisp!" message wherein he says: "I want to make it clear that DRM is perfectly ok with Linux!". Morris more-or-less agrees with that view:

I'm fairly neutral on the technology itself and feel that "market pressure" from users as well as local regulatory policy (e.g. anti-trust laws) should determine how the technology is used, rather than the views of a few kernel hackers.

That sentiment is also shared by Ts'o: "That being said, it's not clear to me that stopping the technology from going into Linux really isn't going to help matters; realistically, the Linux desktop is miniscule[1], and whether or not we add support for TXT in the mainline Linux kernel isn't going to stop Hollywood's plans." His footnote refers to the potential risk of TXT being used in Moblin to lock down those devices, but "realistically, even if we don't let it into mainline kernel, it won't stop Moblin hardware vendors from shipping it".

This is a social, not a technical problem, as Ts'o says. There are powerful interests that certainly want to have that kind of power over the actions of their customers. It will be up to those who value their hardware and software freedoms (and, very likely, the courts) to ensure that those freedoms are still available. Avoiding DRM is not something that has gotten onto the radar of most consumers, but the content providers are doing their best to raise its visibility. One wonders how many revoked features for Kindle books or how much music that expires because it is crippled with DRM it will take before consumers start to rebel.

In the meantime, though, it seems likely that Linux will end up with TXT support somewhere down the road. The objections have been few—technical or ethical—at least so far, and the code obviously exists. There is no barrier to a hardware manufacturer (or distribution) incorporating it and enforcing whatever restrictions it wishes. Given that there are benign uses as well, the code is likely to improve from its inclusion in the mainline. When (almost certainly not "if") those uses turn towards total lockdown, it will be a social battle, on multiple fronts, to preserve the hardware and software freedoms we enjoy today.

Comments (22 posted)

New vulnerabilities

cyrus-sasl: buffer overflow

Package(s):cyrus-sasl CVE #(s):CVE-2009-0688
Created:May 15, 2009 Updated:December 3, 2009
Description: From the Slackware advisory: A buffer overflow in the sasl_encode64() function could lead to a denial of service or possible execution of arbitrary code.
Alerts:
Mandriva MDVSA-2009:113-1 2009-12-03
Gentoo 200907-09 2009-07-12
Ubuntu USN-790-1 2009-06-24
CentOS CESA-2009:1116 2009-06-19
Red Hat RHSA-2009:1116-01 2009-06-18
SuSE SUSE-SR:2009:011 2009-06-09
Debian DSA-1807-1 2009-06-01
rPath rPSA-2009-0091-1 2009-05-27
Mandriva MDVSA-2009:113 2009-05-18
Slackware SSA:2009-134-01 2009-05-15

Comments (none posted)

drupal: cross-site scripting

Package(s):drupal CVE #(s):CVE-2008-3661
Created:May 18, 2009 Updated:May 20, 2009
Description:

From the Drupal advisory:

Certain byte sequences that are valid in the UTF-8 specification are potentially dangerous when interpreted as UTF-7. Internet Explorer 6 and 7 may decode these characters as UTF-7 if they appear before the tag that specifies the page content as UTF-8, despite the fact that Drupal also sends a real HTTP header specifying the content as UTF-8. This enables attackers to execute cross site scripting attacks with UTF-7. SA-CORE-2009-005 - Drupal core - Cross site scripting contained an incomplete fix for the issue. HTML exports of books are still vulnerable, which means that anyone with edit permissions for pages in outlines is able to insert arbitrary HTML and script code in these exports.

Alerts:
Fedora FEDORA-2009-5002 2009-05-15
Fedora FEDORA-2009-4997 2009-05-15

Comments (none posted)

giflib: several vulnerabilities

Package(s):giflib CVE #(s):CVE-2005-2974 CVE-2005-3350
Created:May 19, 2009 Updated:June 18, 2009
Description: From the Fedora advisory: CVE-2005-2974: NULL pointer dereference crash. CVE-2005-3350: Memory corruption via a crafted GIF
Alerts:
Fedora FEDORA-2009-4848 2009-05-12
Red Hat RHSA-2009:0444-01 2009-04-22
Fedora FEDORA-2009-5118 2009-05-19

Comments (2 posted)

gnutls: incorrect certificate validation

Package(s):gnutls CVE #(s):CVE-2009-1417
Created:May 18, 2009 Updated:December 4, 2009
Description:

From the Mandriva advisory:

gnutls-cli in GnuTLS before 2.6.6 does not verify the activation and expiration times of X.509 certificates, which allows remote attackers to successfully present a certificate that is (1) not yet valid or (2) no longer valid, related to lack of time checks in the _gnutls_x509_verify_certificate function in lib/x509/verify.c in libgnutls_x509, as used by (a) Exim, (b) OpenLDAP, and (c) libsoup (CVE-2009-1417).

Alerts:
Mandriva MDVSA-2009:308 2009-12-03
Gentoo 200905-04 2009-05-24
Mandriva MDVSA-2009:116 2009-05-18

Comments (none posted)

ipsec-tools: denial of service

Package(s):ipsec-tools CVE #(s):CVE-2009-1574
Created:May 14, 2009 Updated:December 3, 2009
Description: From the Mandriva alert: racoon/isakmp_frag.c in ipsec-tools before 0.7.2 allows remote attackers to cause a denial of service (crash) via crafted fragmented packets without a payload, which triggers a NULL pointer dereference.
Alerts:
Mandriva MDVSA-2009:112-1 2009-12-03
SuSE SUSE-SR:2009:012 2009-07-03
Ubuntu USN-785-1 2009-06-09
Gentoo 200905-03 2009-05-24
Debian DSA-1804-1 2009-05-20
CentOS CESA-2009:1036 2009-05-19
Red Hat RHSA-2009:1036-01 2009-05-18
Mandriva MDVSA-2009:112 2009-05-13

Comments (none posted)

ipsec-tools: denial of service

Package(s):ipsec-tools CVE #(s):CVE-2009-1632
Created:May 18, 2009 Updated:July 3, 2009
Description:

From the Mandriva advisory:

Multiple memory leaks in Ipsec-tools before 0.7.2 allow remote attackers to cause a denial of service (memory consumption) via vectors involving (1) signature verification during user authentication with X.509 certificates, related to the eay_check_x509sign function in src/racoon/crypto_openssl.c; and (2) the NAT-Traversal (aka NAT-T) keepalive implementation, related to src/racoon/nattraversal.c (CVE-2009-1632).

Alerts:
SuSE SUSE-SR:2009:012 2009-07-03
Ubuntu USN-785-1 2009-06-09
Gentoo 200905-03 2009-05-24
Debian DSA-1804-1 2009-05-20
CentOS CESA-2009:1036 2009-05-19
Fedora FEDORA-2009-4394 2009-05-08
Fedora FEDORA-2009-4298 2009-05-06
Fedora FEDORA-2009-4291 2009-05-06
Red Hat RHSA-2009:1036-01 2009-05-18
Mandriva MDVSA-2009:114 2009-05-18

Comments (none posted)

kernel: privilege escalation

Package(s):kernel CVE #(s):CVE-2009-1527
Created:May 18, 2009 Updated:May 20, 2009
Description:

From the CVE entry:

Race condition in the ptrace_attach function in kernel/ptrace.c in the Linux kernel before 2.6.30-rc4 allows local users to gain privileges via a PTRACE_ATTACH ptrace call during an exec system call that is launching a setuid application, related to locking an incorrect cred_exec_mutex object.

Alerts:
rPath rPSA-2009-0084-1 2009-05-15

Comments (none posted)

kernel: SELinux check bypass

Package(s):kernel CVE #(s):CVE-2009-1184
Created:May 20, 2009 Updated:July 2, 2009
Description: There is a bug in the SELinux code which can cause a number of networking-related checks to be bypassed when running with compat_net=1.
Alerts:
Ubuntu USN-793-1 2009-07-02
Mandriva MDVSA-2009:135 2009-06-17
Debian DSA-1809-1 2009-06-01
Mandriva MDVSA-2009:119 2009-05-19
Mandriva MDVSA-2009:118 2009-05-19
Debian DSA-1800-1 2009-05-15

Comments (none posted)

nsd: buffer overflow

Package(s):nsd CVE #(s):
Created:May 20, 2009 Updated:May 20, 2009
Description: Versions of the nsd name server daemon prior to 3.2.2 contain a single-byte buffer overflow which can be exploited to crash the daemon. Code-execution exploits are considered to be unlikely. See this advisory for more information.
Alerts:
Debian DSA-1803-1 2009-05-20
Fedora FEDORA-2009-5191 2009-05-19
Fedora FEDORA-2009-5190 2009-05-19

Comments (none posted)

ntp: buffer overflow

Package(s):ntp CVE #(s):CVE-2009-1252
Created:May 19, 2009 Updated:December 4, 2009
Description: From the Mandriva advisory: A buffer overflow flaw was discovered in the ntpd daemon's NTPv4 authentication code. If ntpd was configured to use public key cryptography for NTP packet authentication, a remote attacker could use this flaw to send a specially-crafted request packet that could crash ntpd.
Alerts:
Mandriva MDVSA-2009:309 2009-12-03
Fedora FEDORA-2009-5674 2009-05-30
SuSE SUSE-SR:2009:011 2009-06-09
Slackware SSA:2009-154-01 2009-06-04
Fedora FEDORA-2009-5273 2009-05-20
Fedora FEDORA-2009-5275 2009-05-20
rPath rPSA-2009-0092-1 2009-05-27
Gentoo 200905-08 2009-05-26
CentOS CESA-2009:1040 2009-05-21
Ubuntu USN-777-1 2009-05-19
Debian DSA-1801-1 2009-05-19
CentOS CESA-2009:1039 2009-05-19
Mandriva MDVSA-2009:117 2009-05-19

Comments (none posted)

phpmyadmin: multiple vulnerabilities

Package(s):phpMyAdmin CVE #(s):CVE-2009-1150 CVE-2009-1151
Created:May 18, 2009 Updated:June 30, 2009
Description:

From the Mandriva advisory:

Multiple cross-site scripting (XSS) vulnerabilities in the export page (display_export.lib.php) in phpMyAdmin 2.11.x before 2.11.9.5 and 3.x before 3.1.3.1 allow remote attackers to inject arbitrary web script or HTML via the pma_db_filename_template cookie (CVE-2009-1150).

Static code injection vulnerability in setup.php in phpMyAdmin 2.11.x before 2.11.9.5 and 3.x before 3.1.3.1 allows remote attackers to inject arbitrary PHP code into a configuration file via the save action (CVE-2009-1151).

Alerts:
Gentoo 200906-03 2009-06-29
Debian DSA-1824-1 2009-06-25
Mandriva MDVSA-2009:115 2009-05-18

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current 2.6 development kernel is 2.6.30-rc6, released on May 15. "Things definitely are calming down, with just about 300 commits in the last week. And most of them are pretty small too, although the powerpc updates brought some defconfig changes that look largish." The long-format changelog has all the details.

The current stable kernel is 2.6.29.4, released on May 19. It contains a fair number of fixes, some with apparent security implications, and some user-space API improvements for labeled networking. 2.6.27.24, released at the same time, contains a smaller (but still significant) list of fixes.

Comments (none posted)

Kernel development news

Quotes of the week

The Titanic sank because there was too much water onboard after all. How it got in there (Iceberg, torpedoed by the CIA (oh it did not yet exist) in retaliation for British misbehavior) would be good to know. But the message should not suggest increasing the size of the Titanic because it cannot hold all the incoming water.
-- Christoph Lameter (thanks to Florian Mickler)

Even it if is, in fact, correct, it's such an egregious violation of good style, that your good programmer's card is going to lose a big coupon and have a hole punched in it.
-- Pete Zaitcev

Comments (5 posted)

In brief

By Jonathan Corbet
May 20, 2009

get_random_int() for address space layout randomization was examined on last week's Security page, but, since then, some additional ideas have been discussed. Performance was the main reason to stick with the partial MD4 hash that is in the current code, but other possibilities are being considered. Eric Biederman noted that using a stream cipher such as AES might produce high-quality randomness without the performance penalty, but Matt Mackall didn't agree: "It's also unclear that encrypting small blocks with software AES is actually a performance win relative to SHA1, once you look at the key scheduling overhead and the cache footprint of its s-boxes."

Willy Tarreau pointed out that hash functions used to produce the random numbers actually generate far more data than is currently used. Storing the output of half_md4_transform() (or that of a different implementation using the much stronger SHA1 hash) and returning 4-byte chunks from the full—128 or 160 bit—hash value for each call would perform much better. But, Linus Torvalds is concerned that giving out more of the hash value could lead to easier attacks: "I personally suspect that it would be _much_ easier to attack the hash if we actually gave out the whole 16 bytes (over several iteration), when compared to what we do now (only give out a small part and then re-hash)." No patches emerged from the discussion, but no one is completely happy with the current implementation, so that could change at some point.

OOM by any other name. The out-of-memory (OOM) killer has often been featured on this page. But Christoph Lameter raised a previously unseen complaint about OOM in a recent discussion:

While we are at it: Could we get rid of the name "Out of Memory" and stop printing texts to that effect? What we call an OOM is a failure to perform memory reclaim or we are running out of reserves due to not being able to run reclaim. Mostly this is due to OS internal issues having nothing to do actual amounts of memory available.

Christoph says that users are tempted to add more memory in response to OOM situations, while the real fix is often to be found elsewhere - fixing the application which is locking down the bulk of RAM, for example. There was some discussion of changing the OOM messages to read something like "Unable to satisfy memory allocation request and not making progress reclaiming from other sources," but nothing has been merged at this point.

Tracepoints leave a trace: one of the key design criteria for kernel tracepoints is that their impact must be minimal when they are not being used. So Jason Baron was surprised to find out that, with the current tracepoint implementation, arguments to tracepoints are being evaluated before the determination of whether the tracepoint is active. In response, he prepared a patch to prevent the evaluation of arguments for inactive tracepoints. The patch works, but at a cost: it requires a change to the internal tracepoint API.

There is resistance to the API change, mostly because the people involved seem to think that the new version is uglier and that the problem is really a bug in GCC. It may prove hard to avoid, though; even if GCC is fixed soon, older versions will be out there for a long time. Minimizing overhead is seen as more important than API beauty, so, unless somebody comes up with a clever workaround, there may be no avoiding an unwanted tracepoint change.

Union mounts: there is a new set of union mount patches out there for evaluation, along with the necessary user-space tools. Valerie Aurora has put together a howto page for those who would like to experiment with this code. See this LWN article (also by Valerie) for information on the implementation of union mounts.

Comments (18 posted)

GlusterFS 2.0 released

The GlusterFS 2.0 release is available. GlusterFS is an interesting cluster filesystem which runs mostly in user space and which claims to scale into the petabyte range. See the feature list for an overview. "As your volume size grows beyond 32TBs, fsck (filesystem check) downtime becomes a huge problem. GlusterFS has no fsck. It heals itself transparently with very little impact on performance." License is GPLv3.

Comments (5 posted)

This week's reflink() API

By Jonathan Corbet
May 19, 2009
The proposed reflink() system call creates an interesting cross between a hard link and a file copy. The end result of a successful reflink() call is a new, distinct file - with its own inode - which shares data blocks with the original file. A copy-on-write policy is used, so the two files remain distinct; if one is modified, the changes will not be visible in the other. This call has a number of uses, including fast snapshotting and as a sort of optimized copy operation. But, as was described in the previous article on reflink(), there is some disagreement over how file ownership and security-related metadata should be handled.

It comes down to the different use cases for this system call. In the "snapshot" case, security information must be preserved; that, in turn, means that reflink() can only be used by the owner of the file (or by a process with sufficient capabilities to get around ownership restrictions). On the other hand, those wanting to use reflink() as a fast file copy would rather see security information treated like it would be with a file copy; the user creating the reflink must have read access to the original file and ends up owning the new one.

For a while, it seemed like the reflink-as-copy use case was simply going to be left out in the cold. But then Joel Becker, the author of the reflink() patches, proposed a compromise. If the process calling reflink() had ownership or suitable privilege, the snapshot semantics would prevail. Otherwise, read access would be required and a new set of security attributes would be applied. The idea was to try to automatically do the right thing in all situations.

In the end, though, this approach didn't fly either. From Andy Lutomirski's objection:

There are plenty of syscalls that require some privilege and fail if the caller doesn't have it. But I can think of only one syscall that does *something different* depending on who called it: setuid.

Please search the web and marvel at the disasters caused by setuid's magical caller-dependent behavior (the sendmail bug is probably the most famous). This proposal for reflink is just asking for bugs where an attacker gets some otherwise privileged program to call reflink but to somehow lack the privileges (CAP_CHOWN, selinux rights, or whatever) to copy security attributes, thus exposing a link with the wrong permissions.

Others agreed that automagically changing behavior depending on caller privilege was not the best way to go. So Joel went back to the drawing board yet another time. On May 15, he came back with a new proposal. The reflink() API would now look like:

    int reflink(const char *oldpath, const char *newpath, int preserve);

The new preserve parameter would be a set of flags allowing the caller to specify which bits of security-oriented information are to be preserved. Anticipated values are:

  • REFLINK_ATTR_OWNER: keep the ownership of the file the same. The caller must either be the owner or have the CAP_CHOWN capability.

  • REFLINK_ATTR_SECURITY: preserves the SELinux/SMACK/TOMOYO linux security state. This flag is only valid if REFLINK_ATTR_OWNER is also provided. In the absence of REFLINK_ATTR_SECURITY, the new link gets a brand-new security state, as if it were any other new file.

  • REFLINK_ATTR_MODE: the discretionary access control permissions bits remain the same; requires ownership or CAP_FOWNER.

  • REFLINK_ATTR_ACL: all access control lists are preserved. This only works if REFLINK_ATTR_MODE is specified.

The API would also provide REFLINK_ATTR_NONE and REFLINK_ATTR_ALL, with the obvious semantics. Importantly, if the caller lacks the requisite credentials to preserve the requested information, the call will simply fail. There will be no magically-changing semantics depending on the caller's capabilities.

Joel also proposes some new flags to the ln command:

  • -r requests that a reflink be made.
  • -P says that the reflink() call should use REFLINK_ATTR_ALL
  • -p (lower case) is like -P, except that it will retry with REFLINK_ATTR_NONE if the first call fails.

There were some question as to whether all the flags are necessary; perhaps all that is really needed is "preserve all" or "preserve none." But Joel feels like one might as well add the flexibility, given that the argument is being added to the API anyway, and there doesn't seem to be that much strong sentiment to the contrary. All told, the reflink() API would appear to be stabilizing toward something that everybody can agree on. It's probably late for 2.6.31, but this new system call could conceivably be ready for the 2.6.32 development cycle.

Comments (4 posted)

Block layer request queue API changes

By Jonathan Corbet
May 18, 2009
Prior to the 2.6 kernel series, the Linux block layer was somewhat simplistic and inflexible; it showed a lot of history from the early days of the Linux kernel. With the 2.5 development series came a complete rewrite; there have, of course, been a great many changes since then as well. But there are still bits of history to be found in the Linux block API. If Tejun Heo has his way, some of that history will be gone in the near future.

The standard way for a block driver to gain access to the next I/O request in the queue is with a call to:

    struct request *elv_next_request(struct request_queue *queue);

This function returns the request which is, in the I/O scheduler's opinion, the best one to execute next. An interesting feature of elv_next_request() is that it leaves the request on the queue; two calls to elv_next_request() in quick succession will return pointers to the same request. A block driver can explicitly remove the request from the queue with a call to blkdev_dequeue_request(), but that step is not necessary. If a request remains at the head of the queue when the block driver indicates that it has been completed, the block layer will dequeue the request at that time.

Leaving the request on the queue is a throwback to the very early days, when requests were handled one at a time - often a single sector at a time. By hiding the queuing details, the block layer made life easier for simple block drivers. But this apparent simplicity comes at a cost: it complicates the block API and makes it impossible for the block layer to know when processing of a request has begun. So it's not possible to do reliable request timing when drivers work on requests which remain on the queue.

This feature is also increasingly useless. Any contemporary driver worth its salt will process multiple requests at once; that, in return, requires that the driver dequeue requests and keep track of them itself. So few drivers that people actually care about use the process-on-queue model. Given that, Tejun has come to the conclusion that processing on-queue requests is an idea whose time has passed. He has posted a lengthy patch series to make it go away.

The bulk of the patches are concerned with converting all drivers over to the "dequeue the request first" mode of operation. Typically that's just a matter of adding a blkdev_dequeue_request() call in the right place. A few places (the IDE subsystem, for example) are a bit more complex, but, for the most part, the changes are straightforward.

Once that has been done, the patch series culminates with a set of API changes. There is no more elv_next_request(); instead, a driver wanting to look at a request without dequeueing it will call:

    struct request *blk_peek_request(struct request_queue *queue);

Following that, a request can be dequeued with a call to blk_start_request(), which replaces blkdev_dequeue_request():

    void blk_start_request(struct request *req);

In addition to removing the request from the queue, blk_start_request() will start a timer for the request, allowing it to eventually respond if completion is never signaled. Most of the time, though, drivers will just call:

    struct request *blk_fetch_request(struct request_queue *q);

which is a combination of blk_peek_request() and blk_start_request().

There is one other, under-the-hood change which goes along with the above: any attempt to complete a request which remains on the request queue will oops the system. One can think of this as a very clear message that on-queue processing is no longer considered to be the right thing to do in the Linux kernel. That, in turn, is part of the motivation for the API changes, which, for the most part, are just name changes: Tejun wants to be sure that maintainers of out-of-tree block drivers will notice that something has changed and respond accordingly.

These patches have been through a couple of rounds of review. Nothing is ever certain, but it's entirely possible that this set of changes could go in for the 2.6.31 kernel.

Comments (none posted)

Being nicer to executable pages

By Jonathan Corbet
May 19, 2009
In an ideal world, our computers would have enough memory to run all of the applications we need. In the real world, our systems are loaded with contemporary desktop environments, office suites, and more. So, even with the large amounts of memory being shipped on modern systems, there still never quite seems to be enough. Memory gets paged out to make room for new demands, and performance suffers. Some help may be on the way in the form of a new patch by Wu Fengguang which has the potential to make things better, should it ever be merged.

The kernel maintains two least-recently-used (LRU) lists for pages owned by user processes. One of these lists holds pages which are backed up by files - they are the page cache; the other list holds anonymous pages which are backed up by the swap device, assuming one exists. When the kernel needs to free up memory, it will do its best to push out pages which are backed up by files first. Those pages are much more likely to be unmodified, and I/O to them tends to be faster. So, with luck, a system which evicts file-backed pages first will perform better.

It may be possible to do things better, though. Certain kinds of activities - copying a large file, for example - can quickly fill memory with file-backed pages. As the kernel works to recover those pages, it stands a good chance of pushing out other file-backed pages which are likely to be more useful. In particular, pages containing executable code are relatively likely to be wanted in the near future. If the kernel pages out the C library, for example, chances are good that running processes will cause it to be paged back in quickly. The loss of needed executable pages is part of why operations involving large amounts of file data can make the system seem sluggish for a while afterward.

Wu's patch tries to improve the situation through a fairly simple change: when the page reclaim scanning code hits a file-backed, executable page which has the "referenced" bit set, it simply clears the bit and moves on. So executable pages get an extra trip through the LRU list; that will happen repeatedly for as long as somebody is making use of the page. If all goes well, pages running useful code will stay in RAM, while those holding less useful file data will get pushed out first. It should lead to a more responsive system.

The code seems to be in a relatively finished state at this point. So one might well ask whether it will be merged in the near future. That is never a straightforward question with memory management code, though. This patch may well make it into the mainline, but it will have to get over some hurdles in the process. The first of those hurdles is a simple question from Andrew Morton:

Now. How do we know that this patch improves Linux?

Claims like "it feels more responsive" are notoriously hard to quantify. But, without some sort of reasonably objective way to see what benefit is offered by this patch, the kernel developers are going to be reluctant to make changes to low-level memory management heuristics. The fear of regressions is always there as well; nobody wants to learn about some large database workload which gets slower after a patch like this goes in. In summary: knowing whether this kind of patch really makes the situation better is not as easy as one might wish.

The second problem is that this change would make it possible for a sneaky application to keep its data around by mapping its files with the "executable" bit set. The answer to this objection is easier: an application which seeks unfair advantage by playing games can already do so. Since anonymous pages receive preferable treatment already, the sneaky application could obtain a similar effect on current kernels by allocating memory and reading in the full file contents. Sites which are truly worried about this sort of abuse can (1) use the memory controller to put a lid on memory use, and/or (2) use SELinux to prevent applications from mapping file-backed pages with execute permission enabled.

Finally, Alan Cox has wondered whether this kind of heuristic-tweaking is the right approach in the first place:

I still think the focus is on the wrong thing. We shouldn't be trying to micro-optimise page replacement guesswork - we should be macro-optimising the resulting I/O performance. My disks each do 50MBytes/second and even with the Gnome developers finest creations that ought to be enough if the rest of the system was working properly.

Alan is referring to some apparent performance problems with the memory management and block I/O subsystems which crept in a few years ago. Some of these issues have been addressed for 2.6.30, but others remain unidentified and unresolved so far.

Wu's patch will not change that, of course. But it may still make life a little better for desktop Linux users. It is sufficiently simple and well contained that, in the absence of clear performance regressions for other workloads, it will probably find its way into the mainline sooner or later.

Comments (18 posted)

Patches and updates

Kernel trees

Core kernel code

Development tools

Device drivers

Filesystems and block I/O

Memory management

Architecture-specific

Security-related

Virtualization and containers

Benchmarks and bugs

Miscellaneous

Page editor: Jonathan Corbet

Distributions

News and Editorials

Rescue and recovery distributions

May 20, 2009

This article was contributed by Ivan Jelic

According to the FSF's free software definition, free software gives us the "freedom to redistribute copies so you can help your neighbor". Rescuing your neighbor from their computer problems is another good way of using free software. In this article we look at several distributions that might help you rescue a system for yourself or your neighbors.

Parted Magic 4

Purposely or by accident, Parted Magic happens to have a similar name as one of the best known proprietary disk partitioning tools. Parted Magic fits on a small, 73M, CD. One could even use that old, small USB stick you have lying around.

The default boot option copies the system to RAM, allowing optical devices to be used if necessary. If the system booting Parted Magic has between 128 and 512 MB of RAM, the creator suggests booting from removable media. The "Live with low RAM settings" option applies to the computers with less RAM than previously mentioned, so the system starts only TWM and Gparted by default. The rest of the boot options mainly relate to the graphical setup in cases where the system has an old/exotic graphical subsystem, usable only with Xvesa. Detailed explanations of all boot options are available by pressing F1.

Parted Magic 4 uses LXDE by default. The system starts without automatic network setup, so the connection needs to be initiated by the user. The "start network" GUI does this job, offering a wizard like setup for wired and wireless connections. Gparted is available from the desktop, but the full arsenal of PM's tools is visible in "System tools" menu section.

Besides Gparted 0.4.4, with full common GNU/Linux and FAT/NTFS filesystem (including EXT4) support, other items in the System tools menu make Parted Magic a serious contender for the data rescue and recovery swiss army knife title. Partition and disk cloning are made possible with G4L and Partition Image; data synchronization is taken care of by Grsync (rsync is available from the shell, of course); and ISO editing by is done by ISO Master. The Secure Erase capability of ATA drives is exploited by Erase disk tool. Testdisk and Photorec, particularly useful recovery tools, are also part of Parted Magic.

Parted Magic also finds room for Firefox, Xchat, as well as Gftp and Lftp, which are especially useful for FTPS connections.

SystemRescueCD

SystemRescueCD is aptly named. Rescuing the system with this distribution is not as user friendly as PM, but considering the target audience, a GUI is not that big an advantage.

Booting SystemRescueCD is relatively simple since it doesn't offer predefined options. The system will boot to a shell, with support for the common GNU/Linux filesystems, including EXT4 and BRTFS, and FAT/NTFS. The welcome message gives starting pointers about the available shell tools, network setup interface for wired and wireless connections and X server startup. After the "wizard" X config tool enables the X server (Xvesa is available as na option - "startx" might work too), JWM starts.

SystemRescueCD offers basic filesystem tools together with Gparted, Partimage and Testdisk. In addition to the recovery tools, SRCD provides Firefox and Dillo browsers, Xfburn, Xarchiver, Geany editor, Epdfviewer, Gvim and other general purpose applications. Several looks and searches didn't reveal any hidden graphical file manager, so Midnight commander is the only solution in this context.

Clonezilla live

Parted Magic and SystemRescueCD are intended to be multipurpose solutions, but Clonezilla live is made with only one purpose: to make Clonezilla available on a live system. Beside Clonezilla live, Clonezilla SE is recommended as a solution for massive deployment, which, according to official website "can clone many (40 plus!) computers simultaneously". Since we don't have 40 machines at one place to test it, this article is focused on Clonezilla Live.

In general, Clonezilla live allows the user to clone partition(s) or entire disks, and store images locally or to another machine through the network, using SSH, Samba, or NFS. The list of supported filesystems contains ext2, ext3, reiserfs, xfs, jfs, NTFS, FAT, and HFS+, with EXT4 in a testing distribution branch. Clonezilla provides it's functionality through ncurses based dialogs in a wizard style. The only problem which occured during a routine disk-to-image clone test was the unavailability of any option for going backward in the process. The only option in situations like that is to quit and start over again.

RIPLinuX

Recovery Is Possible LinuX closes this round of recovery and restore distributions. According to our testing experience, it's quite a nice closing.

According to the boot options, RIPLinuX should be able to start an X server automatically, but that option failed for some reason during the test. Startx solved the problem though, and made the Fluxbox desktop available.

The main part of the RIPLinuX graphical interface is the rich Fluxbox menu which makes all of the distribution's capabilities available to the user. The menu is organized in a way that links to documentation about the specific applications that are available right next to them, with a note about its online or offline nature. The choice of rescue and recovery tools which are shipped with RIPLinux is very similar to Parted Magic, with an addition of the Erase disk tool.

It seems that RIPLinuX developers managed to reach the absolute limit of its 92MB image, with plenty of general purpose applications included in the system. Beside Firefox 3.5b4, three text editors, two image viewers, GUI file managers and FTP clients, even Xine and XMMS found their way into RIPLinuX live. Even Gaim is included in case anyone wants use instant messaging from RIPLinuX.

Can there be only one?

With the exception of Clonezilla, which is strictly focused on disk/partition cloning, the rest of distributions share the same purpose. Based on their showing during the tests, Parted Magic and RIPLinuX offered almost the same functionality, with a different look and feel. SystemRescueCD seems to lack the tools the other two have, which puts it behind them.

Given that the user is unlikely to watch videos during rescue and recovery, the choice between Parted Magic and RIPLinuX is strictly personal.

Comments (18 posted)

New Releases

Foresight Linux 2.1.1 is out and about!

The release of Foresight 2.1.1 has been announced. "Well known for being a desktop operating system featuring an intuitive user interface and a showcase of the latest desktop software, this new release brings you the latest GNOME 2.26.1 release, a newer Linux kernel 2.6.29, a revamped notification area, and a ton of Xorg improvements!"

Full Story (comments: none)

jibbed 5.0 released

jibbed is a NetBSD Live CD. "This time it's version 5.0 build from the finest NetBSD-5 sources. As usual the Live CD contains the latest packages from pkgsrc and exclusively three new packages. These are the word processor Abiword and two fantastic games Wormux and Crack-Attack. As always it contains Xorg from base and the xfce4 Window manager."

Comments (none posted)

Mandriva Pulse 2 1.2.1 is available

The Pulse 2 team has announced the release of version 1.2.1 of Pulse 2. "Pulse 2 is an Open Source tool that simplifies application deployment, inventory, and maintenance of an IT network. It has been designed to handle from dozens of computers on a single site to 100 000+ computers spread on many sites."

Full Story (comments: 4)

Announcing the Moblin v2.0 beta for Netbooks and Nettops

The Moblin steering committee has announced the release of Moblin v2.0 beta for Netbooks and Nettops. "With this release, developers can begin to experience and work with the source code of the visually rich, interactive user interface designed for Intel Atom based Netbooks. The Moblin v2.0 user experience has been designed from the ground up to provide unique ways to engage with the internet, aggregate your social networking activity, and enjoy your media content. The new user experience and core applications were developed using the Clutter animation framework, leveraging heavily from GL and the physics engine."

Full Story (comments: 14)

Red Hat Enterprise Linux 4.8 released

The eighth update to Red Hat Enterprise Linux has been released. "Red Hat Enterprise Linux 4, first shipped in February 2005, is now in the Production 2 lifecycle phase. With this, the focus of product updates in the future will shift away from providing significant code changes and focus on providing critical fixes and helping customers evolve their IT plans for eventual migration to Red Hat Enterprise Linux 5."

Comments (1 posted)

Slackware64 Released

Slackware has now gone 64-bit with an official x86_64 port being maintained in-sync with the regular x86 -current branch. "We've been developing and testing Slackware64 for quite a while. Most of the team is already using Slackware64 on their personal machines, and things are working well enough that it is time to let the community check our work." DVDs will be available from the Slackware store with the release of Slackware 13.0.

Full Story (comments: 7)

Tin Hat 20090519 is out!

Tin Hat 20090519 has been released. "Tin Hat is a fully featured Linux desktop based on Hardened Gentoo which runs purely in RAM. It aims to be very secure, stable, and fast. This release concentrates primarily on updating the hardened tool chain, and no changes were made to the kernel since the last release. The system was completely recompiled using hardened Gentoo's stock gcc-4.3.3 plus stack-protection added via the CFLAGS and CXXFLAGS in make.conf. Extensive testing of the most used services and apps gave no issues with the exception of Evolution which required lazy linking."

Full Story (comments: none)

Ubuntu's Karmic Koala Alpha 1 released

The Ubuntu distribution has announced the first Alpha release of Karmic Koala, which will eventually become Ubuntu 9.10. "The primary changes from Jaunty have been the re-merging of changes from Debian, updating to the current Linux kernel, and updating GNOME to the current development release. There are also some infrastructure changes for power management and the Intel video driver."

Full Story (comments: 6)

Distribution News

Fedora

Fedora considering mailing list moderation

It seems that some folks in the Fedora community are getting tired of the tone of the discussion on the project's mailing lists. Thus this proposal from the Fedora board: "the Board appoints one or more Board members or other Board-approved volunteers to monitor Fedora Project mailing lists. The Board will warn violators of our 'Be excellent to each other' policy in the form of a one-day list moderation (with notice to the poster). Messages not allowed through will be returned to the poster with explanation as to why they were not allowed. If after one day of moderation, the violation continues, the case will be brought to the Board for further action, which could include permanent moderation, complete removal from the project, or other remedies."

Full Story (comments: 5)

A flag day for Fedora's flags

Back in March, the Fedora Powers That Be adopted a policy on images of flags (national and otherwise) shipped with Fedora packages. In May, they finally got around to announcing it. In general, such flags must be replaced with non-flag images or split out into a separate, optional "-flags" package. The policy, of course, is motivated by the desire to avoid the hassles which come once people get offended by specific flag images. The resulting discussion is interesting, revealing, among other things, that the GNOME project has a no-flags policy, while KDE has a specific "flags allowed" policy instead.

Full Story (comments: 59)

Fedora 11 for the OLPC XO 1.5

Chris Ball has announced that the upcoming 1.5 version of the OLPC XO will be running Fedora 11. "Unlike previous releases, we plan to use a full Fedora desktop build, booting into Sugar but giving users the option to switch into a standard GNOME install instead. (This will mostly be useful for older kids in high school.)"

Comments (none posted)

One week slip of Fedora 11 Release

The release of Fedora 11 has been delayed for a week. The main cause is this blocker bug. "We cannot begin Release Candidate phase until the blocker bugs are closed or at least in MODIFIED state. We are not there today, which would be our last day to enter RC phase and still have enough time to release on the 26th. We hope to enter RC phase in the next couple days, and hit our new target, June 2nd."

Full Story (comments: none)

Fedora Board elections

The call for nominations for the Fedora Board elections is now open. "There are three seats open for this election, currently held by Tom 'spot' Callaway, Jesse Keating, and Seth Vidal. Two appointed seats are open for this election, currently held by Harald Hoyer and Chris Tyler."

Full Story (comments: none)

Fedora Board Recap 2009-05-14

Click below for a brief recap of the May 14 meeting of the Fedora Advisory Board. Topics include export restrictions, upcoming board elections, and mailing list toxicity.

Full Story (comments: none)

Gentoo Linux

Gentoo Council meeting summary

Click below for a summary of the Gentoo council meeting on May 14, 2009. Topics include wording of PMS for EAPI 3, votes on GLEP 54 and GLEP 55, discussion of dropping static libraries automatically, and council election update.

Full Story (comments: none)

Distribution Newsletters

DistroWatch Weekly, Issue 303

The DistroWatch Weekly for May 18, 2009 is out. "After last week's tip on how to upgrade a stable Mandriva Linux to the distribution's development branch (Cooker), we'll continue the series with a tutorial on running Slackware "Current", the development branch of the world's oldest surviving Linux distro. In the news section, Fedora presents a tentative look at a possible feature set for its next version; Ubuntu announces a new service for cloud computing amid controversy over its proprietary nature; the Debian-Desktop project launches new KDE 4 packages for "Lenny", and PC-BSD continues to expand its desktop options with Xfce and GNOME. Also in this week's issue - a roadmap for Sabayon Linux covering the rest of 2009 and a new security oriented live CD with OWASP. Happy reading!"

Comments (none posted)

Fedora Weekly News 176

The Fedora Weekly News for the week ending May 17, 2009 is out. "In this week's content-rich issue, announcements brings us Fedora Activity Day (FAD) updates from Maylasia and the upcoming Berlin and Porto Alegre FUDCons, and several upcoming Fedora related events in Romania and Brazil. A sampling of the Fedora Planet reveals changes in IcedTea, Eclipse Linux Tools, detail on transitioning from rawhide to Fedora 11, amongst other jewels. In QA news, details from the recent iBus test days and many weekly meeting updates. In Developments, a broken dependency brouhaha flavored the fedora-devel list this week along with discussion of emacs add-ons for the Fedora Electronic Lab spin, and details on being excellent to one another on the list. In translation news, updates to Fedora 11 and news of inclusion of the specspo package in the upcoming release. The artwork team muses about wallpaper gallery developments and needs and final media art prep for F11. Nicu's Fedora webcomic postulates on the F11 pre-release queue, and we complete this week's melange with much news on the virtualization front from the lib-virt list."

Full Story (comments: none)

The Mint Newsletter - issue 84

This issue of the Mint Newsletter looks at the upcoming release of Mint 7 and several other topics.

Comments (none posted)

openSUSE Weekly News, Special Edition

The Community Week special edition of the openSUSE Weekly Newsletter is out.

Comments (none posted)

OpenSUSE Weekly News/72

This issue of the OpenSUSE Weekly News covers Community Week, Pascal Bleser : vnstat on openSUSE, SUSE Linux Enterprise in the Americas: KDE: Social Desktop Starts to Arrive, Forums: Why Are We Not Helping More in the Wiki?, compiz-fusion.org: Beryl back from the ashes, and more.

Comments (none posted)

Ubuntu Weekly Newsletter, Issue #142

The Ubuntu Weekly Newsletter for the week ending May 16, 2009 is out. "In this issue we cover: Karmic Koala Alpha 1 Released, Landscape 1.3 released, Server Team: Hungry for Merges, Meta-cycles: Mark Shuttleworth, Ubuntu Florida: Jaunty Release Parties & Qimo build day, Ubuntu Forums: Tutorial of the Week, Infinote-based Gobby hits Karmic, New Ubuntu Forums LoCo Administrator, Ubuntu podcast #28, WorkWithU Vodcast: Episode #1, Server Team Meeting: May 12th, Hall of Fame: Ante Karamatic, and much, much more!"

Full Story (comments: none)

Page editor: Rebecca Sobol

Development

PIM Data Synchronization: Why is it so hard?

May 18, 2009

This article was contributed by Patrick Ohly

Recently, a SyncEvolution user described SyncML and some of its challenges in an LWN article. In this article, the author of that software adds more information for developers who want to synchronize data. Particular attention is given to Personal Information Management (PIM) data (such as contacts, events, tasks, notes) and how SyncEvolution and the underlying Synthesis SyncML Engine deal with the problems inherent in synchronizing that kind of data.

It is worth pointing out that SyncML as a protocol is data format agnostic and not limited to PIM. PIM is just the most common usage today. In addition, PIM data is particularly difficult to synchronize.

Synthesis just made its core technology available under the LGPL v2.1 and 3.0. SyncEvolution 0.9 beta 1 is the first open source program using libsynthesis. Together, these two projects are the core building blocks for data synchronization in the Moblin project.

PIM Synchronization: Challenges

Whenever your author hears the 1974 Steeley Dan song "Rikki don't lose that number", he wonders whether the advice to "send it off in a letter to yourself" is still valid today, or whether we can trust our software to keep important phone numbers safe and sound. Why is it that synchronization software for PIM data still not 100% reliable?

Database replication is a well understood problem. But PIM data is special in many ways. First, there is no globally unique identifier (GUID) for items. When comparing two databases for the first time, there is often no additional meta-information, beyond the data itself. Without a GUID in the item data, it is hard to determine whether two items from different databases refer to the same entity. In particular, because the content and/or representation of the same logical entity is often different in different databases.

For PIM data, the storage and exchange formats are typically vCard 2.1/3.0, vCalendar 1.0 and iCalendar 2.0. At first glance it seems that items in these formats have a GUID. But the UID property in a vCard is not mandatory in version 2.1 or version 3.0 of the standard. Even if it is used by a particular program, it is not guaranteed to be globally unique and therefore cannot be relied upon when comparing two different databases. The same problem exists with vCalendar 1.0, which is still the most common format used by consumer devices for events and tasks. Only iCalendar 2.0 specifies a mandatory, global UID property because it is required for exchanging meeting invitations.

Without a GUID, one has to compare the content of items to identify matches. But the PIM data formats allow many different more or less complete implementations and representations of the same information. One side of an implementation might support just the bare minimum of information for a contact (for example, name and phone number), while the other side may support everything defined in the standard (photo, arbitrary number of email addresses, and phone numbers), plus non-standard extensions such as spouse and instant messaging handles. A simple byte comparison, without any understanding of the semantics of the data, is therefore not good enough.

After identifying matching items, there is a third problem: if the items differ in some properties, which item is more up-to-date? There are REV and LAST-MODIFIED properties but again, support for them is not guaranteed. Worse, both items might have been created or updated ; independently so that each has valid information the other does not have (new phone number added on my cell phone, address changed on my desktop).

Fourth, it is necessary to support these data formats to be interoperable with existing devices. One cannot simply choose a custom data format that avoids the previous three issues. Neither is it possible to make assumptions about the implementation of a peer and what it may or may not support.

Fifth, not knowing enough about a peer is particularly problematic when receiving an item back from that peer. If a property is missing that was sent to the peer earlier, does that mean that the user has removed this piece of information or that the peer was unable to store it? In the former case, the property must also be removed locally. In the latter, it needs to be preserved while updating the other properties. Only allowing one-way synchronization avoids this problem, but is also considerably less useful.

SyncML

The SyncML protocol (aka Open Mobile Alliance Data Synchronization, OMA-DS) itself is fairly simple, at least up to and including version 1.2.1, the latest version supported by Synthesis and most other implementations. SyncML defines a general message format with encodings, both as XML and the more compact WAP Binary XML (WBXML). The exchange of these messages over HTTP (as POST and reply) and Bluetooth is also standardized. A typical session requires three message exchanges. When sending many small data items (~2KB) with WBXML as the encoding, the measured data overhead for the SyncML protocol was 8%, 2.5 times less than for XML.

During a sync session, a client simply talks to a server. The protocol is intentionally not symmetric. A client is fairly simple to implement and usually only talks to one server. The server implements all of the advanced logic like tracking the state of multiple clients, matching items and merging data.

A client has to keep track of local changes (added/removed/updated) between sync sessions, using its own locally unique identifier (LUID) to refer to items. It then has to be able to export, import, update, and delete items. The server needs to maintain a mapping between GUIDs and the corresponding LUIDs that are used by each client.

At the start of a sync session, client and server authenticate each other and negotiate which databases they want to synchronize (identified by a Uniform Resource Identifier (URI)) and which data formats are acceptable (MIME types). In theory, this information could be used to configure clients automatically. In practice, it is often necessary to configure manually because the information is only sent for URIs that are listed explicitly, leading to a chicken-and-egg problem.

The information about supported data types can be detailed enough to describe which properties of the different PIM formats are supported by a client or server. The Synthesis engine generates this information for its peer automatically from the configuration (more on that below) and uses the information received from its peer to merge updates intelligently. Other servers (such as my.funambol.com) check this information only to determine whether specific properties, like PHOTO, are supported and then hard-code the rest of the data handling.

As part of getting the client and server ready for a synchronization, both agree on the sync modes for active databases. The standard specifies one-way and two-way synchronization, both incremental (the only changes sent are those made since the last synchronization) and complete (all currently existing items have to be sent). For the initial session or after a failure, this "slow" mode is used to get client and server in sync (again). That is, the client sends all of its items then the server compares those items against its own data and sends back changes to the client. As explained above, this matching is problematic therefore the standard also supports complete sync modes, where one side is told to wipe out all data before receiving items ("refresh from client" and "refresh from server").

A session concludes when both sides have sent their changes and some meta-information (for example, new LUIDs assigned by the client). The standard defines a mechanism for suspending a session mid-stream, then resuming it later. The same resume mechanism can also be used to recover from an unexpected loss of connection. This is an optional feature of the standard, supported by the Synthesis implementation but not all servers. Without this feature, a slow sync is necessary to keep client and server reliably in sync.

Synthesis SyncML Engine + SyncEvolution

[Moblin sync
components]

Both the Synthesis SyncML Engine and SyncEvolution are implemented in C++. Synthesis paid particular attention to portability of its code to platforms with less capable compilers. Therefore, the choice of C++ features used is intentionally limited (no hard dependency on exception support, moderate use of templates, and the standard template library). SyncEvolution is less restricted and uses both exceptions for error reporting and the "resource acquisition is initialization" (RAII) design pattern to track resources, plus Boost templates (but no Boost libraries at this point).

The diagram shows how the two projects interact and fit into the Moblin infrastructure. A graphical interface is under development. Solid boxes represent executables and dotted boxes represent libraries. The engine itself is compiled into a library with two stable, plain C APIs:

  • an API for a SyncML client user interface, like SyncEvolution
  • a database API for plug-ins, which connect the engine with local data

The BSD-licensed SDK provides a glue mechanism that can be linked statically to access these APIs in C++, without tying clients closely to the implementation. Bindings for Java are available from Synthesis under a commercial license. The official documentation for this is the Synthesis "SDK and Plug-in Interface" reference manual [PDF], which is included in the open source distribution.

The same API is also designed for use of the engine in a SyncML server, but this part of the API is not completely implemented at this time. The code for the server role exists and is used in Synthesis's server products. It is mostly identical with the code that is used by clients.

The engine uses the same XML-based configuration [PDF] mechanism in both roles. Data format support is not hard-coded in the engine. Instead, the XML configuration defines datatypes and their mapping to the standard formats. So, when using Synthesis for both client and server, the definition of a custom data format has to be written only once. The engine can automatically store data defined this way in a relational database using the Open Database Connectivity (ODBC) API, so it might not even be necessary to write C or C++ code.

Because of the shared engine, clients automatically have some of the features normally found only in SyncML servers, like interpreting device information and intelligently updating only those properties of an item really supported by a peer. With well written peers, this goes a long way towards solving problems four (making assumptions about the peer) and five (getting incomplete items back). For cases where the information provided by a peer is insufficient, the engine also has the possibility of making item parsing and generation depend, for example, on the peer name and/or firmware version.

The engine itself does not implement a particular message transport, which minimizes system dependencies and allows adding custom transports without changing the engine. The client calling the engine is responsible for receiving messages, which are then processed by the engine, and for sending messages generated by the engine. SyncEvolution provides that part for HTTP(S), using either libsoup or libcurl, depending on how it was configured during compilation. It also provides a command line tool, which configures a client and runs a sync session, something which is currently missing in the Synthesis open source release itself. The SyncEvolution 0.9 beta 1 source tar ball includes a copy of the engine source and compiles everything with one "configure; make; make install" invocation. This is the most convenient way of getting started using the source code.

Originally, SyncEvolution was a tool for the Evolution mail and PIM application, but it was always meant to be more flexible and can be compiled without depending on Evolution or GNOME. The Evolution backend is just one of many. Plain files (used for KDE synchronization) and Mac OS X Address Book are also supported. More backends could be added as described in this blog article. The file backend synchronizes files inside a directory and is portable, so it can be compiled on different platforms. When adding these backends, your author dodged the bullet of having to rename the project by reinterpreting the name as "SyncEvolution - the missing link".

Another important component of SyncEvolution is a CPPUnit-based testing system, which runs local database access tests, as well as integration tests with real SyncML servers. With the help of the "synccompare" comparison tool, it checks for data modifications when importing and exporting items locally and sending items back and forth.

Data Modeling and Handling

After introducing Synthesis and SyncEvolution, there is still the question is still: how are the tricky PIM data handling issues solved? The Synthesis Engine merely provides the infrastructure for data handling. The actual data modeling and processing of specific kinds of data is defined entirely in the XML configuration [PDF]. The standard PIM formats are supported out of the box in the "syncclient_sample_config.xml": for each kind of data, it defines one "field list", a more or less flat key/value representation of items that is easier to process automatically than the often complex standard PIM formats. The conversion to and from these formats is defined via "profiles" which map the internal fields to the corresponding properties in the external formats.

There are two ways to define different external representations: it is possible to disable parts of a profile conditionally depending on runtime parameters as well as define multiple profiles which use the same field list. Then data conversion is done by parsing with one profile and encoding with another. The semantic associated with a profile definition is sufficient to generate the SyncML Device Information from that profile automatically and to determine which fields need to be updated when importing an updated item. Merging and comparison is also completely configurable. For more complicated cases, the engine can invoke scripts defined in a C-like language, for example to post-process an item just received from a peer.

Open Issues + Ideas

High on the list of items to work on next is to integrate a SyncML server into the Linux desktop. Synthesis offers a "traditional" http server for Linux and Windows, but this is designed for interaction with remote devices over the Internet. For a local desktop, Bluetooth is perhaps more important. Such a desktop server could also offer a GUI that the user can use to control it and interactively influence its operation. During merge operations, current Internet-based SyncML servers are limited to executing hard coded heuristics and have the difficult choice between duplicating or dropping information. A local server could ask the user to help with merging conflicting items.

The data conversion routines in the Synthesis Engine are currently tied to a SyncML session context. After some non-trivial, but doable, code refactoring, these routines could also be exposed as a set of simple API calls. This may be useful in various projects, like OpenSync.

The goal is to continue with SyncEvolution and Synthesis, not just as open source, but also as open projects, with as much communication on public channels as possible. We are actively seeking involvement and feedback as we get these projects going and as we figure out how to do all of this properly.

Comments (none posted)

System Applications

Database Software

PostgreSQL Weekly News

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

Full Story (comments: none)

SQLite version 3.6.14.1 released

Version 3.6.14.1 of the SQLite DBMS has been announced. "SQLite version 3.6.14.1 is a patch release to version 3.6.14 with minimal changes that fixes three bugs. Upgrading is only necessary for users who are impacted by one or more of those bugs. "

Comments (none posted)

SQLObject 0.9.11 announced

Version 0.9.11 of SQLObject has been announced, it includes minor bug fixes. "SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with."

Full Story (comments: none)

SQLObject 0.10.6 announced

Version 0.10.6 of SQLObject has been announced. "I'm pleased to announce version 0.10.6, a minor bugfix release of 0.10 branch of SQLObject."

Full Story (comments: none)

web2py 1.62.1 released

Version 1.62.1 of web2py has been announced, it includes a number of new capabilities. "web2py includes the only Database Abstraction Layer / ORM that works on both the Google App Engine and relational databases (sqlite, mysql, postgresql, mssql, firebird, oracle, db2). You write once and it runs everywhere. You DO NOT NEED to use the Google API to access the Google Datastore as you do when you use other web frameworks on GAE. web2py writes SQL for you (and you don't even need to see it) and automatically creates a web based interface to your data."

Full Story (comments: 1)

Device Drivers

FFADO 2.0 release candidate 2 (1.999.42) is available

Version 1.999.42 of FFADO, a FireWire audio device interface, has been announced. "This release candidate contains a few reliability improvements and bugfixes that should get some field testing before we can release the official 2.0. I would therefore like to ask all users and packagers to upgrade as soon as possible such that we can release sooner rather than later. If we get to about 100 registered users without significant significant bug reports I feel confident that we're good to go. So happy testing!"

Full Story (comments: none)

Virtualization Software

Xen 3.4 Hypervisor now available

Version 3.4 of Xen Hypervisor has been announced. "The new Xen 3.4 hypervisor offers significant enhancements in Xen Client Initiative (XCI), Reliability - Availability - Serviceability (RAS) and Power Management."

Full Story (comments: none)

Web Site Development

nginx 0.6.37 released

Version 0.6.37 of the nginx HTTP server and mail proxy server has been announced. See the CHANGES document for release details.

Comments (none posted)

Desktop Applications

Accessibility

AxTk adds speech output to wxWidgets

The AxTk project has been launched. "AxTk is a toolkit for building highly accessible applications with speech output. AxTk is built on top of wxWidgets and so is cross-platform. The developer can opt to speech-enable an existing wxWidgets UI, or use a new menu-based interface which is easier for a vision impaired user. AxTk also contains a text to speech wrapper class, wxTextToSpeech, with handlers for a variety of speech engines including SAPI, Mac Speech Synthesis Manager, eSpeak and Cepstral."

Comments (none posted)

Audio Applications

Audacious 2.0.1 released

Version 2.0.1 of Audacious is available, it includes a bug fix in the equalizer code. "Audacious is an advanced audio player. It is free, lightweight, based on GTK2, runs on Linux and many other *nix platforms and is focused on audio quality and supporting a wide range of audio codecs."

Comments (none posted)

ladspa-lgv-plugins 0.1 released

Version 0.1 of ladspa-lgv-plugins has been announced. "First release of the pretentiously named "ladspa-lgv-plugins" includes at the moment just one very simple but very convenient plugin: monomix. No more plugins are scheduled in the near future, but never say never, so I kept it open. It is not rocket science, just a way of easily deal with recordings that use full stereo separation. monomix combines the left and right channels of an stereo audio input into a dual mono output. Its interface offers four preset combinations (L+R, L-R, L-only, R-only) and one customizable mode. This allows to eliminate, isolate or enhance different channels on stereo recordings."

Full Story (comments: none)

TkEca 4.4.0 released

Version 4.4.0 of TkEca, a TCL/TK frontend for the ECASOUND audio editor, has been announced. Changes include: "- LADSPA Loading Window. - Main Window is visible during the LADSPA plug-ins loading. - Message if Tkeca is unable to find ecasoundrc file. - Processing Mixdown window. - Master volume control. - Filenames with spaces are allowed. - Certain buttons get disabled during mixdown. - Compressor utility is no longer available for mixdow, it was useless and buggy. - Bug: Certain buttons remain disabled after exporting .ecs. - Bug: Track Properties windows always reset to default values. - Bug: Always applying compressor due an "IF" error."

Full Story (comments: none)

New LADSPA effect plugin: WubFlip

The WubFlip LADSPA effect plugin has been announced. "I have made a LADSPA effect plugin called WubFlip. It's a sort of distortion that might be useful for dirty lofi beats and synths."

Full Story (comments: none)

Desktop Environments

GNOME Software Announcements

The following new GNOME software has been announced this week: You can find more new GNOME software releases at gnomefiles.org.

Comments (none posted)

openSUSE KDE Community Week Brings Distro And KDE Closer (KDE.News)

KDE.news reports on KDE work during the just-completed openSUSE community week. "As SUSE has opened up and become openSUSE over the last couple of years, the team has adopted a pragmatic bug policy so that bugs which are definitely not specific to openSUSE are moved upstream to bugs.kde.org. This is in everybody's best interest since the bugs end up where there are developers most able to fix them quickly, and our expert team of bug triagers improve the quality of the reported bugs by filtering out packaging issues, broken patches, reports against old versions and reports caused by underlying system problems. Keeping bugs hanging around distro bug trackers for months where maintainers' limited resources mean they get limited attention is frustrating for users who take the time to make reports."

Comments (5 posted)

KDE Software Announcements

The following new KDE software has been announced this week: You can find more new KDE software releases at kde-apps.org.

Comments (none posted)

Xorg Software Announcements

The following new Xorg software has been announced this week: More information can be found on the X.Org Foundation wiki.

Comments (none posted)

Desktop Publishing

rst2pdf 0.10 released

Version 0.10 of rst2pdf has been announced. "It's my pleasure to announce the release of rst2pdf version 0.10. This version includes many bugfixes and some new features compared to the previous 0.9 version. Rst2pdf is a tool to generate PDF files directly from restructured text sources via reportlab."

Full Story (comments: none)

GUI Packages

pyFltk 1.1.4 released

Version 1.1.4 of pyFltk, the Python bindings to the FLTK cross-platform GUI toolkit, has been announced. "This is a maintenance release of pyFltk, supporting fltk-1.1.9 and Python2.6. Changes include some bug fixes and fixes for several compilation issues on OSX and 64bit systems."

Comments (none posted)

wxPython 2.8.10.1 released

Version 2.8.10.1 of wxPython, a Python interface to the wxWindows GUI toolkit, has been announced. "This release fixes the problem with using Python 2.6's default manifest, and updates wxcairo to work with the latest PyCairo."

Full Story (comments: none)

Math Applications

mystic 0.1a2 released

Version 0.1a2 of mystic, a simple model-independent inversion framework, has been announced. "Primarily a bugfix and documentation release."

Full Story (comments: none)

Music Applications

Denemo 0.8.4 released

Version 0.8.4 of the Denemo music notation editor has been announced. "Some of the new features are improvements for scripting support and user-created commands and improved MIDI-output. Official support, beneath our website, is avaible via our IRC channel #denemo on irc.freenode.net."

Full Story (comments: none)

Languages and Tools

Caml

Caml Weekly News

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

Full Story (comments: none)

Python

Python-URL! - weekly Python news and links

The May 14, 2009 edition of the Python-URL! is online with a new collection of Python article links.

Full Story (comments: none)

Tcl/Tk

Tcl-URL! - weekly Tcl news and links

The May 20, 2009 edition of the Tcl-URL! is online with new Tcl/Tk articles and resources.

Full Story (comments: none)

Libraries

User space RCU library relicensed to LGPLv2.1

Mathieu Desnoyers has announced that liburcu, a user-space implementation of Read-copy update (RCU) is now available under the LGPL v2.1. RCU is a technique used by the Linux kernel to handle concurrent access to data structures without locking. It was patented originally by Sequent and is now held by IBM, which previously had licensed it only for GPL-licensed implementations. "liburcu is a LGPLv2.1 userspace RCU (read-copy-update) library. This data synchronization library provides read-side access which scales linearly with the number of cores. It does so by allowing multiples copies of a given data structure to live at the same time, and by monitoring the data structure accesses to detect grace periods after which memory reclamation is possible." Click below for the full announcement.

Full Story (comments: 24)

Miscellaneous

DeHaan: Recognizing and Avoiding Common Open Source Community Pitfalls

Michael DeHaan looks at open source development misconceptions in a posting to his blog. In it, he looks at around a dozen different "stumbling blocks" that projects might run up against. "What typically isn't written though are about some of the misconceptions — A lot of folks contributors appear overnight out of the woodwork, that users grow on trees, and that it's possible to direct community members as if they were employees — not so, of course, and folks get disappointed or discouraged when it doesn't happen."

Comments (none posted)

Page editor: Forrest Cook

Linux in the news

Recommended Reading

OpenSSH chink bares encrypted data packets (Register)

The Register covers an OpenSSH bug. "The attack exploits subtle differences in the way SSH software reacts when encountering errors during cryptographic processing. By directing specially manipulated packets at the application, an attacker has a one in 262,144 chance of recovering 32 bits of plaintext from an arbitrary chunk of ciphertext. While those are extremely limited odds, the design flaw still poses a significant threat given the way many applications that employ SSH work."

Comments (8 posted)

Reviews

Intel brings rich UI to Moblin Linux platform (ars technica)

ars technica plays with the new Moblin beta. "Moblin uses an unusual task management paradigm that is well-suited to mobile devices. Applications are organized into "zones," which are loosely analogous to virtual desktops. When I launch an application, the shell will automatically create a new zone in which to house the program's windows. When all of the windows in a zone have been closed, the shell will automatically remove the Zone. The zones tab on the Moblin panel will display thumbnail previews of all of the windows in each zone. You can switch to a certain zone or window by clicking, and you can move windows between zones by dragging and dropping the thumbnails. The zones tab in the shell is Moblin's replacement for the conventional taskbar."

Comments (1 posted)

Miscellaneous

Tom, I Can Name That Distro in Two Notes (Linux Journal)

Linux Journal takes a look at Fedora's naming scheme. F12 nominations are open. "The method for choosing the the nom de plume for the behatted distro is deceptively simple: The new name must share a link to the old name, and that link must follow the pattern "X is a Y, and so is Z." An example, from the last Fedora name contest: "Cambridge was a ship of the Union Navy, and Leonidas was too." Cambridge (X) was the preceding release name, from Fedora 10, Leonidas (Z) was the winning submission, and the connection between the two was that both were ships in the Union Navy (Y)."

Comments (15 posted)

The pursuit of (MySQL) openness

The MySQL DBMS community and enterprise binaries will now be released on the same schedule, according to this Sun blog by Giuseppe Maxia. "We kept going, and we kept pushing, until we got the announcement at the MySQL Conference 2009, stating the end of the binary split. Now the community server binaries will be published as often as the enterprise ones. The rationale of this request is that the strength of MySQl is in its wide community. We claim that the MySQL server is tested by millions of users, and yet we were giving the GA (mature) binaries only to a handful of customers. This looked like a privilege, but it was in fact, from an engineering standpoint, a disadvantage. As a customer, I would gladly adopt a software that has been installed by a few million people, rather than being the privileged first one to try it in production." This minor revision note sums up the change: "Merge community up to enterprise, thus ending the community-server adventure." (Thanks to Bart Cortooms).

Comments (none posted)

Open Database Alliance hedges against Oracle plans for MySQL (ars technica)

Here's a look at movement in the MySQL community from ars technica. "Some key developers in the MySQL community are launching a new coalition called the Open Database Alliance which intends to coordinate collaborative MySQL development. The alliance—which currently consists of Monty Program Ab, Percona, and OpenQuery—aims to provide an inclusive, vendor-neutral environment for moving forward MySQL development. Their efforts will attempt to insulate MySQL from Oracle's competitive interests by giving the collective MySQL community enough leverage to control the project's destiny."

Comments (37 posted)

Page editor: Forrest Cook

Announcements

Non-Commercial announcements

FSF settles with Cisco

The FSF has announced a settlement in its GPL-infringement lawsuit against Cisco. "Cisco has agreed to appoint a Free Software Director for Linksys, a subsidiary of Cisco, to supervise Linksys' compliance with the requirements of free software licenses such as the GPL (the GNU General Public License). The Free Software Director will report periodically to the FSF regarding Linksys' compliance efforts. Cisco has further agreed to take certain steps to notify previous recipients of Linksys products containing FSF programs of their rights under the GPL and other applicable licenses, to publish a licensing notice on the Linksys website, and to provide additional notices in a separate publication. In addition, Cisco will continue to make the complete and corresponding source code for versions of FSF programs used with current Linksys products freely available on its website. Cisco will also make a monetary contribution to the FSF."

Full Story (comments: 29)

Gnash Summer Project Seeks Donations

The Gnash free flash player development team has announced the "Gnash V9 Summer Bash". "The non-profit organization Open Media Now, which manages Gnash, is seeking donations in support of its summer v9 project. "We are halfway to our fundraising goal now and need to raise another $75,000 to make the project a success" says OM Now Executive Director Lauren Riggin. "This is a project that impacts how we, as a community, access and provide web content. So, naturally, we are hoping for a wide spectrum of support from individuals, organizations, and companies -- anyone wanting an alternative to proprietary flash. Five dollars or $50,000, it all says 'Go-for-it'! And that's what we love to hear."" Find out more about the Gnash V9 Summer Bash.

Comments (13 posted)

GNOME foundation needs your vote for Board elections 2009 (GnomeDesktop)

The GNOME foundation has announced the 2009 Board elections. "As you should know, the GNOME foundation is run by a board of 7 directors known as "The Board". After 18 months of active duty, it's now time to refresh either the blood or our confidence. Which means: GNOME Board Elections 2009. May 22th : deadline to apply as a candidate May 22th-25th : send your questions for the candidates June 3rd-17th : Voting period July 3rd : old and new board meet at GUADEC"

Comments (none posted)

Zemlin: Strange Bedfellows: The Linux Foundation and Microsoft

Linux Foundation (LF) executive Jim Zemlin comments on the recent joint letter [PDF] from the LF and Microsoft. The letter is in response to a draft "Principles of the Law of Software Contracts" statement from the American Law Institute. "As Horacio E. Gutiérrez, Microsoft Corporate Vice President and Deputy General Counsel points out in his blog and the letter also states: 'Notwithstanding our varying approaches to the licensing and distribution of software, we share a common desire for a sound, effective commercial law framework for software contracts that reflects business and community realities. Such a framework will ultimately increase the variety and functionality of software available, benefitting both businesses and consumers.'"

Comments (7 posted)

Openmoko: more hardware info and gta02-core

OpenMoko has released more information about the design of its current "gta02" platform. The purpose of this release is to help support the gta02-core project, which is doing a community-based redesign of this hardware. "The gta02-core project is primarily a test-bed for the community development process. While it's hoped to take the process through working prototypes, the project is not intended to result in a mass-production phone. If the community succeeds in the gta02-core project, development of a GTA03 may follow similar lines with community involvement in specifying, designing and developing the hardware."

Full Story (comments: none)

New Books

Beautiful Security - New from O'Reilly

O'Reilly has published the book Beautiful Security edited by Andy Oram and John Viega.

Full Story (comments: none)

XMPP: The Definitive Guide - New from O'Reilly

O'Reilly has published the book XMPP: The Definitive Guide by Peter Saint-Andre, Kevin Smith, and Remko Tronçon.

Full Story (comments: none)

Contests and Awards

Inkscape 0.47 about screen contest announced

The Inkscape 0.47 about screen contest has been announced. "As usual, since we will be releasing a new version of Inkscape in the near future, we need to have a new about screen done. Do you think you're up to the challenge of making one? Here is a chance to have your art being the about screen of the next release! Read more details and the rules here. Deadline for submissions is May 25, 2009."

Comments (none posted)

Calls for Presentations

SciPy 2009 Call for Papers

A call for papers has gone out for SciPy 2009. "SciPy 2009, the 8th Python in Science conference, will be held from August 18-23, 2009 at Caltech in Pasadena, CA, USA. Each year SciPy attracts leading figures in research and scientific software development with Python from a wide range of scientific and engineering disciplines. The focus of the conference is both on scientific libraries and tools developed with Python and on scientific or engineering achievements using Python." Abstracts are due by June 26.

Full Story (comments: none)

Upcoming Events

BugCON '09 has swine influenza

BugCON 2009 has been postponed, the new time and location have not been chosen. "As maybe you know during two weeks Mexico suffered an epidemic, so the institute where BugCON going to be change the dates of all activities, including BugCON, this week we will have confirmed the new dates, probably BugCON will be on Agust. For these reason, BugCON mantein its CFP open from this moment to June 22th. You can read more about BugCON at www.bugcon.org".

Full Story (comments: none)

Conference on Cyber Warfare: registration open

Registration is open for the Conference on Cyber Warfare. "Registration is now open for the CCD CoE Conference on Cyber Warfare, which will take place at the Estonian National Theater on June 17-19, 2009. Following a worldwide Call for Papers, there will be 29 presentations given by researchers from 13 countries."

Full Story (comments: none)

Linux Installfest workshop in Davis, CA

The Linux Users' Group of Davis has announced its next Linux Installfest, the event takes place in Davis, CA on May 30.

Full Story (comments: none)

LPC 2009 Keynote and other speaker updates

Some keynotes for the 2009 Linux Plumbers Conference have been announced. "Keynotes: * Vivek Kundra, Federal CIO (live via video, with real time Q&A) (Invitee - To be confirmed) * Keith Packard, Intel, X Window guru Tutorials: * Linus Torvalds, Advanced git tutorial" The event takes place on September 23-25 in Portland, OR.

Full Story (comments: none)

OpenMoko Freerunner phones discounted for DebConf attendees

DebConf attendees will be offered discounted OpenMoko Freerunner phones. "The folks at Tuxbrain have a surprise for DebConf attendees, with which they want to support the community and drive innovation and progress: For €249 incl. 16% VAT (deductable upon presentation of a valid EU VAT ID), you can pre-order: - a "buzz-free" Openmoko Neo Freerunner phone (A7) ("buzz-free" means it's free of the infamous "buzz" bug) - an extra battery - a headset - a debugging board (v3)"

Full Story (comments: none)

Events: May 28, 2009 to July 27, 2009

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

Date(s)EventLocation
May 25
May 29
Ubuntu Developers Summit - Karmic Koala Barcelona, Spain
May 27
May 28
EUSecWest 2009 London, UK
May 28 Canberra LUG Monthly meeting - May 2009 Canberra, Australia
May 29
May 31
Mozilla Maemo Mer Danish Weekend Copenhagen, Denmark
May 31
June 3
Techno Security 2009 Myrtle Beach, SC, USA
June 1
June 5
Python Bootcamp with Dave Beazley Atlanta, GA, USA
June 2
June 4
SOA in Healthcare Conference Chicago, IL, USA
June 3
June 4
Nordic Meet on Nagios 2009 Stockholm, Sweden
June 3
June 5
LinuxDays 2009 Geneva, Switzerland
June 6 PgDay Junín 2009 Buenos Aires, Argentina
June 8
June 12
Ruby on Rails Bootcamp with Charles B. Quinn Atlanta, GA, USA
June 10
June 11
FreedomHEC Taipei Taipei, Taiwan
June 11
June 12
ShakaCon Security Conference Honolulu, HI, USA
June 12
June 13
III Conferenza Italiana sul Software Libero Bologna, Italy
June 12
June 14
Writing Open Source: The Conference Owen Sound, Canada
June 13 SouthEast LinuxFest Clemson, SC, USA
June 14
June 19
2009 USENIX Annual Technical Conference San Diego, USA
June 17
June 19
Open Source Bridge Portland, OR, USA
June 17
June 19
Conference on Cyber Warfare Tallinn, Estonia
June 20
June 26
Beginning iPhone for Commuters New York, USA
June 22
June 24
Velocity 2009 San Jose, CA, USA
June 22
June 24
YAPC|10 Pittsburgh, PA, USA
June 24
June 27
LinuxTag 2009 Berlin, Germany
June 24
June 27
10th International Free Software Forum Porto Alegre, Brazil
June 26
June 28
Fedora Users and Developers Conference - Berlin Berlin, Germany
June 26
June 30
Hacker Space Festival 2009 Seine, France
June 28
July 4
EuroPython 2009 Birmingham, UK
June 29
June 30
Open Source China World 2009 Beijing, China
July 1
July 3
OSPERT 2009 Dublin, Ireland
July 1
July 3
ICOODB 2009 Zurich, Switzerland
July 2
July 5
ToorCamp 2009 Moses Lake, WA, USA
July 3 PHP'n Rio 09 Rio de Janeiro, Brazil
July 3
July 11
Gran Canaria Desktop Summit (GUADEC/Akademy) Gran Canaria, Spain
July 4 Open Tech 2009 London, UK
July 6
July 10
Python African Tour : Sénégal Dakar, Sénégal
July 7
July 11
Libre Software Meeting Nantes, France
July 13
July 17
(Montreal) Linux Symposium Montreal, Canada
July 15
July 16
NIT Agartala FOSS and GNU/Linux fest Agartala, India
July 15
July 17
Kernel Conference Australia 2009 Brisbane, Queensland, Australia
July 18
July 19
Community Leadership Summit San Jose, CA, USA
July 19 pgDay San Jose San Jose, CA, USA
July 19
July 20
Open Video Conference New York City, USA
July 20
July 24
2009 O'Reilly Open Source Convention San Jose, CA, USA
July 24
July 30
DebConf 2009 Cáceres, Extremadura, Spain
July 25
July 26
EuroSciPy 2009 Leipzig, Germany
July 25
July 26
PyOhio 2009 Columbus, OH, USA
July 25
July 30
Black Hat Briefings and Training Las Vegas, NV, USA
July 26
July 27
InsideMobile San Jose, CA, USA

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

Mailing Lists

Python Concurrency email list announced

A new Python Concurrency email list has been announced. "python-concurrency@googlegroups.com is a new email list for discussion of concurrency issues in python. It arose out of Dave Beazley's class on the subject last week: http://www.dabeaz.com/chicago/concurrent.html". Also, a new Python Concurrency wiki site has been launched.

Full Story (comments: none)

Web sites

ESP launches en.swpat.org

ESP has announced the launch of en.swpat.org. "End Software Patents today launched en.swpat.org, a wiki to document the case against software patents. Over 100 articles have already been started to give an idea of the scope and structure of the wiki."

Full Story (comments: none)

Miscellaneous

O'Reilly Webcast: What to Expect in Rails 3.0

O'Reilly has announced a May 22 webcast by Yehuda Katz on Rails 3.0. "Considered by many developers to be one of the fastest frameworks for building applications, Rails has come a long way since 2005. Slated for release later this year, Rails 3 will feature some innovative new features that will make the developer experience even better. Rails 3 will also be the first release that rolls in the popular Merb project. In this live, online event, Yehuda Katz, Core Team Member on the Rails and Merb projects, will cover some of most important new features in Rails 3.0 and answer questions from the audience."

Comments (none posted)

Page editor: Forrest Cook

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