Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for May 29, 2008The Grumpy Editor reviews Claws Mail The Grumpy Editor's guide to graphical email clients was published almost exactly four years ago. At that time, your editor was looking for a client which could replace an MH-based setup which, for all its age, provided a degree of speed and flexibility which was hard to match. Your editor gets a lot of mail - even before lists like linux-kernel are factored in - so there is a real need for a mail client which can process messages without adding even a few seconds of overhead. At that time, none of the clients reviewed were up to the task; it seems that developers of graphical clients value a number of features above speed and flexibility.That review mentioned a client called sylpheed-claws; at that time, this client was being managed as a sort of development branch for sylpheed, with every intent of getting changes back into that system. Since then, sylpheed-claws has evolved into a full fork intended to create an independent application; it's new name is Claws Mail. In 2004, your editor had found sylpheed-claws to be an unstable platform at best; in 2008, it seemed like time to go back and see what the developers had accomplished in the last four years. To that end, Claws Mail 3.4.0 was installed and put through its paces. The good news is that this client has, indeed, stabilized over time. Your editor was unable to make it crash - always a nice feature in a mail client. Many of the features which were under development four years ago are now stable and supported - and, generally, well documented. Claws Mail has come a long way.
Dealing with email is a keyboard-intensive activity. One of your editor's biggest complaints with graphical clients has been the need to switch constantly between the keyboard and the mouse - a transition which breaks focus and steals time. Claws Mail has improved things in this regard, in that a wide variety of actions can be handled without the mouse. And, unlike some other graphical clients, changing the keyboard bindings is easily done. For some simple operations - plowing through a mail folder, reading and deleting messages - Claws Mail can be visibly slow. Working over IMAP does not help, of course, but it is slower than with, for example, Thunderbird. In addition, by default, Claws Mail will not display a message which becomes selected as the result of, say, deleting the message before it. So the cycle of deleting a message and viewing the next one requires two keystrokes or clicks. That particular problem can be configured away, of course. Much of the remaining slowness can be mitigated by turning off the "execute moves and deletes immediately" option - a change which also makes it easier to recover from overzealous "delete finger" reflexes. One common bit of workflow for your editor involves feeding a message to an external program. As a general rule, graphical mail clients do not make this possible, though this feature is almost universal in non-graphical clients. Claws Mail includes the concept of "actions," which are, essentially, external programs which act on messages. This feature almost solves the problem; actions can be set up with quite a bit of flexibility, and they can be bound to keystrokes. But there is no equivalent to the "|" operation provided by textual clients, meaning that it's not possible to pipe a message into an arbitrary command. Claws Mail only passes through the mail headers which are visible on the screen - and there appears to be no way to configure that behavior. HTML mail appears to be an unfortunate fact of life on the contemporary net. Claws Mail will render such mail as text by default; there are also a couple of plugins which can render HTML mail as intended by its sender. It warmed your editor's heart to note that Claws Mail (unlike certain other clients) does not send HTML mail by default. In fact, it lacks the ability to send HTML mail at all. These developers seem to have their priorities in the right place. Offline operation is another nice feature in a mail client. Claws mail has such a feature, but your editor was only able to get it partially working. The client can gather up mail for offline reading, but changes and sending of mail lead to a series of "I can't do this" dialogs. Some more configuration (e.g. setting up a local drafts folder) helps in this regard, but this area looks a bit like a work in progress. There's no end of other features, of course. Claws mail supports encrypted mail, spelling checking, filtering of messages on arrival (with an optional Perl plugin for those especially complicated filtering jobs), a mail template facility, color-labeling of mail, tagging, scoring, watching of threads, and more. There are plugins which will turn on a laptop LED when mail arrives, strip attachments, view PDF files, track RSS feeds, deal with vCalendar messages, etc. There is a complex search mechanism which can do a lot more than just string matches. It is, in summary, a highly capable tool with more features than just about anybody is likely to use. So has your editor made the change? Not yet. Ways around some of the speed issues will have to be found, and it may be necessary to write a plugin to make Claws Mail work with some LWN processes. A few other details need to be made to work correctly. But it can be said that Claws Mail has gotten closer than any other graphical mail client that your editor has tried to date.
In defense of Firefox Normally, one would not expect a posting about a performance-related bug in pre-release software to generate a great deal of interest. But when LWN pointed to a weblog entry describing the Firefox 3 fsync() bug, the result was (at last count) over 90 comments. Clearly something is going on here to stir up this level of conversation. It's not clear that all participants are taking away the right conclusion, though.Firefox 3 uses the sqlite database, as do a number of other applications. In this case, the database is being used to store the user's browsing history; an active user can create quite a bit of database traffic in a short amount of time. As part of updating the database, sqlite will call fsync() to ensure that the data gets to the disk. All fairly normal stuff which shouldn't create trouble for anybody. Except it does create trouble because (1) these fsync() calls are made frequently, and (2) Linux filesystems do not handle fsync() as well as they should. As a result, heavy use of Firefox 3 on a Linux system can cause the system as a whole to perform poorly. It's clearly an issue that the Firefox developers need to fix, even if it's not entirely their fault. And it appears that they do, indeed, plan to fix it. One could argue that Firefox 3 should never have gotten as far as a release candidate with this sort of bug unfixed. The problem was first reported in early March, but the conversation did not get going in earnest until late April. So there was not a whole lot of time to figure out a fix for the release candidate. More justifiably, it could be said that the developers' consideration of shipping the final release with this problem unfixed was insensitive to the needs of Linux users. The notion that they would bless distributors who patched the problem themselves does not help much in this regard. That thought does raise an interesting question, though: what would have happened if Mozilla did not bless a patch, then denied use of the "Firefox" trademark to distributors who fixed the problem anyway? But all of this is moot; it appears that the Firefox developers have decided to do a second release candidate which includes a fix for this problem. The other common complaint has to do with why Firefox is using a relational database in the first place. It is, arguably, a significant bit of bloat for an already large application. The answer from the developers is that a real database is needed to provide the kind of features that Firefox users are asking for. As the discussion on LWN showed, there really are users who want quick access to significant amounts of history. Your editor has, so far, not had his socks knocked off by the "awesome bar," but other users clearly have. There is value in adding features that your users will call "awesome." There is also value, of course, in the creation of a small and fast application. The Firefox developers have had to chart a course between the addition of features and keeping the overall size reasonable, and they have taken grief for their decisions on both sides. One user's bloat is another user's indispensable tool; it's hard to keep everybody happy. But one generally keeps more users happy by including the features they want. Despite all of that, Firefox 3 clearly shows the results of some attention to performance and memory use. Your editor has not done any sort of formal benchmarking, but a few months of use of the beta releases leads to the conclusion that Firefox 3 is more responsive than its predecessor, and that many of the worst memory usage problems have been addressed. It has been a while since the days when regular restarts to combat the effects of memory leaks were required. Firefox will never be a lightweight program - or even a middleweight program - but it does appear that, for now, the monster's growth has been restrained. Firefox 3 also includes greater GTK integration, which has inspired complaints of its own. But better integration with the Linux system has been something users have been requesting for a while. It is hard to fault the developers for trying to satisfy that request. All told, it would appear that the Firefox community is trying to follow through on its promise of better support for Linux users. They seem to be doing what has been asked of them. In so doing, they have produced a new major release which, for whatever faults it may have, is a real improvement on what came before. The development process which helped to rescue the net from proprietary software and standards continues in full swing. There will, beyond doubt, be no shortage of things to criticize the Firefox developers for in the future. But, before we do that, it's worth taking a moment to back off, let them get the 3.0 release out the door, and congratulate them for a job which is truly, in many ways, well done.
Getting the right kind of contributions Most free software projects encourage contributors—it is the rare project that has an overabundance—but contributions vary greatly in quality. Encouraging good submissions, or those likely to lead to useful contributions down the road, is an important part of any project. But it is a delicate balance. It can be difficult to determine the kinds of tasks suitable for new contributors that will lead to more important contributions later. The flip side of that coin is how to handle contributions that appear to lead elsewhere. Just wading through the significant submissions on a large project's mailing list—linux-kernel being an excellent example—is extremely time consuming; adding noise, in the form of less-than-completely-useful patches, only makes that job harder. New contributors generally want to start with something relatively easy, though, which leads to the tension. Discouraging patches that aren't particularly useful in a way that won't chase off prospective kernel hackers is hard. Al Viro's rather intemperate call for discussion of a linux-wanking mailing list on linux-kernel is probably not the right approach. He was responding to a patch that reformatted a kernel header file to line up the arguments. Viro is not known for his diplomatic skills, but he was responding to a problem that he and other kernel hackers see. There is an increasing amount of trivial cleanup work being submitted that is not translating to more substantial, useful contributions later on. In a followup post, Viro explains his concern:
We are getting another self-contained area. Namely, "pick a
pointless mechanical work out of ever-growing pile, do it, learn nothing,
pick more, maybe look into finding new classes of such mindless stuff".
Of course it always had been there; what changes is that now it's not
just a transient state one might hit on the way in to be slightly
embarrassed
about years later. It gets more visible, it gets self-sustained and it
gets more and more sticky - it became a subculture in its own right and
as far as I can see it is offering more and more incentives to stay in it
instead of moving on.
There is a real cost associated with posts to linux-kernel. It is the main communication mechanism for kernel development so those involved need to work through the posts there. David Miller laments the time he spends sorting through it all:
After deleting all of the noise posted here, I'm often too burnt out
to do real work with what's left and just delete that too. :-/
It's worse than the postmaster and list owner mail I process each
day for vger.kernel.org
Wouldn't you like me to instead have the energy left to review some useful patches? The kernel project provides a number of resources for people who are interested in getting involved but don't know where and how to start. The Kernel Newbies effort is specifically designed to help people get started with the kernel by running a wiki, mailing list, and IRC channel that are focused on the needs of, well, newbies. The idea is to provide information and mentoring that will lead to useful contributions to the kernel. A subproject is the Kernel Janitors who focus on cleaning up kernel code:
We go through the Linux kernel source code, doing code reviews, fixing up
unmaintained code and doing other cleanups and API conversions. It is a
good start to kernel hacking.
Both of these efforts are targeted at getting people up to speed so that the kernel as a whole improves. All of the work is important, but there are many other kernel tasks that are not getting done, possibly because contributors are concentrating on cleanups. Andrew Morton has some suggestions for interested folks:
One could understand a developer deciding to write a do-nothing
whitespace patch as a general throat-clearing exercise, but when asked,
I recommend against that. I generally recommend that people just
download and test the latest -rc, linux-next and -mm kernels and build
and run them. Because they surely will find things which need fixing.
Often simple little things like compilation errors, sometimes things
which need a bisection search.
One problem, though, is that much of that work is more difficult than a whitespace cleanup. For those who are interested in getting their name "up in lights"—in the form of a kernel commit message—the trivial patch path appears easier. Responses like Viro's may deter them, but it risks making linux-kernel look like a hostile place that does not encourage new developers. Some extremely important kernel tasks often do get little or no recognition. Submitting detailed bug reports, bisecting the kernel to find the patch that broke things, or testing proposed fixes go unrecognized—at least in the kernel commit log. There have been thoughts of adding tags to the patches that would note these contributions, but no concrete proposal has been made. Two other documentation efforts are underway to assist new kernel developers. Jesper Juhl is working on a Kernel Newbies Guide to be included into the kernel Documentation tree. It may get folded into Documentation/HOWTO or as a separate file, but the idea is to steer folks in the right direction—and away from the kinds of patches that raise the ire of kernel hackers. LWN's Jonathan Corbet also mentioned a longer document he is working on with support from the Linux Foundation that should be ready for review in June. There may be some rudeness or hostility towards new developers on linux-kernel, but it rarely rises to the level seen on the openbsd-misc mailing list last October. In response to a query about a list of less complicated tasks for OpenBSD—similar to what the Linux Kernel Janitors maintain—project leader Theo de Raadt, who is really not noted for his diplomacy, blasts:
Surely they are too busy whining at us for lists, to actually search
for the lists.
I'll say it again more clearly -- all of you whiners just plain suck. We know you'll never write diffs, and it is up to you to prove us wrong. If you don't write diffs, we have a difficult time feeling any loss. This is sort of the extreme end of the "show us the code" attitude, but, in his own inimitable way, de Raadt is reacting to the same problem. It takes time and effort to shepherd new kernel hackers. Spending time mentoring folks who will never end up contributing is a waste; that time is better spent finding, fixing, or adding bugs. As Linux hacker Ted Ts'o puts it:
The real question is whether people who are wanking about whitespace
and spelling fixes in comments will graduate to writing real, useful
patches. If they won't, there's no point to encouraging them.
How does a project determine which newly interested people will end up being useful contributors versus those that will not? It is a difficult problem that warrants some thought. It surely isn't just kernel projects that have it, as any large, high-profile project will have both a fairly high barrier to entry along with some developers who should be discouraged. Obviously there will never be a clear-cut "future contributor" test, but there may be ways to get a better idea. In the meantime, flaming well-meaning folks to a crisp is unlikely to get there. Referring inappropriate patches to Linux Newbies or something similar—on the off chance the person can be redirected—might be a start.
Page editor: Jonathan Corbet Security Attacking network cards When considering the vulnerabilities of a system, the hardware is usually ignored. Software certainly presents the biggest target—fairly easily exploited as we have seen—but a new class of attacks goes directly at the hardware, specifically network cards. The results can range from a permanent denial-of-service to a complete compromise of the card's function. One researcher has overly cutely dubbed this kind of attack "phlashing" because it attacks the firmware on the card, which is typically stored in flash. The basic idea is that an attacker will rewrite the firmware using an image under their control. That image could do any number of fairly nasty things to the card. Two separate researchers have recently reported on their explorations into this type of attack. Arrigo Triulzi's posting to the, evidently private, Robust Open Source mailing list was reported on Ben Laurie's weblog. Rich Smith of HP also gave a talk on his PhlashDance fuzzing tool at the EuSecWest conference. In both cases, network devices were compromised via insecure remote firmware update capabilities. Smith's research focuses on causing permanent denial-of-service through overwriting the firmware, presumably with garbage. At that point, the card will no longer function and may, in fact, no longer be able to be updated—remotely or locally—which turns it into a paperweight. More importantly, no network traffic can use the device, so if it is situated in a critical router, for example, it could affect a large number of systems. A more insidious attack is described by Triulzi. He replaces the firmware with new code, effectively reprogramming the device to do whatever he wants. One of the attacks goes like this:
[...] I've reached my goal of writing a totally transparent firewall bypass
engine for those firewalls which are PC-based: you simply overwrite the
firmware in both NICs and then perform PCI-to-PCI transfers between the two
cards for suitably formatted IP packets (modern NICs have IP "offload
engines" in hardware and therefore can trigger on incoming and outgoing
packets). The resulting "Jedi Packet Trick" (sorry, couldn't resist) fools,
amongst others, CheckPoint FW-1, Linux-based Strongwall, etc. This is of
course obvious as none of them check PCI-to-PCI transfers.
An additional trick, noted by Laurie and others is to use those same techniques to read or write the main memory of the host computer. This could certainly allow sensitive information to leak—or the host itself to be compromised. As Laurie says: "You might even be able to read disk, too, depending on the disk controller." This is truly frightening stuff that is flying under the radar of most network administrators. There are no known attacks in the wild, but it would seem only a matter of time before that happens. This is definitely something to keep an eye on. Other than avoiding vulnerable network hardware—lists of which do not seem to be available from either researcher—there doesn't seem to be much that can be done to deal with phlashing attacks. A properly programmed I/O memory management unit (IOMMU) might alleviate some of the worst cases by disallowing DMA outside of approved ranges, but card vendors need to make updates more difficult. It might be more convenient for an administrator of a large network to update multiple cards across the wire, but the price paid for that convenience seems too high.
Security news Security, Open Source Style The Open Source Software Security community (oss-security) has announced its existence. "This project is an ongoing effort to manage security information in Open Source software by building on the collaborative foundation of the open source model. The purpose of oss-security is to encourage public discussion of security flaws, concepts, and practices in the open source community."
New vulnerabilities emacs: code execution
kernel: denial of service
mtr: stack-based buffer overflow
php libcurl: safe_mode bypass
roundup: permission bypass
samba: buffer overflow
Page editor: Jake Edge
Kernel development Release status Kernel release status The current 2.6 development kernel is 2.6.26-rc4, released on May 26. In addition to the usual fixes, there are quite a few driver updates in various areas: DRI, networking, MMC, USB, watchdog, and IDE. There is also a fix for 32-bit x86 users who have "too much memory" in their machines. "So if you had PAE enabled _and_ a recent enough CPU to have NX, but not recent enough to be 64-bit (or you were just perverse and wanted to run a 32-bit kernel despite having a chip that could do 64-bit and enough memory that you _really_ should have used a 64-bit kernel), you'd get various random program failures with SIGSEGV. It ranged from X not starting up to apparently OpenOffice not working if it did." As always, all the gory details can be found in the long-format changelog.
Kernel development news Quotes of the week
Stress testing is rarely useful here - things like ioctl races you
find by thinking evil thoughts.
-- Alan Cox
The greatest problem, as I see it is that by pouring vitriol like
this on newbies, we're really damaging our reputation as a
community that welcomes newcomers and strangling our necessary
supply of willing volunteers. On the other hand, as a maintainer,
when there's people yelling me at about patches not being included
plus a persistent regressions list and about ten bug reports to
track down, the last thing I want to see within a million miles of
my inbox is a white space fixing patch. The more of these patches
we get, the worse the problem becomes and the shorter and more
inflammatory the responses get. We can't go on like this.
-- James Bottomley
The #1 project for all kernel beginners should surely be "make sure
that the kernel runs perfectly at all times on all machines which
you can lay your hands on". Usually the way to do this is to work
with others on getting things fixed up (this can require
persistence!) but that's fine - it's a part of kernel development.
-- Andrew Morton
Responding to ext4 journal corruption Last week's article on barriers described one way in which things could go wrong with journaling filesystems. Therein, it was noted that the journal checksum feature added to the ext4 filesystem would mitigate some of those problems by preventing the replay of the journal if it had not been completely written before a crash. As a discussion this week shows, though, the situation is not quite that simple.Ted Ts'o was doing some ext4 testing when he noticed a problem with how the journal checksum is handled. The journal will normally contain several transactions which have not yet been fully played into the filesystem. Each one of those transactions includes a commit record which contains, among other things, a checksum for the transaction. If the checksum matches the actual transaction data in the journal, the system knows that the transaction was written completely and without errors; it should thus be safe to replay the transaction into the filesystem. The problem that Ted noticed was this: if a transaction in the middle of the series failed to match its checksum, the playback of the journal would stop - but only after writing the corrupted transaction into the filesystem. This is a sort of worst-of-all-worlds scenario: the kernel will dump data which is known to be corrupt into the filesystem, then silently throw away the (presumably good) transactions after the bad one. The ext4 developers quickly arrived at a consensus that this behavior is a bug which should be fixed. But what should really done is not as clear as one might think. Ted's suggestion was this:
So I think the right thing to do is to replay the *entire* journal,
including the commits with the failed checksums (except in the case
where journal_async_commit is enabled and the last commit has a bad
checksum, in which case we skip the last transaction). By
replaying the entire journal, we don't lose any of the revoke
blocks, which is critical in making sure we don't overwrite any
data blocks, and replaying subsequent metadata blocks will probably
leave us in a much better position for e2fsck to be able to recover
the filesystem.
A bit of background might help in understanding the problem that Ted is trying to solve here. In the default data=ordered mode, ext3 and ext4 do not write all data to the journal before it goes to the filesystem itself. Instead, only filesystem metadata goes to the journal; data blocks are written directly to the filesystem. The "ordered" part means that all of the data blocks will be written before the filesystem code will start writing the metadata; in this way, the metadata will always describe a complete and correct filesystem. Now imagine a journal which contains a set of transactions similar to these (in this order):
Imagine further that the system crashes with those transactions in the journal, but transaction 2 is corrupt. Simply skipping the bad transaction and replaying transaction 3 would lead to the filesystem being most confused about the status of the reused blocks. But just stopping at the corrupt transaction also has a problem: the data blocks created in transaction 3 may have already been written, but, as of transaction 1, the filesystem thinks those are metadata blocks. That, too, leads to a corrupt filesystem. By replaying the entire journal, Ted hopes to catch situations like that and leave the filesystem in an overall better shape. It is, perhaps, not surprising that there was some disagreement with this approach. Andreas Dilger argued:
The whole point of this patch was to avoid the case where random
garbage had been written into the journal and then splattering it
all over the filesystem. Considering that the journal has the
highest density of important metadata in the filesystem, it is
virtually impossible to get more serious corruption than in the
journal.
The next proposal was to make a change to the on-disk journal format ("one more time") turning the per-transaction checksum into a per-block checksum. Then it would be possible to get a handle on just how bad any corruption is, and even corrupt transactions could be mostly replayed. As of this writing, that looks like the approach which will be taken. Arguably, the real conclusion to take from this discussion was best expressed by Arjan van de Ven in an entirely different context: "having a journal is soooo 1999". The Btrfs filesystem, which has a good chance of replacing ext3 and ext4 a few years from now, does not have a journal; instead, it uses its fast snapshot mechanism to keep transactions consistent. Btrfs may, thus, avoid some of the problems that come with journaling - though, perhaps, at the cost of introducing a set of interesting new problems.
Using the firmware loader for static data Some device drivers need firmware to load into the hardware at initialization time. The kernel firmware loader interface exists to support that functionality, but it requires help from user space which may not be available in all environments. David Woodhouse has proposed a patch that would eliminate that requirement so that more drivers can use the firmware loader rather than craft their own solution. Embedded devices will be one of the main users of this ability. Many of those do not have a user space filesystem available at boot time—via initrd or initramfs—but they still need to access firmware images to download to peripherals. The new request_firmware() implementation would allow those devices to link the firmware into the kernel while still using the kernel firmware infrastructure. Woodhouse has an excellent summary of what he is trying to do in the patch posting:
Some drivers have their own hacks to bypass the kernel's firmware loader
and build their firmware into the kernel; this renders those unnecessary.
Other drivers don't use the firmware loader at all, because they always want the firmware to be available. This allows them to start using the firmware loader. A third set of drivers already use the firmware loader, but can't be used without help from userspace, which sometimes requires an initrd. This allows them to work in a static kernel. A driver that has static firmware data, declares it using:
DECLARE_BUILTIN_FIRMWARE("firmware_name", blob);
The firmware_name is used as a key to find the specific firmware
when request_firmware() is called. blob is a pointer to
the actual code. The declaration adds the firmware to the end of an array
holding struct builtin_fw elements, which look like this:
struct builtin_fw {
char *name;
void *data;
unsigned long size;
};
When a call is made to request_firmware(), the new code linearly searches the array for a matching key before calling out to user space. This allows any statically created firmware blobs to take precedence over those in the filesystem. Whichever is found is returned. There seemed to be strong agreement that Woodhouse's approach was the right way to go. His original implementation copied the firmware blob before returning it to a request_firmware() caller which required a vmalloc()—a waste of precious memory on embedded devices. Woodhouse was concerned that some drivers might modify the firmware before loading it into the device. Once he started looking, he found examples of that, but instead of penalizing all devices, he changed the firmware data returned in a struct firmware to be constant, resulting in the following structure:
struct firmware {
size_t size;
const u8 *data;
};
This constitutes an API change for anyone using the request_firmware() interface. In-tree drivers have been modified by Woodhouse appropriately, but out-of-tree drivers need to be aware of the change. Any driver that needs to modify the data must make a copy for themselves. Another feature that would be useful for memory-constrained devices is compression of the firmware in the kernel image. This is on Woodhouse's radar, but is not seen as a feature that must be in the first release. Not copying the data for most drivers is a bigger win, but compression, especially for large firmware images might help. In those cases, though, both the compressed and uncompressed data will be in memory while the driver is downloading it. Getting this work included into 2.6.26 has been discussed, even though the merge window has closed. Woodhouse thinks it might be possible:
Well, it's supposedly too late, but it's dead simple and shouldn't have
much chance of breaking anything, so I suppose as long as we don't
include the korg1212 patch and the rest of the similar patches which
we're still working on, that's not such an insane request.
This is a fairly simple patch that adds some very useful functionality, especially for the embedded community. Woodhouse has recently stepped up as one the kernel embedded maintainers, so we may see more things like this from him in the future. It is unlikely that Linus Torvalds will merge this feature so late in the 2.6.26 cycle, but inclusion into 2.6.27 seems quite probable.
GEM v. TTM Getting high-performance, three-dimensional graphics working under Linux is quite a challenge even when the fundamental hardware programming information is available. One component of this problem is memory management: a graphics processor (GPU) is, essentially, a computer of its own with a distinct view of memory. Managing the GPU's memory - and its view of system RAM - must be done carefully if the resulting system is intended to work at all, much less with acceptable performance.Not that long ago, it appeared that this problem had been solved with the translation table maps (TTM) subsystem. TTM remains outside of the mainline kernel, though, as do all drivers which use it. A recent query about what would be required to get TTM merged led to an interesting discussion where it turned out that, in fact, TTM may not be the future of graphics memory management after all. A number of complaints about TTM have been raised. Its API is far larger than is needed for any free Linux driver; it has, in other words, a certain amount of code dedicated to the needs of binary-only drivers. The fencing mechanism (which manages concurrency between the host CPUs and the GPU) is seen as being complex, difficult to work with, and not always yielding the best performance. Heavy use of memory-mapped buffers can create performance problems of its own. The TTM API is an exercise in trying to provide for everything in all situations; as a result it is, according to some driver developers, hard to match to any specific hardware, hard to get started with, and still insufficiently flexible. And, importantly, there is a distinct shortage of working free drivers which use TTM. So Dave Airlie worries:
I was hoping that by now, one of the radeon or nouveau drivers
would have adopted TTM, or at least demoed something working using
it, this hasn't happened which worries me... The real question is
whether TTM suits the driver writers for use in Linux desktop and
embedded environments, and I think so far I'm not seeing enough
positive feedback from the desktop side
All of these worries would seem to be moot, since TTM is available and there is nothing else out there. Except, as it turns out, there is something out there: it's called the Graphics Execution Manager, or GEM. The Intel-sponsored GEM project is all of one month old, as of this writing. The GEM developers had not really intended to announce their work quite yet, but the TTM discussion brought the issue to the fore. Keith Packard's introduction to GEM includes a document describing the API as it exists so far. There are a number of significant differences in how GEM does things. To begin with, GEM allocates graphical buffer objects using normal, anonymous, user-space memory. That means that these buffers can be forced out to swap when memory gets tight. There are clear advantages to this approach, and not just in memory flexibility: it also makes the implementation of suspend and resume easier by automatically providing backing store for all buffer objects. The GEM API tries to do away with the mapping of buffers into user space. That mapping is expensive to do and brings all sorts of interesting issues with cache coherency between the CPU and GPU. So, instead, buffer objects are accessed with simple read() and write() calls. Or, at least, that's the way it would be if the GEM developers could attach a file descriptor to each buffer object. The kernel, however, does not make the management of that many file descriptors easy (yet), so the real API uses separate handles for buffer objects and a series of ioctl() calls. That said, it is possible to map a buffer object into user space. But then the user-space driver must take explicit responsibility for the management of cache coherency. To that end there is a set of ioctl() calls for managing the "domain" of a buffer; the domain, essentially, describes which component of the system owns the buffer and is entitled to operate on it. Changing the domains (there are two, one for read access and one for writes) of a buffer will perform the necessary cache flushes. In a sense, this mechanism resembles the streaming DMA API, where the ownership of DMA buffers can be switched between the CPU and the peripheral controller. That is not entirely surprising, as a very similar problem is being solved. This API also does away with the need for explicit fence operations. Instead, a CPU operation which requires access to a buffer will simply wait, if necessary, for the GPU to finish any outstanding operations involving that buffer. Finally, the GEM API does not try to solve the entire problem; a number of important operations (such as the execution of a set of GPU commands) are left for the hardware-specific driver to implement. GEM is, thus, quite specific to the needs of Intel's driver at this time; it does not try for the same sort of generality that was a goal of TTM. As described by Eric Anholt:
The problem with TTM is that it's designed to expose one general
API for all hardware, when that's not what our drivers want...
We're trying to come at it from the other direction: Implement one
driver well. When someone else implements another driver and finds
that there's code that should be common, make it into a support
library and share it.
The advantage to this approach is that it makes it relatively easy to create something which works well with Intel drivers. And that may well be a good start; one working set of drivers is better than none. On the other hand, that means that a significant amount of work may be required to get GEM to the point where it can support drivers for other hardware. There seem to be two points of view on how that might be done: (1) add capabilities to GEM when needed by other drivers, or (2) have each driver use its own memory manager. The first approach is, in many ways, more pleasing. But it implies that the GEM API could change significantly over time. And that, in turn, could delay the merging of the whole thing; the GEM API is exported to user space, and, as a result, must remain compatible as things change. So there may be resistance to a quick merge of an API which looks like it may yet have to evolve for some time. The second approach, instead, is best described by Dave Airlie:
Well the thing is I can't believe we don't know enough to do this
in some way generically, but maybe the TTM vs GEM thing proves its
not possible. So we can then punt to having one memory manager per
driver, but I suspect this will be a maintenance nightmare, so if
people decide this is the way forward, I'm happy to see it
happen. However the person submitting the memory manager n+1 must
damn well be willing to stand behind the interface until time ends,
and explain why they couldn't re-use 1..n memory managers.
One other remaining issue is performance. Keith Whitwell posted some benchmark results showing that the i915 driver performs significantly worse with either TTM or GEM than without. Keith Packard gets different results, though; his tests show that the GEM-based driver is significantly faster. Clearly there is a need for a set of consistent benchmarks; performance of graphics drivers is important, but performance cannot be optimized if it cannot be reliably measured. The use of anonymous memory also raises some performance concerns: a first-person shooter game will not provide the same experience if its blood-and-gore textures must be continually paged in. Anonymous memory can also be high memory, and, thus, not necessarily accessible via a 32-bit pointer. Some GPU hardware cannot address high memory; that will likely force the use of bounce buffers within the kernel. In the end, GEM will have to prove that it can deliver good performance; GEM's developers are highly motivated to make their hardware look good, so there is a reasonable chance that things will work out on this front. The conclusion to draw from all of this is that the GPU memory management problem cannot yet be considered solved. GEM might eventually become that solution, but it is a very new API which still needs a fair amount of work. There is likely to be a lot of work yet to be done in this area. (Thanks to Timo Jyrinki for suggesting this topic.)
Patches and updates Kernel trees
Core kernel code
Development tools
Device drivers
Documentation
Filesystems and block I/O
Kernel building
Memory management
Networking
Architecture-specific
Security-related
Virtualization and containers
Benchmarks and bugs
Miscellaneous
Page editor: Jonathan Corbet
Distributions News and Editorials Fedora's Packager Sponsors Responsibility Policy A Linux distribution is really the sum of its packages. The more packages that are available, the more useful it becomes for a wide range of needs. Case in point, Debian has some 20,000 plus packages available to it's users, and to the wide variety of Debian-based distributions.Fedora doesn't have quite as many packages available (yet), but the project hasn't been working at it for nearly as long either. Of course having thousands of packages available is no good if they won't interact well with each other. A distribution isn't just a collection of random binary packages. Packaging guidelines are critical for ensuring that any package you (the user) installs, works well with the rest of your system. Fedora is working toward having an ever growing number of volunteers maintaining an ever growing number of packages, and still having an integrated distribution that works whether you want the "Everything Spin" or one of the highly specialized Spins, or something in between. One part of making that happen is having sponsors for new volunteers, and coming up with a policy to guide these sponsors. A draft version of the Packager Sponsors Responsibility Policy was posted to Fedora-devel late last week. The wiki version contains some additions and clarifications. With the new policy, sponsors are maintainers with a good record of package maintenance and have shown a willingness to review packages and assist others. Sponsors act as mentors for new contributors, as package reviewers and ultimately they are responsible for making sure that bugs are fixed in their sponsored packages. The policy also indicates some conditions where a sponsorship might be revoked:
A maintainer that no longer wishes to contribute to Fedora, a maintainer
that refuses to follow guidelines, or irreconcilable differences between
the maintainer and the Sponsor. In this event it is the responsibility of
the Sponsor to orphan the maintainers packages, and do any other needed
cleanups.
Like all such policies, it will evolve over time, but all in all it is a good start to a policy that should help new maintainers get involved with the Fedora project.
New Releases Red Hat Enterprise Linux 5.2 announced Red Hat Enterprise Linux 5.2 has been released. "Today we released the second update to Red Hat Enterprise Linux 5. As with earlier minor releases, Red Hat Enterprise Linux 5.2 comes with a broad set of bug fixes, updated hardware support capabilities, quality improvements, and a set of new software features that have been backported from upstream open source projects to the Enterprise Linux 5 code base."
Distribution News SUSE Linux and openSUSE Thesis on openSUSE Published The openSUSE News points to a recently published thesis on "Managing Firm-Sponsored Open Source Communities" which details the collaboration between Novell and the openSUSE community. A summary of the study, the full thesis, and pictures are available at Jan Fredrik's Weblog. "Ch 4 Empirical-findings -- From here on we wander into the world of Novell and the openSUSE project. Based largely on interviews with developers, managers and community members, this chapter presents some of the history of the openSUSE project, the software products, the development process and the openSUSE community." (Thanks to Stephan Binner)
New Distributions FAN (Fully Automated Nagios) FAN (Fully Automated Nagios) aims to provide a CD based on CentOS in order to simplify installation of Nagios and other Nagios tools. Tools installed by FAN are: Linux, MySQL, Nagios, Nagios Plugins, NaReTo, NagVis, Centreon, Net-SNMP and NDOUtils. Version 0.3 was recently released.
Freezy Linux Freezy Linux is a free, easy-to-use Linux-based operating system for the home. The initial version, 1.0, is based on Ubuntu 8.04 Hardy Heron and the GNOME desktop environment. It comes as a live CD which can be installed to the hard drive if desired.
RedPost Launches Wicker: A Customized Ubuntu for Digital Signs and Photo Frames RedPost inc. has announced the launch of Wicker, their customized version of Ubuntu that runs on their digital signs. "Eric Kanagy, CEO, led the project to develop Wicker. "We've customized Ubuntu to make it work like a digital sign or photo frame and we figured we may as well offer it to the world. It's nothing too fancy -- it just does what it's supposed to do.""
Distribution Newsletters Ubuntu Weekly Newsletter #92 The Ubuntu Weekly Newsletter for May 24, 2008 covers the Ubuntu Developer Summit Intrepid Ibex, Ubuntu Live canceled, new Ubuntu Membership Approval Boards to meet, new Ubuntu Contributing Developers, a new Launchpad podcast, and much more.
OpenSUSE Weekly News/23 This edition of the OpenSUSE Weekly News looks at openSUSE 11.0 Beta 3, People of openSUSE: Wolfgang Koller, Status Updates, Duncan Mac-Vicar P.: The greatest unknown openSUSE 11.0 package management feature, Lukás Ocilka: Function Keys in YaST ncurses Frontend, andi.opensuse-id.org: KDE 4.0.4 on openSUSE 10.3, and more.
Gentoo Monthly Newsletter: 26 May 2008 This edition of the Gentoo Monthly Newsletter covers Gentoo Foundation reinstated, Council Meeting Summary, upcoming events, an Interview with Google Summer of Code Student Eric Thibodeau, and much more.
DistroWatch Weekly, Issue 254 The DistroWatch Weekly for May 26, 2008 is out. "An interesting week that brought two big enterprise Linux updates (SUSE Linux Enterprise 10 SP2 and Red Hat Enterprise Linux 5.2, both released on the same day) and a number of smaller distribution releases, of which Absolute Linux 12.1, Ultimate Linux 1.8 and TinyMe 2008.0 seem the most impressive. But the big focus of the coming weeks is undoubtedly openSUSE 11.0 - the most innovative Linux distribution release for some time. Do help with testing, though, if you can. In the news section, Paul Frields and Mark Shuttleworth talk to various publications about their respective distributions, CentOS explains why it takes three weeks to build a new version of its distribution, Xubuntu plans to add some of the much-requested features into Intrepid Ibex, and Famelix GNU/Linux receives undue attention from Microsoft's anti-piracy body. Also not to be missed: our first look at OpenSolaris 2008.05 and an update on Zenwalk's package management utility, Netpkg."
Interviews Interview with Fedora Project Leader Paul Frields Softpedia has an interview with Fedora Project Leader Paul Frields covering the release of Fedora 9, plans for Fedora 10, and some thoughts about working with other distributions. "Well, I should point out that FOSS isn't a simple competition; it's more like 'co-opetition' – so adopting an 'us vs. them' attitude ends up being not very constructive or healthy. It's much healthier to build FOSS by having a robust policy for dealing with upstream software communities. The Fedora policy of working closely and vigorously with these upstream groups means we're not just consuming that work, we're contributing to it actively. By comparison, simply creating patches in our own distribution creates a maintenance drag, as well as an uneven experience for FOSS users who work on a number of platforms. Having the software work differently on each distribution doesn't reassure users about how well FOSS works. When we find problems, we send the solutions, via patches and other forms, back to the upstream communities and work with them to get them included where they make sense. That improves FOSS for *everyone*, and not just Fedora."
Distribution reviews Review: Lightweight Linux distributions (Abandoned Zone) From the Abandoned Zone (blog) comes this review/comparison of several lightweight Linux distributions: Arch 2007.08-2, Damn Small Linux 4.2.5, Puppy 4.0, TinyMe Test7-KD, Xubuntu 8.04, and Zenwalk 5.0. "After installation the system was rebooted. Boottime was measured from Grub to Desktop (login information was entered as quickly as possible) and I ran glxgears to see how well my graphics card was working (this was a problem in the past). Than I took a quick look how well the hardware is detected, which default software is installed and how it performs."
Page editor: Rebecca Sobol
Development The Open Graphics Project prepares to release hardware The Open Graphics Project is working to produce an open-hardware PCI graphics card with open-source drivers. The Wikipedia entry for OGP is a good source for information on the project. The OGP project vision is detailed in the About document:
There is a market for graphics hardware with good support for free software and free operating systems (there may or may not be a market for open graphics hardware also, but that is beyond the scope of this project). Such a graphics card would benefit from lower software development cost and mindshare in order to be commercially viable. Free software could benefit from the active cooperation of the manufacturer of such a card to create better drivers and to get a card that better meets the requirements of free software.
Currently, the market for such cards is not served very well. NVIDIA has no offering in this market, ATI's older cards have very limited support, while their new ones have none, and Matrox has no offering in this market either. XGI are off to a good start but still no 3D code yet.
In order to get manufacturers to make such hardware, we have to show that it will be economically viable to do so.
OGP is working with the company Traversal Technology to develop the hardware side of the project, known as the OGD1. OGP recently announced that it is now taking pre-orders for the OGD1 board. The card will initially cost $1500, there will be a $100 discount for the first 100 orders. Larger quantity orders will receive a significant discount. The initial price may seem rather high for a video card when similar mass-produced products can be had for several hundred dollars. This can partly be justified by the fact that the OGD1 is more of a development platform than a commodity video card. The OGD1 is also useful for embedded and stand-alone video products, where commodity parts are not available and custom designs are expensive. Additionally, part of the money raised by selling OGD1 cards will be used to raise funds for OGP. The OGD1 FAQ addresses the price issue: "OGD1 is actually very competitively priced compared to FPGA kits with similar capabilities and capacity. For very small FPGA projects, OGD1 may be over-kill. But for larger projects, OGD1 is a must and a bargain." The OGD1 rev B hardware specs explain the board's features and show a photo of the board. The basic capabilities include a maximum resolution of 2560x1600 pixels, 256MB of 200Mhz video memory, DVI, RGB, S-Video and composite video outputs, a PCI/PCI-X interface and user-specified I/O. A number of commercial video card manufacturers have been warming up to the concept of open-source drivers. For several years, Intel's policy has been to provide free drivers for all of their video products. ATI has released documentation for their Graphical Processing Unit (GPU) and AMD is also supporting open-source drivers. The LWN 2007 kernel summit coverage notes: "Starting with the R500 chipset and going forward, AMD will fully support free drivers for all of its graphics processors. This support will not take the form of a release of the current proprietary ATI driver; that code is not considered to be something that anybody would really want to look at. So there will be a clean start. AMD will release specifications and a skeleton driver with the plan to have 2D support working by the end of the year. The company is clearly hoping that the community will do much of the work on the driver, but it also plans to participate actively in the process." While the OGD1 is somewhat in competition with commercial video card manufacturers, the developers are encouraging the release of more open-source drivers and specification information. According to the OGD1 FAQ: "We applaud ATI for doing the right thing and making available their GPU documentation for use by Free Software developers. There are certain market segments where ATI's offering may affect us, but there are other market segments (e.g. embedded systems, single-board computers, servers, special-purpose, etc.) where our growth potential is entirely unaffected. Moreover, they in no way impact our broader goals of enabling hardware hacking and bringing open hardware to the people." If you are a developer who is wanting to get involved in the development of video card firmware, or you need a well-supported video architecture for an embedded project, the OGD1 could prove to be an effective solution.
System Applications Database Software DbUnit new release 2.2.3 (stable) is out! (SourceForge) Stable release 2.2.3 of DbUnit has been announced. "DbUnit is a JUnit extension targeted for database-driven projects that, among other things, puts your database into a known state between test runs."
pgDesigner 1.2.7 released Version 1.2.7 of pgDesigner, a graphic database design tool, has been announced. "BUG: Fixed a mistake on the version control during the loading of project files. BUG: Fixed a problem of conversion during the loading of field sizes, if they are empty. NDA: Program compiled with version 2.6.0 of Gambas."
PostgreSQL Weekly News The May 25, 2008 edition of the PostgreSQL Weekly News is online with the latest PostgreSQL DBMS articles and resources.
Interoperability Samba 3.0.29 and 3.2.0rc1 released Two new versions of Samba are available. For more information, see the announcements for version 3.0.29 (stable) and version 3.2.0rc1. (development version).
Security OpenSSL 0.9.8h released Version 0.9.8h of OpenSSL has been announced. "The OpenSSL project team is pleased to announce the release of version 0.9.8h of our open source toolkit for SSL/TLS. This new OpenSSL version is a security and bugfix release. For a complete list of changes, please see http://cvs.openssl.org/getfile/openssl/CHANGES?v=1.1238.2... Two moderate severity security flaws have been fixed in OpenSSL 0.9.8h. The OpenSSL security team would like to thank Codenomicon for reporting these issues"
Telecom FeatherChat: 0.1 release! (SourceForge) The initial release of FeatherChat has been announced. "FeatherChat is a low-data web-based chat program targeted to mobile phone users. Users need a phone with data and a browser. To host, it requires a web-server with PHP and has access to a MySQL db. PHP's PEAR mail is required for e-mail notification."
Web Site Development CommSy: 6.1.0 released (SourceForge) Version 6.1.0 of CommSy has been announced, it includes several bug fixes. "CommSy is a webbased community system, originally developed at the University of Hamburg, Germany, to support learning/working communities."
Contineo Document Management System 3.0.3 released (SourceForge) Version 3.0.3 of Contineo has been announced. "Contineo is a Web-Based Document Management System (DMS), written in Java, with a powerful Search Engine (Lucene), Web-Service interface (Axis2), and Versioning. Documents can be organized into hierarchical folders and searched by keywords or using the search engine. This is the second bugfix release for the stable Contineo 3.0 branch."
Desktop Applications Audio Applications Audacious and Audacious-Plugins 1.5.1 released Version 1.5.1 of Audacious and Audacious-Plugins, an audio player, has been announced. "This release mostly contains important bugfixes, but also certain small enhancements".
Desktop Environments GNOME Software Announcements The following new GNOME software has been announced this week:
KDE 4.1 Beta1 Release Announcement The first beta for KDE 4.1 has been announced. "Beta 1 is aimed at testers, community members and enthusiasts in order to identify bugs and regressions, so that 4.1 can fully replace KDE 3 for end users. KDE 4.1 beta 1 is available as binary packages for a wide range of platforms, and as source packages. KDE 4.1 is due for final release in July 2008." See the Info Page, which will be updated as issues are reported.
KDE Commit-Digest (KDE.News) The April 27, 2008 edition of the KDE Commit-Digest has been announced. The content summary says: "In this week's KDE Commit-Digest: Rating support, with a NEPOMUK backend in Gwenview. KStars gets a conjunctions predictor module. Basic XSLT support and a HTML export GUI in Parley. Work on clouds view integration in Marble. Keyboard navigation support in KNetWalk. The start of a new dock window layout in Kooka. Work on tabbed interface user interaction in Dolphin. A paste text snippets applet in Plasma..."
KDE Software Announcements The following new KDE software has been announced this week:
Multi-pointer X is coming The announcement has gone out: the multi-pointer X (MPX) patches (covered here in February) have been merged into the X.org mainline. MPX is the key to a number of interesting new interaction techniques, including collaborative work on a single display and multi-finger touchscreen interfaces. It should be interesting to see what application developers do with this capability.
Xorg Software Announcements The following new Xorg software has been announced this week:
Electronics XCircuit 3.4.29 released Stable version 3.4.29 of XCircuit, an electronic schematic CAD program, has been announced.
Games Stella: release 2.6.1 (SourceForge) Version 2.6.1 of Stella has been announced, it includes better timing support and bug fixes. "Stella is a multi-platform Atari 2600 VCS emulator. It allows you to play all of your favorite Atari 2600 games again! Stella was originally developed for Linux by Bradford W. Mott, however, it has been ported to a number of other platforms."
Interoperability Wine 1.0-rc2 released Version 1.0-rc2 of Wine has been announced. Changes include: Bug fixes only, we are in code freeze.
Medical Applications Medsphere Announces New Client/Server, Move to AGPL (LinuxMedNews) LinuxMedNews covers the latest release of OpenVista. "Medsphere Systems Corporation, the leading provider of Open Source healthcare IT solutions, today announced the Open Source release of OpenVista Clinical Information System (CIS) version 1.0 Beta and OpenVista Server version 1.5.86. Available for immediate download at www.medsphere.org, these applications compose Medsphere’s Open Source electronic health record (EHR) system."
Announcing the Python/ZCA Healthcare Project The new Python/ZCA Healthcare Project (OSHIP) has been announced. "The concept of OSHIP is that it can be an application framework for interoperable healthcare applications. This should be especially appealing to governments and funding agencies worldwide. OSHIP operation is envisioned as taking the archetypes expressed in ADL and store them in an Archetype Repository as Python objects. These instances are then available to developers to use in healthcare applications. Knowledge workers can create/edit the ADL files (using existing opensource tools) to create whatever knowledge model may be needed for a specific application."
Music Applications dssi-vst 0.7 announced Version 0.7 of dssi-vst, a DSSI plugin wrapper for Win32 VST effects, has been announced. "dssi-vst now exposes a LADSPA descriptor as well as a DSSI descriptor, and the install target now installs dssi-vst to the system LADSPA directory as well as the DSSI one. This change permits you to use dssi-vst to load VST effects in LADSPA hosts, as well as to load VST effects and instruments in DSSI hosts as before."
ssg 1.13 is available Version 1.13 of SSG (Simple Sine Generator), a simple instrument/generator plugin with midi in and audio out, has been announced. "Main change is switch to event port LV2 extension. LV2 URI is changed and installation directory is changed too. So you can have both older midi port variant and newer even port ssg installed simultaneously. Also, bug in Makefile is fixed."
Web Browsers Fsyncers and curveballs (the Firefox 3 fsync() problem) Users of the Firefox 3 beta have noticed that it can often bring the system to a temporary halt. For the curious, here is a clear description of the problem and what is being done to address it. "I think you can see where this is going: if there's a lot of data waiting to be written to disk, and Firefox's (sqlite's) request to flush the data for one file actually sends all that data out, we could be waiting for a while. Worse, all the other applications that are writing data may end up waiting for it to complete as well. In artificial, but not entirely impossible, test conditions, those delays can be 30 seconds or more. That experience, to coin a phrase, kinda sucks. Does it suck as much as file corruption wiping out your bookmarks after your computer (not Firefox) crashes? As you might imagine, opinions vary."
Languages and Tools C++ A coding rules checker for GCC The GGCC project set out in 2006 to add a set of code checking and static analysis tools to the GCC compiler. This project has now announced the initial release of a coding rules checker for C++; in this context, "coding rules" means programming practices, rather than basic coding style. "Our modified version of GCC can dump some information about a C++ program in the form of Prolog facts. Then, a Prolog engine is used for codifying coding rules and search the dumped data for violations of the rules. Very few rules are implemented right now but, hopefully, some more rules will be added in the next days/weeks." Some more information can be found on the GGCC coding rules page, though it seems to lack a list of which rules are actually checked.
Caml Caml Weekly News The May 27, 2008 edition of the Caml Weekly News is out with new articles about the Caml language.
HTML CSSBox: 1.1 released (SourceForge) Version 1.1 of CSSBox has been announced. CSSBox is: "An (X)HTML/CSS rendering engine written in pure Java. Its primary purpose is to provide a complete information about the rendered page suitable for further processing. However, it also allows displaying the rendered document. A new release of the CSSBox HTML/CSS rendering engine has been released. This release fixes some rendering bugs and adds a few new features."
Perl This Week on perl5-porters (use Perl) The May 11-17, 2008 edition of This Week on perl5-porters is out with the latest Perl 5 news.
Python PyGObject 2.14.2 released Version 2.14.2 of PyGObject has been announced, it includes several bug fixes. "GObject is a object system library used by GTK+ and GStreamer. PyGObject provides a convenient wrapper for the GObject+ library for use in Python programs, and takes care of many of the boring details such as managing memory and type casting. When combined with PyGTK, PyORBit and gnome-python, it can be used to write full featured Gnome applications."
Python-URL! - weekly Python news and links The May 26, 2008 edition of the Python-URL! is online with a new collection of Python article links.
Tcl/Tk Tcl-URL! - weekly Tcl news and links The May 24, 2008 edition of the Tcl-URL! is online with new Tcl/Tk articles and resources.
Version Control GIT 1.5.5.2 released Version 1.5.5.2 of the GIT distributed version control system has been announced. "One side effect of declaring to make the cycle toward 1.5.6 shorter is that we would not have that many 1.5.5.X maintenance releases. Nevertheless, there are quite a few fixes accumulated since 1.5.5.1 hence this one."
GIT 1.5.5.3 released Version 1.5.5.3 of GIT has been announced. "This one is much smaller than 1.5.5.2, primarily to push out a few fixes to send-email and bisect that have already been in 'master' for a while."
Page editor: Forrest Cook
Linux in the news Recommended Reading After Debian's epic SSL blunder, a world of hurt for security pros (Register) Here's an article in The Register on the aftermath of the Debian openssl vulnerability. "Among the weak SSL certificates at time of publication is this one belonging to Whitehouse.gov. It's of little consequence, since the site doesn't conduct secure transactions, but it does show the ubiquity of the problem. The key is owned by content delivery provider Akamai Technologies and is used by about 20,000 websites. Akamai is in the process of replacing it."
Trade Shows and Conferences KDE at the Libre Graphics Meeting 2008 (KDE.News) KDE.News has an account from the Libre Graphics Meeting. "The Libre Graphics Meeting brings together developers of free graphics software in the widest sense of the word as well as the users: artists, photographers, designers and publishers. Whether you are interested in fonts, photography, panoramas, digital art, mathematics, colour theory, vector libraries, applications, file formats, interoperability, user interaction, typesetting, text layouting, 3D modeling or animation, or all of those, the Libre Graphics Meeting is the meeting to attend. This year's program had a particularly good mix of introductory and in-depth presentations. No topic was left unexplored, and the great thing is: everyone was talking to everyone and came home with new ideas, new initiatives for cross-project cooperation and integration."
YAPC::Russia (use Perl) use Perl covers the recent YAPC::Russia conference. "I asked in a mailing list of Moscow.pm if someone could help to find a venue of amphitheatre style. In a couple of "peer-to-peer" steps we met with a guy from the Club "Business in .RU-style" which is a part of State University-Higher School of Economics. They proposed us to take one of the auditoriums of such type. Later I asked for one more auditorium to host a second thread of talks."
Companies Wind River, Intel partner on 'infotainment' platform (East Bay Business Times) East Bay Business Times covers a partnership between Wind River and Intel. "Alameda's Wind River (NASDAQ: WIND) will create a standard automotive Linux operating system for the partnership, which will run on Santa Clara-based Intel's low-power Centrino Atom processor. "We see automotive as a forerunner, sitting in front of related marketplaces, like mobile handsets, mobile Internet devices, medical devices, gaming systems and mobile entertainment systems," said John Bruggeman, Wind River's chief marketing officer. The Wind River Linux Platform for Infotainment will be available in August 2008."
Linux Adoption Linux opens London's Oyster (ZDNet) ZDNet reports on a move from proprietary software to Apache and Linux by the London subway system. "The Oyster contactless card system, which handles payments for travel on London's buses and Tube system, suffered from lock-in to proprietary systems, which hindered developments to the online payment systems, said Michael Robinson, a senior consultant with Deloitte, at the Open Source Forum event in London. "The hosting was on a proprietary system, centred on one application," he said. "It demanded certain hardware, and was locked into one design of infrastructure.""
Legal Copyright deal could toughen rules governing info on iPods, computers (Vancouver Sun) The Vancouver Sun covers a proposed trade agreement which would take the copyright battles to a new level. "The deal would create a international regulator that could turn border guards and other public security personnel into copyright police. The security officials would be charged with checking laptops, iPods and even cellular phones for content that 'infringes' on copyright laws, such as ripped CDs and movies. The guards would also be responsible for determining what is infringing content and what is not." (From BoingBoing).
Interviews Linux is a platform for people, not just specialists (Guardian) Glyn Moody interviews Mark Shuttleworth for the Guardian. How close, he asks, is Canonical to breaking even? "Not close. It will require time and ongoing investment. We've positioned ourselves for what we see as the future of software - unlicensed software, people having access to the software that they want at the time that they want it. The service ecosystem around that software will fund it. And if we are the company that has best anticipated that future, then we will be best positioned to benefit from it."
Reviews OLPC 2.0: towards the US$75 laptop (apc) apc reports on the second generation OLPC laptop, which replaces the keyboard with a touch screen. "Even before today’s crop of $500-$800 mini-notebooks became the New Cool Thing, MIT’s vision for a low-cost Linux-powered laptop for the third world was reaching for a price point as low as US$100. It never got there, of course – the product that evolved into the XO-1 sub-note sells for US$188. Even so, it’s notched up some 600,000 sales to date. Now MIT has its sights on a next-gen XO machine, dubbed XO-2, which it hopes will embrace new technologies while also bringing the price down to US$75 by the time the model is ready in 2010."
Red Hat, Novell SUSE Linux Get Upgrades (InformationWeek) InformationWeek takes a look at the recent updates to both Red Hat and Novell Enterprise Linux products. "Both Red Hat and Novell says the upgrades cover things like virtualization, management, hardware support, and security."
Page editor: Forrest Cook
Announcements Non-Commercial announcements GPL-Violations.org and FSFE's Freedom Task Force to work more closely together Coordinators of the FSFE Freedom Task Force (FTF) and GPL-Violations.org recently met in Berlin to discuss future cooperation. "GPL-Violations.org will be pro-actively working on cases and seeking resolutions where violations occur. The FTF will continue and expand its educational and networking activities to ensure awareness of best practice and help support people with their use of the licences."
Open Graphics Project PCI card pre-orders are open Pre-orders are being accepted for an open-designed PCI graphics card project. "Traversal Technology is taking pre-orders for a PCI card developed in collaboration with the Open Graphics Project. It is not a graphics card, it is an FPGA card that can be used to develop and test designs for a free graphics card. Still, it's progress! They're looking to raise enough funds to produce a small batch of them."
Commercial announcements Chesspark Congratulates Facebook for Integrating XMPP Chesspark congratulates Facebook for supporting XMPP, the eXtensible Messaging and Presence Protocol. ""We've built the best stack for allowing companies to connect their applications to XMPP, allowing anyone wishing their web or desktop application to communicate over XMPP to do so seamlessly," states CEO Jack Moffitt, who is also on the board of directors of both the XMPP Standards Foundation, the organization that manages the XMPP specifications, and the Xiph.org Foundation, known for its Open Source and royalty free multimedia standards such as Ogg Vorbis."
Gentoo Foundation reinstated The Gentoo site announces that, according to the state of New Mexico, the Gentoo Foundation has returned to good corporate standing and can, once again, do business.
Synopsys releases VMM methodology standard library under Apache license Synopsys, Inc. has announced the release of its VMM methodology implementation. "Synopsys, Inc., a world leader in software and IP for semiconductor design and manufacturing, today announced it has released the source code for its complete implementation of the proven VMM verification methodology for SystemVerilog, including the VMM Standard Library and VMM Applications, under the popular Apache 2.0 open source license."
TigerLogic Corporation announces Omnis Studio 4.3.1 TigerLogic Corporation has announced the release of the Omnis Studio 4.3.1 rapid application development tool. "Omnis Studio 4.3.1 greatly extends the ability of Omnis to provide fast and easy-to-use tools for Windows, Mac and Linux application developers. New features offer an overall improved Web application developer and Web user experience."
Resources FSFE Newsletter The May 21, 2008 edition of the FSFE Newsletter is online with the latest Free Software Foundation Europe news. Topics include: 1. FTF workshop leads to broad agreement on European licensing infrastructure 2. Lack of quality in standardisation a serious problem 3. Licensing as a strategic imperative, speech at FISL 4. Fellowship Group at Ubuntu Release Party in Berlin 5. Italian team: new mailing list and renewed blog.
Meeting Minutes Perl 6 Design Meeting Minutes (use Perl) The minutes from the May 21, 2008 Perl 6 Design Meeting have been published. "The Perl 6 design team met by phone on 21 May 2008. Larry, Allison, Patrick, Jerry, Will, and chromatic attended."
Calls for Presentations Embedded Linux Conference Europe 2008 - Call for Proposals A Call for Proposals has gone out for the Embedded Linux Conference Europe. The event will take place on November 6-7, 2008 in Ede, the Netherlands. The submission deadline is June 29. "Presentations should be of a technical nature, covering topics related to use of Linux in embedded systems. The CE Linux Forum is focused on the use of Linux in consumer electronics products, but presentations may cover use of Linux in other embedded areas, as long as the topic is of general relevance to most embedded users. Presentations that are commercial advertisements or sales pitches are not appropriate for this conference."
NLUUG fall conference call for papers A call for papers has gone out for the NLUUG fall conference. The event takes place on November 6, 2008 in Ede, The Netherlands. Abstracts are due by June 29.
Upcoming Events Second Annual LLVM Developers' Meeting The Second Annual LLVM (Low Level Virtual Machine) Developers' Meeting has been announced, it will take place on August 1, 2008 at the Apple Inc. Campus in Cupertino, California.
Events: June 5, 2008 to August 4, 2008 The following event listing is taken from the LWN.net Calendar.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[Screenshot]](/images/ns/grumpy/claws-sm.png)