LWN Weekly Edition
Leading itemsSecurity
Kernel development
Distributions
Development
Announcements
->Multipage format
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for January 13, 2011Ruminations on the "cloud problem"While the term "cloud" is fairly amorphous, the central idea of ubiquitous access to one's data and applications from anywhere—on all kinds of devices—is clearly attractive. But, at least as currently implemented, cloud computing is worrisome to free software advocates and anyone even a little concerned about their privacy. There are, of course, various free software efforts to offer alternatives to some of the more popular cloud services but, by and large, they are just getting started and have seen little to no adoption. The beginning of a new year is a good time to consider what cloud services might look like if—when—they become more freedom and privacy oriented. What kind of services are we talking about here? There are the obvious candidates like social networking and email—largely dominated by Facebook, Twitter, Gmail, and the like—but there are, other possibilities as well. Easily accessible, and affordable, cloud data storage would allow users to access documents, music, ebooks, movies, pictures, and so on from any internet-connected device. Sharing and collaborating using that information with friends, relatives, and colleagues should be straightforward as well. Much of this infrastructure already exists in various "walled gardens" that seek to lock users into their service to the exclusion of others. Facebook doesn't make it easy (or even possible in some cases) to remove one's data from their clutches, nor to collect information from "your" social network. That has good and bad points, of course, as most would probably prefer that their email address not get collected by a spammer posing as a "friend". Google has made some efforts to make it easier for users to get their data out, in particular the Data Liberation Front, but most cloud application providers are trying their best to keep users locked in. Not storing unencrypted personal data on the servers of the cloud application providers is the only really foolproof method of retaining control over that data. The model envisioned by the Diaspora project is interesting because the data stays on the user's server (or one under his control). The Diaspora application then facilitates sharing that data with various subsets of the user's "friends". If Grandpa posts a link to embarrassing photos stored in Diaspora to another service, the user can easily remove access because that data stays under his control. Nothing can really protect against Grandpa (or someone else with access) actually posting the photos elsewhere, rather than just a link; one must be able to trust the people that they give access to. But it is more than just photos and snarky status updates. Email is another, obvious candidate for cloud storage. Many folks use Gmail or other services, but there are privacy implications even if Google makes it relatively easy to pull email out of its system. Governments have seemed to be easily able to access information in email accounts, sometimes without even the nicety of a subpoena or other legal document. Employees of those services are likely to be able to access the messages stored in email accounts as well. Beyond that, how about text documents, spreadsheets, favorite applications, desktop settings, browser bookmarks, Gnucash or Quicken data files, and so on? For the most part, those currently live in user's desktop home directories, with semi-synchronized versions living on laptops, GoogleDocs (and the like), and on smartphones—if they are available elsewhere at all. Firefox and other browsers have ways to sync browser data (bookmarks and settings) between multiple browser instances, but why should those settings be treated any differently than Thunderbird preferences, or GNOME/KDE settings? Will there need to be a distinct mechanism to sync each and every different application? It would be nice to believe that some day there will be ways to securely store this kind of data "in the cloud", such that only the owner of the data has the keys to decrypt it. There are already existing services, like Dropbox or SparkleShare, where users can store data, encrypted or not, but they lack an access layer that handles the encryption cleanly. Users must be able to access and share the encrypted data without turning over the keys to the storage provider. The technical challenges of that aren't massively difficult on the cryptographic side, as the Tahoe secure filesystem shows, but there are still a number of other hurdles to overcome. In order for there to be any reasonable level of adoption by the general public, any kind of cloud server solution will have to be easy to use. Coming up with a way to tie together the storage for disparate objects like email, settings/preferences, documents, and so forth will be challenging enough without making wholesale changes to the applications themselves. But any sensible solution also needs to account for the possibility that users will want/need to access that data when the internet is not available. Changes would then need to be synced at some later point. While free software applications would be relatively easy to change to support some kind of new protocol for retrieving and updating settings and the like, it might be easier to avoid that for existing applications. Instead, some kind of "wizard" could be created that understands the local storage used by various applications (both free and proprietary) and could manage the transfer and synchronization as needed. Newer applications or major updates to existing programs could, of course, take this cloud storage mechanism into account. Another hurdle is that internet-connected servers cost money. Most users, especially those who are not particularly technically savvy, won't want to run their own server. Instead, some kind of low-cost, easy-to-use, services would need to be available to provide those users a landing place for their encrypted data. Given the prevalence (and popularity) of gratis web services, it may well be that getting the general public to pay for that kind of service is difficult or impossible. If so, it will be their loss, as the current situation turns users into the product to be sold to advertisers and others, as has been noted elsewhere. For the rest of us, perhaps, the addition of an income stream for storage providers will turn that relationship on its head, making the users into customers. Given that a system that respects privacy really won't have much in the way of useful data to sell to advertisers, since encryption will be the norm, there needs to be another way to generate income. While it certainly won't generate the enormous market valuations that companies like Facebook do, there will hopefully be enough business to support some cloud storage providers. Even users that want to run their own server may have use for a backup elsewhere, and if the service is cheap enough for a nice chunk of storage (on the order of $5/month for example), it will likely be easy to justify. Maybe these ideas are overambitious and/or too pie-in-the-sky. Privacy is not very highly valued by most these days, so it may well be that storing one's data in the cloud will really mean that it gets stored with Google, Facebook, Apple, or others. Other than a lot of work, there are no huge technical barriers to overcome. Some kind of protocol needs to be established or adopted, some encryption key management issues need to be considered, and so on, but they aren't terribly difficult. Instead, the difficult barriers are largely social and political. On the other hand, though, it sure would be nice to be on the road some day, open my laptop (or tablet or phone or ...), and pick up right where I left off at home, with access to the same information, settings, applications, and so on. Hopefully I won't have to wait as long for that as I've been waiting for my personal robot and flying car ...
OpenStreetMap's point of no returnBack in 2008, LWN reported on the OpenStreetMap project and its plan to change the licensing of its map database. This change was controversial, to say the least, but the project as a whole appeared to be determined to press forward with it. At the beginning of 2011, the license change has not yet happened. But it has now been determined that April 1 of this year will be an important milestone date in this process. This could be interesting to watch, as the project is still not entirely sure of what it is changing to.The new license - the Open Database License (ODBL) - is well understood. The ODBL is an attempt to stretch European-style database rights to the point where they cover the database worldwide. To that end, the ODBL is explicitly written as a contract - a crucial difference from most free licenses, which try to avoid contract law entirely. The ODBL must take this approach because the OpenStreetMap database, being primarily factual in nature, is not easily covered by copyright. A license which relied strictly upon copyright law would risk being unenforceable in much of the world. Of course, relying on contract law has its own difficulties - contracts are only binding if everybody involved has agreed to them. Direct downloads of the database from OpenStreetMap will require a click-through agreement, but further redistribution (which is naturally allowed by the license) need not involve any such formalities. If there is ever a case in a part of the world which does not recognize database copyrights, where the defendant denies having ever agreed to the contract, the outcome could be interesting to say the least.
Be that as it may, the
Subject to Section 3 below, You hereby grant to OSMF a worldwide,
royalty-free, non-exclusive, perpetual, irrevocable license to do
any act that is restricted by copyright over anything within the
Contents, whether in the original medium or any other. These rights
explicitly include commercial use, and do not exclude any field of
endeavour. These rights include, without limitation, the right to
sublicense the work through multiple tiers of sublicensees.
The "Section 3" mentioned above restricts the Foundation to the use of ODBL, CC-BY-SA, or "another free and open license." This agreement has been somewhat controversial within the project for a number of reasons, starting with the mechanism by which the license could be changed (again) in the future: a vote of "active contributors" would be held. Some people seem to fear that a future, dark-side Foundation could restrict contribution for a bit, then hold a rigged election to obtain the results it wants. The contributor agreement also restricts contributors to adding data to which they, personally, hold the copyright (if any). Much of the data going into OpenStreetMap, though, comes from governmental sources and may have its own license terms applied to it. Forgoing that data seems undesirable, so some contributors understandably complained. In response, there is now a draft update to the agreement which softens that requirement. This draft has not yet been adopted, though, and there are suggestions that further changes are in the works. Despite the lack of an updated agreement, the OpenStreetMap board recently mandated that, after March 31, only contributors who have accepted the agreement will be allowed to make changes to the database. That clears the way for the final step: the removal of all data for which permission to relicense has not been obtained. Some contributors fear that quite a bit of data could be lost at that time. How much data is entirely unclear. There appears to be no publicly-available information on how many contributors have accepted the agreement, or how much data can be relicensed. There seems to be confusion about what will happen to data contributed by one person (who may not have accepted the agreement) which was subsequently edited by another (who did agree) - or vice versa. People within the Foundation may have a good idea of what the consequences of the license change will be, but they don't seem to be talking much; requests for information (example) have gone unanswered. The board did say, in its December 2010 meeting minutes, that:
The board discussed the issue of data loss and expects, considering
what has been seen, it will not be a showstopper at the time of the
final switch.
In any case, that "final switch" may still be some time in the future. The April 1 deadline ensures that new data is ODBL-compatible, but it does not, itself, force a relicensing of the database. The OpenStreetMap license change page contains a lot of information about the new license and the motivation for the change, but it contains no dates for an actual changeover. So this transition, which has dragged on for some years, could continue to drag for a while yet, especially if it looks like a lot of data could be lost. The prospect of a significantly reduced map database could give strength to the loud contingent of contributors who would rather see the project just put the data into the public domain and be done with it. The motivations which are driving the move to the ODBL are similar to those behind the use of the GPL for code; contributors do not want to see others distribute enhanced versions of their work without giving back their changes. But trying to extend the reach of copyright to data it does not naturally cover, in a project involving many thousands of contributors, is never going to be an easy thing to do. There is no clear map showing a way out of this situation.
Supporting OOXML in LibreOfficeThe formation of the Documentation Foundation and the launch of the LibreOffice project have created a user and developer community which has few parallels elsewhere in the free software world. This community is huge given the newness of the project, and it appears to include many people who have not engaged with free software development in the past. As a result, the Foundation's mailing lists sometimes host conversations that wouldn't be found in other projects. An extensive and sometimes bitter debate on whether LibreOffice should write files in the OOXML format is a good example of differing views of how this project (and free software in general) should work.OOXML, of course, is the Microsoft-driven "standard" alternative to the ODF format. Given its sponsor and the dubious means by which it attained "standard" status, OOXML was always going to be controversial. The simple fact of the matter, though, is that, if Office writes OOXML files, then those files will proliferate. Whether we like the format or not has little influence on the final result. Just before the end of the year, Larry Gusaas called on the LibreOffice community to refuse to support the writing of OOXML files. Standard OpenOffice.org is able to read such files, but will not write them; that is, according to Larry, how things should be. But LibreOffice is based on the Go-oo project, which is the version of OpenOffice.org which has actually been shipped by most Linux distributions. This version does have the ability to write OOXML files; thus, LibreOffice does as well. Quite a few people supported Larry's desire for read-only OOXML support in LibreOffice; one could easily peruse the thread and come to the conclusion that the LibreOffice community is overwhelming opposed to the idea of writing in that format. Even so, a number of LibreOffice developers have made it clear (repeatedly) that they have no intention of removing the ability to write OOXML files. There is, thus, no need to worry that we might have to go on using Go-oo after all. There are many reasons for LibreOffice to support this format, even if the community has to collectively hold its nose in the process. The reality of the situation is that many LibreOffice users will need to work with people who send them OOXML files and will expect to get a response in the same format. Telling collaborators that their choice of document format is unacceptable works in some situations, but a corporate employee who talks that way to a customer may soon end up with a great deal of unexpected free time. A LibreOffice which cannot write OOXML files would be unsuited to many environments, and adoption would suffer accordingly. Beyond that, as has been pointed out in the discussion, Microsoft will, someday, phase out support for its (equally proprietary) DOC format, leaving OOXML as the only real option for document interchange. There appears to be little hope that Microsoft's ODF support will be sufficient to make ODF a viable alternative. So any office productivity suite which aspires to millions of users, and which does not support OOXML, will find itself scrambling to add that support when DOC is no longer an option. It seems better to maintain (and improve) that support now than to be rushing to merge a substandard implementation in the future. A number of people in the LibreOffice community seem to be under the impression that free software is about fighting Microsoft. But free software is really about giving freedom to its users and developers; one of the key ways in which that freedom has been expressed since the beginning is through a high level of interoperability. Linux systems speak most protocols, and they handle most file formats of interest. That makes it possible to plug in a Linux system almost anywhere and to work with almost everybody. We should think long and hard before we walk away from that sort of freedom. We should also think about (1) whether a project like LibreOffice really has the weight to affect document format use by withholding support for those it doesn't like, and (2) whether we as a community would want to use that power in that way if we did have it. There is a separate message from Larry which brought out another interesting aspect of the debate:
It should be a community decision, not one made by the
developers. Or based on LibreOffice being based on Go-OO code which
already had OOXML write support because of the Novell agreement
with Microsoft.
It is a rare free software project indeed which allows a decision of this kind to be made by anybody but the developers involved. Most such projects are those controlled by corporations which have no qualms about vetoing features which do not align with The Official Product Roadmap. Debian does allow the community to shape its distribution through its general resolution mechanism, but those who are allowed to vote on resolutions are almost exclusively developers, and they are all contributors. Few other communities even have a way by which the community as a whole could attempt to make such a decision, much less enforce it. The Document Foundation's proposed bylaws do envision a board of directors and an engineering steering committee which could address such issues, but such institutions will only override the developers in extreme situations; otherwise, they tend not to have many developers to override. In the free software world, the people who do the work make the decisions about that work, and there are few who would seek to change that state of affairs. In this discussion, developers have not been calling for the removal of full OOXML support, and no patches to that effect have been posted. LibreOffice is shipping with that support, and that situation seems unlikely to change. So, it seems, the LibreOffice developers have made the decision to continue to support writing the OOXML format. They are well aware that OOXML is not an ideal document format, that its attainment of "standard" status was shadowy at best, that it is another proprietary moving-target format, and that there is still some patent uncertainty surrounding it. They are aware that the much more open (though still imperfect) ODF format is preferable, and that ODF should be the default format used by LibreOffice. But they have also concluded that supporting OOXML gives more freedom and capability to their users and is good for LibreOffice in the long term.
Security Trusted internet identityThe US government has recently been pushing a scheme to create some kind of "trusted" identity for people to use on the internet. At a meeting at Stanford University on January 7th, US Commerce Secretary Gary Locke outlined the problems that he perceives with trust on the internet and how the creation of "trusted digital identities" might alleviate those problems. There is likely some truth in what he says, and trusted identities could well fix some of the problems. Unfortunately, when looking at it from a privacy perspective, that kind of scheme is likely to cause more problems than it solves. The threats that Locke describes are fairly well-known: "data breaches, malware, ID theft and spam". It's not exactly clear how a trusted identity would fix any of the problems he lists, but that's not really his role. He is trying to build a groundswell of support for these identities, but he is also being rather disingenuous when he says things like:
Let's be clear. We are not talking about a national ID card. We are not
talking about a government-controlled system. What we are talking about
is enhancing online security and privacy and reducing and perhaps even
eliminating the need to memorize a dozen passwords, through creation and
use of more trusted digital identities.
PRIVACY Forum moderator (and long-time privacy advocate) Lauren Weinstein has been following this plan (which originates in the US Department of Homeland Security) since at least last June. As he points out, the entire trusted identity scheme rests on those identities being linked to government-issued IDs like driver's licenses or social security numbers. While Locke might be technically correct about national IDs, he is playing rather fast-and-loose with the reality as Weinstein notes:
This entire scheme rests on the ability to link Internet
presence/roles with real-world identities. So even if no physical
card ever exists, the system as currently understood would very much
equate to a national ID card for accessing the Internet.
There are the obvious problems with linking internet activity back to a particular "meatspace" identity, not least that it removes the ability to do some things anonymously. Those records will be an attractive target for fishing expeditions by law enforcement of various sorts. One need not look any further than the current attempts to track down Wikileaks members and supporters via Twitter records as an example of how this kind of data might be misused. At the meeting, White House Cybersecurity Coordinator Howard Schmidt said that there is no chance "a centralized database will emerge". Even if that's true, it won't be terribly hard to reconstruct an internet trail from distributed databases if the ID is tied to government-issued credentials. Trusted IDs would also be a juicy target for identity thieves. In short, these IDs suffer from privacy and control issues that have been identified for decades by people like Weinstein and organizations like the Electronic Frontier Foundation. While Locke may be giving lip service to some of those longstanding concerns, it is pretty clear that, at least so far, there is no real intent to address them. There is also a question of how free software fits into this puzzle. Is presenting a trusted identity going to require running proprietary code? Is it going to require running a Trusted Platform Module attested operating system as well? The latter is clearly something that Microsoft and Apple would be happy to see, but it would run completely counter to the ideas of free and open source software. Ars technica digs in to some of the technical details of the most recent draft [PDF] of the proposal. That analysis certainly doesn't alleviate any of the issues that Weinstein raises, and in fact raises a few others, such as:
In stage number six, the project will address the "liability concerns of
service providers and individuals." It looks as though the project will
create rules for the system that allow for the fixing of security breaches
without everyone suing each other's brains out, perhaps something like the
Digital Millennium Copyright Act's safe harbor provisions. The last three
stages involve promoting and improving the Ecosystem, including offering
loans, tax breaks, and insurance grants for early adopters.
Another draft is due in the next few months, and Weinstein is not very optimistic:
Revised details of the Internet "Trusted ID" NSTIC plan will
reportedly be released within a matter of months. Perhaps there will
be wondrous revelations that will transform my current very dark view
of the proposal into a ringing endorsement.
Unfortunately, I very much doubt that this will be the case. I wish I did not have to be so cynical and concerned about this project. Contrary to some observers, I don't feel that the proponents of this plan are evil or stupid, nor that their motives aren't in large measure essentially laudable. But a lack of evil and stupidity does not eliminate short-sightedness, foolishness, and priorities run dangerously amok. Schmidt is also pushing the idea that acquiring a trusted identity would be voluntary, but if the system gets put in place it's a little hard to believe it will be. The internet is playing a bigger and bigger role in our lives. If the US government succeeds in this plan, it's not hard to imagine that it will be difficult to do anything of consequence on the 'net without having such an ID. This is an issue that bears watching. One might be forgiven for cynically noting that our best defense against this plan may be the government bureaucracy itself, as it will undoubtedly take some time—perhaps on the order of years—for a proposal like this to actually get implemented. In the meantime, though, privacy advocates and free software users should be making an effort to clearly show the problems inherent in this trusted identity scheme.
Brief items Security quote of the week
So there you have it. The names are secure: they're identifiable by a key
of arbitrary length and cannot be stolen. They're human-meaningful: the
name can be whatever string you like. And they're decentralized: no
centralized authority determines who gets what name and yet they're
available to everyone in the network.
-- Aaron Swartz on
a proposed way to "square" Zooko's
triangle (by way of BoingBoing).
New vulnerabilities apparmor: tasks may become unexpectedly unconfined
bip: denial of service
cups: may start prematurely
django: multiple vulnerabilities
dpkg: directory traversal
ifupdown: dhcp may start prematurely
kernel: denial of service
kernel: privilege escalation
kernel: denial of service
kernel: information leak
kernel: denial of service
mhonarc: multiple vulnerabilities
php: denial of service
php: cross-site scripting
pidgin: denial of service
pidgin: denial of service
pyfribidi: buffer overflow
webkit: lots of vulnerabilities
webkitgtk: multiple vulnerabilities
wireshark: denial of service
wireshark: arbitrary code execution
wordpress: unauthorized access
Page editor: Jake Edge Kernel development Brief items Kernel release statusThe 2.6.38 merge window is open, so there is no current development kernel. See the separate article, below, for a summary of what has been merged to date.Stable updates: the 2.6.36.3 and 2.6.32.28 updates were released on January 7; both contain a large number of important fixes. The 2.6.34.8 update was released on January 6; it, too, contains lots of important fixes.
Quotes of the week
A golden rule is that when a programmer reads some code, he should
be able to understand why it's there. There is no way on this
little earth that a programmer will be able to look at this code
and say "ah-hah, that must be a workaround for gcc-4.5
-finline-functions!".
-- Andrew Morton
With almost every single kernel version bump we've had, we've found
numerous places where strings in the logs have subtly changed,
breaking our infrastructure :( Finding these is a painful process
and often shows up late in the deployment process. This is
disastrous to our deployment schedules as rebooting our number of
machines, well, it takes a while...
-- Mike Waychison
I'm sorry if this is tangential to your comment above, but I feel the need to have folks recognize that printk() is _not_ a good foundation on which to build automation.
The end of dcache_lockOne of the most significant changes for 2.6.38 will not be an obviously user-visible feature; it is, instead, the dcache scalability patch set by Nick Piggin. These patches rework the virtual filesystem layer in some tricky ways, eliminating a number of longstanding scalability problems. The changes were significant enough that Linus paused the merge window for a couple of days after merging them, saying:
It's scary because this is some very core code, and the new RCU
lookup model is way more clever and subtle than the old dentry_lock
spinlock.
But it's rather impressive and I really wanted to merge it, because some of the performance numbers are pretty stunning. For example, a hot-cache "find . -size" on my home directory (which basically just does name lookups to get the stat information for every file recursively) became 35% faster. And that's the _unthreaded_ case. Not some odd high-end scalability thing, and not some recompiled binary taking advantage of new facilities. Pathname lookup is just simply faster. This code mostly works, but early testers have reported an issue or two, and there are likely to be some subtle problems remaining still. This might be a good time for people running development kernels to have especially good backups. Also, as Nick noted, out-of-tree filesystems will need some changes to work with new VFS.
How not to get a protocol implementation mergedThe "Open Base Station Architecture Initiative" is a consortium of companies which are trying to create an open market for cellular base station hardware. One of the things this initiative has defined is the UDPCP protocol - a UDP-based protocol used for communications between base stations. UDPCP offers reliable transfer, multicast, and more. The Linux kernel does not currently support UDPCP, but Stefani Seibold has posted a patch which would add that support to the kernel's network stack.There have been a number of comments about this code, but one observation by Eric Dumazet is noteworthy: the posted implementation only works with IPv4. The networking developers have made it clear that they are uninterested in accepting an IPv4-only implementation in 2011; IPv6 support is required for any new code. Stefani responded that no base stations currently provided IPv6 functionality and no customers were interested, so there was no point in adding that support at this time. The answer didn't change, though; the networking developers have no interest in merging code which is guaranteed to need fixing in the near future. Stefani has described this requirement as "dogmatic," but she also seems to have realized that it's not going to go away. So UDPCP stays out of the mainline for now, but we will, hopefully, eventually see a reworked version with support for IPv6.
Kernel development news 2.6.38 merge window part 1As of this writing, almost 5400 non-merge changesets have been pulled into the mainline for the 2.6.38 development cycle. This cycle looks to be another busy one, with a fair emphasis on the reworking of low-level infrastructure. User-visible changes merged so far include:
Changes visible to kernel developers include:
The merge window can be expected to remain open until roughly January 19. That leaves plenty of time for other interesting features to find their way into the mainline; next week we'll summarize changes for the second half of the 2.6.38 merge window.
The CHOKe packet schedulerA packet on the network typically passes through several machines on the way from its source to its destination. One of those machines (or, more correctly, one of the outbound links from one of those machines) will be the limiting factor on how many packets can traverse that path in a given period of time. If a system tries to send too many packets through the limiting link, the packet queue on the router attached to that link will grow. A growing queue affects other users of that router and will eventually hit its limits, causing packet loss.The TCP protocol has, for many years, included congestion control algorithms which attempt to determine the carrying capacity of a path and to avoid exceeding that capacity. These algorithms have successfully prevented a repeat of the meltdowns which plagued the early Internet. But congestion control isn't working as well as it should, for a few reasons. Some TCP implementations are more dutiful than others when it comes to congestion control. An increasing amount of traffic on the net uses other protocols (UDP in particular) which do not have congestion control built into them. Excessive queue sizes in routers ("bufferbloat") can also disguise congestion problems until it is too late. All of these problems are motivating a search for better ways of controlling congestion. The key signal for congestion control on the net is dropped packets; TCP will continue to ramp up its transmit rate until the occasional lost packet makes it clear that the limit has been hit. So the way for a router in the middle of the network to tell a specific sender that it's transmitting too much data is to drop some of that data on the floor. The idea is simple in concept, but it can be harder in practice for a simple reason: network routers can deal with many thousands of packets every second; they cannot afford to spend significant amounts of time on any one of those packets. An obvious way for a router to schedule packets would be to maintain a queue for every flow (source/destination pair with port numbers) through the system. Packets could then be dequeued and transmitted with absolute fairness, and, any time the queue for a flow gets too long, packets could be dropped from that queue. Implementing this algorithm would require some complex data structures and a fair amount of processor time, though, so it is not an option for a router which handles a significant amount of traffic. An alternative is the CHOKe algorithm [PS]; CHOKe stands either for "CHOose and Kill" or "CHOose and Keep," depending on one's attitude toward the problem. Stephen Hemminger has recently posted a CHOKe implementation for Linux, so this seems like a good time to look at how this algorithm works. CHOKe is intended for points where multiple flows come together - routers and bridges, primarily. The idea behind CHOKe is to keep the length of transmit queues under control and to penalize flows with excessive traffic while avoiding the need to maintain any sort of per-flow state. To that end, the packet queuing algorithm works essentially like the following. When a packet arrives for a given outbound link, the CHOKe code will:
The key feature of CHOKe - the one which distinguishes it from RED (from which it is derived) - is the check against a random packet in the queue. That is a heuristic mechanism for identifying problematic flows without actually having to track what each flow is doing. Experience, as reported in the CHOKe paper, suggest that it works pretty well. An important factor in successful use of CHOKe in the real world will be careful selection of the controlling parameters: the minimum and maximum queue lengths, average period, and drop probability. In particular, there is mounting evidence (thanks to the efforts by Jim Gettys) that overly long queues lead to all kinds of pathological network behavior, and could even threaten a net collapse at some point. Use of algorithms like CHOKe, combined with reasonably-sized queues, could help keep the Internet working well into the future.
Extending the use of RO and NXPages of memory that are managed by the kernel are governed by access control flags that are somewhat analogous to the permissions which are applied to files. Those flags govern whether the page can be written to and whether its contents can be executed. Both attributes are useful to restrict what can happen to those pages in the presence of programming errors or security attacks. A pair of patches that were merged in the current merge window will further extend the usage of these flags for the x86 architecture. The page access flags, unlike file permissions, are enforced by the memory management hardware. The flags of interest for these patches are "write" and "execute", both of which imply "read" access, so they are often specified as follows: RO+X (read-only and execute) or RW+NX (read-write and no-execute). By restricting the usage of these pages, the scope of security flaws can be reduced because, for example, a buffer overflow in an NX page will not be directly useful for code execution. The memory that is used by the kernel to hold its read-only data (i.e. the .rodata segment) has been able to be marked read-only since 2.6.16 in early 2006, depending on the setting of CONFIG_DEBUG_RODATA. In 2.6.25, the kernel .rodata segment was additionally marked NX (i.e. no-execute), but only for the x86_64 architecture. A patch that was originally created for 2.6.30 (for both the 32 and 64-bit x86 architectures) expanded the use of NX for all kernel data pages, including read-write sections for initialized data and BSS. That patch was created by Siarhei Liakh and Xuxian Jiang but had fallen by the wayside after causing some boot crashes on one of Ingo Molnar's test systems. When Kees Cook brought up the idea of doing better page access protection of the kernel's memory, Molnar remembered that Matthieu Castet had "dusted off those patches and submitted two of them", back in August. After a few iterations, Molnar pulled them into the -tip tree, and Linus Torvalds pulled that for the mainline in the current 2.6.38 merge window. The revised patch itself is fairly straightforward. If CONFIG_DEBUG_RODATA is set, various sections of the kernel (.text and .rodata) are page aligned for both their start and end addresses. The NX bit is set for all pages from the end of the .text (i.e. code) section to the _end address that marks the end of the kernel's data section. There were two other pieces of the puzzle addressed in the patch, the first of which was presumably the cause of the boot crashes that Molnar had with the earlier patch. Some older systems that use PCI BIOS require that some pages in the 640K-1M region be executable. There are also some ISA mappings that require read-write access to that region. Rather than try to work all of that out, and potentially run afoul of buggy hardware, the patch just sets pages in that region to be RW+X on systems where PCI BIOS is used. The second change simply modifies free_init_pages() to turn on NX for any pages that are freed that way, so that those pages have to be explicitly allowed to store executable code when they are reused. A related patch adds read-only and no-execute flags to the pages used by kernel modules. It came from the same developers, and seems to have been dropped from -tip along with the NX patch. And, like the other patch, Castet pushed it the last bit to finally get it included in the mainline. The patch splits the module_core and module_init regions into three parts: code, read-only data, and read-write data. Each of those parts is page aligned and the page access permissions are set just before load_module() returns. For the code pieces, RO+X are set, while the data parts get NX and either RO or RW depending on the type of data. These changes are all governed by the setting of CONFIG_DEBUG_SET_MODULE_RONX. Beyond setting the page access control flags at module load time, the kernel must also reset those flags to RW+NX when the module is unloaded. In addition, the module_init region is freed after initialization is completed and its pages need to be put back to RW+NX. There is one further wrinkle: Ftrace needs to be able to modify the code in modules to enable tracepoints, so the patch provides a means for all module text pages to be set RW while Ftrace is making those changes, and then to set them back to RO afterward. Marking the kernel module pages as RO and/or NX is important not only because it is consistent with how the rest of the kernel pages are handled, but also because it makes other kernel protection efforts actually work for modules. For example, there has been an effort to declare structures of function pointers as const, so that exploits cannot change the pointers for their own nefarious purposes, but that only works if the .rodata pages are actually marked RO. The main cost of these patches is some bits of wasted memory from page aligning the various sections. Since that cost is probably not significant for any but the most resource-constrained embedded systems, it would make sense for CONFIG_DEBUG_RODATA and CONFIG_DEBUG_SET_MODULE_RONX to be turned on for most distributions—or to default to "on", though that is generally frowned upon by Torvalds and others. The fact that these patches have been around for a while, but never quite made the jump into the mainline is unfortunate. There is no real person or group that is currently shepherding core kernel security patches along, though Cook and Dan Rosenberg have recently been making an effort to push these kinds of changes. Cook's query helped resurrect both of these patches; they might have languished far longer without that interest. It is also worth noting that much or all of the protections embodied in these patches have long been available in the grsecurity/PaX kernels. While no wholesale import of the features from those kernels is ever going to happen, piecemeal patches that implement "sane" (at least in Torvalds's eyes) features can be adopted. That should lead to better kernel security, which is something that is certainly worth shooting for.
Patches and updates Kernel trees
Core kernel code
Development tools
Device drivers
Filesystems and block I/O
Memory management
Networking
Security-related
Virtualization and containers
Miscellaneous
Page editor: Jonathan Corbet Distributions Fast distributions and slow serversIt's unsurprising - and commendable - that community members want to eat their own dog food when promoting their favorite Linux distribution — but sometimes the dog food expires far too quickly. This was brought to the fore, again, by a question posed to the Fedora Board about Fedora-it.org, which is running on a hosted server running Ubuntu. On January 9, Gianluca Sforna queried the Fedora Board about the Italian community site for Fedora, which is hosted by Italian Linux Distro Network (ILDN). Sforna wanted to know whether the project has, or wants to have, a position on the topic of hosting a Fedora site on a non-Fedora server — not an idle question, since the site is in a development stage and will soon be seeking approval from the Fedora Board to use the Fedora trademark. Former Fedora Board member Matt Domsch quickly, and many would say reasonably, replied that "there is no requirement that a Fedora-trademark-approved web site be run on Fedora - merely that the content be related to Fedora." The issue might have been considered closed there, but Bill Nottingham pointed out that "large chunks" of the Fedora infrastructure run on Red Hat Enterprise Linux (RHEL) as well — not Fedora. That inspired Jóhann B. Guðmundsson to ask why Fedora isn't eating its own dog food. It certainly seems a reasonable question on the surface; why wouldn't a Linux distribution project wish to showcase the distribution by hosting its infrastructure using its own system? Guðmundsson goes a bit farther and asks if it "discredits Fedora as a viable server platform" if the infrastructure runs on RHEL. But is Fedora really a viable server platform to begin with? The consensus, unsurprisingly, seems to be "no." Fedora's lifecycle is far too short. Having to upgrade a server, even if a distribution upgrade works flawlessly, every 13 months is simply more work and disruption than most organizations care to face. A 13-month-old desktop may seem ancient to most in the Linux community, but a once a server is configured and doing its job there is often little reason to perform a significant update after only 13 months. And the reality, as Mike McGrath illustrates is that it's impossible to even get the 13 months and not really worth the effort: So sure, we could run Fedora for everything, especially if we slimmed our offering considerably. But what do we gain? Many of the systems above hardly change as far as their primary purpose goes. Look at our dns servers. They run bind. But they also have several underlying systems that make them part of our infrastructure. Monitoring, configuration management, account systems, etc. So by upgrading dns every 6 or 12 months, literally gain NOTHING. But the time lost in creating the staging tests, upgrading them, running the tests, then scheduling the downtime in production and doing the actual upgrades is actually quite large. Then there's the matter of Fedora's actual focus as a distribution. Several Fedora contributors have taken the position that it's too focused on desktop usage, and not enough on servers. Adam Williamson says that they're missing the point of Fedora: To expand on this: remember, a lot of the 'point' of Fedora is to offer a space for experimentation and development. Mike and I are suggesting Fedora is not a good distribution to run boring, stable, important server tasks which just don't change a lot over time on - like DNS. However, if you were prototyping the next generation of DNS server, would Fedora be a great place to do it? Why yes, it would. Would that be partly thanks to the efforts of the server SIG? Definitely. Ditto if you're developing a web server or a web app or a new cloud infrastructure. Maybe Fedora isn't the distro you'll choose to deploy it to paying customers on, two years down the road, but it's certainly a good choice of distro to do your development work on. To put it another way, one size does not fit all. Some of the qualities that make Fedora interesting for developers and some users make it unsuitable for those seeking a distribution that's usable on "boring, stable" servers. Sometimes boring is a feature. Fedora does have a Server Special Interest Group (SIG), but it has few active participants and seems to be moving a bit slowly. There's no spin from the SIG, though you can find a recently generated Kickstart file. Can't we have an LTS?Fedora isn't the only distribution that has this conversation on a regular basis, of course. It has come up repeatedly in the openSUSE community, particularly since openSUSE reduced its support period to 18 months from 24. At the time this decision was made, I was working with Novell as the openSUSE community manager and agreed with the decision to cut support — despite knowing that it would be unpopular. While not a popular decision, it makes little sense for Red Hat or Novell to fund the support of their respective community releases as long as some community members would like. A few extra months of support are not likely to make a distribution like openSUSE or Fedora competitive with RHEL or SUSE Linux Enterprise Server (SLES) — but they will cost the company a pretty penny over time. One thing that volunteer contributors have not typically been eager or effective at is backporting packages to older releases. The Fedora Legacy project tried, and failed, when it came to supporting Fedora releases past their lifecycle. In the openSUSE community, discussions of an "openSUSE LTS" or openSLES have surfaced frequently, but often to little effect. Many users are supportive of the idea, but finding the number of hands skilled enough and devoted enough to make it happen is not easy. Sending an email or opening a request is easy. Actually making it happen is difficult — but not impossible. Wolfgang Rosenauer has been pushing this idea forward with the Evergreen project, an effort to provide long term support for openSUSE releases. There does seem to be some momentum behind the effort and an actual repository for 11.1 updates in the openSUSE Build Service (OBS). openSUSE 11.1 technically went end of life December 31st, 2010 but Rosenauer noted that the updates hadn't closed yet as of January 7, 2011. It's unclear where the final repositories will land and when Evergreen will be able to offer updates by default. Unfortunately, the archives for the evergreen mailing list are open to subscribers only — but subscription is open and apparently unmoderated. At the moment it looks to be a handful of participants with Rosenauer doing much of the work. He has called for assistance, and noted: "I've seen basically people offering to test stuff... While that's important it's not enough to get this project flying. If it would be that easy the openSUSE Community (or even Novell) would do it already." While one wishes success to Rosenauer and the Evergreen contributors, and to those trying to run the Fedora Server SIG, at best they will create something that's largely redundant. Organizations that truly need long term server-suitable distributions can turn to RHEL, SLES, Ubuntu LTS, Debian, and CentOS, to name a few. There's little real practical need for repurposing Fedora or openSUSE as infrastructure distributions.
Brief items Distribution quotes of the week
Fedora, you know I love you, but I've been waiting for years for the
All-Star game to come to Raleigh. It'll be the first FUDCon on this
continent I will have missed, which feels pretty weird, I must admit - but
I'm sure you'll have a lovely time without me. And when you speak of me
over your beverages, please speak kindly. :)
-- Greg
DeKoenigsberg prioritizes.
Have you seen what I've seen lately? Wow! Pure confusion (and near hatred
on Unity), the "Ubuntu is a kernel" crowd not liking the "new direction",
the regulars who open with "I use Ubuntu" and then say "don't get me
wrong", and then spew forth about a dozen incorrect statements. And, the
guy who refuses to write about the session switcher. There's even one guy
that launches into how interfaces are controversial (referring to Unity),
then does the old "sleight of hand" trick substituting a quote from Linus
about kernel interfaces being tricky. Some malnews is nearly magic.
-- Randall Ross
Preferably by glaring at whoever created a source file with spaces in
the name until they fix it. Meanwhile, by using ? or *. I doubt this
will be a serious problem.
-- Lars Wirzenius
DEFT Linux 6 releasedDEFT Linux 6 is available. DEFT is "a very easy to use system that includes an excellent hardware detection and the best free and open source applications dedicated to incident response and computer forensics." It includes a long list of tools aimed at tracking down problems on Linux and Windows systems.
MeeGo 1.1 update 2 and MeeGo 1.0 update 6The MeeGo project has released updates for MeeGo v1.1 Core, Netbook and In-Vehicle, and for MeeGo v1.0 Core and Netbook. These updates fix security issues and other bugs.
Sci-ZyX-v0.6.0.3 and viros-0.7.2k110111The first beta release of Sci-ZyX is available. "Sci-ZyX is a VirOS produced, rebootlessly installable, descendent of Scientific Linux's 6rolling alpha(4)."
Distribution News Fedora Fedora board Recap 2011-01-10Click below for the minutes of the January 10 meeting of the Fedora board. Topics include board goals as well as FESCo and FAmSCo goals, status on CWG, and other board business.
SUSE Linux and openSUSE Reviewing the openSUSE Trademark GuidelinesThe openSUSE board has invited the community to review and comment on the openSUSE trademark guidelines. "As with anything in life, time gives perspective. There has been sufficient time since the implementation of the first guidelines to observe real use cases where the guidelines were either effective or ineffective. And for the Board, this includes identifying a more responsive workflow to addressing requests for authorization of usage, as we, and others, recognize the current process as being perfectible."
The openSUSE Board election 2010The openSUSE Board Election process started in December 2010, and voting is now open. There are seven candidates for two open seats. All openSUSE members whose membership is in good standing are eligible and encouraged to vote.
Newsletters and articles of interest Distribution newsletters
Oracle Q&A: A Refresher on Unbreakable Linux Kernel (Linux.com)Over at Linux.com, Jennifer Cloer talks with Oracle's Monica Kumar about its "Unbreakable Linux Kernel". Oracle provides the 2.6.32-based kernel as an alternative to run atop its RHEL 5 clone. "Kumar: Over the years, a number of Oracle developers have made significant contributions to Linux in the areas of clustering, data integrity, file systems, virtualization, asynchronous I/O, testing and more. Oracle's Linux development team is an integral part of the Linux community. Our team, working with the Linux community, understands how to make Linux even better in performance, scalability and reliability. Even the "optimized for Oracle" contributions can benefit all Linux distributions and any application that wants to take advantage of them."
Remnant: Leaving CanonicalWorth a read: Scott James Remnant's goodbye note to Canonical. "Ok, Mark wasn't really a Nigerian 419 scammer, but some people did discard his e-mail as spam! The job sounded interesting, and I was largely waiting for him to stop talking on the phone so I could say yes. Even better, he was going to pay me up front for the first couple of months because the company hadn't been formed yet let alone contracts signed and such. No, I didn't have to send him any money first to make the transaction happen."
Page editor: Rebecca Sobol Development Bombono DVD authoring tool turns 1.0Pundits may tell you that physical media will soon be history when it comes to video distribution. Maybe — but for the foreseeable future, burning video onto an optical disc is an important part of the process, particularly when you're sending content to the 90% of the public that doesn't know what a "codec" is. For that task, dropping a .MKV file onto a blank disc won't do; you need a real, honest-to-goodness DVD. Bombono is a GTK+-based DVD authoring tool that we first examined in May of 2010. Back then, Bombono had some format and authoring limitations that made it not-quite-ready for regular usage. When the author alerted us that the application had recently made its 1.0 release, I decided to take another look. Bombono is not a video editor — rather, it is a utility for creating the linked menu structure and supporting features of the disc format. The 0.6 release reviewed in May offered a functional but no-frills subset of DVD functionality, primarily centered on building nested menus and basic navigation. But it left out several other features, and more importantly, it required that all of your disc's video content already be in DVD-compliant MPEG-2 format. The 1.0 release corrects this format support weakness, and it does add several DVD menu features — although it is still a far cry from full-featured support. Action!The project provides source code bundles of the new release as well as packages for Ubuntu and Fedora. In addition, openSUSE, Debian, Mandriva, Gentoo, Slackware, Arch Linux, Alt Linux, Zenwalk, and FreeBSD all have builds available, the progress of which are tracked on the site's Download page. The Ubuntu build is provided through a personal package archive (PPA), but if you already have 0.6 installed, the new release can be installed alongside it as the bombono-dvd-testing package, which installs itself in /opt/bombono-dvd-testing/ rather than in /usr/. The 0.6 release was lightweight in terms of dependencies, requiring only mjpegtools, TwoLAME, and the dvdauthor command-line tool. 1.0 adds two new package dependencies: FFmpeg (from which Bombono inherits its new video transcoding feature) and ENCA, a text analyzer that is used for converting between video subtitle formats. ![[Bitrate calculator]](/images/2011/bombono-bitrate-sm.png)
Bombono's DVD authoring workflow has not changed. You start your project in the Source tab, in which you add video, audio, and still image files to the project's Media List. In addition to adding files through the built-in file browser or system drag-and-drop, Bombono can extract video from DVD discs, which is accessible through the Project menu. As mentioned above, the FFmpeg support means that you can add almost any video or audio file to the Media List; if it is not in DVD-compatible MPEG-2 (including MPEGs without the proper resolution and frame rate), a "T" icon will be superimposed on the file's thumbnail. The FFmpeg support also allows you to "mux" (i.e. multiplex) an audio and a video file together for use in the Media List; like DVD extraction this option is available in the Project menu. The Source tab also allows you to mark chapter points in any video on the Media List. To do so, you must click on the "check" button in the list, then right-click in the video timeline at the time code you desire. Last but not least, you can use the timeline to save individual video frames as still images. This is important because Bombono does not let you directly choose a frame to use as each video's thumbnail in the menus. Saving the frame and then adding the still image to the Media List is the only alternative. Designing a project's menus is done in the Menu tab. As in 0.6, you must create your menus in the Menu List, then edit them one at a time. You can add "frame" buttons and basic text labels in the canvas area, rearranging them as desired. The all-important linking of buttons to actions and videos is performed by right-clicking on the button and choosing the action desired — jumping to a new menu, playing a video title, sending the "play all" command, etc. ![[Output tab]](/images/2011/bombono-output-sm.png)
The Output tab allows you to build the DVD contents (converting formats where necessary) and author the DVD image. It uses the external dvdauthor tool for this step, the progress of which can be monitored in an output panel. You have the choice of creating an ISO image, burning the image directly to an optical disc, just creating the properly-formatted DVD content folder, or running the rendering step only. This last option converts the video and audio files and creates the dvdauthor XML command file in your output folder; if you have complex changes to make beyond Bombono's feature set, you can then edit the XML file separately. The goodApart from the ability to painlessly convert existing video content to DVD-compatible format (which is a killer feature), the 1.0 release of Bombono does add some needed functionality that was missing in 0.6. ![[Subtitle menu]](/images/2011/bombono-subtitlemenu-sm.png)
The first is subtitle support. Currently Bombono can import any subtitle file supported by FFmpeg, which includes SubRip/SRT, SSA/ASS, DVB, PGS, and XSUB. I tested Bombono with some subtitled sample files hosted by Multimedia.cx, and it does not appear that Bombono can extract subtitles from existing video files, but there are utilities (such as Gnome Subtitles) than can assist with preparing the subtitle files. Bombono 1.0 is also limited to one subtitle file per video file. There are three new menu-editing features: motion menus, "play all" links, and customizable selection and highlight colors. Motion menus are animated menu screens. To enable animation on a particular menu, you right-click on it in the Menu tab's Menu List and open "Menu Settings." Marking a menu as animated animates all of the video elements on the menu screen; the easiest application is to generate moving thumbnails of the video links on a menu, but it could also be used to animate the background image. You can control the animation duration and looping behavior, use an external audio file, and trigger an "end action" to be executed at the end of the animation. The customizable selection and highlight colors close a major gap in earlier versions of Bombono. For every menu, you can select an alpha-transparent color that will be overlaid on top of the selected menu item when the remote control cursor selects the item. Without it, you ran the risk of the default highlighting color being invisible against your background. "Play all" links are exactly what they sound like: you can trigger the playback of the entire menu's contents with a single button press. A nice technical addition in 1.0 are the bitrate control features, also from FFmpeg. If you right-click each video in the Media List, you can open up a "bitrate calculator" dialog box, which allows you to manually set the video bitrate, scale the entire video up or down, or restore any changes to the file's original settings. If you come close to filling up a disc, this is a valuable feature. The menu bar at the top of the main window provides a running tab of the space used by the disc contents, but in previous releases you had no way to adjust the disc space usage. Another option in the right-click menu allows you to max-out the disc entirely, providing maximum video quality with one click. The bad & the uglyEven considering the functional improvements over the initial Bombono release, there are still some noticeable gaps in the application's feature set. Minor changes were made to the menu-editing canvas, such as the addition of horizontal and vertical alignment tools, but it still lacks support for basic tasks like re-arranging the z-order of onscreen elements, cropping images, aspect-ratio preservation when scaling, and many basic drawing tools, like lines and gradients. I understand that one can create more complex images in other tools, which might excuse the missing line or gradient tools, but the missing z-ordering genuinely impairs one's ability to create a menu. The newest-created item is always on top. That means that you have to create every object to be used in the menu in the order it will be visible on-screen. Even if that were possible to do without making mistakes, it means the designer has no freedom to change his or her mind without starting over. Similarly, although you can scale images on canvas, it is impossible to do so while preserving their shape, so users will just get frustrated and quit. Last but not least, there is no on-screen ruler to precisely lay out items on the canvas, and there is no zoom function — the canvas is always scaled to fit the window, and not even the current zoom factor is displayed. More serious, however, is that Bombono still breaks GNOME's human interface guidelines (HIG) in rather serious ways. I gave the application a pass on this point for 0.6, chalking it up to early-in-development quirks, but some of the problems are inexcusable in a stable, 1.0 release. For starters, the menu bar mixes tabs, a text label, and a drop-down selection widget in with the actual menus (one of which, "Go," happens to be redundant because it only offers access to the always-visible tabs). The two most-used content lists (the Media List and Menu List) both use a "check" icon to represent the "edit" action, which is non-standard. The text labels used in the tabs, window panes, and content lists are inconsistent in their font style, font size, and alignment. Button and selection widgets vary considerably in size, spacing, and background color. In addition to the obvious UI issues, there is too much reliance on right-click context menus to bring up critical functionality. Menu settings, bitrate calculations, subtitle support, button linking and alignment, inserting and deleting chapter markers, and saving still frames are all accessible only through right-clicks. That makes them difficult to discover and not keyboard-accessible. Finally, although I applaud the addition of subtitle support in this release, the feature set still leaves off several other important DVD mastering functions, including multiple audio tracks, multiple subtitle tracks, and extra camera angles. I am sure there are video wizards who would bemoan the lack of advanced scripting and interactive features, or THX sound options, but to me those are of limited appeal to the home video author. Ultimately, Bombono markets itself as simple DVD authoring, which puts some of those features out-of-scope. On the other hand, these issues do not prevent Bombono from writing good discs. With 0.6, I experienced corrupted dvdauthor XML files and some other problems that prevented me from actually building valid DVD ISOs. That was not the case in 1.0; I found no show-stoppers or crashes in the DVD mastering process. I was alarmed when selected an existing folder as my ISO output location and an error box told me "Folder /home/nate/bombono is not empty. We need to remove all files in it before authoring. Continue?" — I would have expected dvdauthor to use a temporary directory when building the disc image. In the final tally, though, although Bombono 1.0 is definitely a marked improvement over 0.6 (particularly with the addition of automatic media transcoding), there are enough holes that it just doesn't feel like a 1.0 release to me. I expect 1.0 software to meet HIG guidelines, to have well-designed menus, to just not "get in my way" when doing major tasks like laying out elements on a canvas. Bombono has technical chops — I just hope its developers will try to bring the front end up to the same level.
Brief items Quote of the week
Adding to C++ is difficult and the process to get a new feature
accepted is typically most painful for its proposer. However, once
accepted, the new feature can have major impact on a large
community. If I didn't want to have an impact on the world, I could
try to get my intellectual stimulation through crossword puzzles,
writing fiction, or designing a toy programming language.
-- Bjarne
Stroustrup
Cassandra 0.7 releasedThe Apache Software Foundation has announced the release of version 0.7 of the Cassandra distributed database. New features include secondary indexes, large row support ("up to two billion columns per row"), and support for online schema changes.
Chrome losing H.264 supportGoogle's Chromium Blog describes some video codec changes in the Chrome browser. "To that end, we are changing Chrome's HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies."
GTK+ 2.99.0The beta GTK+ 2.99.0 release is out, indicating that the big 3.0 release is coming soon. At this point, the removal of deprecated API features is nearly complete; now would be a good time for any application developers who have not already done so to think seriously about portability to 3.0.
Bayer: Hudson's futureAndrew Bayer has an update on the future of the Hudson project. "Oracle has told us that they have trademark applications filed in both the EU and US for Hudson, based on Hudson's creation by Kohsuke while working at Sun. The problem is that this trademark ownership gives Oracle the ability to revoke the Hudson project's right to call itself Hudson at any time, and while Oracle has made an attempt to offer some guarantees (most notably, that binary releases of Hudson, once they've been released with the name Hudson attached, will always retain the right to the name), they are not offering any binding guarantee that the Hudson project will be able to retain its use of the name in perpetuity." The project will be renamed Jenkins. (Thanks to Scott Bronson)
Trojitá 0.2.9 releasedTrojitá is a Qt-based email client with an emphasis on a small footprint and speed. The recently-announced 0.2.9 release includes a number of improvements and enhancements, with support for threaded message display being at the top of the list.
Newsletters and articles Development newsletters from the last week
Neary: Open Source community building: a guide to getting it rightDave Neary has put together a guide for companies wanting to build or join open-source communities. "Companies are used to controlling the products they work on. Attempting to transfer this control to a project when you want to grow a developer community will result in a lukewarm response from people who don't want to be second class citizens. Similarly, engaging with a community project where you will have no control over decisions is challenging. Exchange control for influence."
Sobotka: Why GIMP is inadequateTroy Sobotka looks at problems with the GIMP and its development state. "How is it that the flagship imaging application struggles along with only two principal developers working on it and an alternate project such as Blender is absolutely thriving in Libre software? To an outsider, this might be interpreted as a symptom of a lower level dysfunction."
Page editor: Jonathan Corbet Announcements Brief items Broadcom joins the Linux FoundationJust on the heels of its wireless driver being released in the staging tree of the 2.6.37 kernel, Broadcom has joined the Linux Foundation. "In September, Broadcom announced it had open sourced its drivers for selected Wi-Fi chipsets, a pivotal move that garnered applause throughout the Linux community. Since then, the driver has been integrated into the latest Linux kernel release 2.6.37 and, as a result, is actively being improved upon by the entire Linux community. Given its portfolio of semiconductors for wired and wireless communications, Broadcom is an important addition to The Linux Foundation."
A flood update from linux.conf.auThe linux.conf.au organizers have sent out an update on what effects, if any, the flooding in Brisbane will have on the conference. It's hard to say for sure, but it looks like LCA will happen as scheduled. "It would be a boost to morale and to our spirits, and a beginning to a return to normality if people who made plans to come to Brisbane stick to those plans, come to Brisbane, and enjoy what we hope will still be the best community-driven linux conf around."
Open Internet Apps ChallengeThe US Federal Communications Commission (FCC) is sponsoring a challenge for "researchers and software developers to engage in research and create apps that help consumers foster, measure, and protect Internet openness". Entries must consist of open source applications or research papers and will be judged on a variety of different criteria. Entries are due between February 1 and June 1 and winners will have their applications/research promoted by the FCC along with their expenses paid for a reception in Washington, DC. "The Open Internet Challenge seeks to encourage the development of new, more effective applications that provide users with information about the extent to which their fixed or mobile broadband Internet services are consistent with open Internet principles. These software tools could, for example, detect whether a broadband provider is interfering with DNS responses, application packet headers, or content." (Thanks to Charles E. Bermingham.)
UK review of the patent systemA review is underway in the UK to identify barriers to growth within the country's "intellectual property framework." The IP review team has issued a call for evidence seeking information on how well the current patent system is working (or not working). Evidence should be should be presented to the review team by March 1. (Thanks to Alan Cox)
Articles of interest Villa: Changing JobsLuis Villa has left the Mozilla Corporation to work at the law firm of Greenberg, Traurig. "Mozilla has been terrific for me. Working with happy, dedicated, passionate people is always a joy, and I've learned a ton from my teammates in legal and from Mitchell. I particularly can't say enough good things about my boss, Harvey- he's been a tremendous mentor to me. And of course Mozilla is exactly the kind of job I went to law school to get- directly helping hackers ship world-class software. Leaving today was hard- I'll miss my coworkers, and I realized over the past few days that some of them may even miss me ;)" He adds that he will continue to work on the new MPL, which should be released soon.
LPI Community Corner: To Russia With LoveThis edition of the community corner features Jon "maddog" Hall with some reflections on Linux in Russia, plus an LPIC-1 exam preparation screencast from PaulPaulito.com and a "Top Story" of 2010 poll.
Inside Track: Oracle has Kicked Lustre to the Curb (InsideHPC)InsideHPC has received an anonymous tip that Oracle has ceased development of Lustre. "We can look forward to more Limbo for a while, but what happens next with stewardship of Lustre? Will Oracle quietly kill it like they did with OpenSolaris? Will they set the legacy code base free like they did with Grid Engine? Or will they just cash in and sell it? Chances are that Lustre is being shopped around and we won't hear a peep from the Dark Tower until a sale is announced. That could be months, and that kind of prolonged uncertainty would not be good for the Lustre community." (Thanks to Chris Samuel)
PlayStation 3 hack - how it happened and what it means (The Guardian)The Guardian looks at the implications of the recent PS3 hack. "Like many members of the hacker community, Fail0verflow is resolutely anti-piracy — its members bypass console security systems merely as an intellectual challenge, or to run their own operating systems and applications. Consequently, the group didn't itself reveal the key. However, days later hacker, George Hotz (also known as Geohot), previously responsible for opening the iPhone system to so-called "jailbreak" hacks, did released the required firmware package decrypter on his website. Although the current hack requires users to modify their PS3 to run homebrew apps (or use a PS3 'Jailbreak' dongle, which bypasses the security system on machines with older versions of the firmware), further developments may ensure that anyone with the relevant software tools and technical knowledge could produce applications that will run on any PS3. It would then effectively be an open system. And naturally, the floodgates that have prevented widescale piracy on the console for the last few years could be smashed to pieces."
New Books Org Mode 7 manual - printed edition now available"The Org Mode 7 Reference Manual - Organize your life with GNU Emacs" by Carsten Dominik and others is available from Network Theory Ltd.
jQuery Pocket Reference--New from O'ReillyO'Reilly Media has released "jQuery Pocket Reference" by David Flanagan.
Building Wireless Sensor Networks--New from O'Reilly MediaO'Reilly Media has released "Building Wireless Sensor Networks" by Robert Faludi.
Calls for Presentations First KDE Conference in India - conf.kde.inKDE-India will be holding conf.kde.in March 9-11, 2011 in Bengaluru (Bangalore), India. The Call for Participation is open until January 15.
Linux Audio Conference 2011The Linux Audio Conference (LAC) takes place in Maynooth, Ireland, May 6-8, 2011. The deadline for the call for papers has been extended until February 20.
OpenStreetMap State of the Map 2011: call for papers (The H)The H covers the OpenStreetMap State of the Map conference, taking place September 9-11 in Denver, Colorado. Tne call for papers is open until March 15.
Upcoming Events The Linux Foundation's 2011 event scheduleThe Linux Foundation has announced its events schedule for the coming year. There will be LinuxCon events in Yokohama, Vancouver, Prague (co-located with the Kernel Summit), and Sao Paulo, with a number of other conferences scheduled as well.
Events: January 20, 2011 to March 21, 2011The following event listing is taken from the LWN.net Calendar.
If your event does not appear here, please tell us about it.
Page editor: Rebecca Sobol
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||