By Jonathan Corbet
May 21, 2008
As your editor writes, the Fedora development list is the scene of an
extended, heated discussion about Fedora 9. One might think that some
users would be unhappy about the inclusion of KDE 4, say, or maybe
it's an issue with Firefox 3, with its refusal to run older extensions
and persistent
fsync() bug.
It would not be hard to imagine users being upset by the continued presence
of Codeina. In fact, nobody seems to have much to say about those issues.
Instead, a small group of very vocal users is complaining about the X
Window System.
That, too, might not be completely beyond imagination. Your editor can
certainly attest that Rawhide users had more than their share of X-related
fun over the course of the Fedora 9 development cycle. The
interesting thing, though, is that just about all of the problems reported
by Rawhide users got fixed before the final release. So, while
Fedora 9 has a lot of very new X infrastructure, it seems to be
fairly solid infrastructure.
The problem, instead, is that NVIDIA has not shipped a version of its
binary-only graphics driver which works on Fedora 9. These vocal
users feel that the Fedora Project has done them a major disservice by
shipping a release without an NVIDIA-compatible X server. Instead, they
say, Fedora should either have declined to ship a "pre-release" server, or
it should provide a separate set of packages with an older server for
NVIDIA users. NVIDIA seems
to agree:
Fedora 9 is shipping a pre-release X server. If you can't wait for
an updated NVIDIA graphics driver and the limited support provided
in 173.08 graphics driver release is insufficient for your
purposes, please use the X.Org nv driver or fall back to a
supported distribution.
There are a few responses to be made to this set of claims, starting with
the "pre-release" bit. The server is only "pre-release" by a relatively
short period of time, and, more importantly, the ABI for this server
release has been frozen for a few months now. The X developers have made
it clear that the ABI will not change before the 1.5 release ships. So
there's no real reason why NVIDIA could not release a driver if it chose to
do so.
But NVIDIA has not so chosen. More to the point, NVIDIA has implemented a
clear policy of not releasing drivers for a given X version until that
version appears in a stable release by a major distribution. This is a
policy which forces some distributor to ship a version of X which is not
supported by NVIDIA. Criticizing a distribution like Fedora for being the
first one out with a new X version seems misplaced; if one is averse to the
use of new software, there are probably better distributions to be running.
But what about the compatibility packages request? Beyond the inconvenient
fact that putting resources into supporting proprietary software is contrary
to Fedora's policies, that sort of support is expensive to provide. See Adam Jackson's response for a blunt summary of
just how expensive. If Fedora developers start putting their time into
that sort of project, they will be putting less time into making Fedora
itself better. This does not seem like a good tradeoff for Fedora users
who, after all, have chosen a distribution with a "100% free software"
policy.
And, certainly, some Fedora users appreciate the priorities that the developers
have taken:
Well I'm an Intel & Radeon user and Xorg in F9 is dramatically
better better for all my machines. So, yes, if new code improves
life for the open source drivers, lets do this again & again in
future releases. I don't want my desktop experience held hostage by
one company with binary drivers.
In fact, X has gotten significantly better, and it has gotten better more
quickly as a result of Fedora's decision to go with the upcoming release.
Any attempt to maintain compatibility with proprietary drivers would, at
best, slow that progress down significantly.
Users unquestionably have the right to hook binary-only drivers into their
systems. But ensuring that those drivers work with current free software
is their problem - not the free software developers' problem. The use of
proprietary software may have some advantages for some people, but it does
put users at the mercy of the only people who can fix or update that
software: the software's owner. Most developers (most!) do not overtly
wish to make life
difficult for users of binary drivers. But asking them to go out of their
way to shield binary driver users from the decisions made by their vendors
is not just excessive; it actively risks making things worse for free
software users.
Anybody who wants to criticize Fedora can certainly find any number of
valid things to gripe about. Your editor would start with the two
obnoxious PackageKit icons which materialized on the GNOME panel, and
which, it seems, cannot be made to go away without the application of a
fair amount of dynamite. Why does a Rawhide user need a constant reminder
that there are updates available? But the failure to provide an
NVIDIA-compatible X server does not seem like an appropriate thing to
complain about. One should not blame Fedora for being free software.
Comments (23 posted)
By Jake Edge
May 21, 2008
There has been a longstanding complaint about the difficulty in embedding
Mozilla into other applications, but an effort is underway to change that.
Mozilla evangelist Christopher Blizzard is coordinating a group of
interested developers to redefine the application programming interfaces
(APIs), libraries, and
embedding "story" to try to make it easier for other applications. Mozilla
is leading the way, but they want to build a community around embedding, so
they are reaching out to developers that wish to
help guide the effort.
Embedding the Gecko
rendering engine—the guts of Mozilla's web
content handling—will allow separate programs to deal with and use
the web without writing the code themselves. New applications can
leverage all of the work done by Mozilla to handle HTML, CSS, Javascript,
etc. to concentrate on their specific task. There are several embedding use
cases cited on the Mozilla wiki, but the focus of this new effort has
been on applications where handling web content is just part of the task at
hand.
To some extent, this effort is probably being
driven by the rise of
WebKit, which has a specific focus on being embeddable.
WebKit is derived from the KHTML rendering engine—which underlies
Konqueror—as modified by Apple for their Safari browser. There has
been a fair amount of press about WebKit lately, which, along with the
defection of the Epiphany browser from Gecko to WebKit, may have given
Mozilla more motivation to make Gecko more embeddable.
Two meetings have occurred so far to discuss and plan a strategy for
providing better embedding support. Blizzard has a lengthy report from the
first
which goes into some detail about the direction they are headed. The other
was held in early
May, but there are no reports from that as yet. This a young project
that is looking for more interested folks to get involved.
One of the larger complaints about trying to embed Gecko into other
applications is that there are multiple ways to do it. It is difficult for
a developer to know which is right for their application. Blizzard says:
Sometimes you use libxul, sometimes you use the win32 embedding widget,
sometimes you use the gtk embedding widget, sometimes you have to reach
down into internal interfaces to change things and some times you
don't. Having a single story around how to make use of the embedding APIs
on your platform and in your environment is one of our goals.
Another area that needs work is providing a stable API. One of the
downsides to not having stability at the API or application binary
interface (ABI) is that security holes in Gecko tend to cascade throughout all the
other applications that use it. But Blizzard does not expect to nail down
the API right away:
So we will have some iteration during early development and will start
locking things down once we have a better sense of what people [want] and what
we'll need to change internally once we understand about our user's
specific use cases. Stable API is a goal, but it's a longer goal. The more
that we have people help us understand and contribute code out of the gate
the faster we will get here.
The diagram at right gives an overview of how the new API will fit. There
is existing code at both the top and bottom of the diagram, while most the
of the middle is new. Applications will be able to use some of the
embedded functionality through platform-specific APIs—for GNOME,
Windows, or OS X—or write directly to
the new embedding APIs for more capabilities. One of the more interesting
decisions is to use the existing APIs as a model, but not for creating a
fully compatible implementation. Blizzard
explains:
Note that trying to be a drop in replacement to WebKit or MSHTML/WebBrowser
Control is not on the table. Therein lies madness. You end up chasing
compatibility instead of just trying to make something that works really
really well. But we can learn what works well from them and what doesn't
and hopefully apply that to our new embedding interfaces.
The project has started on a roadmap of features that need to be worked on,
beginning with the basics. Reorganizing the libraries and header files to
create a software development kit (SDK) is high on that list. One of the
bigger issues that needs to be addressed is how to handle profiles—the
directory (i.e. $HOME/.mozilla) that Mozilla uses for
user-specific data storage. Some use cases will want to run without a
profile, but the current code expects to always have one available. The
full list in the meeting report is worth a read.
This is an interesting project that should lead to more interesting
applications down the road. The barriers to working with Gecko today are
fairly high, but the advantages to using a well-tested, well-supported,
and reasonably fast rendering
engine for applications that need it are compelling. Those barriers look
to be lowering in the not-too-distant future.
Comments (2 posted)
By Jonathan Corbet
May 20, 2008
Developers in the Debian project had a busy week cleaning up after the
openssl vulnerability was disclosed. Once that was taken care of, they
moved on to process-related issues. Clearly, some shortcomings in how
Debian handles patches to the programs it ships have been revealed; now the
project would like to face those problems and make things work better in
the future. The resulting discussion shows Debian at its introspective
best, and may well have results that other distributors will want to pay
attention to. As a Fedora developer
noted:
"
This bug could easily have been us on the receiving end."
All distributors make changes to their packages, so all of them are
potentially exposed to this kind of failure.
Debian's packaging policy resembles that of most other distributions. A
Debian source package is supposed to contain a tarball of the upstream
source distribution, without changes. Any distribution-specific patches
are included separately and applied when the source package is prepared for
building. There are couple of Debian-specific issues to be faced, though:
- From the discussion, it seems that the "pristine upstream
tarball" rule is occasionally bent by developers. Sometimes there is
no alternative: some upstream source distributions contain material
which, due to its licensing, cannot be shipped by Debian. The
justification for other cases is not always quite as clear.
- Debian's patches are all mashed together and included as a single diff
file. So there is no metadata describing the patches, and they are
difficult to separate from each other. In this regard, Debian differs
from RPM-based distributions, which generally keep each patch separate.
The end result of all this is that Debian's patches are hard for others to
review, hard for upstream projects to consider, and even hard for other
Debian developers to get a handle on.
Raphaël Hertzog started a discussion
on how to improve this situation. A key part of his approach (and an idea
which others have been pursuing as well) is to make changes to the Debian
source package format which would make the nature of each patch explicit.
At a minimum, packagers would include a debian/patches directory
with the source; that directory would contain each patch, broken out into a
separate file. Some Debian packages are built this way already, though the
practice is far from universal.
Beyond that, though, it would be nice to have the source package itself
understand the patch stream and its associated metadata. There are a few
proposals for this; Raphaël favors the "3.0 (quilt)" format, which
keeps the patches (in a separate tarball) as a quilt series. This format
seems to have a certain amount of support; among other things, its
simplicity would make it easy for Debian developers to create packages in
this format without having to learn new tools. The quilt series file -
like the spec file used with RPM packages - makes it clear which patches
must be applied, and in which order.
There are other variants of the 3.0 source package format, though. The
"3.0 (git)" format contains a git repository containing the
upstream source and a series of patches to it. This approach has the
advantage of including the history of the patches along with the other
metadata; it could also, arguably, make it easier for other distributors
(and upstream) to cherry-pick patches of interest. On the other hand, a
git-based package format requires the availability of git and has the
potential to make those packages larger. The GitSrc FAQ has some more
information on this format; there's also a "3.0 (bzr)" format
variant out there.
Any of these new formats, if widely adopted, would bring a new level of
transparency to Debian's patching activities. It would enable the creation
of a "patches.debian.org" site (clearly inspired by patches.ubuntu.com) where anybody
could quickly look at the changes which have been made to any given
package. There are some developers who doubt the utility of this; they
worry that upstream developers won't want to poll a site to see what
changes have been made to their code. One developer at least (GNOME hacker
Vincent Untz) thinks that a
patches.debian.org site would be a step in the right direction, though.
Another quibble which has been heard is that Debian does not need any new
infrastructure for patch management. The right place for patch tracking,
it is said, is with the upstream project. Nobody seems to challenge the
claim that more patches need to go back upstream, but there is also the
fact that quite a few patches will never get there. The upstream
developers for a number of projects seem to have different goals and are
seen by the distribution maintainers as being overtly uncooperative. And
some patches - such as those removing non-free material - may not be
something that even cooperative upstream maintainers want. So there will
always be a need for distribution-specific patches; the "track it upstream"
approach will not solve the whole problem.
Meanwhile, Joey Hess brought a completely different
idea to the discussion: just treat every divergence from upstream as a
bug. Each patch would have a corresponding entry in the Debian bug
tracking system (BTS) with a special tag. Anybody could then query the
list of outstanding bugs, view the patches, and participate in the
associated discussion. Using the BTS brings some real technical
advantages, in that the system already exists. But, Joey says, the real benefit is elsewhere:
The biggest reason for using the BTS is not technical. It's that,
if we decide that the project will treat divergence from upstream
as a bug, then we've effectively decided that maintainers will be
responsible for both minimising unnecessary divergence,
communicating about it to upstream, and for keeping track of what
divergence exists. Because developers are responsible for their
bugs.
A separate patch tracking mechanism, instead, would be a mostly automatic
subsystem on the side which might not bring the same sort of pressure to
bear on developers.
The BTS approach is not universally acclaimed either. Some developers
claim that most Debian-specific patches are not really Debian bugs - they
are, instead, upstream bugs. Regardless of whether that is really true,
distribution bug trackers generally carry a great many entries which, in
the end, describe bugs in upstream packages. Another complaint is that
creating and maintaining BTS entries would be just another bit of
bureaucratic work imposed on Debian developers. Beyond any doubt, some
developers would see it that way.
But this may be a place where a bit more bureaucracy makes some sense. The
Linux distributors of the world (certainly not just Debian) are carrying
thousands of patches against the free programs they distribute. Making the
nature and extent of those patches more readily apparent can only be
beneficial for users, reviewers, distributors, and upstream maintainers.
One clear conclusion from recent events is that all distributors could do
more to let the rest of the community know about the changes they are making.
A distributor's ability to patch a program is a crucial part of the whole
ecosystem - it's the distributors' way of balancing their users' needs
against the upstream maintainer's policies. But distributors should be
clear about the changes they are making, willing to merge those changes
upstream whenever possible, and wanting feedback on those patches. Any
"bureaucracy" which helps to make that happen can only help our community
as a whole in ways that go far beyond the avoidance of another openssl
disaster.
One final note: the existence of source package formats which incorporate
distributed version control system repositories shows that developers have
been thinking about this problem for a while; it's not just a response to
recent events. There is an effort underway to think about what the
intersection of version control and packaging can really achieve for all
distributors; the folks working on this project can be found at vcs-pkg.org. They are working on organizing
a gathering this
September in Extremadura. Vcs-pkg is worth watching; it has the
potential to make things work better for developers and users of all
distributions.
Comments (31 posted)
Page editor: Jonathan Corbet
Security
By Jake Edge
May 21, 2008
Two weeks ago on this page, we reported on some Wordpress
vulnerabilities that were caused by incorrectly generating
authentication cookies. The article was a bit light on details about such
cookies, so this follow-up hopes to remedy that. In addition, Steven
Murdoch, who discovered both of the holes, recently presented
a paper on a new cookie technique that provides some additional
safeguards over other schemes.
HTTP is a stateless protocol which means that any application that wishes
to track multiple requests as a single session must provide its own way to
link those requests. This is typically done through cookies, which are
opaque blobs of data that are stored by browsers. Cookies are sent to the
browser as part of an HTTP response, usually after some kind of
authentication is successful. The browser associates the cookie with the
URL of the site so that it can send the cookie value back to the server on
each subsequent request.
Servers can then use the value as a key into some kind of persistent
storage so that all requests that contain that cookie value are treated as
belonging to a particular session. In particular, it represents that the
user associated with that session has correctly authenticated.
The cookie lasts until it expires or is
deleted by the user. When that happens, the user must re-authenticate to
get a new cookie which also starts a new session. Users find this annoying
if it happens too frequently, so expirations are often quite long.
If the user explicitly logs out of the application, any server-side
resources that are being used to store state information can be freed, but
that is often not the case. Users will generally just close their browser (or
tab) while still being logged in. It is also convenient for users to be
allowed multiple concurrent sessions, generally from multiple computers,
which will cause the number of sessions stored to be larger, perhaps much
larger, than the number of users.
Applications could restrict the number of sessions allowed by a user, or
ratchet the expiration value way down, but they typically do not for user
convenience. This allows for a potential denial of service when an
attacker creates so many sessions that the server runs out of persistent
storage. For this reason, stateless
session cookies [PDF] were created.
Stateless session cookies store all of the state information in the cookie
itself, so that the server need not keep anything in the database,
filesystem, or memory. The data in the cookie must be encoded in such a
way that they cannot be forged, otherwise attackers could create cookies
that allow them access they should not have. This is essentially where
Wordpress went wrong. By not implementing stateless session cookies
correctly, a valid cookie for one user could be
modified into a valid cookie for a different user.
A stateless session cookie has the state data and expiration "in the clear"
followed by a secure hash (SHA-256 for example) of those same values along
with a key known only by the server. When the server receives the cookie
value, it can calculate the hash and if it matches, proceed to use the
state information. Because the secret is not known, an attacker cannot
create their own cookies with values of their choosing.
The other side of that coin is that an attacker can create spoofed
cookies if they know the secret. Murdoch wanted to extend the concept such
that even getting access to the secret, through a SQL injection or other
web application flaw, would not feasibly allow an attacker to create a
spoofed cookie. The result is hardened
stateless session cookies [PDF].
The basic idea behind the scheme is to add an additional field to stateless
session cookies that corresponds to an authenticator generated when an
account is first set up. This authenticator is generated from the password
at account creation by iteratively
calculating the cryptographic hash of the password and a long salt
value.
Salt is a random string—usually just a few characters long—that is added to a password before it gets hashed,
then stored with the password in the clear. It is used to eliminate the use of rainbow tables to crack
passwords. Hardened stateless session cookies use a 128-bit
salt value, then repeatedly calculate HASH(prev|salt), where
prev
is the password the first time through and the hash value from the previous
calculation on each subsequent iteration.
The number of iterations is large, 256 for example, but not a secret. Once
that value is calculated, it is hashed one last time, without the salt, and
then stored in the user table as the authenticator. When the cookie value
is created after a successful authentication, only the output of the
iterative hash itself is placed in the cookie, not the authenticator that
is stored in the database. Cookie verification then must do the standard
stateless session cookie hash verification, to ensure that the values have
not been manipulated, then hash the value in the
cookie to verify against authenticator in the database.
If it sounds complicated, it is; the performance of doing 256 hashes is
also an issue, but it does protect against the secret key being lost.
Because an attacker cannot calculate a valid authenticator value to put
in the cookie (doing so would require breaking SHA-256), they cannot create
their own spoofed cookies.
While it is not clear that the overhead of all of these hash calculations
is warranted, it is an interesting extension to the stateless session
cookie scheme. In his paper, Murdoch mentions some variations that could be used to further
increase the security of the technique.
Comments (3 posted)
Brief items
CentOS looks at the impact of the Debian SSL vulnerability for CentOS
users. "
This vulnerability can affect CentOS machines through the
use of keys that were generated with the OpenSSL package from Debian. For
instance, if a user uses OpenSSH public key authentication to log on to a
CentOS server, and this user generated the key pair with a vulnerable
OpenSSL library, the server is at heavy risk because the key can be
reproduced easily."
Full Story (comments: 26)
Netcraft is reporting a
cross-site scripting (XSS) vulnerability at PayPal. Because PayPal uses the Extended Validation SSL certificate, the abuse potential is somewhat higher as we
described in an article in March. "
Harry Sintonen discovered the vulnerability and announced it to other web application security specialists in an Internet Relay Chat (IRC) channel today. Sintonen told Netcraft that the issue was critical, adding that, 'you could easily steal credentials,' and, 'PayPal says you can trust the URL if it begins with https://www.paypal.com,' which is not true in this case."
Comments (6 posted)
New vulnerabilities
Django: cross-site scripting
| Package(s): | Django |
CVE #(s): | CVE-2008-2302
|
| Created: | May 21, 2008 |
Updated: | May 21, 2008 |
| Description: |
The Django administration application suffers from a cross-site scripting and JavaScript-injection vulnerability. |
| Alerts: |
|
Comments (none posted)
gnutls: several vulnerabilities
| Package(s): | gnutls |
CVE #(s): | CVE-2008-1948
CVE-2008-1949
CVE-2008-1950
|
| Created: | May 20, 2008 |
Updated: | September 17, 2008 |
| Description: |
From the Red Hat advisory: Flaws were found in the way GnuTLS handles malicious client connections. A malicious remote client could send a specially crafted request to a service using GnuTLS that could cause the service to crash. |
| Alerts: |
|
Comments (none posted)
kernel: multiple vulnerabilities
| Package(s): | kernel |
CVE #(s): | CVE-2008-2136
CVE-2008-2148
|
| Created: | May 15, 2008 |
Updated: | January 8, 2009 |
| Description: |
The kernel has several denial of service vulnerabilities. From the
secunia report:
1) An error exists in the implementation of the "sys_utimensat()" system call. This can be exploited to update the access or modification time of arbitrary files via specially crafted arguments passed to the affected system call.
2) A memory leak exists in the "ipip6_rcv()" function included in the IPv6 over IPv4 (SIP) tunneling driver. This can be exploited to potentially exhaust all available memory via specially crafted network packets. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2007-6282
CVE-2007-6712
|
| Created: | May 20, 2008 |
Updated: | August 27, 2008 |
| Description: |
From the Red Hat advisory: The possibility of a kernel crash was found in the Linux kernel IPsec protocol implementation, due to improper handling of fragmented ESP packets. When an attacker controlling an intermediate router fragmented these packets into very small pieces, it would cause a kernel crash on the receiving node during packet reassembly. (CVE-2007-6282) Also, on 64-bit architectures, the possibility of a timer-expiration value
overflow was found in the Linux kernel high-resolution timers functionality, hrtimer. This could allow a local unprivileged user to setup
a large interval value, forcing the timer expiry value to become negative,
causing a denial of service (kernel hang). (CVE-2007-6712) |
| Alerts: |
|
Comments (none posted)
libxslt: code execution
| Package(s): | libxslt |
CVE #(s): | CVE-2008-1767
|
| Created: | May 21, 2008 |
Updated: | August 1, 2008 |
| Description: |
From the Red Hat advisory: Anthony de Almeida Lopes reported the libxslt library did not properly
process long "transformation match" conditions in the XSL stylesheet files.
An attacker could create a malicious XSL file that would cause a crash, or,
possibly, execute and arbitrary code with the privileges of the application
using libxslt library to perform XSL transformations. |
| Alerts: |
|
Comments (none posted)
peercast: buffer overflow
| Package(s): | peercast |
CVE #(s): | CVE-2008-2040
|
| Created: | May 21, 2008 |
Updated: | July 22, 2008 |
| Description: |
The peercast streaming server suffers from a buffer overflow which can be exploited by a remote attacker. |
| Alerts: |
|
Comments (none posted)
phpGedView: privilege escalation
| Package(s): | phpgedview |
CVE #(s): | CVE-2008-2064
|
| Created: | May 20, 2008 |
Updated: | May 21, 2008 |
| Description: |
From the Debian advisory: It was discovered that phpGedView, an application to provide online access to genealogical data, allowed remote attackers to gain administrator privileges due to a programming error. |
| Alerts: |
|
Comments (none posted)
setroubleshoot: symlink and HTML injection vulnerabilities
| Package(s): | setroubleshoot |
CVE #(s): | CVE-2007-5495
CVE-2007-5496
|
| Created: | May 21, 2008 |
Updated: | May 21, 2008 |
| Description: |
The setroubleshoot utility, used by system administrators to diagnose SELinux-related problems, suffers from symbolic link (file overwrite) and HTML injection vulnerabilities. |
| Alerts: |
|
Comments (none posted)
vsftpd: denial of service
| Package(s): | vsftpd |
CVE #(s): | CVE-2007-5962
|
| Created: | May 21, 2008 |
Updated: | June 6, 2008 |
| Description: |
The vsftpd daemon suffers from a memory leak, leading to a denial of service vulnerability. |
| Alerts: |
|
Comments (none posted)
Page editor: Jake Edge
Kernel development
Brief items
The current 2.6 development kernel is 2.6.26-rc3,
released by Linus on
May 18. Lots of fixes, of course, and things are stabilizing (though
the
list of regressions
remains long). Linus also notes that the kernel developers have now been
using git for as long as they used BitKeeper - but there's a lot more
developers now. As always, the
long-format
changelog has the details.
As of this writing, almost 300 changesets have been merged into the
mainline git repository since 2.6.26-rc3. They include a new test driver
for MMC memory cards, a new device_create_drvdata() function
(intended to fix a race condition caused by the previous separation of
device_create() and dev_set_drvdata()), a USB wireless
device management driver, and a lot of fixes.
The current stable 2.6 kernel is 2.6.25.4, released on May 15. It
contains a fairly long list of fixes, a couple of which are
security-related.
Comments (none posted)
Kernel development news
So you can either try to drink from the firehose and inevitably be
bitched about because you're holding something up or not giving
something the attention it deserves, or you can try to make sure
that you can let others help you. And you'd better select the "let
other people help you", because otherwise you _will_ burn out. It's
not a matter of "if", but of "when".
--
Linus Torvalds on git workflows (worth
reading in its entirety)
I have spoken with engineers both individual and within companies
who have developed and who plan to develop substantial kernel
features. I'm forever explaining to people why they should work to
get that code merged up. One reason for their not yet having done
so which comes up again and again is apprehension at the reception
they will receive. In public. This problem appears to be
especially strong in Asian countries. You have just made the
situation worse.
But it's not just a self-interest thing. It is inevitably and
unavoidably the case that when one senior kernel developer acts
like an arrogant hostile dickhead, we will all be increasingly
regarded as arrogant hostile dickheads.
--
Andrew Morton
I suppose alternately I could send another patch to remove
"remember that ext3/4 by default offers higher data integrity
guarantees than most." from Documentation/filesystems/ext4.txt ;)
--
Eric Sandeen
Comments (2 posted)
By Jake Edge
May 21, 2008
A steady stream of random events allows the kernel to
keep its entropy pool stocked up, which in turn allows processes to use the
strongest random numbers that Linux can provide. Exactly which events
qualify as random—and just how much randomness they
provide—is sometimes difficult to decide. A recent move to eliminate
a source of
contributions to the entropy pool has worried some, especially in the embedded
community.
The kernel samples unpredictable events for use in generating random
numbers, storing that data in the entropy pool. Entropy is a measure of
the unpredictability or randomness of a data set, so the kernel estimates
the amount of entropy each of those events contributes to the pool.
Many kernels run on hardware that is lacking some of the
traditional sources of entropy. In those cases, the timing of interrupts
from network
devices has been used as a source of entropy, but it has always been
controversial, so it was recently proposed for removal.
Two of the best sources of random data for the entropy pool—user interaction via a
keyboard or mouse and disk interrupts—are often not present in embedded
devices. In addition, some disk interfaces, notably ATA, do not add
entropy, which extends the problem to many "headless" servers. But network
interrupts are seen as a dubious source of entropy because they may be able
to be observed, or manipulated, by an attacker. In addition, as network
traffic rises, many network drivers turn off receive interrupts from the
hardware, allowing the kernel to poll periodically for incoming packets.
This would reduce entropy collection just at the time when it might be needed for
encrypting the traffic.
This is not the first time eliminating the IRQF_SAMPLE_RANDOM flag
from network drivers has come up; we looked at the issue two years
ago (though the flag was called SA_SAMPLE_RANDOM at that time).
It has come up again, starting with a query on linux-kernel from
Chris Peterson: "Should network devices be allowed to contribute
entropy to /dev/random?" Jeff Garzik, kernel network device driver
maintainer, answered: "I tend to push people to /not/ add
IRQF_SAMPLE_RANDOM to new drivers,
but I'm not interested in going on a pogrom with existing code."
For anyone that is interested in such a pogrom, Peterson proposed a
patch to
eliminate the flag from the twelve network drivers that still use it.
This sparked a long discussion on how to provide entropy for those devices
that do not have anything else to use. While the actual contribution of
entropy from network devices is questionable, mixing that data into the
pool does not harm it, as long as no entropy credit—the current
estimate of entropy in the pool—is awarded.
Alan Cox proposed a new flag to track sources
like that:
A more interesting alternative might be to mark things like network
drivers with a new flag say IRQF_SAMPLE_DUBIOUS so that users can be
given a switch to enable/disable their use depending upon the environment.
Some were in favor of an approach like this, but Adrian Bunk notes that:
If he can live with dubious data he can simply use /dev/urandom .
If a customer wants to use /dev/random and demands to get dubious data
there if nothing better is available fulfilling his wish only moves
the security bug from his crappy application to the Linux kernel.
Part of the problem stems from a misconception about random numbers
gotten from /dev/random versus those that are read from
/dev/urandom, which we described in a Security page
article last December. In general, applications should read from
/dev/urandom. Only the most sensitive uses of random
numbers—keys for GPG for example—need the entropy guarantee
that /dev/random provides. In a system that is getting regular
entropy updates, the quality of the random numbers from both sources is the same.
There is still an initialization problem for some systems, though, as Ted
Ts'o points out:
Hence, if you don't think the system hasn't run long enough to collect
significant entropy, you need to distinguish between "has run long
enough to collect entropy which is causes the entropy credits using a
somewhat estimation system where we try to be conservative such that
/dev/random will let you extract the number of bits you need", and
"has run long enough to collect entropy which is unpredictable by an
outside attacker such that host keys generated by /dev/urandom really
are secure".
A potential entropy source, even for embedded systems, is to sample
other kernel and system parameters that are not predictable externally.
Garzik suggests:
EGD demonstrates this, for example:
http://egd.sourceforge.net/ It
looks
at snmp, w, last, uptime, iostats, vmstats, etc.
And there are plenty of untapped entropy sources even so, such as reading
temperature sensors, fan speed sensors on variable-speed fans, etc.
Heck, "smartctl -d ata -a /dev/FOO" produces output that could be hashed
and added as entropy.
Another source is from hardware random number generators. The kernel
already has support for some, including the VIA
Padlock that seems to be well thought of. Not all processors have such
support, however. The Trusted
Platform Module (TPM) does have random number generation and is
becoming more widespread, especially in laptops, but there is no kernel
hw_random driver for TPM.
Garzik advocates adding a kernel driver for what he calls the "Treacherous
Platform Module", but as others pointed out, it can all be done in user
space using the TrouSerS
library. Even for the hardware random number generators that are supported
in the kernel there is no automatic entropy collection, as it is left up to
user space to decide whether to do that. This is done to try and keep
policy decisions about the quality of the random data out of kernel code.
Systems that wish to sample that data should use rngd to feed the
kernel entropy pool. rngd will apply FIPS 140-2 tests to
verify the randomness of the data before passing it to the kernel. Andi
Kleen is not in favor of that approach:
Just think a little bit: system has no randomness source except the
hardware RNG. you do your strange randomness verification. if it fails
what do you do? You don't feed anything into your entropy pool and all
your random output is predictable (just boot time) If you add anything
predictable from another source it's still predictable, no difference.
There is concern that some of the hardware random number generators are
poorly implemented or could malfunction, so it would be dangerous to
automatically add that data into the pool. Doing the FIPS testing in the
kernel is not an option, leaving it up to user space applications to make
the decision. There is nothing stopping any superuser process from adding bits
to the entropy pool—no matter how weak—but the consensus is that the
kernel itself must use sources it knows it can trust.
Another instance of this problem—in a different guise—appears in a discussion about random numbers for virtualized I/O, with Garzik asking: "Has anyone yet written a "hw" RNG
module for virt, that reads the host's
random number pool?" Rusty Russell responded with a patch for a virtio "hardware"
random number generator as well as one that adds it into his lguest
hypervisor. The lguest patch reads data from the host's
/dev/urandom,
which is not where H. Peter Anvin thinks it
should come from:
There is no point in feeding the host /dev/urandom to the guest (except
for seeding, which can be handled through other means); it will do its
own mixing anyway. The reason to provide anything at all from the host
is to give it "golden" entropy bits.
The virtio implementation only provides the hw_random
implementation, thus it requires user space help to get entropy data into
the kernel. Much like any process that can read /dev/random,
lguest could exhaust the host entropy pool, so there was some discussion of
limiting how much random data guests can request from the device. A guest
implementation could then use a small pool of entropy read from the host to
seed its own random number generator for the simulated hardware device.
Removing the last remaining uses of IRQF_SAMPLE_RANDOM in network
drivers seems likely, though some way to mix that data into the entropy
pool without giving it any credit is still a possibility. With luck, that
will encourage more effort into incorporating new sources of entropy using
tools like EGD or, for systems that have it available, random number
hardware. For systems that lack the traditional entropy sources, this
should lead to a better initialized and fuller pool, while eliminating a
potential attack by way of network packet manipulation.
Comments (33 posted)
By Jonathan Corbet
May 21, 2008
Last week's big kernel lock
article discussed a BKL-related performance regression and concluded
that we would likely see a new interest in its elimination. In the
intervening week, that interest has indeed come to the fore. There are now
a couple of different efforts afoot to get rid of this long-lasting lock.
One might well wonder why the BKL is so persistent. Over the last
(approximately) fifteen years, thousands of locks have been added to the
kernel, pushing the BKL into increasingly obscure corners. But there are a
lot of those corners, including a great many explicit
lock_kernel() calls, the open() method for every char
device, most ioctl() implementations, all fasync()
implementations, and more. The BKL can be found throughout the kernel, and
doesn't appear ready to go without a fight.
Part of the problem is simply that locking is hard. So going in and
changing the locking of some crufty, old driver is not at the top of the
list for a lot of developers, who would generally rather be creating crufty
new drivers. Beyond that, though, the BKL is special. It was originally
created to be more than just a locking primitive; its purpose is to allow
BKL-covered code to pretend that it is still running on an old,
uniprocessor system. So its semantics are very different from any other
lock in the Linux kernel.
For example, the BKL nests, so programmers can add lock_kernel()
calls anywhere without worrying about whether the BKL might already have
been acquired elsewhere. As with a mutex, code holding the BKL can sleep;
however, the scheduler will magically release the BKL until the holding
thread wakes up again. So there can be various threads in kernel space,
all of which think they hold the BKL, but only one of them will actually be
running at any given time. The end result is that it is hard to get a
handle on what is happening with the BKL at any given time; code can depend
on it without ever really being aware of its existence.
As Ingo Molnar put it in his kill
the BKL tree announcement:
Furthermore, the BKL is not covered by lockdep, so its dependencies
are largely unknown and invisible, and it is all lost in the haze
of the past ~15 years of code changes. All this has built up to a
kind of Fear, Uncertainty and Doubt about the BKL: nobody really
knows it, nobody really dares to touch it and code can break
silently and subtly if BKL locking is wrong.
That doesn't mean that people aren't willing to try; Ingo's tree - to which
we will return shortly - is a major
effort in that direction. But first,
consider another initiative which, somewhat accidentally, turned up an
example of just how subtle BKL-related issues can be. As was mentioned
above, the kernel grabs the BKL whenever a process opens a char device; the
BKL is held while the associated driver's open() function runs.
To eliminate BKL, one must remove this particular use of it; one cannot
just take it out, however, without breaking every driver which does not
have proper locking internally. So, in fact, this lock_kernel()
call cannot be removed until every driver's open() function has
been audited and, if necessary, fixed. That's a big flag day.
An alternative, which your editor rashly jumped into doing, is to push the
acquisition of the BKL down one level. Every open() function is
forced to be correct through the addition of explicit
lock_kernel() and unlock_kernel() calls; once all of the
in-tree drivers have been fixed in this way, the higher-level call in
chrdev_open() can be removed. This work may seem like a step
backward, in that it replaces a single lock_kernel() call with
approximately 100 others. But it's actually a big step forward, in that
each driver can now be audited and fixed independently. This work has now
been done, the resulting tree is in linux-next, and, if all goes well, it
should be ready for 2.6.27.
While doing this work, though, your editor noticed quite a few drivers with
open functions that were either completely empty (all they do is
"return 0") or they do something relatively trivial. These
functions, one would think, do not need to acquire the BKL; they touch no
global resources and cannot possibly race with any other part of the
kernel. In fact, as was suggested by others, the empty open()
functions could just be removed altogether.
It was Alan Cox who pointed out that life
is not quite so simple. Under the current regime, an open function which
looks like this:
static int empty_open(struct inode *inode, struct file *filp)
{
return 0;
}
is really better modeled as this:
static int empty_open(struct inode *inode, struct file *filp)
{
lock_kernel();
unlock_kernel();
return 0;
}
These two may seem the same, but there is a crucial difference: in the
second form, empty_open() will not return until it can acquire the
BKL. In other words, after empty_open() runs, one knows that the BKL became available
at least once. And this matters: a classic device driver error is to
(1) register a device with the kernel, then (2) initialize all of
the internal data structures needed to manage that device. Should some
other process attempt to open and use the device between those two steps,
unpleasant things can happen. The lock_kernel() call in the
open() function, despite protecting no critical section directly,
serializes the opening of the device with the driver's initialization, and
thus prevents mayhem. So, says Alan,
I think it would be best to make them lock/unlock kernel in the
first pass and then work through them. The BKL can be subtle and
evil, but as I brought it into the world I guess I must banish it
;)
Alan will not be alone in that effort, though, and Ingo Molnar's "kill the
BKL" tree is likely to help this work considerably. Ingo's approach is to
get rid of most of the features which make the BKL special. So, with his
patches, the BKL becomes just another mutex which, crucially, can be
tracked with the lock
validator. It is no longer released when a thread calls
schedule(), a change which forced the addition of a few explicit
"release, schedule, and reacquire" changes in code which would otherwise
deadlock. There's a number of warnings added to point out calls made
holding the BKL which should not be. And so on.
This patch set, in essence, removes the BKL entirely, replacing it with
just another big lock which happens to do nesting. And the nesting might
go too at some point. So the BKL becomes more visible and easier to
understand. And, presumably, easier to eliminate.
Linus likes this approach, though he would
like to see it reworked to the point that it can be merged into the
mainline relatively soon. Doing that would require putting most of the
changes behind a configuration option decorated with a sufficient number of
scary warnings; then people who wanted to test this code could turn it on
and see what explodes. The number of explosions would probably be
relatively small - but probably not zero.
This set of changes, along with the other work being done, suggests that
significant progress toward the elimination of the BKL can be expected over
the next few kernel development cycles. Once it's gone, we'll have a
kernel without legacy locking issues, and without the unpleasant
performance issues that the BKL can bring. That will still take a while,
though; there is simply no substitute for actually looking at all the
BKL-covered code and ensuring that it will run safely in the absence of
that protection. It's a painstaking job requiring moderate skills which
can only be rushed so much.
Comments (2 posted)
By Jonathan Corbet
May 21, 2008
Journaling filesystems come with a big promise: they free system
administrators from the need to worry about disk corruption resulting from
system crashes. It is, in fact, not even necessary to run a filesystem
integrity checker in such situations. The real world, of course, is a
little messier than that. As a recent discussion shows, it may be even
messier than many of us thought, with the integrity promises of
journaling filesystems being traded off against performance.
A filesystem like ext3 works by maintaining a journal on a dedicated
portion of the disk. Whenever a set of filesystem metadata changes are to
be made, they are first written to the journal - without changing the rest
of the filesystem. Once all of those changes have been journaled, a
"commit record" is added to the journal to indicate that everything else
there is valid. Only after the journal transaction has been committed in
this fashion can the kernel do the real metadata writes at its leisure;
should the system crash in the middle, the information needed to safely
finish the job can be found in the journal. There will be no filesystem
corruption caused by a partial metadata update.
There is a hitch, though: the filesystem code must, before writing the
commit record, be absolutely sure that all of the transaction's information
has made it to the journal. Just doing the writes in the proper order is
insufficient; contemporary drives maintain large internal caches and will
reorder operations for better performance. So the filesystem must
explicitly instruct the disk to get all of the journal data onto the media
before writing the commit record; if the commit record gets written first,
the journal may be corrupted. The kernel's block I/O subsystem makes this
capability available through the use of barriers; in essence, a barrier forbids the
writing of any blocks after the barrier until all blocks written before the
barrier are committed to the media. By using barriers, filesystems can
make sure that their on-disk structures remain consistent at all times.
There is another hitch: the ext3 and ext4 filesystems, by default, do not
use barriers. The option is there, but, unless the administrator has
explicitly requested the use of barriers, these filesystems operate
without them - though some distributions (notably SUSE) change that default.
Eric Sandeen recently decided that this was not the best situation, so he
submitted a patch changing
the default for ext3 and ext4. That's when the discussion started.
Andrew Morton's response tells a lot about
why this default is set the way it is:
Last time this came up lots of workloads slowed down by 30% so I
dropped the patches in horror. I just don't think we can quietly
go and slow everyone's machines down by this much...
There are no happy solutions here, and I'm inclined to let this dog
remain asleep and continue to leave it up to distributors to decide
what their default should be.
So barriers are disabled by default because they have a serious impact on
performance. And, beyond that, the fact is that people get away with
running their filesystems without using barriers. Reports of ext3
filesystem corruption are few and far between.
It turns out that the "getting away with it" factor is not just luck. Ted
Ts'o explains what's going on: the journal
on ext3/ext4 filesystems is normally contiguous on the physical media. The
filesystem code tries to create it that way, and, since the journal is
normally created at the same time as the filesystem itself, contiguous
space is easy to come by. Keeping the journal together will be good for
performance, but it also helps to prevent reordering. In normal usage, the
commit record will land on the block just after the rest of the journal
data, so there is no reason for the drive to reorder things. The commit
record will naturally be written just after all of the other journal log
data has made it to the media.
That said, nobody is foolish enough to claim that things will always happen
that way. Disk drives have a certain well-documented tendency to stop
cooperating at inopportune times. Beyond that, the journal is essentially
a circular buffer; when a transaction wraps off the end, the commit record
may be on an earlier block than some of the journal data. And so on. So
the potential for corruption is always there; in fact, Chris Mason has a torture-test program which can make it happen
fairly reliably. There can be no doubt that running without barriers is
less safe than using them.
Anybody can turn on barriers if they are willing to take the performance
hit. Unless, of course, their filesystem is based on an LVM volume (as
certain distributions do by default); it turns out that the device mapper
code does not pass through or honor barriers. But, for everybody else, it
would be nice if that
performance cost could be reduced somewhat. And it seems that might be
possible.
The current ext3 code - when barriers are enabled - performs a sequence of
operations like this for each transaction:
- The log blocks are written to the journal.
- A barrier operation is performed.
- The commit record is written.
- Another barrier is executed.
- Metadata writes begin at some later point.
On ext4, the first barrier (step 2) can be omitted because the ext4
filesystem supports checksums on the journal. If the journal log data and
the commit record are reordered, and if the operation is interrupted by a
crash, the journal's checksum will not match the one stored in the commit
record and the transaction will be discarded. Chris Mason suggests that it would be "mostly safe" to
omit that barrier with ext3 as well, with a possible exception when the
journal wraps around.
Another idea for making things faster is to defer barrier operations when
possible. If there is no pressing need to flush things out, a few
transactions can be built up in the journal and all shoved out with a
single barrier. There is also some potential for improvement by carefully
ordering operations so that barriers (which are normally implemented as
"flush all outstanding operations to media" requests) do not force the
writing of blocks which do not have specific ordering requirements.
In summary: it looks like the time has come to figure out how to make the
cost of barriers palatable. Ted Ts'o seems to
feel that way:
I think we have to enable barriers for ext3/4, and then work to
improve the overhead in ext4/jbd2. It's probably true that the
vast majority of systems don't run under conditions similar to what
Chris used to demonstrate the problem, but the default has to be
filesystem safety.
Your editor's sense is that this particular
dog is now wide awake and is likely to bark for some time. That may
disturb some of the neighbors, but it's better than letting somebody get
bitten later on.
Comments (64 posted)
Patches and updates
Kernel trees
Core kernel code
Development tools
Device drivers
Filesystems and block I/O
Janitorial
Memory management
Networking
Architecture-specific
Security-related
Virtualization and containers
Benchmarks and bugs
Miscellaneous
Page editor: Jonathan Corbet
Distributions
News and Editorials
By Rebecca Sobol
May 21, 2008
A new distribution called Exherbo has
announced its
existence. It's at least partly inspired by Gentoo and has borrowed
some Gentoo code.
Exherbo is not a Gentoo fork in the conventional sense. Although it
shares some code with Gentoo, and although many concepts are similar, and
although many of the people involved were or are Gentoo developers, most
Exherbo code is rewritten from scratch.
Exherbo is not your average distribution, nor does it aspire to be. In
fact, Exherbo is not for users at all. Exherbo is designed to be a
developer's playground. A place to experiment, to innovate, and to break
packages with impunity.
So far there isn't much there. The projects page lists only
two projects so far: Arbor, an exheres-format (the Exherbo package format) repository
for base system and assorted useful packages, and Genesis, which aims to be
a replacement init daemon.
There are two mailing
lists available, the main development list and a commit mailing list.
The source repository has
some packages in git and a few more in subversion. There's a Bugzilla bug tracker too. So there
isn't much yet, but the infrastructure is there to support what may come.
Perhaps the most interesting part of the site for most people is the Planet Exherbo, a typical blog space
for developers to talk about what they are doing, or would like to do, or
whatever. For example you'll find this post [warning, site is currently reported by Firefox 3 as an "Attack Site", content can also be found on the Planet site] by Anders Ossowicki which
explains:
First of all, Exherbo was announced because some elements of it will be
discussed at an upcoming conference. Rather than having a blank page and
let people start various rumors it seemed wise to at least let people
know what was going on. But in an effort not to hype it above what it
was, we didn't hand over all available information and code.
Unfortunately Slashdot picked up the announcement because some tard
decided it would be a great idea to submit it to them. We did not do that
ourselves because, as we state on the website, we have no need for users
at the moment and exherbo won't fulfill users demands for the foreseeable
future. That is not to say exherbo won't ever become useful but we're not
there at the moment. Some very basic things still need to be worked out
properly.
So there it is. Do not download and expect a working distribution. Do not
expect a release of a working distribution any time soon. But if you are a
developer with an itch to scratch, this might be the place to so. Just to
keep it all together, here's the original LWN announcement and all associated
comments.
Comments (2 posted)
New Releases
rPath has announced that rPath Linux 2 is now available. "
rPath
Linux is a base operating system platform on which you easily build
customized virtual or software appliances, or even an entire operating
system of your own. Building on the rPath Linux foundation, use rPath's
tools to create and maintain your own minimal operating system stack, with
"Just Enough OS" to support the applications and services you
include."
Full Story (comments: none)
Novell has
announced
the availability to customers worldwide of SUSE Linux Enterprise 10 Service
Pack 2 (SP2). With this release SP1 goes into a
6-month maintenance period.
Comments (none posted)
The third beta of openSUSE 11.0 is available. "
Over 700 bugs were
fixed since beta 2, more new artwork was added and several new package
versions were includes. The live installation has seen great improvements
and should work flawless now."
Full Story (comments: none)
Fedora Unity has announced the release of the Fedora 9 Everything Spin, for
those who want it all. The
Everything Spin includes
everything available at the time of the release of Fedora 9.
Full Story (comments: 1)
Distribution News
Debian GNU/Linux
In this edition of Bits from the DPL (dated May 15th), Steve McIntyre
points to several interviews, recent delegations, team reviews, Summer of
Code 2008, DebConf, Lenny, and openssl. Click below for all the bits.
Full Story (comments: none)
The Perl5.10 transition has now been completed, with about 400 source
packages in testing getting updates. "
Please also note that this new
perl version is the last major update to the Debian toolchain for
lenny."
Full Story (comments: none)
Fedora
The Cooperative Bug Isolation Project (CBI) is now available for Fedora 9.
CBI is an ongoing research effort
to find and fix bugs in the real world. "
We distribute specially
modified versions of popular open source software packages. These special
versions monitor their own behavior while they run, and report back how
they work (or how they fail to work) in the hands of real users like you.
Even if you've never written a line of code in your life, you can help make
things better for everyone simply by using our special bug-hunting
packages."
Full Story (comments: none)
Gentoo Linux
The Gentoo Foundation has been
reinstated
and returned to good standing by the state of New Mexico, USA. "
This
accomplishment allows other aspects of the foundation's work to proceed
again. The foundation takes care of Gentoo's intellectual property
(copyrights, trademarks) and money. It ensures that nobody violates our
copyrights and trademarks, serves as a place to hold money, and decides
where to devote that money."
Comments (none posted)
New Distributions
GKLinuxOS is based on PCLinuxOS
2007 and comes with lots of applications including OpenOffice.org and other
office software, graphics and drawing, multimedia audio-video programs,
programs for web-browsing, email and chat, and much more. GKLinuxOS 2008
with KDE 3.5.x is available.
Comments (none posted)
Distribution Newsletters
The Ubuntu Weekly Newsletter for May 17, 2008 covers the OpenSSL/OpenSSH
vulnerability, FOSSCamp 2008 Prague, The Art of Release(Mark Shuttleworth),
5-a-day and Loco teams, Linux distro Smack Down(Podcast), Metalinks, what
are those?, Ubuntu on Berlin metro system, Ubuntu featured in
Vermist(Movie), and much more.
Full Story (comments: none)
This edition of
OpenSUSE Weekly
News covers Linuxtag 2008 - latest information, People of openSUSE:
Marcus Hüwe, and much more.
Comments (none posted)
The
DistroWatch
Weekly for May 19, 2008 is out. "
Fedora 9 came out last week as
expected, but the many experimental features and software packages in the
distribution seem to detract some would-be users from upgrading their
distribution. Do you enjoy testing the latest and greatest the Linux
development world has to offer? Then Fedora 9 is for you. Otherwise look
elsewhere. In the news section, Ubuntu's Mark Shuttleworth calls on greater
release synchronisation between the major Linux vendors, Debian struggles
to come to terms with a massive OpenSSL vulnerability, ComputerWold
Australia interviews Ian Murdock, the Sun Microsystems' vice president in
charge of OpenSolaris, and Gentoo succeeds in reinstating Gentoo Foundation
in New Mexico. Also in this issue, an explanation why DistroWatch does not
focus more on GPL violations and other legal topics, and an opinion piece
on the subject of growing mistrust of users towards Canonical and
Ubuntu."
Comments (none posted)
Distribution meetings
Ubuntu Live
2008, originally scheduled for July 21-22, 2008, has been canceled.
"
We are planning to include some Ubuntu content in the O'Reilly Open
Source Convention (OSCON), also happening July 21-25 in Portland,
Oregon."
Comments (none posted)
Newsletters and articles of interest
LinuxDevices has a brief overview and
review of rPath Linux 2.0. "
rPath Linux is a specialized Linux distribution designed for use by ISVs (independent software vendors) wishing to deliver their products as pre-installed hardware appliances, or as 'software appliances.' The latter are pre-configured Linux server stacks suitable for installation by users on real or virtual commodity hardware."
Comments (8 posted)
Distribution reviews
techpark6.com has
a
review of Ubuntu 8.04. "
With such an expansive operating system
like Ubuntu 8.04 you'll likely encounter the gamut of opinions ranging from
praise to unsatisfied complaints. Having used Ubuntu 8.04 since the early
alpha testing period, I can say that I find Ubuntu 8.04 to be one of the
more (if not the most) polished and ready for widespread use Linux
operating systems made to date."
Comments (none posted)
Page editor: Rebecca Sobol
Development
By Forrest Cook
May 21, 2008
Rakarrack
is a new GUI-based application that can turn a Linux machine into
a collection of audio effects for use in the making of music.
The developers include Josep Andreu, Daniel Vidal and
Hernán Ordiales with help from other individuals.
Rakarrack version 0.1.2 was recently
announced,
it appears to be the first public release.
From the project's web page:
Rakarrack is a guitar effects processor for GNU / Linux simple and easy to use but it contains features that make it unique in this field of applications. It contains 10 effects: Linear Equalizer, Parametric Equalizer, Compressor, Distorsion, Overdrive, Echo, Chorus, Phaser, Flanger and Reverb. It integrates a tuner and a MIDI converter (experimental). It can also be handled by an external MIDI controller. The settings designed by the user can be stored in presets and these presets can be used to create banks of effects.
The README file in the source code has some information on the
motivation behind the project:
"This app born after an informal conversation about effects for guitar
over GNU/linux. The major part of this apps are discontinued or simply
not have new versions after few years. Josep Andreu say on the IRC chat
"I can made an app based on the effects set hid[d]en on code of
ZynAddSubFX (by Paul Nasca Octavian). Some time after here is the
result of our work..."
The project
screen shots show the GUI layout and various color schemes.
Compared to a typical hardware audio processor, the GUI has big
advantages over the usual LCD display that most effect units have.
One need not hunt around a pushbutton-controlled memory to view and
change the many adjustable parameters and the system disk provides
nearly unlimited configuration storage possibilities.
To hear Rakarrac in action, listen to the
demo
by Carlos Pino (ogg format).
One might wonder if audio effects processors will soon follow
mobile phones, TiVo-like video recorders and consumer-based audio
recorders in the transition from proprietary operating systems to
Linux-based embedded systems.
Such a system could be put together with a small Linux-compatible
embedded platform, an LCD interface such as
LCDproc
(with the aforementioned UI limitations),
keyboard and audio interfaces and some DSP software similar to
Rakarrac. In the mean time, if you have a need for a versatile
hardware effector and can spare some CPU cycles, Rakarrac may be
an effective solution. The software is available for download
here.
Comments (5 posted)
System Applications
Database Software
The May 18, 2008 edition of the PostgreSQL Weekly News
is online with the latest PostgreSQL DBMS articles and resources.
Full Story (comments: none)
Device Drivers
Version 1.2.2 of ALE Server, an RFID-EPC compliant RFID middleware package,
has been
announced.
"
The staff at logicAlloy is pleased to announce a new release of ALE Server, our open source RFID middleware. This new version has bug fixes related to the default password and linux distributions."
Comments (none posted)
DNS Software
Some projects send out an email to announce a release; others opt for press
releases. Here is
the
press release for Unbound 1.0, a new, BSD-licensed domain name
server intended to compete with Bind. "
Although BIND has been the de
facto choice for DNS servers since the 1980s, a desire to seek an
alternative server that excels in security, performance and ease of use
prompted an effort to develop an open source DNS implementation. Unbound is
the result of that effort."
Comments (13 posted)
Interoperability
Edition number two of the Samba Mashup Report has been
announced.
"
Table of Contents:
1. Samba 3.2.0 Moves closer to Release
2. Bug fix release for Samba 3.0 in the works
3. Developer Interests - Volker Lendecke
4. Samba at Connectathon
5. Samba4 - Fact or Fantasy?
6. Call for submissions and summaries"
Comments (none posted)
Networking Tools
Version 0.0.2 of nfsreplay has been
announced.
"
nfsreplay is a tool to replay Network File System traffic. It can be used for server and client benchmarking under a wide range of workloads. It allows temporal and spatial scaling of the original trace."
Comments (none posted)
The initial release of Putty Terminal Deployer has been
announced.
"
PuTTY Terminal Deployer allows dynamic PuTTY secure shell (SSH) logins to multiple Linux servers. Host, IP addresses and AES encrypted/Base64 encoded passwords are read from a configuration file. All GUI labels are created dynamically from this info."
Comments (none posted)
Version 0.4.0 of pyftpdlib has been announced.
"
Python FTP server library provides an high-level portable interface
to easily write asynchronous FTP servers with Python. Based on asyncore
framework pyftpdlib is currently the most complete RFC-959 FTP server
implementation available for Python programming language.
This new version, aside from fixing some bugs, includes two new
features:
- IPv6 support (as described in RFC-2428).
- The possibility to assume the id of real users when using system
dependent authorizers."
Full Story (comments: none)
Peer to Peer
Version 0.0.2 of DistrPeer has been
announced.
"
DistrPeer is a client to p2p network without any hubs and trackers, in other words, fully decentralized. Each file before sharing is encoded and splitted for keeping in several computers what provide redundant and distributed storing of files."
Comments (none posted)
Web Site Development
A new security fix release of the Django web platform has been
announced.
"
The Django administration application will, when accessed by a user who is not sufficiently authenticated, display a login form and ask the user to provide the necessary credentials before displaying the requested page. This form will be submitted to the URL the user attempted to access, by supplying the current request path as the value of the form's "action" attribute.
The value of the request path was not being escaped, creating an opportunity for a cross-site scripting (XSS) attack by leading a user to a URL which contained URL-encoded HTML and/or JavaScript in the request path."
Comments (none posted)
Miscellaneous
Version 0.9.2 of OpenPanel has been
announced.
"
OpenPanel is a remote server administration and configuration system for Unix-based systems. It offers both an AJAX Web interface and a CLI which allow you to manage users, domains, email, and other hosting-related services.
Added configurable AXFR restrictions for DNS. Fixed handling of MySQL users, hosts and privileges. Fixed handling of Postfix aliases and catch-all forwards. Cleaned up lots of post-installation issues and stray dependencies."
Comments (none posted)
Desktop Applications
Audio Applications
Version 0.1.0 of NASPRO has been announced.
"
NASPRO is a free, powerful, reusable,
modular, real-time capable, thread-safe, scalable, standard-agnostic,
cross-platform framework for digital signal processing, especially
focused on sound processing.
Its main aim is to give audio application developers a full-featured,
yet scalable, high-performance and integrated tool to make use of
virtually any external sound processing component (including, but not
limited to, LADSPA/DSSI, LV2, VST, AudioUnits and DirectX plugins) via
a single, fully transparent and platform-independent API."
Full Story (comments: none)
Desktop Environments
Version 2.23.2 of the GNOME desktop environment has been released.
"
We start the 2.23 development cycle only a few weeks ago, and some
results are already appearing here and there. By results, I mean new
features, new bugs fixes, and also cool new bugs :-) I'd love to see
even more new bugs -- reporting them would help me with my bugzilla
points, but it seems GNOME contributors have this habit of keeping
things stable. Oh, well."
Full Story (comments: none)
Version 2.23.2 of GARNOME, the bleeding edge GNOME distribution, is out.
"
The "Music for the Maases" release.
Hope you enjoy the ride. We are pleased to announce the release of
GARNOME 2.23.2 Desktop and Developer Platform. This is the second
development release on our trip to GNOME 2.24, which will be out in
September."
Full Story (comments: none)
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)
Desktop Publishing
Version 0.4 of pdfposter is available.
"
``Pdfposter`` can be used to create a large poster by building it from
mult[i]ple pages and/or printing it on large media. It expects as input a
PDF file, normally printing on a single page. The output is again a
PDF file, maybe containing multiple pages together building the
poster. The input page will be scaled to obtain the desired size.
This is much like ``poster`` does for Postscript files, but working
with PDF."
Full Story (comments: none)
Interoperability
Version 1.0-rc1 of Wine
has been announced.
Changes include: Bug fixes only, we are in code freeze.
Comments (none posted)
Music Applications
Version 2.5 of jack-keyboard is available.
"
The biggest change is switching from hand-written makefiles to autotools.
This should make packagers' life easier.
jack-keyboard is a virtual MIDI keyboard - a program that allows you to
send JACK MIDI events (play ;-) using your PC keyboard."
Full Story (comments: none)
Version 1.0 jack-smf-utils of has been announced.
"
Jack-smf-utils is a set of two command line utilities - jack-smf-player and jack-smf-recorder - whose purpose is to play and
record MIDI streams from/to Standard Midi Files (i.e. the files with .mid
extension) using JACK MIDI."
Full Story (comments: none)
Version 0.2.0 of ll-plugins, a collection of LV2 plugins, has been announced.
"
The plugins are reasonably simple and could be used as examples or
starting points for hackers who want to write LV2 plugins based on the
frameworks in the lv2-c++-tools package. There are synths, event
processors, simple audio and control manipulators and GUI-based plugins."
Full Story (comments: none)
Version 0.23.0 of NtEd, a musical score editor, is out.
"
New in NtEd 0.23.0:
A unique MIDI IMPORT function:
- recognizes triplets
- distributes the MIDI tracks onto multiple voices per staff"
Full Story (comments: none)
Science
Version 2.3 of the
Modular toolkit for Data Processing (MDP) has been announced, it includes new capabilities and
bug fixes.
"
[MDP] is a Python data processing framework. Implemented algorithms include: Principal Component Analysis (PCA), Independent Component Analysis (ICA), Slow Feature Analysis (SFA), Independent Slow Feature Analysis (ISFA), Growing Neural Gas (GNG), Factor Analysis, Fisher Discriminant Analysis (FDA), Gaussian Classifiers, and Restricted Boltzmann Machines."
Full Story (comments: none)
Web Browsers
The first release candidate for Firefox 3 is now available, with many new features and performance improvements. "
This milestone is focused on testing the core functionality provided
by many new features and changes to the platform scheduled for Firefox
3. Ongoing planning for Firefox 3 can be followed at the Firefox 3
Planning Center, as well as in mozilla.dev.planning and on
irc.mozilla.org in #granparadiso." Click below for more details.
Full Story (comments: 15)
Languages and Tools
C
Version 4.2.4 of GCC, the Gnu Compiler Collection, has been announced.
"
GCC 4.2.4 is a bug-fix release, containing fixes for regressions
in GCC 4.2.3 relative to previous GCC releases."
Full Story (comments: none)
The May 19, 2008 edition of the GCC 4.3.1 Status Report
has been published.
"
The GCC 4.3 branch is open for commits under normal release branch
rules.
GCC 4.3.1 is still not ready for release as the x86 direction flag
issue (36079) needs to be resolved. We have reached consensus to
add a new flag -mcld to allow to work around the kernel bug and to
add a configure option to enable/disable this by default.
The patch from Uros is implementing the -mcld parts but lacks the
configure option part for which no patch exists yet."
Full Story (comments: none)
Caml
The May 20, 2008 edition of the Caml Weekly News
is out with new articles about the Caml language.
Full Story (comments: none)
Java
Version 1.6 of OpenSwing has been
announced, it includes many new capabilities and some bug fixes.
"
OpenSwing is a component library that provides a rich set of advanced graphics components and a framework for developing java applications based on Swing front-end. It can be applied both to rich client applications and Rich Internet Applications."
Comments (none posted)
Lisp
Version 19e of CMU Common Lisp has been announced.
"
This version fixes several ANSI compliance issue, and includes
several more enhancements and bug fixes."
Full Story (comments: none)
Version 2.45of
GNU CLISP
has been announced.
"
This version adds
just-in-time compilation of closures, pre-opening of shared libraries,
foreign pointer introspection, access to versioned library symbols,
new Gray stream functions, and fixes many bugs.
CLISP is one of the most popular and actively maintained open-source
Common Lisp implementations."
Full Story (comments: none)
Perl
Version 0.6.2 of Parrot has been announced.
"
On behalf of the Parrot team, I'm proud to announce Parrot 0.6.2
"Reverse Sublimation." Parrot is a virtual machine aimed at running
all dynamic languages."
Full Story (comments: none)
The May 4-10, 2008 edition of
This Week on perl5-porters is out with the latest Perl 5 news.
Comments (none posted)
Python
Version 0.9.8.2 of Pyrex, a language for writing Python extension modules,
is available.
"
A block of external functions can now be declared nogil at once.
cdef extern from "somewhere.h" nogil: ...
Also some minor nogil-related bugs have been fixed."
Full Story (comments: none)
The May 19, 2008 edition of the Python-URL! is online with
a new collection of Python article links.
Full Story (comments: none)
IDEs
Version 4.1.4 of eric, an IDE for Python and Ruby, is out.
"
It includes a fix for an API change of Qt 4.4, that caused eric4
to crash. Please update immediately."
Full Story (comments: none)
Libraries
Version 0.9.8.2 of Urwid, a console UI library for Python, is out.
"
This is a maintenance release that fixes a number of bugs that
have been found in 0.9.8.1."
Full Story (comments: none)
Page editor: Forrest Cook
Linux in the news
Recommended Reading
Rahul Sundaram
takes a look at
the Guidelines for Free System Distributions. "
I have been spending
the last couple of weeks talking to them about clarifying where exactly
they are drawing the lines on what constitutes a free system beyond just
software and today, FSF just again proved to be quite reasonable by publishing
the free system distribution guidelines based on the Fedora licensing
guidelines. While I just send my detailed list of feedback on these
guidelines and we are not done just yet, I hope this proves to be a useful
document to everyone involved and all hail the pragmatic extremists for
that. The world is just better off with them in it despite all their own
quirks."
Comments (none posted)
Companies
geek.com
mentions the inclusion of the fast-booting Splashtop distribution on
Asus motherboards.
"
DeviceVM, the makers of Splashtop, just made a big announcement though. Their technology will no longer be restricted to the top-shelf motherboards and will see a much wider release. At first it will be featured on Asus P5Q (high-efficiency design, Intel P45 chipset) family of motherboards, starting with the P5Q Deluxe, P5Q-WS, P5Q3 Deluxe, and P5Q-E. Later Splashtop will be featured on all the companys motherboards, over a million units a month."
Comments (1 posted)
CrunchGear
reports that Verizon has joined the LiMo Foundation.
"
Verizon has signed up as the final member on the board of directors of the LiMo Foundation, a group founded by Motorola, NEC, NTT DoCoMo, Panasonic, Samsung, and Vodafone to deliver an open and globally consistent software platform based upon Mobile Linux for use by the whole industry to catalyze next-generation mobile consumer experiences."
Comments (9 posted)
Linux at Work
Red Hat News
takes
a look at a team of soccer playing robots powered by Fedora.
"
The AllemaniACs use Fedora on every machine they have including
desktops, laptops and the systems on the robots. More importantly, much of
the software they need to program and communicate with their machines is
pre-packaged in Fedora. The AllemaniACs are not only using Fedora, the team
has also used its need for specific capabilities to contribute to open
source through Fedora. When the team has found a need for open source
software not found in Fedora already, they work on packaging it, and then
feed that work back into the Fedora community."
Comments (1 posted)
InformationWeek
examines the use of Red Hat Linux by the New York Stock Exchange.
"
Linux has been known to be in use at several New York financial services firms, but few have stepped up to the podium to testify on the value of their implementations. As a result of mergers and acquisitions, the New York Stock Exchange has migrated over the last few years from HP-UX to IBM AIX to Sun Solaris to Linux. NYSE Group CIO Steve Rubinow said the conversion to Linux followed the acquisition of the Euronext exchange in 2007. Unlike some trading companies that suggest Linux is running their secondary systems, Rubinow emphasized that Linux is running the NYSE's mission-critical trading systems."
Comments (12 posted)
Resources
David M. Williams at iTWire
looks at desktop environments, covering what they are and some of the differences between GNOME and KDE. Desktop environments are sometimes a bit of a puzzle for new Linux users; this article should help explain them. "
This perhaps may explain why when we talk about KDE and GNOME its not immediately apparent just whats going on. Anyone who comes from a Microsoft Windows or MacOS world has been brought up with the concept that your operating system has just one look. You might be able to tweak it or apply a few colour schemes and minor themes, but fundamentally Windows looks like Windows anywhere. In the Linux world any number of different looks can apply because the window managers are replaceable."
Comments (6 posted)
Page editor: Forrest Cook
Announcements
Non-Commercial announcements
David A. Wheeler has sent in a pointer to The Digital Standards Organization (
Digistan); "
The Digital Standards
Organization was founded by open standards professionals in 2007 with the
goal of promoting customer choice, vendor competition, and overall growth
in the global digital economy through the understanding, development, and
adoption of free and open digital standards."
Digistan will be presenting The Hague Declaration
on May 21, 2008, to encourage governments to take open standards
seriously. Take a look at the declaration and add your signature if you
agree.
Comments (18 posted)
Red Hat has announced a partnership with Seneca College wherein students
will work with the Fedora project. "
A new grant funds a liaison position within the School of
Computer Studies to work with Fedora Project members to identify
opportunities for student involvement and to guide students as they
integrate into the community. This proven model was developed at Seneca
and will be incorporated into several programs beginning with the
Linux/Unix System Administration (LUX) program, an intense one-year
graduate certificate. Fedora projects will be integrated into academic
coursework, used as major projects, or funded through government grants."
Full Story (comments: none)
The One Laptop Per Child has finally sent out an official communication on
its agreement with Microsoft, which involves the creation of a dual-boot
version of the XO laptop. "
OLPC is substantially increasing its engineering resources and all
software development continues entirely on GNU/Linux. We will continue
to work to make Sugar on Linux the best possible platform for education
and to invest in our expanding Linux deployments in Peru, Uruguay,
Mexico and elsewhere. No OLPC resources are going to porting Sugar to
Microsoft Windows..."
Full Story (comments: 41)
The
Sugar Labs Foundation has
announced its existence. "
Sugar is the core of the XO laptop's human-computer interface; it provides a fun, easy-to-use, social experience that promotes sharing and learning. Sugar Labs will focus on providing a software ecosystem that enhances learning on the XO laptop as well as other laptops distributed by other companies, such as the ASUS Eee PC. Consistent with the OLPC mission to provide opportunities for learning, an independent Sugar Labs Foundation can deliver learning software to other hardware vendors and, consequently, reach more children."
Comments (none posted)
Commercial announcements
Adobe Labs has
announced
a beta release of Flash Player 10.
"
Adobe Flash Player 10, code-named "Astro," introduces new expressive features and visual performance improvements that allow interactive designers and developers to build the richest and most immersive Web experiences. These new capabilities also empower the community to extend Flash Player and to take creativity and interactivity to a new level.
This public prerelease is an opportunity for developers and consumers to test and provide early feedback to Adobe on new features, enhancements, and compatibility with previously authored content."
See the
release notes for more information.
Comments (43 posted)
ActiveState has announced the release of ActivePerl 5.10.0.1003
with new DBD::Oracle functionality.
"
Complete and
ready-to-install, ActivePerl includes core Perl, popular modules, the Perl Package Manager (PPM),
and complete documentation. With over 250,000 downloads each month, ActivePerl remains the
industry-standard for Perl development. ActivePerl is provided free to the community and is
available as a supported and OEM product to enterprises globally."
Full Story (comments: none)
New installers are available for Zenoss Core.
"
Zenoss, Inc., a leading provider of commercial open source network,
systems and applications management software, today announced availability of the Zenoss Core
"Stack," point-and-click installers for leading Linux platforms including Ubuntu Linux, Red Hat's
Enterprise Linux and Fedora Core, CentOS, Debian, OpenSUSE and Novell's SUSE Enterprise."
Full Story (comments: none)
New Books
Pragmatic Bookshelf has published the book
Advanced Rails Recipes
by Mike Clark.
Full Story (comments: none)
O'Reilly has published the book
Java Power Tools
by John Ferguson Smart.
Full Story (comments: none)
O'Reilly has published the book
JavaScript: The Good Parts
by Douglas Crockford.
Full Story (comments: none)
Resources
Coverity, Inc. has announced the availability of the Scan Report on Open
Source Software 2008. "
The Coverity Scan site was developed with
support from the U.S. Department of Homeland Security as part of the
federal government's 'Open Source Hardening Project.' The report is based
on 2 years of analysis of more than 55 million lines of code on a recurring
basis from over 250 popular open source projects with Coverity Prevent, the
industry-leading static source code analysis solution."
Full Story (comments: 30)
Contests and Awards
use Perl has
announced
that nominations for the White Camel award are open.
"
Every year, at OSCON, the White Camels are presented.
If you look at the previous winners, you'll notice that these are mostly unsung heroes, like previous awardee Eric Cholet, the human moderator of so many Perl mailing lists, or Jay Hannah, one of the people running pm.org (if you ever created/maintained a pm group, chances are that Jay walked you through the process).
Some of these people may be well known, like Allison Randal or Randal Schwartz, while others may be complete strangers to at least part of the globe, like Josh McAdams or Jay."
Comments (none posted)
Education and Certification
Several Python and Plone boot camps will take place in North Carolina
during August, 2008.
"
Triangle (NC) Zope and Python Users Group (TriZPUG) is proud to open
registration for our fourth annual ultra-low cost Plone and Python
training camps, BootCampArama 2008".
Full Story (comments: none)
Calls for Presentations
A call for papers has gone out for Hack.lu 2008.
The event will take place in Luxembourg on October 22-24, 2008,
submissions are due by July 1.
"
The purpose of the hack.lu convention is to give an open and free
playground where people can discuss the implication of new technologies
in society.
hack.lu is a balanced mix convention where technical and non-technical
people can meet each others and share freely all kind of information."
Full Story (comments: none)
Upcoming Events
The
Netfilter Workshop 2008
has been announced.
"
Following the lastest successful workshop in Karlsruhe, Germany,
in October 2007. We are happy to announce the next edition in the
workshop series. This year the event will be hosted in Paris, France
from September 29th to October 3rd, 2008."
Full Story (comments: none)
Open Source City
will take place in Liverpool, UK on June 17-22, 2008.
"
Open Source City tips its hat to Liverpools pioneering spirit by offering a programme of workshops, masterclasses, talks and concerts that shed light on the growing impact of Free/Libre Open Source Software on the creative practices of today, in particular in media art and music."
Comments (none posted)
Events: May 29, 2008 to July 28, 2008
The following event listing is taken from the
LWN.net Calendar.
| Date(s) | Event | Location |
May 28 May 31 |
LinuxTag 2008 where .com meets .org |
Berlin, Germany |
May 29 June 1 |
RailsConf 2008 |
Portland, OR, USA |
May 29 May 30 |
SyScan08 Hong Kong |
Hong Kong, China |
May 30 May 31 |
eLiberatica 2008 - The benefits of Open and Free Technologies |
Bucharest, Romania |
June 2 June 5 |
VON.x Europe |
Amsterdam, the Netherlands |
June 3 June 4 |
Nordic Nagios Meet |
Stockholm, Sweden |
June 6 June 7 |
Portuguese Perl Workshop |
Braga, Portugal |
June 6 June 7 |
European Tcl/Tk User Meeting 2008 |
Strasbourg, France |
June 9 June 13 |
Python Bootcamp with David Beazley |
Atlanta, Georgia, USA |
June 10 June 15 |
REcon 2008 |
Montreal, Quebec, Canada |
June 11 June 13 |
kvm developer's forum 2008 |
Napa, CA, USA |
June 16 June 18 |
YAPC::NA 2008 |
Chicago, IL, USA |
June 17 June 22 |
Liverpool Open Source City |
Liverpool, England |
June 18 June 20 |
Red Hat Summit 2008 |
Boston, MA, USA |
June 18 June 20 |
National Computer and Information Security Conference ACIS 2008 |
Bogota, Columbia |
June 19 June 21 |
Fedora Users and Developers Conference |
Boston, MA, USA |
June 22 June 27 |
2008 USENIX Annual Technical Conference |
Boston, MA, USA |
June 23 June 24 |
O'Reilly Velocity Conference |
San Francisco, CA, USA |
June 28 June 29 |
Rockbox Euro Devcon 2008 |
Berlin, Germany |
July 1 July 5 |
Libre Software Meeting 2008 |
Mont-de-Marsan, France |
July 3 July 4 |
SyScan08 Singapore |
Novotel Clarke Quay, Singapore |
| July 3 |
Penguin in a Box 2008: Embedded Linux Seminar |
Herzelia, Israel |
| July 5 |
Open Tech 2008 |
London, England |
July 7 July 12 |
EuroPython 2008 |
Vilnius, Lithuania |
July 7 July 12 |
GUADEC 2008 |
Istanbul, Turkey |
July 14 July 18 |
PHP 5 & PostgreSQL Bootcamp at the Big Nerd Ranch |
Atlanta, USA |
July 18 July 20 |
RubyFringe |
Canada, Toronto |
| July 19 |
Firebird Developers Day |
Piracicaba-SP, Brazil |
July 19 July 25 |
Ruby & Ruby on Rails Bootcamp at the Big Nerd Ranch |
Atlanta, USA |
July 19 July 20 |
LugRadio Live 2008 - UK |
Wolverhampton, United Kingdom |
| July 20 |
OSCON PDXPUG Day |
Portland, OR, USA |
July 21 July 25 |
O'Reilly Open Source Convention |
Portland, OR, USA |
July 21 July 22 |
Ubuntu Live - cancelled |
Portland, Oregon, USA |
July 23 July 26 |
Ottawa Linux Symposium |
Ottawa, Canada |
| July 26 |
PyOhio 2008 |
Columbus, OH, USA |
July 26 July 27 |
EuroSciPy2008 |
Leipzig, Germany |
If your event does not appear here, please
tell us about it.
Audio and Video programs
The Linux Foundation has posted
a series of videos from the Collaboration Summit held in Austin. There's a bunch of interesting stuff there, but, unfortunately, the videos are in Flash format and, thus, will not collaborate well with a lot of Linux systems. The word from the Foundation is that the company hired to do the video work wasn't able to figure out how to produce the final result in an open format.
Comments (3 posted)
Page editor: Forrest Cook