Sponsored link Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here. |
LWN.net Weekly Edition for May 1, 2008Large educational Linux deployment for Brazil Numbers like 52 million are attention grabbers, especially when they refer to students getting access to Linux. That's the number of Brazilian public school students who will have access to Linux-based educational computers in some 53,000 labs spread throughout the country. As reported on Mauricio Piacentini's weblog, the Brazilian government already has 17,000 of the labs up and running and plan to be fully rolled out by the end of 2009. The project, called ProInfo, is run by the Ministry of Education (MEC) for Brazil. Piacentini heard about it at the recent Fórum Internacional Software Livre (FISL) conference, which is held annually in Porto Alegre, Brazil. He noted that the project is not only providing computers and infrastructure, but also a "Linux Educacional" distribution with free educational and entertainment software along with other "open content".
The distribution is Debian-based using KDE 3.5 as its desktop. Packages from the KDE Education Project (KDE-Edu) and KDE Games Center (KDEGames) were included. The project customized the interface, adding a quick navigation bar at the top (seen at left). This is the second version of the distribution incorporating feedback from installations of the previous version. The distribution ISOs, open content, and some documentation (all in Portuguese) can be found at the MEC ProInfo website. There are various different lab configurations that ProInfo has devised that depend on the nature of the location of the school. Urban labs have equipment for up to fifteen students whereas rural installations have power-friendly hardware that can support up to five users. There is also a configuration targeted at schools for people with special needs that has a large display and accessibility tools added to the distribution. ProInfo also has a project that sounds much like OLPC, except in Portuguese: Um Computador por Aluno ("One computer per student") that plans to bring 150,000 laptops (possibly Intel Classmate PCs) to students over the next year or so. Some have quibbled about the number of students estimated, but even if it is overestimated by a factor of two or three—which seems unlikely—it is still an enormous project that will impact a huge number of students. Free software is perfect for these kinds of projects, because it can reduce the hardware requirements significantly, eliminate licensing nightmares, and provide a look "under the hood" for students who are interested. Computer skills are largely portable if some of those students end up using other operating systems in the future, but because they are using free software now, any documents, pictures, music, and other data files will be able to move with them. Folks from the KDE project are justifiably proud of this deployment. It uses KDE 3.5, but plans are afoot to work with MEC to explore using KDE4 down the road according to KDE hackers Piacentini and Aaron Seigo. Many have been concerned about the future of KDE 3.5, but the project has always maintained that it will be around for a long time. As Seigo says:
KDE 3.5 will be supported in the market for many years to come due to
deployments such as this one. Looking towards the future, KDE4 will likely
make some things even easier for them in the future, such as how to
implement the navigation bar they added to the top of desktop as a result
of usability research done involving this specific audience. With Plasma, a
few lines of JavaScript is all that would be needed.
Proponents of the other desktops or distributions should be cheering this deployment as well. There will probably be lots of lessons learned that can apply to other projects in Brazil or elsewhere that standardize on a different set of software components. This is an exciting project for the free software community. But even more importantly, it is great to see so many of these tools become available to those who have not yet been exposed to them.
Sun and corporate open source Over the last couple of weeks there has been an interesting set of articles posted on various weblogs on how Sun is managing its open source projects. As more companies try to get involved with free software, they may find things to learn from this discussion. So here are a few thoughts on corporate open source.It all started with a posting by Ted Ts'o which stated:
So if you run into a Sun salescritter or a Sun CEO claiming that
OpenSolaris is just like Linux, it's not. Fundamentally, Open
Solaris has been released under a Open Source license, but it is
not an Open Source development community. Maybe it will be someday,
as some Sun executives have claimed, but it's definitely not a
priority by Sun; if it was, it would have been done before now.
The posting drew responses from Dave Neary and Alvaro Lopez Ortega, among others; both the original messages and the responses to it are worth reading in their entirety. In summary, the responses say that (1) Sun really is trying to be a good open source player, and (2) Sun has done as well as could be expected, that the creation of true open source communities is hard. The first part can only be true. Sun has been the source of a great deal of free software, including packages like OpenOffice.org which are found in almost every Linux distribution. This company has released its core operating system as open source, and it is making noises about, finally, making Java truly open at all levels. There are few companies which have contributed code at this level, and that should be recognized. Beyond any doubt, Sun is contributing to this community. What people question, though, is Sun's interest in creating real communities around its open source projects. These projects are notoriously hard to participate in and contribute to. As Ted points out, OpenSolaris currently gets less than one patch per day from outside the company, the project's governing board is made up entirely of Sun employees, and its (non-distributed) revision control system lives inside the Sun firewall. External OpenSolaris developers have known to quit with messages like:
Sun agreed that "OpenSolaris" would be governed by the community
and yet has refused, in every step along the way, to cede any real
control over the software produced or the way it is produced, and
continues to make private decisions every day that are later
promoted as decisions for this thing we call OpenSolaris. Rather
than be honest about it and restructure the community to correspond
to this MySolaris style of over-the-wall development, Sun prefers
to lie to the external community members while ignoring their
input.
OpenOffice.org, too, remains hard to work with; thus the many discouraged comments on the ooo-build wiki from developers who want to get things done:
Many ooo-build patches are ready for up-streaming but there is no /
little response from up-stream. Worse there is the perception that
taking leadership and actually doing something about merging fixes
would be firmly opposed. Finally - even when maintainers are
active, responsive & friendly - there is no agreed mechanism for
blanket approving fixes - or sub-types of trivial fixes, which thus
tend to fester in IssueZilla.
The key to what is going on here can be found in many places, including in Alvaro's posting:
Besides, the OpenSolaris development model is quite different
because of a number of technical reasons. IMO, the first one is
something as simple as that we want to ensure its quality by
following a number of processes. Another very important technical
point is that we want OpenSolaris to continue being binary
compatible (ABI) with the previous Solaris revisions, which is
something Linux could not even dream of.
The real issue is control; Sun does not want to relinquish control over how its projects evolve. This is not a particularly uncommon situation with corporate-controlled projects; these projects will always be subject to the controlling company's agenda. Thus, no developer is likely to be successful in projects like:
Companies which control open source projects in this way are generally acting within their rights; they may even be acting in their own best interests. The software is still open source. But the retention of this sort of control will have an effect on the community which builds around the software. In many cases, it can have the effect of preventing the creation of that community in the first place. And that, too, may be what the company had in mind. There are a number of company-controlled open source projects which, by all appearances, are mostly for show and bragging rights. The company does not really seem to have much interest in developing a significant external community. In cases like this, if the software on offer is valuable enough, the result will often be a more community-oriented fork. Projects like ADempiere, LedgerSMB, and Cinelerra CV result from this kind of frustration. Opinions clearly differ on whether Sun is truly uninterested in the creation of outside development communities for its projects, or whether it simply is having a hard time letting go. If the latter is the case, then Sun might be well advised to follow Dave Neary's suggestion and create a separate, non-profit foundation for the development of OpenOffice.org. Sun's apologists are right when they say that turning a large blob of proprietary code into free software is a hard thing to do. But it's harder if you don't give the community the power to help; in the case of OpenOffice.org, there would appear to be enough of an interested community to make a real go at it. This might be Sun's best chance to show that it can create real development communities around its software.
On the conviction of Hans Reiser On April 28, a California jury found Hans Reiser guilty of first-degree murder. There has been a lot of speculation in the press, both before and after the conviction, on what the loss of Mr. Reiser will mean for the Linux community. Much of that speculation, it seems, lacks an understanding of what Mr. Reiser's role in the community really was. Your editor will take no position on whether his conviction was correct or just. But there are things to be said about what this conviction will mean.Hans Reiser was, of course, the designer (and, to an extent, implementer) of the reiserfs filesystem. When it was merged, reiserfs had the distinction of being the first journaling filesystem for Linux which was intended for general use; it also offered good performance in some situations, especially those involving lots of small files. Reiserfs saw a significant amount of use and was adopted by a handful of distributors. There are, doubtless, quite a few reiserfs deployments still operating out there. Mr. Reiser's role in reiserfs development and maintenance ended some years ago, though. He stopped work on it when reiser4 development started, and even opposed the incorporation of improvements done by others. Reiserfs continues to be maintained independently of its creator, though there is not much interest in adding features to it at this point. Reiserfs is nearing the end of its run, and nothing which happened this week has changed that situation in any way. There is more concern about what will happen with Reiser4, Mr. Reiser's next generation filesystem. Many reports have suggested that current events spell the end for this project, but it is worth taking a look at the longer history. Reiser4 is not exactly new; it was first posted in 2002. Mr. Reiser made an unsuccessful effort to get it merged for the 2.6.0 kernel, and frequently thereafter. He blamed commercial interests and politics for his failure in this regard, but the real situation is more straightforward than that. Reiser4 tried to do a number of things very differently from other filesystems. It included some very non-POSIX semantics which raised red flags within the development community. There was a multipurpose reiser4() system call which implemented a wide range of features and included an in-kernel interpreter for a special language. There was a low-level plugin mechanism which raised concerns (not all justified) about varying on-disk formats and proprietary formats. Reiser4 did many things at the filesystem level that others thought should be done at the virtual filesystem level instead. The "files as directories" feature, beyond striking people as strange, opened up a wide range of trivial deadlock scenarios. In summary, this code was nowhere near ready for inclusion into the mainline kernel. Kernel development projects which are done in isolation often encounter this kind of surprise when they are finally posted to the development community. Over the next few years work on reiser4 continued. Many of the problems were solved by simply removing most of the features which made reiser4 unique, turning it into just another filesystem. Once you have just another filesystem, attention will turn to performance; in this case, many people found that they got benchmark results which differed from those posted by Mr. Reiser. Community interest in this filesystem fell over time, and the development rate fell as well. There was still work happening to prepare reiser4 for the mainline kernel when Mr. Reiser was arrested, but it was moving slowly. Perhaps the biggest obstacle to the inclusion of reiser4, though, was the confrontational approach taken toward the rest of the community. When developers pointed out problems with reiser4, Mr. Reiser had a tendency to question their motives rather than pay attention to what they were saying. His interactions with the community were characterized by statements like:
What makes you think kernel developers have a deep understanding of
the value of connectivity in the OS? They don't. The average kernel
developer is not particularly bright.
A number of developers reached a point where they simply chose not to engage with him any more. By rejecting the development community, Mr. Reiser remained forever an outsider to it. And that is why the practical effect of Mr. Reiser's conviction on the community will be relatively small, at least in the short term. As brilliant as he is, his effectiveness was limited by his disregard for the rest of the community and his certainty of always being right. He could have accomplished much more with a different approach. That said, his loss is unfortunate. He did prove able, over a number of years, to raise funds for Linux filesystem work, and the community benefited from that work. Some of the reiser4 developers are still interested in working on that code, and they still submit patches. But now nobody is paying them to do that work, which puts the whole enterprise in danger. There are limits to how long reiser4 development can be carried forward as a labor of love. The biggest loss, though, is elsewhere. More than anybody else, Mr. Reiser put a lot of thought into what our systems should look like in the future. He saw capable filesystems as the way to make our systems far more powerful than they are now. In a world where the filesystem was the only namespace of any significance on the system, all objects would be equal and the number of potential connections between them would explode. His long-term goal was not (just) better benchmarks; it was to create a filesystem which could serve as this all-encompassing namespace. It was a radical idea, and, perhaps, impractical. But our future comes from ideas like that. After a few relatively quiet years, there is now a flurry of activity around Linux filesystems. The challenges in this area are large, but we have many highly capable developers working on the problem and there can be no real doubt that Linux filesystems will continue to be among the best available anywhere. But that development community has lost a voice which, for all its faults, had some unique and innovative things to say, and we are all poorer for it.
Page editor: Jonathan Corbet Security The Tahoe secure filesystem The Tahoe filesystem is designed as a secure, distributed filesystem that is available as free software. Tahoe is also designed for fault tolerance so that data remains available even in the presence of missing or malicious peers. In March, the project released a 1.0 version which makes this a good time to take a peek. The basics of Tahoe are somewhat similar to GNUnet or Freenet in that the data is encrypted and spread around to multiple nodes in the network. Unlike those, though, Tahoe does not seek to provide anonymity. The nodes making up a Tahoe filesystem are called a "grid". Grids consist of some number of peers acting as storage server nodes along with an "introducer" that knows all of the other nodes and is the central point of contact for the grid. Files are stored in Tahoe by first being encrypted on the local machine using AES. They are then broken into "shares", ten by default, that are distributed to different servers in the grid. Before that happens, though, the encrypted file is encoded in such a way that the whole file can be recovered even if only a subset of the shares can be retrieved. This encoding, known as "erasure coding", is the key to the fault-tolerance of the Tahoe system. By default, Tahoe encodes the shares such that retrieving three of the ten is sufficient to recover the entire file. It also increases the size of the file by the expected 10/3 ratio. The suggested use case for Tahoe is a "friendnet" where some group of friends share their storage with each other in a way that reduces or eliminates the need for backups. Tahoe also has ways to share data in either read-only or read-write (immutable or mutable in Tahoe-speak) modes. Tahoe is used as a commercial backup system by Allmydata, sponsor of the Tahoe project. Tahoe is designed to be secure, which means that it protects the integrity and confidentiality of the data stored in it. SHA-256 is used extensively to ensure consistency of the plaintext, ciphertext, and shares. Files stored in the system are identified by long identifiers called capabilities, that look something like: URI:CHK:yeyur23dw7cg3mxmsl2kiqvtt4:sdtrgczwtntzyfg2uapbfytxvyqsn45j4jpgrhcey7ebzpaoznya:3:10:107833344For mutable files, there are two versions of the capability, one that allows only reading, while the other allows writing as well. Anyone who does not have a capability string for a particular file cannot access it at all. Multiple user interfaces are available for Tahoe, including a web interface, a command-line interface, a FUSE extension and a web API. Tahoe is written in Python, using some C extensions for efficiency. It uses the Twisted framework for event handling, pycryptopp (a Python interface to the Crypto++ library) for its encryption needs, and zfec for the erasure coding. All of the Tahoe code is available under the GPL. Installing Tahoe was fairly straightforward—there were a few hiccups which have since been resolved—using the installation guide. Joining the test grid was as easy as putting an introducer identifier into a file and starting Tahoe from the command line. In some basic testing, it seems to work quite well, overall, though it did not seem to use available bandwidth as efficiently as it might. This brief overview only scratches the surface of the information available about Tahoe; there is much more on the documentation page. For anyone interested in distributed, secure, and/or fault-tolerant filesystems, Tahoe is definitely worth a look.
New vulnerabilities asterisk: denial of service
blender: buffer overflows, temp file issues
comix: denial of service
IBM java: arbitrary file write
jrockit: multiple vulnerabilities
kdelibs: arbitrary code execution
kdelibs4: buffer overflow in KHTML's image loader
kronolith2: cross-site scripting
ldm: authentication bypass/information disclosure
perl: heap buffer overflow
perl-Imager: buffer overflow
phpgedview: cross-site scripting
phpmyadmin: arbitrary file read
python, idle: arbitrary code execution
util-linux-ng: argument injection vulnerability
wordpress: privilege escalation
xine-lib: buffer overflow
Page editor: Jake Edge
Kernel development Release status Kernel release status The 2.6.26 merge window remains open, so there is no released 2.6 development kernel. See the article below for a summary of patches merged over the last week.No stable kernel releases have been made over the last week. As of this writing, the 2.6.24.6 and 2.6.25.1 stable updates are in the review process; if all goes well, these updates should be released on May 1.
Kernel development news Quotes of the week Those who have been watching the linux-kernel list know that the 2.6.26 merge window has been a little rougher than some of those which came before. That has led to some fairly strong discussion over how changes find their way into the mainline. Here's a few selections.
I'm not saying the patch is wrong ... or that just because it broke
voyager it shouldn't be done. What I'm saying is that it shouldn't have
been put into the x86 tree without mailing list review.
-- James Bottomley
Running a git tree isn't a private fiefdom, it's a public trust; to keep the trust of other developers, you have to run the tree in a transparent fashion ... and making the mailing list the only input to it is one way of ensuring this. It also helps with review that we're all so worried about so little being done ...
But, we'd not mind at all posting 1000 x86.git patches to lkml (or
another list) every 3 months (or more frequently), if people request
that.
-- Ingo Molnar
You can post whatever patches you like a million times to lkml.
That's not the problem.
It's that the patches don't get reviewed, posting them more or to a
different place doesn't help that.
-- David Miller
Sorting x86 arch code is inevitably going to break a few eggs, but I
suspect the time cost has been more in Dave v Ingo (12 rounds, two falls,
two submissions or a knockout) than actually sorting out the fallout of a
couple of problem cases.
-- Alan Cox
So here's how we're going to fix David's problem:
-- Andrew Morton
- Everyone gets their stuff into linux-next. - Lots of people _test_ linux-next. Just once a week. Those two steps will improve the merge-window chaos a lot. Things will get better.
IMO, the merge window is way too short for actually testing anything. I rebuild
the kernel once or even twice a day and there's no way I can really test it.
I can only check if it breaks right away. And if it does, there's no time to
find out what broke it before the next few hundreds of commits land on top of
that.
-- Rafael Wysocki
And yes, there is a solution: don't develop so much. Don't allow thousands
of developers to be involved. Do a small core group, and make development
so hard or inconvenient that you only have a few tens of people who write
code, and vet them and force them to jump through hoops when adding new
features (or fixing old ones, for that matter).
-- Linus Torvalds
The 2.6.26 merge window, part 2 Since last week's summary was written, another 3700 changesets have found their way into the mainline git repository. The most significant user-visible changes include:
Changes visible to kernel developers include:
The merge window remains open; tune in next week for (what should be) the final set of changes merged for 2.6.26.
Restricting root with per-process securebits Linux capabilities have had a long and somewhat tortuous journey as part of the Linux kernel. Slowly—and very carefully—functionality is being added to this security feature to get it to a point where it is a viable alternative to the all-or-nothing setuid(0) model. A recently merged patch adds a per-process securebits feature that will allow capabilities-based daemons or subsystems to coexist with existing setuid utilities. Linux capabilities break up the privileged tasks normally associated with root (i.e. uid 0) into finer-grained abilities which can be individually granted or revoked for specific processes. The idea is to change the standard Unix model that root has all special privileges while all other users have none. The terminology is always a bit contentious, though, as Linux capabilities are derived from a POSIX proposal that was never adopted, but shares the name "capabilities" with an entirely different approach; this article is only concerned with capabilities of the Linux variety. There has long been interest in creating a Linux system that did not rely upon a single root account. Capabilities are seen as the way to get there, but they have suffered from a bit of a chicken-and-egg problem. With the recent work to add file-based capabilities and restore CAP_SETPCAP to its original meaning, a true capabilities-based system is becoming possible. In the patch, which has been merged for 2.6.26, Andrew Morgan describes the new functionality:
The feature added by this patch can be leveraged to suppress the privilege
associated with (set)uid-0. This suppression requires CAP_SETPCAP to
initiate, and only immediately affects the 'current' process (it is inherited
through fork()/exec()). This reimplementation differs significantly from the
historical support for securebits which was system-wide, unwieldy and which
has ultimately withered to a dead relic in the source of the modern kernel.
The patch removes the global securebits variable, replacing it with an entry in struct task_struct, that can be manipulated by a process, but only for itself—and any children. Morgan envisions hybrid systems that have some utilities using capabilities to get their privileges along with some setuid(0) utilities. In that scenario, a capabilities-based utility or daemon may wish to limit what its children can do, even if they execute a setuid(0) binary. As part of the evolution, process trees can be created that cannot get root privileges. Processes which have the CAP_SETPCAP capability can change their securebits setting via the prctl() system call. There are three separate bits that govern the interaction of capabilities and setuid:
prctl(PR_SET_SECUREBITS, 0x2f);
This is the equivalent of setting SECURE_NOROOT, SECURE_NO_ROOT_LOCKED,
SECURE_NO_SETUID_FIXUP, SECURE_NO_SETUID_FIXUP_LOCKED, and
SECURE_KEEP_CAPS_LOCKED.
The memory of the sendmail-capabilities bug from 2000 makes some a bit queasy—or worse—about any patches that involve capabilities and setuid. Andrew Morton asks: "what was the bug which caused us to cripple capability inheritance back in the days of yore? (Some sendmail thing?)" That bug was caused because unprivileged users could take away the CAP_SETUID capability from setuid binaries like sendmail. When sendmail then used setuid to drop its privileges, it failed, but sendmail did not check, so it was still running with full privilege. This could be leveraged by a user to gain root privileges. It was a disconnect between capabilities and the longstanding behavior of Unix-like systems when dropping privileges. Morgan has written a detailed description of the sendmail-capabilities bug in response to Morton's questions. He makes it clear that he wants to move toward full capability support without breaking existing code:
I'm basically interested in evolving the capability implementation
back to the POSIX.1e model and making it whole - but most certainly
*without crippling legacy superuser support in the process* .
As folk get more comfortable with this full capability model. I believe we can delete more cruft from the main kernel, but even that clean up will leave a fully functional legacy model in place. I feel it should be for something like init, or one of its children to be able to run subsystems in capability-only or legacy modes. Morton seemed satisfied that his concerns had been addressed, but still wonders about the future for capabilities: "So how do we ever get to the stage where we can recommend that distributors turn these things on, and have them agree with us?" This was echoed by Ismail Dönmez, who was looking for concrete examples of how to use the per-process securebits feature. Morgan provides a pointer to some examples along with his belief that sometime soon the capabilities developers will become confident enough to recommend turning off the "experimental" flag for the SECURITY_FILE_CAPABILITIES kernel configuration. That flag governs both the file-based capabilities as well as the per-process securebits. In addition, Morgan says:
More importantly I'm hopeful that in that time we'll have accumulated
enough documentation and user-space experience and examples to convince
others that this is, indeed, a viable feature to support in mainstream
distributions.
A developerWorks article on file-based capabilities by Serge Hallyn and a web page on POSIX capabilities by Chris Friedhoff were both mentioned in the thread as good references for the work being done to actually use capabilities in systems. Those pre-date the securebits work, so Dönmez was looking for use-cases for the new feature. Morgan replied that containers were one, deferring to Hallyn who has some ideas on using securebits:
We tend to talk about 'system containers' versus 'application
containers'. A system container would be like a vserver or openvz
instance, something which looks like a separate machine. I was
going to say I don't imagine per-process securebits being useful
there, but actually since a system container doesn't need to do any
hardware setup it actually might be a much easier start for a full
SECURE_NOROOT distro than a real machine. Heck, on a real machine init
and a few legacy [daemons] could run in the init namespace, while users
log in and apache etc run in a SECURE_NOROOT container.
But I especially like the thought of for instance postfix running in a carefully crafted application container (with its own virtual network card and limited file tree and no visibility of other processes) with SECURE_NOROOT on. Capabilities are an interesting, but complicated, security feature. For most of the ten years they have been part of the Linux kernel, they have either been broken, ignored, or both. With the latest work being done by Hallyn, Morgan, and others, capabilities are finally becoming a fully-working alternative to things like SELinux. It will be interesting to see if more user utilities will become capability-aware and whether distributions start using capabilities. Some day, root may just fade away.
Ksplice: kernel patches without reboots The kernel developers are generally quite good about responding to security problems. Once a vulnerability in the kernel has been found, a patch comes out in short order; system administrators can then apply the patch (or get a patched kernel from their distributor), reboot the system, and get on with life knowing that the vulnerability has been fixed. It is a system which works pretty well.One little problem remains, though: rebooting the system is a pain. At a minimum, it requires a few minutes of down time. In many situations, that down time cannot be tolerated. Reboots also disrupt any ongoing work, break existing network connections, and can cause the loss of results from long-running processes. And, most importantly of all, reboots prove traumatic for a certain subset of Linux administrators who prize a long uptime above almost all other things. Administrators currently have to choose between multi-year uptimes and security fixes; anything which frees them from a dilemma of this magnitude can only be welcome. That "anything" might just be a recently-announced project called ksplice. With ksplice, system administrators can have the best of both worlds: security fixes without unsightly reboots. An in-depth explanation of how ksplice works can be found in this document [PDF]. In short, ksplice requires as input the source tree for the running kernel and the security patch. It will then build two kernels, one with the patch and one without; the kernels are built with a special set of options which makes it easy to figure out which functions change as a result of the patch. The two kernels will be compared, with the purpose of finding those functions. Changes can propagate further than one might expect, especially if, for example, an inline function is modified. Once a list of changed functions has been made, the updated code for those functions is packaged into a kernel module and loaded into the system. Then comes the tricky part: getting the running kernel to start using the new code. That requires patching the running code, which is a risky thing to do. Ksplice starts with a call to stop_machine_run(), which dumps a high-priority thread onto each processor, thus taking control of all processors in the system. It then examines all threads in the system to ensure that none of them are running in the functions to be replaced; if so, trampoline jumps are patched into the beginning of each replaced function (they "bounce" the call to the old code into the replacement code) and life continues. Otherwise ksplice will back off and try again later. This method imposes a number of limitations. One is that only code changes can be patched in with ksplice; patches which make changes to data structures cannot be accommodated. Another comes from the retry-based approach to ensuring that no threads are running in the patched functions; what happens if one of those functions is never free? Kernel functions like schedule(), sys_poll(), or sys_waitid() are likely to always have processes running within them. In cases like this, ksplice will eventually give up and inform the user that the patch cannot be done; it is simply not possible to make changes to those particular functions. These limitations mean that, out of 50 security patches examined by the ksplice developers, eight could not be applied with ksplice. So multi-year uptimes are probably still incompatible with the application of all security patches. Even so, ksplice certainly has the potential to reduce patch-related downtime considerably. Chances are good that there will be a fair amount of interest in ksplice in sites running high-uptime, mission-critical systems. There are few things in the way of an immediate merge of this code into the mainline. One is a matter of coding quality and can be fixed. Then, there is the matter of the lead developer being unconvinced that merging this code makes sense since it is, essentially, a standalone feature. Andi Kleen's response made the (usual) reasons for merging the code clear:
To be honest you weren't the first to come up with something like
this (although you're the first to post to l-k as far as I
know). But the usual problem of something that is kept out of tree
is that it eventually bitrots and gets forgotten. The only sane way
to make such extensions a generically usable linux feature is to
merge them to mainline.
So, presumably, the code will eventually be proposed for a mainline merge. But there is one other little difficulty pointed out by Tomasz Chmielewski: Microsoft holds a patent described this way:
A system and method for automatically updating software components
on a running computer system without requiring any interruption of
service. A software module is hotpatched by loading a patch into
memory and modifying an instruction in the original module to jump
to the patch.
Microsoft came up with this novel new technique in the distant past: 2002. The posting immediately brought out a crowd of surprised graybeards who distinctly remember using such techniques on their PDP-11 systems some decades before Microsoft "invented" hot-patching. The basic claim of the patent would thus appear to be invalidated by some decades' worth of prior art, but some of the dependent claims include features (such as capturing all other processors on the system) which were unlikely to be useful on PDP-11s. Given that the kernel developers are now well aware of this patent, they must take it into account when deciding whether to accept this code into the mainline. It would not be surprising if they chose to avoid baiting the Microsoft FUD machine in this way, even if they all agreed that the patent lacked validity. So a promising technology risks being left out of the kernel as the result of a software patent which was filed at least 30 years too late.
Patches and updates Core kernel code
Development tools
Device drivers
Documentation
Filesystems and block I/O
Janitorial
Memory management
Networking
Architecture-specific
Security-related
Virtualization and containers
Miscellaneous
Page editor: Jonathan Corbet
Distributions News and Editorials Distributions in the Summer of Code For the fourth year, Google's Summer of Code will pay undergraduate students to work with some of the world's top developers on open-source projects. Students and mentors also get a T-shirt, which for many of us is motivation enough. Many of the accepted projects are not surprising, such as GNOME, KDE, Drupal, and Python. One interesting category of projects, however, is distributions. Aren't they just writing packages? What would they do with a Summer of Code project? That's what this article aims to discover. This year, four distributions were accepted for a combined total of 40 slots: Debian, Fedora, Gentoo, and openSUSE. Conspicuous in their absence are other major distributions such as Mandriva and Ubuntu. One wonders what happened—did they apply (if not, how come?); were they rejected? Ubuntu participated in 2006 and 2007, so it is curious that the distribution is not in SoC this year. In addition to these four distributions, three of the BSDs participated as well, receiving a combined total of 35 slots: DragonFly BSD, FreeBSD, and NetBSD. Since these are operating systems in addition to their own package distributions, many of their slots are devoted to core OS code, while the Linux distributions' slots are not. Let's take a closer look at the types of distribution projects in this year's Summer of Code. Many of Debian's 12 projects relate to installation (two slots), configuration management (two slots), or package management/development (seven slots). The exception is a project to make an embedded, Debian-based NAS device. Another 12 slots went to Fedora, which shared two of its slots with JBoss. Fedora has a more eclectic mix: it devoted two slots to package management and two to configuration management, investing the remaining slots in features for a translation framework (three), creation of a new Web interface for the hardware profiler Smolt, enhancement of the booting profiler Bootchart to use SystemTap, and creation of a simple, non-linear video editor for ogg video to integrate with the screencasting tool recordmydesktop. Gentoo received six slots, of which two relate to package management. The other four are dedicated to diverse projects: implementing OpenPAM-compatible modules for Linux, improving a Web-based, WYSIWYG XML editor, making it easy to set up a Beowulf cluster, and improving Gentoo's embedded network-appliance framework. OpenSUSE got ten slots; five of these are going toward package management/development, and one is going toward installation. The remaining four are the most generally interesting: implementing a face-based authentication module, enabling ext4 as GRUB's boot partition, interactive crash analysis (presumably an improvement upon what recent GNOME versions do rather than a duplication), and creation of a GUI manager for LTSP thin clients. Now let's take a quick look at BSD land. Of DragonFly's projects, six out of seven are OS-related, and the other is installation-related. FreeBSD received 21 slots, of which many are devoted to the core OS—of the rest, four are related to package management/development, and one aims to improve Wine support. NetBSD received 14 slots, of which many again went to the core OS. Other than that, one slot went to installation and another to package management. Distributions and "mixed" distributions/OSs unsurprisingly devote a large quantity of their efforts to their core competencies of package management, configuration management, and installation. At least in the Summer of Code, however, they do devote a significant amount of effort to solving larger problems that affect people outside the distribution.
New Releases The Heron has landed Ubuntu 8.04 LTS, aka Hardy Heron, has been released. "The Ubuntu team is pleased to announce Ubuntu 8.04 LTS (Long-Term Support) on desktop and server, continuing Ubuntu's tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution." Click below for more details.
Slackware 12.1 RC3 The third release candidate for Slackware 12.1 was announced in the April 28th entry of the slackware-current changelog. "We'll call this Slackware 12.1 RC3, and freeze the tree for anything that isn't critical. Things seem very stable, so it's probably a good idea to save any further upgrades and additions until -current restarts."
Gentoo 2008.0_beta2 released The second beta for Gentoo 2008.0 has been announced. "This should be the last beta and will be followed by the final 2008.0 release after further bug fixing."
Distribution News Debian GNU/Linux Debian participates in the 2008 Google "Summer of Code" The Debian Project takes a look at this year's Summer of Code projects. "We have been allocated twelve tasks for this year. Google will fund the students mentioned here to work full time on those tasks during their summer vacation, from May 26th to August 18th. They will be guided and evaluated during this time by a team of Debian developers."
Latest stuff from the DPL: teams review starting Steve McIntyre has started reviewing Debian teams. "As part of my election platform this year, I promised a thorough review of how Debian's team are working. It's taken a few days longer than I planned to get here, but I've just sent out copies of a survey to lots of our mailing lists."
New addition to the DAM team The Debian Account Manager team has another new member, Christoph Berg.
New README.source documentation for Debian packages According to discussions on the debian-policy list, a new documentation file, debian/README.source, is recommending for any Debian source package with a complex build system. So far this is just a recommendation and not considered release-critical for Lenny.
Blocking uploads of packages involved in the Python 2.5 transition Python 2.5 is migrating to testing and is the planned default for Lenny. Click below for more information.
Fedora Fedora 7 End of Life Fedora 7 will reach its End of Life for official updates on Friday, June 13, 2008. Fedora 9 will have been available for one month by this time, and Fedora 8 is also available for upgrade.
Fedora Board Recap 2008-APR-22 Click below for a summary of the April 22 meeting of the Fedora board. Topics discussed include Red Hat Summit and FUDCon, Board Succession, and Spins.
Fedora Board public meeting, 1800 UTC 2008-05-06 The Fedora Board is holding its monthly public meeting on Tuesday, May 6, 2008, at 1800 UTC on IRC Freenode. The public is invited to listen in at #fedora-board-meeting and discuss topics and post questions at #fedora-board-public.
SUSE Linux and openSUSE openSUSE Google Summer of Code Projects Announced openSUSE announced its Google Summer of Code projects. "Special thanks to everybody that has been involved so far: the volunteering mentors, those driving the application process, and of course - all of the students. Congratulations to all the selected students!"
Distribution Newsletters BSD Magazine #1 published The first issue of BSD Magazine has been announced. It's available by subscription in print or electronic form, with a corporate rate for companies.
Misc Debian development news (#7) This edition of Debian development news covers debhelper v7, Help the DPL, New debian-ports.org machine, Debconf translation updates, and Planet Debian via Mail.
Gentoo Monthly Newsletter: 24 April 2008 The fourth edition of the Gentoo Monthly Newsletter is out. " This month, we haven't made any significant changes from the previous edition. However, we have featured an interview, and we hope to include more of them in future issues. You'll note that we will be interviewing not only Gentoo developers, but also people involved in the Gentoo community at large."
OpenSUSE Weekly News/19 This edition of openSUSE Weekly News looks at OpenOffice_org 2.4 available, 11.0 feature by feature: All you ever wanted to know!, Tips and Tricks: fdupes & freedup, Building KDE on openSUSE was never easier, Lukas Ocilka: Image-based Installation, and several other topics.
Ubuntu Weekly Newsletter #88 The Ubuntu Weekly Newsletter for April 26, 2008 covers Hardy Heron Release Parties, Ubuntu 8.04 press release translations, Open Week, Forum Interviews & Tutorials, Preinstalled Ubuntu PCs for Russia, Ubuntu UK Podcast, Full Circle Magazine, Team Meeting Summaries, and much more.
DistroWatch Weekly, Issue 250 The DistroWatch Weekly for April 28, 2008 is out. "This was surely one of the most trying weeks for the system administrators of many public FTP and HTTP servers that provide the Ubuntu ISO images - such was the demand for the new release that not even the project's main web site could keep up with the request rate! But that's a testament to Ubuntu's popularity, which has now grown into the world's most wanted alternative operating system. In other news, the Debian project has revived the Debian Weekly News, OpenSolaris has announced a final release candidate for its upcoming first stable release, Software Wydawnictwo has published the inaugural issue of the new BSD Magazine, and openSUSE has unveiled a new resource for beta testers of its distribution. Also not to be missed: our first look at the new ASUS Eee PC 900 with Xandros Desktop pre-installed."
Distribution meetings Announcing Ubuntu Open Week This week is Ubuntu Open Week, which is a community building event for the distribution. Running April 28 through May 3, the event consists of IRC sessions on multiple topics for all segments of the community, not just programmers or folks doing packaging. "The aim of the week is to help grow the Ubuntu community, and we have an awesome set of topics ready for you to attend. If you've considered getting involved in Ubuntu and don't know where to start, then this is a great opportunity to jump in." Click below for the announcement.
Miscellaneous Articles The Perfect Desktop - Ubuntu 8.04 LTS (Hardy Heron) (HowtoForge) HowtoForge provides step-by-step instructions for setting up the Hardy Heron on the desktop. "This document describes step by step how to set up a Ubuntu 8.04 LTS (Hardy Heron) desktop. The result is a fast, secure and extendable system that provides all you need for daily work and entertainment."
Interviews Ubuntu man Shuttleworth dissects Hardy Heron's arrival (The Register) The Register talks with Mark Shuttleworth about the Hardy release. "[Shuttleworth] is giddy about the inclusion of the Wubi installer with Hardy Heron. This software package lets you run Ubuntu on a Windows machine without bothering to set up a dedicated partition. So, you can play with Ubuntu and see if you like it while avoiding a major disk commitment. "What I really like is that Canonical didn't invent it. It was a community guy decided this was possible, and he worked through the community process and got it in. And it is a major feature for this release.""
Interview: Steve McIntyre, Debian Project Leader (ComputerWorldUK) ComputerWorldUK has an interview with Steve McIntyre, the recently elected Debian Prioject Leader. "Debian is sometimes criticised as being for hobbyists despite evidence that it's used by some very serious organisations for some massive deployments. Do you think the Debian project has some work to do in articulating its enterprise credentials? I think that there's always scope for us to do more on that front. There will always be some users who won't believe in Debian as an option for the enterprise just because we're not directly backed by a large corporation, and that will be a difficult attitude to change. However, I know of lots of companies today that will provide paid support for Debian where it's required, and we already have a fine reputation for stability. I think that the next trick is to start making more of a positive impact directly in the "Enterprise" space with positive press exposure and good reviews."
Distribution reviews Ubuntu 8.04 Brings Power and Polish to the Linux Desktop (Wired Blog) Scott Gilbertson reviews Ubuntu 8.04 LTS. "Ubuntu 8.04 also features a new version of Xorg, which offers much better auto-configuration options for setting up your monitor. The new Screen Resolution utility also makes it easier to dynamically change your screen resolution and control a second or external monitor. Other significant under-the-hood changes are aimed at improving security -- like the new PolicyKit interface which makes it easy to allow or deny access to applications and even specific parts of applications. PolicyKit is a huge step forward for administrators looking to maintain tight control over their systems."
The Great Ubuntu-Girlfriend Experiment (Content Consumer) There is lots of Ubuntu buzz right now due to the release of Hardy, but the Content Consumer weblog has an article with wider applicability as well. If the year of the Linux desktop is ever going to happen, usability by non-technical folks is a requirement. One way to measure the usability is to sit your girlfriend in front of a Linux desktop and see what problems she encounters trying to do some normal desktop tasks. "Erin’s knowledge of computers is limited to word processors, spreadsheets, Photoshop and a reasonable amount of browsing on the Web. Fairly standard stuff for a university philosophy student. All I did to the system (before leaving Erin at the log-in screen) was to install it and create a user account for her. She had no problems logging in, and loved the stylised heron background. Then I gave her one by one the tasks I’d set her. I didn’t give her any help at all." (seen at Slashdot)Update: As can be seen in the comments, this item offended some of our readers. I offer my deepest apologies to anyone who was offended by it. That was certainly not the intent.
Page editor: Rebecca Sobol
Development Stream video and audio with Boxtream Boxtream is a GPL-licensed streaming video and audio system that is being developed by Jerome Alet and a team of developers at the University of Nice in France:
Boxtream is a mobile and autonomous audio and video streaming and recording studio. Of course, depending on your own hardware choices, the number and extent of capabilities and the quality of the final results may vary, but at least the software part should be versatile enough to accommodate even the most basic hardware.
Boxtream was mostly designed to stream live courses featuring a professor and his slides (or any other computer based output like software training, web browser, video player...), but can also be used to stream congresses, interviews and the like.
Boxtream uses a virtual smorgasbord of open-source components to achieve its results. Scripting is done with the Python language, metadata is stored in the XML format. The GStreamer multimedia framework library is used for handling the audio/video data and the Icecast streaming media server is used for media distribution. Video and audio are encoded with Ogg Theora and Ogg Vorbis. The Graphviz graph visualization software is used for presenting a graphical view of the video system's scenario. A few notable Boxtream features include a GUI interface, support for on-disk recording, selectable audio and video rates, support for image overlays and automation for all tasks. The Boxtream features list has a more complete list. Boxtream supports a number of video switching devices as well as other video and audio equipment. The hardware list has more information. This architecture diagram gives a pictorial view of a fairly complicated Boxtream system. An online example shows the system being used for a scientific conference. Boxtream version 0.998 was announced on April 27, 2008. Changes include support for more video hardware, inclusion of the dia schema software, bug fixes and a license change from GPLv2 to GPLv3. If your organization is in need of a full-featured video conferencing system, you should give Boxtream a look.
System Applications Database Software Firebird sub-release 2.0.4 announced Sub-release 2.0.4 of the Firebird DBMS has been announced. "Several important bugs have been fixed, including a number of unregistered nbackup bugs that were found to cause database corruptions under high-load conditions. During Firebird 2.1 development it was discovered that Forced Writes had never worked on Linux, in either the InterBase or the Firebird era. That was fixed in V.2.1 and backported to this sub-release. The issue with events over WNet protocol reported below for v.2.0.3 has been fixed."
Three Kexi patches announced Three patches have been released for Kexi, a KDE visual database design tool. "Dear users, As there are no new releases of KOffice in 1.x series, we're providing important maintenance patches from time to time. These patches are especially recommended for Linux/Unix distributions: in order to maintain high quality of the software, packagers should apple them before building."
PostgreSQL Weekly News The April 27, 2008 edition of the Postgres Weekly News is online with the latest PostgreSQL DBMS articles and resources.
Interoperability Inaugural Samba Mashup Report released A new newsletter that covers the Samba world has released its first issue. It is planned to be bi-weekly (fortnightly for those of a UK persuasion). It will summarize mailing list threads and cover recent events affecting the Samba community. "Several of Samba team members agreed during discussions held at Samba XP (see article #3) that periodic thread summaries from the recent development activities would be helpful for keeping the community and Samba OEM vendors up to date. So using editorial privilege, I've decided to term these as mashup reports." Click below for the full issue.
Samba 3.2.0pre3 announced Version 3.2.0pre3 of Samba has been announced. "This is the third preview release of Samba 3.2.0. This is *not* intended for production environments and is designed for testing purposes only."
Networking Tools A GPL'd DHCP server with SQL, Perl, Python, Java, and LDAP support Version 2.0.4 of the Freeradius DHCP server has been released. "It's experimental, but the code works for clients including MAC, XP, Vista, *BSD, and Linux. We're looking for contributors to test it, and to supply bug fixes, questions, scripts, SQL schemas, or anything else that could be useful."
Printing CUPS DDK will be part of CUPS 1.4 The CUPS printing project has announced the inclusion of the CUPS Driver Development Kit with CUPS version 1.4. "As part of the CUPS 1.4 development, the CUPS DDK is being merged into the main CUPS sources. Aside from making the DDK components standard in every CUPS-based printing environment, we hope this will make providing printer drivers even easier than before."
Gutenprint: 5.2.0-beta2 released (SourceForge) Version 5.2.0-beta2 of Gutenprint has been announced, it includes a critical bug fix. "Gutenprint is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX, Linux, and Macintosh OS X (10.2 and above) systems. Gutenprint includes CUPS and Foomatic drivers, and an enhanced Print plug-in for GIMP that replaces the print plug-in packaged with the GIMP distribution."
Security FreeIPA 1.0 released Version 1.0 of FreeIPA has been announced. "FreeIPA is an integrated security information management solution combining Linux (Fedora), Fedora Directory Server, MIT Kerberos and NTP. FreeIPA binds together a number of technologies and adds a web interface and command-line administration tools. Currently it supports identity management with plans to support policy and auditing management. We were able to achieve most of the planned features for this release though we had to postpone some of them to later versions we are very happy about the outcome."
Miscellaneous Wubi: 8.04 final released (SourceForge) Version 8.04 final of Wubi has been announced. "We are pleased to announce the release of Wubi 8.04! Wubi is an officially supported Ubuntu installer for Windows users that allows to install and uninstall Ubuntu as any other Windows application, in a simple and safe way."
Desktop Applications Audio Applications Rivendell v1.0.0rc1 announced Version 1.0.0rc1 of Rivendell, a radio station automation system, has been announced. "Rivendell is a full-featured radio automation system targeted for use in professional broadcast environments. It is available under the GNU General Public License." Changes in this release include skinnable modules, a database update and bug fixes.
Desktop Environments GNOME 2.24 roadmap released The roadmap for GNOME 2.24 (and beyond) is out. There will be a lot of stuff in the next release, including Epiphany's WebKit migration, "unified account management" in Evolution, XRandR 1.2 support, Empathy, Conduit, and a decision on a new distributed version control system.
GARNOME 2.23.1 released Version 2.23.1 of GARNOME, the bleeding-edge GNOME distribution, has been announced. "Welcome to the 2.23 development cycle! We'll hopefully enjoy some nice new bugs and crashes, while we'll have to live with new features, improvements or fixes. This is the first development release on our trip to GNOME 2.24, which will be out in September, in around five months."
GNOME Software Announcements The following new GNOME software has been announced this week:
KDE 4.1 Alpha1 is out The first alpha release of KDE 4.1 has been released. "Highlights: - Qt 4.4 based (webkit support, among others) - Akonadi cross-desktop PIM storage engine - KDE PIM available (not Akonadi-based yet)".
KDE Software Announcements The following new KDE software has been announced this week:
Xorg Software Announcements The following new Xorg software has been announced this week:
Financial Applications GnuCash 2.2.5 released Version 2.2.5 of GnuCash has been announced. "The GnuCash development team proudly announces GnuCash 2.2.5 aka "Do what I mean", the fifth bug fix release in a series of stable releases of the GnuCash Free Accounting Software."
Games OpenCards: 0.14 released (SourceForge) Version 0.14 of OpenCards has been announced, it includes new features and bug fixes. "OpenCards is a flashcard learning extension for OpenOffice Impress. The basic idea of OpenCards is to use slide-titles as flashcard fronts and the slide contents as their backs."
UFO:Alien Invasion: 2.2.1 released (SourceForge) Version 2.2.1 of UFO:Alien Invasion has been announced. "It is the year 2084. You control a secret organisation charged with defending Earth from a brutal alien enemy. Build up your bases, prepare your team, and dive head-first into the fast and flowing turn-based combat. The UFO:AI development team is proud to announce the release of UFO:Alien Invasion Version 2.2.1 - This is a bugfix release for the 2.2 version."
GUI Packages FLTK 1.1.9 final version released Version 1.1.9 final of FLTK has been announced. "This version fixes two regressions and a bug that could lead to a crash under some circumstances."
Music Applications jack-smf-utils 0.9 released Version 0.9 of jack-smf-utils has been announced. "Jack-smf-utils is a set of two utilities - jack-smf-player and jack-smf-recorder - whose purpose is to play and record MIDI streams from/to Standard Midi Files (i.e. the files with .mid extension) using JACK MIDI."
Office Suites OpenOffice.org Newsletter The April, 2008 edition of the OpenOffice.org Newsletter is out with the latest OO.o office suite articles and events.
Languages and Tools C GCC 4.3.1 Status Report The April 17, 2008 edition of the GCC 4.3.1 Status Report has been published. "GCC 4.3.1 is scheduled for 2008-05-05. As we have not yet built 4.3.1-rc1, we will slip that date. As shown below, there are 2 P1s on the 4.3 branch, so we are not yet ready to build RC1."
Caml | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||