By Jake Edge
April 1, 2009
When we last looked in on
GCC, the 4.4 release branch was held up by licensing issues,
specifically the exemption that would allow GCC plugins. Since that time,
things have progressed—there is now a 4.4 release branch—but the
license issue has not yet been completely resolved, though a new revision is
available. But, since the license change is not
needed for the 4.4 release, some GCC hackers are unhappy about the manner
in which the release was held up. It has led to questions about the roles
of the Free Software Foundation (FSF) and the GCC steering committee (SC)
have in controlling GCC development.
Holding up a release for licensing concerns is seen by many as a reasonable
request that the FSF might make. That organization is very concerned about
licenses, in general, and they certainly think it is important to get the
license right before releasing any code under the license. It is the
concerns expressed by GCC developers about the wording of the runtime
library exception that led to the license review. But Richard Stallman,
acting for the FSF, did not ask that the release be delayed—at least
directly—he asked that no release branch be created. The net effect
on the release process is the same (i.e. no release), but the impact on
development of new features destined for GCC 4.5 is a large part of what
irked the GCC developers.
The other piece of the puzzle is that the issue is essentially moot: there
is no plugin API in GCC 4.4 that would require the runtime library
exemption changes. Stallman is adamant that proprietary GCC plugins be
outlawed before such an API gets added. But, since the API isn't present
(yet), the license changes aren't needed yet either. So, while it makes
sense to take whatever time is required to get the license right, many
seem very puzzled as to why that would need to hold up the release
and new development.
There has never been a clear explanation of why the release branch
needed to be delayed, at least publicly. Either Stallman
relented—perhaps due to completing the license rewording—or the
SC eventually decided to override his request because the release branch
was created on March 27. But there was clear discontent in the ranks that
the SC could, evidently, be pushed around so easily by the FSF. This led
to questions about the role of the SC, how much control over "technical"
decisions the FSF has, and, in general, how the project is governed. As
Daniel Berlin put it: "Where is the
pushback by the SC onto the FSF?"
Berlin's complaint was that it has taken the FSF too long to resolve the
issue, to the point where it is now (and has been for a bit) seriously
impacting GCC development. Because the license change is not required for
this release, there is no good reason to delay it. Ian Taylor was fairly blunt:
I'm a strong supporter of the FSF, but I agree with Danny. This has
gone on far too long. Releasing gcc 4.4.0 with the same licensing as
gcc 4.3.0 will do no significant harm. The FSF is acting
inappropriately in restricting us in this way.
In response to Berlin's criticism of their response, SC member David
Edelsohn noted that there were things going
on behind the scenes:
Why do you think that the SC has not pushed back? Not all diplomacy
is best done in public. This is frustrating for all of us.
But a lack of communication from the SC to the greater GCC community is
part of the problem, according to Berlin:
Okay then, as the leadership body of the GCC community, part of your
responsibility is keeping your constituents (the rest of us!) informed
of the status of things troubling them.
I don't believe saying "we have given the FSF a deadline to meet in
the near future" would at all endanger any diplomacy, and i'd love to
see a counter argument that says otherwise.
The discussion then turned to the role that the FSF plays in GCC
development. SC member Joe Buck points out
that the FSF holds the cards: "The problem in this instance is that
the SC has little power; it's
the FSF that's holding things up and I don't know more than you do."
But that doesn't sit well with some. Steven Bosscher asks:
I don't understand this. Why does the SC have little power in this
matter? Surely you could decide to ship GCC 4.4 with the old license,
as the official GCC maintainer? But you *choose* not to use this
power (perhaps for good reasons, but I'm unconvinced).
Others believe that the FSF should be in complete control. Richard Kenner outlines how he sees the relationship:
The matters to which we defer to the FSF are any matters that they *ask*
us to! They own the code. If RMS, for some reason, decides that he doesn't
like the phrasing of a comment somewhere, we have to either convince RMS
he's wrong or change the comment.
As a practical matter, the FSF *delegates* most of their responsibilities
to the maintainer of the package, but they can undo that delegation as to
any matter any time they want.
Berlin would like to see the governance
structure for GCC more clearly
spelled out. The SC web
page seems to indicate that its role is to prevent the project from
being controlled by any party. But whether the SC is supposed to prevent
the FSF from controlling its own project was disputed. Ultimately,
the developers do have some power as Buck states: "There are checks on FSF control
in the sense that the project can be
forked and developers can leave."
That kind of talk inevitably leads some to mention the egcs/GCC split,
and subsequent join, as an example of the power that the development
community has. No one has said they are seriously considering a fork, but
the GPL certainly allows such things if the FSF's hand gets too heavy.
Jeff Law doesn't see it coming to that:
FWIW, I don't think we're anywhere near the same kind of tipping point
we faced a dozen years ago. I believe both sides learned lessons along
the way and I actually see evidence of that in the simple fact that
we've got a license and blessing to go forward with a plugin framework.
Clearly some developers are chafing under what they see as unnecessary
interference in technical issues from Stallman. But as Buck points out, Stallman does not dictate
technical details to GCC. Various decisions (bugtracker, version control,
etc.) have gone against his express wishes. In addition, contrary to
Stallman's aversion to C++, Taylor has used that language for the gold linker, and currently has a
branch that implements some of GCC in C++.
He sees things this way:
While agreeing that the FSF is the legal owner of the code, I personally
consider the implementation language to be a technical detail which the
FSF has no special control over. We can consider their input, but we
need not follow it. This is distinct from licensing issues, where we
had to either move to GPLv3 or fork into an independent project.
This discussion will hopefully lead to a clearer picture of the governing
structure of GCC. With luck, it may also make Stallman and the FSF more
cognizant of the perception that they are meddling in technical issues to
the detriment of their relationship with at least some in the community.
No one in the rather long thread could come up with any sensible reason
that the release branch should have been held up. At best, that means that
Stallman didn't communicate the why, which leads many to a sense
that he is being rather arbitrary.
In the meantime, though, GCC is preparing for the 4.4 release. Release
manager Mark Mitchell created the release branch, Bosscher is rounding up folks to update the 4.4 changes page, and
work is proceeding towards a release. That also allows the changes for 4.5
to be added to the trunk, which puts that release back on track.
With GCC 4.5 there will likely be a new plugin API for which the license
change is needed. On April 1, Edelsohn announced that the revised runtime library
exception had been released. It explicitly allows for Java byte code
to be used as input into GCC, making a "compilation process" using that
input eligible
for the runtime library exception. One of the other concerns, regarding
independent modules, will be addressed in the FAQ,
though it has not been at the time of this writing.
Assuming the new exception passes muster on the gcc-devel list, and no
problems are found that would require adjustments, it will presumably end
up in the 4.4 release. While that should conclude this particular issue,
the overarching governance questions will remain.
Comments (11 posted)
April 1, 2009
This article was contributed by Nathan Willis
Xiph.org achieved a milestone last
week, unveiling the
first public release of its new encoder for Theora video. The new encoder is codenamed
Thusnelda to distinguish it from previous work, and makes several big
improvements, including fixes to constant bitrate and variable bitrate
encoding.
Theora is derived from a video codec called VP3 created by On2
Technologies. On2 donated the code to VP3 and to the public under an open
source license in 2001, and agreed to help Xiph.org develop Theora as its
successor. The specification for the Theora codec's format was finalized in
2004, but the reference encoder itself — the actual binary that
converts a video file into Theora format — only reached 1.0 in
November of 2008. Work on Thusnelda began shortly thereafter, spearheaded
by Xiph.org's
Christopher Montgomery, but was bolstered by a grant
from Mozilla and the Wikimedia Foundation that allowed lead Theora
developer Tim Terriberry to focus on improving the encoder to coincide with
the built-in Theora support slated for Firefox 3.5.
What's new
The Thusnelda encoder is denoted 1.1 alpha, and is available
for download from Xiph.org in several formats: source code for the
libtheora library, binaries of the ffmpeg2theora command-line conversion
utility, and even a Mac OS X Quicktime component.
According to Xiph.org's Ralph Giles, the most noticeable improvement in
1.1 is proper rate control, particularly for fixed bit rate encoding, where
the user specifies either the number of bits per second desired in the
output (a common use case for streaming applications), or the desired file
size. "The 1.0 encoder relies a lot on heuristics, instead of trying
to optimize directly the trade-off between quality of the coded images and
the number of bits used to represent them," he said, "More
significantly, the fixed bitrate mode in the 1.0 reference encoder didn't
really work; it just guessed how to meet its target and often missed the
requested bitrate, sometimes by quite a bit, which was a problem for
streaming and fixed-size encodes."
But Montgomery's work — supported for a year by his employer Red
Hat — also included extensive refactoring of the code, which should
result in improvements today and allow for easier changes moving
forward. "The older encoder was structured as a bunch of nearly
independent passes," Giles said, "[it] made something like 8
passes over each frame. This made some forms of decision making hard,
i.e. if an earlier decision caused you problems (higher bitrate) in a later
stage you were out of luck. The new encoder collapses most of the
passes."
The restructuring also allows Thusnelda to take advantage of features in
the Theora specification that had never been implemented before, such as
"4MV" macroblocks, a motion compensation scheme that adaptively chooses
whether to encode motion information for an entire segment of the picture,
for a sub-segment, or for none of the segment. "Theora always breaks
each image up into square blocks," Giles explained, "one of
those blocks then can be split into four motion vectors, or use an average,
and if any of those four don't need to be coded, the alpha encoder can skip
coding a corresponding motion vector. Making a change like that was too
difficult with the 1.0 codebase."
Measuring success
Naturally, real-world performance and not a feature list is the primary
means of assessing an encoder. Theora has been the object of criticism in
years past, especially when compared against proprietary offerings such as
H.264. Reader comments on news stories at Slashdot often dismissed Theora
as a poor alternative, producing larger files than the competition for the
same subjective quality.
Codec testers are always at the mercy of the encoder, however, and as
noted above Theora's 1.0-series encoder had significant flaws, especially
with respect to constant bitrate encoding. In the oft-cited doom9.org 2005 codec
shootout, the Theora encoder performed poorly by failing to meet the
target file size due to poor rate control; the very feature targeted in the
1.1 branch. Similarly, Eugenia Loli-Queru's 2007 Theora versus
H.264 test for OSNews repeatedly cited problems with the encoder that
made direct comparison close to impossible.
Both tests pre-date the 2008 release of
the final 1.0 encoder, much less the 1.1 alpha. Shortly after the
Thusnelda alpha, Jan Schmidt posted the results of his personal
tests on his blog, indicating a 20% reduction in file size and 14%
reduction in encoding time over the 1.0 encoder. Those are significant
numbers, even without accounting for better rate control and other encoding
parameter improvements. As commenters to the blog pointed out, Schmidt's
test was not scientific, particularly as it involved re-encoding an H.264
file rather than a lossless original, and showed example still frames
rather than video results.
Video quality is ultimately a subjective, human-centric measure.
Although there are attempts to quantify video encoding quality, such as peak
signal-to-noise ratio (PSNR) and structural similarity index
(SSIM), they rarely replace subjective evaluations of quality. Xiph's
Gregory Maxwell said that Thusnelda improves on Theora's PSNR, but that it
was a mistake to assume that that equated to a subjective improvement for
any particular use case.
To an extent the objective metric problem is
equal to the coding problem. If we had a perfect metric we could probably
make a perfect encoder (ignoring a lot of engineering details) ... If we
could objectively know what 'looks good' then we could make a coder which
uses that metric to decide what to code. Then the problem of coding
largely reduces to efficiently packing information, which is well
understood. So in any case, objective metrics are usually useful for
measuring the results of small changes which are mostly 'objective' in
nature; they aren't very useful for measuring perceptual changes, nor are
they useful for comparing dramatically different codecs.
Terriberry concurred, noting that none of the simple objective metrics
take any kind of temporal effects into account, and they are still less
trustworthy than the processing done in the brain. "Like most
things, it's a matter of knowing what the limitations of your tools
are. PSNR and SSIM are useful for monitoring day-to-day changes in the code
to identify regressions and optimize parameters. But for evaluating
fundamentally different approaches, there's currently no substitute for
using real humans."
Theora took hits from critics on subjective quality in the 2005 and 2007
tests, too, points which Montgomery responded to in 2007 with a page on
his personal Web site. Although some subjective quality issues like
discernible blockiness are not the result of problems with the 1.0 encoder,
he argued, many of the most visible problems are, and he urged readers to
watch the progress made in the 1.1 series.
What's next
There are several improvements still to come before 1.1 is declared
final, according to the Theora team. Giles said the next major feature
will be per-block quantizers, the functions that simplify a block of input
data into smaller values for output. "[Theora precursor] VP3 used a
fixed set of quantizers, and the "quality" knob was the only way you could
change things. When VP3 became Theora, back 2004, we added support for
varying those quantizers both per video, and per frame type. The 1.0
encoder was able to support alternate quantizer matrices, because you just
switch them out, but there were some tuning issues."
"1.1alpha1 is still using the same set, but we expect that the
change soon," Giles said. The newly-restructured codebase makes it
easy to vary the quantizer used, not just on a per-file or per-frame basis,
but block-by-block. Terriberry added that the new code will support 4:2:2
and 4:4:4 pixel formats, which will allow higher color quality, and the
ability to use different quantization
matrices for different color channels and frames.
Giles and Terriberry agreed that 1.1 final will be significantly better
than even the current alpha release once all of the changes are
incorporated. Terriberry noted that many of the remaining improvements are
"minor things" but that added together they will be substantial. "And
that's not even mentioning things like speed optimizations, which also have
real practical benefits."
"There are other things still on the docket as well — we're
not done yet!" added Montgomery, "However, we're finally to
the point of putting together a release solidly better than 1.0 in every
way, along with a much higher future ceiling."
Between now and then, the team is soliciting user input from real-world
encoding tests. "We put it out to show what we've been up to, and to
make it easier to give it a try," said Giles. "We're
interested in samples where it really does poorly, especially relative to
1.0, compatibility testing with current decoders, and general build and
integration issues which of course can only be found through people trying
your software in their own environments." He encouraged users to
submit concrete issues through the bug tracker, but to share other
experiences through the project mailing list, or simply to blog about
them for all to read.
Web video is poised to start changing dramatically once Firefox 3.5
ships with a built-in Theora decoder underlying the HTML5 video element.
That makes it all the more important to get the Theora encoder right.
Xiph.org does not have the full-time staff or resources of larger activist
groups like the Free Software Foundation or Creative Commons, it has only
software developers. Consequently, without the support of Red Hat,
Mozilla, and the Wikimedia Foundation, it might not have been able to get up
to speed. It remains to be seen whether the final build of Thusnelda will
beat Firefox 3.5 to release, but the progress made already is
encouraging.
Comments (13 posted)
March 27, 2009
This article was contributed by Don Marti
The
Open Source Business
Conference, held at San Francisco's Palace Hotel, draws a lot of
lawyers, from both corporate legal departments and law firms. Continuing
Legal Education (CLE) credit is available. Jeff Norman, a
partner
at the law firm of Kirkland & Ellis, delivered a talk on "Shims and
Shams: Firewalling Proprietary Code in a Copyleft Context."
This talk gives some insights into the current thinking on how difficult it
can be to create a combined software product using
both copyleft and proprietary code.
Most clients who want to combine GPL and proprietary
code, Norman said, do not have an open source business
model in mind. But the idea of creating a mixed
GPL/proprietary software product is difficult and
expensive. Step one for the lawyer is to explore
the reasons behind the idea. The question is:
"Why do you want to do something unusual instead of
complying with open source disclosure requirements?"
Only if the client says, "We can't open source this,"
does Norman recommend what he calls "shimming," which
he defines as "programing practices and architectures
that reduce the risk that independently created
proprietary code might be deemed a derivative work
based upon some other code that is intended to operate
with such proprietary code." Shimming includes both
procedural shims, which are development practices,
and substantive shims, which are design decisions.
The GPL's reciprocity requirements rely not on any
technical criterion, but on the legal definition
of a "derivative work." The definition is actually
consistent across countries. Norman surveyed the law
in US, Europe, and Asia, and found "little substantial
difference." While the definition is consistent, it's
also broad, often surprisingly broad. Case law shows
that derivative works can come into existence easily,
whenever pre-existing work is either incorporated into
new work or modified.
Two cases show the wide reach of the derivative work concept.
A.R.T Company sold products based on unmodified
postcards, and in one case was found to be creating
a derivative work. (Another case found that
A.R.T.'s product consisting of a postcard mounted
on a tile was not infringing, creating a conflict
between two U.S. circuit courts.) In another case, Midway
Manufacturing Co. v. Artic International, Inc.,
the court found that selling a hardware speed-up
kit for an existing arcade game was creating a
derivative work of the game software, even though
the defendant did not copy or modify the original
game software. Courts use the test of "access and
substantial similarity." If the alleged infringer
had access to the copyrighted work, and even parts of
the alleged derivative work are substantially similar,
then, according to the test, it's a derivative work.
Applying the idea to software, "proprietary code may
incorporate non-proprietary code in non-obvious ways,"
Norman said.
"There are built in to most computer languages
directives that cause code to be combined," he said.
The C preprocessor's #include directive is one example. "I've
seen hundreds
of thousands of lines of code incorporated with one
include." In one example, a proprietary program used
a widget class's API, and the widget class, using a
header file, incorporated code from a system library.
"This whole thing becomes a derivative work," he said.
Distribution or not?
If a combination of GPL and proprietary code is only
for in-house use, some clients decide simply
not to redistribute it. The GPL's
reciprocity requirements apply only in distribution.
However, distribution could happen in a lot of ways.
Does depositing source code in escrow count as
distribution? How about an acquisition that's
structured as a sale of assets from one company
to another? "Relying on no distribution is very
dangerous. There are a lot of situations where
distribution can happen but you wouldn't think of it
as distribution," Norman said.
The other approach is what Norman recommends.
"Don't create a derivative work and then you won't
have a problem." He said that some open source
advocates say, "You're violating the spirit or the
purpose of the GPL." But in the long run, allowing a
license to reach out too far could enable proprietary
vendors to apply unwanted terms to open source code.
"If the end user is not creating a derivative work,
not only are the license terms not being triggered
but you don't want them to be triggered,"
Fallacies
In the years that developers have been using and discussing
the GPL, some have developed a false sense of security
about when they're creating a derivative work.
Just using an API may or may not create a derivative
work. The purely functional aspects of a function
call are not copyrightable. However, Norman says,
even minor non-functional aspects of an API, such as
the sequence of fields in a structure, are probably
copyrightable. And just using an API can result
in bringing thousands of lines of code into your
application. Another fallacy is the often-heard, "We
can avoid any problems if we use dynamic rather than
static links," However, dynamic linking by itself does
not automatically avoid creating a derivative work.
Some US circuits ignore extremely small copying under
the so-called "de minimis" exception. However,
Norman said, "it would almost never cover code,"
There's no sure test for what is or isn't de minimis
copying, and one module or section of a program could
be found to be a derivative work. "Even if the whole
project is not substantially similar, one module may
be substantially similar," he added.
The clean room
With the broad standards of what is a derivative
work, combined with the ways that software can
mingle at build time, "derivative works practically
create themselves," Norman said. In order for
a combined product not to be a derivative work,
developers need to take specialized and expensive
measures. Avoiding creating a derivative work is not
something to do in the ordinary course of business.
Shimming requires the same clean-room techniques
that software companies use to protect themselves
when doing reverse engineering. Building a combined
product cleanly "really has to be worth it," Norman
said. "If you have someone who has never done a clean
room before you're going to spend time getting them
up to speed." Besides the development costs, there's
some publicity cost. "In any shimming scenario you
may get some negative PR," he said.
The wrong way to do shimming is simply to build a
wrapper, implementing essentially the same interface
as the GPL software, then communicate with the
wrapper. It doesn't work because the wrapper becomes
a derivative work, then the code that talks to the
wrapper does too. In practice, two development
teams need to work side by side, but not in direct
communication with each other. One team handles GPL
code, the other handles the proprietary code, and the
two communicate only through the legal department,
which acts as filter.
They have to be kept separate, Norman says, because,
"Programmers like to borrow just like lawyers.
How often do you borrow from somebody else's brief?"
The filtering has to block any knowledge about
creative expression from making its way across
the barrier. Since anyone could have seen the GPL
code, "We have a set of programmers who verify under
affidavit that they've never looked at this code
before." The clean room developers' access to the
Internet has to be monitored, or better yet, blocked.
"It's a fairly cumbersome technique, but most software
companies have done some kind of clean room before,"
Norman said.
NDISwrapper
is an example of another safe approach, Norman
said. A network device driver originally written
and compiled for Microsoft Windows cannot be a
derivative work of Linux. NDISwrapper itself is
GPL-licensed, and probably a derivative work of Linux (it's very
difficult to make a kernel module that isn't).
The API used in the Windows driver clearly has nothing
to do with the copyleft API.
Another approach is to split the GPL code into
a server process and put the proprietary code in
the client. However, this is unlikely to work if the
server and client are distributed together on the same
CD, relying on what the GPL calls "mere aggregation."
Any "intimate communication" between the server
and client could also create a derivative work,
Norman said. The last approach is to time-shift
the creation of a derivative work to the end user.
An example is the NVIDIA proprietary device drivers
for Linux, which the company distributes separately
from the kernel. This only works for technical
or hobbyist end users, not for an integrated
product. There's also a potential patent problem:
distributing two pieces that, when combined, infringe a
patent constitutes contributory infringement, Norman
said later.
A problem shimming scenario is using it to attempt
to undo a previous decision to combine software.
It could be "admitting that what you did was
problematic." If possible, try to buy a exception
from the copyright holder instead, Norman said.
Shimming is possible and might even be necessary,
as in the case of third-party code that can't be
relicensed. But the lesson is that companies will
save time, use fewer developers, make a simpler
product, and avoid legal bills just sticking with
the copyleft.
Comments (36 posted)
Page editor: Jonathan Corbet
Security
By Jake Edge
April 1, 2009
Being able to verify that the code running on a system is the "correct"
code is an important feature for some environments. The Linux integrity management architecture (IMA)
patches—recently
merged for 2.6.30—look at the integrity of processes as they are
started by the
kernel. But that requires running on a "good" kernel. So a patch, recently
put out for comments on linux-kernel, proposes a lower-level mechanism
which uses Intel's Trusted Execution
Technology (TXT) to verify the integrity of the kernel itself.
Whereas the IMA lives completely within the Linux kernel, but uses
Trusted Platform Module (TPM) hardware to check and enforce the integrity
of code that is executed, the TXT-based integrity system interposes a
virtual machine monitor (VMM or hypervisor) between the hardware and the
kernel. This hypervisor, called
Trusted Boot or tboot
interacts with the TXT hardware, which is contained in various recent Intel
chipsets, to verify the integrity of the kernel before launching it.
The TXT hardware can itself verify the integrity of many of the firmware
components (things like BIOS and option ROMs) that must be assumed when
using IMA. In their introductory post, Joseph Cihula and Shane Wang of
Intel describe the advantages
of a TXT-based integrity system as follows:
To get trust in the initial kernel without using Intel TXT, a static root
of trust must be used. This bases trust in BIOS starting at system reset
and requires measurement of all code executed between system reset through
the completion of the kernel boot as well as data objects used by that
code. In the case of a Linux kernel, this means all of BIOS, any option
ROMs, the bootloader and the boot config. In practice, this is a lot of
code/data, much of which is subject to change from boot to boot
(e.g. changing NICs may change option ROMs). Without reference hashes,
these measurement changes are difficult to assess or confirm as benign.
This process also does not provide DMA protection, memory
configuration/alias checks and locks, crash protection, or policy
support.
By using the hardware-based root of trust that Intel TXT provides, many of
these issues can be mitigated. Specifically: many pre-launch components
can be removed from the trust chain, DMA protection is provided to all
launched components, a large number of platform configuration checks are
performed and values locked, protection is provided for any data in the
event of an improper shutdown, and there is support for policy-based
execution/verification. This provides a more stable measurement and a
higher assurance of system configuration and initial state than would be
otherwise possible. Since the tboot project is open source, source code
for almost all parts of the trust chain is available (excepting SMM and
Intel-provided firmware).
It is interesting that they mention system management mode (SMM) as that
has recently been the target
of some research on undetectable rootkits. The kind of malware
described in the research could subvert even TXT-based integrity systems.
In a followup post, Cihula and Wang
describe in some detail how TXT, tboot, and the kernel cooperate to make it
all work. Tboot is loaded by the bootloader—typically grub—as the
"kernel". The grub.conf file lists the Linux kernel and Intel-supplied
binary-only "authenticated code module" as "modules" that get loaded as
well. For those who wish it, tboot also supports launching the Xen hypervisor,
instead of the Linux kernel,
as the guest. Tboot
then does all of the setup necessary to determine if the TXT environment is
present and configured correctly, if not, it just launches the kernel as
usual. But if it finds a proper TXT environment, it initiates the
integrity checking and verifies the hardware environment.
At that point, user-defined policies are consulted to determine the
how to verify the integrity of the kernel and initial ramdisk (initrd) and
what to do if verification fails. Tboot creates a
shared page of memory and populates it with some data about itself for the
kernel to use. The physical address of the shared page is passed to the
kernel as a boot parameter. The kernel then maps that page as part of the
boot process.
The shared page is also used by the kernel to communicate its intent to
move to one of the sleep states of the processor. Instead of directly
sleeping, it informs tboot of all of the relevant ACPI data via the shared
page and jumps into tboot via a vector listed in the page. When going
into the standby (suspend to RAM or S3) sleep, additional steps are taken
to ensure the memory integrity across the S3 boundary. This is done by
calculating a hash value over critical memory regions (kernel code and data
as well as the S3 resume code) and signing it using the TPM. The
user-supplied tboot policies determine what actions to take if the RAM
verification fails upon coming out of S3.
The patch itself is relatively small and
comments on it nearly non-existent. While it provides a potentially
interesting protection against various attack scenarios, it also adds a
layer underneath the kernel. In addition, there are some binary components
to tboot that may raise some eyebrows. It will be interesting to see what
kind of reception it gets, once folks start looking at it.
Comments (1 posted)
Brief items
The Fedora project has sent out an update on last August's intrusion; there
is quite a bit more information here now. "
The compromise was not the result of a software vulnerability, and as
we have previously stated, our investigation has revealed no such
vulnerabilities. Instead, the intruder took a copy of a SSH private
key which was not secured with a passphrase from a system outside the
Fedora infrastructure. The intruder then used that key, which
belonged to a Fedora administrator, to access Fedora systems."
Full Story (comments: 27)
The New York Times broke the
story of "GhostNet", a globe-spanning infiltration of computers, most of which are controlled by various governments. In investigating malware at the offices of the Dalai Lama, security researchers found a much larger operation. "
Their sleuthing opened a window into a broader operation that, in less than two years, has infiltrated at least 1,295 computers in 103 countries, including many belonging to embassies, foreign ministries and other government offices, as well as the Dalai Lamas Tibetan exile centers in India, Brussels, London and New York.
[...]
The researchers, who have a record of detecting computer espionage, said they believed that in addition to the spying on the Dalai Lama, the system, which they called GhostNet, was focused on the governments of South Asian and Southeast Asian countries."
Comments (7 posted)
New vulnerabilities
acroread: multiple vulnerabilities
| Package(s): | acroread |
CVE #(s): | CVE-2009-0193
CVE-2009-0658
CVE-2009-0927
CVE-2009-0928
CVE-2009-1061
CVE-2009-1062
|
| Created: | March 27, 2009 |
Updated: | April 21, 2009 |
| Description: |
From the SUSE advisory: Multiple flaws in the JBIG2 decoder and the JavaScript engine of the Adobe Reader allowed attackers to crash acroread or even execute arbitrary code by tricking users into opening specially crafted PDF files.
|
| Alerts: |
|
Comments (none posted)
auth2db: SQL injection
| Package(s): | auth2db |
CVE #(s): | |
| Created: | March 30, 2009 |
Updated: | April 1, 2009 |
| Description: |
From the Debian advisory:
It was discovered that auth2db, an IDS logger, log viewer and alert
generator, is prone to an SQL injection vulnerability, when used with
multibyte character encodings.
|
| Alerts: |
|
Comments (none posted)
firefox: remote code execution
Comments (none posted)
java-1.6.0-sun: multiple vulnerabilities
| Package(s): | java-1.6.0-sun |
CVE #(s): | CVE-2006-2426
CVE-2009-1093
CVE-2009-1094
CVE-2009-1095
CVE-2009-1096
CVE-2009-1097
CVE-2009-1098
CVE-2009-1099
CVE-2009-1100
CVE-2009-1101
CVE-2009-1102
CVE-2009-1103
CVE-2009-1104
CVE-2009-1105
CVE-2009-1106
CVE-2009-1107
|
| Created: | March 26, 2009 |
Updated: | November 18, 2009 |
| Description: |
Java 1.6.0 has a long list of vulnerabilities.
From the Red Hat alert:
CVE-2006-2426 Untrusted applet causes DoS by filling up disk space
CVE-2009-1101 OpenJDK JAX-WS service endpoint remote Denial-of-Service
CVE-2009-1093 OpenJDK remote LDAP Denial-Of-Service
CVE-2009-1094 OpenJDK LDAP client remote code execution
CVE-2009-1095 CVE-2009-1096 OpenJDK Pack200 Buffer overflow vulnerability
CVE-2009-1102 OpenJDK code generation vulnerability
CVE-2009-1097 OpenJDK PNG processing buffer overflow vulnerability
CVE-2009-1098 OpenJDK GIF processing buffer overflow vulnerability
CVE-2009-1099 OpenJDK: Type1 font processing buffer overflow vulnerability
CVE-2009-1100 OpenJDK: DoS (disk consumption) via handling of temporary font files
CVE-2009-1103 OpenJDK: Files disclosure, arbitrary code execution via "deserializing applets"
CVE-2009-1104 OpenJDK: Intended access restrictions bypass via LiveConnect
CVE-2009-1105 OpenJDK: Possibility of trusted applet run in older, vulnerable version of JRE
CVE-2009-1106 OpenJDK: Improper parsing of crossdomain.xml files (intended access restriction bypass)
CVE-2009-1107 OpenJDK: Signed applet remote misuse possibility |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2009-0778
|
| Created: | April 1, 2009 |
Updated: | February 3, 2010 |
| Description: |
From the Red Hat advisory:
Memory leaks were found on some error paths in the icmp_send()
function in the Linux kernel. This could, potentially, cause the network
connectivity to cease. (CVE-2009-0778, Important)
|
| Alerts: |
|
Comments (none posted)
krb5: denial of service
| Package(s): | krb5 |
CVE #(s): | CVE-2009-0844
CVE-2009-0845
CVE-2009-0846
CVE-2009-0847
|
| Created: | March 30, 2009 |
Updated: | January 14, 2010 |
| Description: |
From the Mandriva advisory:
The spnego_gss_accept_sec_context function in
lib/gssapi/spnego/spnego_mech.c in MIT Kerberos 5 (aka krb5) 1.6.3,
when SPNEGO is used, allows remote attackers to cause a denial of
service (NULL pointer dereference and application crash) via invalid
ContextFlags data in the reqFlags field in a negTokenInit token
(CVE-2009-0845).
From the Red Hat advisory:
An input validation flaw was found in the ASN.1 (Abstract Syntax Notation
One) decoder used by MIT Kerberos. A remote attacker could use this flaw to
crash a network service using the MIT Kerberos library, such as kadmind or
krb5kdc, by causing it to dereference or free an uninitialized pointer.
(CVE-2009-0846)
Multiple input validation flaws were found in the MIT Kerberos GSS-API
library's implementation of the SPNEGO mechanism. A remote attacker could
use these flaws to crash any network service utilizing the MIT Kerberos
GSS-API library to authenticate users or, possibly, leak portions of the
service's memory. (CVE-2009-0844, CVE-2009-0845)
|
| Alerts: |
|
Comments (none posted)
nss-ldapd: insecure config file creation
| Package(s): | nss-ldapd |
CVE #(s): | CVE-2009-1073
|
| Created: | March 31, 2009 |
Updated: | April 1, 2009 |
| Description: |
From the Debian advisory: Leigh James that discovered that nss-ldapd, an NSS module for using LDAP as a naming service, by default creates the configuration file /etc/nss-ldapd.conf world-readable which could leak the configured LDAP password if one is used for connecting to the LDAP server.
|
| Alerts: |
|
Comments (none posted)
openssl: denial of service
| Package(s): | openssl |
CVE #(s): | CVE-2009-0590
|
| Created: | March 31, 2009 |
Updated: | July 27, 2011 |
| Description: |
From the Ubuntu advisory: It was discovered that OpenSSL did not properly validate the length of an encoded BMPString or UniversalString when printing ASN.1 strings. If a user or automated system were tricked into processing a crafted certificate, an attacker could cause a denial of service via application crash in applications linked against OpenSSL.
|
| Alerts: |
|
Comments (none posted)
openswan: denial of service
| Package(s): | openswan |
CVE #(s): | CVE-2009-0790
|
| Created: | March 30, 2009 |
Updated: | September 9, 2009 |
| Description: |
From the Red Hat advisory:
Gerd v. Egidy discovered a flaw in the Dead Peer Detection (DPD) in
Openswan's pluto IKE daemon. A remote attacker could use a malicious DPD
packet to crash the pluto daemon. (CVE-2009-0790)
|
| Alerts: |
|
Comments (none posted)
systemtap: race condition
| Package(s): | systemtap |
CVE #(s): | CVE-2009-0784
|
| Created: | March 26, 2009 |
Updated: | April 2, 2009 |
| Description: |
systemtap has a race condition vulnerability.
From the Debian alert:
Erik Sjoelund discovered that a race condition in the stap tool shipped
by Systemtap, an instrumentation system for Linux 2.6, allows local
privilege escalation for members of the stapusr group. |
| Alerts: |
|
Comments (1 posted)
Page editor: Jake Edge
Kernel development
Brief items
The current stable 2.6 kernel remains 2.6.29. The 2.6.30 merge
window is open (see below), and no stable updates have been released over
the last week.
The 2.6.29.1 stable update is in the review
process as of this writing. This update, containing just over 40
fixes, can be expected around April 2 or 3.
Comments (none posted)
Kernel development news
Really someone needs to sit down and actually build a proper model
of the VM behaviour in a tool like netlogo rather than continually
keep adding ever more complex and thus unpredictable hacks to
it. That way we might better understand what is occurring and why.
--
Alan Cox
It is very disappointing that nobody appears to have attempted to
do _any_ sensible tuning of these controls in all this time - we
just keep thrashing around trying to pick better magic numbers in
the base kernel.
Maybe we should set the tunables to 99.9% to make it suck enough to
motivate someone.
--
Andrew Morton
We kernel people really are special. Expecting normal apps to spend
the kind of effort we do (in scalability, in error handling, in
security) is just not realistic.
--
Linus Torvalds
Comments (2 posted)
By Jonathan Corbet
April 1, 2009
As of this writing, almost 6200 non-merge changesets have been added to the
mainline for the 2.6.30 release. So the merge window is well and truly
open. There's a lot of stuff set up for 2.6.30 already, with more
certainly to come. The user-visible changes merged so far include:
- The relatime mount
option is now the default; this means that file access times will only
be updated if they are newer than the creation or modification times.
Another change merged also causes the access time to be updated at
least once per day. Users needing access times to be updated for
every access can use the new "strictatime" mount option to get that
behavior. See That massive
filesystem thread for more information on this change.
- At long last, the integrity
management patches have been merged. Among other things, this
code can use the trusted platform module (TPM) to ensure that the
files on a system have not been tampered with and to do remote
attestation.
- Also at long last, TOMOYO
Linux has been merged. TOMOYO is a pathname-based security module
similar to (but significantly different from) AppArmor.
- There is a new cpuinfo_transition_latency sysfs variable for
CPU frequency governors; it serves to inform user space of the time it
takes for the CPU to transition from one frequency to another.
- There is now support for the new AES-NI cryptographic instructions
being introduced into Intel processors; see this
white paper [PDF] for details on AES-NI.
- The x86_64 and SuperH architectures have gained kexec jump support.
- There is a new guest debugging interface for KVM, allowing the host to
do interactive debugging of guest systems. KVM has also gained
support for PowerPC e500 processors.
- There is a new user-space API for detailed control over the
timestamping of network packets. See Documentation/networking/timestamping.txt
for details.
- The Reliable Datagram Sockets (RDS) protocol is now supported by the
networking layer. See Documentation/networking/rds.txt for more
information.
- The x86 architecture now has an option to put a "canary" value at the
end of the kernel stack; if that value ever changes, the stack has
been (accidentally or maliciously) overrun.
- The reiserfs filesystem has seen a burst of work which cleans up the
code, improves SELinux support, and improves performance. This is
likely to be the last set of updates for reiserfs.
- The usual array of new drivers has been merged. They include:
- Block: PCI-Express SAS 6Gb/s host adapters.
- Graphics: AMD R6xx/R7xx GPUs (2D only for now).
- Networking: USB Qualcomm Serial modems,
Marvell Libertas 8686 SPI 802.11b/g cards,
Marvell 88w8xxx TOPDOG PCI/PCIe wireless cards,
Prism54 SPI (stlc45xx) wireless adapters,
Atmel at76c503/at76c505/at76c505a USB wireless adapters,
OpenCores 10/100 Mbps Ethernet MAC devices, and
Atheros "otus" 802.11n USB devices.
- Sound: Mitac MIO A701 phones,
Wolfson Micro WM8400 and WM9705 codecs,
Wolfson Microelectronics 1133-EV1 modules,
Atmel Audio Bitstream DAC devices,
Atmel AC97 controllers,
Asaki-Kasei AK4104 S/PDIF transmitters,
Echo Audio IndigoIOx and IndigoDJx cards,
Turtle Beach Classic, Fiji and Pinnacle cards, and
Asus Xonar Essence STX sound cards.
- Video/DVB: Mars-Semi MR97310A USB cameras,
Freescale MC44S803 low power CMOS broadband tuners,
SQ Technologies SQ905-based USB cameras,
i.MX3x camera sensor interfaces,
ST STV0900 satellite demodulators,
ST STV6110 silicon tuners,
SQ Technologies SQ905C-based USB cameras
Zarlink ZL10036 silicon tuners,
LG Electronics LGDT3305-based tuners,
Hauppauge HD PVR USB devices, and
Intel CE6230 DVB-T USB2.0 receivers.
- Processors and systems: SuperH SH7786,
ESPT-Giga SH7763-based reference boards,
SMSC reference platform with a SH7709S CPUs,
Palm LifeDrive and Tungsten|T5 systems,
Brivo Systems LLC ACS-5000 master boards,
Dave/DENX QongEVB-LITE platforms,
Marvell RD-78x00-mASA development boards,
Marvell PXA168 and PXA910 processors,
TI OMAP850 processors,
OMAP 3430 SDP boards,
Nokia RX-51 internet tablets,
Teltonika 3G Router RUT100 systems,
Faraday FA526 cores,
Cortina Systems Gemini family SoCs,
GE Fanuc SBC310 and PPC9A PowerPC boards,
Freescale Media5200 boards,
AMCC Redwood(460SX) systems,
Phytec phyCORE-MPC5200B-IO (pcm032) boards, and
Freescale MPC8544 ("Socrates") boards.
- Miscellaneous: AMCC PPC4xx crypto accelerators,
Adrienne Electronics Corporation PCI time code devices,
Symbol 6608 barcode scanners,
E-Ink Broadsheet/Epson S1D13521 controllers,
NXP Semiconductor PCA9665 i2c controllers, and
Siemens Syleus and Hades sensor chips.
- The "Phidgets" USB drivers have been removed; users should shift
to the user-space
drivers instead.
Changes visible to kernel developers include:
- The adaptive spinning mutex patch has been merged. This change will
cause mutexes to behave more like spinlocks in the contended case. If
(and only if) the lock is held by code running on a different CPU, the
mutex code will
spin on the assumption that the lock will be released soon. This behavior
results in significant performance improvements. Btrfs, which had its own spinning mutex
implementation, has been converted to the new mutexes.
- There is a new set of functions added to the crypto API which allow
for piecewise compression and decompression of data.
- The bus_id member of struct device is gone; code
needing that information should use the dev_name() macro
instead.
- There is a new timer function:
int mod_timer_pending(struct timer_list *timer, unsigned long expires);
It is like mod_timer() with the exception that it will not
reactivate an already-expired timer.
- There have been some changes around the fasync() function in
struct file_operations. This function is now responsible for
maintaining the FASYNC bit in struct file; it is
also now called without the big kernel lock held. Finally, a positive
return value from fasync() is mapped to zero, meaning that
the return value from fasync_helper() can be returned
directly by fasync(). (This is your editor's modest
contribution to 2.6.30).
- The SCSI layer has a new support library for object storage device
support; see Documentation/scsi/osd.txt for details.
- The x86 "subarchitecture" mechanism has been removed, now that no
architectures actually use it. The Voyager architecture has been
removed as a result of these changes.
- x86 is also the first architecture to use a new per-CPU memory
allocator merged for 2.6.30. This allocator changes little at the API
level, but it will provide for more efficient and flexible per-CPU
variable management.
- Support for compressing the kernel with the bzip2 or lzma algorithms
has been added. Support for the old zImage format has been
removed.
- The asynchronous function
call infrastructure is now enabled by default.
- The DMA operations debugging
facility has been merged.
- The owner field of struct proc_dir_entry has been
removed, causing lots of changes throughout the tree.
If the usual two-week pattern holds, the merge window can be expected to
remain open through about April 9. The rate at which changes flow
into the mainline will likely be lower for the second half of the merge
window - the alternative is for this development cycle to be far larger
than any of its predecessors. But it is certain that more interesting
changes will be merged for 2.6.30.
Comments (21 posted)
April 1, 2009
This article was contributed by Goldwyn Rodrigues
The kernel page cache contains in-memory copies of data blocks
belonging to files kept in persistent storage.
Pages which are written to by a processor, but not yet written to disk, are
accumulated in cache and are known as "dirty" pages. The amount of
dirty memory is listed in
/proc/meminfo. Pages in
the cache are flushed to disk after an interval of 30 seconds. Pdflush
is a set of kernel threads which are responsible for writing the
dirty pages to disk, either explicitly in response to a
sync() call, or
implicitly in cases when the page cache runs out of pages, if the
pages have been in memory for too long, or there are too many dirty pages
in the page cache (as specified by
/proc/sys/vm/dirty_ratio).
At a given point of time, there are between two and eight pdflush threads running in the
system. The number of pdflush threads is determined by the load on the
page cache; new pdflush threads are spawned if
none of the existing pdflush threads have been idle for more than
one second, and there is more work in the pdflush work queue.
On the other hand, if the last active pdflush thread has been asleep
for more than one second, one thread is terminated. Termination of
threads happens until only a minimum number of pdflush
threads remain. The current number of running pdflush threads is
reflected by /proc/sys/vm/nr_pdflush_threads.
A number of pdflush-related issues have come to light over time.
Pdflush threads are common to all block devices, but it is thought that
they would perform better if they concentrated on a single disk spindle.
Contention between pdflush threads is avoided through the use of the
BDI_pdflush flag on the backing_dev_info structure, but
this interlock can also limit writeback performance.
Another issue with pdflush is
request starvation. There is a fixed number of I/O requests available for each
queue in the system. If the limit is exceeded, any application
requesting I/O will block waiting for a new slot. Since pdflush works on several
queues, it cannot block on a single queue. So, it sets the
wbc->nonblocking writeback information flag. If other applications continue to write on the
device, pdflush will not succeed in allocating request slots.
This may lead to starvation of
access to the queue, if pdflush repeatedly finds the queue congested.
Jens Axboe in his patch set proposes a new
idea of using flusher threads per backing device info (BDI), as a
replacement for
pdflush threads. Unlike pdflush threads, per-BDI flusher threads focus
on a single disk spindle. With per-BDI flushing, when the
request_queue is congested, blocking happens on request allocation,
avoiding request starvation and providing better fairness.
With pdflush, The dirty inode list is stored by
the super block of the filesystem. Since the per-BDI flusher needs to
be aware of the dirty pages to be written by its assigned device, this list is now stored by the BDI.
Calls to flush dirty inodes on the superblock result in flushing the
inodes from the list of dirty inodes on the backing device for all
devices listed for the filesystem.
As with pdflush, per-BDI writeback is controlled through the
writeback_control data structure, which instructs the writeback code
what to do, and how to perform the writeback. The important fields of this
structure are:
- sync_mode: defines the way synchronization should be performed
with respect to inode locking. If set to WB_SYNC_NONE, the writeback
will skip locked inodes, where as if set to WB_SYNC_ALL will wait for
locked inodes to be unlocked to perform the writeback.
- nr_to_write: the number of pages to write. This value is
decremented as the pages are written.
- older_than_this: If not NULL, all inodes older than the
jiffies recorded in this field are flushed. This field takes precedence over
nr_to_write.
The struct bdi_writeback keeps all information required for flushing
the dirty pages:
struct bdi_writeback {
struct backing_dev_info *bdi;
unsigned int nr;
struct task_struct *task;
wait_queue_head_t wait;
struct list_head b_dirty;
struct list_head b_io;
struct list_head b_more_io;
unsigned long nr_pages;
struct super_block *sb;
};
The bdi_writeback structure is initialized when the device is registered through
bdi_register(). The fields of the bdi_writeback are:
- bdi: the backing_device_info associated with this
bdi_writeback,
- task: contains the pointer to the default flusher thread
which is responsible for spawning threads for performing the
flushing work,
- wait: a wait queue for synchronizing with the flusher threads,
- b_dirty: list of all the dirty inodes on this BDI to be flushed,
- b_io: inodes parked for I/O,
- b_more_io: more inodes parked for I/O; all inodes queued for
flushing are inserted in this list, before being moved to
b_io,
- nr_pages: total number of pages to be flushed, and
- sb: the pointer to the superblock of the filesystem which
resides on this BDI.
nr_pages and sb are parameters passed asynchronously to
the the BDI flush thread, and are not fixed through the life of the
bdi_writeback. This is done to facilitate devices with multiple
filesystem, hence multiple super_blocks. With multiple super_blocks
on a single device, a sync can be requested for a single filesystem
on the device.
The bdi_writeback_task() function waits for the
dirty_writeback_interval,
which by default is 5 seconds, and initiates wb_do_writeback(wb)
periodically. If there are no pages written for five minutes, the flusher
thread exits (with a grace period of dirty_writeback_interval).
If a writeback work is later required (after exit), new flusher
threads are spawned by the default writeback thread.
Writeback flushes are done in two ways:
- pdflush style: This is initiated in response to an explicit writeback
request, for example syncing inode pages of a super_block.
wb_start_writeback() is called with the superblock information
and the number of pages to be flushed. The function tries to acquire
the bdi_writeback structure associated with the BDI. If successful, it
stores the superblock pointer and the number of pages to be flushed in the
bdi_writeback structure and wakes up the flusher thread to perform the
actual writeout for the superblock. This is different from how pdflush
performs writeouts: pdflush attempts to grab the device from the
writeout path, blocking the writeouts from other processes.
- kupdated style: If there is no explicit writeback requests, the thread
wakes up periodically to flush dirty data. The
first time one of the inode's pages stored in the BDI is dirtied, the
dirtying-time is recorded in the inode's address space. The periodic
writeback code walks through the superblock's inode list, writing
back dirty pages of the inodes older than a specified point in time.
This is run once per dirty_writeback_interval, which defaults
to five seconds.
After review of the first
attempt, Jens added
functionality of having multiple flusher threads per device based on
the suggestions of Andrew Morton. Dave Chinner suggested that
filesystems would like to have a flusher thread per allocation group.
In the patch set (second iteration) which followed, Jens added a
new interface in the superblock to return the bdi_writeback structure
associated with the inode:
struct bdi_writeback *(*inode_get_wb) (struct inode *);
If inode_get_wb is NULL, the default bdi_writeback of the BDI is
returned, which means there is only one bdi_writeback thread for the BDI. The
maximum number of threads that can be started per BDI is 32.
Initial experiments conducted by Jens found an 8% increase in
performance on a simple SATA drive running Flexible File System
Benchmark (ffsb). File layout was smoother as compared to the
vanilla kernel as reported by vmstat, with a uniform distribution of
buffers written out. With a ten-disk btrfs filesystem, per-BDI flushing performed
25% faster. The writeback is tracked by Jens's block layer git tree
(git://git.kernel.dk/linux-2.6-block.git) under the "writeback" branch.
There have been no comments on the second iteration so far, but
per-BDI flusher threads is still not ready enough to go into the
2.6.30 tree.
Acknowledgments: Thanks to Jens Axboe for reviewing and explaining
certain aspects of the patch set.
Comments (14 posted)
By Jonathan Corbet
March 31, 2009
Long, highly-technical, and animated discussion threads are certainly not
unheard of on the linux-kernel mailing list. Even by linux-kernel
standards, though,
the
thread that followed the 2.6.29 announcement was impressive. Over the
course of hundreds of messages, kernel developers argued about several
aspects of how filesystems and block I/O work on contemporary Linux
systems. In the end (your editor will be optimistic and say that it has
mostly ended), we had a lot of heat - and some useful, concrete results.
One can only pity Jesper Krogh, who almost certainly didn't know what he
was getting into when he posted a report of
a process which had been hung up waiting for disk I/O for several minutes.
All he was hoping for was a suggestion on how to avoid these kinds of
delays - which are a manifestation of the famous ext3 fsync()
problem - on his server. What he got, instead, was to be copied on the
entire discussion.
Journaling priority
One of the problems is at least somewhat understood: a call to
fsync() on an ext3 filesystem will force the filesystem journal
(and related file data) to
be committed to disk. That operation can create a lot of write activity
which must be waited for. But contemporary I/O schedulers tend to
favor read operations over writes. Most of the time, that is a rational
choice: there is usually a process waiting for a read to complete, but
writes can be done asynchronously. A journal commit is not asynchronous,
though, and it can cause a lot of things to wait while it is in progress.
So it would be better not to put journal I/O operations at the end of the
queue.
In fact, it would be better not to make journal operations contend with the
rest of the system at all. To that end, Arjan van de Ven has long
maintained a simple patch
which gives the kjournald thread realtime I/O priority. According to Alan Cox, this patch alone is
sufficient to make a lot of the problems go away. The patch has never made
it into the mainline, though, because Andrew
Morton has blocked it. This patch, he says, does not address the real
problem, and it causes a lot of unrelated I/O traffic to benefit from
elevated priority as well. Andrew says the real fix is harder:
The bottom line is that someone needs to do some serious rooting
through the very heart of JBD transaction logic and nobody has yet
put their hand up. If we do that, and it turns out to be just too
hard to fix then yes, perhaps that's the time to start looking at
palliative bandaids.
Bandaid or not, this approach has its adherents. The ext4 filesystem has a
new mount option (journal_ioprio) which can be used to set the I/O
priority for journaling operations; it defaults to something higher than
normal (but not realtime). More recently, Ted Ts'o has posted a series of ext3 patches which
sets the WRITE_SYNC flag on some journal writes. That flag marks
the operations as synchronous, which will keep them from being blocked by a
long series of read operations. According to Ted, this change helps quite
a bit, at least when there is a lot of read activity going on. The ext3
changes have not yet been merged for 2.6.30 as of this writing (none of
Ted's trees have), but chances are they will go in before 2.6.30-rc1.
data=ordered, fsync(), and fbarrier()
The real problem, though, according to Ted, is the ext3
data=ordered mode. That is the mode which makes ext3 relatively
robust in the face of crashes, but, says Ted, it has done so at the cost of
performance and the encouragement of poor user-space programming. He went
so far as to express his regrets for
this behavior:
All I can do is apologize to all other filesystem developers
profusely for ext3's data=ordered semantics; at this point, I very
much regret that we made data=ordered the default for ext3. But
the application writers vastly outnumber us, and realistically
we're not going to be able to easily roll back eight years of
application writers being trained that fsync() is not necessary,
and actually is detrimental for ext3.
The only problem here is that not everybody believes that ext3's behavior
is a bad thing - at least, with regard to robustness. Much of this branch
of the discussion covered the same issues raised by LWN in Better than POSIX? a couple of
weeks before. A significant subset of developers do not want the
additional robustness provided by ext3 data=ordered mode to go
away. Matthew Garrett expressed this position
well:
But you're still arguing that applications should start using
fsync(). I'm arguing that not only is this pointless (most of this
code will never be "fixed") but it's also regressive. In most cases
applications don't want the guarantees that fsync() makes, and
given that we're going to have people running on ext3 for years to
come they also don't want the performance hit that fsync()
brings. Filesystems should just do the right thing, rather than
losing people's data and then claiming that it's fine because POSIX
said they could.
One option which came up a couple of times was to extend POSIX with a new
system call (called something like fbarrier()) which would enforce
ordering between filesystem operations. A call to fbarrier()
could, for example, cause the data written to a new file to be forced out
to disk before that file could be renamed on top of another file. The idea
has some appeal, but Linus dislikes it:
Anybody who wants more complex and subtle filesystem interfaces is
just crazy. Not only will they never get used, they'll definitely
not be stable...
So rather than come up with new barriers that nobody will use,
filesystem people should aim to make "badly written" code "just
work" unless people are really really unlucky. Because like it or
not, that's what 99% of all code is.
And that is almost certainly how things will have to work. In the end, a
system which just works is the system that people will want to use.
relatime
Meanwhile, another branch of the conversation revisited an old topic: atime
updates. Unix-style filesystems traditionally track the time that each
file was last accessed ("atime"), even though, in reality, there is very
little use for this information. Tracking atime is a performance problem,
in that it turns every read operation into a filesystem write as well. For
this reason, Linux has long had a "noatime" mount option which would
disable atime updates on the indicated filesystem.
As it happens, though, there can be problems with disabling atime
entirely. One of them is that the mutt mail client uses atime to
determine whether there is new mail in a mailbox. If the time of last
access is prior to the time of last modification, mutt knows that
mail has been delivered into that mailbox since the owner last looked at
it. Disabling atime breaks this mechanism. In response to this problem,
the kernel added a "relatime" option which causes atime to be updated only
if the previous value is earlier than the modification time. The relatime
option makes mutt work, but it, too, turns out to be insufficient:
some distributions have temporary-directory cleaning programs which delete
anything which hasn't been used for a sufficiently long period. With
relatime, files can appear to be totally unused, even if they are read
frequently.
If relatime could be made to work, the benefits could be significant; the
elimination of atime updates can get rid of a lot of writes to the disk.
That, in turn, will reduce latencies for more useful traffic and will also
help to avoid disk spin-ups on laptops. To that end, Matthew Garrett
posted a patch to modify the relatime semantics slightly: it allows atime
to be updated if the previous value is more than one day in the past. This
approach eliminates almost all atime updates while still keeping the value
close to current.
This patch was proposed for merging, and more: it was suggested that
relatime should be made the default mode for filesystems mounted under
Linux. Anybody wanting the traditional atime behavior would have to mount
their filesystems with the new "strictatime" mount option. This idea ran
into some immediate opposition, for a couple of reasons. Andrew Morton didn't like the hardwired 24-hour value,
saying, instead, that the update period should be given as a mount option.
This option would be easy enough to implement, but few people think there
is any reason to do so; it's hard to imagine a use case which requires any
degree of control over the granularity of atime updates.
Alan Cox, instead, objected to the patch as
an ABI change and a standards violation. He tried to "NAK" the patch,
saying that, instead, this sort of change should be done by distributors.
Linus, however, said he doesn't care; the
relatime change and strictatime option were the very first things he merged
when he opened the 2.6.30 merge window. His position is that the
distributors have had more than a year to make this change, and they
haven't done so. So the best thing to do, he says, is to change the
default in the kernel and let people use strictatime if they really need
that behavior.
For the curious, Valerie Aurora has written a detailed
article about this change. She doesn't think that the patch will
survive in its current form; your editor, though, does not see a whole lot
of pressure for change at this point.
I/O barriers
Suppose you are a diligent application developer who codes proper
fsync() calls where they are necessary. You might think that you
are then protected against data loss in the face of a crash. But there is
still a potential problem: the disk drive may lie to the operating system
about having written the data to persistent media. Contemporary hardware
performs aggressive caching of operations to improve performance; this
caching will make a system run faster, but at the cost of adding another
way for data to get lost.
There is, of course, a way to tell a drive to actually write data to
persistent media. The block layer has long had support for barrier
operations, which cause data to be flushed to disk before more operations
can be initiated. But the ext3 filesystem does not use barriers by default
because there is an associated performance penalty. With ext4, instead,
barriers are on by default.
Jeff Garzik pointed out one associated
problem: a call to fsync() does not necessarily cause the drive to
flush data to the physical media. He suggested that fsync()
should create a barrier, even if the filesystem as a whole is not using
barriers. In that way, he says, fsync() might actually live up to
the promise that it is making to application developers.
The idea was not controversial, even though people are, as a whole, less
concerned with caches inside disk drives. Those caches tend to be
short-lived, and they are quite likely to be written even if the operating
system crashes or some other component of the system fails. So the chances
of data loss at that level are much smaller than they are with data in an
operating system cache. Still, it's possible to provide a higher-level
guarantee, so Fernando Luis Vazquez Cao posted a series of patches to add barriers to
fsync() calls. And that is when the trouble started.
The fundamental disagreement here is over what should happen when an
attempt to send a flush operation to the device fails. Fernando's patch
returned an ENOTSUPP error to the caller, but Linus asked for it to be removed. His position is
that there is nothing that the caller can do about a failed barrier
operation anyway, so there is no real reason to propagate that error
upward. At most, the system should set a flag noting that the device
doesn't support barriers. But, says Linus, filesystems should cope with
what the storage device provides.
Ric Wheeler, instead, argues that
filesystems should know if barrier operations are not working and be able
to respond accordingly. Says Ric:
One thing the caller could do is to disable the write cache on the
device. A second would be to stop using the transactions - skip the
journal, just go back to ext2 mode or BSD like soft updates.
Basically, it lets the file system know that its data integrity
building blocks are not really there and allows it (if it cares) to
try and minimize the chance of data loss.
Alan Cox also jumped into this discussion
in favor of stronger barriers:
Throw and pray the block layer can fake it simply isn't a valid
model for serious enterprise computing, and if people understood
the worst cases, for a lot of non enterprise computing.
Linus appears to be unswayed by these arguments, though. In his view,
filesystems should do the best they can and accept what the underlying
device is able to do. As of this writing, no patches adding barriers to
fsync() have been merged into the mainline.
Related to this is the concept of laptop mode. It has been suggested that, when a system is in laptop
mode, an fsync() call should not actually flush data to disk;
flushing the data would cause the drive to spin up, defeating the intent of
laptop mode. The response to I/O barrier requests would presumably be
similar. Some developers oppose this idea, though, seeing it as a
weakening of the promises provided by the API. This looks like a topic
which could go a long time without any real resolution.
Performance tuning
Finally, there was some talk about trying to make the virtual memory
subsystem perform better in general. Part of the problem here has been
recognized for some time: memory sizes have grown faster than disk speeds.
So it takes a lot longer to write out a full load of dirty pages than it
did in the past. That simple dynamic is part of the reason why writeout
operations can stall for long periods; it just takes that long to funnel
gigabytes of data onto a disk drive. It is generally expected that
solid-state drives will eventually make this problem go away, but it is
also expected that it will be quite some time, yet, before those drives are
universal.
In the mean time, one can try to improve performance by not allowing the
system to accumulate as much data in need of writing. So, rather than
letting dirty pages stay in cache for (say) 30 seconds, those pages
should be flushed more frequently. Or the system could adjust the
percentage of RAM which is allowed to be dirty, perhaps in response to
observations about the actual bandwidth of the backing store devices.
The kernel already has a "percentage dirty" limit, but some developers are
now suggesting that the limit should be a fixed number of bytes instead.
In particular, that limit should be set to the number of bytes which can be
flushed to the backing store device in (say) one second.
Nobody objects to the idea of a better-tuned virtual memory subsystem. But
there is some real disagreement over how that tuning should be done. Some
developers argue for exposing the tuning knobs to user space and letting
the distributors work it out. Andrew is a
strong proponent of this approach:
I've seen you repeatedly fiddle the in-kernel defaults based on
in-field experience. That could just as easily have been done in
initscripts by distros, and much more effectively because it
doesn't need a new kernel. That's data.
The fact that this hasn't even been _attempted_ (afaik) is deplorable.
Why does everyone just sit around waiting for the kernel to put a new
value into two magic numbers which userspace scripts could have
set?
The objections to that approach follow these lines: the distributors cannot
get these numbers right; in fact, they are not really even inclined to try
to get them right. The proper tuning values tend to change from one kernel
to the next, so it makes sense to keep them with the kernel itself. And
the kernel should be able to get these things right if it is doing its job
at all. Needless to say, Linus argues for
this approach, saying:
We should aim to get it right. The "user space can tweak any
numbers they want" is ALWAYS THE WRONG ANSWER. It's a cop-out, but
more importantly, it's a cop-out that doesn't even work, and that
just results in everybody having different setups. Then nobody is
happy.
Linus has suggested (but not implemented) one
set of heuristics which could help the system to tune itself. Neil
Brown also has a suggested approach, based
on measuring the actual performance of the system's storage devices.
Fixing things at this level is likely to take some time; virtual memory
changes always do. But some smart people are starting to think about the
problem, and that's an important first step.
That, too, could be said for the discussion as a whole. There are clearly
a lot of issues surrounding filesystems and I/O which have come to the
surface and need to be discussed. The Linux kernel community as a whole needs to
think through the sort of guarantees (for both robustness and performance)
it will offer to its users and how
those guarantees will be fulfilled. As it happens, the 2009 Linux
Storage & Filesystems Workshop begins on April 6. Many of
these topics are likely to be discussed there. Your editor has managed to
talk his way into that room; stay tuned.
Comments (72 posted)
Patches and updates
Kernel trees
Core kernel code
Development tools
Device drivers
Documentation
Filesystems and block I/O
Memory management
Networking
Architecture-specific
Security-related
Virtualization and containers
Miscellaneous
Page editor: Jonathan Corbet
Distributions
News and Editorials
April 1, 2009
This article was contributed by Bruce Byfield
This year, the election of the Debian Project Leader (DPL) is proving more sedate than in previous years. The change, perhaps, reflects the diminished importance of the distribution, or the efforts over the last few years to increase civility within the project. Or possibly the change is due to the fact that only two candidates are running — Stefano Zacchiroli and incumbent Steve McIntyre, two long time project members who respect one another. But, for whatever reason, this years DPL election is noteworthy mainly for its civility. Zacchiroli and McIntyre share many views, and, on many others, differ mainly in emphasis. The result is that the election will likely be decided mainly on personality and management style rather than issues.
As outlined in the Debian Constitution, the DPL is elected each year. The election begins with a week long nomination period, followed by a three week campaign period and a two week voting period. Only official Debian Developers can vote, and results are tallied by the Project Secretary using a Condorcet method, in which the winner is the candidate who would beat each of the other candidates in a run-off election (although, this year, the results will be the same as a simple majority vote, since there are only two candidates). This year, voting began on March 29, and is scheduled to end on April 11, a second before midnight UTC.
The Candidates: Steve McIntyre
Steve McIntyre, the current DPL, has been a Debian Developer since 1996. According to his election platform, his main contribution to Debian is as a member of the CD Team, "both developing the debian-cd software itself and using that same software to create the official CDs." In addition, McIntyre hosts servers on Debian's autobuilder network for building packages for multiple hardware architectures, and helps to administer the project's Summer of Code program.
McIntyre ran largely on his record in his present term. In his platform, he
emphasized how, in the past year, he organized a review of how various
Debian teams were performing. To try to improve inefficient teams, he has
tried to recruit new members and suggest new work methods. He also
emphasized communication, saying that he has helped resolve disputes within
the project, and represented Debian at trade fairs, as well as to the press
and other free software groups. He listed "communications within the
project. The Debian community tends to discuss everything publicly and at great lengths, but, this year, debian-vote seems subdued compared to previous years." as his first goal in a new term, followed by finding ways to improve processes within the project, such as the one by which new maintainers join the project.
However, McIntyre did not specify how he would approach these goals. Instead, he simply said, "I want to see improvements made where they are clearly needed. There are cases where communications are lacking, or people and teams might not be working as effectively as they want to or need to. In those cases, I want to help and encourage the people involved to make those improvements. If that is not enough, then we may need stronger actions."
Rather than focusing on details, McIntyre urged people to vote for him on the basis of his experience, his organizational work, and his personality. "I'm a programmer, which means I have strong opinions on many subjects (*grin*). Despite that, I believe I am honest, generally approachable and easy to work with. I am a good communicator and negotiator, and I have made many friends in the Debian and wider Free Software Community over the years."
The Candidates: Stefano Zacchiroli
Stefano Zacchiroli, better known as "Zack," has been a Debian developer since 2001. He maintains a number of packages related to OCaml and Vim as well as "tools for mathematics in XML, [and] Python libraries for dealing with XML," according to his platform.
In contrast to McIntyre's statement, Zacchiroli's statement was much more organized and concrete. Even so, it is at least twice as long, listing key points in bullet lists and listing specific actions he wants to take. These key point range from a promise to be "transparent and present," responsible for setting the project agenda, and active in communicating his activities to the rest of the project to encouraging consensus and the control of "vocal minorities" in discussions, and finding new ways in which new developers and non-programmers can become more active more quickly. He also promised to encourage face-to-face meetings, to see that core teams within the project consist of at least three members, and to encourage members of inactive or poorly organized teams to find a replacement and "something to work on that is more fun for them."
While Zacchiroli's platform included such concrete ideas as methods for continuing to improve the levels of politeness on mailing lists and redesigning the web site, a large part of it centered on the role of the DPL. In Zacchiroli's view, the DPL is responsible for conflict resolution within the project. He explained that, while he will not be a "'post-in-every-thread' DPL" that he "will try to be present in 'hot' discussions . . . which concern the organization and the big picture of the project. I will also encourage seeking the DPL opinion on specific topics by pinging me explicitly. The DPL['s] opinion can also be a reasonable first attempt to solve a conflict; if it fails, we do have other mechanisms to settle it." He suggested that these proposals will be aided by his personality: "I am thoughtful, listen to others, and open to be convinced by good arguments."
Campaign Issues
For those who want details about the campaigning, Zacchiroli provides a convenient summary of most of the questions raised on the debian-vote mailing list during the campaign period.
However, for those hoping to differentiate the candidates by their stands on the issues, debian-vote offers little help. McIntyre and Zacchiroli are in broad agreement on many — even most — subjects, including the use of non-sexist language in standard project documents. Both agree that collaborative package management is desirable, particularly as a way to help new maintainers gain experience, and that important packages should usually have core teams to maintain them. Similarly, the two candidates are in broad agreement that Debian's reserve funds of some $125,000 could be greatly reduced, although McIntyre suggests that they be halved, and Zacchiroli suggests that they could be reduced to $50,000.
One small difference that emerges on debian-vote is the role of the DPL in discussions of policies and actions: Zacchiroli sees the DPL as the leader of discussions who sets the agenda, while McIntyre favors a less direct approach of encouraging sensible people to voice their opinions whenever possible. However, this is a difference in approach, not a dispute over whether anything needs to be done.
Even McIntyre's announcement of Luk Claes, another long-time Debian Developer, as a running mate has not been much of issue. The idea that the DPL needs trusted assistants is not a new one; for instance, in 2005, Branden Robinson and Andreas Schuldei ran, promising that if either was elected, he would be assisted by "Project SCUD" — a group of half a dozen long-time Debian contributors. However, while Project SCUD was controversial in its day, nobody has publicly expressed a comparable level of concern that McIntyre proposed a kind of partnership that the Debian Constitution does not explicitly provide for, explaining that he and Claes are "planning on splitting the workload between us, depending on what fits and who has the time at any given point. My plan is for both of us to receive leader@mail."
Most likely, the proposal is uncontroversial because Zacchiroli's position is not far from McIntyre's. Although Zacchiroli said in his platform that he does not believe in a "DPL board" because "the DPL term is too short to spend time with extra coordination hops," he immediately moved closer to McIntyre's position by adding that he "will be looking for a 2IC (second in charge, vice-leader)." This admission led McIntyre to add a rebuttal to his own platform: "That I can understand completely, but I'd be personally much happier if he was to name his proposed assistant before the election. I did that deliberately with Luk, as I want people to be able to vote for a known quantity rather than somebody unnamed."
The largest difference between the candidates is in their answers to the question of what actions will improve Debian the most. In reply to the question, Zacchiroli wrote, "When I joined in 2001, Debian was The Distribution that a lot of users were using and all my friends knowing Free Software were dreaming of contributing to. Things have changed since then: newbies now use Ubuntu or Fedora, and contributors can easily join their communities. Debian is too often seen as the old distro that some old timers still use, having a process to join which is not worth trying. The Debian value that needs to be improved the most is changing that: putting Debian back into its place." Zacchiroli maintains that, within a year, Debian can set an example for the rest of the free software community, particularly in contributing changes to upstream projects.
In comparison, McIntyre replied
to the question by writing about improving communication both inside and
outside the project. "We need to encourage more people to experiment
with new ideas, rather than simply live with the status quo all the
time. Larger projects have inertia, and we have to acknowledge that: either
push things more to overcome it, or work around it for the new ideas until
they're ready for wider adoptions." He added that "the most
important thing we need to do is to work out exactly what we want the
Debian project to be, in terms of leadership. Making it clearer and easier
for people to gain recognition for whatever work they're doing on or with
Debian is far and away the best way to encourage more people to get
involved." Noticeably, though, the solution for both candidates to the main problem that they see is to improve coordination within and without the project, the only difference being the reasons they want to do so.
Conclusion
Rather than attack each other's policies, both McIntyre and Zacchiroli tried to point out the weakness in each other's statements. For instance, in the rebuttal added to the end of his platform statement, Zacchiroli attempts to characterize Claes and McIntyre's candidacy as vague, claiming that "their platform lacks hints and strategies that explain how they are going to attack those problems . . . . Also, I'm missing the vision of the two candidates on relevant topics such as Debian membership, mailing list discussion quality, [and] derivatives [distributions based on Debian]."
For his part, McIntyre attempted in his own rebuttal to counter Zacchiroli's bullet lists by saying, "I'm not sure he will have the time to do what he's planning: time always runs away more quickly than you expect" — a comment that serves to remind voters of his own experience as DPL.
After you read McIntyre's and Zacchiroli's comments, you soon realize that there is no major difference of opinion between them. When you find an apparent one, on close examination, it tends to be a matter of emphasis at a particular time more than anything approaching a major disagreement. In fact, one candidate's answer in a particular context often echoes the other's answers in another. Both show an awareness of issues and maturity that could make an effective DPL.
The main question about this years' election, apart from who wins, is whether such reasonableness will affect voter turnout. Although many decry the acrimony of previous elections, it may have encouraged people to discuss issues and vote. This years' reasonableness seems to have reduced discussion on debian-vote (always taking into account the Debian community's tendency to discuss everything publicly and at great length) and the possibility seems strong that the number of votes cast could be similarly reduced. We'll know some time in the early hours of April 12 when the results are announced.
Comments (5 posted)
New Releases
The CentOS 5.3 release is available. "
CentOS-5.3 is based on the upstream release EL 5.3.0, and includes
packages from all variants including Server and Client. All upstream
repositories have been combined into one, to make it easier for end
users to work with. And the option to further enable external
repositories at install time is now available in the installer." See
the release notes for more information.
Full Story (comments: 8)
The Fedora 11 beta release has been
announced. "
The larger open source community, beyond just developers and Fedora contributors, can download, test, and report issues, which should substantially improve the final release. Fedora even provides convenient Live images that testers can write to either CD/DVD, or to a USB key. Windows users can also make Live USB keys using the easy LiveUSB Creator application." See
the Fedora 11 feature list for information on some of the new stuff in this release.
Comments (none posted)
Ubuntu Jaunty Jackalope (9.04) beta is available for testing. In
particular, there is a
call for testing
suspend/resume. For those who have already downloaded Jaunty beta, beware
of a
python upgrade with some problems.
The bad packages have been blocked and fixed packages have been uploaded, so
make sure you have the correct python 2.6 packages.
Full Story (comments: none)
Distribution News
Debian GNU/Linux
The voting period has begun in the this year's Debian Project Leader
elections. There are three choices available: Stefano Zacchiroli, Steve
McIntyre (the current DPL) or neither. Voting will be open until April 11,
2009.
Full Story (comments: none)
Fedora
The Fedora Advisory Board is holding its monthly public meeting on Tuesday,
7 April 2009, at 1800 UTC on IRC Freenode. "
We're trying something
new (albeit in a minor way) in this meeting. The moderator will still be
available to gather input from the #fedora-board-public channel, but will
voice people, one at a time, in the queue in the #fedora-board-meeting
channel. We'll limit time per voice as needed to give everyone in the
queue a chance to be heard. If this process works well, we'll use it at
later meetings and note the change on the wiki." Public meetings
will be held on the first Tuesday of each month.
Full Story (comments: none)
Gentoo Linux
Click below for a summary of the March 26, 2009 meeting of the Gentoo
council. Topics include GLEP 55 and EAPI-3 Proposals.
Full Story (comments: none)
Ubuntu family
The Ubuntu Developer Community has announced a new initiative to help those
interested in developing Ubuntu. "
Thursday is from now on Packaging
Training day. We'll have regular one-hour sessions in #ubuntu-classroom on
irc.freenode.net where we'll have speakers who present a packaging
technique and leave enough time for all packaging related questions you
might have." Click below for the April schedule.
Full Story (comments: none)
Other distributions
LynuxWorks has
announced
that BlueCat 5.6 Linux operating system now supports Portwell's commercial
off the shelf PEB-2737 embedded computer board. "
Utilizing an Intel
Embedded Compact Extended form factor, the PEB-2737 leverages Intel's
Z510/Z530 Atom processor series by providing an optimized
micro-architecture for low power, compact and fanless devices and when
combined with LynuxWorks' BlueCat Linux, is a basis for applications in
in-vehicle infotainment, medical, military and industrial automation and
control."
Comments (none posted)
Distribution Newsletters
The
DistroWatch
Weekly for March 30, 2009 is out. "
After last week's interview with Tiny Core's Robert Shingledecker, the latest issue of DistroWatch Weekly takes a first look at the world's smallest desktop Linux distribution. Can a 10 MB distro be turned and tweaked into a powerful desktop replacement? Read on to find out. In the news, PCLinuxOS has seen developers leave the popular distribution over internal conflicts due to issues around the latest release. This has also caused ripples as TinyMe decides to move away from PCLinuxOS as their base. In the meanwhile, the administrator of a PCLinuxOS community web site has announced that he will no longer be involved with PCLinuxOS and will instead work on a new distribution called Unity. In other news, OpenSolaris posts major improvements to their package management system, Fedora calls for testing the open-source Nouveau driver, and the founder of Qimo 4 Kids explains the purpose of the young distribution designed for children. All this and more in this issue of DistroWatch Weekly - happy reading!"
Comments (none posted)
The Fedora Weekly News for the week ending March 29, 2009 is out.
"
This week in "What Happened Last Summer?" Developments conveys an
announcement on the Fedora intrusion of 2008. Announcements reels-off a
list of interesting "Upcoming Events". PlanetFedora selects choice blog
posts including Richard W.M. Jones' RPM-dependency visualizer. Marketing
reports that "Fedora has the Most New Features". Ambassadors reports
that "Fedora is on the move in Italy". QualityAssurance shares the
results of "Test Days" for the nouveau driver and other outstanding
work. Translation catches-up on problems with Persian l10n and more.
Artwork asks is it too late for "A Lion for Leonidas?". Security warns
of a "Firefox Emergency". Virtualization concludes that "KVM and QEMU
Merge Feature Stays in Fedora 11" and on "Web Based libvirt Management"
and a comprehensive "Fedora Virtualization Status Report"."
Full Story (comments: none)
This issue of the
openSUSE Weekly News
covers an Update on iFolder, openSUSE Weekly News @ RadioTux.de, People of
openSUSE is back, OpenSource meet Business, My GIMP Tutorial and Resource
and more.
Comments (none posted)
The Ubuntu Weekly Newsletter for the week ending March 28, 2009 is out.
"
In this issue we cover: Ubuntu 9.04 Beta Released, Jaunty Countdown
Banners, Ubuntu 7.10 reaches EOL April 18th, Ubuntu Server dedicated
course, QA Team Testing Day: Ubuntu Installers, Ubuntu Makassar, Ubuntu
Tunisia, Ubuntu New York, Ubuntu LoCo Drupal 6.3.1 released, Launchpad
Maintenance April 1st, Linking project releases in Launchpad to Milestones,
LinkedIn for Ubuntu Members, Ubuntu 9.04 Free Culture Showcase Winners, The
Fridge needs a new theme, LWN subscription for Ubuntu Members, Ubuntu
Podcast #23 and an interview with John Pugh(Canonical Technical Partner
Mgr.), Full Circle Magazine #23, March 2009 Team Reports, and much, much
more!"
Full Story (comments: none)
Distribution meetings
Look for the openSUSE project at LinuxExpo in Prague.
"
The openSUSE Project is bringing the green to Prague in April! The
openSUSE Project will have a booth, demos, and several presentations at the
LinuxExpo in Prague, April 15 and 16th at the Hotel Olympik Artemis."
Full Story (comments: none)
The openSUSE Project will be having its
first
contributor's conference, September 17 - 20, 2009 in Nuremberg, Germany.
"
If you're interested in being part of the conference team, speak up on the opensuse-marketing mailing list. We're looking for contributors to help with speaker selection, event staff, video recording talks and sessions, and much more. See the wiki for more help, and add your name if you're interested in being part of the conference team."
Comments (none posted)
Distribution reviews
Computerworld
reviews
SUSE Linux Enterprise Desktop 11.
"
There are lots of Linux distros being touted as great desktop operating systems for PCs. However, there's only one that I can wholeheartedly recommend to business owners as a Windows replacement: Novell's SUSE Linux Enterprise Desktop 11 (SLED).
SLED 11, which was released on March 24, stands above its competitors because it works and plays well with existing Windows business networks, data files and application servers. You can, of course, add this functionality to other Linux distributions -- if you're willing to do it manually. SLED gives you pretty much the full deal out of the box."
Comments (none posted)
ars technica
reviews
Ubuntu 9.04 beta. "
All things considered, Ubuntu 9.04 is shaping up
to be a pretty good release, albeit a bit light on new features. I've been
running the it since the beginning of the month, when I installed it from a
daily CD image. I've only had a few minor problems with it and it's
definitely on track to be much more robust than the last two versions. I'm
having significantly fewer problems with Compiz and PulseAudio. I've also
noticed that boot performance in 9.04 is excellent, as my system starts up
much faster."
Comments (none posted)
Jason Brooks
takes
a look at SUSE Linux Enterprise Desktop (SLED). "
Based on my tests so far of SLED 11, I've found Novell's new Linux offering to be a solid desktop operating system with a set of features and support options that are well tuned for enterprises - particularly those looking to integrate the Linux desktop into a Microsoft-centric infrastructure."
Comments (none posted)
Page editor: Rebecca Sobol
Development
April 1, 2009
This article was contributed by Koen Vervloesem
Simultaneously running multiple operating systems on one computer has
been a common practice for decades on mainframes, but is now commonly used
on all classes of machines. This can be used for server consolidation: many
underutilized physical servers are replaced by one powerful physical server
hosting different virtual machines. However, this doesn't make management
of the (now virtual) servers easier. To the contrary: as more and more
servers are virtualized, system administrators could lose the "big picture"
of their server farm. Good administration tools for virtualization are
priceless.
After many months of development and bug-fixing, the developers of
ConVirt have released
version 1.0 of their graphical management tool for
virtual machine life cycle management. This tool, in a previous life called
XenMan, offers a solution to install ("provision" in virtualization lingo),
monitor and manage the complete lifecycle of Xen and KVM deployments from a
central dashboard. ConVirt is an open source product, aimed at the
enterprise market. The company Convirture offers paid support, but
free support is available through the community forums and wiki.
Managing a set of virtual machines manually is a time-consuming and
error-prone task. Many system administrators write their own custom
provisioning scripts to handle this, but then the problem of keeping track
of all these virtual machines and monitoring them pops up. ConVirt manages
both Xen and KVM from a single interface and shields the low-level
differences between these virtualization platforms from the user. This
means users don't need to learn and use multiple tools if different virtual
machines use a different virtualization platform. Installing, configuring
and monitoring virtual machines is all possible from a single
dashboard. Most of the tasks, such as migrating virtual machines, taking
snapshots or adding storage, are possible with a few clicks.
Preparation
Preparing an environment of virtual machines for ConVirt happens in
three steps: install ConVirt on one computer, prepare each server to be
managed by ConVirt, and then start ConVirt, after which it discovers the
prepared managed servers. The second step may be skipped if all managed
virtual machines reside on the same computer as ConVirt.
Before the preparation, one should take a couple of things
into account. ConVirt can be installed on most Linux systems, but it is
only tested on a couple of distributions. Convirture has certified
ConVirt on CentOS or Red Hat Enterprise Linux 5.2 with Xen 3.1, SUSE Linux
Enterprise Server 10 SP2 with Xen 3.2, Debian 5.0 with KVM-72 and Ubuntu
Server/Desktop
8.10 with KVM-72. The community has tested ConVirt successfully on some other
configurations. The remotely managed servers should have a supported
version of Xen or KVM, and should be accessible by SSH.
The wiki has specific installation
instructions for a few Linux distributions. Your author applied
them successfully on an Ubuntu 8.10 Desktop with KVM. On each server,
download the convirture-tools package and run:
convirt-tool setup
to configure the server. For Xen, this command configures the
Xend Server to listen on port 8006 and to open port 8002 for migration. The
setup tool writes a summary of its operations to the
/var/cache/convirt/server_info file for later reference. ConVirt
doesn't require deploying a software agent on the managed servers because
it uses SSH.
Virtual infrastructure
ConVirt supplies a wealth of monitoring information at multiple levels:
the individual virtual machine, the physical server. and the server
pool. The user sees performance, utilization, and availability metrics for
the CPU, memory, storage, and network. This gives one a good overview
to decide where adjustments need to be made to capacity or to reallocate
resources.
The concept of a server pool is central in ConVirt's operation, to
the point that the user can install, configure, and monitor virtual machines
at the server pool level. Key monitoring information for different servers
of the pool is summarized to a pool-wide value. In the same way one can
change the pool-wide configuration, which ConVirt then applies to all
servers in the pool. It's also possible to associate shared storage (SAN or
NAS) with a server pool. All virtual machines on this server pool then use
the same storage settings.
Adding a server to a server pool is simple: select a server pool in
ConVirt and right-click to select 'Add Server'. Choose Xen or KVM as the
virtualization platform and enter the IP address or hostname of the server,
provide the username and password for SSH and press OK. After this, the
server shows up under the server pool and is ready to host virtual
machines.
Virtual appliances
Templates are central to ConVirt's provisioning capabilities: the tool
comes with a couple of templates, which are easily customizable. ConVirt
creates two default groups in the image store: Xen Paravirtual, which
contains virtual machine images for the Xen platform, and Common, which
contains images that can be deployed on Xen or KVM if the processor
supports virtualization. The Xen image store comes with templates for a
CentOS or Fedora installation, and the Common image store has templates for
a generic Linux or Windows installation.
Of course it is possible to create a template based on your own image or
a third-party virtual appliance. An interesting feature is the
integrated virtual appliance catalog browser: ConVirt searches on the
websites of a number of appliance vendors (at this moment only rPath and JumpBox) of virtual appliances. Users can
browse the catalog and download the right appliance, which can then be
installed in ConVirt.
The rest of the configuration of a template comes down to allocating
CPU, memory and storage, and defining the network. Installing a template
into a new or existing server is a one-click action. If a user has a lot of
servers with different workloads, ConVirt is able to identify the optimal
placement in the server pool, taking into account the performance and workload
of the various servers. Migrating a virtual machine between servers
couldn't be easier: with a simple drag-and-drop move, the user can move a
virtual machine from one server to another while it's running and without
interrupting operations. The same holds for a whole group of virtual
machines, for example if the server is upgraded or down for
maintenance.
ConVirt 1.0 also allows dynamic configuration of CPU and memory
resources for live virtual machines. In the future the project intends to
add a policy-based mechanism to allow a more elastic pre-configuration and
enforcement of resource limits.
Conclusion and future direction
ConVirt is an interesting solution for system administrators with a lot
of servers and virtual machines to manage. One central dashboard to
install, monitor and manage virtual machines should be more than
welcome. On the server side there is virtually no extra work: a user only
needs to run the setup tool once to configure the server correctly.
ConVirt is fully open source, and Convirture actively encourages the
community to discuss, give feedback, and make suggestions as well as contribute
directly to the codebase. Convirture's founder
Arsalan Farooq said that they have
received several key contributions from outside Convirture, but he admits
that the majority of the code has been contributed by his company. His hope
is that this ratio will change going forward in favor of even more
community contributions.
At this moment, ConVirt supports Xen and KVM, but the management tool
has a plugin architecture that allows new platforms to be added
easily. According to Farooq, the ConVirt developers will continue to add
support for any relevant open source virtualization platforms that might
emerge, and he mentioned Red Hat's oVirt
platform. He also added that this is an area where the developers
especially encourage community involvement, so if you want your favorite
virtualization technology to be supported in ConVirt, get
involved with the project.
Comments (3 posted)
System Applications
Database Software
The March 29, 2009 edition of the PostgreSQL Weekly News
is online with the latest PostgreSQL DBMS articles and resources.
Full Story (comments: none)
Version 3.6.12 of the SQLite DBMS has been
announced.
Changes include some new capabilities, bug fixes and performance improvements.
Comments (none posted)
Version 3.0.1 of SQuirreL SQL Client has been
announced,
it features bug fixes and a new Korean translation.
"
SQuirreL SQL Client is a graphical SQL client written in Java that will allow
you to view the structure of a JDBC compliant database, browse the data in
tables, issue SQL commands etc."
Comments (none posted)
Device Drivers
Version 2.0.0 of Syntek Semicon DC-1125 Driver has been
announced.
"
Linux/Unix driver development for Syntek Semicon USB2.0 Video device DC-1125, like the one that is found in Asus A6K laptops. The device can be recognized by the usb id 174f:a311 and maybe also be a standalone unit (not integrated)."
Comments (none posted)
Interoperability
Maintenance Release 3.2.9 of Samba has been
announced.
"
This is the latest bug fix release for Samba 3.2 and is the version recommended for all production Samba servers running this release series." See the
release notes for more information.
Comments (none posted)
Mail Software
Stable version 1.2.0 of Bogofilter, a bayesian spam filter,
has been announced.
"
This release adds 3 new options to force bogofilter to use a specified number of tokens when scoring a message.
The options are:
--token-count=n
--token-count-min=n
--token-count-max=n
When one or more of these options is specified, bogofilter tries to
use the specified number of tokens when computing a message's score."
Full Story (comments: none)
Networking Tools
Version 0.9.12 of conntrack-tools has been announced.
"
The netfilter project presents another development release of the
conntrack-tools that includes a new `-S' option for the command line
tool, and a generic infrastructure to allow using different protocols to
replicate state-changes, currently unicast UDP and multicast are supported."
Full Story (comments: none)
Web Site Development
Version 9.03.0 beta 2 of Midgard2 has been announced.
"
The second beta of Midgard2 9.03 is targeted at web framework and
desktop developers. It provides a comprehensive set of content
repository APIs that can be used to build replicated information
applications that share their information using a common storage layer
and replication tools."
Full Story (comments: none)
Desktop Applications
Audio Applications
Version 2.8 of Ardour, a multi-track audio editor, has been
announced.
"
I am pleased to announce the release of Ardour 2.8. As has been previously announced, the 2.X series is now in a state of "feature freeze" so that we can try to concentrate on Ardour 3.0, but as a gesture of thanks to the community for the support during February, I wanted to release this mostly-bugfix version that also comes with a couple of significant features. These include much more reliable VST support on Linux, track/bus templates and, with some important qualifications, AudioUnit state and preset handling."
Comments (none posted)
Version 0.49.1 of Traverso has been announced.
"
Traverso is a cross platform multitrack audio recording and
editing suite with a clean and innovative interface targeted for home
and professional use. Changes in this release:
* New Transport Console
* Improvements to the New Project Dialog
* AudioClip Selection or Grouping, featuring: Move, Copy, Remove
* Fold Sheet or Track: Move all the audioclips in a Track or the entire Sheet
right from the mouse cursor without the need to select them first!
* Various smaller new features and bug fixes".
Full Story (comments: none)
Data Visualization
Version 9.5 of the DISLIN data plotting library has been released.
"
DISLIN is a high-level and easy to use plotting library for
displaying data as curves, bar graphs, pie charts, 3D-colour plots,
surfaces, contours and maps. Several output formats are supported
such as X11, VGA, PostScript, PDF, CGM, WMF, HPGL, TIFF, GIF, PNG,
BMP and SVG."
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)
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)
Phoronix
tries out the Nouveau driver in Fedora 11. Overall, they seemed fairly impressed with its capabilities. "
The xf86-video-nv driver is officially maintained by NVIDIA, but it's their half-assed attempt at being open-source friendly. The X.Org driver's code is obfuscated, its 2D support is limited, there is no 3D acceleration at all, and it barely receives new features and support these days. Meanwhile, a group of open-source developers have been reverse-engineering NVIDIA's binary Linux driver to write the Nouveau driver that will offer 2D, 3D, and video acceleration and aims to be feature-complete. The Nouveau project has been around for a few years, but their code is starting to come to maturation with kernel mode-setting and a Gallium3D driver hopefully being stable by year's end."
Comments (27 posted)
Electronics
Version 1.0 of TTA-Based Codesign Environment (TCE) has been announced.
"
TTA-Based Codesign Environment (TCE) is a toolset for designing
application-specific processors (ASP) based on the Transport Triggered
Architecture (TTA). TTA is a minimalistic processor architecture
template that allows high level of control for the designer to choose
the boundary between the hardware and the software.
The toolset provides a complete codesign flow from C programs down to
synthesizable VHDL and parallel program binaries. Processor
customization points include the register files, function units,
supported operations, and the interconnection network."
Full Story (comments: none)
Fonts and Images
Release 0.19 of Open Clip Art Library has been announced.
"
Release 0.19 of Open Clip Art Library, containing over 12,000
high quality scalable
vector graphics (SVG) files released into the public domain by over a 1000
artists, is now available for download and use. In celebration of this
accomplishment, since OCAL's last release happened in 2005, and March
being 5th anniversary of the Open Clip Art Library (OCAL), the OCAL
community set a goal to achieve 10,000 uploaded pieces of vector graphics."
Full Story (comments: none)
Interoperability
Version 1.1.18 of Wine has been
announced. Changes include:
"
RPC over HTTP support.
Improved support for upgrades in MSI.
Debug symbols in WineDbg on Mac OS X.
Many Direct3D code cleanups.
Various bug fixes."
Comments (none posted)
Multimedia
Version 0.5.34 of Elisa Media Center has been announced.
"
This release fixes a bunch of bugs and introduces cool new features
(under the hood) in the widgets system and the styling engine."
Full Story (comments: none)
Music Applications
Version 0.03.9-1 of guitarix, a JACK-based guitar amplifier,
has been announced.
"
This is a bugfix release.
fixed bug's : set gain persistent in jconv settings
remove compiler flags ( sse + fast-math )
make guitarix_midi_out temporarly".
Full Story (comments: none)
Version 0.9.10 of Strasheela has been announced.
"
Strasheela is a highly expressive constraint-based music composition
system. Users declaratively state a music theory and the computer
generates music which complies with this theory. A theory is
formulated as a constraint satisfaction problem (CSP) by a set of
rules (constraints) applied to a music representation in which some
aspects are expressed by variables (unknowns)."
Full Story (comments: none)
Miscellaneous
Version 1.8.1 update 3 of OmegaT has been
announced.
"
OmegaT is a free and open source multiplatform Computer Assisted Translation tool with fuzzy matching, translation memory, keyword search, glossaries, and translation leveraging into updated projects.
A new maintenance version of OmegaT 1.8.1 has been released.
The focus of this release is on spellchecking, with two bug fixes and one enhancement."
Comments (none posted)
Version 3.0.2 of XMind has been
announced.
"
Popular brainstorming and mind mapping tool, Eclipse Community Award 2008 winner, often used for capture ideas, knowledge/project management and GTD, supporting fishbones/org-charts/tree charts/spreadsheets, compatible with Freemind/Mindmanager,easy-to-use.
Change of Version 3.0.2
New Features:
1. Security
2. New Sheet from Topic
3. Hyperlink in Notes"
Comments (none posted)
Languages and Tools
C
The GCC project has created a release branch for 4.4.0, opening up the
mainline for new development. This branch
has been held up for some time
while the Free Software Foundation has pondered changes to the licensing
for the GCC runtime libraries. The delay has created some significant
unhappiness in the GCC community, some members of which have vocally
wondered what the GCC steering committee is for if the FSF is making
this kind of decision. The logjam appears to have been cleared, but there
has been no word, yet, on any decisions on the licensing issues.
Full Story (comments: 3)
Caml
The March 31, 2009 edition of the Caml Weekly News
is out with new articles about the Caml language.
Full Story (comments: none)
Python
Versions 0.6.1 and 0.5.2 of Sphinx have been announced.
"
Sphinx is a tool that makes it easy to create intelligent and beautiful
documentation for Python projects (or other documents consisting of
multiple reStructuredText source files)."
Full Story (comments: none)
Guido van Rossum has announced that the Python project will be moving to
the Mercurial distributed version control system. "
It's hard to explain my reasons for choosing -- like most language
decisions (especially the difficult ones) it's mostly a matter of gut
feelings. One thing I know is that it's better to decide now than to
spend another year discussing the pros and cons. All that could be
said has been said, pretty much, and my mind is made up."
Full Story (comments: 9)
The March 28, 2009 edition of the Python-URL! is online with
a new collection of Python article links.
Full Story (comments: none)
Tcl/Tk
The March 27, 2009 edition of the Tcl-URL! is online with new
Tcl/Tk articles and resources.
Full Story (comments: none)
XML
Version 0.1r of pyxser has been announced.
"
pyxser stands for Python XML Serialization, it's Python
object serializer that does the job in a standard way.
Unlike other serializers, it uses structured document
defined in the pyxser DTD, has a FPI (forma public
identifier) and the deserialization process run before
validating the serialized object document against the
pyxser DTD."
Full Story (comments: none)
Cross Compilers
Version 0015 of Arduino, an open-source development system for
Atmel AVR microprocessors, is
available.
The main new feature is support for the new
Arduino Mega
development board, see the
release notes
for more information.
Comments (none posted)
Editors
Pretest version 23.0.92 of the Emacs editor is out.
This is a testing release for what will become Emacs 23.1.
Full Story (comments: none)
Page editor: Forrest Cook
Linux in the news
Recommended Reading
Over at Linux Journal, Glyn Moody
looks at efforts to project Richard Stallman's copyright hack (the GPL) into the World Trade Organization (WTO). "
The similarities are clear. Both copyright and the WTO have both been instruments of control that seek to limit what people — and peoples — can do in their respective spheres of creation and trade. Both have steadily accreted powers over the years, until they have become hugely problematic for those who wish to see knowledge and products based on knowledge made as widely available as possible. So the idea that Stallman's hack might be applicable is certainly attractive — exciting even."
Comments (3 posted)
Trade Shows and Conferences
The Register
covers
comments by Microsoft's Robert Youngjohns at the
Open Source Business Conference.
"
Microsoft has made a "tremendous commitment" to systems and file interoperability, according to its head of North American sales and marketing.
Robert Youngjohns on Wednesday called interoperability between Widows and Linux and support for open-file formats and open-source languages like PHP a business imperative.
He added Microsoft should be judged by its actions with support for PHP, not by its words - presumably statements by senior management on alleged violations of hundreds of Microsoft patents by Linux and open source."
Comments (26 posted)
Companies
The New York Times
reports
that Intel will be handing control of the Moblin distribution (recently
reviewed by LWN) to the Linux
Foundation. "
Intel will maintain strong control over the software
since it employs the top Moblin developers. But that could change over time
as outside developers show interest in the software."
Comments (7 posted)
Reuters
reports that Red Hat Inc. is ripe for a corporate acquisition.
"
Citigroup said Red Hat Inc, which posted strong quarterly results on Wednesday, is a potential takeover target as the Linux software maker's strategy attracts the attention of larger technology firms.
Citigroup and RBC Capital raised their price targets on Red Hat, which also forecast full-year results in line with market estimates.
"We believe Red Hat is a tempting acquisition target," Citigroup analyst Brent Thill wrote in a note to clients."
Comments (41 posted)
Legal
Microsoft and TomTom have
settled their patent dispute as reported by eWeek. TomTom will pay Microsoft an undisclosed amount of money to license the patents, while removing code covered by the FAT patents over the next two years. "
According to Microsoft, the agreement includes patent coverage for Microsoft's three file management systems patents provided in a manner that is fully compliant with TomTom's obligations under the General Public License Version 2 (GPLv2). TomTom will remove from its products the functionality related to two file management system patents (the "FAT LFN patents"), which enables efficient naming, organizing, storing and accessing of file data, Microsoft said. TomTom will remove this functionality within two years, and the agreement provides for coverage directly to TomTom's end customers under these patents during that time." While Microsoft and TomTom say this is all GPLv2 compatible, there may be others who disagree.
Comments (17 posted)
Groklaw
covers
the Software Freedom Law Center's
response
to the TomTom settlement. From SFLC: "
Today's settlement between
Microsoft and TomTom ends one phase of the community's response to
Microsoft patent aggression, and begins another. On the basis of the
information we have, we have no reason to believe that TomTom's settlement
agreement with Microsoft violates the license on the kernel, Linux, or any
other free software used in its products. The settlement neither implies
that Microsoft patents are valid nor that TomTom's products were or are
infringing."
Comments (6 posted)
Interviews
Over at Linux Magazine, Jeff Layton
interviews ext4 hacker Ted Ts'o. Layton stays away from the recent ext4 controversy, instead looking at the design goals and future plans for ext4. "
One of our primary design goals was that it should be painlessly easy to upgrade from ext3 to ext4. You might not get all of the benefits of ext4 unless you do a backup/reformat/restore of your filesystem, but you would get at least some of the benefits by simply remounting the filesystem using ext4 and enabling some of ext4's features."
Comments (40 posted)
Resources
Dave Phillips
looks
at the status of the five most active notation software projects.
"
The essential requirements for all music notation programs include
various score layout functions, data entry methods, music symbol palettes,
audio output support modes and options for printing the finished
score. Basic programs may include only a limited subset of the possible
features, while more professional software offers more features for greater
control over the details of a work. Of course, with greater control comes
greater complexity. The designers of music notation programs work hard to
balance ease of operation with the proliferation of features."
Comments (4 posted)
Reviews
LinuxDevices
takes a look at Seagate's soon to be released NAS device.
"
Seagate is readying a four-bay network-attached storage device for small businesses that runs embedded Linux and stores up to 8TB. The hot-swappable BlackArmor NAS 440 offers an iTunes server and DLNA-compliant media server, RAID 0/1/5/10, dual gigabit Ethernet ports, and four USB ports, says Seagate.
With the BlackArmor NAS 440, Seagate has launched its first homegrown, small business NAS device, re-launching a BlackArmor brand that it picked up when it acquired Maxtor in 2006."
Comments (11 posted)
Miscellaneous
Ben Galbraith is Mozilla's Co-Director of Developer Tools. In this blog post
he
ponders various gaps in the tool-chain with regard to memory tools.
"
To be clear, most web pages and web applications don't push the
browser's memory limitations enough to cause performance problems related
to either of the scenarios above. As stated at the outset, this blog entry
is about those web applications that need to treat the browser as a
high-performance run-time, which in the context of this entry means that
they have much-larger-than-average memory requirements." (Found on
Linux
Journal)
Comments (none posted)
Page editor: Forrest Cook
Announcements
Non-Commercial announcements
The Free Software Foundation has posted
a revised version
of the new GCC runtime library exception. There's no description of the
changes, but the new text is short and easy to read. Essentially, it seems
to specifically equate Java virtual machine code with human-readable
languages, meaning that Java byte code can be processed through GCC and
still link against the runtime library.
Comments (8 posted)
The Linux Foundation has announced credativ as its newest member.
"
credativ, an independent consulting and services company focused on
free software and open standards, will participate in advancing the
Linux Standard Base (LSB), which establishes common standards across
the different Linux distributions. Additionally, as one of Europe's
largest employers of Debian developers, credativ has a particular
interest in encouraging collaboration focused around Debian development."
Full Story (comments: none)
Commercial announcements
SGI has
announced
that it has been acquired by Rackable Systems Inc. The purchase price
is "approximately $25 million."
Comments (23 posted)
New Books
O'Reilly has published the book
Beautiful Teams
by Andrew Stellman and Jennifer Greene.
Full Story (comments: none)
O'Reilly has published the book
Java SOA Cookbook by Eben Hewitt.
Full Story (comments: none)
Education and Certification
The Advanced Scientific Programming in Python Summer School will be held
in Berlin, Germany from August 31 - September 4, 2009.
"
Many scientists spend much of their time writing, debugging, and
maintaining software. But while techniques for doing this efficiently
have been developed, only few scientists actually use them. As a
result, they spend far too much time writing deficient code and
reinventing the wheel instead of doing research. In this course we
present a selection of advanced programming techniques with
theoretical lectures and practical exercises tailored to the needs of
the programming scientist."
Full Story (comments: none)
use Perl has
announced
the availability of a Perl educational DVD.
"
Peter Scott has just created a learning Perl DVD, published by Addison Wesley. 4+ hours of Perl instruction on screencast with video of the author introducing each lesson. This is an introduction to Perl for the student who learns by example and prefers a visual and/or auditory style."
Comments (none posted)
Calls for Presentations
A call for papers has gone out for DeepSec 2009.
"
The DeepSec organisation is happy to announce the Call for Papers for the
next conference in November 2009. The conference will take place at the
Imperial Riding School Renaissance Hotel in Vienna, Austria."
Submissions are due by July 15.
Full Story (comments: none)
FOSS.IN 2009 has been announced.
"
FOSS.IN/2009 will be held on December 1-5, 2009 (Tuesday through
Saturday) at Bangalore's largest and most modern conference venue - the
NIMHANS Convention Centre."
The first call for participation has gone out for the event.
Full Story (comments: none)
Upcoming Events
EuroDjangoCon registration is open.
"
Just to let you know you can still register for EuroDjangoCon '09. The other levels of prices were
scrapped and instead we're just going with the early bird rates. It will be
in Prague on May 4th - 6th (conference days) and 7th - 8th (sprint days).
The venue has changed to the Iris Congress Hotel and the conference is now single track."
Full Story (comments: none)
Registration for the 2009 Linux Plumbers Conference - September 23-25,
Portland - is open. "
For those new to the conference, the Linux Plumbers Conference
was created to bring together key developers involved in
Linux plumbing - the 'Linux plumbers' - and give them an
opportunity to discuss problems face-to-face, both within
subsystems and across subsystems."
Full Story (comments: none)
Events: April 9, 2009 to June 8, 2009
The following event listing is taken from the
LWN.net Calendar.
| Date(s) | Event | Location |
April 8 April 10 |
Linux Foundation Collaboration Summit |
San Francisco, CA, USA |
| April 14 |
OpenClinica European Summit |
Brussels, Belgium |
| April 15 |
Linuxwochen Österreich - Krems |
Krems, Austria |
April 16 April 17 |
Nordic Perl Workshop 2009 |
Oslo, Norway |
April 16 April 18 |
Linuxwochen Austria - Wien |
Wien, Austria |
April 16 April 19 |
Linux Audio Conference 2009 |
Parma, Italy |
April 20 April 23 |
MySQL Conference and Expo |
Santa Clara, CA, USA |
April 20 April 24 |
samba eXPerience 2009 |
Göttingen, Germany |
April 20 April 24 |
Perl Bootcamp at the Big Nerd Ranch |
Atlanta, GA, USA |
April 20 April 24 |
Cloud Slam '09 |
Online, Online |
April 22 April 25 |
ACCU 2009 |
Oxford, United Kingdom |
| April 23 |
Linuxwochen Austria - Linz |
Linz, Austria |
April 23 April 24 |
European Licensing and Legal Workshop for Free Software |
Amsterdam, The Netherlands |
April 23 April 26 |
Liwoli 2009 |
Linz, Austria |
| April 25 |
Linuxwochen Austria - Graz |
Graz, Austria |
| April 25 |
Festival Latinoamericano instalación de Software libre |
All Latin America, All Latin America |
| April 25 |
Grazer Linux Tage 2009 |
Graz, Austria |
April 25 April 26 |
LinuxFest Northwest 2009 10th Anniversary |
Bellingham, Washington, USA |
April 25 May 1 |
Ruby & Ruby on Rails Bootcamp |
Atlanta, Georgia, USA |
| April 27 |
OSDM 2009 |
Bangkok, Thailand |
May 4 May 6 |
EuroDjangoCon 2009 |
Prague, Czech Republic |
May 4 May 6 |
SYSTOR 2009---The Israeli Experimental Systems Conference |
Haifa, Israel |
May 4 May 7 |
RailsConf 2009 |
Las Vegas, NV, USA |
May 4 May 8 |
JavaScript/Ajax Bootcamp at the Big Nerd Ranch |
Atlanta, Georgia, USA |
| May 5 |
Linuxwochen Austria - Salzburg |
Salzburg, Austria |
May 6 May 8 |
Embedded Linux training |
Maynard, USA |
May 6 May 9 |
Libre Graphics Meeting 2009 |
Montreal, Quebec, Canada |
| May 7 |
NLUUG spring conference |
Ede, The Netherlands |
May 8 May 9 |
Linuxwochen Austria - Eisenstadt |
Eisenstadt, Austria |
May 8 May 9 |
Erlanger Firebird Conference 2009 |
Erlangen-Nürnberg, Germany |
May 8 May 10 |
PyCon Italy 2009 |
Florence, Italy |
| May 11 |
The Free! Summit |
San Mateo, CA, USA |
May 13 May 15 |
FOSSLC Summercamp 2009 |
Ottawa, Ontario, Canada |
| May 15 |
Firebird Developers Day - Brazil |
Piracicaba, Brazil |
May 15 May 16 |
CONFidence 2009 |
Krakow, Poland |
May 16 May 17 |
YAPC::Russia 2009 |
Moscow, Russia |
May 18 May 19 |
Cloud Summit 2009 |
Las Vegas, NV, USA |
| May 19 |
Workshop on Software Engineering for Secure Systems |
Vancouver, Canada |
May 19 May 21 |
Where 2.0 Conference |
San Jose, CA, USA |
May 19 May 22 |
PGCon PostgreSQL Conference |
Ottawa, Canada |
May 19 May 22 |
php|tek 2009 |
Chicago, IL, USA |
May 19 May 22 |
SEaCURE.it |
Villasimius, Italy |
| May 21 |
7th WhyFLOSS Conference Madrid 09 |
Madrid, Spain |
May 22 May 23 |
eLiberatica - The Benefits of Open Source and Free Technologies |
Bucharest, Romania |
May 23 May 24 |
LayerOne Security Conference |
Anaheim, CA, USA |
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 |
If your event does not appear here, please
tell us about it.
Audio and Video programs
Audio recordings are available for the LibrePlanet conference.
"
The Free
Software Foundation (FSF) today released the complete audio recordings
from the first day of the LibrePlanet GNU/Linux conference, held on
March 21, 2009, in Cambridge, MA.
The recordings include a talk given by Samba's Jeremy Allison on
Microsoft and its relationship with the free software community, and
Gnash developer Rob Savoye announcing the Cygnal project -- a rich
media server with features roughly compatible with the Flash Media
Server. Two members of the autonomo.us group, Evan Prodromou and FSF
director Mako Hill, spoke about efforts to engineer for free network
services and the successful launch of the micro-blogging service
identi.ca."
Full Story (comments: none)
Page editor: Forrest Cook