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 July 17, 2008Ubuntu, security response, and community contributionsA recent interview with Mark Shuttleworth is raising a few eyebrows. The Austrian news site derStandard sat down with Ubuntu founder and Canonical CEO Shuttleworth at GUADEC in Istanbul asking about many aspects of Ubuntu, desktops, and Linux in general. His answers to questions about synchronizing releases with other major distributions included some controversial claims. Last May, Shuttleworth suggested that the major enterprise distributions (Red Hat, SUSE, Debian, and Ubuntu) should coordinate their release cycles to foster better stabilization of Linux components. None of the other distributions have expressed much in the way of interest in that plan—at least publicly—though Shuttleworth says there have been some interesting discussions behind the scenes. In answer to a question about the belief that Ubuntu has much more to gain than either Red Hat or Novell, Shuttleworth said:
Well we have a better security track record than Red Hat, we do that by
focusing very hard on security, making sure the updates are available as
fast as possible on Ubuntu, independent studies have generally ranked
Ubuntu number one.
Below is a table that summarizes the response time for a few vulnerable packages over the last several months. It shows when the vulnerability was first announced along with the first update from each of four major distributions. Note that some distributions fixed the vulnerability at different times for different versions, so the date below is the first; other distribution versions may have waited longer for an update.
There doesn't appear to be any clear "winner", though Red Hat seems to beat Ubuntu in most cases—at least on this set of vulnerabilities. It would be much easier to do this kind of comparison if Ubuntu followed Red Hat's lead and published regular assessments of its security performance. It is rather easy to make sweeping statements, referring to unnamed "independent studies", while it is much harder to actually gather the information and present it. Red Hat's transparency on its security performance is something that all distributions should strive for—especially those who would tout their security response. But the security issue is just a part of a fairly pervasive perception that Ubuntu and Canonical are not contributing very much back to the community. That is the underlying concern that Shuttleworth is addressing. He continues:
So what I'm trying to say here, that the notion that Canonical wouldn't
contribute anything in such a situation and it would be a one way flow is
something I disagree with. Look for example at the fact that Ubuntu has
usually better hardware support, if we all were on the same kernel the
others could take the drivers we put in there and have hardware support
that is just as good as Ubuntu.
While supporting more hardware is an excellent goal, doing it by merging unsupported drivers into the kernel is not the recommended path. As Red Hat kernel hacker Dave Jones puts it:
Does no-one else see the hypocrisy in this statement ? Here's how it reads
to me... "It would be great if everyone just shipped the Ubuntu kernel and
debugged the random crap we merge that we don't have the resources to do
ourselves".
If only there were some kind of process of getting drivers merged upstream to kernel.org. Perhaps then we COULD be on the same kernel. Oh wait, there is a process. Ubuntu just chooses to ignore it. Canonical, unlike the other major enterprise distribution vendors, is not known for its kernel contributions. It is a much smaller organization than Red Hat or Novell, so its support organization is rather small as well. Trying to support lots of hardware is a difficult task. Doing it with out-of-tree and binary-only drivers makes it that much harder. Historically there has also been friction between Ubuntu and its upstream distribution, Debian, at least partially because of a perception that it does not contribute back. It is against this backdrop that Shuttleworth is speaking. The fact that he feels that he needs to defend Ubuntu speaks volumes. Some of the complaints might be written off to jealousy over the popularity of Ubuntu, but there is a fair amount of truth to them as well. Canonical and the Ubuntu community have done some fairly amazing things in a short period of time, but they did it by leveraging lots of work by Debian and others. It is important to be a contributing member of the larger Linux ecosystem, so Ubuntu and Canonical need to work to remove this perception of the distribution—regardless of its merits. Talk alone won't do that, action is required.
Fedora and distributed source packagesFedora's new version of RPM, announced on July 9, has hit the Rawhide repositories; after inspiring some initial cries of pain, it would appear to settling in well. It is good to see activity on Red Hat's version of RPM after a long period where nothing much was happening. In the process of bringing this new code to Rawhide, the RPM developers have also inspired some interesting side discussions on topics like whether such a major change should have gone through the official "features" process first. But the most extended (and arguably most interesting) discussion came from an unexpected direction.Doug Ledford is known in kernel development circles, but, being an RHEL engineer, he has not been seen much in the Fedora camp. He joined the RPM discussion with a feature request of his own: he would like a set of tags which would facilitate the location of a package's source code in a distributed version control system (DVCS). So these tags would indicate which DVCS is in use (git, mercurial, etc.), where the repository is to be found, the tag corresponding to the source code for a specific version of a package, etc. And, Doug let it be known, it would be nice if he could have those tags soon; tomorrow would be nice, but before the Fedora 10 release in particular. Once this information exists for a package, interesting things can be done. For example, source RPM packages could become much smaller; rather than containing a tarball and a set of distributor-applied patches, it could just hold the DVCS information. An "installation" of that package would then just go to the source repository and check out the sources from there. If the source repository is managed carefully, it could help the cooperation between Fedora and the upstream projects; patches could be pushed and pulled between repositories with ease. This kind of mechanism could also make it easier for the Fedora project to distribute "spins" created by outsiders by reducing the resources required to make the associated source code available. See this lengthy pitch from Doug for more discussion of the advantages of the distributed source package approach. Of course, there are some obstacles too. Not all projects are using a DVCS, so integration with those projects would be more difficult. Quite a few projects have material in their repositories which, for legal reasons, cannot be distributed by Fedora. Finding a way to excise that material without breaking the connections between repositories could be challenging. The tarballs distributed by many upstream projects - which are the starting place for Fedora packages now - often contain changes which are not reflected in their source repositories. Those changes can include the removal of non-distributable material, or simply generating the configure file. These challenges are real, and some of them will take a fair amount of work to resolve. But it seems clear that things eventually need to go in this direction. Tighter integration between projects and distributors can only help the whole free software ecosystem work in a more efficient manner. Tarballs reflect a form of frozen state which is entirely divorced from the code's history - and from its future. Or, as Doug put it:
It's all about the repo. A tarball is something you hand off to
poor saps that haven't joined the 21st century, all the while
snickering at their inability to get with the times. It is nothing
more than a middle man step that interferes with efficiency of
operation and that should be cut out of the loop.
A source package format that can maintain its connections wherever it goes can only make the whole system work better. So it is good that the Fedora folks (including those beyond Doug who have been thinking about this issue for a while now) are working on this problem. There was, however, an interesting omission from the discussion; as far as your editor can tell, nobody ever mentioned the work being done by the vcs-pkg project, which is aimed toward this goal:
Our goal is to integrate version control with distro package
maintenance. We want to recognise all involved in the process, from
upstream, the package maintainers of the various distributions,
their security and release teams, and power users, who aren't
afraid to fix their own bugs, and give maximum flexibility to
them.
This group is mostly Debian-based, but its members are making a concerted effort to create solutions which are independent of any given distribution (or DVCS). It can only make sense for Fedora to work with this project - or at least have a look at what vcs-pkg is doing and come up with a good excuse why a different solution has to be invented for Fedora. The integration of distributed version control and packaging can only reach its full potential if, among other things, it facilitates cooperation between distributors and their upstream providers, their users, and, importantly, other distributors. If each distributor brews up its own solution (again), they'll have a hard time sharing their work with each other. Few upstream projects will have the patience to integrate with several disparate distributor systems, so that integration will be much less likely to happen. All of this can be avoided, though, if the distributors decide now to work toward some common standards for the use of distributed version control in packaging.
What Red Hat and Firestar agreed toOn July 15, Red Hat and Firestar released the terms of the settlement [PDF] of their patent suit. When we last looked at this settlement, those terms were not available. Now we can examine exactly what was agreed to and assess the degree of protection that Red Hat actually negotiated for the wider community. It may be tempting to say that recent events have reduced the relevance of this settlement, but that would be a mistake; what Red Hat has done here still matters.Those recent events, of course, are dominated by Sun's announcement that it had successfully challenged the Firestar patent; the US Patent and Trade Office (PTO) has officially rejected all of Firestar's claims. As your editor (along with numerous others) has said, this should not have been a particularly hard thing to do; the weakness of this particular patent was evident after even a cursory reading. So one might well wonder why Red Hat chose to pay the troll in this particular case. And, incidentally, Red Hat did pay. Naturally enough, the specific payment terms have been removed from the agreement, but a payment was a part of the deal. It is nice that Sun took a less compromising approach to this case, even though it was not named as a defendant. But Sun's success has not rendered this settlement moot, for a few reasons. To begin with, Firestar now has two months to fight the PTO decision and reinstate its patent. That looks like a difficult task, but, with the PTO, one never really knows. Second, the settlement does not cover just that one patent; it covers just about any patent that Firestar owns or will acquire in the next five years - though some of that coverage goes away in 2013. And, perhaps most importantly, Red Hat clearly sees this settlement as a template for the resolution of other patent suits which are certain to come in the future. The settlement itself reads somewhat like a Pascal program; one must start toward the bottom and read it in reverse. Following that analogy, the main program can be found in section 5.2:
Licensor grants and promises to grant to Red Hat Community Members
a perpetual, fully paid-up, royalty-free, irrevocable worldwide
license of the Licensed Patents to engage in any and all activities
related to Red Hat licensed Products, including without limitation
to make, have made, use, have used, sell, have sold, offer for
sale, have offered for sale, provide or have provided, distribute
or have distributed, import or have imported and Red Hat Licensed
Product and services related to any Red Hat Licensed Product.
So, these patents have been licensed for any practical purpose to anybody who happens to be a Red Hat Community Member, as long as they are working with Red Hat Licensed Software. Well, almost any purpose; there is a small catch, as will be seen shortly. First, though, it is time to read the declarations toward the top of the settlement to see what those terms really mean. Who, exactly, is a Red Hat Community Member?
...any Entity that is a licensee or licensor of, contributes to,
develops, authors, provides, distributes, receives, makes, uses,
sells, offers for sale, or imports, in whole or in part, directly
or indirectly, any Red Hat Licensed Product, including without
limitation any upstream contributor to, or downstream user or
distributor of, a Red Hat Licensed Product.
This definition is clearly quite comprehensive; anybody who makes use of the software is considered to be a Red Hat Community Member. Your editor is pondering offering for sale a line of "Proud Red Hat Community Member" T-Shirts at the next Debconf or OpenBSD hackfest. This is a club that we all get to join. The other key term, though, is "Red Hat Licensed Product," because only such products are covered by the settlement. The definition of this product is simple:
"Red Hat Licensed Product" means any Red Hat Product, Red Hat
Derivative Product, or Red Hat Combination Product.
Now, perhaps, we have moved away from Pascal programming and are stuck with the unenviable task of making sense of a convoluted Java class hierarchy. One of the subclasses, the definition of "Red Hat Product," is crucial:
...(a) any product, process, service, or code developed by,
licensed by, authored by, distributed under a Red Hat Brand by,
made by, sold under a Red Hat Brand by, offered for sale under a
Red Hat Brand by, sponsored by, or maintained by Red Hat, (b) any
predecessor version of any of the foregoing, including without
limitation any upstream predecessor version any of the foregoing...
So essentially, a Red Hat Product is anything developed or shipped by Red Hat under one of its trade names. So anything in Red Hat Enterprise Linux qualifies. The important thing that Red Hat didn't see fit to specify in its early PR is that anything in Fedora - also being software distributed under a Red Hat Brand - qualifies too. Since Fedora packages rather more software than RHEL does, that broadens the coverage of this agreement considerably. Also important is the "any predecessor version" clause. Coverage under this agreement does not apply to just the specific, possibly patched version of a program shipped by Red Hat; anything which came before in that package's upstream is also part of the deal. And, incidentally, this coverage does not go away if Red Hat stops shipping a package; just one shipped version will do. The Red Hat Brand has become the magic touch which confers protection against Firestar patents onto any software it touches. Thus far, we have coverage for Red Hat's packages and their predecessors upstream. What happens, though, if the upstream project continues to develop the software beyond the version shipped by Red Hat? That's where the "Red Hat Derivative Product" category comes in:
"Red Hat Derivative Product" means any product, process, service,
or code that is a direct or indirect Derivative of at least one Red
Hat Product.
So the combination of "any predecessor version" and the definition of a Derivative Product means that the entire project is covered, from its first version through anything it will do in the future - though, once again, there's a catch. But, before we get to that, there is the third subclass: "Red Hat Combination Product." It refers to a grouping of something which is one of the two product types described above and something unrelated - an aggregation. The apparent intent is to cover situations like dynamic linking: an application which links to a covered library will, itself, be covered. These definitions, too, appear to be quite broad. Just about anything which has been shipped by Red Hat, or which has even shared the same disk drive as something shipped by Red Hat qualifies. But, as has been mentioned before, there is one catch in the form of an excluded class of software:
a Red Hat Derivative Product that infringes the particular Licensed
Patent at issue without use of or reference to any portion or
functionality in or from a Red Hat Product on which the Red Hat
Derivative Product is based.
(There is similar language for Combination Products as well). What this section is saying is that, if a derived product contains infringing code, that infringing code must have been part of the covered Red Hat product as well. In other words, outsiders cannot bless their particular patent infringement by grabbing enough code from some other project to create a derived product. One can see why this restriction was seen to be necessary; without it, any software (free or proprietary) could have easily been brought under the coverage umbrella. Instead, one must first convince Red Hat to distribute that software at least once. Plenty of other legalese can be found in the agreement, of course; interested readers are encourage to read the whole thing. But the core of it is what's described above. Notably absent (unless it has been redacted from the payment section, which seems unlikely) is any discussion of what happens if the patent is held to be invalid. So, even if Sun is ultimately successful in its challenge (as seems likely), Red Hat will not be getting its money back under the terms of this agreement. Red Hat's initial press release claimed that this settlement demonstrated the company's commitment to standing up for the community in the face of patent trolls, and stated that it would discourage any future such cases. At this point it seems fairly evident that Sun has made a better show of standing up for the community and discouraging future cases. What Red Hat has done, though, is to show us how future patent problems could be resolved in the absence of obvious prior art. If one must pay the troll, one would do well to come out with an agreement like this one and, at least, keep the troll away from the rest of the community. Whether patent holders who actually have a legal leg to stand on will be willing to agree to such a settlement remains to be seen; the nature of the game is such that, unfortunately, we are likely to get an answer to that question sooner or later.
Security Trust and mirrorsA recent look at attacks on package managers has much of interest. None of the attack methods are particularly new at some level, but applying them to the update process is. When the mechanism that is used to keep one's system updated with respect to security vulnerabilities is itself susceptible, it is definitely worth a look. Much of the problem stems from the fact that many community distributions rely on volunteer mirrors to distribute updates. These mirrors could be malicious which would allow them to distribute bad code to systems that are checking for updates. In addition, mirrors are perfectly placed to notice which machines are updating for particular vulnerabilities—information that could be used in attacks. The study looked at ten of the most popular Linux and BSD package management systems and found all of them to be vulnerable to one or more of the flaws they identified. Package managers track metadata—information about what package versions and dependencies there are—as well as the packages themselves in formats like .rpm or .deb. Typically, the packages are cryptographically signed (using GPG for example) so that they can be verified as genuine by client systems. Some package managers also sign the metadata, but some do not, which allows for additional attacks. The biggest issue with mirrors is the information that they gain. When a client requests a certain package, it is pretty easy to guess that it is probably vulnerable to whatever security flaw is being fixed in that new package. A malicious mirror—or one that has been subverted—could try to attack the client machine via the flaw being fixed. A suitable vulnerability could be used to completely compromise the client machine. Once a particular chunk of data, either package or metadata, has been signed, it is valid more or less forever. This can be used by malicious mirrors in two ways: serving up old metadata that points clients at known vulnerable package versions or serving up old packages that are known to have flaws. In both cases, it is a kind of "replay" attack, using old, valid data for malicious purposes. In most cases, package managers will not downgrade to previous package versions unless explicitly instructed to, so machines that have already upgraded are not generally vulnerable to a package replay. However, if a client reliably contacts a particular mirror for metadata, that mirror can continue serving an older version until an exploit of interest comes along. By knowing that the client has not upgraded—because it has been held back by the mirror-served metadata—an attacker can exploit the newly-discovered vulnerability at their convenience. Mirrors can also perform "endless data" attacks where the data transfer for the package or metadata is never terminated. The mirror keeps sending more and more data until it fills the client disk. This is likely to "only" cause a denial of service on the machine that is being updated, but that can still be a serious result, especially when the update process is automated. Unsigned metadata can allow for several other kinds of attacks. Manipulating the dependencies that are provided or needed by a package can lead to various kinds of problems. A dependency on a non-existent package will stop the update from happening, while a dependency on a package of the attacker's choosing can lead to complete compromise. There is not a lot that can be done to solve the information gathering problem. Subscription-based distributions generally provide their own servers and do not rely upon mirrors to avoid this problem. For community distributions, there really is no central authority that has the resources to do that. Also, controlling all the mirrors only goes so far; if any are compromised, the same kinds of attacks are possible. Downloading the packages to a non-vulnerable host is probably the best avoidance technique, but is difficult to do in practice. The lessons from this study are clear. Metadata should be signed and only downloaded from "trusted" servers. If there is a concern about man-in-the-middle attacks, an encrypted connection should be used between the clients and servers with certificates being checked to ensure the connection is going where expected. In the end, it comes down to trusting the mirrors that one uses. It is not terribly surprising that mirrors can cause these kinds of problems, but the study authors did an excellent job pulling together the different kinds of attacks. The picture that they paint is not particularly pretty, but it is one we needed to see.
Security reports Study: Attacks on package managersThe University of Arizona is publishing a study on security problems with package management systems. The core problem would appear to be that tools like yum and apt will happily install versions of packages with known vulnerabilities if they think that's the most recent version available. And feeding such packages to the package managers is not a big challenge: "To give an example of how easy it is for a malicious party to obtain a mirror, we ran an experiment where we created a fake administrator and company name and leased a server from a hosting provider. We were able to get our mirror listed on every distribution we tried (Ubuntu, Fedora, OpenSuSE, CentOS, and Debian) and our mirrors were contacted by thousands of clients, even including military and government computers!"
New vulnerabilities apache: multiple vulnerabilities
bluez: input validation flaw
drupal: multiple vulnerabilities
firefox: multiple vulnerabilities
java-1.5.0-sun: multiple vulnerabilities
java-1.6.0-sun: multiple vulnerabilities
java: multiple vulnerabilities
newsx: stack overflow
php: denial of service
wireshark: multiple vulnerabilities
Page editor: Jake Edge Kernel development Brief items Kernel release statusThe 2.6.26 kernel is out, released by Linus on July 13. For those just tuning in, some of the bigger changes in 2.6.26 include PAT support in the x86 architecture, read-only bind mounts, the KGDB debugger, a lot of virtualization work, and more. See the KernelNewbies 2.6.26 page for lots of details.The 2.6.27 merge window has opened, with some 3000 changesets incorporated as of this writing. See the separate article below for a summary of what has been merged (so far) for the next development cycle. The 2.6.25.11 stable kernel update was released on July 13. It contains a single fix for a locally-exploitable vulnerability (limited to x86_64 systems).
Kernel development news Quotes of the week
That said, I didn't actually _test_ my patch. That's what users are
for!
-- Linus Torvalds
6924d1ab8b7bbe5ab416713f5701b3316b2df85b is a work of art.
Is it ascii-art tetris? a magic eye picture? you decide!
It looks even more spectacular in gitk.
-- Dave Jones
-- Ingo Molnar
But I could also see the second number as being the "year", and
2008 would get 2.8, and then next year I'd make the first release
of 2009 be 2.9.1 (and probably avoid the ".0" just because it again
has the connotations of a "big new untested release", which is not
true in a date-based numbering scheme). And then 2010 would be
3.0.1 etc..
-- Linus Torvalds opens the can of worms
Anyway, I have to say that I personally don't have any hugely strong opinions on the numbering. I suspect others do, though, and I'm almost certain that this is an absolutely _perfect_ "bikeshed-painting" subject where thousands of people will be very passionate and send me their opinions on why _their_ particular shed color is so much better.
Indeed, I apologise for reviewing the code on a monitor that is
wider than yours. If only we could make sure that all Linux
developers used smaller monitors then the code quality would surely
improve!
-- Herbert Xu
And we should obviously have _a_ version of the firmware available
with the kernel when that is possible. But I'd hate for it to be
1:1 with a particular driver version - because at that point it
smells of being a single work, and if it is more than mere
aggregation it's no longer viable with most of our firmware (I
don't think we have source for more than one or two cases).
-- Linus Torvalds
2.6.27: what's coming (part 1)Linus wasted no time after the 2.6.26 release; he opened the 2.6.27 merge window less than 24 hours later. As of this writing, the process has barely begun with a mere 3000 changesets merged. So we do not have a complete picture of what will be in the next kernel release. But we can look at what has been merged so far.User-visible changes include:
Changes visible to kernel developers include:
Come back next week for the next episode in the "what's coming in 2.6.27" series.
Block layer: integrity checking and lots of partitionsOne likes to think of disk drives as being a reliable store of data. As long as nothing goes so wrong as to let the smoke out of the device, blocks written to the disk really should come back with the same bits set in the same places. The reality of the situation is a bit less encouraging, especially when one is dealing with the sort of hardware which is available at the local computer store. Stories of blocks which have been corrupted, or which have been written to a location other than the one which was intended, are common.For this reason, there is steady interest in filesystems which use checksums on data stored to block devices. Rather than take the device's word that it successfully stored and retrieved a block, the filesystem can compare checksums and be sure. A certain amount of checksumming is also done by paranoid applications in user space. The checksums used by BitKeeper are said to have caught a number of corruption problems; successor tools like git have checksums wired deeply into their data structures. If a disk drive corrupts a git repository, users will know about it sooner rather than later. Checksums are a useful tool, but they have one minor problem: checksum failures tend to come when they are too late to be useful. By the time a filesystem or application notices that a disk block isn't quite what it once was, the original data may be long-gone and unrecoverable. But disk block corruption often happens in the process of getting the data to the disk; it would sure be nice if the disk itself could use a checksum to ensure that (1) the data got to the disk intact, and (2) the disk itself hasn't mangled it. To that end, a few standards groups have put together schemes for the incorporation of data integrity checking into the hardware itself. These mechanisms generally take the form of an additional eight-byte checksum attached to each 512-byte block. The host system generates the checksum when it prepares a block for writing to the drive; that checksum will follow the data through the series of host controllers, RAID controllers, network fabrics, etc., with the hardware verifying the checksum along each step of the way. The checksum is stored with the data, and, when the data is read in the future, the checksum travels back with it, once again being verified at each step. The end result should be that data corruption problems are caught immediately, and in a way which identifies which component of the system is at fault. Needless to say, this integrity mechanism requires operating system support. As of the 2.6.27 kernel, Linux will have such support, at least for SCSI and SATA drives, thanks to Martin Petersen. The well-written documentation file included with the data integrity patches envisions three places where checksum generation and verification can be performed: in the block layer, in the filesystem, and in user space. Truly end-to-end protection seems to need user-space verification, but, for now, the emphasis is on doing this work in the block layer or filesystem - though, as of this writing, no integrity-aware filesystems exist in the mainline repository. Drivers for block devices which can manage integrity data need to register some information with the block layer. This is done by filling in a blk_integrity structure and passing it to blk_integrity_register(). See the document for the full details; in short, this structure contains two function pointers. generate_fn() generates a checksum for a block of data, and verify_fn() will verify a checksum. There are also functions for attaching a tag to a block - a feature supported by some drives. The data stored in the tag can be used by filesystem-level code to, for example, ensure that the block is really part of the file it is supposed to belong to. The block layer will, in the absence of an integrity-aware filesystem, prepare and verify checksum data itself. To that end, the bio structure has been extended with a new bi_integrity field, pointing to a bio_vec structure describing the checksum information and some additional housekeeping. Happily, the integrity standards were written to allow the checksum information to be stored separately from the actual data; the alternative would have been to modify the entire Linux memory management system to accommodate that information. The bi_integrity area is where that information goes; scatter/gather DMA operations are used to transfer the checksum and data to and from the drive together. Integrity-aware filesystems, when they exist, will be able to take over the generation and verification of checksum data from the block layer. A call to bio_integrity_prep() will prepare a given bio structure for integrity verification; it's then up to the filesystem to generate the checksum (for writes) or check it (for reads). There's also a set of functions for managing the tag data; again, see the document for the details.
Extended partitionsOne of the more annoying and long-lived annoyances in the Linux block layer has been the limit on the number of partitions which can be created on any one device. IDE devices can handle up to 64 partitions, which is usually enough, but SCSI devices can only manage 16 - including one reserved for the full device. As these devices get larger, and as applications which benefit from filesystem isolation (virtualization, for example) become more popular, this limit only becomes more irksome. The interesting thing is that the work needed to circumvent this problem was done some years ago when device numbers were extended to 32 bits. Some complicated schemes were proposed back in 2004 as a way of extending the number of partitions while not changing any existing device numbers, but that approach was never adopted. In the mean time, increasing use of tools like udev has pretty much eliminated the need for device number compatibility; on most distributions, there are no persistent device files anymore. So when Tejun Heo revisited the partition limit problem, he didn't bother with obscure bit-shuffling schemes. Instead, with his patch set, block devices simply move to a new major device number and have all minor numbers dynamically assigned. That means that no block device has a stable (across boots) number; it also means that the minor numbers for partitions on the same device are not necessarily grouped together. But, since nobody really ever sees the device numbers on a contemporary distribution, none of this should matter. Tejun's patch series is an interesting exercise in slowly evolving an interface toward a final goal, with a number of intermediate states. In the end, the API as seen by block drivers changes very little. There is a new flag (GENHD_FL_EXT_DEVT) which allows the disk to use extended partition numbers; once the number of minor numbers given to alloc_disk() is exhausted, any additional partitions will be numbered in the extended space. The intended use, though, would appear to be to allocate no traditional minor numbers at all - allocating disks with alloc_disk(0) - and creating all partitions in that extended space. Tejun's patch causes both the IDE and sd drivers to allocate gendisk structures in that way, moving all disks on most systems into the (shared) extended number space. Even though modern distributions are comfortable with dynamic device numbers (and names, for that matter), it seems hard to imagine that a change like this would be entirely free of systems management problems across the full Linux user base. Distributors may still be a little nervous from the grief they took after the shift to the PATA drivers changed drive names on installed systems. So it's not really clear when Tejun's patches might make it into the mainline, or when distributors would make use of that functionality. The pressure for more partitions is unlikely to go away, though, so these patches may find their way in before too long.
Handling kernel security problemsEven the most casual observer of the linux-kernel mailing must have noticed that, in the shadow of the firmware flame war, there is also a heated discussion over the management of security issues. There have also been some attempts to turn this local battle into a multi-list, regional conflict. Finding the right way to deal with security problems is difficult for any project, and the kernel is no exception. Whether this discussion will lead to any changes remains to be seen, but it does at least provide a clear view of where the disagreements are.Things flared up this time in response to the 2.6.25.10 stable kernel update. The announcement stated that "any users of the 2.6.25 kernel series are STRONGLY encouraged to upgrade to this release," but did not say why; none of the patches found in this release were marked as security problems. As it happens, there were security-related fixes in that update; some users are upset that they were not explicitly called out as such. They have reached the point of accusing the kernel developers of hiding security problems. These problems, it is said, are fixed with relatively benign-sounding commit messages ("x86_64 ptrace: fix sys32_ptrace task_struct leak," for example) and users are not told that a security fix has been made. This, in turn, is thought to put users at risk because (1) they do not know when they need to apply an update, and (2) there is no clear picture of how many security problems are surfacing in the kernel code. So, as "pageexec" (or "PaX Team") put it:
the problem i raised was that there's one declared policy in
Documentation/SecurityBugs (full disclosure) yet actual actions are
completely different and now Linus even admitted it. the problem
arising from such inconsistency is that people relying on the
declared disclosure policy will make bad decisions and potentially
endanger their users. there're two ways out of this sitution:
either follow full disclosure in practice or let the world at large
know that you (well, Linus) don't want to. in either case people
will adjust their security bug handling processes and everyone will
be better off.
There are two aspects to the charge that the kernel is not following a full disclosure policy: commit messages are said to obscure security fixes, and kernel releases do not highlight the fact that security problems have been fixed. There is an aspect of truth to the first charge, in that Linus will freely admit to changing commit logs which discuss security problems too explicitly:
I literally draw the line at anything that is simply greppable
for. If it's not a very public security issue already, I don't want
a simple "git log + grep" to help find it.
That said, I don't _plan_ messages or obfuscate them, so "overflow" might well be part of the message just because it simply describes the fix. So I'm not claiming that the messages can never help somebody pinpoint interesting commits to look at, I'm just also not at all interested in doing so reliably. His goal here is clear: make life just a little harder for people who are searching the commit logs for vulnerabilities to exploit. One may argue over whether this policy amounts to hiding security problems, or whether it will be effective in reducing exploits (and plenty of people have shown their willingness to do such arguing), but the fact remains that it is the policy followed by Linus at this time. In his view, the committing of a fix is the disclosure of the problem, and there is no need to be more explicit than that. That view extends to the whole security update process found in much of the community. He has no respect for embargo policies or delayed disclosure, and he criticizes the "whole security circus" which, in his opinion, emphasizes the wrong thing:
It makes "heroes" out of security people, as if the people who don't just
fix normal bugs aren't as important.
In fact, all the boring normal bugs are _way_ more important, just because there's a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more "special" than a random spectacular crash due to bad locking. Beyond that, it is often hard to know which patches are truly security fixes. It has been argued at times that all bugs have security relevance; it's mostly just a matter of figuring out how to exploit them. So explicitly marking security fixes risks taking attention away from all of the other fixes, many of which may also, in fact, fix security issues. Thus, Linus says:
If people think that they are safer for only applying (or upgrading
to) certain patches that are marked as being security-specific,
they are missing all the ones that weren't marked as such. Making
them even _believe_ that the magic security marking is meaningful
is simply a lie. It's not going to be.
So why would I add some marking that I most emphatically do not believe in myself, and think is just mostly security theater? That said, the stable kernel updates go out with patches which are known to be security fixes. Some people clearly believe that being STRONGLY encouraged to update is not sufficient notification of that fact. It does seem that there has been a trend away from explicit recognition of security issues in the stable releases. The inclusion of CVE numbers was once common; in the 2.6.25 series, only 2.6.25.1, 2.6.25.2, and 2.6.25.5 had such numbers in the changelogs. It is, indeed, true that a straightforward reading of the stable release changelogs will not tell users whether those releases fix relevant security issues. There are a number of answers to that complaint too, of course. The real information is in the source code, and that is always public. The fixes in the stable series are unlikely to be all that relevant to most users anyway; they are running distributor kernels which are many months behind even the -stable series and which may (or may not) be affected by a specific problem. In the end, users who are concerned about security issues in their kernels have somebody to turn to: their distributors. Linux distributors follow disclosure rules and tend to do a pretty thorough job of fixing the known security problems and propagating those fixes to users. For users who need a high level of long-term support, there are distributors who are more than willing to provide that kind of service for a fee. As is often the case, what it really comes down to here is resources. It would be nice if somebody were to follow the patch stream (well over 100 patches/day into the mainline) and identify each one which has security implications. For each patch, this person could then figure out which kernel version was first affected by the vulnerability, obtain a CVE number, and issue a nicely-formatted advisory. But this is a huge job, one which nobody is likely to do in an uncompensated mode for any period of time. So somebody would have to pay for this work. And, to a great extent, that is just what the distributors are doing now - with the nice addition that they backport the fixes into the kernels they support. It is worth noting that those distributors have not been doing a whole lot of complaining about how security fixes are handled now. Instead, the complaining has come, primarily, from the maintainers of the out-of-tree grsecurity project which, from a suitably cynical point of view, could be seen to benefit from raising the profile of Linux kernel security problems. But, regardless of the validity of any such charge, there may be some value in what they are asking. It is good to have a clear sense for what the security problems in a piece of code are. If nothing else, it helps the project itself to understand where it stands with regard to security and whether things are getting better or worse. So it would be nice if the kernel developers could be a bit more diligent and organized in how they track security issues, much like the tracking of regressions has improved over the last couple of years. But this kind of improvement will not happen until somebody decides to put the work into it. Actually putting some time into documenting kernel security issues will accomplish far more than complaining on mailing lists.
Kernel security problems: a responseI would like to try to clarify a few points in the article, "Handling kernel security problems" by Jonathan Corbet.First off, I speak only for myself, not for the other half of the Linux -stable team, Chris Wright, who might totally disagree with me, nor for the other kernel developers who help out with the security@kernel.org alias, nor for my current employer Novell. Also note that all of my -stable development is done on my own time, and is not part of my role at my current job. All of that out of the way, I object to a few things stated in the original article:
It does seem that there has been a trend away from explicit
recognition of security issues in the stable releases. The
inclusion of CVE numbers was once common; in the 2.6.25 series,
only 2.6.25.1, 2.6.25.2, and 2.6.25.5 had such numbers in the
changelogs. It is, indeed, true that a straightforward reading of
the stable release changelogs will not tell users whether those
releases fix relevant security issues.
A number of times, when we do -stable releases, there are no CVE numbers issued for the "security" related issues that are fixed in there. This happens when the fix is first made in Linus's tree, and is either forwarded to the stable@kernel.org alias saying, "we need to get this out now", or just by the fact that it is only later that people realize that a CVE number should be allocated. And yes, the trend is away from explicit recognition of security issues, exactly following Linus's statement that you quote from. It comes down to who are the users of the -stable kernel series. I personally see these kernels for two different groups of people:
The first group should always update to the latest -stable kernel update as they are relying on the -stable team to always provide them the latest fixes that are known to be needed for them. Simply marking things as "security related" can be misguided as Linus points out. The change log entries should show all users what was fixed, and if they run machine where this code is used, then they should upgrade. It's as simple as that. In fact, in the 2.6.25.11 release I tried to say exactly that:
It contains one bugfix, any user of the 2.6.25 kernel on x86-64
with untrusted local users is very STRONGLY recommended to
upgrade.
How much clearer can I be? Does a user of the -stable tree, who has to be technically competent to be able to do such a thing in the first place, need to know more to decide if they need to upgrade their machines or not? It seems people are upset that I am no longer using the magic words "security fix", and that is true, I am not saying that anymore. As Linus and others have noted, marking some bugs as being "security-related" is not helpful, especially as not everyone can even agree - or sometimes even know at release time - whether a bug has security implications or not. Also note that this release does not refer to a CVE number. This is because, as of this moment, there still is not a number assigned, despite asking the relevant groups for such an assignment. I never want to hold up a release by waiting for any such number, so I personally will just not use them in the future in -stable releases unless they are already contained in the original changelog entry in Linus's tree. The second group, the distributions, all seem very happy with how the -stable releases are conducted. They have the capability to pick and choose from the fixes and apply them to their older kernel versions and ship them to their customers as they see fit. The distros all know what things are security related by the fact that they know and understand the code and the threat model as they have developers assigned to handle such security issues, and have done so for years. In your summary, you state:
It is good to have a clear sense for what the security problems in a
piece of code are. If nothing else, it helps the project itself to
understand where it stands with regard to security and whether things
are getting better or worse. So it would be nice if the kernel
developers could be a bit more diligent and organized in how they
track security issues, much like the tracking of regressions has
improved over the last couple of years.
I think the individual developers of the kernel all know quite well what the security problems for their code are. This is backed up by the fact that these developers are the ones usually making the fix and telling the -stable team that a specific patch is needed to be added. What you seem to be asking for is a way to somehow classify bugs and fixes in the kernel tree as "security related" or not. And that goes back to Linus's original point. To try to do so marginalizes bugs which are somehow not so designated as not worth fixing. However, if someone wants to do this work for the kernel community, and it proves to be useful over time, I'll be the first in line to say that I was wrong.
Patches and updates Kernel trees
Core kernel code
Development tools
Device drivers
Documentation
Filesystems and block I/O
Janitorial
Memory management
Networking
Architecture-specific
Security-related
Virtualization and containers
Benchmarks and bugs
Miscellaneous
Page editor: Jonathan Corbet Distributions News and Editorials Gentoo: New release, "new" leadershipLast week, lots of Gentoo news came out, so it's a good time to look at what happened and what it means. Gentoo's 2008.0 release marked its first since more than a year ago, despite its attempts to release twice a year. Fortunately, Gentoo releases don't mean much because it's already a live distribution rather than a snapshot in time with occasional updates. A release provides a new kernel with the accompanying driver support, occasionally a flashy new bootsplash, and the usual bugfixes to the GUI installer, which is not universally loved. But what happened to make this release come so long after the last one? First, 2007.1 was canceled, largely because so many security vulnerabilities came out that it was impossible to keep up with release rebuilds. 2008.0 was scheduled to come out in March, so it slipped 4 months.Tobias Klausmann described the problems well. Here are a couple of them:
Building release media in itself isn't easy to begin with - catalyst is a
powerful but complex (and complicated) tool. ... On top of this, the central
release coordinator has to keep in mind all of the gritty details of the
arches that will see release media. There's arches like ppc which also have
a differently-bitted cousin (ppc64); there are arches that are very, very
slow when building stuff (MIPS). On top of that, some software just doesn't
build on some arches (no Java on alpha, for example) which can make deciding
what to put on the LiveCD very hairy.
People have lives. This is one that bit us this time: life struck at a very bad point (not that the event had been any better post-release). This occupied the time of a dev for a prolonged time. It made painfully obvious that in some spots, stand-in personnel wasn't there. In addition, Tobias cited three other problems:
The main problem delaying 2008.0 was real life interfering with a critical developer. This is being addressed by creating new processes and backup people who can take over when others aren't around. As for the other problems, it's unclear how to fix them. Suggestions would be appreciated. The other major news in Gentoo is the election of a new council. The council is a group of 7 people who lead Gentoo by making decisions on global issues. Two things make this election interesting:
The 145 voters approach the highest number ever in a council election—here's how it compares with previous years: 
This is the highest turnout since the first year the council existed, showing a significant increase in interest by the developer community in who their leadership was compared to the intervening years. To understand exactly who they voted for, these histograms show how highly each candidate was ranked, in order of result. The left side indicates that a candidate was highly ranked, and the right side shows that a candidate was poorly ranked. Of particular interest is the position of "astinus," a developer who retired during the election but was still voted above three other people. Since these three people all favor ignorance of any social issues from someone with good technical contributions, this really shows how strongly the Gentoo development community supports the the creation of a friendlier environment. Notably, of the previous council, every single one of the five members who ran for the new council was re-elected. This shows that the community didn't care about the mistakes that resulted in the new election. It also shows that the community supported the existing council's actions and believed in what its members were saying about the need for social change within Gentoo. With its new release and its accompanying publicity, Gentoo has renewed interest from many users and has shown that it remains a distribution under active development. Having a new council in place for the next year puts Gentoo in position to rebuild its development community and keep development thriving so the publicity and new users gained by the release don't fade away.
New Releases BLAG 90000 ReleasedBLAG 90000, a 100% Free Software distribution, has been released. It comes on a single CD (only 606 megs!), is easily installed, and user friendly. "Linux-libre, a project to make a branch of the Linux kernel with non-free software removed, has flourished. This is the first "major" release of BLAG to include this kernel by default. Upstream (read: Linus) is now making moves to make it easier so everyone can have a truly free kernel. They're not there yet, but they are advancing and will hopefully make this separate kernel unnecessary real-soon-now. But until they do, we'll have linux-libre."
Mandriva Linux 2009 Alpha 2 releasedMandriva Linux 2009 Alpha 2 has been released. "This alpha introduces several significant changes, most obviously the inclusion of KDE 4 - 4.1 beta 2, specifically - as the default version of KDE, and the latest development version of GNOME, 2.23.4. The kernel has also been updated to release 2.6.26rc7."
Intrepid Alpha 2 releasedThe second alpha of Ubuntu 8.10 Intrepid Ibex has been released. "Alpha 2 includes a number of software updates that are ready for large-scale testing. Please refer to http://www.ubuntu.com/testing/intrepid/alpha2 for information on changes in Ubuntu." This release is also available in Kubuntu, Ubuntu Education Edition, and Xubuntu flavors.
Distribution News Debian GNU/Linux Status of Emdebian {ARM}Neil Williams provides a status report on embedded Debian (Emdebian). "Emdebian has been developing nicely over the last few months and the time has come to produce a general status report because we are close to having a reproducible set of working root filesystems for embedded ARM devices to run Emdebian using prebuilt packages. Kernels and kernel modules need to be arranged separately and the installation method will need to be customised to the particular device at this stage. (I am hoping to build the root filesystem tarball into the Debian Installer at some stage.) Only ARM is supported at this time (ARM as in the current Debian ARM port, not armel)."
Bits from the DPLSteve McIntyre provides a Debian Project Leader update. Topics include the teams survey, upcoming events and talks, team updates and delegations, collaborating with Debian derivatives, Debconf and Lenny.
Fedora FESCo Elections open on July 15thElections for the Fedora Engineering Steering Committee (FESCo) are now open. "Any Fedora Account System (FAS) account holder who has completed the CLA, and has an addition account (like ambassadors, art, cvs*, fedorabugs, l10n-commits, web, etc.) in the FAS is eligible to vote. Voting is open until Monday, July 21st, 2008 23:59 UTC. Election results will be announced shortly afterward."
Fedora Board Recap 2008-JUL-08Click below for a recap of the Fedora Board meeting that took place on July 8, 2008. Topics include board followup on CVS commits map and privacy considerations, board answers to community questions, and election improvements.
SUSE Linux and openSUSE SUSE on package management vulnerabilitiesAn advisory for SUSE and openSUSE users has gone out, telling them that they need not worry about the package management vulnerabilities which were recently disclosed. "[S]tarting with version 10.3 openSUSE uses a central download redirector that directly serves the meta data. Stale mirrors are therefore detected immediately. To avoid sending clients to mirrors that do not have certain files (yet), the download redirector also continuously monitors it's mirrors. It only redirects to servers that are known to have the file in question."
Ubuntu family The Harvest Season has started!Harvest is a package aimed at improving Ubuntu's packages. "What can I do with Harvest? Harvest helps to identify both bugs that may be easy to address, and other package changes that are not yet bugs, but could improve the package. Please take a look at the available opportunities when updating a package."
Ubuntu launches a community quality assurance teamUbuntu now has a formal community quality assurance team. "We are broadly looking at enhancing the awareness and contribution to QA around Ubuntu as well as helping people interested in serious QA work find a common, collaborative, and open environment." See the team wiki page for more information.
Other distributions Attacks on Package Managers - ummm... (Planet CentOS)Johnny Hughes looks at the security of CentOS Mirrors. "First, let me explain the CentOS mirror system. CentOS directly controls about 30 mirror servers from which we serve updates via yum and rsync to other public mirrors and to users directly. These mirrors are members of the CentOS.org domain and are totally controlled by the CentOS project. These mirrors can be totally trusted because only CentOS Project personel have login or update access to these machines."
Distribution Newsletters DistroWatch Weekly, Issue 261The DistroWatch Weekly for July 14, 2008 is out. "It's been a slow distro week, but not completely dead. We've had a few releases, several developmental releases, and a bit of news. We also have a guest writer with us this morning, Maurice Lawles. You might know Maurice from his TechieMoe website and hard-hitting distro reviews. Today he shares some of his thoughts on the KDE 4 situation."
Fedora Weekly News Issue 134The Fedora Weekly News for July 12, 2008 looks at the New RPM version in Rawhide, Bugzilla upgrade, Rawhide Orphanarium Purge and much more.
Mandriva Linux Community Newsletter #129This issue of the Mandriva community newsletter looks at Mandriva Flash 2008 Spring released, Mandriva Linux 2009 plans announced, Mandriva to sponsor GUADEC, Mandriva again at the forefront of semantic research and development with SCRIBO, and several other topics.
openSUSE Weekly NewsIssue 30 of the openSUSE Weekly News has been published. "In this week's issue: * openSUSE Build Service 1.0 Released * Announcing openSUSE Day at LinuxWorld Expo * People of openSUSE: Joe Brockmeier * openSUSE Build Service Trust concept * John Anderson: Get build dependencies with zypper * Michal Zugec: Network Documentation".
PCLinuxOS Magazine July 2008 ReleasedPCLinuxOS Magazine for July 2008 is out. The issue is available in html format, or download the full color PDF format.
Newsletters and articles of interest The Perfect Server - OpenSUSE 11 (HowtoForge)HowtoForge sets up a server with openSUSE 11. "This is a detailed description about how to set up an OpenSUSE 11 server that offers all services needed by ISPs and hosters: Apache web server (SSL-capable), Postfix mail server with SMTP-AUTH and TLS, BIND DNS server, Proftpd FTP server, MySQL server, Dovecot POP3/IMAP, Quota, Firewall, etc. This tutorial is written for the 32-bit version of OpenSUSE 11, but should apply to the 64-bit version with very little modifications as well."
Distribution reviews Desktop Distros (TuxMachines)TuxMachines compares some desktop distributions including Ubuntu 8.04, OpenSuse 11.0, SLED 10 SP2, Fedora 9, and Sabayon 3.4f. "Desktop Linux has come a long way since my first outings back in 1999, and all 5 distros look amazing, all 5 have a choice of i386 or 64 bit variants, which both seem to work pretty well, the strong thing about Linux is its choice of distros, you will find something you like, its just a matter of patience and trying, and level of IT awareness."
Page editor: Rebecca Sobol Development Control model railroads with JMRIJMRI is the Java Model Railroad Interface, a cross-platform open-source project that has been developed by a long list of contributors:
The JMRI project is building tools for model railroad computer control. We want it to be usable to as many people as possible, so we're building it in Java to run anywhere, and we're trying to make it independent of specific hardware systems.
JMRI is intended as a jumping-off point for hobbyists who want to control their layouts from a computer without having to create an entire system from scratch.
JMRI provides the DecoderPro and
PanelPro
applications, tools for model railroaders who want to configure
DCC decoders and create control panels.
DCC, the Digital Command Control system, uses a PC-connected interface to send power and two-way control signals over the model railroad track to control boards on model train engines and other peripherals such as track switches and lights. The protocol allows for the control of multiple engines, each engine can have addressable lights, sound effects, smoke generators, etc. The JMRI Hardware Support document lists a wide variety of supported DCC interface devices and other controller options. The JMRI Help System document and DecoderPro Manual are a good place to read about the capabilities of the system. Production version 2.2 of JMRI was announced on July 15, just in time for the 2008 National Model Railroad Convention in Anaheim, CA: "At long last, the 2.1.* series of JMRI test releases has resulted in something good enough for new users to start with, our definition of a "production" release. We're therefore making a new production version, JMRI 2.2, available today." A number of JMRI clinics are being held at the NMR convention. The release notes for version 2.2 mention support for many new devices, improved support for existing devices, new scripts, documentation improvements and more. ![[JMRI]](/images/ns/jmrilogo.png)
The JMRI project has suffered a legal controversy: "For the last three years JMRI has been under attack by Matt Katzer and his attorney Kevin Russell. They have been using various coercive tactics, some of which we believe are illegal, in an attempt to put a stop to JMRI's work or to extract money from JMRI. Katzer, through his attorney Russell, obtained a patent on model railroad technology that other people had developed years before. Using a "continuation" application, they applied for a patent that covered JMRI after JMRI had openly published its code. Because Katzer and Russell didn't provide the prior art to the Patent Office, the patent was promptly issued." (Also see this LWN article from April 2006). Donations are being accepted for the JMRI legal defense fund. Despite having no compatible hardware, your author decided to download JMRI 2.2 onto an Ubuntu Hardy Heron system with the default OpenJDK Runtime Environment version 1.6.0-b09. The JMRIdemo application was run and everything started up as expected. The demo allows the user to step through the user interface and see the various configuration and control screens. To get an idea of the amount of complexity that a JMRI system can handle, see the SP Shasta Route model railroad layout that is featured at this year's NMR convention.
System Applications Database Software Firebird 2.5 Alpha 1 is ready to testFirebird 2.5 Alpha 1 has been released. "The Firebird Team is pleased to let loose the first Alpha of Firebird 2.5, more or less feature-complete and ready to field-test. Kits are available for 32-bit and 64-bit Windows and Linux. So - please test it well and report your experiences (good or bad) to the firebird-devel list."
MySQL 5.1.26-rc has been releasedVersion 5.1.26-rc of the MySQL DBMS has been announced. "MySQL 5.1.26-rc is slated to be the last release candidate before we declare MySQL 5.1 as "production ready" (GA). We therefore appreciate any feedback and community testing of this release, to ensure that we have ironed out any remaining critical issues. This one is still labeled a "candidate" release, so the usual hints about a pre-production release apply."
Postgres-R released as free softwarePostgres-R is a multi-master database replication mechanism aimed at high-availability, clustered environments. Postgres-R developer Markus Wanner has just announced that it is now free software. As a free software project Postgres-R is in an early state, being distributed as a patch to PostgreSQL proper. But there seems to be some interest in this release, which should help it to be pulled into shape quickly. See this additional posting for some information on the current status of this code.
PostgreSQL Weekly NewsThe July 13, 2008 edition of the PostgreSQL Weekly News is online with the latest PostgreSQL DBMS articles and resources.
Embedded Systems BusyBox 1.11.1 announcedStable version 1.11.1 of BusyBox, a collection of command line tools for embedded systems, has been announced: "Bugfix-only release for 1.11.x branch. It contains fixes for awk, bunzip2, cpio, ifupdown, ip, man, start-stop-daemon, uname and vi."
Web Site Development FCKeditor.Java: 2.4 released (SourceForge)Version 2.4 of FCKeditor.Java has been announced. "Online text editor (DHTML editor), for ASP, ASP.NET, ColdFusion, PHP, Java and JavaScript brings to the web many of the powerful features of known desktop editors like Word. It's XHTML compliant and works with Firefox, Mozilla, Netscape and IE. The stabilization of version 2.4 of our Java integration package has been completed successfully. One important issue has been solved, making upgrading strongly recommended."
Yet another Bulletin Board: 2.2.3 released (SourceForge)Version 2.2.3 of Yet another Bulletin Board has been announced. "YaBB is a FREE Perl forum (bulletin board) system that has rivaled professional message boards for years. YaBB provides chat for visitors where they can post any time and reply to anyone! Just 5 weeks after the last release, we are proud to announce Yet another YaBB update! This release provides primarily bug and layout fixes. There are a few minor bonus feature additions too."
Desktop Applications Audio Applications Ardour 2.5 releasedVersion 2.5 of Ardour, a multi-track audio workstation package, has been announced. "As happens all too often, its been longer than expected between releases, but finally Ardour 2.5 is ready to ease the path, soothe the brow and excite the heart of musicians and audio engineers worldwide. Tons of bug fixes and several new features will make it worthwhile for everyone and anyone to try this out."
Sonic Visualiser 1.3 now availableVersion 1.3 of Sonic Visualiser, an audio analysis utility, has been announced. "This is a feature release, containing several new features and a number of bug fixes over the previous 1.2 release."
Vamp plugin SDK v1.3 now availableVersion 1.3 of Vamp plugin SDK has been announced. "Vamp is a plugin API for audio analysis and feature extraction plugins written in C or C++. Its SDK features an easy-to-use set of C++ classes for plugin and host developers, a reference host implementation, example plugins, and documentation. It is supported across Linux, OS/X and Windows. Version 1.3 is a maintenance release, with several bugfixes (almost all of which only affect hosts, not plugins) and no new features."
Desktop Environments GNOME Software AnnouncementsThe following new GNOME software has been announced this week:
KDE Commit-Digest (KDE.News)The June 8, 2008 edition of the KDE Commit-Digest has been announced. The content summary says: "Global keyboard shortcuts for applets, and an Amarok and "python expression" runner in Plasma. A Java test applet and various interaction improvements in Plasma. Simple network and CPU monitors in the system-monitor Plasmoid. Initial import of PeachyDock, a Plasma-based alternative panel. The Oxygen window decoration gets the "on-all-desktops" button. Continued development toward Amarok 2.0. KDevelop gets a new context browser, and various other improvements..."
KDE Software AnnouncementsThe following new KDE software has been announced this week:
Xorg Software AnnouncementsThe following new Xorg software has been announced this week:
Desktop Publishing LyX version 1.6.0 (beta 4) is releasedVersion 1.6.0 beta 4 of LyX, a gui front end to the TeX typesetter, has been announced. "Compared with the latest stable release, this is the culmination of one year of hard work, and we sincerely hope you will enjoy the results. This release is the last planned beta release in the path that leads to 1.6.0, the beta status is thus an indication of the development stage and so we advise care when using this release. Please back up your work before using this release as it should be generally done in a beta release."
Educational Software Mnemosyne: 1.0.2 released (SourceForge)Version 1.0.2 of Mnemosyne has been announced, it includes some new features and bug fixes. "Mnemosyne resembles a traditional flash-card program but with an important twist: it uses a sophisticated algorithm to schedule the best time for a card to come up for review."
GUI Packages Urwid 0.9.8.3 - Console UI LibraryVersion 0.9.8.3 of Urwid, a console-based user interface library, has been announced. "This is a maintenance release that fixes a memory leak and a canvas bug affecting Urwid 0.9.8, 0.9.8.1 and 0.9.8.2."
Interoperability Wine 1.1.1 announcedVersion 1.1.1 of Wine has been announced. "What's new in this release: - Fixes for Photoshop CS3 and Office 2007 installers. - More progress on gdiplus. - Support for Unicode files in regedit. - Improved video playback. - Many Richedit fixes and improvements. - Various bug fixes."
Music Applications Qsynth 0.3.3 - Knobs GaloreVersion 0.3.3 of Qsynth, a Qt GUI frontend to the FluidSynth soft-synth library, has been announced. "Thanks to Pedro Lopez-Cabanillas and Guido Scholz, this Qsynth release is now a reality. Main new features are a the new rotating knob style options, first full translations, German and Spanish and last but not least, there's this Windows(TM) all-in-one package available (includes FluidSynth port) for your (sick:) pleasure only."
Rubber Band v1.2 availableVersion 1.2 of Rubber Band, an audio time-stretching and pitch-shifting library and utility, has been announced. "Version 1.2 is faster in most situations, better sounding in many, and less potentially subject to patent claims than version 1.0.1 was."
Office Suites New OpenOffice.org 3.0 beta available for testingOO.o 3.0 beta 2 has been released. "The OpenOffice.org Community is pleased to announce that a new public beta release of OpenOffice.org 3.0 is now available. This second beta release has been produced in response to feedback to the first beta, released in May. It is made available to allow as many users as possible to test and evaluate the next major version of OpenOffice.org, but is not recommended for production use at this stage."
Web Browsers Firefox 2.0.0.16 ReleasedAn update to the Firefox 2 browser has been released; it fixes a couple of security issues, including a remote code execution vulnerability. "Note: Firefox 2.0.0.x will be maintained with security and stability updates until mid-December, 2008. All users are encouraged to upgrade to Firefox 3."
Languages and Tools C GCC 4.3.2 Status ReportThe July 14, 2008 edition of the GCC 4.3.2 Status Report has been published. "The GCC 4.3 branch is open for commits under normal release branch rules. The 4.3.2 release is expected around 2008-08-06."
Caml Caml Weekly NewsThe July 15, 2008 edition of the Caml Weekly News is out with new articles about the Caml language.
Haskell Haskell Weekly NewsThe July 9, 2008 edition of the Haskell Weekly News is online with the latest Haskell language articles.
Java OpenSwing: 1.6.8 released (SourceForge)Version 1.6.8 of OpenSwing has been announced. "OpenSwing is a component library that provides a rich set of advanced graphics components and a framework for developing java applications based on Swing front-end. It can be applied both to rich client applications and Rich Internet Applications. In this release: Added new global property "AUTO_EXPAND_TREE_MENU" to ClientSettings, in order to auto expand tree nodes in application tree menu of MDIFrame. Fixed problem in TreePanel when invoking repaintTree() method: in past releases this method removed some listeners..."
Lisp Common Lisp Reasoner: 1.0.1 released (SourceForge)Version 1.0.1 of Common Lisp Reasoner has been announced. "The Common Lisp Reasoner extends the Common Lisp Object System (CLOS) to incorporate a rule language and support a variety of practical AI-related search and reasoning tasks, including scheduling, planning, diagnosis and predictive reasoning. The Common Lisp Reasoner adds integrated knowledge representation, reasoning and search capabilities to Common Lisp. The latest release is a revision to ensure maximum portability across Common Lisp implementations, including for the first time, SBCL".
Perl Parrot 0.6.4 released (use Perl)Version 0.6.4 of Parrot has been announced. "On behalf of the Parrot team, I'm proud to announce Parrot 0.6.4 "St. Vincent Amazon." Parrot is a virtual machine aimed at running dynamic languages."
Python Jython 2.5 alpha releasedVersion 2.5 alpha 0 of Jython, a Python implementation in Java, is out. "This is the first alpha release of Jython 2.5 and contains many new features. In fact, because we have skipped 2.3 and 2.4, there are too many to even summarize."
Announcing the netaddr library for PythonThe new NetAddr library for Python has been announced. "It is a network address manipulation library released under the BSD license. It supports several of the most common address formats (IPv4, IPv6 and MAC and IEEE EUI) as well as several aggregate notations such as CIDR. An effort has been made to provide an API that is as Pythonic as possible. NetAddr is now in beta (latest release is 0.3.1) and is currently being actively developed. Developers and testers are needed to assist in improving the quality and availability of network library support for Python which is distinctly lacking when compared with other popular interpreted languages such as Ruby and Perl. NetAddr is an attempt to redress this imbalance to some extent."
Tcl/Tk Tcl-URL! - weekly Tcl news and linksThe July 10, 2008 edition of the Tcl-URL! is online with new Tcl/Tk articles and resources.
Tcl-URL! - weekly Tcl news and linksThe July 16, 2008 edition of the Tcl-URL! is online with new Tcl/Tk articles and resources.
Version Control GIT 1.5.6.3 releasedVersion 1.5.6.3 of the GIT distributed version control system has been announced. "The changes since the previous maintenance release is getting smaller. About half the diff is in Documentation/ section."
Page editor: Forrest Cook Linux in the news Recommended Reading Is Gentoo Ready for Latest Linux Release? (InternetNews.com)InternetNews.com inquires into the current state of Gentoo. "[Donnie] Berkholz is of the belief that if Gentoo creates a great developer community, they'll build a great distribution, which will naturally draw users. Though there is a caveat. 'I do think there is an upper limit on our user base in Gentoo's current form, because there's only so many people willing to build from source,' Berkholz noted. 'As hardware gets faster, that does increase, but it's still a matter of compiling OpenOffice.org for 3 hours versus installing a binary version of it in 5 minutes.'"
KDE on KDE 4.0 (Groklaw)Groklaw has Sebastian Kügler debunk 11 Myths About KDE 4. "Lately a lot has been said (or bemoaned) in the community about KDE 4, the 4.0 release and the KDE developers. In the following article we would like to address some common misconceptions about KDE 4 as we see it. As we firmly believe in KDE 4 and the future of the Free Desktop, we expected the heated discussions about KDE4 and especially the 4.0 release to go away - and we were wrong about that. As blogging about the issues raised didn't seem to reach the audience we intended, we took the opportunity presented by Groklaw for this article with both hands. We sincerely hope it sheds some light on why the KDE community did what it thought it had to do and we hope it shows we do take the criticism seriously."
Companies Xandros buys Linspire What does it mean for Linux? (ITPro)ITPro writes off Xandros and Linspire in this lengthy article. "Where Xandros is sold in a box, Ubuntu is given away free. Where Ubuntu is seen to donate code back to the community, Xandros and Linspire have developed proprietary extensions. Where Ubuntu asks for manufacturers to free their drivers, Xandros and Linspire have signed patent covenants with Microsoft. Being easy to install and easy to use is not enough. The first lesson of 'open source business' is that your first debt is to your user and developer communities, from which everything else grows. OEMs will look first to the most popular alternative."
Interviews Brian Proffitt Joins Linux Foundation as LDN Community Manager (OSTATIC)Joe Brockmeier talks with Brian Proffitt about his new job with the Linux Foundation. "OStatic: What will your duties be with the Linux Foundation? Brian Proffitt: My title is Community Manager of the Linux Developer Network, and my primary responsibility will be to direct that site to manage its content and overall direction. To do that, I'll be writing some content, figuring out what the overall content will be, and talking to Foundation members, outside vendors, and individual developers to see what kind of documentation and support they need to write apps for Linux. Then making sure they get it."
Reviews GNOME 3.0 officially announced... and explained (ars technica)Here's an ars technica article about the plans for a GNOME 3.0 release. "Although the GNOME development community is still strongly committed to maintaining its incremental development strategy for the desktop, the rules are different for GTK+, the underlying toolkit used to build the platform. Developers have grown increasingly frustrated with the limitations of GTK+ and have started to evaluate proposals for remedying its weaknesses and adding more modern capabilities."
Motorola Releases Touchscreen Linux Smartphone (InformationWeek)InformationWeek looks at a new Linux-based Linux smartphone from Motorola. "The Linux-powered handset has a sleek candy-bar form factor, and the 2.2-inch touchscreen with 240 by 320 resolution. The included stylus can be used with the built-in handwriting recognition software. The smartphone will also come preloaded with stock trading and dictionary applications, and it's capable of receiving corporate e-mail. Users will be able to surf the Web on an integrated Opera browser, but this device cannot access 3G networks. Instead, the handset uses EDGE data for browsing and retrieving e-mails, with a top downlink speed of 236.8 Kbps."
Test drive OpenOffice.org 3.0 (Tectonic)Tectonic reviews the OpenOffice.org 3.0 beta. "The import extension opens PDF documents in either Impress or in OpenOffice Draw. The PDF is imported and each line of text can be edited as a single entity. Importing PDFs at this point does work but there are variable results in the formatting of documents, particularly those with complex layouts. But standard documents with a linear layout work reasonably well."
Ubuntu Photo Manager Experiment (Ubuntu Productivity)Ubuntu Productivity reviews several free and commercial photo editing applications for Linux. "I have a passion for photography and have become heavily entrenched in the tools available on Mac OS X, such as Aperture and Photoshop. This experiment focuses mainly on Aperture and what tools, if any, exist for Ubuntu to replace my Aperture workflow with something cross-platform and open-source that I can use on Mac OS X and Ubuntu."
Miscellaneous In memoriam: Linux evangelist and Linux.com editor Joe BarrLinux.com reports the death of longtime Linux author Joe Barr. "Many knew him as a Linux evangelist; others knew him from his ham radio activities. And those of us who worked with Joe knew him in all of his sometime irascible, often funny moods. Joe was always one of our favorite people, and we are devastated to report that he died at home, unexpectedly, last night."
Page editor: Forrest Cook Announcements Non-Commercial announcements Support the Django Software FoundationA call for funding has gone out for the recently created Django Software Foundation. "A short while ago, we announced the creation of the Django Software Foundation, a non-profit organization that exists (among other reasons) to sponsor Django coding sprints and other events for our community. Now, we're kick-starting the foundation by holding a fundraising drive. With Django 1.0 around the corner, our immediate goal is to raise enough money to support the upcoming pre-1.0 coding sprints, which bring developers together in the real world for highly productive design and programming sessions. After the 1.0 release, we're planning to fund regularly scheduled sprints, user meet-ups and other community events."
In Memory of Uwe Thiem (KDE.News)KDE.News reports on the passing of Uwe Thiem. "I'm very sorry to let everyone know that Uwe Thiem, a long term contributor to KDE, passed away yesterday at 14:45 of kidney failure. Uwe was one of the longest contributors to the KDE family and was one of the original members of the core development team. He moved on to become the main KDE representative in Africa. Uwe was one of the first people to write a book on KDE development, which helped many people who have become regular contributors today, and was still writing about KDE last week."
New Books High Performance MySQL, Second Edition - New from O'ReillyO'Reilly has published the book High Performance MySQL, Second Edition by Baron Schwartz, Peter Zaitsev, Vadim Tkachenko, Jeremy D. Zawodny, Arjen Lentz, and Derek J. Balling.
Learning Perl, Fifth Edition - New from O'ReillyO'Reilly has published the book Learning Perl, Fifth Edition by Randal L. Schwartz, Tom Phoenix, and brian d foy.
Resources ODBMS.ORG releases new reportsODBMS.ORG has announced the availability of a series of new reports. "ODBMS.ORG, a vendor-independent non-profit group of high-profile software experts lead by Prof. Roberto Zicari, today announced the exclusive publication of a new series of user reports on using technologies for storing and handling persistent objects: http://www.odbms.org/downloads.html#odbms_ur".
Contests and Awards Applications are open for the 2008 Pizzigati PrizeApplications are being accepted until September 1 for the 2008 Pizzigati Prize. "The Tides Foundation is proud to announce the 2008 Antonio Pizzigati Prize for Software in the Public Interest. This prize will go to a software developer who has made, in the open source spirit, an outstanding contribution to the nonprofit world and the ongoing work of social change."
Surveys mod_perl Users Survey (use Perl)A user survey for mod_perl has been announced. "At the impromptu mod_perl BOF at YAPC::NA, Fred Moyer and myself hacked together a short mod_perl survey to help identify the current needs of mod_perl users. It was inspired by the Perl survey done last year by Kirrily Robert."
Calls for Presentations CFP now open for ClubHack2008 - IndiaA call for papers has gone out for ClubHack2008. "ClubHack is India's own international hackers' convention started in 2007. We are expecting good deep knowledge technical presentations/demonstrations on topics from the world of Information Security. These presentations are expected to be of 40 minutes each. The schedule time for each presenter would be 50 minutes out of which 40 minutes are for the presentation & 10 for the question-answer sessions. We'd request you to submit the papers keeping the time constraint in mind."
Linux-Kongress 2008Linux-Kongress is one of the original Linux development conferences. The 2008 edition has been announced for October 7 to 10 in Hamburg, Germany. The call for papers has gone out, with submissions due by August 4.
Upcoming Events Sprinting to the finish (Django)The Django web platform project has announced a series of coding sprints leading up to the 1.0 release. "To help get everything done by the deadline, we'll be holding a series of sprints. Over the next six weeks we'll hold sprints in Sausalito, Lawrence, Austin, Washington, DC, and Portland, and virtually all over the world. Each sprint day we'll devote at least 24 hours of focused work. Each sprint will be on a Friday, though work will likely continue at a fair clip into the weekend."
KDE and GNOME to Co-locate Flagship Conferences on Gran Canaria in 2009 (KDE.News)KDE.News reports on the decision to co-host next year's Akademy and GUADEC conferences in Gran Canaria, Canary Islands. "The conferences will be separate events, but co-located and hosted by the same organizers, the Cabildo of Gran Canaria and its Secretary of Tourism, Technological Innovation and Foreign Trade."
EuroSciPy - First Slides OnlineSome conference slides are available for the upcoming EuroSciPy conference. "The EuroSciPy Conference will be held July 26-27, 2008 in Leipzig, Germany."
Announcing openSUSE Day at LinuxWorld ExpoThe LinuxWorld openSUSE Day has been announced. "Join the openSUSE Project for a day of fun and FOSS at the LinuxWorld Expo! On Wednesday, August 6th, the openSUSE Project will be holding its first "openSUSE Day" in North America, in conjuction with the LinuxWorld Expo at the Moscone Center in San Francisco. We'll have a full day of presentations about the openSUSE Project, KDE, GNOME, the Linux kernel, the openSUSE Build Service, and much more."
Events: July 24, 2008 to September 22, 2008The following event listing is taken from the LWN.net Calendar.
If your event does not appear here, please tell us about it.
Page editor: Forrest Cook
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[The
art of Ingo Molnar]](/images/ns/kernel/gitk-octopus-sm.png)