LWN.net Weekly Edition for March 22, 2007

Linux and flash

One of the things your editor heard Lawrence Lessig say at Wizards of OS 4 was that video is the communication medium of our time. The free software world needs to better support this channel. In support of this argument, consider that those of us interested in the next U.S. presidential election (a mere year and a half away) may have to resort increasingly to anonymously-posted videos to get our full share of attack advertisements. The best mudslinging will be unavailable to those of us stuck in the text world.

While there are a number of video formats out there, what all of this really comes down to is that we need decent support for Flash. For better or for worse, Flash dominates in a number of areas, including network video and a number of interactive site features. It's not just for really obnoxious advertisements anymore. We do not have decent support for Flash now; that proprietary plugin just does not cut it in the free software world.

The good news is that we're getting closer to the level of support we need. In particular, Benjamin Otte has recently announced that the swfdec Flash player is now able to work with video from YouTube. In general, swfdec has some ground to cover yet; to answer the question of whether swfdec can replace proprietary Flash Benjamin writes:

What's important here is that swfdec has hit a point where it will start to be truly useful; that, in turn, may help to attract more developers to the project. A program which almost works is often more attractive to hack on than something which is just a promise for the future.

Swfdec is not the only Flash-related project out there; Gnash is also working toward a solution to this problem. Gnash would also appear to be at a similar point in development; the project is not quite ready to proclaim YouTube support, but, according to Gnash hacker Rob Savoye, that's a result of different objectives:

Given that what we need is one truly good Flash player, one might well wonder what the point of two competing projects is. That is the same question people asked about desktops in the past; at this point it seems clear (to your editor, at least) that the competition between GNOME and KDE has helped to increase the pace of free desktop development and to explore different approaches to the graphical Linux experience. The important thing is to focus on the development and stay away from silly flame wars. To that end, Rob's message contains some good news:

If the projects can continue to cooperate and learn from each other, Linux should have a high-quality Flash implementation in short order. If some of the more desktop-oriented distributions were to realize that supporting these projects is very much in their own interest, it could happen even sooner. There are few limits to what a free software project can do once it gets rolling.

A good Flash player is just the beginning, however. If we want free software to have a significant role in the creation of all this content, we need good authoring tools - and those are rather further behind. Another thing Lawrence Lessig urged was the creation of a free software culture for Flash developers, almost all of whom are, for all practical purposes, shipping binaries at this point. Some good free Flash tools, along with increased support for sharing source, could transform the Flash development world - for video and more. We could help to bring freedom to an important communication medium; that would be even better than creating the ability to watch silly videos with free software tools.

Comments (32 posted)

Playing with the N800

Besides, it's a cool new gadget.

The N800 is, naturally, a Linux-powered device. It has an 800x480 screen, two speakers, and a pop-out camera. There's a headphone jack, a USB port, and two SD memory slots. The device can communicate wirelessly via 802.11 or Bluetooth. Also provided is a stylus which is used for most interaction with the device; there is a built-in storage slot for the stylus which should help to prevent loss, but it's still nice that Nokia thought to provide a spare as well.

On the connectivity side, the N800 developers have done some nice work. On the first boot, the tablet offers to pair with a Bluetooth-capable phone and set up a GPRS connection automatically. Anybody who has been through the process of setting up a Bluetooth/GPRS link on a Linux system knows that there can be a certain amount of pain involved - and that's before trying to get any real work done over such a painfully slow connection. Having GPRS Just Work is a nice bonus. The tablet also handles WiFi connections easily.

After that, however, a new N800 user might well feel at a bit of a loss. The startup screen includes a Google search bar (the usage of which is entirely straightforward), an RSS reader window with no subscribed feeds, a contact manager window (with no contacts, obviously), and a "Discover Tableteer" window which, when "tapped," opens a web browser on a remarkably static and unhelpful Nokia page. Digging through the menus yields a simple email client. Anybody expecting something that feels like a normal Linux system will be disappointed; there's not a whole lot else there. That can be changed, of course; we'll get to application installation shortly.

The tablet comes packaged with a user's manual, in PDF format, in a large number of languages. The user will not encounter this manual until he or she happens to fire up the file manager and look in the right place, however. The "Discover Tableteer" window does not do much to help a beginning user find this useful document.

Text entry is done through a keyboard which appears at the bottom of the screen; individual letters are approximately 2mm square. In practice, the letters are not hard to hit, and, with a bit of practice, one gets good at entering text quickly. Learning the simple gestures to minimize trips to the shift keys helps a lot. There is another mode where the keyboard expands to fill most of the screen; in this mode, the stylus can be put aside and text can be typed directly with the fingers. It works, and can be nice for extended text input, but your fat-fingered editor had a hard time using it as a real QWERTY keyboard. Finally, the tablet does support handwriting recognition, but your editor has not really had a chance to play with that mode yet.

The web browser is the proprietary Opera application. It works reasonably well for the most part, making good use of the limited display space. Your editor has found it to be not entirely stable; it occasionally hangs and must be restarted. Dragging Google maps around does not work. Pages generally render well, though; the browser is good enough for the sort of work one would want to do on a small tablet device.

Your editor tried the Minimo browser as well. It does not seem to render pages as nicely as Opera, based on some quick tests. It is also far less stable; your editor managed to crash it almost immediately. Still, Minimo will stay on the system in the hope that it gets better; your editor would much prefer to run free software on this system.

There is an application manager which can be used to install more software onto the tablet. The bad news is that it has little to offer out of the box. The good news is that one can go to maemo.org to look for a rather wider variety of software goodies for the device. The bad news is that the majority of those applications, as of this writing, say "missing install" and cannot actually be installed onto a tablet. The good news is that there's still quite a few useful tools available. In short order, your editor was able to equip his tablet with essential utilities like xterm and an ssh client.

The really bad news showed up with some of the other interesting packages, such as vim and gnumeric. The application manager will happily download the packages before popping up a window which says:

Such a message would perhaps have been acceptable ten years ago on some distributions. One would not expect to see it on a Debian-based system in 2007. There is no excuse for an "application manager" which is unable to handle dependencies anymore.

The N800 includes a (proprietary) Flash player and a media player as well. As many others have noted, the tablet comes well equipped to handle patent-encumbered formats like MP3 but it cannot play an Ogg file. One can make an argument for minimizing the size of the base system on a resource-limited tablet, but there's no easy way to fill in that gap afterward either. It would appear that installing an Ogg player, at this point in time, would involve downloading the development kit and building the application from source.

In general, the N800 feels a little like an unfinished product. Nokia has created a nice piece of hardware, based (mostly) on free software, and appears to be hoping that the development community will help turn it into a fully capable device. The company's practice of selling tablets to developers at a sharply-reduced price is clearly intended to help make this happen. One can only hope that Nokia succeeds here; the company has done what we really need it to do: made a open, Linux-based device. We certainly have the ability to make it do interesting things from here.

Comments (9 posted)

The road to freedom in the embedded world

If I had to choose the single moment that defines when the Free Software movement became self-aware, it would be the 1983 publication of the GNU manifesto by Richard Stallman. Despite its age it is amazingly up to date. Free Software has come a long way since that time; creating an alternative by inspiring people to put together the GNU Project piece by piece on a proprietary platform.

Only with the publication of the Linux kernel were people able to see pure Free Software operating systems running on their computers in the 90s. But they were still booting off a proprietary BIOS, and we also saw an increasing tendency to put hardware functionality into proprietary firmware. Only recently have projects such as LinuxBIOS managed to bring more freedom to the BIOS, although notebooks still are problematic. The issue of proprietary firmware is still being worked on, including by the FSF.

Compared to the situation in the personal computer area, embedded devices are still several years behind, but there are people who are working hard to catch up. I recently had the pleasure to learn a little more about this exciting field.

One device that a lot of people have in their homes or offices are routers to connect to the internet. Until not so long ago, these used to be entirely proprietary. That is no longer true. Not only do several vendors provide routers with more or less free firmware based on the Linux kernel, but the OpenWRT project and its younger offspring the FreeWRT project have also made some amazing advances in this area.

However even though FreeWRT has a web interface to build custom firmware online, both are still catching up with the freedom, ubiquity and sophistication of modern GNU/Linux desktop distributions.

There are still problems with hardware compatibility and drivers, as both distributions are still confined to a certain chipset, and locked into the 2.4 Linux kernel series because of proprietary drivers for the wireless card built by Broadcom, a manufacturer that has proven itself to be very uncooperative towards the Free Software community.

Getting rid of these restrictions to freedom is a collaborative effort with many different players, including FSFE's Freedom Task Force, which helped the OpenWRT team to avoid making mistakes in the reverse engineering of the Broadcom wireless driver, such that the result will then be fully usable by all Free Software.

The situation with mobile phones and PDAs is even worse than that of routers. Until very recently it was close to impossible to find mobile phones that were running Free Software and gave the user control over what they were doing.

One of the first companies that tried to answer requests for Free Software mobile phones was Trolltech with their Qtopia Greenphone. Maybe because this was the first time this was tried, and maybe because they didn't consult enough community voices before launching the phone, they made some mistakes. One of them was the overly restrictive EULA terms, which Trolltech quickly corrected after being confronted with the problem.

This was not the only problem. The Greenphone's package management is still proprietary, although that problem can be mitigated by using the ipkg package manager instead. Ultimately it seems that everything but the communication stack can be replaced by Free Software in this way. So the Greenphone was a step in the right direction, but it is not yet good enough.

The interest it raised probably also helped bringing about the OpenMoko phone, which will ship very soon and which is taking another big step toward freedom. Like the Greenphone, the GSM stack remains proprietary, though. Reasons for this appear to be a thicket of cross-licensed patents and regulatory concerns about frequency usage and transmission strength.

Many politicians are concerned that tinkering with these could impair the ability of other people to communicate, including the ability to access emergency services. Their argument is that the potential damage done by tinkering is greater than the damage of not having the freedom to change the code. This is a reincarnation of the old "your freedom to swing your fist ends at my nose" argument, and it is not easily discarded. We need to convince society with good answers to this and because of that, the GSM stack is likely to remain a difficult area for some time.

Depending on when you start to count, it took our community at least 10 years to address the issue of the proprietary BIOS on our PCs, but we did not let this stop us from improving our GNU/Linux Desktops. In the same way I believe we should work to create maximum freedom on mobile phones.

Other possible candidates have been launched by Nokia, namely the 770 and N800 internet tablets. Both devices are running a Linux kernel with a very small GNU/Busybox system using Debian package management.

Because they do not need the GSM stack, these devices might be made entirely free, though unfortunately they are not being shipped that way. They come with the proprietary Opera browser and a Flash player, which are easily uninstalled and can be replaced by a Mozilla port called Minimo; maybe Gnash can be compiled for them as well.

But there is more work waiting to be done: In a sad kind of irony Nokia seems to have chosen the Gtk+ library over Qt because that would allow them to keep part of their helper library for the embedded small screen proprietary. There are also other parts that are still kept proprietary, like the boot loader and battery charging application. They also seem to share the proprietary firmware problem with the personal computer platform. Even the flashing utility is proprietary software at the current point in time.

This has made some people very sceptical. It may even turn out that we will not be able to free these specific devices entirely without Nokia's help on the hardware interfaces, which may never come. But working to free them will inevitably end up providing more freedom, although maybe not on these specific devices. Experience gained can be used in many ways, and Free Software written can be transferred to other platforms.

Like the Greenphone, these Nokia devices provide a substantial step towards freedom, but are not yet good enough. So they have to be seen as an intermediate step towards freedom in the embedded world. Both Trolltech and Nokia deserve praise for making a step into the right direction, as well as constructive criticism on the remaining proprietary parts, which should also be set free.

There are projects that have already gotten very far in this effort for other devices, like the Familiar Project for the iPAQ which, I was told, is now running fully Free Software except for the wireless driver. And there are other devices that seem capable of running Familiar, like the Siemens Simpad, which also spawned its own community project to set it free. So maybe a FreeMaemo.org project is what we need for the Nokia internet tablets.

An essential element in truly achieving freedom in the embedded world will be to further strengthen the Free Software community in this area and enable more Free Software developers to tinker with these devices.

One person who has done extraordinary work in this area is Harald Welte. His signature is also visible all over the OpenMoko project and the way it actively reaches out to build a strong developer community. We need more people like him and the other OpenMoko developers, and I hope you will take a look at their call for GPL'ed wireless drivers and application developers.

We also need to get more of the devices into the hands of capable developers. This is what Armijn Hemel of gpl-violations.org did during FOSDEM 2007 when he gave a bunch of routers to the OpenWRT project so they would have more devices to work with and set free.

Ultimately freedom is not static. It is a process that involves a lot of work. It is also a differential question: There are steps towards more freedom, which are good, and steps towards less freedom, which cause problems -- if not immediately, then in the future. The choices of which direction to take were recently described by FSFLA as "The fifth freedom."

As a community, we have set the personal computer free to a very large extent. We are not yet as far with embedded devices, but there are first signs of the Free Software community growing into this area.

With the possible exception of the GSM stack, I believe we have good reason to expect 100% Free Software devices in the near future by starting from the most free, although imperfect, options available and setting them free entirely.

Through this effort we'll not only see the Free Software community flourish in this area and we are also likely to see more hardware vendors willing to supply the community and people who value their freedom with such devices.

Eventually it will be possible to enter the store and buy such a device running only Free Software out of the box, which is what I really want. And with projects such as the GPE Palmtop Environment we will be able to use the same software environment on different hardware devices; something that is common on personal computers, and a great advantage.

Working for this goal can serve to strengthen Free Software on the desktop, because integration of the mobile devices with desktop computers is an important issue. With Free Software it could be possible to use the same software on both, possibly in different versions and from different vendors. The result would be seamless integration that proprietary software might not be able to achieve across vendor boundaries.

It seems only a question of time until someone picks up on this and offers the combination of freedom and convenience to people. In the end, by walking forward on the road to embedded freedom, we might end up strengthening Free Software overall.

(The author is initiator and president of the Free Software Foundation Europe (FSFE) and his personal blog is available at the Fellowship of FSFE)

Comments (124 posted)

Page editor: Jonathan Corbet

Security

SQL-Ledger and LedgerSMB: a study in security reporting

Accounting information is the kind of data that most organizations would want to keep private; it is also information that attackers might be most interested in. Because of that, security vulnerabilities in accounting packages require high visibility and prominent announcements so that users can take the appropriate steps to safeguard their data. Two related accounting systems, SQL-Ledger and LedgerSMB provide an interesting contrast in approaches to security reporting.

SQL-Ledger is a GPL-licensed accounting system first released in 1999; it has a large feature set and a sizable number of happy and loyal users. It is a web-based program, written in Perl that uses an SQL database to store the information. The original intent seems to be a system that lived behind a firewall and was not exposed to the Internet; most of the vulnerabilities reported recently have a much reduced impact behind the firewall. In fact, buried at the end of the FAQ, SQL-Ledger recommends using the web server authentication mechanisms (presumably HTTP Basic Auth for Apache) on top of those provided by SQL-Ledger.

SQL-Ledger is tightly controlled by its creator, Dieter Simader, and he has not encouraged a developer community to spring up around the system. This has caused some users to become frustrated with the pace of development; it doesn't help that the suggested way to get features added more quickly is to pay Simader's company to develop them. In addition, the documentation, user forums and wiki are only available to those who pay for them. There is nothing inherently wrong with doing things this way, but it is quite different than the way most GPL projects operate.

The project continued in this manner for quite some time until a reported session hijacking issue was not handled quickly by Simader. Another user mentioned that the issue had been known for a lot longer as they had reported it nearly a year earlier and, though there had been several releases in the interim, no fix had been made. This incident led directly to the September 2006 fork of the SQL-Ledger code as the LedgerSMB (SMB for 'small-medium business') project.

The LedgerSMB developers have created a project that operates the way open source developers expect, with open documentation, a public source code repository and a willingness to accept patches from anyone interested. They have also been doing an informal security audit of the shared codebase and coordinating security releases with SQL-Ledger. They have released a number of detailed vulnerability reports on the Bugtraq mailing list that cover security updates for both projects.

Visiting each project's homepage is very instructive with regards to the security updates. The SQL-Ledger page makes no mention of updates; one must follow the "What's New" link to see the updates and the descriptions make no mention of the security implications of the release. A user could easily be lulled into thinking that "added %00 check for login to trigger an error" is just a run-of-the-mill bug fix rather than a fix for an arbitrary code execution and authentication bypass bug as described in the report.

The LedgerSMB site, on the other hand, has its news listed on the front page and calls the most recent security release (1.1.10) a fix for "a serious security hole." The users and announce mailing lists both have detailed reports about the problem whereas the SQL-Ledger public user mailing list makes no mention of the new release. One presumes and hopes that the users who have purchased support get some kind of notification from DWS Systems (Simader's company), but the non-paying users need to pay close attention to Bugtraq (or the LedgerSMB site).

In many ways, the contrast between the two mirrors the contrast between how open source and proprietary software projects handle security issues. One disseminates the information far and wide while the other treats it as a public relations black eye and obscures it. DWS Systems is presumably trying to protect its income stream but, by doing it in the way it has, it appears to have alienated a segment of its user base which is now directly competing with the company. Had Simader been more responsive to those issues, there very well might not be a competing project. It will be interesting to see which approach works better in the long term or if both thrive equally.

Comments (5 posted)

Brief items

Felten: Too much innovation in the OLPC?

Comments (15 posted)

New vulnerabilities

asterisk: SIP denial of service

Comments (2 posted)

inkscape: format string vulnerabilities

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

libwpd: buffer overflows

Comments (none posted)

lookup-el: insecure temporary file

Comments (none posted)

LSAT: insecure temporary file creation

Comments (none posted)

nas: code execution

Comments (none posted)

openafs: privilege escalation

Comments (none posted)

OpenOffice.org: buffer overflow and command execution

Comments (none posted)

ssh: privilege escalation

Comments (none posted)

webcalendar: missing input sanitizing

Comments (none posted)

Updated vulnerabilities

acroread: multiple vulnerabilities

Comments (1 posted)

amarok: remote code injection

Comments (none posted)

apache: cross-site scripting

Comments (none posted)

bind: denial of service

Comments (none posted)

bluez-utils: hidd vulnerability

Comments (none posted)

bugzilla: multiple vulnerabilities

Comments (none posted)

busybox: insecure password generation

Comments (2 posted)

cpio: arbitrary code execution

Comments (none posted)

vixie-cron: privilege escalation

Comments (1 posted)

cscope: buffer overflows

Comments (none posted)

cscope: buffer overflows

Comments (1 posted)

Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service

Comments (none posted)

dovecot: index cache file handling error

Comments (none posted)

ekiga: format string vulnerability

Comments (none posted)

elinks: arbitrary file access

Comments (none posted)

fail2ban: denial of service

Comments (3 posted)

fetchmail: password disclosure and DOS

Comments (none posted)

ffmpeg: buffer overflows

Comments (2 posted)

freeradius: several vulnerabilities

Comments (none posted)

freetype: integer overflows

Comments (none posted)

gcc: file overwrite vulnerability

Comments (none posted)

gd: buffer overflow

Comments (2 posted)

gdb: buffer overflow

Comments (none posted)

gdm: improper file permissions

Comments (none posted)

gedit: format string vulnerability

Comments (1 posted)

GnuPG: unsigned data injection vulnerability

Comments (none posted)

grip: buffer overflow

Comments (none posted)

gv: stack-based buffer overflow

Comments (none posted)

gzip: multiple vulnerabilities

Comments (1 posted)

horde-kronolith: local file inclusion

Comments (none posted)

imlib2: arbitrary code execution

Comments (none posted)

java: multiple vulnerabilities

Comments (1 posted)

kdelibs: denial of service

Comments (none posted)

kdelibs: kate backup file permission leak

Comments (1 posted)

kdelibs: cross-site scripting

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: denial of service

Comments (1 posted)

kernel: denial of service

Comments (none posted)

kernel: denial of service by memory consumption

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

krb5: uninitialized pointers

Comments (1 posted)

krb5: local privilege escalation

Comments (none posted)

ktorrent: incorrect validation

Comments (1 posted)

libgadu: memory alignment bug

Comments (none posted)

libgtop2: buffer overflow

Comments (none posted)

libmodplug: boundary errors

Comments (none posted)

libpng: buffer overflow

Comments (none posted)

libpng: heap based buffer overflow

Comments (1 posted)

libtiff: buffer overflow

Comments (none posted)

libvncserver: authentication bypass

Comments (none posted)

libxml2 - arbitrary code execution

Comments (none posted)

libxml2: multiple buffer overflows

Comments (none posted)

lynx: arbitrary command execution

Comments (none posted)

mod_jk: stack overflow

Comments (none posted)

mplayer: buffer overflow

Comments (none posted)

mysql: format string bug

Comments (none posted)

MySQL: privilege violations

Comments (none posted)

MySQL: logging bypass

Comments (2 posted)

nbd: arbitrary code execution

Comments (none posted)

ncompress: buffer underflow

Comments (none posted)

openldap: security bypass

Comments (none posted)

OpenSSH: denial of service

Comments (none posted)

openssh: privilege separation issue

Comments (none posted)

openssh: remote denial of service

Comments (none posted)

php: several vulnerabilities

Comments (1 posted)

php: multiple vulnerabilities

Comments (none posted)

php: buffer overflows

Comments (none posted)

phpbb2: missing input sanitizing

Comments (none posted)

phpbb2: multiple vulnerabilities

Comments (none posted)

postgresql: insufficient verification

Comments (none posted)

postgresql: SQL injection

Comments (1 posted)

quake: buffer overflow

Comments (none posted)

rpm: arbitrary code execution

Comments (none posted)

samba: several vulnerabilities

Comments (none posted)

Mozilla: multiple vulnerabilities

Comments (1 posted)

shadow-utils: mailbox creation vulnerability

Comments (none posted)

silc-server: denial of service

Comments (none posted)

slocate: information disclosure

Comments (none posted)

snort: remote arbitrary code execution

Comments (1 posted)

spamassassin: denial of service

Comments (none posted)

sun-jdk: arbitrary code execution

Comments (1 posted)

tcpdump: denial of service

Comments (none posted)

ulogd: buffer overflow

Comments (none posted)

unzip: long file name buffer overflow

Comments (1 posted)

w3c-libwww: possible stack overflow

Comments (1 posted)

wireshark: multiple vulnerabilities

Comments (6 posted)

wordpress: cross-site scripting

Comments (none posted)

xen, qemu: information disclosure

Comments (none posted)

xine: format string vulnerabilities

Comments (none posted)

xine-lib: arbitrary code execution

Comments (none posted)

xine-lib: buffer overflow

Comments (none posted)

xine-lib: buffer overflow

Comments (none posted)

xinit: race condition

Comments (1 posted)

X.org: local privilege escalations

Comments (none posted)

xpdf: buffer overflow

Comments (1 posted)

Page editor: Jonathan Corbet

Kernel development

Brief items

Kernel release status

The current -mm tree is 2.6.21-rc4-mm1. Recent changes to -mm include a new version of the lumpy reclaim patch, some anti-fragmentation work, an updates RSDL scheduler, and the revoke() system call.

There is a 2.6.20.4 stable kernel update in the works as this is written; it may well be released by the time you read it.

For older kernels: 2.6.16.44 was released on March 20 with a fair number of fixes, a couple of which are security-related.

Comments (none posted)

Kernel development news

Quote of the week

-- Linus Torvalds

Comments (none posted)

Toward improved page replacement

To help in the choice of pages to remove, the kernel maintains two big linked lists for each memory zone. The "active" list contains pages which have been recently accessed, while the "inactive" list has those which have not been used in the recent past. When the kernel looks for pages to evict, it will scan through the inactive list, in the theory that the pages least likely to be needed soon are to be found there.

There is an additional complication, though: there are two fundamental types of pages to be found on these lists. "Anonymous" pages are those which are not associated with any files on disk; they are process memory pages. "Page cache" pages, instead, are an in-memory representation of (portions of) files on the disks. A proper balance between anonymous and page cache pages must be maintained, or the system will not perform well. If either type of page is allowed to predominate at the expense of the other, thrashing will result.

The kernel offers a knob called swappiness which controls how this balance is struck. If the system administrator sets a higher value of swappiness, the kernel will allow the page cache to occupy a larger portion of memory. Setting swappiness to a very low value is a way to tell the kernel to keep anonymous pages around at the expense of the page cache. In general, the system can be expected to perform better if page cache pages are reclaimed first; they can often be reclaimed without needing to be written back to disk, and their layout on the disk can make recovery faster should they be needed again. For this reason, the default value for swappiness favors the eviction of page cache pages; anonymous pages will only be targeted when memory pressure becomes relatively severe.

Swappiness clearly affects how the process of scanning pages for eviction candidates is done. If swappiness is low, anonymous pages will simply be passed over. As it turns out, this behavior can lead to performance problems; there may be a lot of anonymous pages which must be scanned over before the kernel finds any page cache pages, which are the ones it was looking for in the first place. It would be nice to avoid all of that extra work, especially since it comes at a time when the system is already under stress.

Rik van Riel has posted a patch which tries to improve this situation. The approach taken is quite simple: the active and inactive lists are each split into two new lists: one pair (active and inactive) for anonymous pages and one pair for page cache pages. With separate lists for the page cache, the kernel can go after those pages without having to iterate over a bunch of uninteresting anonymous pages on the way. The result should be better scalability on larger systems.

The idea is simple, but the patch is reasonably large. Any code which puts pages onto one of the lists must be changed to specify which list is to be used; that requires a number of small changes throughout the memory management and filesystem code. Beyond that, the current patch does not really change how the page reclamation code works, though Rik does note:

There tends to be a lot of sympathy for changes which remove tuning knobs in favor of automatic adaptation within the kernel itself. So if this approach could be made to work, it might well be adopted. Getting system tuning right is hard; it's often better if the computer can figure it out by itself.

Meanwhile, the list-splitting patch, so far, lacks widespread testing or benchmarking. So, at this point, it is difficult to say when (or in what form) this patch will find its way into the mainline.

Comments (17 posted)

fallocate()

Unix systems have not traditionally provided a way for applications to control block allocation. An application on a current Linux kernel has only one way to force allocation: write a stream of data to the relevant portion of the file. This technique works, but it loses one of the advantages of preallocation: letting the kernel do all the work at once and ensure that the blocks are contiguous on disk if possible. Writing useless data to the disk solely for the purpose of forcing block allocation is also wasteful.

The POSIX way of preallocating disk space is the posix_fallocate() system call, defined as:

     int posix_fallocate(int fd, off_t offset, off_t len);

On success, this call will ensure that the application can write up to len bytes to fd starting at the given offset and know that the disk space is there for it.

Linux does not currently have an implementation of posix_fallocate() in the kernel. This patch by Amit Arora may change that situation, however. Amit's patch has been through a couple of rounds of review which have changed the interface considerably; the current form of the proposed system call is:

    long fallocate(int fd, int mode, loff_t offset, loff_t len);

The fd, offset, and len arguments have the same meaning as with posix_fallocate(), making it easy for the C library to implement the standard interface. The additional mode argument changes the way the call operates; normal usage will be to specify FA_ALLOCATE, which causes the requested blocks to be allocated. If, instead, FA_DEALLOCATE is given, the requested block range will be deallocated, allowing an application to punch a hole in the file.

Internally, the system call does not do much of the work; instead, it calls the new fallocate() inode operation. Thus, each filesystem must implement its own fallocate() support. The future plans call for a possible generic implementation for filesystems which lack fallocate() support, but the generic version would almost certainly have to rely on writing zeroes to the file. By pushing the operation into the filesystem itself, the kernel gives the filesystem the opportunity to satisfy the allocation in a more efficient way, without the need to write filler data. Filesystems do need to be sure that applications cannot use fallocate() to read old data from the allocated blocks, though.

For now, filesystem-level support is scarce. There are patches circulating which add fallocate() support to ext4. The XFS filesystem has supported preallocation (through a special ioctl() call) for some time, but will need to be modified to do preallocation through the new inode operation. It's not clear when other filesystems may get native support; the tracking of allocated but unwritten blocks is a significant addition. So, for the near future, the efficiency benefits of fallocate() may be unavailable for most users.

Comments (7 posted)

The 2007 Linux Storage and File Systems Workshop

Fifty members of the Linux storage and file system communities met February 12 and 13 in San Jose, California to give status updates, present new ideas and discuss issues during the 2007 Linux Storage and File Systems Workshop. The workshop was chaired by Ric Wheeler and sponsored by EMC, NetApp, Panasas, Seagate and Oracle.

Day 1: Joint Session

Ric Wheeler opened with an explanation of the basic contract that storage systems make with the user: the complete set of data will be stored, bytes are correct and in order, and raw capacity is utilized as completely as possible. It is so simple that it seems that there should be no open issues, right?

Today, this contract is met most of the time but Ric posed a number of questions. How do we validate that no files have been lost? How do we verify that the bytes are correctly stored? How can we utilize disks efficiently for small files? How do errors get communicated between the layers?

Through the course of the next two days some of these questions were discussed, others were raised and a few ideas proposed. Continue reading for the details.

Ext4 Status Update

Mingming Cao gave a status update on ext4, the recent fork of the ext3 file system. The primary goal of the fork was the move to 48-bit block numbers; this change allows the file system to support up to 1024 petabytes of storage. This feature was originally designed to be merged into ext3, but was seen as too disruptive. The patch is also built on top of the new extents system. Support for greater than 32K directory entries will also be merged into ext4.

On top of these changes a number of ext3 options will be enabled by default including: directory indexing which improves file access for large directories, "resize inodes" which reserve space in the block group descriptor for online growing, and 256-byte inodes. Ext3 users can use these features today with a command like:

    mkfs.ext3 -I 256 -O resize_inode dir_index /dev/device

A number of other features are also being considered for inclusion into ext4 and have been posted on the list as RFCs. This includes a patch that will add nanosecond timestamps and the creation of persistent file allocations, which will be similar to posix_fallocate() but won't waste time writing zeros to the disk.

Ext4 currently stores a limited number of extended attributes in-inode and has space for one additional block of extended attribute data, but this may not be enough to satisfy xattr-hungry applications. For example, Samba needs additional space to support Vista's heavy use of ACLs, and eCryptFS can store arbitrarily large keys in extended attributes. This led everyone to the conclusion that data needs to be collected on how extended attributes are being used to help developers decide how to best implement them. Until larger extended attributes are supported, application developers need to pay attention to the limits that exist on current file systems e.g. one block on ext3 and 64K on XFS.

Online shrinking and growing was briefly discussed and it was suggested that online defragmentation, which is a planned feature, will be the first step toward online shrinking. A bigger issue however is storage management and Ted Ts'o suggested that the Linux file system community can learn from ZFS on how to create easy to manage systems. Christoph Hellwig sees the disk management issue as being a user space problem that can be solved with kernel hooks and sees ZFS as a layering violation. Either way it is clear that disk management should be improved.

The fsck Problem

Zach Brown and Valerie Henson were slated to speak on the topic of file system repair. While Val booted her laptop, she introduced us to the latest fashion: laptop rhinestones, a great discussion piece if you are waiting on a fsck. If Val's estimates for fsck time in 2013 come true, having a way to pass the time will become very important.

Val presented an estimate of 2013 fsck times. She first measured a fsck of her 37GB /home partition (with 21GB in use) which took 7.5 minutes and read 1.3GB of file system data. Next, she used projections of disk technology from Seagate to estimate the time to fsck a circa-2013 home partition, which will be 16 times larger. Although 2013 disks will have a five-fold bandwidth increase, seek times will only improve about 1.2 times (to 10ms) leading to an increase in fsck time from about 8 minutes to 80 minutes! The primary reason for long fscks is seek latency, since fsck spends most of its time seeking over the disk discovering and fetching dynamic file system data like directory entries, indirect blocks and extents.

Reducing seeks and avoiding the seek latency punishment is key to reducing fsck times. Val suggested one solution would be keeping a bitmap on disk that tracks the blocks that contain file system metadata; this would allow for reading all data in a single arm sweep. This optimization, in the best case, would make a single sequential sweep over the disk and, on the future disk, reading all file system metadata would only take around 134 seconds, a large improvement over 80 minutes. A full explanation of the findings and possible solutions can be found in the paper Repair-Driven File System Design [PDF]. Also, Val announced that she is working full time on a file system called chunkfs [PDF] that will make speed and ease of repair a primary design goal.

Zach Brown presented some blktrace output from e2fsck. The outcome of the trace is that, while the disk can stream data at 26 Mb/s, fsck is achieving only 12 Mb/s. This situation could be improved to some degree without on-disk layout changes if the developers had a vectorized I/O call. Zach explained that in many cases you know the block locations that you need, but with the current API you can only read one at a time.

A vectorized read would take a number of buffers and a list of blocks to read as arguments. Then the application could submit all of the reads at once. Such a system call could save a significant amount of time since the I/O scheduler can reorder requests to minimize seeks and merge requests that are nearby. Also, reads to blocks that are located on different disks could be parallelized. Although a vectorized read could speed up the fsck eventually file system layout changes will be needed to make fsck faster.

libata: bringing the ATA community together

Jeff Garzik gave an update on the progress of libata, the in-kernel library to support ATA hosts and devices. He first presented the ATAPI/SATA features that libata now supports including: PATA+C/H/S, NCQ, FUA, SCSI SAT, and CompactFlash. The growing support for parallel ATA (PATA) drives in libata will eventually deprecate the IDE driver; Fedora developers are helping to accelerate testing and adoption of the libata PATA code by disabling the IDE driver in Fedora 7 test 1.

Native Command Queuing (NCQ) is a new command protocol introduced in the SATA II extensions and is now supported under libata. With NCQ the host can have multiple outstanding requests on the drive at once. The drive can reorder and reschedule these requests to improve disk performance. A useful feature of NCQ drives is the force unit access (FUA) bit which will ensure the data, in write commands with this bit set, will be written to disk before returning success. This has the potential of enabling the kernel to have both synchronous and non-synchronous commands in flight. There was a recent discussion about both NCQ FUA and SATA FUA in libata on the linux-ide mailing list.

Jeff briefly discussed libata's support for SCSI ATA translation (SAT) which lets an ATA device appear to be a SCSI device to the system. The motivation for this translation is the reuse of error handling and support for distribution installers which already know how to handle SCSI devices.

There are also a number of items slated as future work for libata. Many drivers need better suspend/resume support and the driver API is due for a sane initialization model using a allocate/register/unallocate/free system and "Greg blessed" kobjects. Currently libata is written under the SCSI layer and debate continues on how to restructure libata to minimize or eliminate its SCSI dependence. Error handling has been substantially improved by Tejun Heo and his changes are now in mainline. If you have had issues with SATA or libata error handling, try an updated kernel to see if those issues have been resolved. Tejun and others continue to add features and tune the libata stack.

Communication Breakdown: I/O and File Systems

During the morning a number of conversations sprung up about communication between I/O and file systems. A hot topic was getting information from the block layer about non-retryable errors that affect an entire range of bytes and passing that data up to user space. There are situations when retries are happening on a large range of bytes even when the I/O layer knows that an entire range of blocks are missing or bad.

A "pipe" abstraction was discussed to communicate data on byte ranges that are currently in error, under performance strain (because of a RAID5 disk failure), or temporarily unplugged. If a file system were aware of ranges that are currently handling a recoverable error, have unrecoverable errors or are temporarily slow, it may be able to handle the situation more gracefully.

File systems currently do not receive unplug events and handling unplug situations can be tricky. For example, if a fibre channel disk is pulled for a moment and plugged back in it may be down for only 30 seconds but how should the file system handle the situation? Ext3 currently remounts the entire file system as read only. XFS has a configurable timeout for fibre channel disks that must be reached before it sends an EIO error. And what should be done with USB drives that are unplugged? Should the file system save state and hope the device gets plugged back in? How long should it wait and should it still work if it is plugged into a different hub? All of these questions were raised but there are no clear answers.

The Filesystems Track

The workshop split into different tracks; your author decided to follow the one dedicated to filesystems.

Security Attributes

Why Linux Sucks for Stacking

Josef Sipek, Unionfs maintainer, went over some of the issues involved with stacking file systems under Linux. A stacking file system, like Unionfs, provides an alternative view of a lower file system. For example, Unionfs takes a number of mounted directories, which could be NFS/ext3/etc, as arguments at mount time and merges their name space.

The big unsolved issue with stacking file systems is handling modifications to the lower file systems in the stack. Several people suggested that leaving the lower file system available to the user is just broken and that by default the lower layers should only be mounted internally.

The new fs/stack.c file was discussed too. This file currently contains a simple inode copy routines that is used by Unionfs and eCryptfs, but in the future more stackable file system routines should be pushed to this file.

Future work for Unionfs includes getting it working under lockdep and additional experimentation with an on-disk format. The on-disk format for Unionfs is currently under development; it will store white-out files (representing files which have been deleted by a user but which still exist on the lower-level filesystems) and persistent Unionfs inode data.

B-trees for a Shadowed FS

Many file systems use B-trees to represent files and directories. These structures keep data sorted, are balanced, and allow for insertion and deletion in logarithmic time. However, there are difficulties in using them with shadowing. Ohad Rodeh presented his approach to using b-trees and shadowing in an object storage device, but the methods are general and useful for any application.

Shadowing may also be called copy-on-write (COW); the basic idea is that when a write is made the block is read into memory, modified, and written to a new location on disk. Then the tree is recursively updated starting at the child and using COW until the root node is atomically updated. In this way the data is never in an inconsistent state; if the system crashes before the root node is updated then the write is lost but the previous contents remain intact.

Replicating the details of his presentation would be a wasted effort as his paper, B-trees, Shadowing and Clones [PDF], is well written and easy to read. Enjoy!

eXplode the code

Storage systems have a simple and important contract to keep: given user data they must save that data to disk without loss or corruption even in the face of system crashes. Can Sar gave an overview of eXplode [PDF], a systematic approach to finding bugs in storage systems.

eXplode systematically explores all possible choices that can be made at each choice point in the code to make low-probability events, or corner cases, just as probable as the main running path. And it does this exploration on a real running system with minimal modifications.

This system has the advantage of being conceptually simple and very effective. Bugs were found in every major Linux file system, including a fsync bug that can cause data corruption on ext2. This bug can be produced by doing the following: create a new file, B, which recycles an indirect block from a recently truncated file, A, then call fsync on file B and crash the system before file A's truncate gets to disk. There is now inconsistent data on disk and when e2fsck tries to fix the inconsistency it corrupts file B's data. A discussion of the bug has been started on the linux-fsdevel mailing list.

NFS

The second day of the file systems track started with a discussion of an NFS race. The race appears when a client opens up a file between two writes that occur during the same second. The client that just opened the file will be unaware of the second write and will keep an out-of-date version of the file in cache. To fix the problem, a "change" attribute was suggested. This number would be consistent across reboots, unit-less and would increment on every write.

In general everyone agreed that a change attribute is the right solution, however Val Henson pointed out that implementing this on legacy file systems will be expensive and will require on disk format changes.

Discussion then turned to NSFv4 access control lists (ACLs). Trond Myklebust said they are becoming a standard and Linux should support them. Andreas Gruenbacher is working on patches to add NFSv4 support to Linux but currently only ext3 is supported; more information can be found on the Native NFSv4 ACLs on Linux page. A possibly difficult issue will be mapping current POSIX ACLs to NFSv4 ACLs, but a draft document, Mapping Between NFSv4 and Posix Draft ACLs, lays out a mapping scheme.

GFS Updates

Steven Whitehouse gave an overview of the recent changes in the Global File System 2 (GFS2), a cluster file system where a number of peers share access to the storage device. The important changes include a new journal layout that can support mmap(), splice() and other system calls on journaled files, page cache level locking, readpages() and partial writepages() support, and ext3 standard ioctls lsattr and chattr.

readdir() was discussed at some length, particularly the ways in which it is broken. A directory insert on GFS2 may cause a reorder of the extensible hash structure GFS2 uses for directories. In order to support readdir() every hash chain must be sorted. The audience generally agreed that readdir() is difficult to implement and Ted Ts'o suggested that someone should try to go through committee to get telldir/seekdir/readdir fixed or eliminated.

OCFS2

A brief OCFS2 status report was given by Mark Fasheh. Like GFS2, OCFS2 is a cluster file system, designed to share a file system across nodes in a cluster. The current development focus is on adding features, as the basic file system features are working well.

After the status update the audience asked a few questions. The most requested OCFS2 feature is forced unmount and several people suggested that this should be a future virtual file system (vfs) feature. Mark also said that users really enjoy the easy setup of OCFS2 and the ability to use it as a local file system. A performance hot button for OCFS2 are the large inodes and occupy an entire block.

In the future Mark would like to mix extent and extended attribute data in-inode to utilize all of the available space. However, as the audience pointed out, this optimization can lead to some complex code. In the future Mark would also like to move to GFS's distribute lock manager.

DualFS: A New Journaling File System for Linux

DualFS is a file system by Juan Piernas that separates data and meta data into separate file systems. The on-disk format for the data disk is similar to ext2 without meta-data blocks. The meta data file system is a log file system, a design that allows for very fast writes since they are always made at the head of the log which reduces expensive seeks. A few performance numbers were presented; under a number of micro- and macro-benchmarks DualFS performs better than other Linux journaling file systems. In its current form, DualFS uses separate partitions for data and metadata, forcing the user to answer a difficult question: how much metadata do I expect to have?

More information, including performance comparisons, can be found on the DualFS LKML announcement and the project homepage. The currently available code is a patch on top of 2.4.19 and can be found on SourceForge.

pNFS Object Storage Driver

Benny Halevy gave an overview of pNFS (parallel NFS), which is part of the IETF NFSv4.1 draft and tries to solve the single server performance bottleneck of NFS storage systems. pNFS is a mechanism for an NFS client to talk directly to a disk device without sending requests through the NFS server, fanning the storage system out to the number of SAN devices. There are many proprietary systems that do a similar thing including EMC's High Road, IBM's TotalStorage SAN, SGI's CXFS and Sun's QFS. Having an open protocol would be a good thing.

However, Jeff Garzik was skeptical of including pNFS in the NFSv4.1 draft particularly because to support pNFS the kernel will need to provide implementations of all three access protocols: file storage, object storage and block storage. This will add significant complexity to the Linux NFSv4 implementation.

Benny explained that the pNFS implementation in Linux is modular to support multiple layout-type specific drivers which are optional. Each layout driver dynamically registers itself using its layout type and the NFS client calls it across a well-defined API. Support for specific layout types is optional. In the absence of a layout driver for some specific layout type the NFS client falls back to doing I/O through the server.

After this overview Benny turned to the topic of OSDs, or object based storage devices. These devices provide a more abstract view of the disk than the classic "array of blocks" abstraction seen in todays disks. Instead of blocks, objects are the basic unit of an OSD, and each object contains both meta-data and data. The disk manages the allocation of the bytes on disk and presents the object data as a contiguous array to the system. Having this abstraction in hardware would make file system implementation much simpler. To support OSDs in Linux Benny and others are working to get bi-directional SCSI command support into the Kernel and support for variable length command descriptor blocks (CDBs).

Hybrid Disks

Hybrid disks with an NVCache (flash memory) will be in consumers' hands soon. Timothy Bisson gave an overview of this new technology. The NVCache will have 128-256Mb of non-volatile flash memory that the disk can manage as a cache (unpinned) or the operating system can manage by pinning specified blocks to the non-volatile memory. This technology can reduce power consumption or increase disk performance.

To reduce power consumption the block layer can enable the NVCache Power Mode, which tells the disk to redirect writes to the NVCache, reducing disk spin-up operations. In this mode the 10 minute writeback threshold of Linux laptop mode can be removed. Another strategy is to pin all file system metadata in the NVCache, but spin-ups will still occur on non-metadata reads. An open question is how this pinning should be managed when two or more file systems are using the same disk.

Performance can be increased by using the NVCache as a cache for writes requiring a long seek. In this mode the block layer would pin the target blocks ensuring a write to the cache instead of incurring the expensive seek. Also, a file system can use the NVCache to store its journal and boot files for additional performance and reduced system start-up time.

If Linux developers decide to manage the NVCache there are many open questions. Which layer should manage the NVCache? The file system or block layer? And what type of API should be created to leverage the cache? Another big question is how much punishment can these caches take? According to Timothy it takes about a year (using a desktop workload) to a fry the cache if you are using it as a write cache.

Scaling Linux to Petabytes

Sage Weil presented Ceph, a network file system that is designed to scale to petabytes of storage. Ceph is based on a network of object based storage devices and complete copies of each object is distributed across multiple nodes using an algorithm called CRUSH. This distribution makes it possible for nodes to be added and removed from the system dynamically. More information on the design and implementation can be found on the Ceph homepage

Conclusion

The workshop concluded with the general consensus that bringing together SATA, SCSI and file system people was a good idea and that the status updates and conversations were useful. However, the workshop was a bit too large for code discussion and more targeted workshops will need to be held to workout the details of some of the issues discussed at LSF'07. Topics for future workshops include virtual memory and file system issues and extensions that are needed to the VFS.

Comments (52 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 2.6.21-rc4. (March 16, 2007)

• Andrew Morton: 2.6.21-rc4-mm1. (March 20, 2007)

• Adrian Bunk: Linux 2.6.16.44. (March 21, 2007)

• Adrian Bunk: Linux 2.6.16.44-rc2. (March 19, 2007)

Core kernel code

• Davide Libenzi: signalfd/timerfd/asyncfd v5 - asyncfd core .... (March 15, 2007)

• Davide Libenzi: signalfd/timerfd/asyncfd v5 - timerfd core .... (March 15, 2007)

• Davide Libenzi: signalfd/timerfd/asyncfd v5 - signalfd core .... (March 15, 2007)

• Davide Libenzi: signalfd/timerfd/asyncfd v5 - KAIO asyncfd support (example/maybe-broken) .... (March 15, 2007)

• Davide Libenzi: eventfd+KAIO - eventfd core .... (March 15, 2007)

• Con Kolivas: RSDL cpu scheduler for 2.6.21-rc3-mm2. (March 16, 2007)

• Con Kolivas: RSDL v0.31. (March 19, 2007)

• Con Kolivas: sched: rsdl improvements. (March 21, 2007)

• Venkatesh Pallipadi: Add not_critical_when_idle timer. (March 19, 2007)

Development tools

• Junio C Hamano: GIT 1.5.0.5. (March 19, 2007)

• Josef Sipek: Guilt v0.23. (March 21, 2007)

• Keiichi KII: [RFC][PATCH -mm take3 0/6][resend] proposal for dynamic configurable netconsole. (March 20, 2007)

Device drivers

• Nicolas Boichat: Apple SMC driver (hardware monitoring and control). (March 19, 2007)

• Rodolfo Giometti: LinuxPPS: Pulse per Second support for Linux. (March 21, 2007)

Filesystems and block I/O

• Edward Shishkin: Reiser4: Transparent compression support. Further development and compatibility.. (March 15, 2007)

• Amit K. Arora: sys_fallocate() system call. (March 19, 2007)

• Amit K. Arora: Persistent preallocation in ext4 (using fallocate inode op). (March 21, 2007)

• Nick Piggin: Announce: new-aops-1 for 2.6.21-rc3. (March 19, 2007)

Janitorial

• Christoph Hellwig: move die notifier handling to common code. (March 19, 2007)

Memory management

• Fengguang Wu: Adaptive readahead update. (March 16, 2007)

• Mel Gorman: Bias the location of pages freed for min_free_kbytes in the same MAX_ORDER_NR_PAGES blocks. (March 19, 2007)

• Rik van Riel: split file and anonymous page queues. (March 19, 2007)

• Rik van Riel: split file and anonymous page queues #2. (March 20, 2007)

• Rik van Riel: split file and anonymous page queues #3. (March 21, 2007)

• Peter Zijlstra: per device dirty throttling. (March 19, 2007)

• Adam Litke: [RFC] hugetlb: pagetable_operations API (V2). (March 20, 2007)

• Christoph Lameter: Quicklists for page table pages V3. (March 20, 2007)

Networking

• David Howells: [RFC] AF_RXRPC socket family implementation [try #2]. (March 19, 2007)

• David Howells: [RFC] AF_RXRPC socket family implementation [try #3]. (March 21, 2007)

• Patrick McHardy: : ktime clocksource + hrtimer. (March 19, 2007)

• QIlpo Jervinen: LOST marking rewrite. (March 19, 2007)

Architecture-specific

• Steven Rostedt: Make common x86 arch area for i386 and x86_64 - Take 3. (March 19, 2007)

Security-related

• Tasos Parisinos: crypto API: RSA algorithm patch (kernel version 2.6.20.1). (March 19, 2007)

Miscellaneous

• Aneesh Kumar K.V: e2fsprogs: Add ext4migrate. (March 19, 2007)

• Dave Jones: new list: Fedora-kernel-list.. (March 21, 2007)

Page editor: Jonathan Corbet

Distributions

News and Editorials

On the road to Slackware 12

Thu Nov 9 18:16:50 CST 2006
Q: Hey, what's the deal with -current?
A: Renovations are underway to the toolchain (gcc, glibc, binutils, etc),
       and it makes little sense to update what is essentially Slackware 11.0
       only to do the work all over again once the new toolchain is ready.
       In addition, these things aren't going as smoothly as anticipated.
       I'd like to put the NPTL version of glibc into /lib and the LinuxThreads
       version into /lib/obsolete/linuxthreads (since some old binaries are
       going to need them), but doing this prevents the use of a 2.4 kernel.
       Perhaps it's finally time to drop support for Linux 2.4? Personally,
       I'd rather not as 2.4 is more forgiving of flaky hardware and thus
       tends to get better uptimes (at least on the servers I run ;-).
       Comments about this issue are welcomed.
       glibc-2.5 has also been having some problems with locale support here
       that need to be investigated and dealt with. I'd rather base the glibc
       in Slackware on an official glibc release, but using the development
       repo is also something under (slight) consideration if it works
       better.

That changed this week with this lengthy changelog notice going back to this November 20th entry.

Mon Nov 20 14:31:25 CST 2006
Thanks to everyone who provided valuable feedback on the question below.  It
looks as if Slackware -current (future 12.0?) is going to charge into 2.6-only
territory, but it will be a conservative "charge".  :-)  The overwhelming
consensus is that the 2.6 series is now more than stable enough for production
use.  Some folks expressed concern over the loss of Linux 2.4.x compatibility,
but they were a definite minority.  Some suggested maintaining two -current
branches -- one following 2.4 and the other 2.6.  The solution that'll be
taken concerning 2.4.x will be to make Slackware 11.0 better maintained than
simply security updates.  It should see some other non-security updates as
well (perhaps the introduction of an /updates directory?), and will be a long
lived OS for those who swear by the stability of the 2.4.x kernel series.
Meanwhile, 2.4.x compatibility features (such as the, er, mess? going on in
the startup scripts) will be steadily eliminated in -current to focus on the
best possible 2.6.x support.  With a lot of work, we should be able to make
the next Slackware release an excellent choice for both servers and desktops.
Again -- thanks for all the input!  :-)

So what's new for the next Slackware release, besides a 2.6 kernel? Many packages have been upgraded. Several packages have been added to go along with the modular X.org upgrade. Python 2.5 is in along with newer versions of Ruby, Samba and several version control systems (git, Subversion, Mercurial). The init scripts have been split into a new package to go along with an upgrade to sysvinit-2.86. The current kernel is Linux 2.6.18.8 and KDE 3.5.6 is in. All in all there's been quite a bit of removal of old cruft, shiny new packages added, many things split and rearranged. From the March 17th entry:

Sat Mar 17 19:14:35 CDT 2007
  Happy St. Patrick's Day!  :-)
  This is more-or-less stable (functionally), but there's still a lot of
  package splitting and other rearranging and adding to be done, but it's
  time for the Slackware community to see how far we've gotten.  If the
  luck o' the Irish is with us, it'll be a fairly short alpha/beta/rc
  period from here.  Well, have fun!

Comments (1 posted)

New Releases

Debian Installer etch RC2 released

Full Story (comments: none)

Foresight Linux 1.1 released

Comments (none posted)

openSUSE 10.3 Alpha2 Release

Full Story (comments: none)

Slightly changed openSUSE 10.2 ISOs released

Full Story (comments: none)

Distribution News

Call for votes for the Debian Project Leader Elections 2007

Full Story (comments: none)

Gentoo code of conduct adopted

Full Story (comments: 4)

openSUSE @ FOSDEM 2007 video recordings online

Full Story (comments: none)

Ubuntu announcements

Daniel Holbach looks at using tags in Malone (the bug tracker), especially the 'bitesize' tag.

Ben Collins covers the kernel team bug triage policy. "This policy is meant to work in conjunction with current bug triaging policies. This is in the hopes that the bug flow to the kernel team will be easier, and allow community to better help the team with the large amount of bug reports we receive."

Comments (none posted)

Ubuntu 5.10 reaches end-of-life on April 13th 2007

Full Story (comments: none)

Distribution Newsletters

Gentoo Weekly Newsletter

Comments (none posted)

Mandriva : Cooker : the Inside Man VI

Comments (none posted)

Ubuntu Weekly News: Issue #32

Full Story (comments: none)

DistroWatch Weekly, Issue 194