The Ottawa Kernel Summit
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
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
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
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
Comments (10 posted)
[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)
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
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
Comments (1 posted)
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
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
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
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
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
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,
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
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
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
Inside this week's LWN.net Weekly Edition
- Security: Quietly fixing security holes; new vulnerabilities in apache, CGI.pm, others...
- Kernel: Fixing the scheduler; Reiser4; Module unload races.
- Distributions: Linux in Spain, Mandrake and Red Hat betas, Xandros 1.1, SPB-Linux, ScummLinux
- Development: Python 2.3 is out, Perl's Exegesis 6,
New versions of Alsa, PostgreSQL, SAP DB, Mozilla Firebird, PythonCAD,
KDE, GIMP, Qt, HylaFAX, AbiWord, gFTP, SBCL, OProfile.
- Press: The continuing SCO saga, NetWare to support Linux, Unilever Joins OSDL,
Interviews with Galeon developers, Brian Kernighan, Bruce Eckel.
- Announcements: IBM sells cluster to Japan, SuSE teams with SAP,
Bruce Perens at LinuxWorld, Silicon Valley Linux Picn*x12.