LWN Weekly Edition
Leading itemsSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->Multipage format
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for April 16, 2009PostgreSQL 8.4 Beta: "We've got momentum"The PostgreSQL project has released the beta of its 8.4 version, with the final release expected in late June or July. Like previous PostgreSQL releases, 8.4 features dozens of enhancements throughout the code, but Bruce Momjian, a member of PostgreSQL's core team since the project was founded in 1996, described it as a "more surgical release" with improvements tending to cluster in select areas. In particular, that area seems to be administrative features. However, almost as interesting as the features in the beta are the ones that failed to meet the cut this time, and the project's struggle to control the release process as it undergoes major growth. Momjian explained the release's more targeted approach as the result of the project's advanced state. "You see a real consolidation in this release," he said, "and I think that's because you're seeing a much more complete feature set. You're seeing a real maturity of the code base, which is kind of surprising, because, if you looked a few years ago, you'd see changes all over the map." At the same time, Momjian characterized the PostgreSQL code as being constantly revised, so that the project is unlikely to need any time soon the kind of major revision that KDE underwent last year.
That's
always been a fear of ours, but we've actually never had to do it. And I
think the reason is that, in general, we're always restructuring our source
code. So we're always having to re-engineer things and clean them up.
For example, by the end of the Windows port [in 2003], the code was cleaner than when we started. You'd think that after adding a Windows port, the code would be just — you know — spaghetti code central, right? But we end up abstracting a lot of the Unix-specific behavior into a portability library. so now, a lot of the assumptions that you make about Unix are now codified in a separate place. And then you put the Windows pieces in there, and it works really well, too. Nor is the project hesitant about altering behavior or deprecating legacy code in the name of what Momjian called "high standards and the promise of reliability."
New featuresPostgreSQL releases tend to be one to two years apart, with far too many features to mention in any detail. Many of these features are highlighted in a PDF presentation by Momjian entitled, "Upcoming PostgreSQL Performance Features [PDF]", including Column Level Permissions and Per-Database Locales. However, if you ask active contributors what the major enhancements are in the 8.4 release, their answers emphasize automated administrative features. Selena Deckelmann, user groups leader in the project, emphasized changes to Free Space Map, which maps unused space in a database. In previous releases, PostgreSQL could only detect newly freed space by an administrator manually running the Vacuum utility. By contrast, in the 8.4 release, freed space is re-mapped automatically, saving both time and effort. Deckelmann also called attention to a new feature called Visibility Map. While in previous releases, Vacuum had to re-map all rows in a table, regardless of whether they had changed, Visibility Map improves performance by allowing the utility to skip rows that have not changed. Yet another automated feature mentioned by Deckelmann is Auto Explain, which captures the explain plan for a query — that is, how the query finds results — and saves the results, information that can be used to improve system load and the efficiency of queries, and, ultimately, to reduce the costs of a database operation. "It's something that a lot of admins end up doing anyway," Deckelman observed, "They write a script that looks for long-running queries, and then they go in and manually figure with each one what's going on. It's kind of a neat feature that came from the Japanese PostgreSQL team." Josh Berkus, another core team member, noted that Oracle's Statspack, a set of tools to generate statistics useful to database administrators, inspired pgstat. As Berkus explained the situation, users migrating from Oracle expect to see comparable tools in PostgreSQL, and Statspack:
...allows you to see
exactly what's going on with your server internally in terms of how much
memory it's using, what queries it is running, and all those other things
that you need to know so that, when the load on the server starts going up,
you know what to do about it. We've had some hackish tools for a long time,
and have had some sophisticated activity logging, but activity logging is
not very interactive. So we're adding some new interactive tools. We're
trying to achieve an analog of what Statspack provides.
Berkus noted, though, that pgstat will not be stable enough to be installed by default in 8.4. Instead, it will be shipped in postgresql-contrib, the repository for tools that, for one reason or the other, are not part of the regular installation. Some tools in contrib may be too specialized for most installations, or illegal to ship under American restrictions on the exporting of cryptographic tools, while others, like pgstat, are still in development. According to Deckelmann, statistics in PostgreSQL receive another boost in the 8.4 release with increased control over them. To reduce system overhead, statistics are no longer automatically collected and written to a file, operations that can have significant system overhead if done regularly. Instead, statistics can now be configured to run from a RAM disk to improve performance. However, if the latest release has a single outstanding feature, it is parallel restore. As the name suggests, parallel restore allows admins to restore a database with multiple processes, rather than a single thread. Berkus, who runs his own PostgreSQL consulting business, said, "[Parallel restore] is the feature i've been making the most use of. I've been using it in beta already — pretty heavily. Because if you have 300 gigabyte databases, upgrading them single-threaded is lethally slow. It's a real issue." He went on to describe parallel restore as a particularly difficult feature to implement, all the more so because it had to accommodate past changes in the PostgreSQL file format. While employed as a supervisor at Sun Microsystems, Berkus said, he had two employees working on a similar feature for a year and a half "without coming up with more than a rough prototype." By contrast, PostgreSQL developed its version in three weeks, followed by three months of debugging. Features for the next releaseAs mentioned earlier on LWN, PostgreSQL's core team had hopes of other major features being in the 8.4 release, particularly Hot Standby and SE-PostgreSQL. Hot Standby is a feature that is a major step in improving PostgreSQL's replication. Replication is an area in which PostgreSQL lags behind MySQL; it has been identified by the core team as one of the major priorities for the project, according to Berkus. PostgreSQL does have some replication, Berkus said, but it is needlessly complicated and "not for someone who can't make a large time investment in finding out how it works. And that's a real problem for the sort of average-case web developer that has two servers and just wants to make sure that PostgreSQL is mirrored." Hot Standby is an important improvement in replication that allows administrators to run queries on a database that is being recovered from an archive. The module allows replication of the database logs in order to create read-only duplicates of the database. Unfortunately, funding for development of the feature only came through in August 2008, leaving only a few months before the November code freeze. Nor could Hot Standby be finalized in the extended testing period that followed. SE-PostgreSQL is an even greater innovation, which will add the SE Linux security model, making PostgreSQL the first database to use the same security model as many distributions, such as Fedora. The problem is, Berkus explained
Because we are the trendsetters, it is very hard
to advance in this area. There's no standard defined syntax, and all the
papers on the topic are highly academic and speculative, so it means that
we really have to spend a lot of time implementing things down to the API
level and spending long periods of time arguing over details of which
security features should be implemented in any context.
Having failed to be ready for the 8.4 release, both Hot Standby and SE-PostgreSQL are high on the priority list for the next release. In fact, according to Momjian, 8.4 is partly designed to ease their later implementation. Momjian suggested that, given the maturity of PostgreSQL's code, these might be simply the first of many new features that are too large to be implemented in a single release. Meanwhile, he planned on promoting SE-PostgreSQL in the release notes in the hopes of encouraging interest in it and perhaps attracting a few developers with SE Linux experience. "To continue to grow and continue to have the sort of reputation we have, you have to make some hard decisions," Momjian said. Like Berkus and Deckelmann, Momjian clearly regretted the necessity for omitting these features. However, having faced long delays because of the refusal to jettison unfinished features before — notably in the implementation of the Windows port in version 7.4 and more generally in the sheer number of features in version 8.3 — the PostgreSQL core team has learned the hard way not to insist that a release include all the features they hoped it would have. Lessons from the releaseBesides the features, the 8.4 release has been important to the PostgreSQL team in its effort to regain control of its development processes. The project has always had an extensive review process, in which veteran developers were counted on for the final review of contributions. However, ever since the 8.3 release, Momjian explained:
We're getting really major, large,
complex patches almost every week. And obviously that's very hard for the
veterans to digest. One of the challenges is that we've not grown our
veterans' group as quickly as we have our submitters. It's like a snake
swallowing a mouse — it takes a while to go through. You have this
bulge of activity, and it's really struggling just to digest so many
complex patches.
To make matters worse, the review process can be daunting, especially to new contributors. Consequently, many were working in private and submitting their code only at the last moment before a freeze. To reduce these problems, PostgreSQL implemented a series of what it calls CommitFests — alternate months in which no contributions are allowed, and project members concentrate on reviewing existing contributions. This solution helped reduce the problems, but did not eliminate them. In addition, Berkus said that CommitFests did not address complaints he had heard about people who would review a patch, only to find that a veteran had reviewed and submitted the patch before they had finished. Another challenge was how to enlist the aid of those who said that they were willing to help review out of public-spiritedness, but did not want the trouble of picking out patches to review by themselves. Solving such issues seemed central to increasing the efficiency of reviewing and in keeping CommitFests from extending beyond their originally allotted time. Realizing that greater efforts were needed, the core team is now using a wiki to coordinate each CommitFest. In addition, over the last half year or so, Berkus created a team of what he calls "Round-Robin Reviewers" — those who wanted their reviews assigned. He also implemented reviews for routine matters such as patch structure by less experienced contributors. The core team and veterans still have to do the majority of the work, but the process has reduced the work load, and added 25 reviewers to the previous pool of 15. The changes can still make for a slow process, but Berkus apparently judges them a qualified success, noting that the 8.4 release will likely take several months less than the 8.3 release. ConclusionOverall, Momjian seems satisfied with the general direction of PostgreSQL. He even suggested that the project is starting to gain increased recognition.
In the past year or so, I'm been seeing PostgreSQL put up as —
I won't say a model open source project, but one that's getting the kind of
respect for office disruption that OpenOffice is getting. It is starting to
be seen as a valid competitor to Oracle. I've heard people say, 'What is
the business case for buying Oracle when 80% of its functionality can be
found in PostgreSQL, and in some cases it's easier to use and easier to
administer, and, in most cases, cheaper?'
Momjian speculated that the recession may be driving this increased respect. Berkus pointed, too, to the increased sponsorship of the program, which now means that more developers are being paid to work on the project full-time, and to the increased number of PostgreSQL conferences and user groups world wide. "Compared to other open source databases, we are still developing very quickly," Berkus said. "We still have developer momentum." As you look over the feature list for 8.4 as well as the features that were dropped, it is hard to disagree. While stopping short of being revolutionary, the new release suggests sustained, steady progress in development.
ELC/LFCS2009: A tale of two panelsTwo kernel panel sessions were held last week in San Francisco, one for each of two conferences sharing facilities—and participants. In both cases, the kernel developers making up the panel were asked about various kernel features and developments, both from a historical and future perspective, but each had its own focus as well. The Embedded Linux Conference (ELC) panel was, unsurprisingly, focused on topics of most interest to the embedded community, while the Linux Foundation Collaboration Summit (LFCS) panel looked at more mainstream kernel concerns. ELC: Embedded Linux Kernel Features and DevelopmentsBesides the venue, the panel sessions also had another thing in common: LWN Executive Editor Jonathan Corbet, who moderated the LFCS panel and was a member of the ELC version. The ELC panel was moderated by CE Linux Forum (CELF) architecture group chair Tim Bird, while embedded maintainer David Woodhouse and Matt Mackall, developer of the SLOB memory allocator (along with various other kernel tasks), rounded out the panel. Bird asked most of the questions, but the audience also got the opportunity to ask a few too. One of the themes of the discussion—as well as Woodhouse's earlier keynote—was the convergence of features between so-called "big iron" (servers and mainframes) and embedded devices. Corbet was amused to see "highmem" support recently added for ARM processors, noting that it was a controversial feature at the time it was added for servers; supporting a full 1GB of RAM on a 32-bit processor was once a "big iron" problem. Mackall also pointed to SMP and NUMA support moving into the embedded architectures. But things are not only moving in that direction, Mackall said, there is recognition from the big iron developers that there is value for their systems in some of the embedded features too. Bird asked the panel about the proliferation of embedded distributions and whether that was a good or bad thing. Woodhouse said "fragmentation doesn't have to be bad"; it's only bad when a distribution doesn't work well with the various upstreams and goes off and does its own "weird things". Multiple distributions are one of the "great strengths of Linux", Corbet said, as it provides playgrounds where folks can experiment with different approaches. Mackall pointed to a lack of community involvement in the various embedded Linux distributions, noting that the most successful desktop distributions were those with a strong community. In the mobile space, the distributions are "coming from the top down", he said, for any of them to be successful, they need to get community feedback. The impact and usefulness of new "social networking" sites for Linux developers—like MontaVista's meld and the LF's relaunch of the Linux.com community—was another question Bird put to the panel. Woodhouse didn't really see the need, but "communication is always good". Mackall was concerned that these other services not become a "substitute for talking to the Linux kernel community through its normal channels". Corbet noted that there is value in "small town environments", but there is a risk that they can become inbred. "It rarely leads to good things" when a small community gets headed off in their own direction, he said. One of the more interesting exchanges centered around the question of what a developer who just has a small amount of time can do to assist the larger community. The discussion spread out from there, though. Woodhouse stated that every developer needed to make sure that what they are working on can go upstream even if their managers "need to be whipped to allow you to do that". But Mackall wanted to "back up a step" and ensure that developers are running Linux on their desktop. Mackall said that developers should be running Linux at home as well; if they are going to work with Linux, they should "live it". Making it work on a laptop is a good exercise; if it doesn't work, figure out why and fix it. He has seen too many embedded Linux developers with Windows desktops who don't understand Linux well enough to properly develop on it. "They don't have the Linux mindset", he said. Those thoughts were echoed by Woodhouse as he related an anecdote about some embedded developers who would FTP a file to the Windows box, edit it using Notepad, then FTP it back to the Linux machine. It is not efficient to do things that way, he said. Doing the development on Linux will lead to a better result, Mackall said. Doing everything on a Linux desktop will help that, Mackall pointed out, "you should read your mail on it too". Towards the end of the hour-long session, Bird asked "have we won?", is embedded Linux unstoppable or "is it possible to lose?". Mackall and Corbet had similar thoughts, worrying about the proliferation of devices running Linux that could not be modified by their users. "We haven't won until I can put my code on my phone", Mackall said. Corbet echoed that: "If we end up populating the world with locked-down Linux systems, then we've lost". In closing, Bird noted that embedded Linux has made an "awful lot of progress". This is the fifth year for ELC and he has been working on embedded Linux for 17 years, over that time, "things have gotten way better", he said. LFCS: The Linux Kernel: What's NextCorbet opened the panel by having the participants introduce themselves to an audience of around 400 people. The panel consisted of X.org project lead Keith Packard of Intel, Andrew Morton the kernel "odd job man" from Google, USB maintainer Greg Kroah-Hartman of Novell, and Ted Ts'o of IBM who is currently on loan to the LF as its CTO. After that, Corbet got started by asking Kroah-Hartman about the -staging tree. Approximately one-third of the code that was merged as part of the 2.6.30 merge window came in via the -staging tree, which Kroah-Hartman maintains. Corbet said there was a lot of confusion about the tree and asked for an explanation. Basically, it is a collection of drivers that used to live outside of the tree, Kroah-Hartman said, consisting of bad code with bad API usage and other major problems barring their acceptance into the mainline, in other words, "crap". But there is a lot of hardware in use that requires those drivers and the code was not getting improved out of the tree, so moving them gives a centralized location where people can get them and hopefully improve them. Kroah-Hartman said that there were several drivers that had graduated from -staging and into the mainline, so the process seemed to be working. "If you want to get involved in the kernel, that's a good place to start", he said. He noted that there are TODO files in each driver's directory listing the kinds of changes needed before the driver will be accepted into the mainline. Corbet mentioned that he had been going to conferences for years hearing about all the great things that were going to be done in the Linux graphics area, but that we had now reached a point where much of it had actually been done. He asked Packard to fill the audience in on what had been done and "why it's cool". Packard described how X.org had "turned the graphics stack upside down" by moving the device configuration out of user space and into the kernel. By doing that, X becomes just an API for existing applications, and other APIs such as OpenGL or Wayland can be considered, he said. Support for Intel graphics is good, and there is lots of work going on for Radeon (ATI) chipsets, but NVIDIA is "not helping at all". He pointed out that Fedora 11 will be shipping with the Nouveau driver for NVIDIA hardware because it has surpassed the free 'nv' driver in capabilities. He also noted that moving the configuration and initialization into the kernel allows people to experiment with graphics acceleration without spending an inordinate amount of time figuring out how to initialize the hardware. Next, Corbet asked Ts'o about the status of the ext4 filesystem. Ts'o reported that Fedora and Ubuntu would be shipping it in their next releases that are coming within a few months. He said that the user community was growing and "to be brutally honest, that will sometimes find bugs". He said one goal is to get it into the next round of enterprise distributions. He also noted that ext4 is a temporary solution, based on BSD FFS, which is technology from the 70s. Btrfs, nilfs, and others were where the interesting filesystem development is happening. All of those make it an "exciting time" to be a filesystem developer. Morton responded to a query about the linux-next tree by saying that it is working out well, overall, as a place for integration and testing. But, he said that he was "a bit disappointed with the uptake it has", especially from a testing perspective. Fewer maintainers are taking advantage of the opportunity to integrate and test using linux-next than he would like to see. It is often the case that when there is a problem that shows up in Linus Torvalds's tree, it is because the code never made into linux-next. From the audience, ftrace developer Steven Rostedt asked about the pressure to merge new code upstream into the mainline, but that there is major resistance to certain things—he mentioned SystemTap and utrace—being merged. He wanted to know what can be done to resolve that. Morton responded that for device drivers or supporting new architectures, the path is easier, but that the two examples Rostedt gave touch core kernel code. Morton likened the utrace battle to an "incestuous family struggle", but noted that the code needed improvement before it could go in. One of the reasons that utrace didn't make it into the kernel was a lack of an in-kernel user of the code, Rostedt noted. Morton responded that having an in-kernel user for a feature is a "nice checkbox", because it gives the kernel community a means to test the code. But, Kroah-Hartman pointed out that "changing core kernel code is hard, and it should be". Ts'o also pointed out that several core kernel developers are helping out with utrace, which should significantly smooth its path into the mainline. That discussion led Corbet to ask about tracing, noting that there were several tracing solutions that were still out of the tree, but that ftrace got new tracers added for each kernel release. Morton would like to "see evidence that people are using them and getting good results". Both he and Ts'o pointed at the lack of documentation for various tracers, saying that adding that and making the tracing more usable would help get more of that code into the mainline kernel. The recently proposed nftables packet filtering subsystem was raised by Corbet as an example of a place where a user-space interface—the existing iptables—might be supplanted. He asked how that transition could be accomplished. Morton called it a "pretty traumatic transition" that would require a compatible set of tools, with several years of warning along with buy-in from the distributions. That takes three to four years according to Kroah-Hartman. Ts'o called the packet filtering interface more of an administrative interface that didn't have to be kept as stable as others, but that the iptables command does need to be stable. All of that led Packard to complain about the difficulties of keeping the current user-space interface for X servers while moving modesetting into the kernel. According to Packard, there are exactly two users of the interface, both of which are under his control, so why does he need to provide backward compatibility? Ts'o said that the problem would be for distribution users who wanted to upgrade their kernel. Because the distribution might use an old X server, that interface—which Packard described as "open /dev/mem"—needs to be maintained. Kernel hackers want as much testing of new kernels as they can get, so any barrier to that testing is problematic. At the end of the session, LF Executive Director Jim Zemlin announced the first ever LF "Unsung Hero" award, which he then presented to Morton. He explained that Morton is an avid car racer, so the LF arranged for him to have a day at the track as a reward. It was no surprise that there was much applause for Morton—one of the few people actually able to follow the linux-kernel mailing list. He also reviews an incredible amount of the code that ends up in the kernel. These sessions provide an interesting view into the thinking of the members of the panel—one not easily derived from just keeping up with the technical side of Linux development via the LWN Kernel page or even by sifting through linux-kernel. They also give attendees a look at what's coming in the future that can be hard to discern, though Corbet's Linux Weather Forecast is helpful there. In the end analysis, though, the biggest benefit may just be putting kernel developers and users together in a fairly informal setting so that both sides get a better feel for the other. Faces and personalities don't necessarily jump out of the normal communication channels, so panel sessions like those that went on in San Francisco are useful well beyond their technical content.
Book Review: Pragmatic Version Control Using GitGiven the ubiquity of Git as a version control system throughout the free software community, one would expect there to be more books about it. So far, that is not the case—though there are indications that is changing—so Travis Swicegood's Pragmatic Version Control Using Git is welcome for those trying to come up to speed on Git. Overall, the book provides a nice starting point, though there are some rough spots.
Like any book covering a free software package, this one begins with some
important basics: where to get and how to install the tool.
For Linux
users, this guide is probably unnecessary as Git is packaged for most
distributions these days—Mac OS X or Windows users may find more of
interest. The discussion of Git configuration, along with the reminder to
set the user.name and user.email parameters before doing
any commits, something that I regularly forget when setting up a new machine,
is quite useful for all.
Unlike some other authors, though, Swicegood takes the time to give a bit of the flavor of Git through a discussion of its concepts—along with some indication of why one might want to use it—before descending into the much more boring installation guide. He takes a "30,000 foot" view of the tool and, with no command syntax or specific usage details, spells out what Git can do. One of the primary problems that any text on a version control system (VCS) must overcome is the need to give "real-world" examples while still keeping the book to a reasonable size. Swicegood does a good job here, by following one example repository throughout the text. One could quibble with the scope of some of his examples, but, by and large, they give a good idea of how things work. In some ways, the simplicity of those examples appears to encourage curious readers to do some experimentation. That is, after all, a pretty good way to learn how to use a tool. The book is broken up into three main sections (plus an Appendix with a reference and some pointers to more information), but the meat of the text is in Section II, "Everyday Git". For whatever reason, the last chapter of the first section covers setting up local repositories as well as cloning remote repositories. That might make sense, but it is rather puzzling that it starts talking about things like git rebase, branches, and doing releases here. Much of that is covered in further detail later and it doesn't seem to belong. In Section II, the book does an excellent job of covering how to use Git on a day-to-day basis. I have found myself referring to it several times since reading it to remind myself of the syntax of a command—or the name of a command itself. The sequence is logical, starting with adding and committing files, moving through branch creation and management as well as examining and working with history in Git, and completing the core with a look at remote repositories. Two additional chapters covered somewhat more advanced—or just less often used—features such as organizing the repository and working with multiple remote projects as well as things like compacting a repository and working with the reflog. Swicegood uses the term "staging" for what is commonly referred, at least in other Git documentation, as the "index". Some readers, especially if they are already well-versed in Git, may find this a bit confusing, but I found that it made sense and, in some ways, simplified the concept. In any case, it seems clear that is how Swicegood envisions the Git index, so passing it along to his readers is a nice touch. There is no specific mention of the Git version covered by the book—though some early examples mention 1.6.0.2—which is a rather large oversight. Git development moves rapidly, so some of what Swicegood talks about could well be out-of-date. New Git features, such as the unmentioned git stash, were left out, but it isn't clear whether that was done on purpose or because they were added after the book was completed. Most of what is covered should be unaffected, though, as the basic operation of the tool is fairly stable. The third, thinnest and weakest section is "Administration", which covers migrating to Git and running Git servers. Both chapters seem to suffer from a lack of breadth. In the migration chapter, nothing but CVS or Subversion are considered, and tools like tailor are not even mentioned. Two things about Swicegood's choices of Git features stood out in a negative way. He seems overly enamored of git rebase, which certainly has its place, but it has some drawbacks that he doesn't fully caution against. His solution for how to create a repository for others to use was somewhat unsatisfying; Git itself can be configured to support such things. Instead, Swicegood reaches for Gitosis, a Python tool for managing remote git repositories. The project seems to have no web page (other than a gitweb page) and one must install it by cloning its repository. Given that there is no mention of how to "manually" set up a Git server, it all seems a bit strange. There are a handful of less-substantive complaints I could make as well: a throwaway George Santayana quote on the history chapter was a bit annoying, an embarrassing "EMCAScript" typo in one of the examples stood out, as did a few other minor flaws. Swicegood complains frequently about having to truncate or otherwise modify the output of commands to fit on the page, which seems a bit silly. Either fix the problem somehow in the production process or ignore it to the extent possible; involving the reader in the pain of the typographic process seems unnecessary. But these are nits. While I had some complaints—it is a rare book indeed where I don't—Pragmatic Version Control Using Git has certainly found a spot for itself on my shelf. It especially shines as a quick reference to commands needed daily or nearly so. It will also provide a good starting point for those who wish to learn Git from scratch. Once other Git books come out, it will be interesting to see which end up on my shelf and which are shuffled off to long-term storage. In the end, that is the best test for a good book.
Security Another Linux capabilities hole foundA recent patch posted to the linux-kernel mailing list fixes a long-standing flaw in the Linux capabilities implementation. The problem has existed since capabilities were added to the kernel during the 2.1 development series—more than ten years ago. One of the obvious questions is how a bug of that sort could have escaped notice for so long. The problem was reported in March by Igor Zhbanov, who provided an excellent analysis of the flaw and how it can be exploited. The basic problem lives in the VFS and NFS code which tries to drop privileges, by way of capabilities, before performing operations. The mask of capabilities bits that was used for that purpose does not include CAP_MKNOD (the ability to make a device node entry) or CAP_LINUX_IMMUTABLE (which allows changing the S_APPEND and S_IMMUTABLE file attributes). That means that those capabilities bits are not removed before the file operation is performed. Zhabanov shows that on a compromised client machine, the root user could give another user CAP_MKNOD, which would allow that user to run the mknod command and create a device entry owned by them. If this was done on an NFS-mounted filesystem, that entry would be created on the server still owned by the user. This works even if the root_squash option—essentially mapping root users on client machines to "nobody" on the server machine—was used on the export. If the user on the compromised machine can execute code on the server or any other client, they can directly access the device that underlies the device node entry. They will not require any special permissions on the other machines because the device node is owned by them. For example, creating the equivalent of /dev/hda on the server's filesystem might allow direct access to the hard disk block device on any system that had the NFS filesystem mounted. Uglier exploits can certainly be imagined. This is clearly a nasty problem. Linus Torvalds merged the fix for the recently released 2.6.30-rc2 kernel. One would guess the -stable tree folks won't be too far behind. Serge Hallyn also provided patches for 2.4 and 2.2 kernels, though the latter has become completely unsupported. The patch was greeted with a question from Valdis Kletnieks: "Wow. How did this manage to stay un-noticed for this long?" Torvalds had a characteristically blunt answer: "Because nobody uses capabilities?" While that might explain how the bug went undetected for so long, it doesn't help alleviate the problem. Whether folks are using capabilities or not is irrelevant, the kernel itself certainly is. This is not the first time capabilities have been the source of a nasty, exploitable hole. The unfortunately-named "sendmail-capabilities bug" provided a way to gain root privileges by exploiting the way sendmail dropped its privileges. The solution, when this bug was found in 2000, was to "cripple" capabilities in the kernel by disabling capability inheritance. That functionality was not restored until relatively recently. If distributions and other users were doing more with capabilities, it does seem likely that this particular problem would have been seen sometime in the last decade. But, by and large, Torvalds is right. For one thing, capabilities are a Linux-specific feature, so anyone writing portable code is likely to avoid using them. In addition, they are fairly difficult to wrap your head around; that complexity tends to lead folks to ignore capabilities. There have been some efforts at using capabilities in distributions more, but one has to wonder how many more exploits still lurk in that code. It is hard to imagine removing capabilities at this late date—it is a user-space interface from the kernel after all—but some must be wondering if the feature is worth all the trouble it has caused.
New vulnerabilities clamav: denial of service
ghostscript: overflows and underflows
ghostscript: integer overflows
imp4: cross-site scripting
mod_perl: cross-site scripting
ntop: world-writable log file
ntp: arbitrary code execution
openafs: multiple vulnerabilities
php: denial of service
pptp: file permission problem
seamonkey: XSL Transformation vulnerability
tor: multiple vulnerabilities
wireshark: multiple vulnerabilities
wordpress-mu: cross-site scripting vulnerability
xine-lib: integer overflow
Page editor: Jake Edge Kernel development Brief items Kernel release statusThe current 2.6 development kernel is 2.6.30-rc2, released on April 14. "New 'microblaze' architecture, a somewhat late 'input' layer merge, a new intel virtual networking driver and some firmware loading updates. And mn10300 and frv moved their header files from include/asm to arch. That accounts for the bulk, but shouldn't affect anybody." The short-form changelog is in the announcement; see the full changelog for all the details.There have been no stable 2.6 updates released in the last week, and none are in the review process.
Kernel development news Quotes of the week
When the revolution comes, and the people who haven't converted to
git get sent to the gulags, we'll make "-M" the default.
-- Linus Torvalds
I have been asked to include aufs into mainline from several people
several times. As long as you have strong NACK for aufs and reject
all union-type filesystems, I have to give up unwillingly and will
answer them "Aufs was rejected. Let's give it up."
-- J.R. Okajima gives up
while(my_rootfs_hasnt_appeared_and_i_am_sad()) {
wait_on(&new_disk_discovery);
}
IBM has a well-known disdain for vowels, and basically refuses to
use them for mnemonics (they were called on this, and did "eieio"
as an instruction just to try to make up for it).
-- Linus Torvalds (thanks to Ben Hutchings)
But I'm from Finland. In Finnish, about 75% of all letters are vowels. I find this dis-emvoweling to be stupid and impractical. Without vowels, you can't tell Finnish words apart (admittedly, _with_ vowels, you generally cannot pronounce them, so to a non-Finn it doesn't much matter).
Notes from the LSF storage trackOur recent coverage from the 2009 Linux Storage and Filesystem Workshop (day 1, day 2) contained no notes from the storage track - an unfortunate result of your editor's inability to be in two places at the same time. Happily, James Bottomley took good notes, which he has now made available to us to publish. Topics covered include multipathing, I/O scheduling and tracing, ATA issues, and more; click below for the full text.
Rebasing and merging: some git best practicesIn a typical development cycle, Linus Torvalds pulls patches from over 100 git trees into the mainline repository. While this is going on, it's not unusual for him to complain about how some of those trees are managed; most of the gripes have to do with excessive use of rebasing and merging operations. In a recent discussion on the dri-devel list, Linus clarified his rules somewhat on subsystem tree management. Your editor, on the theory that there might be a developer or two out there who does not read dri-devel, thought that it might be good to expose those rules more widely.The git "rebase" operation takes a set of patches applied to one tree and reworks them to apply to a different tree. If a developer has written some patches against 2.6.29, he or she can use "git rebase" to turn them into patches against 2.6.30-rc1 instead. With git, rebasing can also be used to make edits to the commit history. If something needs to be fixed in a patch which was made some time ago, the developer can (1) remove the more recent patches from the tree, (2) make the needed changes, and (3) rebase the removed patches back onto the fixed patch. This technique can be used to silently disappear an embarrassing bug from the history, improve patch changelogs, fix a patch conflict against somebody else's tree, and more. It's something that git-based developers simply end up doing occasionally. There are a couple of problems associated with rebasing, though. One of those is that it changes the commit history. Whenever a series of commits is rebased, anybody who was working with the old history is left out in the cold. If a heavily-used tree is rebased, all developers depending on that tree are forced to scramble to readjust to the new reality. The other problem is that rebased patches are changed patches; any testing that they saw may no longer be applicable. That is why Linus tends to grumble hard at trees which have obviously been rebased just prior to the sending of a pull request. The changes in those trees probably worked before the rebase, but the post-rebase changes have not been tested and may not work as well. Rebasing is clearly a useful technique, though. Linus does not tell developers not to use it; in fact, he encourages it sometimes. The key rule that was passed down is this: Thou Shalt Not Rebase Trees With History Visible To Others. If a developer has pulled in somebody else's tree, the resulting tree can no longer be rebased, since that would break the second developer's history. Similarly, once a tree has been exported such that others may be making use of it, it can no longer be rebased. On the other hand, private history can be rebased at will - and it probably should be. If a patch is seen to introduce a bug, it's best to fix it at the source rather than reverting it or adding a second, fixup patch; the result is a cleaner history which is less likely to create problems for people trying to bisect unrelated bugs. Your editor has found that rebasing is often needed to add tags ("Acked-by," for example) to patches which have been circulated for review. When one is creating a set of patches for the mainline kernel, one is really creating an entire history, not just the end result. Making that history clean and readable is to everybody's benefit. The associated rule that goes with this, though, is that trees which are subject to rebasing should not be exposed to the world:
This means: if you're still in the "git rebase" phase, you don't
push it out. If it's not ready, you send patches around, or use
private git trees (just as a "patch series replacement") that you
don't tell the public at large about.
So, in other words, trees which might be rebased should be kept private. They should also not have other developers' trees pulled into them. It's worth noting that Linus very much practices what he preaches on this front. The mainline git repository accepts 10,000 or so changesets every development cycle, but it is never rebased. And that is a good thing: rebasing the mainline would cause massive pain throughout the development community. Merging is the other place where subsystem maintainers can run afoul of the Chief Penguin. A "merge" in git is similar to a merge in most other source code management systems; it joins two (or more) independent lines of development into the current branch. Git merges differ, though, in that they can have more than two incoming branches; Ingo Molnar is famous for his use of "octopus merges" joining vast numbers of branches in a single operation. In almost all cases, performing a merge adds a special commit to the repository indicating that the merge has been done and noting which files, if any, had conflicts. Merges go both ways. When Linus pulls a subsystem tree into the mainline, the result is a merge. But it is also common for developers to perform merges in the other direction; they will pull the mainline (or some higher-level subsystem tree) into a branch containing a local line of development. It is natural to want to develop code against the current state of the art; it gives confidence that the end result will work with everybody else's changes and minimizes the chances of an ugly merge conflict later on. But excessive pulling from the mainline (as evidenced by the merge commits which result) tends to irritate Linus. As he put it:
But if I see a lot of "Merge branch 'linus'" in your logs, I'm not
going to pull from you, because your tree has obviously had random
crap in it that shouldn't be there. You also lose a lot of
testability, since now all your tests are going to be about all my
random code.
As anybody who has worked with tip-of-the-repository kernels knows, the state of the mainline at any random point can be, well, random. So frequent pulling of the mainline into a development branch will add a certain amount of randomness to that branch; this randomness is not particularly helpful for somebody who is trying to get a feature working. It also increases the chances that another developer who ends up in the middle of the series while running a bisect operation will encounter unrelated bugs. So Linus would rather that developers not pull down from upstream trees:
And, in fact, preferably you don't pull my tree at ALL, since
nothing in my tree should be relevant to the development work _you_
do. Sometimes you have to (in order to solve some particularly
nasty dependency issue), but it should be a very rare and special
thing, and you should think very hard about it.
The reality of the situation tends not to be so strict, though. An occasional merge to stay on top of what's happening elsewhere can make sense. What Linus suggests, though, is that the merges happen at specific release points. So pulling the tip of the mainline tree into a development tree probably does not make sense, but there might be an argument for pulling in 2.6.29 or 2.6.30-rc1. Doing things this way allows development to be based on a (hopefully) relatively stable point where the issues are known. The temptation to merge in the mainline during development can be hard to resist; one likes to know whether one's work is even remotely relevant to the current state of the code. Fortunately, git makes it really easy to create throwaway branches and test out merges and integration there. Once it's clear that things work, the test branch can be deleted and the (unmerged) development branch sent upstream. Similar rules apply to the merging of downstream code. The receiving repository should be in a reasonably well defined and stable state; typically developers maintain a "for upstream" branch for this kind of merge. And the downstream code should be "ready": it should be at some sort of release point and not in a random state of development. Of course, these rules are not absolute:
Git does allow people to do many different things, and solve
problems different ways. I just want all the regular workflows to
be "good practice", but then if you have to occasionally break the
rules to solve some odd problem, go ahead and break the rules (and
tell people why you did it that way this time).
Linus first started playing with BitKeeper in February, 2002, so the kernel community now has seven years worth of experience with distributed version control. But the truth of the matter is that we are still figuring out the best way to use this particular tool. This is a process which is likely to continue for some time yet. As other large projects move toward using tools like git, they may want to look hard at the processes and rules which have been developed in the kernel community; they might just be able to shorten their own learning experience.
Solving the ext3 latency problemOne might think that the ext3 filesystem, by virtue of being standard on almost all installed Linux systems for some years now, would be reasonably well tuned for performance. Recent events have shown, though, that some performance problems remain in ext3, especially in places where the fsync() system call is used. It's impressive what can happen when attention is drawn to a problem; the 2.6.30 kernel will contain fixes which seemingly eliminate many of the latencies experienced by ext3 users. This article will look at the changes that were made, including a surprising change to the default journaling mode made just before the 2.6.30-rc1 release.The problem, in short, is this: the ext3 filesystem, when running in the default data=ordered mode, can exhibit lengthy stalls when some process calls fsync() to flush data to disk. This issue most famously manifested itself as the much-lamented Firefox system-freeze problem, but it goes beyond just Firefox. Anytime there is reasonably heavy I/O going on, an fsync() call can bring everything to a halt for several seconds. Some stalls on the order of minutes have been reported. This behavior has tended to discourage the use of fsync() in applications and it makes the Linux desktop less fun to use. It's clearly worth fixing - but nobody did that for years. When Ted Ts'o looked into the problem, he noticed an obvious problem: data sent to the disk via fsync() is put at the back of the I/O scheduler's queue, behind all other outstanding requests. If processes on the system are writing a lot of data, that queue could be quite long. So it takes a long time for fsync() to complete. While that is happening, other parts of the filesystem can stall, eventually bringing much of the system to a halt. The first fix was to mark I/O requests generated by fsync() with the WRITE_SYNC operation bit, marking them as synchronous requests. The CFQ I/O scheduler tries to run synchronous requests (which generally have a process waiting for the results) ahead of asynchronous ones (where nobody is waiting). Normally, reads are considered to be synchronous, while writes are not. Once the fsync()-related requests were made synchronous, they were able to jump ahead of normal I/O. That makes fsync() much faster, at the expense of slowing down the I/O-intensive tasks in the system. This is considered to be a good tradeoff by just about everybody involved. (It's amusing to note that this change is conceptually similar to the I/O priority patch posted by Arjan van de Ven some time ago; some ideas take a while to reach acceptance). Block subsystem maintainer Jens Axboe disliked the change, though, stating that it would cause severe performance regressions for some workloads. Linus made it clear, though, that the patch was probably going to go in, and that, if the CFQ I/O scheduler couldn't handle it, there would soon be a change to a different default scheduler. Jens probably would have looked further in any case, but the extra motivation supplied by Linus is unlikely to have slowed this process down. The problem, as it turns out, is that WRITE_SYNC actually does two things: putting the request onto the higher-priority synchronous queue, and unplugging the queue. "Plugging" is the technique used by the block layer to issue requests to the underlying disk driver in bursts. Between bursts, the queue is "plugged," causing requests to accumulate there. This accumulation gives the I/O scheduler an opportunity to merge adjacent requests and issue them in some sort of reasonable order. Judicious use of plugging improves block subsystem performance significantly. Unplugging the queue for a synchronous request can make sense in some situations; if somebody is waiting for the the operation, chances are they will not be adding any adjacent requests to the queue, so there is no point in waiting any longer. As it happens, though, fsync() is not one of those situations. Instead, a call to fsync() will usually generate a whole series of synchronous requests, and the chances of those requests being adjacent to each other is fairly good. So unplugging the queue after each synchronous request is likely to make performance worse. Upon identifying this problem, Jens posted a series of patches to fix it. One of them adds a new WRITE_SYNC_PLUG operation which queues a synchronous write without unplugging the queue. This allows operations like fsync() to create a series of operations, then unplug the queue once at the end. While he was at it, Jens fixed a couple of related issues. One was that the block subsystem can still sometimes run synchronous requests behind asynchronous requests in some situations. The code here is a bit tricky, since it may be desirable to let a few asynchronous requests through occasionally to prevent them from being starved entirely. Jens changed the balance to ensure that synchronous requests get through in a timely manner. Beyond that, the CFQ scheduler uses "anticipatory" logic with synchronous requests; upon executing one such request, it will stall the queue to see if an adjacent request shows up. The idea is that the disk head will be ideally positioned to satisfy that request, so the best performance is obtained by not moving it away immediately. This logic can work well for synchronous reads, but it's not helpful when dealing with write operations generated by fsync(). So now there's a new internal flag that prevents anticipation when WRITE_SYNC_PLUG operations are executed. Linus liked the changes:
Goodie. Let's just do this. After all, right now we would otherwise
have to revert the other changes as being a regression, and I
absolutely _love_ the fact that we're actually finally getting
somewhere on this fsync latency issue that has been with us for so
long.
It turns out that there's a little more, though. Linus noticed that he was still getting stalls, even if they were much shorter than before, and he wondered why:
One thing that I find intriguing is how the fsync time seems so
_consistent_ across a wild variety of drives. It's interesting how
you see delays that are roughly the same order of magnitude, even
though you are using an old SATA drive, and I'm using the Intel
SSD.
The obvious conclusion is that there was still something else going on. Linus's hypothesis was that the volume of requests pending to the drive was large enough to cause stalls even when the synchronous requests go to the front of the queue. With a default configuration, requests can contain up to 512KB of data; stack up a couple dozen or so of those, and it's going to take the drive a little while to work through them. Linus experimented with setting the maximum size (controlled by /sys/block/drive/queue/max_sectors_kb) to 64KB, and reports that things worked a lot better. As of this writing, though, the default has not been changed; Linus suggested that it might make sense to cap the maximum amount of outstanding data, rather than the size of any individual request. More experimentation is called for. There is one other important change needed to get a truly quick fsync() with ext3, though: the filesystem must be mounted in data=writeback mode. This mode eliminates the requirement that data blocks be flushed to disk ahead of metadata; in data=ordered mode, instead, the amount of data to be written guarantees that fsync() will always be slower. Switching to data=writeback eliminates those writes, but, in the process, it also turns off the feature which made ext3 seem more robust than ext4. Ted Ts'o has mitigated that problem somewhat, though, by adding in the same safeguards he put into ext4. In some situations (such as when a new file is renamed on top of an existing file), data will be forced out ahead of metadata. As a result, data loss resulting from a system crash should be less of a problem.
Sidebar: data=guardedAnother alternative to data=ordered may be the data=guarded mode proposed by Chris Mason. This mode would delay size updates to prevent information disclosure problems. It is a very new patch, though, which won't be ready for 2.6.30. So Ted suggested that, maybe, data=writeback should be made the default. There was some resistance to this idea; not everybody thinks that ext3, at this stage of its life, should see a big option change like that. Linus, however, was unswayed by the arguments. He merged a patch which creates a configuration option for the default ext3 data mode, and set it to "writeback." That will cause ext3 mounts to silently switch to data=writeback mode with 2.6.30 kernels. Says Linus:
I'm expecting that within a few months, most modern distributions
will have (almost by mistake) gotten a new set of saner defaults,
and anybody who keeps their machine up-to-date will see a smoother
experience without ever even realizing _why_.
It's worth noting that this default will not change anything if (1) the data mode is explicitly specified when the filesystem is mounted, or (2) a different mode has been wired into the filesystem with tune2fs. It will also be ineffective if distributors change it back to "ordered" when configuring their kernels. Some distributors, at least, may well decide that they do not wish to push that kind of change to their users. We will not see the answer to that question for some months yet.
Hotplug file descriptors and revoke()Once upon a time, operating systems did not have to worry about hardware coming and going at awkward times. Whatever peripherals were bolted into the box when the system booted could be counted on to still be there at shutdown time. Contemporary systems don't work that way; devices will come and go at the whim of the user. Various subsystems have evolved mechanisms for coping with hardware which suddenly vanishes, but that code tends to be subsystem-specific and complex. Eric Biederman recently encountered this code and didn't really like what he saw. So he has set out to make something better.Eric's patch series begins with this observation:
Not long after I touched the tun driver and made it safe to delete
the network device while still holding it's file descriptor open I [saw]
someone else touch the code adding a different feature and my
careful work went up in flames. Which brought home another point:
at the best of it this is ultimately complex tricky code that
subsystems should not need to worry about.
Eric also notes that the growth in hotplug-capable PCI devices will increase the number of subsystems and drivers which need to be prepared for this eventuality. Rather than spread hotplug-specific code through more parts of the kernel, he would like to create one central, well-supported mechanism. The issue that Eric is looking at in particular is: what happens to open file descriptors when the underlying resource goes away? Regardless of whether that resource is a physical device, a module, or something different altogether, the kernel needs to do a right thing when the file descriptor no longer points to something valid. Eric's patches create a new infrastructure which allows any subsystem to easily revoke access to a file descriptor in a more reliable and robust manner than has been seen before. The first issue that comes up is, invariably, mmap(). If a no-longer-existing device or file has been mapped into a process's address space, interesting and unpleasant things could happen. Eric's answer is a new function:
void remap_file_mappings(struct file *file,
struct vm_operations_struct *vm_ops);
A call to remap_file_mappings() will locate every virtual memory area (VMA) associated with the given file. All mapped pages will be unmapped, making them inaccessible to the process which had mapped them. The operations associated with the VMA will be replaced with vm_ops; those operations will normally be revoked_vm_ops, which simply return a bus error whenever the process attempts to access one of the affected pages. The kernel also clearly needs to block any other operations - read(), write(), ioctl(), etc. - which might be performed on this file descriptor. The way to do that, of course, is to replace the file_operations structure associated with the file. The function to do that is:
int fops_substitute(struct file *file, const struct file_operations *f_op,
struct vm_operations_struct *vm_ops);
One might imagine that this function could be quite simple, along the lines of:
file->f_op = f_op;
remap_file_mappings(file, vm_ops);
But the truth of the matter is rather more complicated. To begin with, there may be threads running in the old file operations, and some of those might be waiting for events which will, now, never happen. As a way of helping drivers unwedge themselves in this situation, Eric's patches add a new entry to struct file_operations:
int (*awaken_all_waiters)(struct file *filp);
This function should cause any thread which is waiting for the given file to wake up and take note that the world has changed. The next sticking point is that, now that the file operations have been swapped out, there is no way for the underlying driver to know when all file descriptors have been closed. That is handled by waiting until there are no more known users of the old file operations, then calling the release() function directly from fops_substitute(). That leads to the sticky question of what happens if some thread never wakes up and the usage count never goes to zero; in the current patch, fops_substitute() will simply hang in this situation. Before one can even worry about that, though, there is the troublesome point that the kernel has no idea how many users of a given file_operations structure exist. So Eric has had to add a reference counting mechanism. In the new way of doing things, any kernel code must bracket calls into a file's file_operations with:
int fops_read_lock(struct file *file);
void fops_read_unlock(struct file *file, int revoked);
The return value from fops_read_lock() (which Eric invariably calls fops_idx) is non-zero if access to the file has already been revoked; it must be passed into the matching call to fops_read_unlock(). The biggest part of the patch series is a slog through the core VFS code adding locking around every file_operations access. That's a lot of little code changes which have to be made in a lot of places. There is a payoff, though: the handling of revoked files in various other subsystems can be ripped out and replaced with the new, generic code. The changes to the /proc filesystem, for example, leave the code almost 400 lines shorter. So the kernel gets smaller, and the new code, should, with luck, be more robust and more maintainable. This mechanism is useful for situations where devices disappear, but there is also a bigger goal in sight. There has long been a desire for a generic revoke() system call which would disconnect all open descriptors to a given file or device. It could be used to implement some sort of secure attention key, killing all processes which have open file descriptors to a console device, for example. revoke() would also be useful for forced unmounting of filesystems. It's a useful idea, with only one problem: revoke() is really hard. Nobody has yet come through with an implementation that looks complete and robust enough to be put into the kernel. Eric's patch set has not gotten there yet either. But it does represent another stab at the problem using an approach which, most developers agree, is the way that revoke() needs to be implemented. Over time, it might just evolve into the general solution which has evaded other developers for years.
Patches and updates Kernel trees
Core kernel code
Development tools
Device drivers
Documentation
Filesystems and block I/O
Memory management
Networking
Architecture-specific
Security-related
Virtualization and containers
Benchmarks and bugs
Miscellaneous
Page editor: Jonathan Corbet Distributions News and Editorials ALT LinuxALT Linux is well-known in Russia, but less well-known in other parts of the world. Up until recently the web site has only been available in Russian, but now more parts of the wiki have been translated to English. ALT Linux got its start years ago as a Russian localization of the pre-Mandriva Mandrake Linux. The last release before forking away from those roots was the Linux-Mandrake Russian Edition Spring 2001. After that the ALT Linux team created Sisyphus, the development tree from which stable releases are now branched. Sisyphus is the heart of ALT. It's an APT-enabled RPM package repository with some unique tools, available with git. Developed by an international team of developers, Sisyphus supports x86 and x86-64 architectures with ports to ARM and PowerPC underway. Some the tools in Sisyphus include: hasher, a tool for building packages in safe and repeatable manner; gear, a tool for building RPM packages from git repositories; and Alterator, a system configuration framework. Sisyphus is regularly branched to create a family of stable distributions which are supported by the Russian company ALT Linux Ltd. The company now has an office in Brazil as well. Stable distributions are available for servers, development platforms, personal and business desktops, terminal servers for schools, and more. Russian schools started deploying ALT's Free Software Suite (FSS) in 2008 in over 1000 schools within three pilot regions. Other schools from outside those regions also participated so that more than 2000 schools now use some form of ALT Linux. The ALT Linux Software Developer Kit is available to help educational facilities customize their distributions. Alexey Rusakov, the current project manager of ALT Linux. In this February 2009 interview in How Software is Built, he talks about ALT's roots, and Free Software in Russia. The success of GNU/Linux in Russia was very much concerned with these ideas that software should be obtained legally and that some software can be distributed and modified legally. Copying or fixing something for each other is a usual thing in Russia, and Free Software fits better to our mentality. At the present time, there is already a serious movement toward Free Software in areas where there is not much money. These areas are very significant, including medical, educational, and other government-controlled institutions. Business structures also started adopting GNU/Linux, mainly because it gives more freedom in copying and installing as well as in changing and customizing it as needed. ALT Linux seems to be well poised to become a definitive free software solution in Russia and beyond. Its foothold in Russian schools could pave its way into the Russian government. Translations into other languages, first English and then Brazilian Portuguese will help ALT expand into a global market.
New Releases Debian GNU/Linux updatedThe Debian Project has announced a revision to the old stable distribution Debian 4.0 (etch), now at 4.0r8.The current stable version (5.0 lenny) has also been updated to v5.0.1. Note the new versioning scheme for revisions.
Fedora 11 Snapshot 1A snapshot of Fedora 11 is available for testing. This snapshot is the the penultimate testing release, to be followed by the preview release later this month. "Lots of work has gone into the storage code of Anaconda since the Beta release, please do re-test with these images if you had difficulty installing the Beta."
Kubuntu Jaunty KDE 3 Remix BetaKubuntu has announced a remix of Kubuntu Jaunty Jackalope (9.04) with KDE 3.5, currently available as a beta. See the release notes for more information.
PC-BSD 7.1iXsystems has announced the release of PC-BSD 7.1, Galileo Edition. "PC-BSD 7.1 is built upon the FreeBSD 7.1-STABLE operating system. FreeBSD is a UNIX-based operating system that provides a high level of security and stability. The Galileo Edition of PC-BSD includes updated versions of KDE (4.2.2) and Xorg (7.4). The latest version of KDE includes new window effects, screen savers, and better 3D Acceleration. PC-BSD exclusively features the Push Button Installer (PBI), a push-button software installation wizard with a wide range of applications. The latest version of the Push Button Installer improves PBI self-containment to increase reliability."
Untangle 6.1 Hits the StreetsUntangle has announced the release of version 6.1 of its Debian Lenny based gateway distribution. "The highlight of the release is our new app, Commtouch Spam Booster, but there are several other significant upgrades and enhancements as well. Please see the 6.1 changelog for a comprehensive list of everything new and shiny."
Fixstars Launches Yellow Dog Enterprise Linux v6.1 for CellFixstars has announced the release of Yellow Dog Enterprise Linux (YDEL) v6.1. "This release introduces important performance improvements as well as new features for the world's only Linux OS built specifically for the Cell Broadband Engine. In addition to providing continued support for Fixstars GigaAccel 180 and IBM QS2x blades, YDEL v6.1 now offers support for the Sony PlayStation3 and IBM JS2x series blades."
Distribution News Debian GNU/Linux Steve McIntyre is re-elected as Debian project leaderCurrent Debian project leader Steve McIntyre will also be the new project leader starting on April 17th. McIntyre was declared the winner over the other candidate, Stefano Zacchiroli, using the Condorcet voting method. More information can be found on the voting page as well as by clicking below.
Bits from the Debian Installer teamThe Debian Installer team had two meetings to discuss the future, organization and technical challenges for the Lenny->Squeeze release cycle. "This "Bits from the D-I team" post represents the minutes of these two meetings and will summarise decisions and discussions that happened during the meetings."
DebConf8 final report / deadline remindersThe organizers of last year's DebConf8 in Argentina have put the finishing touches on the final report. The DebConf9 deadline for visa assistance is April 30, 2009. DebConf9 will be in Cáceres, Spain, July 24-30, 2009.
Fedora Fedora Board Meeting Recap 2009-04-07Click below for a brief recap of the April 7, 2009 meeting of the Fedora Advisory Board. Topics include QA briefing and some questions & answers.
Gentoo Linux Initial summary for Gentoo Council meetingThe Gentoo Council met on April 9, 2009; click below for a summary. Topics include Migration of KEYWORDS out of ebuilds, EAPI 3 features block and EAPI 3 updates.
Mandriva Linux Smolt in Mandriva (Frederik's Blog)Smolt, a hardware profiling tool developed for Fedora, is now in Mandriva Cooker (development branch). "On the smolts.org website, people can view all hardware entries and indicate which one is working OK for them. The database is also coupled with a wiki, where extra instructions can be written to get the hardware working. Smolt is used by default already for some time in Fedora and also in OpenSUSE." (Thanks to Rahul Sundaram)
SUSE Linux and openSUSE openSUSE Board Meeting Minutes, March 25Click below for a look at the minutes for the openSUSE Board meeting for March 25, 2009. Topics include Trademark guide lines, Improvement of IRC cloak and email address handling, openSUSE conference, openSUSE Foundation and more.
Ubuntu family Ubunchu! An Ubuntu MangaUbunchu! is a Japanese manga (comic) by Hiroshi Seo. The story follows three students in a system administration club as they try out Ubuntu. The manga is now available in English, as well as Spanish and Korean. There is also a Launchpad project for collaboration.
Distribution Newsletters Ubuntu Weekly Newsletter #137The Ubuntu Weekly Newsletter for the week ending April 11, 2009 is out. "In this issue we cover: Archive frozen in preparation of Ubuntu 9.04, Ubuntu 7.10 reaches EOL April 18th, Ubuntu Open Week, QA Team: Next Testing Day, LoCo Team news(New York, Florida, Nebraska, Australia, and Tunisia), Updating the PPA Docs, Meet Gavin Panella, Expanding the Forum Council, New Staff in Town, apt URLs now available on the Ubuntu Wiki, More Easter eggs in Ubuntu, Bookmarkftp update, Running Ubuntu: literally, Ubunchu the Ubuntu Manga is now in English, Ubuntu Server Team meeting minutes, and much, much more!"
OpenSUSE Weekly News/67This edition of the OpenSUSE Weekly News covers: OBS will be added to LDN, People of openSUSE: Sascha Manns, Jigish Gohil: Most efficient Ways to Download, polishlinux: KDE 4.3 - early preview, tuxmachines.org: We're Linux" Video Contest Winners, and several other topics.
Fedora Weekly News #171The Fedora Weekly News for the week ending April 12, 2009 is out. "Our latest issue includes important Announcements about Fedora 11 and freeze statuses. Ambassadors celebrates the way "Italians Fete Document Freedom Day" and "LinuxFest Northwest Ramps Up". Developments relays some fraught conversations about "Emacs, Glibc, Malloc and i586" and cautions that "Mono Breakage on PPC May Cause Reversion". Translations keys us in to the "Fedora 11 Release Notes Discussion". Artwork provides insight into "Finishing the Artwork for Fedora 11". Virtualization reports on the "Virtualization Technology Preview Repo.""
DistroWatch Weekly, Issue 298The DistroWatch Weekly for April 13, 2009 is out. "Recently the latest version of perhaps the world's most friendly BSD distribution was released. PC-BSD 7.1 is based off FreeBSD and we take a first look at this interesting operating system. In the news, Novell's Online Build Service, recently added to the Linux Foundation's Developer Network, gains support for the ARM processor, Moblin sets its sight on a 2-second boot, Fedora re-issues 64-bit images of its recent beta release of version 11, FreeBSD hits 20,000 packages in its ports directory, Debian announces the final results of the project leader elections, and Kubuntu releases a KDE 3 remix of its 9.04 Jaunty Jackalope beta. Finally, don't miss the first episode of "Ubunchu!" the world's first open source manga featuring Ubuntu Linux. Happy reading!"
Distribution meetings FUDCon Berlin 2009 & LinuxTag 2009FUDCon Berlin and LinuxTag are about 2 months away. The FUDCon will be co-located with LinuxTag. Click below for the FUDCon schedule.
Interviews April tribute to the Fedora Project art team (Linux Graphics Users.com)In the Linux Graphics Users forum, there is an interview with the Fedora art team, which looks at graphics tools as well as how the art team operates. It also gives some advice that would be useful for others who want to put together such a team for their project. "Nicu Buculei- The general community is contributing indirectly: we try to do everything in the open, publishing the progress of our work and asking for the feedback from the larger community and then using the feedback to improve the graphics. [...] As an example, for Fedora 11 Máirín Duffy conducted an informal survey on her blog and learned that a lot of users prefer a photo realistic wallpaper, so we are trying such an approach for the next release. Since the graphics are included in the Beta release, we are eagerly awaiting for the post-Beta feedback in a few days."
Distribution reviews SUSE Linux Enterprise Server 11 Is (Almost) All Things to All Companies (eWeek)eWeek reviews SUSE Linux Enterprise Server 11. "[Sites] upgrading to SLES 11 from SLES 10 should be pleasantly surprised at the software management system that graces the new version--it performs much better than the framework that shipped with Version 10. The newer system is still based on RPM, but now includes the back-end tool zypper, which, across a few years of OpenSUSE releases, had the opportunity to mature into a very effective software management tool."
Portable Ubuntu: The Easy New Way To Try Linux (bMighty)bMighty takes a look at Portable Ubuntu. "Portable Ubuntu is actually based on another Linux distro, known as Cooperative Linux or coLinux. The coLinux distro is designed to allow a LInux kernel and Windows to run simultaneously on the same system. As a result, coLinux has spawned some projects similar to Portable Ubuntu that run other distros; TopologiLinux, for example, runs Slackware, a popular community-supported Linux distro."
Page editor: Rebecca Sobol Development Alternatives to SQL DatabasesTraditional SQL databases with "ACID" properties (Atomicity, Consistency, Isolation and Durability) give strong guarantees about what happens when data is stored and retrieved. These guarantees make it easier for application developers, freeing them from thinking about exactly how the data is stored and indexed, or even which database is running. However, these guarantees come with a cost. Bob Ippolito presented a talk titled "Drop ACID and think about data" at PyCon 2009, which gave an overview of number of non-traditional databases. These alternatives compromise one or more of the ACID properties and expose the particulars of that data store's implementation in exchange for improved performance or scalability. Each also has its own limitations. This article will look at the more mature open source options Ippolito mentioned. A number of companies have developed their own in-house data stores, including Amazon's Dynamo and Google's Bigtable. While none of the open source options are exactly like Dynamo or Bigtable, there are a number of high-performance, reliable and scalable options available.
CassandraCassandra is a data store written in Java that was open-sourced by Facebook and is now part of the Apache Incubator. Cassandra was originally designed to solve Facebook's in-box searching problem. Email reverse indexes were growing much faster than their databases could keep up with and they needed a affordable way to continue to grow. Cassandra is designed to scale inexpensively with commodity networking equipment and servers, possibly in multiple data centers. Scalability and high availability are achieved by automatically "sharding" and replicating data across the servers and data centers. A single Cassandra instance stores a single table, and each row is accessed with a key string. Every row of this table can have its own structure, storing a huge number of (key, value, time-stamp) tuples and/or nested columns. This makes Cassandra much more flexible than a simple key-value store, but not as general as a document database. Although in heavy use by Facebook, Cassandra is early in development and still lacks some polish and documentation. MemcachedPerhaps the simplest key-value store is Memcached. Memcached is widely used to to speed up web applications by caching dynamic content. Part or all of the web pages are served from the cache instead of generating them at each request. Unlike in-process or shared memory caches, Memcached listens on a network socket and can be shared by many servers. Memcached may also be run on multiple servers and it will spread the keys across those servers and transparently fall back to servers that are still available when one goes down. Memcached keys and values are always strings. In addition to storing, retrieving and deleting values, it allows atomic appending/prepending string data to stored values and addition to/subtraction from 64-bit integer values stored as decimal strings. Memcached's data store is a fixed size and resides entirely in-memory. Data may be stored with an expiration time. Memcached will actively throw out data when the cache is full or when the data is set to expire. Tokyo CabinetFor a key-value data store that won't throw out data, Tokyo Cabinet is a good choice. Like Berkeley DB, it uses either a hash table, B+ tree or a array of fixed-length records to store data on disk, but Tokyo Cabinet performs better and is thread safe. Tokyo Cabinet also promises to never corrupt data even in a "catastrophic situation". Tokyo Cabinet is actively maintained, and data stored is not limited by system RAM. Tokyo Cabinet clients are separated into readers and writers. When a writer is accessing the database all other clients are blocked. This will result in poor performance for write-heavy workloads. Tokyo Cabinet supports appending data to values stored. When using a B+ tree layout Tokyo Cabinet provides a cursor object to efficiently move forward and backward through the keys. B+ tree pages may also be compressed on disk with zlib or bzip2. Compressing data not only saves disk space, but can also increase performance on I/O-bound systems. RedisRedis is a disk-backed, in-memory key-value store with a number of additional features. Redis supports master-slave replication for redundancy, but not sharding, so all data must fit in a single system's RAM. Redis values may be binary strings, lists or sets. Redis provides atomic addition to/subtraction from integer values stored as decimal strings and push/pop/replacement of values in lists. The intersection of set values stored may also be calculated. Redis can asynchronously save the database on request by forking the server process and writing out data in the background. The last successful save time may be queried to check when the changes have made it to disk. This design allows for good performance with the ability to save data when it makes sense for the particular application, but the application is responsible to make sure data is properly saved. When using any key-value store as a cache care must be taken to invalidate values when the data changes or inconsistency will be introduced. Choosing a memory-only cache will be faster once it is populated, but there is a cost associated with filling an empty cache on restart. Key-Value stores are ideal for storing data that is not deeply nested and does not require complicated locking. CouchDBDocument databases are designed to store large blocks of semi-structured data. The data is not restricted to a particular schema, so new versions of data can be stored alongside old versions without the need for migrations. Documents can be very large and deeply nested. CouchDB is a JSON-based document database written in Erlang. CouchDB gives access to the database over HTTP with a RESTful API. Views of the database may be created on demand using Javascript to collect and filter document contents and are updated as documents change. Indexes are not maintained outside of views, so there is a start-up cost associated with constructing a new view. CouchDB documents are stored with a sequence number and are never overwritten, this way partial writes will never result in data corruption. Readers are never blocked by writers and will always see a consistent snapshot of the database while reading data. The data is periodically compacted by writing out a new data file and deleting the original once it is no longer being accessed. CouchDB uses peer based asynchronous replication. Documents may be updated on any peer, allowing for good write throughput. Conflicts will occur when two clients update the same document, and multiple conflicting documents may coexist in the database. A deterministic method is used to decide which document will be treated as the latest version. This lets CouchDB leave conflict resolution to the application. Once a conflict is resolved the new version is stored in the database as usual. MongoDBMongoDB is a document database written in C++. MongoDB uses a binary-encoded JSON format that shrinks the data size and allows for faster searching and indexing. Large binary data, such as video files, can also be stored more efficiently in this format. Data is updated in place and MongoDB will automatically run a repair procedure on the database in the event of an unclean shutdown. MongoDB documents may be nested or include references to other documents. References will be replaced with the value of the referenced document when queried. MongoDB supports persistent single or compound key indexes. Indexes are implemented as B-Trees and queries will automatically take advantage of all indexes available. Queries may include common conditional operators, membership testing and values in embedded documents. MongoDB has auto-sharding support, splitting documents across many servers so that data stored is not limited by the capacity of a single server. MongoDB also supports asynchronous replication for high availability. Choosing a Data StoreThe best data store for an application depends in large part on how deeply nested the values stored will be. If the application needs to only store strings and integers then a simple key-value store like Memcached, Tokyo Cabinet or Redis would be best. If the values can be represented as lists and sets of simple values then Tokyo Cabinet, Redis or Cassandra would be good options. If the application needs nested lists and hashes then choose Cassandra, CouchDB or MongoDB. Finally, if the values contain deeply nested data then only a document database like CouchDB or MongoDB will do. Once a data store has been chosen and and the application optimized for it, switching to a completely different API will not be easy. It is worth investing time evaluating the remaining options by writing code to simulate the application's usage patterns before making a choice.
System Applications Audio Projects PulseAudio 0.9.15 releasedVersion 0.9.15 of the PulseAudio sound server has been announced, Bluetooth support is now complete. See the change log for details. Also, version 0.9.8 of PulseAudio Volume Control has been announced.
Rivendell 1.4.0 releasedVersion 1.4.0 of Rivendell has been announced, several new capabilities have been added. "Rivendell is a full-featured radio automation system targeted for use in professional broadcast environments. It is available under the GNU General Public License."
Database Software PostgreSQL 8.4 BetaThe beta release of PostgreSQL 8.4 is out; the PostgreSQL developers are looking for testers to help find the remaining bugs. There's a lot of new features in this release; see the announcement (click below) for the list of the most important additions.
PostgreSQL Weekly NewsThe April 12, 2009 edition of the PostgreSQL Weekly News is online with the latest PostgreSQL DBMS articles and resources.
SQLite release 3.6.13 announcedVersion 3.6.13 of the SQLite DBMS has been announced, several bugs have been fixed.
Device Drivers libshcodecs 0.9.5 releasedVersion 0.9.5 of libshcodecs has been announced. "libshcodecs is a library for controlling SH-Mobile hardware codecs. The [SH-Mobile] processor series includes a hardware video processing unit that supports MPEG-4 and H.264 encoding and decoding. libshcodecs is available under the terms of the GNU LGPL."
Embedded Systems BusyBox 1.14.0 and 1.13.4 releasedStable version 1.13.4 and unstable version 1.14.0 of BusyBox have been announced, many changes have been added. "Most of growth is in hush. The rest shrank a bit."
Filesystem Utilities Announcing Tahoe-LAFS version 1.4Version 1.4 of Tahoe-LAFS has been announced. "The allmydata.org team is pleased to announce the release of version 1.4.1 of "Tahoe", the Lightweight-Authorization Filesystem. This is the first release of Tahoe-LAFS which was created solely as a labor of love by volunteers -- it is no longer funded by allmydata.com (see [1] for details). Tahoe-LAFS is a secure, decentralized, fault-tolerant cloud storage system. All of the source code is publicly available under Free Software, Open Source licences."
LDAP Software LDAP Account Manager: 2.6.0 released (SourceForge)Version 2.6.0 of LDAP Account Manager has been announced. "PHP based tool for managing various account types (Unix, Samba, Kolab, ...) in an LDAP directory. This release adds support for the management of NIS netgroups and EDU person accounts. The LAM admin users can now be searched in LDAP instead of providing a static list. LAM Pro allows you to adopt it to your corporate design."
python-ldap 2.3.7 releasedVersion 2.3.7 of python-ldap has been announced, it includes numerous bug fixes. "python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema)."
Security announcing ClamAV 0.95.1Version 0.95.1 of the ClamAV virus scanner has been announced. "0.95.1 is a bugfix release, please see the ChangeLog at http://freshmeat.net/urls/7065abfc92b936d016260efff5f9c67f for details."
Web Site Development GreasySpoon: release 0.5.4 available (SourceForge)Version 0.5.4 of GreasySpoon has been announced. "GreasySpoon is an scripting solution allowing to easily manipulate HTTP traffic: access control, content filtering, cross-domain management, mashups, etc. GreasySpoon relies on ICAP protocol and is designed to work with any ICAP compatible proxy like Squid. Version 0.5.4 fixes several bugs and includes some optimisations."
Midgard2 9.03.0 RC releasedVersion 9.03.0 RC of the Midgard2 web content management system has been announced. "The Midgard Project has released first Release Candidate of Midgard2 9.03 "Vinland" - the new generation of the Midgard content repository."
mod_wsgi 2.4 announcedVersion 2.4 of mod_wsgi is available. "The mod_wsgi package consists of an Apache web server module designed and implemented specifically for hosting Python based web applications that support the WSGI interface specification. Examples of major Python web frameworks and applications which are known to work in conjunction with mod_wsgi include CherryPy, Django, MoinMoin, Pylons, Trac, TurboGears, Werkzeug and Zope. Version 2.4 of mod_wsgi is principally a bug fix update. It fixes memory leaks, configuration corruption, truncation of request/response data and other minor issues. A small number of other minor improvements have also been made."
Pyjamas 0.5p1 releasedVersion 0.5p1 of Pyjamas has been announced. "Pyjamas 0.5p1 is a bug-fix release. Pyjamas is a Web Widget Framework, written in python, that is compiled to javascript using its stand-alone python-to-javascript compiler. It began as a port of GWT, to python."
Desktop Applications Audio Applications Amarok 2.1 Beta 1 'Nuliajuk' released (KDEDot)KDE.News covers the first beta release of the Amarok 2.1 music player. "Featuring one of the longest ChangeLogs in Amarok history, this beta release showcases what is possible when building on the strong technical foundations that have been laid with Amarok 2.0. Nearly all parts of Amarok have received attention, and while not a final release, it is already very usable and quite stable."
CAD pythonOCC 0.2 releasedVersion 0.2 of pythonOCC has been announced. "We're really proud to announce this new release, which is really a huge step far from the previous one and closer to our main goal: provide an easy-to-use, deploy, maintain and industrial quality python CAD package. Here are the main changes: 'wo' stands for 'Whole OpenCascade': almost the whole OCC API (about 90%) is now covered by the wrapper. Pleat read this file to lists available modules, *memory leaks were fixed *pythonOCC comes now with a complete set of sample scripts *the licence was moved to the GNU General Public License v3 *many bugfixes and improvements."
Desktop Environments GNOME 2.26.1 releasedStable version 2.26.1 of the GNOME desktop environment has been announced. "This is the first update to GNOME 2.26. It contains the usual mixture of bug fixes, translations updates and documentation improvements that are the hallmark of stable GNOME releases, thanks to our wonderful team of GNOME contributors! The next stable version of GNOME will be GNOME 2.26.2, which is due on May 20. Meanwhile, the GNOME community is actively working on the development branch of GNOME that will become GNOME 2.28 in late September 2009."
GNOME Software AnnouncementsThe following new GNOME software has been announced this week:
KDE Software AnnouncementsThe following new KDE software has been announced this week:
Xorg Software AnnouncementsThe following new Xorg software has been announced this week:
Electronics GNU Radio 3.2 release candidate 2 is availableRelease candidate 2 of GNU Radio 3.2, a software-defined radio platform, has been announced. "This release contains all the features, fixes, and bugs of the GNU Radio development trunk as of 4/14/09. Our goal is for this to be the last release candidate before the formal 3.2 release."
Graphics JessyInk 1.0 releasedVersion 1.0 of JessyInk has been announced, this is the first stable release. "JessyInk is a JavaScript that can be incorporated into an Inkscape SVG image containing several layers. Each layer will be converted into one slide of a presentation. Current features include: slide transitions, effects, an index sheet, a master slide and auto-texts like slide title, slide number and number of slides."
Interoperability Wine 1.1.19 announcedVersion 1.1.19 of Wine has been announced. Changes include: "Support for Visual C++ project files in winemaker. Improvements to the Esound driver. Many Direct3D code cleanups. Fixes to OLE clipboard handling. OpenBSD compilation fixed. Various bug fixes."
Medical Applications Updated open source releases within OpenVista project (LinuxMedNews)LinuxMedNews covers the latest release of OpenVista. "Medsphere today announced the release of open source code for recently developed components of the comprehensive OpenVista electronic health record (EHR) solution. Medspheres open source release, now available for download at www.medsphere.org, includes the OpenVista Interface Domain (OVID), the OpenVista Clinical Information System (CIS) 1.0RC1, and OpenVista Server 1.5SP1."
Multimedia Oggz 0.9.9 releasedVersion 0.9.9 of Oggz, a library and tool set for working with Ogg files, has been announced. "Features: 0.9.9 adds Dirac support, security fixes, improved low-memory behaviour, and a new 'oggz' wrapper tool with bash completion."
Music Applications FluidSynth 1.0.9 releasedVersion 1.0.9 of FluidSynth has been announced. "On behalf of the FluidSynth team I'm very happy to announce the release of version 1.0.9 - "A Sound Future". The nickname for this release was chosen based on the recent development interest in the project and the addition of new team members. This last development cycle is the result of contributions from many individuals. The future of FluidSynth is looking bright and we are working to create a more regular release schedule and plan for innovation and improvement."
gdigi 0.1.7 releasedVersion 0.1.7 of gdigi has been announced. "Control your Digitech effect pedal under Linux! gdigi is tool aimed to provide X-Edit functionality to Linux users". See the change log for more information on this release.
Office Applications KeepNote 0.5.2 announcedVersion 0.5.2 of KeepNote has been announced, many new features have been added. "KeepNote is a simple cross-platform note taking program implemented in Python. I have been using it for my research and class notes, but it should be applicable to many note taking situations."
Science EAS3 version 1.6.7 released (SourceForge)Version 1.6.7 of EAS3, the Eingabe Ausgabe System, has been announced. "EAS3 is a toolkit for writing and manipulating IEEE binary floating point data. It provides libraries and a comand line interface for data manipulation. The file format stores 5-dim. arrays plus additional data. It is already used for num. flow solvers. In version 1.6.7 "Faxe", literal constants are defined with _rk. Additionally a minor bug in the interpolation module is corrected."
OBO-Edit: 2.0 is available (SourceForge)Version 2.0 of OBO-Edit has been announced, it includes a number of new capabilities. "OBO-Edit is an open source, platform independent application for viewing and editing ontologies developed by the Berkeley Bioinformatics and Open Source Projects Group at Lawrence Berkeley National Lab."
Web Browsers SeaMonkey 1.1.16 security releaseVersion 1.1.16 of SeaMonkey has been announced. "Today, the SeaMonkey project released a new version of its all-in-one internet suite. SeaMonkey 1.1.16 closes a few critical security vulnerabilities found in previous versions. With that, SeaMonkey offers the same level of security as its sibling Firefox 3, which has issued updates for the same problems recently as well."
Languages and Tools C GCC 4.4.0 Status ReportThe April 14, 2009 edition of the GCC 4.4.0 Status Report has been published. "Release Candidate 1 has been released today. The branch remains open under the usual release branch rules; it is open for regression and documentation fixes only, but please be very conservative at this point in deciding what changes are needed before the 4.4.0 release and what can wait until after that release."
IDEs Pydev 1.4.5 releasedVersion 1.4.5 of Pydev, an Eclipse IDE plugin for Python and Jython, has been announced, numerous improvements have been made.
Libraries FreeImage: 3.12.0 released (SourceForge)Version 3.12.0 of FreeImage has been announced, it includes several new capabilities. "FreeImage is an Open Source library project for developers who would like to support popular graphics image formats like PNG, BMP, JPEG, TIFF and others as needed by today's multimedia applications. FreeImage is easy to use, fast, multithreading safe, compatible with all 32-bit versions of Windows, and cross-platform (works both with Linux and Mac OS X)."
Version Control GIT 1.6.2.3 releasedVersion 1.6.2.3 of the GIT distributed version control system has been announced. "The latest maintenance release GIT 1.6.2.3 is available at the usual places".
Page editor: Forrest Cook Linux in the news Business Linux Expected To Thrive As Economy Recovers (Information Week)Information Week covers predictions made by IDC analyst Al Gillen at the Linux Foundation Collaboration Summit. "Companies simply aren't investing in new initiatives. In the recession, they will "fall back on existing skills" to get them through a downturn, and part of those existing skills include more use of free Linux, he said. Nevertheless, Linux will emerge as the fastest-growing operating system, post downturn, because of the underlying trends in the market. By 2013, IDC expects revenue from Linux software, servers, and services to equal about half those of the lucrative Unix market, or $35.5 billion versus $74 billion."
IDC: Linux to benefit from recession (The Register)The Register looks at an IDC prognostication. "Economic turmoil has always driven change (and sometimes innovation) in the data centre, and this global recession will be no different. This time around, like the recession that started in 2001, it looks like Linux is going to be one of the big beneficiaries."
Linux Adoption Government sticks to proprietary line: leaves Linux in the dust (Technology & Business)Technology & Business takes a look at the Australian government's decision to use proprietary solutions in schools. "When the NSW Department of Education and Training put out a tender for its $150 million 'netbooks for schools' contract, the opportunity for Linux to be used in the State's education system was looking quite possible. The tender specified that all proposed devices must be able to run either Windows or Linux and many of the vendors submitting proposals had been using Linux to some extent. The final decision to use Lenovo Laptops powered by Microsoft's operating system and running proprietary software was a blow to the open source community, and also a blow, say some people to education." (Thanks to Dahna McConnach)
Another Look At Linux Netbook Return Statistics (bMighty.com)Matthew McKenzie questions statistics on Linux netbook returns. "Last year, for example, the director of U.S. sales for MSI told Laptop Magazine that customers return Linux netbooks four times as often as Windows netbooks. As Computerworld.com contributor Eric Lai pointed out, however, such claims can be misleading. According to Lai, MSI's numbers weren't based on the company's actual netbook return rates. In fact, at the time, MSI wasn't even shipping a Linux-powered netbook model. So, where did MSI get its information? From third-party market research."
Legal Should an Open Source Licence Ever Be Patent-Agnostic? (Linux Journal)Glyn Moody covers a new license that is being submitted to the Open Source Initiative. "Sharing lies at the heart of free software, and drives much of its incredible efficiency as a development methodology. It means that coders do not have to re-invent the wheel, but can borrow from pre-existing programs. Software patents, despite their name, are about locking down knowledge so that it cannot be shared without permission (and usually payment). But are there ever circumstances when software patents that require payment might be permitted by an open source licence?"
Reviews Enter gNewSense - the free Ubuntu (FSM)Free Software Magazine has posted a review of gNewSense for those of you wanting to live a firmware-free life. "Considering the explanations above it is no surprise that using gNewSense is more restricting than using Ubuntu. Missing support for many WLAN cards, missing GLX as well as no Firefox do not make gNewSense more attractive for the user. In order to prevent disappointment it is strongly recommended to read up on hardware support and provided software before the installation."
Miscellaneous New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)Dark Reading reports on a "new" way to install rootkits on a Linux system. "At Black Hat Europe this week in Amsterdam, Anthony Lineberry, senior software engineer for Flexilis, will demonstrate how to hack the Linux kernel by exploiting the driver interface to physically addressable memory in Linux, called /dev/mem." Of course, this attack would be blocked by the STRICT_DEVMEM configuration option, introduced into the mainline kernel in 2.6.25 (and by some distributors prior to that).
Page editor: Forrest Cook Announcements Non-Commercial announcements EFF: CS student targeted for criminal investigationElectronic Frontier Foundation The EFF is challenging an illegal computer seizure by the Boston College Campus Police. "A Boston College computer science student has asked a Massachusetts court to quash an invalid search warrant for his dorm room that resulted in campus police illegally seizing several computers, an iPod, a cell phone, and other technology. The Electronic Frontier Foundation (EFF) is representing the student, who has petitioned the court for the immediate return of his property and is demanding that investigators be prohibited from any further searches or analysis of his digital data."
Wikipedia voting on license changeBack in November, the Free Software Foundation released version 1.3 of the GNU Free Documentation License; this version contained a special escape clause allowing sites like Wikipedia to shift to the Creative Commons CC-BY-SA license. Some months later, the Wikimedia Foundation is voting on whether to make this change. Anybody with at least 25 edits is able to vote; the vote closes on May 3. "The Board has evaluated possible licensing options for Wikimedia material, and believes that this proposal is the best available path towards achieving our collective goal to collect, develop and disseminate educational material, and make it available to people everywhere, free of charge, in perpetuity."
Commercial announcements CadSoft releases Eagle 5.5CadSoft has released version 5.5 of their Eagle printed circuit CAD application. This release adds improvements to a number of different commands. See the What's new document for details.
EnterpriseDB joins Open Source Channel Alliance as charter memberEnterpriseDB has announced that it has joined the Open Source Channel Alliance. "EnterpriseDB, a leading enterprise open source database company, today announced that it has joined the Open Source Channel Alliance as one of eight charter members. The Open Source Channel Alliance is a consortium of independent software vendors (ISVs) led by Red Hat. The consortium seeks to deliver the value of open source technologies to the mid-market through a distribution agreement with SYNNEX Corporation (NYSE: SNX), a leading business process services company with an extensive channel of value-added resellers (VARs) and system integrators (SIs)."
Likewise Software named founding member of Open Source Channel AllianceLikewise Software has been named as a founding member of the Open Source Channel Alliance. "Likewise Software today announced its participation as one of 9 founding members of the Open Source Channel Alliance -- a consortium of open source independent software vendors led by Red Hat that will deliver open source technologies to a large base of value-added resellers and system integrators through a distribution agreement with SYNNEX Corporation (NYSE: SNX)."
Resources FSFE NewsletterThe April 15, 2009 edition of the FSFE Newsletter is online with the latest Free Software Foundation Europe news. "This month's newsletter has been specially extended to include items for the first quarter of 2009. Starting from the next month onwards, the traditional format of the newsletter will be back: one month, one newsletter!"
Contests and Awards eLinux wiki editor contest announcedThe CE Linux Forum has announced a new eLinux wiki editor contest. "The eLinux wiki (http://elinux.org//) is a repository of information for developers who work on Linux in embedded systems. The CE Linux Forum sponsors this site, and is offering prizes to individuals who make useful edits to the site over the next 5 weeks. The initial phases of the contest were open to attendees of the recently completed Embedded Linux Conference. However, the contest is now open to the public. The grand prize is the winner's choice of a Sony PlayStation 3 video console, or $500 U.S."
Announcing the Were Linux video contest finalistsThe Linux Foundation recently announced the winners of the Were Linux video contest. "The journey that begin during last football season with the realization that Microsoft paid Jerry Seinfeld $10 million for his appearance in their ads is almost over. The judging for the Were Linux video contest has been completed and Im pleased to announce the finalists. These videos reflect the best of what was truly a global community effort with videos being submitted from Asia, Europe, North America, the Middle East and South America. The response exceeded all of our expectations: frankly I was worried wed get 20 entries, but we ended up getting over 90. We would like to thank all of the community members who took the time to submit videos. Many were smart, many were funny, all were creative." The videos themselves can be found on this page.
Calls for Presentations BugCON '09, Mexico: Call For PapersA call for papers has gone out for the BugCON '09 security conference, the event takes place at the Instituto Politécnico Nacional (IPN) in Mexico on June 24-26, 2009. Submissions are due by April 30.
DebConf9 registration, CFP and visa help deadlines approachingA call for papers and registration announcement have gone out for DebConf9, the event takes place in Cáceres, Extremadura, Spain on July 24 - 30, 2009. The submission deadline is April 15.
Hacker Space Fest 2009 Call For PapersA call for papers has gone out for the Hacker Space Fest 2009. The event takes place in Vitry sur Seine, France on June 26-30, submissions are due by May 1. "Soon enough, we wanted to reiterate the HSF experience : however, it was out of the question to institutionalize this temporary autonomous zone, nor make it an ersatz of the previous edition, nor even to wrap it into an "elite" or "underground" aura. On the opposite, we ardently desire; and especially to explore further, in all directions some lesser known domains (see below) et foster meeting and sharing around experiences at the confluence of art, technology and politics."
LinuxCon Call For Proposals deadline 4/15Matt Domsch has a reminder about the LinuxCon CFP deadline in his blog. Presentation proposals are due by April 15th. "I'm on the program committee for this new conference, and we're absolutely looking for fresh presenters and engaging topics. The conference is co-located with the Plumbers Conference, so there will be plenty of deep technical people there. But LinuxCon isn't just about low-level I-cut-my-teeth-on-Z80-assembly presentations. We want plenty of higher level system administrator, end user, and business executive relevant topics too."
PyOhio: Call for ProposalsA call for proposals has gone out for PyOhio 2009. "PyOhio 2009, the second annual Python programming mini-conference for Ohio and surrounding areas, will take place Saturday-Sunday, July 25-26, 2009 at the Ohio State University in Columbus, Ohio. A variety of activities are planned, including tutorials, scheduled talks, Lightning Talks, and Open Spaces." Submissions are due by May 15.
SVG Open 2009 announcedThe 7th International Conference on Scalable Vector Graphics (SVG Open 2009) will be held in Mountain View, CA on October 2-4, 2009. "Scalable Vector Graphics (SVG) is an exciting open standard of the World Wide Web Consortium (W3C) enabling high-quality, interactive, animated and stylable graphics to be delivered over the web using accessible, human-readable XML. At the SVG Open 2009 Conference you will have the opportunity to learn to use it to create effective and compelling web content, learn techniques for developing SVG software solutions, and see the latest developments from the W3C. You will meet the creators of SVG applications in person, the authors of the SVG specifications, and you will have the opportunity to provide your own input for future development." The call for participation has gone out, submissions are due by May 15.
Web 2.0 Expo New York Opens Call for ParticipationA call for participation has gone out for the Web 2.0 Expo. "O'Reilly Media and TechWeb have opened the Call for Participation for the second edition of Web 2.0 Expo New York, scheduled for November 16-19 at the Javits Center in New York City. Like the just completed SF show, Web 2.0 Expo NY will continue to explore the theme of "The Power of Less"-how to best use the tools and principles of Web 2.0 technologies to innovate and stay competitive in a challenging (to say the least) economy." The submission deadline is May 26.
Upcoming Events Announcing the Gran Canaria Desktop SummitThe Gran Canaria Desktop Summit has been announced. "The Gran Canaria Desktop Summit, co-hosting GUADEC, the GNOME Conference, and Akademy, the KDE conference, invite you to participate in the inaugural Desktop Summit, from July 4th to July 10th 2009, in Las Palmas, Gran Canaria, Spain."
OSCON 2009 registration openRegistration for the 2009 O'Reilly Open Source Convention is now open. "OSCON 2009 will be July 20-24 in San Jose, California. Early registration ends June 2. Use the special discount code 'os09pgm' for an extra 15% off."
RAID 2009 announcedThe 12th International Symposium on Recent Advances in Intrusion Detection 2009 (RAID2009) takes place on September 23-25, 2009 in Saint Malo, Brittany, France. "This symposium, the 12th in an annual series, brings together leading researchers and practitioners from academia, government, and industry to discuss issues and technologies related to intrusion detection and defense. The Recent Advances in Intrusion Detection (RAID) International Symposium series furthers advances in intrusion defense by promoting the exchange of ideas in a broad range of topics."
Events: April 23, 2009 to June 22, 2009The following event listing is taken from the LWN.net Calendar.
If your event does not appear here, please tell us about it. Web sites MacForge.net reaches 65,000 open-source projectsMacForge.net has reached 65,000 projects. "MacTech(r) Magazine announced today that its MacForge(tm) Mac open source project index now has over 65,000 projects. In 2005, MacForge.net was created for not only the experienced open source user, but to introduce the Mac technical community to the wonderful array of projects available."
Audio and Video programs Audio recordings of the LibrePlanet conferenceThe Free Software Foundation has posted a set of audio recordings from the LibrePlanet conference, held on March 21. Speakers included Jeremy Allison, Mako Hill, Rob Savoye, Ciaran O'Riordan, and Richard Stallman.
Page editor: Forrest Cook
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[Book Cover]](/images/pvcgit.jpg)