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)
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
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.
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)
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
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
Comments (none posted)
Page editor: Jake Edge
Kernel development
Brief items
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
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)
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)
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)
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)
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)
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
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
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 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)
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)
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)
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)
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 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)
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
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)
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)
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)
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)
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)
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
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
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)
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)
This issue of the
Mint
Newsletter looks at the upcoming release of Mint 7 and several other
topics.
Comments (none posted)
The
Community
Week special edition of the openSUSE Weekly Newsletter is out.
Comments (none posted)
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)
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
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
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
The May 17, 2009 edition of the PostgreSQL Weekly News
is online with the latest PostgreSQL DBMS articles and resources.
Full Story (comments: none)
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)
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)
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)
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
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
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
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
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
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)
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)
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)
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
The following new GNOME software has been announced this week:
You can find more new GNOME software releases at
gnomefiles.org.
Comments (none posted)
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)
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)
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
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
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)
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
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
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
The May 19, 2009 edition of the Caml Weekly News
is out with new articles about the Caml language.
Full Story (comments: none)
Python
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
The May 20, 2009 edition of the Tcl-URL! is online with new
Tcl/Tk articles and resources.
Full Story (comments: none)
Libraries
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
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
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
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
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 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)
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 alliancewhich currently consists of Monty Program Ab, Percona, and OpenQueryaims 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
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)
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)
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)
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 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
O'Reilly has published the book
Beautiful Security
edited by Andy Oram and John Viega.
Full Story (comments: none)
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
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
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 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)
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)
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)
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)
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) | Event | Location |
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
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 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 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