Leading items

Not just IBM's problem

The Ottawa Kernel Summit managed to get through its agenda with almost no discussion of SCO, despite the fact that SCO had just told those developers that they need to purchase a binary licence in order to be able to run their own code. The IBM employees present were, without exception, entirely quiet on the whole situation - but they also radiated a sort of calm confidence that was impossible to miss. In general, at both the Summit and OLS, it was difficult to find anybody who was genuinely worried about SCO and its actions.

There are exceptions, of course, but it appears that much of the Linux community has come to the conclusion that IBM's lawyers will make the whole SCO problem go away. There are certainly reasons to feel that way. IBM's legal team inspires fear in many, especially when intellectual property issues are at stake. And IBM's interests align reasonably well with the wider community's interests in this case. IBM wants a commodity operating system platform which is free of external proprietary interests; with such a platform, IBM is well positioned to sell its hardware, services, and proprietary add-ons. So it would suit IBM to see SCO defeated in a manner that would strongly discourage any other enterprising bandits from attempting the same sort of heist.

Still, IBM is not the Linux community, and its interests are not exactly the same. It is conceivable (though unlikely) that IBM could eventually reach a settlement with SCO that ends the case, but leaves a number of users and developers in an uncertain legal position. And IBM has no particular incentive to defend Linux users against any future copyrights suits filed by SCO - especially if the victims are not IBM customers.

We all have high hopes for IBM's defense in this case. But the Linux community has a problem with SCO that is different from IBM's problem, and expecting IBM to fix it for us could prove to be a big mistake. We need to find ways of ending SCO's constant attacks on Linux developers and users. SCO's attempt to hijack and put a tax on Linux cannot be allowed to succeed.

The challenges which have quieted SCO in Germany (and, with luck, will have the same effect in Australia) show one way forward. SCO's attacks on Linux are slanderous, and its attacks on Linux developers head toward libel. The company needs to be made to put up its evidence or back down from its claims. This especially needs to happen in the U.S.

SCO also continues to distribute the 2.4 kernel - get your copy here. LWN downloaded a copy of this kernel on July 30, 2003; the date on SCO's server is May 9. This kernel lacks some of the disputed developments (e.g. RCU), but SCO has made it clear that it objects to code in all of the 2.4 kernels. So what we have here is SCO distributing code over which it claims proprietary rights as a derived product containing a great deal of uncontested, GPL-licensed code. That is, of course, a clear violation of the GPL. One can only hope that SCO's attitude toward copyright and licensing will come up at the IBM trial. But the situation would certainly be helped if one or more developers with copyrighted code in the kernel would bring an infringement case against SCO. That would be a counteroffensive which would attract some attention.

SCO is not just IBM's problem; the company has made it clear that it plans to cast its legal net far more widely than that. So it is important that IBM not be SCO's only problem. If we sit back and wait for IBM to clean up this mess, we may not get the thorough and complete job that we truly need.

Comments (10 posted)

Kroupware Kompleted

[This article was contributed by Joe 'Zonker' Brockmeier]

The Kroupware Project, announced last October, has been finished and released as Kolab. The project began last September when three companies, Erfrakon, Intevation GmbH and Klarälvdalens Datakonsult won a bid to create a free software groupware solution for Germany's federal agency for IT security, the Bundesamt für Sicherheit in der Informationstechnik (BSI). The goal was to create an end-to-end groupware solution, both client-side and server-side software, entirely from free software.

Instead of starting from scratch, which is where many free software projects fail, Kroupware was based on existing projects. The Kolab Server is made up of existing projects like Apache, Postfix, OpenLDAP and the Simple Authentication and Security Layer (SASL). The KDE Kolab client is made up of several existing programs for KDE, including KMail, Kontact and KDE PIM. Another project is underway to create an all-in-one groupware client for KDE called Kontact and work is being done on a webmail client as well.

The suite supports e-mail (POP3 and IMAP4), calendaring, global and private addressbooks, vacation notices, notes, synchronization with Palm OS devices, task lists and a number of other features that companies and organizations are looking for in a groupware suite. The server is managed using a Web-based interface. Almost all of the protocols used, with the notable exception of Palm's HotSync Protocol, are Internet Engineering Task Force (IETF) standards.

The project isn't aimed solely at any Linux distribution, or Linux alone for that matter. The Kolab server should run on just about any Unix-like system that runs Apache, Postfix, OpenLDAP and the other components that make up the server. On the client side, Windows users can fully access the Kolab Server groupware functions using Outlook and the Bynari Insight Connector Plugin. Note that the Bynari software is proprietary, but there is work being done by a third-party to create a free software connector. Other Windows groupware clients may work as well if an organization prefers to run Windows, or a mix of Windows and Linux, on the desktop.

It's good to see a fully open source, end-to-end, groupware solution being made available. Particularly one that allows Windows users and Linux users to share the same groupware server and allow companies to deploy Linux in some parts of their business without having to make an all-or-nothing commitment.

It will be interesting to see whether vendors are quick to embrace Kolab after developing their own groupware solutions. A single, standard, open source groupware solution could do a lot to boost Linux though it might hinder sales of products like Openexchange Server or Ximian Connector.

This is yet another piece of the puzzle that could allow Linux to gain significant share of the desktop market. At the moment, installation and configuration of the suite is still a bit rough for companies who are used to buying pre-packaged solutions. However, it should not be difficult for Linux distributors or other vendors to smooth over the installation process a bit and create a value-added product based on Kolab. And, of course, work continues on Kolab even though the Kroupware Project has been declared "complete." It seems as if legal challenges and perception are now the greatest obstacles to adoption of Linux on the desktop.

Comments (1 posted)

Trip report: the Ottawa Linux Symposium

The 2003 Ottawa Linux Symposium has run its course. Once again, OLS has established itself as the premier North American Linux developers' conference. A solid roster of speakers delivered four days' worth of intensely technical talks on where Linux development (and kernel development in particular) is headed. It is always nice to attend an event where the talk is technical and nobody is trying to sell you anything.

Your editor was not able to attend all of the presentations, of course, and did not write up every one he attended. Below, however, you'll find quick summaries of several of the more interesting talks given at OLS this year. Those looking for all the details can find them in the OLS 2003 Proceedings.

In response to popular demand (i.e. somebody actually asked), I have also put up the slides for my talk on porting drivers to the new kernel. Giving this sort of talk at OLS is a unique challenge, given that, for any topic, there's certain to be at least one person in the audience who knows way more than the speaker. Happily, the hecklers were kind...

Thanks are due to the OLS organizers for putting together another high-quality event, for the event's sponsors for helping making it possible, and to all the speakers for presenting their work.

Ugly ducklings - resurrecting unmaintained code

Dave Jone's talk covered the work he has done in 2.5 to fix up the MTRR and AGPGART drivers. Dave has observed a common sort of lifecycle for drivers. A driver is initially written for a specific vendor's widget. Over time, it is extended to support compatible widgets from other vendors, then slightly different widgets from yet other vendors. The number of special cases increases. Meanwhile, the maintainer gets bored and moves on. Eventually you end up with thousands of lines of spaghetti which is unmaintainable.

Dave's approach to such drivers includes splitting code into separate files by vendor (usually) and separating code which should never have been run together in the first place. "Useless abstractions" can be cleaned out. Eventually you end up with a code body which is sufficiently clean and understandable that it can be updated for modern hardware, new features, etc. But one should not underestimate the amount of work it can take to get there.

Large projects and bugzilla

Luis Villa discussed his experience working as GNOME's quality assurance person. He has, he estimates, read some 30,000 bug reports over the last few years. The experience appears to not have warped him too badly, though such things can take years to show.

He is, as one might expect, a strong proponent of organized bug tracking. A good QA system, he says, makes writing software easier (through reductions in mailing list traffic, among other things), eases the release process, makes the software better, and, important, makes writing software more fun.

The key point of the talk, perhaps, was that QA people have less power in free software projects than they do in the proprietary world. That makes it even more imperative that they not forget that they are providing a service to the developers, and that they have to understand what the developers need from them. Filtering ("triage") is especially important; developers should not have to deal directly with the full flow of bug reports. If the bug trackers are providing the sort of bug filtering and categorization that the hackers need, all will be well. Otherwise the bug tracking system will degenerate into an unused pile of old information.

Interactive kernel performance

Robert Love's talk covered work done in the 2.5 kernel to improve interactive performance. What's interactive? Robert takes a wide view; interactive applications are "everything except Oracle." The topics covered will be familiar to LWN Kernel Page readers; they include the anticipatory disk scheduler, the O(1) process scheduler, the preemptible kernel and other low-latency work, etc. In his opinion, the single most important bit of work to go in this time around (with regard to interactive performance) is the anticipatory scheduler.

udev - devfs done right

Greg Kroah-Hartman described udev, his user-space devfs replacement (covered here last April) in a standing room only session. Progress on udev has been slow since April (Greg has been busy with other stuff), but some things have happened. There is now a set of configuration files to allow the user to specify how device naming and permissions should be handled; it uses various attributes of a device (it's serial number, label, position in the bus topology, etc.) to figure out what the system administrator would like it to be called. Future versions will use the "tdb" database to track devices and handle persistent naming.

Future work includes changing udev to run as a daemon process; this change is required to properly handle out-of-order hotplug events. For those wanting to experiment with it, the udev code can be found on kernel.org in /pub/linux/utils/kernel/hotplug/.

Why doesn't my laptop suspend?

Pat Mochel's talk was on power management, or "why doesn't my laptop suspend?" He asked for a show of hands: how many in the audience have laptops? Well, this is OLS, so most of the attendees raised their hands. How many of those suspend correctly? Most hands went down.

Older, APM-based machines would handle suspend operations entirely in the firmware; it "just worked" for most people. Newer ACPI systems, however, push the suspend task into the software; this is evidently an improvement. And Linux software has not yet caught up with that. ACPI support is pretty much in place, but that is the easy part. The harder part is working power management support into all the drivers, coming up with a reliable way of suspending the system, and implementing a reasonable user-level interface to it all.

Much of this work has been done for 2.5; it still languishes in Pat's tree, however, and has not been merged into the mainline. The changes include a new set of driver power management methods; there is also a cleaned up software suspend subsystem with a safer snapshot mechanism and the ability to write the system image to any persistent media.

Pat has said that he will finish this work, though it was clear that he would appreciate some help from other developers as well. His hope is to get the work merged by August 20. Should he be successful, appreciative users should send him a birthday present ("small, unmarked bills") on that day.

Toward an O(1) VM

Rik van Riel discussed recent work with virtual memory management; the talk covered page replacement strategies, the reverse mapping VM, etc. The key point of his talk, however, was this: by many metrics relevent to VM, our newer, "faster" machines are actually slower. Over the years, the time required to perform tasks like reading an entire disk, or writing a system's entire RAM to disk, has gone up by a couple of orders of magnitude or more. Much of the previous century's research into VM is losing its relevance as memory and disk sizes increases faster then the transfer speeds between them. VM hackers increasingly find themselves having to make things up as they go.

Integrating DMA into the device model

James Bottomley discussed the new generic DMA layer; these functions have been documented in this article, which is part of the LWN driver porting series. What was new in this talk is James's discussion of where the DMA API needs to go in the future. The current version has no way of returning a failure code from the DMA mapping routines. But failure can happen: a system can run out of I/O memory management unit space, a problem which will be exacerbated in the future as GART hardware is used as a poor man's IOMMU. At some point, that sort of failure must be communicated back to the caller.

Device drivers can provide a DMA mask describing the range of addresses that their devices can handle. But there is no way for the system to pass back a mask saying which addresses the device needs to handle. Better performance can often be maintained when devices are operated in their smaller-memory modes; the system should provide the information that allows those modes to be used when they are applicable. Finally, the current approach to cache coherency needs some work; drivers should be able to find out just how coherency works on the host system. The means by which the CPU and peripherals share DMA buffers needs to be reorganized into a straightforward ownership model; in the current system, it is not always clear who has the right to change a buffer, and that can lead to data corruption.

The party

Your reporter was going to write up the legendary OLS closing party at the Black Thorn, but the whole event has become somewhat fuzzy and difficult to recall. Suffice to say that a lot of fun was had.

Comments (21 posted)

Page editor: Jonathan Corbet
Next page: Security>>