|
|
Subscribe / Log in / New account

LWN.net Weekly Edition for August 11, 2005

Interview: Eben Moglen

August 11, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

Attending Linux trade shows is a lot of hassle, particularly when you have to drive a couple of states to make it to the location. However, this is greatly mitigated by the fact that one has the opportunity to speak face to face with some of the more interesting people in the Linux community. This week at Linux World Conference & Expo, I had the chance to speak with Eben Moglen, President and Executive Director of the Software Freedom Law Center. The interview touched on the Software Freedom Law Center, the revision process for the GPL version 3 and several other topics.

LWN: What's the status of the Software Freedom Law Center, what kind of activities are going on, and its funding?

The status is making a law firm is an interesting activity, particularly if you're building a small business on Manhattan island. I've spent more time on real estate and physical details of making it work than I thought we would, but we're successfully housed and we're hiring lawyers and we've been recruiting clients and releasing some press about the clients we've recruited and that process is scaling up, we expect Dan Ravicher my junior partner and I to have at least two more lawyers, maybe three more hired during the next few months and we will be looking to hire some young people, freshly graduating from law school this coming spring and entertaining our first international fellows starting this year.

As for funding, we've received now two rounds of funding from OSDL, which has been acting as our agent for collecting from a number of vendors, they have been gratifyingly reliable in the funding of our firm, and I have no reason to believe that there will be any difficulty. I think the principle that better support for developers is good for business is now firmly in everybody's mind and we have been very graciously entrusted with the task of making that happen.

LWN: A while back, you said something about getting an answer from Linus on the Linux kernel license. Since there is a COPYING file that makes it clear that the kernel is governed under the GPL, where's the uncertainty?

If the kernel is pure GPL, then I think we would all agree that non-GPL, non-free loadable kernel modules represent GPL violations. Nonetheless, we all know that there are a large number of such modules and their existence is tolerated or even to some degree encouraged by the kernel maintainers, and I take that to mean that as an indication that there is some exception for those modules.

The kernel also maintains a technical mechanism, namely the GPL-only symbols and tainting structure, which seems to suggest an API for the connection of non-GPL'ed code to the kernel, which also seems to me a strong indication of the presence of an exception. The difficulty as a lawyer, even a lawyer that is reasonably knowledgeable about these matters, is that I don't understand what the terms of that exception are.

So, say I want to audit a system, say an embedded product, in which I find non-GPL loadable kernel modules present, how do I know whether that fits within an exception which is legitimately available to third parties and when it is not?

Linus has said over the years a number of things about how he would not object to anything that was not in obvious bad taste, or ugly, or awkward or unacceptable and I understood, I think, what he meant at each of those particular times. But it would be helpful in applying an analysis from a lawyer's point of view, and think about the problem.

One very important area is the problem faced by people who make software-controlled radios, which they want to run in systems which make use of the Linux kernel and other GNU and free software. Those parties may feel they're under regulatory orders not to release source code modules, because regulators in Japan and Europe and the United States have all, to differing degrees, made clear to manufacturers of radio transmission hardware that if they allow after-market modification that violates spectrum control regulations they may be in trouble. The Japanese in particular have been very strong in their wording.

So then there are parties in the world who think they are in legal trouble on one side with the regulators if they do release source code for loadable kernel modules that drive their software-controlled radios, and they don't know if they're in legal trouble on the other side if they don't release source code. For those parties, in particular, it would be very helpful if the kernel developers had decided to formalize the nature of their exceptions, and the Free Software Foundation and I have made a few attempts to discuss that matter with kernel developers. I had conversations with Ted Ts'o, I talked to Linus about it and I understood there were some reluctances to clarify, in a full and complete way, what was going on. There may have even been disagreements among kernel developers about that, I wouldn't know. But I continue to think that it would be useful, for a whole variety of people who are trying in good faith to do the very best they can, and who may be navigating some dodgy legal territory, for them to be able to refer to something beyond the COPYING file which -- with all due respect -- I think probably doesn't contain all the terms that are relevant to the use of the kernel.

LWN: So, if the kernel is covered solely by the GPL, you would see proprietary modules as an infringement?

Yes. I think we would all accept that. I think that the degree of interpenetration between kernel modules and the remainder of the kernel is very great, I think it's clear that a kernel with some modules loaded is a "a work" and because any module that is dynamically loaded could be statically linked into the kernel, and because I'm sure that the mere method of linkage is not what determines what violates the GPL, I think it would be very clear analytically that non-GPL loadable kernel modules would violate the license if it's pure GPL.

LWN: Should distributors of proprietary modules then be worried about infringement?

As a matter of fact, I think they are worried about it, and that's why I think that clarifying the license terms would be helpful. If there are no exceptions and that were stated very clearly then they would know that's not the way to do what they're doing. If there are some exceptions available, for example for people who have no legal choice, they'd like to know what those rules are and I'm sure lots of other lawyers around the community would too.

LWN: The Free Software Foundation put out a press release about a year ago saying that the reason that SCO was attacking the Linux kernel and not attacking GNU was because of the FSF copyright assignment policies of the FSF, do you still see it that way, and why is the kernel vulnerable when GNU is not, in that case?

I think what I said then was not that the reason was, because I truly didn't know what the reason was why Mr. McBride did anything at all. I think what I said was, I took from the fact that they were fulminating a great deal about the illegality of the GPL and the badness of the Free Software Foundation, and yet weren't objecting to our code was because they knew it would be particularly easy to show that they were wrong.

I think that what I said was, that a process of taking a copyright assignment process from each contributor, accompanied by a legal indemnity, promising that the code was the code of the contributor and that there was nobody else with a dominating interest in it and doing so at the point of an indemnification promise to the Free Software Foundation produced a very strong chain link fence between us and claims of the kind that SCO was throwing around and I thought that constituted an indication of a cautious and prudent model of how to put free software together which Stallman had been following since long before I worked with him in the construction of the GNU Project. That didn't mean I think, that it was the only way to put together code that is strong, but where it works, it's a highly desirable model to pursue.

Linus eventually found another formula, which suited his view of the way the kernel development process works for introducing some accountability in the contributions process, and I thought that was a very good idea, and I said so. I think that if all the free software in the world were assembled in the most prudent and conservative fashion, that Mr. McBride and his colleagues would have found no place to even begin with the FUD with which they began. I think it's also important to point out that we all thought those accusations were baseless to start with and had good reasons to think they were baseless to start with. There wasn't anything wrong with how the kernel is put together. If there was a statement to make, it was simply the way the kernel is put together doesn't prove on its face the cleanliness of how it was put together with the degree of strength that otherwise could have been mustered.

I would advise clients of the Software Freedom Law Center, in light of SCO and many other things to begin their projects in ways that document and protect more carefully that structure of how free software is put together. But I understand completely how Linus Torvalds, living in Finland as a University of Helsinki undergraduate, unadvised by counsel, would not have chosen what I would now recommend to my clients to choose.

LWN: You made a comment about patent holders shaking down users of free software for royalties. I haven't heard of any situations where this is happening, can you tell us how bad the problem is, why it's not being made public when it happens?

Well, I think I can say why it isn't being made public, when a manufacturer of products with embedded free software, or user on a large scale of free software is the subject of claims such as this, from a company such as Microsoft, if they take a license and pay it's because they want peace and quiet. If what they want is peace and quiet, they'll be quiet about how they procured peace. The result of which, we won't hear except in an indirect way. That's why it's not public.

Why it's not a good idea is that each one of those parties that procures peace and quiet for itself is doing harm to the others in the ecology. Each one that takes a license strengthens the apparent patent claim that they are paying tribute on. The result of which is to strengthen the hand by which the troll tends to pick somebody else up later on. From an ecological point of view, we're concerned about the health of the entire community. You'd like to say to such people, before you pay that license fee, can you talk to about why that patent FUD may be just FUD? Could we discuss what we know about the patents held by the parties shaking you down? Could we present to you why maybe those patents aren't very strong and maybe not an appropriate basis for the payment of tribute. In other words, could we maintain a united, consolidated front.

The problem with the private license deals, they affect our solidarity and our ability to act defensively as a community together. And whether they're done publicly or not by the party who took the license, there's always a risk they'll be trumpeted by the patent holder as a sign of the strength of its patent and the degree to which other people should be afraid. So, when I have some reason to believe that some such situation is in progress, I often make an attempt to communicate with the party taking out a license, and often they won't talk and they prefer peace and quiet. I think that more respect for the needs of the community would be an appropriate leaven in their decision-making process?

LWN: How bad is the problem? Is this happening a great deal?

Well, I'm not in a position to say how often it's happened of course, since I'm sure I only know about a fraction of when it's going on. It's pure chance when we discover it, sometimes. I think it's bad for the reason I have suggested, that everybody knows... the patent problem is a real problem, and it needs a real solution. And you see people like the Open Source Development Labs stepping up and trying to create collaborative means to address the problem. Everything that subtracts energy from that attempt to collaborate to solve the problem, is in itself making the problem worse.

Without unduly criticizing businesses that are making business decisions, they're paying money to have peace, which is perfectly understandable to do and may be culturally particularly appropriate in certain national settings, I think that overall it creates difficulty for us, it aggravates the problem of patents overall.

LWN: There's a draft bill in the House right now, that would restructure the patent system, would it be good for free software?

It would not be bad for free software if it passes. That is to say there's nothing in that bill that aggravates the problem. Many things that were originally proposed in that bill that would have been good have been removed in the process of discussion.

My particular analysis is that, at the moment, the legislative process is stalled. I do not expect any movement in that legislative process. I think that, for the moment, that initiative is in the deep freeze. My analysis is that the power of pharma to control what happens to patents in the United States Congress is nearly absolute. The Princeton health economist, Uva Rinehart, who was a major advisor to the Clinton task force and is one of the most knowledgeable health care economists in the United States referred recently in a National Public Radio report I was listening to, to the pharmaceutical companies' "substantial equity stake in the United States Congress," and I thought that was a very elegant way of putting it.

My belief is that until such time as there is a deal which includes the pharmaceutical companies, there is very little enthusiasm in the United States Congress for meaningful patent reform.

I must say, as a person who represent parties who are very afraid of what patents can do to them, I think that this operation is very largely a sideshow. I think it was intended to give the impression that things were being done, and I think that people, in good faith, who want good outcomes, nobly put their shoulders to the wheel and tried to turn it. But I do not believe it will turn this time. I don't think it's going to turn until we make some serious attempt either to disengage the interests of pharma from IT and pursue sector-based relief from the patent problem or until we step up to the problem that the patent system doesn't work very well under 21st century conditions and no matter what the pharmaceutical companies think it needs serious reform.

LWN: You've encouraged free software developers to get patents on unique ideas. Is that happening much, and what resources are there for developers who want to obtain patents?

The grave difficulty in operating in this direction, which Mr. Stallman and I have been thinking about for years now, in order to be efficient in obtaining patents, you need to associate patent lawyers with patent agents with engineers in the very early stages of design and development of inventions.

You need to have people there right along, it's very inefficient to try after a project is over to develop the patent applications. Moreover, in the United States patent law, once you have gone on sale, which includes public distribution of free software, you have a year to file a patent application and after that you may not file at all.

The consequence of which is that there are both resource constraints and deadlines, which are very serious given the way that the free software development process works. Having patent agents and lawyers working along side developers is not a possibility. It's not efficient and it's not the way our community operates.

The result is that the process of getting patents for free software, to build a pool, is almost impracticable while the developer community is spread very thin and very little of it works for large technology businesses with established processes for the getting of patents.

On the other hand, resources may flow towards that in the same way that they have flowed towards the Software Freedom Law Center. I think that one of the most important things said in the OSDL announcement yesterday is that there would be resources for patent prosecution, that is for getting patents, available to developers who came forward and wanted their patents to go into the patent commons. That represents the first significant movement behind patent prosecution, behind getting patents. It's one of the things I hope people will notice about what OSDL has said, because I think it's an important strategic advance.

Will it work in that sense across the enormous range of free software projects? No, I don't think so, we're just at the beginning, we'd have to scale that in many different directions. But, in some crucial projects, important to our commercial partners in this process, and large numbers of users, and tightly coordinated development teams that have worked in large technology companies and know how the patent-getting processes work, in a range of conditions that are satisfied only in some parts of our community, I think there will be some real progress. I think you will see our inventions patented and there will be some cross-licensing negotiations that will be effective for us in gaining some use of other people's patent claims free of legal difficulty.

LWN: In the framework you talked about, these patents would be assigned to the commons, so that they couldn't decide to abuse them.

One of the things we need to do is arrange all of the legal infrastructure so that it works well for everybody. Yes, I think that's a reasonable thing to expect, there will be safeguards to prevent that kind of change of heart...

LWN: Let's talk about DRM. If the GPL requires distribution of scripts that control compilation and installation of an executable, does that extend to the binary keys for DRM?

I think the answer to that question is no. Under the existing GPL 2, the better argument would be that those are not covered by the definition of complete and corresponding source code under section 3 of the license. One could change that definition in a future version of the GPL, and say, for example, it's a straightforward idea, you could say the encryption keys that make it possible to run this software on the hardware on which you are receiving the software.

It is a possible approach. I think there are very significant difficulties with it, including the possibility we would pinch off a whole system of hardware in the world and say "free software doesn't run there." I think that might be a strategic mistake for the free software world, to say "we are going to write off a whole generation and form of hardware and not even attempt to bring freedom there..." I think we would risk leaving a whole lot of people in a condition of unfreedom for a long time.

I think unless we are prepared to be more sophisticated in our approach to this -- this is a very ham-fisted approach, the idea that you buy a computer and are not allowed to be in charge of it. It's a very anti-consumer thing to do. Instead of building an electric fence around it, as though it were some kind of bad place we don't want to go. I think we have a duty to bring freedom there if we can, and we need to empower consumers to reject such hardware and my hope is that in a future version of the GPL, we will devise something elegant and effective at using the gravitational force of freedom to unlock that place over there, and not just seal it off.

LWN: You talked a bit at the beginning about software-controlled radios and why they're important, do you want to add to that?

I've published pieces about that. If we are interested in freedom, generally, one of the things that we have to recognize about the 20th century is that there was a great degree of unfreedom that was generated by control over spectrum. Governments around the world either controlled spectrum themselves or delegated control to a small number of powerful people, and that affected 20th century politics very, very deeply.

It was also a technical response to a problem that doesn't exist with intelligent devices that exist in the 21st century... the technical rationale for the concentration of spectrum in a few hands is gone, and there never was a social rationale for that concentration of spectrum. It was never the case that the public trust that held the common property of the airwaves needed to be dealt with in a concentrated fashion for social or political reasons, the only justification ever given was a technical one.

So from my point of view, the world of devices that know about the spectrum and deal with it intelligently can promise more democracy in media than we ever had before, just as the web did for publication of text and is now doing for video. We need to be alert to the fact that the way we deal with software-controlled radios and the ability for people to use the spectrum themselves the way they want to, is a very important political and social issue in the 21st century. That's why I pay very close attention to how the free software world interacts with the world of spectrum control and regulation. 15 years from now, that's where the action is and I want to get the early stuff right if it's at all possible to do so.

LWN: Can we talk a little about the GPL revision process? When you did the GFDL process, some people thought they weren't listened to. What did you learn from the process?

I don't disagree with you that the process that was applied to the publication and modification of the GNU Free Documentation License would not work very well for the GPL version 3. And I think you've given reason, there's a very small group of people who need to be satisfied by and to use the license and in the other case, there's everybody on Earth... The GPL involves affecting a much broader community of stakeholders, much more various and much more complicated, we need to be in touch with that community as much as we can, and I think the process on that scale is a much different process.

I also should say that although it is true the number of people using the GNU FDL isn't that large, the number of people objecting to the FDL wasn't all that large either. There were a small number of people who wanted to say something and have their views heard. Whether they were heard or whether they thought they were heard is two different questions... I don't think there was a word written on that subject that I didn't read. Many words written on that subject I had no desire to respond to because I thought that response would only increase the intensity of the discussion... my goal in helping the Free Software Foundation construct a new GPL is to increase the lucidity without increasing the intensity. I hope there is a lot less shouting and a lot more thinking next time around by all parties.

LWN: Do you think that's likely?

I do. If you want to know what I think we've learned, I think we've learned some things about increasing the lucidity without increasing the intensity.

We'd like to thank Eben Moglen for taking the time to talk with LWN.

Comments (22 posted)

The launch of openSUSE

The SUSE Linux distribution has had a large and dedicated following for many years. SUSE users appreciate the combination of the distribution's administration tools, large selection of packages, and "German engineering." This distribution has always been relatively closed in its openSUSE development process, however. There is no development version available, and even beta tests have been closed affairs. SUSE has not, as a rule, invited its users to be a part of the development process.

The opening up of the SUSE distribution was bound to happen, sooner or later. Maintaining a major distribution is a major bit of work. But major distributions have user communities which can help with that work, and which can be the source of no end of good ideas as well. Bringing in the user community can improve the distribution, ensure wider testing, and, as a bonus, further bind those users with the distribution. People tend to be more enthusiastic about software which they have helped to shape and polish. Red Hat figured this out some years ago, and most other major distributions are created with a great deal of outside involvement.

SUSE Linux is now attempting to follow a similar path through the openSUSE project, which was officially announced on August 9. OpenSUSE will play a role similar to Red Hat's Fedora; it is a free distribution, developed with community input, which will help to drive the development of SUSE's high-end commercial offerings. Unlike Fedora, however, openSUSE will continue to be available as a retail, boxed product. In this way, Novell hopes to make the distribution as accessible as possible.

Since openSUSE is new, it lags Fedora in a number of ways. At the top of the list would be the lack of an ongoing development version of the distribution. The announcement of openSUSE included a beta release for openSUSE 10.0, which is a step in the right direction (see our review on this week's Distributions Page). The occasional beta release, however, is not the same as a bleeding-edge development repository along the lines of Rawhide, Debian unstable, or Ubuntu's "breezy." Your editor, who has not had a successful Rawhide update in some time, currently finds his enthusiasm for development repositories to be at a relatively low point. But the fact remains that making the current development version of a distribution available facilitates early testing and feedback. It also provides an experience some users want: riding the leading edge of a fast-moving distribution is a great way to taste - and participate in - the vitality of the free software community as a whole.

The openSUSE "how to participate" page shows some parallels with the early Fedora days. The first and foremost way for people to participate at this time is to test packages and report bugs. Interested people are also encouraged to submit patches, write documentation, or apply for a job. There is currently no way for outside developers to apply changes or provide packages themselves; the roadmap page states that "a first version" of a build server will be made available in early 2006. Given the frustration experienced by would-be Fedora developers, the openSUSE folks would be well advised to get that infrastructure in place in short order.

Some things are missing from the openSUSE site altogether. There is, for example, no discussion of how openSUSE will be governed. Who will make decisions on distribution policy, which packages will be included, etc.? Fedora, instead, launched with detailed plans for various sorts of advisory boards - and promptly ignored them all. More recently, Red Hat has been talking about loosening its firm grip on Fedora; very little has been said, instead, about just how independent openSUSE will be from Novell's management.

Also missing is any discussion of the security update policy for openSUSE releases. SUSE's security response tends to be rapid and thorough. The same has traditionally been true of Red Hat, but Fedora brought with it a new policy on security patches. Updates tend to come quickly from Fedora, but the short period for security support makes Fedora a relatively difficult platform for any sort of production use. That suits Red Hat's goals nicely, of course - Red Hat is wanting to sell its enterprise support offerings. It would not be entirely surprising to see openSUSE take a similar path; hopefully the project will post a security update policy in the near future so that its users will know what to expect.

If the openSUSE project is to be successful, it must find a way to attract developers and users, and to keep them happy. There is quite a variety of community distribution projects out there, and many of them do not have any apparent conflicts of interest with corporate goals. OpenSUSE will have to distinguish itself from those other distributions somehow. The openSUSE FAQ gives a hint as to how the project's leaders are hoping to proceed:

The openSUSE project explicitly looks beyond the technical community to the broader non-technical community of computer users interested in Linux... Only the openSUSE project refines its Linux distribution to the point where non-technical users can have a successful Linux experience.

The "only" claim is certainly debatable, but, with SUSE Linux as a base, the openSUSE project has a solid base upon which to build in that direction. There will always be room for a well-designed, robustly-built, user-oriented Linux distribution.

Comments (3 posted)

Some SCO notes

It has been some time since the SCO Group has graced the LWN front page. That situation is just fine with us; there is no end of more interesting stuff happening out there. A couple of events this week merit a bit of attention, though. Even as it heads toward total irrelevance, the SCO Group is worth watching.

SCO launched its annual SCO Forum (evidently a rather smaller event this year) with a delightful open letter from Darl McBride. The letter, in some ways, is classic Darl; full of bluster and easy to refute. It's almost like the good old days, before SCO's lawyers finally got him to keep his mouth closed. Others have taken on the task of writing detailed rebuttals of this letter; there is no real point in doing it here.

What is truly worth noting in the latest open letter, however, is that it contains no threats to sue anybody. Darl, instead, seems to have concluded that he should maybe think about trying to sell some software. As a result, his letter is all about showing why OpenServer is better than Linux. It is FUD from one end to the other, but it is boilerplate commercial FUD of the type we have seen before. Darl seems to be working from the playbook that Microsoft discarded (as ineffective) some years ago. The "Linux has no support" line is a holdover from the 1990's. It didn't work then; there is no real reason for us to worry about it now.

The SCO Group seems to have concluded that the litigation lottery ticket is not going to pay off, and so is putting its effort into plan B. Had the company done that a few years ago, it might have gotten somewhere. At this point, however, SCO seems unlikely to survive the countercharges being leveled against it. Novell's attempt to force SCO's remaining cash into an escrow account could, on its own, suffice to end the show - before companies like IBM and Red Hat even begin to get their licks in.

Some additional amusement can be found in IBM's deposition of Erik Hughes, a SCO employee. One widely-reported outcome from this deposition (which was just recently unsealed) is that it seems likely that UnixWare's "Linux Kernel Personality" product included Linux kernel code for a couple of releases. If that is indeed the way of things, SCO may have been in violation of the GPL - at the same time it was charging copyright infringements by others.

Remember the "Chris and Darl show" teleconferences from the early days of the IBM suit? One could almost get nostalgic about those bizarre exercises. Your editor would always try to get a question in, but, somehow, tragically, time always ran out before the question could be asked. In August, 2003, a message was sent to SCO's Blake Stowell and Chris Sontag asking a question which was not heard during the teleconference: noting that the 2.4 kernel was still available from SCO's FTP server, your editor asked just how SCO was able to reconcile its claims over the kernel with the GPL and its distribution of vast amounts of code over which it could have no possible claim. An interesting, private conversation resulted, in which a SCO employee stated that he did not think the GPL was valid. Nothing publishable ever came from the exchange, however, and your editor had long since forgotten about it.

It can be a surprising experience to run across one's name unexpectedly in a legal document. IBM's lawyers, it seems, found that old message and brought it up in the Hughes deposition. Your editor, it seems, was one of a group of "long-haired smelly's" asking about the contradictions inherent in SCO's continued distribution of Linux while claiming that it contained SCO's proprietary code. The continued availability of the kernel on SCO's site has been well documented; the "smelly's" helped to document that SCO knew it was a violation of the GPL at the time.

In retrospect, it seems clear that IBM's lawyers could have disposed of the SCO threat on their own. That notwithstanding, the community's "distributed defense" response to this attack is notable. As a group, we dug up vast amounts of information, poked holes in SCO's claims, and singlehandedly won the PR battle (which IBM could not engage in). Anybody contemplating an attack on the free software community will need to think long and hard about how to handle the community's response. On the other hand, the sheer buffoonery of SCO's attack presents a risk of its own: somebody may well decide that SCO's failure resulted from poor execution, rather than an inherently bad idea. Should that happen, we may have to go through all of this again.

[Coming soon: the Grumpy and Malodorous Editor's Guide to All-Natural Deodorants.]

Comments (11 posted)

Page editor: Jonathan Corbet

Security

mod_spambot

It has been known for years that spammers harvest web sites for email addresses to add to their lists. Various sites have responded by hiding or obfuscating email addresses found on their pages; some people go to extreme measures to keep their address from ever appearing on a page. One wonders what they are worried about; your editor only receives a mere 3-4000 spams per day to his highly-public email address, after all.

Suffice to say that without SpamAssassin LWN would likely have collapsed under the flood years ago.

Some folks have decided that it is time to take a more active stance against the harvesting of email addresses from web pages. The result is an Apache module called mod_spambot; version 0.47 was recently released. The idea behind this module is to detect accesses by address harvesters and shut them down. Unfortunately, the approach this module takes is too simplistic to work in many situations.

mod_spambot is essentially a traffic throttling module. If a given site pulls down too many pages in a given time period (default is 100 pages in one hour), its access is cut off. There is also a "honeypot" option which will, instead, feed the (presumed) harvester a set of pseudo-random pages with bogus email addresses in them. This approach may well cut off some spammers, but anybody who has maintained a busy web site can see a few problems fairly quickly:

  • This approach will also cut off others who may be grabbing large numbers of pages from the site. Search engines come to mind, as do archive sites or anybody wanting to mirror a portion of a site. Cutting off people who thoughtlessly run a recursive wget to grab an entire site has some appeal; "download the site" operations account for a substantial part of LWN's bandwidth usage. But most site operators do not want to pull the plug on search engines and the like. mod_spambot allows the administrator to construct a whitelist, but who wants to figure out how to whitelist every possible search engine of interest?

  • There are some very large networks out there hiding behind a massive router and a single IP address. Traffic which looks like it originates from a single host may, in fact, be generated by hundreds of individual readers.

  • Increasingly large amounts of traffic are generated by robots whose sole purpose is to get a referrer URL onto a "top referrers" page somewhere on the site. Purveyors of Internet gambling experiences and particular types of imagery appear to like this approach to marketing. The interesting thing is that these accesses come simultaneously from a large number of IP addresses. These people, clearly, are using a network of zombie machines for their attacks. Spammers already use zombies to deliver their mail; it is hard to believe that they would not use those machines for address harvesting as well.

So throttling robots based on IP address will miss some attackers while blocking legitimate users of the site. It would be nice to prevent one's web site from being used as a resource by spammers, but this approach is not, yet, the way to that end.

Comments (16 posted)

Brief items

Update on RFID passports

Bruce Schneier looks at current plans for RFID-enabled U.S. passports; it seems that things are headed in the right direction. "The most important feature they've included is an access-control system for the RFID chip. The data on the chip is encrypted, and the key is printed on the passport. The officer swipes the passport through an optical reader to get the key, and then the RFID reader uses the key to communicate with the RFID chip. This means that the passport-holder can control who has access to the information on the chip; someone cannot skim information from the passport without first opening it up and reading the information inside. Good security."

Comments (1 posted)

Greasing the wheel with Greasemonkey (SecurityFocus)

Here's a SecurityFocus column on how the recent GreaseMonkey vulnerability was handled. "If we must continue the discussion to encompass the model of open source, then I have to say that the approach Greasemonkey took shows what makes open source great: openness. Throughout the whole painful process, information was available to those who needed it: developers, IT folks, users, and security pros. No one was kept in the dark, and all the details -- code, communications, thought processes, and so on -- were always available so that interested parties could make decisions based on facts instead of promises and conjecture."

Comments (none posted)

New vulnerabilities

gaim: buffer overflow

Package(s):gaim CVE #(s):CAN-2005-2103
Created:August 10, 2005 Updated:February 27, 2006
Description: Gaim suffers from a heap-based buffer overflow which can be exploited via a hostile "away message" to execute arbitrary code.
Alerts:
Fedora-Legacy FLSA:158543 gaim 2006-02-25
Slackware SSA:2005-242-03 gaim 2005-08-31
Fedora FEDORA-2005-751 gaim 2005-08-17
Fedora FEDORA-2005-750 gaim 2005-08-17
Mandriva MDKSA-2005:139 gaim 2005-08-15
Gentoo 200508-06 gaim 2005-08-15
Ubuntu USN-168-1 gaim 2005-08-12
Red Hat RHSA-2005:589-01 gaim 2005-08-09

Comments (none posted)

sysreport: insecure temporary file

Package(s):sysreport CVE #(s):CAN-2005-2104
Created:August 9, 2005 Updated:November 11, 2005
Description: Bill Stearns discovered a bug in the way sysreport creates temporary files. It is possible that a local attacker could obtain sensitive information about the system when sysreport is run.
Alerts:
Fedora FEDORA-2005-1072 sysreport 2005-11-10
Fedora FEDORA-2005-1071 sysreport 2005-11-10
Red Hat RHSA-2005:598-01 sysreport 2005-08-09

Comments (none posted)

ucd-snmp: denial of service

Package(s):ucd-snmp CVE #(s):CAN-2005-2177
Created:August 9, 2005 Updated:January 27, 2006
Description: A denial of service bug was found in the way ucd-snmp uses network stream protocols. A remote attacker could send a ucd-snmp agent a specially crafted packet which will cause the agent to crash.
Alerts:
Mandriva MDKSA-2006:025 net-snmp 2006-01-26
Ubuntu USN-190-2 ucd-snmp 2005-11-21
Debian DSA-873-1 net-snmp 2005-10-26
Red Hat RHSA-2005:395-01 net-snmp 2005-10-05
Ubuntu USN-190-1 net-snmp 2005-09-29
Red Hat RHSA-2005:373-01 net-snmp 2005-09-28
Mandriva MDKSA-2005:137 ucd-snmp 2005-08-11
Red Hat RHSA-2005:720-01 ucd-snmp 2005-08-09

Comments (none posted)

xpdf: denial of service

Package(s):xpdf kpdf CVE #(s):CAN-2005-2097
Created:August 9, 2005 Updated:August 2, 2006
Description: A flaw was discovered in Xpdf in that could allow an attacker to construct a carefully crafted PDF file that would cause Xpdf to consume all available disk space in /tmp when opened.
Alerts:
Debian DSA-1136-1 gpdf 2006-08-02
Mandriva MDKSA-2005:138-1 cups 2005-09-19
Debian DSA-780-1 kdegraphics 2005-08-22
SuSE SUSE-SR:2005:019 multi 2005-08-19
Fedora FEDORA-2005-732 cups 2005-08-17
Fedora FEDORA-2005-733 cups 2005-08-17
Gentoo 200508-08 xpdf 2005-08-16
Fedora FEDORA-2005-730 xpdf 2005-08-15
Fedora FEDORA-2005-729 xpdf 2005-08-15
Mandriva MDKSA-2005:136 gpdf 2005-08-11
Mandriva MDKSA-2005:135 kdegraphics 2005-08-11
Mandriva MDKSA-2005:134 xpdf 2005-08-11
Mandriva MDKSA-2005:138 cups 2005-08-11
Red Hat RHSA-2005:708-01 gpdf 2005-08-10
Red Hat RHSA-2005:706-01 CUPS 2005-08-09
Red Hat RHSA-2005:671-01 kdegraphics 2005-08-09
Red Hat RHSA-2005:670-01 xpdf 2005-08-09
Ubuntu USN-163-1 xpdf 2005-08-09

Comments (none posted)

Page editor: Jonathan Corbet

Kernel development

Brief items

Kernel release status

The current stable 2.6 release is 2.6.12.4, which was announced on August 5.

The current 2.6 prepatch is 2.6.13-rc6, released by Linus on August 7. This prepatch contains a fix for recent aic7xxx performance problems (so extra testing by people with the relevant hardware is being requested), the removal of a few patches which caused regressions, and a number of fixes. The long-format changelog has the details.

Linus's git repository contains a very small number of fixes added since -rc6. It appears that the August 12 to 19 time frame for 2.6.13 found in Andrew Morton's kernel status report may be just about right.

The current -mm tree is 2.6.13-rc5-mm1. Recent additions to -mm include a relayfs update, a new kzalloc() function (see below), some debugging helpers from the realtime preemption patch set, some architecture updates, and lots of fixes.

The current 2.4 prepatch is 2.4.32-pre3, released by Marcelo on August 8. This prepatch adds a handful of fixes and a 2.6 serial ATA backport.

Comments (none posted)

Kernel development news

Quote of the week

I have to say, with tcl/tk, "google" + "random typing" can make you appear to know what the hell you're doing.

-- Linus Torvalds

Comments (none posted)

Toward more robust network-based block I/O

One thing which came out of this year's Kernel Summit is that the kernel still does not deal well with network-based block devices when memory gets tight. If the system is full of dirty memory, the kernel must write some of those dirty pages to their backing store so that the memory may be reused. But the act of writing that data over the network can require the allocation of more memory. Even worse, completing network-based I/O requires the ability to receive the acknowledgment packets back from the remote device. Not only does that packet reception require memory, but the system must contend with the fact that the network could also be the source of vast numbers of packets which are completely unrelated to the problem at hand. If the system cannot find a way to receive the packets it needs while ignoring unrelated packets, extreme memory pressure will eventually lead to a lockup.

Solving this problem is hard. At the Summit, Linus suggested that it might not even make sense to try; instead, users should be directed toward I/O hardware which does not present this sort of problem. In reality, however, Linux will do its best to support network-based block devices. Daniel Phillips has recently been working on a patch which tries to make some progress in that direction.

Like many before him, Daniel bases his approach on the use of preallocated memory pools - a chunk of memory which is set aside for use when no other memory is available. Daniel has tried to take things a little further by quantifying how much memory should be set aside. To that end, each network driver should, when an interface is brought up, make a call to: 

    int adjust_memalloc_reserve(int pages);

Where pages is the number of pages required to be able to continue to receive packets on the given interface. A helper function, estimate_skb_pages(), can come up with a guess for how many pages will be required to hold a given number of packets with a specified maximum size. The call to adjust_memalloc_reserve() will cause the virtual memory subsystem to set aside the given number of pages for emergency use by the driver. In this way, it is hoped, the system will reserve a sufficient amount of memory without being overly wasteful.

Memory can be allocated from the reserve by adding the new __GFP_MEMALLOC flag to the allocation request. A new networking helper function, dev_memalloc_skb(), will use that flag if necessary to obtain a packet. Before doing so, however, it checks a count of packets allocated from the reserve; no interface is allowed to allocate beyond a maximum count, which defaults to 50. Unlike previous versions of the patch, the current code does not attempt to track which packets, in particular, were allocated from reserve memory. Any packets which originate from a given device will, when returned to the system, be credited to that device's reserve.

A longstanding problem with the reserve approach is that, if one is not careful, the reserve simply gets depleted and the system runs out of memory anyway. In a situation where memory use is not entirely within the system's control - when dealing with incoming network data, for example - this sort of depletion is especially likely. Your system may be doing its best to flush dirty pages to your home iSCSI array, but the network memory reserves are full of incoming music being downloaded by your children, so the entire system comes to a halt. Such an outcome may please the RIAA, but the kernel developers are trying to satisfy a different audience.

Daniel's answer to this problem is to add a special flag to network sockets which are involved in block I/O. Only sockets marked with SOCK_MEMALLOC are entitled to use packet memory from the reserves. When the packet arrives on the interface, the system cannot know whether it is useful or not, so that packet must be received (possibly using reserve memory) and fed into the system in the usual way. The protocol code, however, is expected to check each packet to see whether it comes from a device which is currently using reserve memory. If so, and the packet does not belong to a suitably-marked socket, that packet is to be dropped immediately. In this way, it is hoped, the system will be able to focus its remaining resources on recovering from its memory crunch.

This approach may have some promise. This patch needs some work, however, before it is ready for serious stress testing. Once it has been worked into shape, the patch can be applied to a suitably-equipped system, which can then be pushed into a state of serious memory pressure. That point has been the downfall of a number of other approaches to this problem; whether Daniel's work is up to this test remains to be seen.

Comments (1 posted)

kzalloc()

The kernel code base is full of functions which allocate memory with kmalloc(), then zero it with memset(). Recently, Pekka Enberg concluded that much of this code could be cleaned up by using kcalloc() instead. kcalloc() has this prototype: 

    void *kcalloc(size_t n, size_t size, unsigned int __nocast gfp_flags);

This function will allocate an array of n items, and will zero the entire array before returning it to the caller. Pekka's patch converted a number of kmalloc()/memset() pairs over to kcalloc(), but that patch drew a complaint from Andrew Morton:

Notice how every conversion you did passes in `1' in the first argument? And that's going to happen again and again and again. Each callsite needlessly passing that silly third argument, adding more kernel text.

Very few callers actually need to allocate an array of items, so the extra argument is unneeded in most cases. Each instance of that argument adds a bit to the size of the kernel, and, over time, that space adds up. The solution was to create yet another allocation function: 

    void *kzalloc(size_t size, unsigned int __nocast gfp_flags);

This function returns a single, zeroed item. It has been added to -mm, with its appearance in the mainline likely to happen for 2.6.14.

Comments (9 posted)

Time to merge GFS?

Red Hat recently announced that Fedora Core 4 was available with the Global Filesystem (GFS). Like Oracle's OCFS2, GFS allows a tightly-linked cluster to manage filesystems stored on a shared disk. Now that GFS is actually shipping, Red Hat would like to see it merged into the mainline kernel. Thus, recently, David Teigland posted the patches for review and asked for feedback. He got some.

One issue has to do with locking. Since the filesystem is kept on shared storage, the nodes of the cluster must take care to avoid stepping on each others' toes and corrupting things. The distributed lock manager (DLM) subsystem is used to that end; whenever a node wishes to access a particular block on the filesystem, it first obtains a cluster-wide lock on that block. As long as the filesystem only supports the read() and write() system calls, this locking works reasonably well. The filesystem code can obtain the locks it needs, perform the operation, then return the locks, and all works well.

The problem comes in when the filesystem supports mmap() as well. Accesses to memory mapped with mmap() does not happen with the read() and write() system calls; it is, instead, done with regular memory operations. Locking in this case is handled in conjunction with the virtual memory subsystem; the permissions on any particular page are set to be consistent with the level of lock currently held by the local node. If the node does not have a lock for a specific block in the filesystem, the page table entry for the corresponding page will show that page as being absent. If the process which made the mapping tries to access the page, it will incur a page fault; the filesystems nopage() method can then set up the mapping, acquiring whatever locks are required.

Page faults are asynchronous events. In particular, a page fault could happen while the kernel is busy handling a read() or write() operation somewhere else in the filesystem. In this case, the kernel will be acquiring two independent locks in the filesystem, and in an arbitrary order. It does not take much experience with locking to learn that, when multiple locks are to be acquired, the order in which they are taken is critical. Consider a case where there are two locks (call them "A" and "B") and two processes needing them. Imagine that one process acquires A, while the other acquires B. Each process then attempts to grab the remaining lock. At this point, both processes will wait forever; this situation is called an "ABBA deadlock." Contrary to what some may believe, the term has nothing to do with 1970's Swedish rock bands.

Avoiding this kind of deadlock requires a fair amount of ugly filesystem trickery; Zach Brown put it this way:

So clustered file systems in Linux (GFS, Lustre, OCFS2, (GPFS?)) all walk vmas in their file->{read,write} to discover mappings that belong to their files so that they can preemptively sort and acquire the locks that will be needed to cover the mappings that might be established in ->nopage. As you point out, this both relies on the mappings not changing and gets very exciting when you mix files and mappings between file systems that are each sorting and acquiring their own DLM locks.

Sorting this situation out properly will probably require some sort of support at the VFS layer. In that way, one hopes, a single, working solution would be found. The alternative seems to be a bunch of brittle and complicated code in each filesystem which has this problem.

Another glitch encountered by GFS is its support for "context-dependent path names." These are, in essence, symbolic links with magic properties. The GFS code, if it encounters "@hostname" as a component in a symbolic link, will substitute the name of the current host. Similar substitutions will happen for @mach, @os, @uid, and others. There is also support for an alternative syntax ("{hostname}"), for whatever reason.

This mechanism exists to allow cluster nodes to establish private areas on a shared disk. It can also be used, for example, to create architecture-specific directories full of binaries on a common path. In the past, administrators have used automounter trickery to a very similar end. The filesystem hackers, who do not like to see this sort of magic buried within individual filesystems, suggest that bind mounts should be used instead. That technique, however, is relatively cumbersome and error-prone, so there is some interest in finding a way to maintain the sort of functionality implemented by context-dependent links.

The objections to context-dependent links include the addition of magic to parts of the filesystem namespace and the fact that they are specific to one filesystem. Moving the resolution of these links up to the VFS layer could be a part of the solution, since it would then at least function the same way for all filesystems. Adding this kind of semantics may always be a hard sell, however, since it changes the way Linux filesystems are expected to behave. The old, automounter-based approach may end up being the recommended technique for those needing this sort of behavior.

Comments (6 posted)

A realtime preemption overview

August 10, 2005

This article was contributed by Paul McKenney

There have been a considerable number of papers describing a number of different aspects of and approaches to realtime, a few of which were listed in the RESOURCES section of my "realtime patch acceptance summary from July.

However, there does not appear to be a similar description of the realtime preemption (PREEMPT_RT) patch. This document attempts to fill this gap, using the V0.7.52-16 version of this patch. However, please note that the PREEMPT_RT patch evolves very quickly!

Philosophy of PREEMPT_RT

The key point of the PREEMPT_RT patch is to minimize the amount of kernel code that is non-preemptible, while also minimizing the amount of code that must be changed in order to provide this added preemptibility. In particular, critical sections, interrupt handlers, and interrupt-disable code sequences are normally preemptible. The PREEMPT_RT patch leverages the SMP capabilities of the Linux kernel to add this extra preemptibility without requiring a complete kernel rewrite. In a sense, one can loosely think of a preemption as the addition of a new CPU to the system, and then use the normal locking primitives to synchronize with any action taken by the preempting task.

Note that this statement of philosophy should not be taken too literally, for example, the PREEMPT_RT patch does not actually perform a CPU hot-plug event for each preemption. Instead, the point is that the underlying mechanisms used to tolerate (almost) unlimited preemption are those that must be provided for SMP environments. More information on how this philosophy is applied is given in the following sections.

Features of PREEMPT_RT

This section gives an overview of the features that the PREEMPT_RT patch provides.

  1. Preemptible critical sections
  2. Preemptible interrupt handlers
  3. Preemptible "interrupt disable" code sequences
  4. Priority inheritance for in-kernel spinlocks and semaphores
  5. Deferred operations
  6. Latency-reduction measures

Each of these topics is covered in the following sections.

Preemptible critical sections

In PREEMPT_RT, normal spinlocks (spinlock_t and rwlock_t) are preemptible, as are RCU read-side critical sections (rcu_read_lock() and rcu_read_unlock()). Semaphore critical sections are preemptible, but they already are in both PREEMPT and non-PREEMPT kernels (but more on semaphores later). This preemptibility means that you can block while acquiring a spinlock, which in turn means that it is illegal to acquire a spinlock with either preemption or interrupts disabled (the one exception to this rule being the _trylock variants, at least as long as you don't repeatedly invoke them in a tight loop). This also means that spin_lock_irqsave() does -not- disable hardware interrupts when used on a spinlock_t.

Quick Quiz #1: How can semaphore critical sections be preempted in a non-preemptible kernel?

So, what to do if you need to acquire a lock when either interrupts or preemption are disabled? You use a raw_spinlock_t instead of a spinlock_t, but continue invoking spin_lock() and friends on the raw_spinlock_t. The PREEMPT_RT patch includes a set of macros that cause spin_lock() to act like a C++ overloaded function -- when invoked on a raw_spinlock_t, it acts like a traditional spinlock, but when invoked on a spinlock_t, its critical section can be preempted. For example, the various _irq primitives (e.g., spin_lock_irqsave()) disable hardware interrupts when applied to a raw_spinlock_t, but do not when applied to a spinlock_t. However, use of raw_spinlock_t (and its rwlock_t counterpart, raw_rwlock_t) should be the exception, not the rule. These raw locks should not be needed outside of a few low-level areas, such as the scheduler, architecture-specific code, and RCU.

Since critical sections can now be preempted, you cannot rely on a given critical section executing on a single CPU -- it might move to a different CPU due to being preempted. So, when you are using per-CPU variables in a critical section, you must separately handle the possibility of preemption, since spinlock_t and rwlock_t are no longer doing that job for you. Approaches include:

  1. Explicitly disable preemption, either through use of get_cpu_var(), preempt_disable(), or disabling hardware interrupts.

  2. Use a per-CPU lock to guard the per-CPU variables. One way to do this is by using the new DEFINE_PER_CPU_LOCKED() primitive -- more on this later.

Since spin_lock() can now sleep, an additional task state was added. Consider the following code sequence (supplied by Ingo Molnar): 

	spin_lock(&mylock1);
	current->state = TASK_UNINTERRUPTIBLE;
	spin_lock(&mylock2);                    // [*]
	blah();
	spin_unlock(&mylock2);
	spin_unlock(&mylock1);

Since the second spin_lock() call can sleep, it can clobber the value of current->state, which might come as quite a surprise to the blah() function. The new TASK_RUNNING_MUTEX bit is used to allow the scheduler to preserve the prior value of current->state in this case.

Although the resulting environment can be a bit unfamiliar, but it permits critical sections to be preempted with minimal code changes, and allows the same code to work in the PREEMPT_RT, PREEMPT, and non-PREEMPT configurations.

Preemptible interrupt handlers

Almost all interrupt handlers run in process context in the PREEMPT_RT environment. Although any interrupt can be marked SA_NODELAY to cause it to run in interrupt context, only the fpu_irq, irq0, irq2, and lpptest interrupts have SA_NODELAY specified. Of these, only irq0 (the per-CPU timer interrupt) is normally used -- fpu_irq is for floating-point co-processor interrupts, and lpptest is used for interrupt-latency benchmarking. Note that software timers (add_timer() and friends) do not run in hardware interrupt context; instead, they run in process context and are fully preemptible.

Note that SA_NODELAY is not to be used lightly, as can greatly degrade both interrupt and scheduling latencies. The per-CPU timer interrupt qualifies due to its tight tie to scheduling and other core kernel components. Furthermore, SA_NODELAY interrupt handlers must be coded very carefully as noted in the following paragraphs, otherwise, you will see oopses and deadlocks.

Since the per-CPU timer interrupt (e.g., scheduler_tick()) runs in hardware-interrupt context, any locks shared with process-context code must be raw spinlocks (raw_spinlock_t or raw_rwlock_t), and, when acquired from process context, the _irq variants must be used, for example, spin_lock_irqsave(). In addition, hardware interrupts must typically be disabled when process-context code accesses per-CPU variables that are shared with the SA_NODELAY interrupt handler, as described in the following section.

Preemptible "interrupt disable" code sequences

The concept of preemptible interrupt-disable code sequences may seem to be a contradiction in terms, but it is important to keep in mind the PREEMPT_RT philosophy. This philosophy relies on the SMP capabilities of the Linux kernel to handle races with interrupt handlers, keeping in mind that most interrupt handlers run in process context. Any code that interacts with an interrupt handler must be prepared to deal with that interrupt handler running concurrently on some other CPU.

Therefore, spin_lock_irqsave() and related primitives need not disable preemption. The reason this is safe is that if the interrupt handler runs, even if it preempts the code holding the spinlock_t, it will block as soon as it attempts to acquire that spinlock_t. The critical section will therefore still be preserved.

However, local_irq_save() still disables preemption, since there is no corresponding lock to rely on. Using locks instead of local_irq_save() therefore can help reduce scheduling latency, but substituting locks in this manner can reduce SMP performance, so be careful.

Code that must interact with SA_NODELAY interrupts cannot use local_irq_save(), since this does not disable hardware interrupts. Instead, raw_local_irq_save() should be used. Similarly, raw spinlocks (raw_spinlock_t, raw_rwlock_t, and raw_seqlock_t) need to be used when interacting with SA_NODELAY interrupt handlers. However, raw spinlocks and raw interrupt disabling should -not- be used outside of a few low-level areas, such as the scheduler, architecture-dependent code, and RCU.

Priority inheritance for in-kernel spinlocks and semaphores

Realtime programmers are often concerned about priority inversion, which can happen as follows:

  • Low-priority task A acquires a resource, for example, a lock.

  • Medium-priority task B starts executing CPU-bound, preempting low-priority task A.

  • High-priority task C attempts to acquire the lock held by low-priority task A, but blocks because of medium-priority task B having preempted low-priority task A.

Such priority inversion can indefinitely delay a high-priority task. There are two main ways to address this problem: (1) suppressing preemption and (2) priority inheritance. In the first case, since there is no preemption, task B cannot preempt task A, preventing priority inversion from occurring. This approach is used by PREEMPT kernels for spinlocks, but not for semaphores. It does not make sense to suppress preemption for semaphores, since it is legal to block while holding one, which could result in priority inversion even in absence of preemption. For some realtime workloads, preemption cannot be suppressed even for spinlocks, due to the impact to scheduling latencies.

Priority inheritance can be used in cases where suppressing preemption does not make sense. The idea here is that high-priority tasks temporarily donate their high priority to lower-priority tasks that are holding critical locks. This priority inheritance is transitive: in the example above, if an even higher priority task D attempted to acquire a second lock that high-priority task C was already holding, then both tasks C and A would be be temporarily boosted to the priority of task D. The duration of the priority boost is also sharply limited: as soon as low-priority task A releases the lock, it will immediately lose its temporarily boosted priority, handing the lock to (and being preempted by) task C.

However, it may take some time for task C to run, and it is quite possible that another higher-priority task E will try to acquire the lock in the meantime. If this happens, task E will "steal" the lock from task C, which is legal because task C has not yet run, and has therefore not actually acquired the lock. On the other hand, if task C gets to run before task E tries to acquire the lock, then task E will be unable to "steal" the lock, and must instead wait for task C to release it, possibly boosting task C's priority in order to expedite matters.

In addition, there are some cases where locks are held for extended periods. A number of these have been modified to add "preemption points" so that the lock holder will drop the lock if some other task needs it. The JBD journaling layer contains a couple of examples of this.

It turns out that write-to-reader priority inheritance is particularly problematic, so PREEMPT_RT simplifies the problem by permitting only one task at a time to read-hold a reader-writer lock or semaphore, though that task is permitted to recursively acquire it. This makes priority inheritance doable, though it can limit scalability.

Quick Quiz #2: What is a simple and fast way to implement priority inheritance from writers to multiple readers?

In addition, there are some cases where priority inheritance is undesirable for semaphores, for example, when the semaphore is being used as an event mechanism rather than as a lock (you can't tell who will post the event before the fact, and therefore have no idea which task to priority-boost). There are compat_semaphore and compat_rw_semaphore variants that may be used in this case. The various semaphore primitives (up(), down(), and friends) may be used on either compat_semaphore and semaphore, and, similarly, the reader-writer semaphore primitives (up_read(), down_write(), and friends) may be used on either compat_rw_semaphore and rw_semaphore. Often, however, the completion mechanism is a better tool for this job.

So, to sum up, priority inheritance prevents priority inversion, allowing high-priority tasks to acquire locks and semaphores in a timely manner, even if the locks and semaphores are being held by low-priority tasks. PREEMPT_RT's priority inheritance provides transitivity, timely removal of inheritance, and the flexibility required to handle cases when high priority tasks suddenly need locks earmarked for low-priority tasks. The compat_semaphore and compat_rw_semaphore declarations can be used to avoid priority inheritance for semaphores for event-style usage.

Deferred operations

Since spin_lock() can now sleep, it is no longer legal to invoke it while preemption (or interrupts) are disabled. In some cases, this has been solved by deferring the operation requiring the spin_lock() until preemption has been re-enabled:

  • put_task_struct_delayed() queues up a put_task_struct() to be executed at a later time when it is legal to acquire (for example) the spinlock_t alloc_lock in task_struct.

  • mmdrop_delayed() queues up an mmdrop() to be executed at a later time, similar to put_task_struct_delayed() above.

  • TIF_NEED_RESCHED_DELAYED does a reschedule, but waits to do so until the process is ready to return to user space -- or until the next preempt_check_resched_delayed(), whichever comes first. Either way, the point is avoid needless preemptions in cases where a high-priority task being awakened cannot make progress until the current task drops a lock. Without TIF_NEED_RESCHED_DELAYED, the high-priority task would immediately preempt the low-priority task, only to quickly block waiting for the lock held by the low-priority task.

    The solution is to change a "wake_up()" that is immediately followed by a spin_unlock() to instead be a "wake_up_process_sync()". If the process being awakened would preempt the current process, the wakeup is delayed via the TIF_NEED_RESCHED_DELAYED flag.

In all of these situations, the solution is to defer an action until that action may be more safely or conveniently performed.

Latency-reduction measures

There are a few changes in PREEMPT_RT whose primary purpose is to reduce scheduling or interrupt latency.

The first such change involves the x86 MMX/SSE hardware. This hardware is handled in the kernel with preemption disabled, and this sometimes means waiting until preceding MMX/SSE instructions complete. Some MMX/SSE instructions are no problem, but others take overly long amounts of time, so PREEMPT_RT refuses to use the slow ones.

The second change applies per-CPU variables to the slab allocator, as an alternative to the previous wanton disabling of interrupts.

Summary of PREEMPT_RT primitives

This section gives a brief list of primitives that are either added by PREEMPT_RT or whose behavior is significantly changed by PREEMPT_RT.

Locking Primitives

spinlock_t
Critical sections are preemptible. The _irq operations (e.g., spin_lock_irqsave()) do -not- disable hardware interrupts. Priority inheritance is used to prevent priority inversion. An underlying rt_mutex is used to implement spinlock_t in PREEMPT_RT (as well as to implement rwlock_t, struct semaphore, and struct rw_semaphore).

raw_spinlock_t
Special variant of spinlock_t that offers the traditional behavior, so that critical sections are non-preemptible and _irq operations really disable hardware interrupts. Note that you should use the normal primitives (e.g., spin_lock()) on raw_spinlock_t. That said, you shouldn't be using raw_spinlock_t -at- -all- except deep within architecture-specific code or low-level scheduling and synchronization primitives. Misuse of raw_spinlock_t will destroy the realtime aspects of PREEMPT_RT. You have been warned.

rwlock_t
Critical sections are preemptible. The _irq operations (e.g., write_lock_irqsave()) do -not- disable hardware interrupts. Priority inheritance is used to prevent priority inversion. In order to keep the complexity of priority inheritance down to a dull roar, only one task may read-acquire a given rwlock_t at a time, though that task may recursively read-acquire the lock.

RW_LOCK_UNLOCKED(mylock)
The RW_LOCK_UNLOCKED macro now takes the lock itself as an argument, which is required for priority inheritance. Unfortunately, this makes its use incompatible with the PREEMPT and non-PREEMPT kernels. Uses of RW_LOCK_UNLOCKED should therefore be changed to DEFINE_RWLOCK().

raw_rwlock_t
Special variant of rwlock_t that offers the traditional behavior, so that critical sections are non-preemptible and _irq operations really disable hardware interrupts. Note that you should use the normal primitives (e.g., read_lock()) on raw_rwlock_t. That said, as with raw_spinlock_t, you shouldn't be using raw_rwlock_t -at- -all- except deep within architecture-specific code or low-level scheduling and synchronization primitives. Misuse of raw_rwlock_t will destroy the realtime aspects of PREEMPT_RT. You have once again been warned.

seqlock_t
Critical sections are preemptible. Priority inheritance has been applied to the update side (the read-side cannot be involved in priority inversion, since seqlock_t readers do not block writers).

SEQLOCK_UNLOCKED(name)
The SEQLOCK_UNLOCKED macro now takes the lock itself as an argument, which is required for priority inheritance. Unfortunately, this makes its use incompatible with the PREEMPT and non-PREEMPT kernels. Uses of SEQLOCK_UNLOCKED should therefore be changed to use DECLARE_SEQLOCK(). Note that DECLARE_SEQLOCK() defines the seqlock_t and initializes it.

struct semaphore
The struct semaphore is now subject to priority inheritance.

down_trylock()
This primitive can schedule, so cannot be invoked with hardware interrupts disabled or with preemption disabled. However, since almost all interrupts run in process context with both preemption and interrupts enabled, this restriction has no effect thus far.

struct compat_semaphore
A variant of struct semaphore that is -not- subject to priority inheritance. This is useful for cases when you need an event mechanism, rather than a sleeplock.

struct rw_semaphore
The struct rw_semaphore is now subject to priority inheritance, and only one task at a time may read-hold. However, that task may recursively read-acquire the rw_semaphore.

struct compat_rw_semaphore
A variant of struct rw_semaphore that is -not- subject to priority inheritance. Again, this is useful for cases when you need an event mechanism, rather than a sleeplock.

Quick Quiz #3: Why can't event mechanisms use priority inheritance?

Per-CPU Variables

DEFINE_PER_CPU_LOCKED(type, name)
DECLARE_PER_CPU_LOCKED(type, name)
Define/declare a per-CPU variable with the specified type and name, but also define/declare a corresponding spinlock_t. If you have a group of per-CPU variables that you want to be protected by a spinlock, you can always group them into a struct.

get_per_cpu_locked(var, cpu)
Return the specified per-CPU variable for the specified CPU, but only after acquiring the corresponding spinlock.

put_per_cpu_locked(var, cpu)
Release the spinlock corresponding to the specified per-CPU variable for the specified CPU.

per_cpu_lock(var, cpu)
Returns the spinlock corresponding to the specified per-CPU variable for the specified CPU, but as an lvalue. This can be useful when invoking a function that takes as an argument a spinlock that it will release.

per_cpu_locked(var, cpu)
Returns the specified per-CPU variable for the specified CPU as an lvalue, but without acquiring the lock, presumably because you have already acquired the lock but need to get another reference to the variable. Or perhaps because you are making an RCU-read-side reference to the variable, and therefore do not need to acquire the lock.

Interrupt Handlers

SA_NODELAY
Used in the struct irqaction to specify that the corresponding interrupt handler should be directly invoked in hardware-interrupt context rather than being handed off to an irq thread. The function redirect_hardirq() does the wakeup, and the interrupt-processing loop may be found in do_irqd().

Note that SA_NODELAY should -not- be used for normal device interrupts: (1) this will degrade both interrupt and scheduling latency and (2) SA_NODELAY interrupt handlers are much more difficult to code and maintain than are normal interrupt handlers. Use SA_NODELAY only for low-level interrupts (such as the timer tick) or for hardware interrupts that must be processed with extreme realtime latencies.

local_irq_enable()
local_irq_disable()
local_irq_save(flags)
local_irq_restore(flags)
irqs_disabled()
irqs_disabled_flags()
local_save_flags(flags)
The local_irq*() functions do not actually disable hardware interrupts, instead, they simply disable preemption. These are suitable for use with normal interrupts, but not for SA_NODELAY interrupt handlers.

However, it is usually even better to use locks (possibly per-CPU locks) instead of these functions for PREEMPT_RT environments -- but please also consider the effects on SMP machines using non-PREEMPT kernels!

raw_local_irq_enable()
raw_local_irq_disable()
raw_local_irq_save(flags)
raw_local_irq_restore(flags)
raw_irqs_disabled()
raw_irqs_disabled_flags()
raw_local_save_flags(flags)
These functions disable hardware interrupts, and are therefore suitable for use with SA_NODELAY interrupts such as the scheduler clock interrupt (which, among other things, invokes scheduler_tick()).

These functions are quite specialized, and should only be used in low-level code such as the scheduler, synchronization primitives, and so on. Keep in mind that you cannot acquire normal spinlock_t locks while under the effects of raw_local_irq*().

Miscellaneous

wait_for_timer()
Wait for the specified timer to expire. This is required because timers run in process in the PREEMPT_RT environment, and can therefore be preempted, and can also block, for example during spinlock_t acquisition.

smp_send_reschedule_allbutself()
Sends reschedule IPI to all other CPUs. This is used in the scheduler to quickly find another CPU to run a newly awakened realtime task that is high priority, but not sufficiently high priority to run on the current CPU. This capability is necessary to do the efficient global scheduling required for realtime. Non-realtime tasks continue to be scheduled in the traditional manner per-CPU manner, sacrificing some priority exactness for greater efficiency and scalability.

INIT_FS(name)
This now takes the name of the variable as an argument so that the internal rwlock_t can be properly initialized (given the need for priority inheritance).

local_irq_disable_nort()
local_irq_enable_nort()
local_irq_save_nort(flags)
local_irq_restore_nort(flags)
spin_lock_nort(lock)
spin_unlock_nort(lock)
spin_lock_bh_nort(lock)
spin_unlock_bh_nort(lock)
BUG_ON_NONRT()
WARN_ON_NONRT()
These do nothing (or almost nothing) in PREEMPT_RT, but have the normal effect in other environments. These primitives should not be used outside of low-level code (e.g., in the scheduler, synchronization primitives, or architecture-specific code).

spin_lock_rt(lock)
spin_unlock_rt(lock)
in_atomic_rt()
BUG_ON_RT()
WARN_ON_RT()
Conversely, these have the normal effect in PREEMPT_RT, but do nothing in other environments. Again, these primitives should not be used outside of low-level code (e.g., in the scheduler, synchronization primitives, or architecture-specific code).

smp_processor_id_rt(cpu)
This returns "cpu" in the PREEMPT_RT environment, but acts the same as smp_processor_id() in other environments. This is intended for use only in the slab allocator.

PREEMPT_RT configuration options

High-Level Preemption-Option Selection

  • PREEMPT_NONE selects the traditional no-preemption case for server workloads.

  • PREEMPT_VOLUNTARY enables voluntary preemption points, but not wholesale kernel preemption. This is intended for desktop use.

  • PREEMPT_DESKTOP enables voluntary preemption points along with non-critical-section preemption (PREEMPT). This is intended for low-latency desktop use.

  • PREEMPT_RT enables full preemption, including critical sections.

Feature-Selection Configuration Options

  • PREEMPT enables non-critical-section kernel preemption.

  • PREEMPT_BKL causes big-kernel-lock critical sections to be preemptible.

  • PREEMPT_HARDIRQS causes hardirqs to run in process context, thus making them preemptible. However, the irqs marked as SA_NODELAY will continue to run in hardware interrupt context.

  • PREEMPT_RCU causes RCU read-side critical sections to be preemptible.

  • PREEMPT_SOFTIRQS causes softirqs to run in process context, thus making them preemptible.

Debugging Configuration Options

These are subject to change, but give a rough idea of the sorts of debug features available within PREEMPT_RT.

  • CRITICAL_PREEMPT_TIMING measures the maximum time that the kernel spends with preemption disabled.

  • CRITICAL_IRQSOFF_TIMING measures the maximum time that the kernel spends with hardware irqs disabled.

  • DEBUG_IRQ_FLAGS causes the kernel to validate the "flags" argument to spin_unlock_irqrestore() and similar primitives.

  • DEBUG_RT_LOCKING_MODE enables runtime switching of spinlocks from preemptible to non-preemptible. This is useful to kernel developers who want to evaluate the overhead of the PREEMPT_RT mechanisms.

  • DETECT_SOFTLOCKUP causes the kernel to dump the current stack trace of any process that spends more than 10 seconds in the kernel without rescheduling.

  • LATENCY_TRACE records function-call traces representing long-latency events. These traces may be read out of the kernel via /proc/latency_trace. It is possible to filter out low-latency traces via /proc/sys/kernel/preempt_thresh.

    This config option is extremely useful when tracking down excessive latencies.

  • LPPTEST enables a device driver that performs parallel-port based latency measurements, such as used by Kristian Benoit for measurements posted on LKML in June 2005.

    Use scripts/testlpp.c to actually run this test.

  • PRINTK_IGNORE_LOGLEVEL causes -all- printk() messages to be dumped to the console. Normally a very bad idea, but helpful when other debugging tools fail.

  • RT_DEADLOCK_DETECT finds deadlock cycles.

  • RTC_HISTOGRAM generates data for latency histograms for applications using /dev/rtc.

  • WAKEUP_TIMING measures the maximum time from when a high-priority thread is awakened to the time it actually starts running in microseconds. The result is accessed from /proc/sys/kernel/wakeup_timing. and the test may be restarted via: 

    	echo 0 > /proc/sys/kernel/preempt_max_latency

Some unintended side-effects of PREEMPT_RT

Because the PREEMPT_RT environment relies heavily on Linux being coded in an SMP-safe manner, use of PREEMPT_RT has flushed out a number of SMP bugs in the Linux kernel, including some timer deadlocks, lock omissions in ns83820_tx_timeout() and friends, an ACPI-idle scheduling latency bug, a core networking locking bug, and a number of preempt-off-needed bugs in the block IO statistics code.

Quick quiz answers

Quick Quiz #1: How can semaphore critical sections be preempted in a non-preemptible kernel?

Strictly speaking, preemption simply does not happen in a non-preemptible kernel (e.g., non-CONFIG_PREEMPT). However, roughly the same thing can occur due to things like page faults while accessing user data, as well as via explicit calls to the scheduler.

Quick Quiz #2: What is a simple and fast way to implement priority inheritance from writers to multiple readers?

If you come up with a way of doing this, I expect that Ingo Molnar will be very interested in learning about it. However, please check the LKML archives before getting too excited, as this problem is extremely non-trivial, there are no known solutions, and it has been discussed quite thoroughly. In particular, when thinking about writer-to-reader priority boosting, consider the case where a reader-writer lock is read-held by numerous readers, and each reader is blocked attempting to write-acquire some other reader-writer lock, each of which again is read-held by numerous readers. Of course, the time required to boost (then un-boost) all these readers counts against your scheduling latency.

Of course, one solution would be to convert the offending code sequences to use RCU. ;-) [Sorry, couldn't resist!!!]

Quick Quiz #3: Why can't event mechanisms use priority inheritance?

There is no way for Linux to figure out which task to boost. With sleeping locks, the task that acquired the semaphore would presumably be the task that will release it, so that is the task whose priority gets boosted. In contrast, with events, any task might do the down() that awakens the high-priority task.

[Thanks to Ingo Molnar for his thorough review of a previous draft of this document].

Comments (14 posted)

Patches and updates

Kernel trees

Linus Torvalds Linux-2.6.13-rc6: aic7xxx testers please.. ?
Andrew Morton 2.6.13-rc5-mm1 ?
Chris Wright Linux 2.6.12.4 ?
Con Kolivas 2.6.12-ck5 ?
Marcelo Tosatti Linux 2.4.32-pre3 ?

Architecture-specific

Con Kolivas i386 No-Idle-Hz aka Dynamic-Ticks 5 ?

Core kernel code

Paul E. McKenney Use RCU to protect tasklist for unicast signals ?

Development tools

Con Kolivas Interbench 0.27 ?
Con Kolivas Interbench 0.28 ?
Marty Ridgeway August LTP now available ?
Petr Baudis Cogito-0.13 ?
Stephane Eranian new perfmon2 kernel patch available ?

Device drivers

Andy Fleming Gianfar PHY Layer Update ?
dmitry pervushin spi ?
Alex Aizman open-iscsi/linux-iscsi-5 Initiator ?
Todd Poynor PowerOP 0/3: System power operating point management API ?
Todd Poynor PowerOP 1/3: PowerOP core ?
Todd Poynor PowerOP 2/3: Intel Centrino support ?
Todd Poynor PowerOP 3/3: Intel Centrino cpufreq integration ?
Paul Mackerras Add pci_walk_bus function to PCI core ?
Alan Stern Don't use a klist for drivers' set-of-devices ?

Filesystems and block I/O

Dave Kleikamp jfs update ?
Hiroyuki Machida Posix file attribute support on VFAT ?
Janak Desai New system call, unshare ?

Janitorial

Christoph Hellwig consolidate sys_ptrace ?

Memory management

Adam Litke Demand faulting for large pages ?
Nick Piggin mm: remove PageReserved ?
Nick Piggin mm: remap ZERO_PAGE mappings ?
Nick Piggin mm: core remove PageReserved ?
Daniel Phillips Net vm deadlock fix (take two) ?
Daniel Phillips Net vm deadlock fix, version 5 ?
Rik van Riel non-resident page tracking ?
Yasunori Goto gurantee DMA area for alloc_bootmem_low() ver. 2. ?

Networking

Arnaldo Carvalho de Melo ANNOUNCE: Linux DCCP implementation merged ?

Security-related

David Madore capabilities patch (v 0.1) ?
Evgeniy Polyakov New asynchronous crypto subsystem [acrypto] release. ?

Miscellaneous

Andrew Morton kernel status, 4 Aug 2005 ?

Page editor: Jonathan Corbet

Distributions

News and Editorials

First Look at SUSE Linux 10.0

August 10, 2005

This article was contributed by Ladislav Bodnar

The users and fans of SUSE Linux had a reason to rejoice earlier this week. After almost a decade of being developed behind closed doors, their favorite distribution has finally opened up to outside participation - in the form of openSUSE. You'll find more about this on the Front page of this edition. Now let's take a look at the first openSUSE beta.

Early reports indicate that the result of the openSUSE development will be known as "SUSE Linux". It will be available as a free download immediately after the release, in a fashion similar to Fedora Core. However, a retail product will also be provided; this will be labeled as "SUSE Linux Pro" and, together with the printed documentation, it will include the usual non-free and commercial applications that many SUSE customers have come to expect with their boxed sets. Also, Novell is reportedly planning to give away a large number of SUSE CD/DVD sets during various conferences, user group meetings and other IT gatherings. It seems that some of the ideas behind the openSUSE initiative were borrowed from the highly successful Ubuntu project which has already created a large user and developer base despite its comparatively young age.

The first beta of SUSE Linux 10.0 for was released earlier this week. There are editions for the i386 and x86_64 architectures, both of which come in the form of four 700 MB ISO images. Additional packages are made available via FTP/HTTP on the project's main server and its mirrors. Besides the "SL-10.0-OSS-beta1" directory there is also a directory called "SL-OSS-current" which looks like a placeholder for the current development tree. At the time of writing this is just a symbolic link to the beta1 directory, but it is possible that it will eventually become a development repository of SUSE packages, similar to Red Hat's "rawhide", Mandriva's "cooker" or Debian's "sid", with daily updates.

We spent an afternoon investigating the first beta of SUSE Linux 10.0. Compared to SUSE 9.3, the installation program has been subjected to some visible changes, mostly cosmetic, but some of them indicate the direction this novice-friendly SUSE is likely to take in the future. As an example, in the desktop selection dialog users can select either GNOME or KDE, but not both, unless they opt for the advanced packages selection utility. This is in line with the installer in Novell Linux Desktop 9. The package installation step is now hidden from view, replaced by a slide show introducing SUSE Linux to users, and a vertical progress bar. The background of the GRUB boot screen is a breathtaking image of the Prague castle, while the desktop wallpaper in KDE is a detailed close-up photo of a magnificent gecko lizard. Users log in through a beautified KDM dialog. Many of these changes are clearly designed to entice novice Linux users with some eye candy, while hiding the more technical stuff behind "advanced" dialogs and tabs.

The first beta of SUSE 10.0 comes with kernel 2.6.13-rc5, X.Org 6.8.2, GCC 4.0.1, KDE 3.4.2 and a current development release of GNOME 2.11. The first impressions by users on various forums indicate that the release is fairly stable, especially the KDE desktop, but GNOME is considerably less polished (which is probably not SUSE's fault). Our experiences were similar - even as the first beta it is a lot more usable than the first test release of Fedora Core 4. Java packages, and everything that requires them, including OpenOffice.org, are not available on the CDs, but can be installed separately. The YaST Control Center has also undergone some cosmetic changes.

According to the roadmap, the first beta of SUSE 10.0 will be followed by three more beta releases and one release candidate, roughly in weekly intervals. The final release is scheduled for the middle of September. At first glance, the stated goal of "beginner-friendliness" is still some distance away, especially when comparing this release to the latest versions of Xandros Desktop or Linspire, so it will be interesting to watch the development process to see what new ideas the Novell management and SUSE development team come up with. Given the limited amount of time available to complete the process, don't expect many exciting new features. SUSE Linux 10.0 seems like a test run to establish good communication and bug reporting resources between the developers and testers, rather than a break-through release with universal appeal.

Comments (none posted)

New Releases

Novell launches openSUSE.org

The Novell sponsored openSUSE.org project is a community program providing free, easy access to SUSE Linux and a chance to join in its development. SUSE Linux 10.0 Beta 1 (code name: Prague), "an unsupported, open source only, preliminary edition of SUSE Linux that contains bleeding-edge packages and represents the latest development snapshot" is available for download. The final release of 10.0 is scheduled for September 28, 2005.

Comments (11 posted)

Distribution News

Red Hat: Fedora Foundation moving forward

Red Hat has published a press release describing progress in the creation of the Fedora Foundation. "Organizational aspects of establishing the Fedora Foundation are progressing rapidly. Bylaws leading to the incorporation of the Foundation have been drafted and initial board members are being selected. Fedora Projects also continue with strong community involvement. The launch of the Foundation is expected to accelerate these projects." The Foundation is also apparently intended to accumulate a patent pool of its own.

Comments (none posted)

The Debian Core Consortium launches

The much-rumored Debian Core Consortium has finally announced its existence. "Founding members of the Alliance include credativ, KNOPPIX, LinEx, Linspire, MEPIS, Progeny, Sun Wah, UserLinux, and Xandros. The initial release of the Debian Common Core, expected in the September time frame, will be based on Debian 3.1 ('Sarge') and certified to LSB. The common core will be the basis for future releases of each member's Linux products, and the DCC Alliance will serve as a single point of contact for software and hardware vendors who want to ensure that their products will work with Debian."

Comments (16 posted)

Debian Project mourns the loss of Jens Schmalzing

The Debian Project has lost a member of its community. Jens Schmalzing died on July 30th in a workplace accident in Munich. "Jens was involved in Debian as a maintainer of several packages, as supporter of the PowerPC port, as a member of the kernel team, and was instrumental in taking the PowerPC kernel package to version 2.6. He also maintained the Mac-on-Linux emulator and its kernel modules, helped with the installer and with local Munich activities. The kernel team dedicates the 2.6.12-2 release to him."

Full Story (comments: none)

Debian - Removing packages from testing (FAQ)

The testing branch is due for some weeding. Packages that have release critical bugs may be weeded out of etch if those bugs aren't fixed soon. "During the Bug Squashing Party happening last weekend the release team also hinted a lot of packages for removal from testing. Since this is something that can happen to all maintainers at any point of the release process, we want to refresh why and how testing removals happen. (Attached to the mail you can also find a list of all packages removed from testing during the weekend)"

Full Story (comments: none)

The Perfect Setup - Mandrake/Mandriva 10.2

Falko Timme has published a how-to article with detailed information on setting up a server on a Mandriva 10.2 system. "This is a detailed description about the steps to be taken to setup a Mandrake 10.2 based server that offers all services needed by ISPs and hosters (web server (SSL-capable), mail server (with SMTP-AUTH and TLS!), DNS server, FTP server, MySQL server, POP3/IMAP, Quota, Firewall, etc.). In addition to that I will show how to use Debian's package manager apt on an rpm-based system because it takes care of package dependencies automagically which can save a lot of trouble."

Comments (1 posted)

New Distributions

New cdmedic live CD 6.2 version (LinuxMedNews)

LinuxMedNews covers the release of version 6.2 of the CDMEDIC live CD. CDMEDIC is a Knoppix-based live CD with software appropriate for radiologists, nuclear medicine and radiotherapy physicians and MDs, neurologists and neurosurgeons and also other branches related to medical imaging.

Comments (none posted)

Distribution Newsletters

Debian Weekly News

The Debian Weekly News for August 9, 2005 looks at release critical bugs in etch, assessing the risk of a package upload, GNUstep in Debian, the Debian Core Consortium, a MySQL upgrade, GNOME in etch, the new debian-science mailing list, and more.

Full Story (comments: none)

Gentoo Weekly Newsletter

The Gentoo Weekly Newsletter for the week of August 8, 2005 is out. This edition covers the first Gentoo installer, blocking Tor users from the forums, and several other topics.

Comments (none posted)

DistroWatch Weekly, Issue 112

DistroWatch Weekly for August 8, 2005 is out. This edition looks at openSUSE, the Slackware code freeze, a VidaLinux feature, an interview with Robert Lange of VectorLinux, tips and tricks with Konqueror and Kate and more.

Comments (none posted)

Package updates

Fedora updates

Fedora Core 4 updates: readahead (fix inverted free memory test), yaboot (eliminate unneeded check), ttmkfdir (includes Asian TrueType fonts), selinux-policy-targeted (bump for FC4).

Fedora Core 3 updates: ttmkfdir (includes Asian TrueType fonts).

Comments (none posted)

Slackware updates

Slackware has a few updates this week, including some ham radio package updates. Click below for a look at this week's change log.

Full Story (comments: none)

Trustix TSL-2005-0039

Trustix has updated several packages for TSL 2.2 & 3.0. Click below for details on bug fixes in fetchmail, iptables, mod_fastcgi, mysql, php, postfix, ppp, setup and sqlgrey.

Full Story (comments: none)

Distribution reviews

Damn Small Linux 1.4 Review (GNUman.com)

GNUman.com reviews Damn Small Linux 1.4. "Fluxbox is the window manager, chosen for size, speed and functionality, it is a nice desktop to work with; although it has a 'taskbar' at the bottom of the screen, to open the menu you should right-click on the desktop. Of course there are shorcuts to the most popular programs on the desktop to save you time looking for them, but at some point you will want to see what else this tiny operating system can do. DSL comes loaded with software; from the popular Mozilla Firefox web-browser and Axyftp, Nirc and Naim for communication, and xmms for music, right up to sshd, ftpd,Damn Small Linux default startup the 'monkey' httpd and even smb4k to allow access to and from network file shares; allowing you to set up a fully (multi) functional server straight from the cd."

Comments (none posted)

SymphonyOS - Act II (Alpha 4) (tuxmachines.org)

tuxmachines.org reviews SymphonyOS Alpha4. "Overall Alpha 4 is an exciting development release. It shows wonderful improvement and future promise. Although a few problems were encountered, it performed very well for an alpha/development product. It just makes one even more anxious for a production quality release."

Comments (none posted)

Review: Slax 5.0.6 (Linux.com)

Linux.com reviews Slax. "The first time I used it, Slax restored my faith in my old clunker of a Toshiba laptop. The distribution ran (and even booted) faster from the CD-ROM drive than Windows did from the hard disk. But as I began to get a feel for Slax and use it to browse the Web, listen to music, and the like, I didn't feel like Slax had sacrificed usability for agility. This fine balance alone would make Slax an interesting and noteworthy distro, but it has even more tricks up its sleeve."

Comments (none posted)

Mandrake Revisited: A Lycoris user revisits the OS he left years earlier (DesktopOS.com)

DesktopOS.com has a review of Mandrake 10.2 Limited Edition. "Several years ago, Linux desktops were not very refined. Mandrake seemed to be the best of the bunch, with a nearly usable desktop. I held out hope that it would become the best desktop Linux, since it seemed so far ahead of the competition. But as time went on, they kept releasing buggy software, and by version 8.2, the system I had was clunky and slow; the menu was cluttered with broken programs. Overall I found it to be unstable and unusable. I gave up on Mandrake and chose Lycoris DLX instead, as it seemed a better, more functional desktop environment with more promise."

Comments (none posted)

Page editor: Rebecca Sobol

Development

The Cairo Vector Graphics Library

Cairo (formerly Xr/Xc) is a C language vector graphics library that is available under the GNU Lesser General Public License (LGPL) and the Mozilla Public License (MPL):

Cairo is a vector graphics library designed to provide high-quality display and print output. Currently available backends include the X Window System, OpenGL (via [WWW]glitz), Quartz, win32, in-memory image buffers, PNG images, PostScript, and PDF files. Some of these backends are still experimental. Cairo is designed to produce identical output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension or OpenGL). Cairo provides a stateful user-level API with capabilities similar to the PDF 1.4 imaging model. Cairo provides operations including stroking and filling Bézier cubic splines, transforming and compositing translucent images, and antialiased text rendering.

[Cairo] The language and toolkit bindings include a large collection of popular languages, .NET, GTK+, and GNUstep. Apparently, Qt bindings do not exist yet, but they are mentioned as a possibility.

The Cairo online documentation includes a manual with API documentation and information on creating backends and language bindings, a fairly limited FAQ, and some tutorial materials.

The Cairo examples list some important projects that currently use or plan to use Cairo. The code samples documentation presents an excellent pairing of example code snippets along with the resulting imagery. Take a look for examples of Cairo's real capabilities.

LWN.net covered a talk on Cairo and some associated applications by project developer Carl Worth at the 2005 LinuxConf.au.

Cairo release 0.9.0 was announced this week, it is a development release with a focus on an API freeze. "The cairo 1.0 release will be source and binary compatible with the cairo 0.9.x series. All API changes in cairo 0.9.x are finalized at this point, and cairo 0.9.x should be considered API frozen. Barring discovery of serious issues with the new APIs, no API changes are anticipated between this release and the 1.0 release."

If you want to experiment with the software, the Cairo download site includes CVS access, tar files, Debian packages, and links to a few dependencies.

Comments (1 posted)

System Applications

Database Software

Firebird 2 Alpha 3 Linux Builds are available

Alpha 3 builds of the Firebird 2 database have been announced. "The Firebird Project is pleased to announce that regular and NTPL Linux builds of Firebird 2 Alpha 3 are now ready for testers to download."

Comments (none posted)

Interoperability

Samba 3.0.20rc2 is available

Release 3.0.20rc2 of Samba is available for testing. "This is the second release candidate of the 3.0.20 code base and is provided for testing purposes only. While close to the final stable release this snapshot is *not* intended for production servers. If all goes well, this could become the final 3.0.20 release."

Full Story (comments: none)

Mail Software

DomainKeys library 0.67 available (SourceForge)

Version 0.67 of the DomainKeys library, a set of cross-platform tools for adding DomainKeys functionality to mail software, is available. "This is a bugfix release. Apart from bugfixes, the next release will be DKIM compatible, once that standard settles down a bit. This project provides a general purpose set of tools, C library and CPAN modules to help DomainKeys developers. The goal is that these tools and library can be easily adopted by all MTAs, LDAs and possibly MUAs. This project is about conforming to the DomainKeys standard."

Comments (1 posted)

Networking Tools

AF version 0.7.2 released

Version 0.7.2 of AF, the active port forwarder, has been released. See the change log for details. "Active port forwarder is a software tool for secure port forwarding. It uses SSL to increase security of communication between a server and a client. Originally, it was developed to forward data point to point. However, the need for bypassing firewalls in order to connect to internally located computers influenced the further development of the project. AF is dedicated for people, who don't have an external ip number and want to make some services available across the net."

Comments (none posted)

Scapy 1.0.0 Released

Version 1.0.0 of Scapy, an interactive packet manipulation tool, packet generator, network scanner, network discovery tool and packet sniffer, is out with major feature enhancements. "This release works on most Unix variants. It has color themes, many new protocols (ISAKMP, SMB, etc.), 802.11 WEP support, graphing capabilities, and better support for extensions."

Comments (none posted)

Web Site Development

Gallery 2 Release Candidate 1 Released (SourceForge)

Release candidate 1 of Gallery 2, a web-based photo management application, has been announced. "We have made small improvements since the Beta 4 release. One new thing you'll notice is that now we offer up 4 different flavors of packages for you to download so that you can pick one that suits your needs. This will make it easier for those of you who are using FTP to transfer Gallery up to your webserver."

Comments (2 posted)

Miscellaneous

demexp 0.6 released

Stable version 0.6 of demexp, an electronic voting system, has been released. "Compared to previous stable version 0.4, version 0.6 mainly focuses on making the client more user friendly: support of demexp:// URL, support of multiple servers at once, change tracking on the server, caching."

Full Story (comments: none)

DSpace 1.3.1 Released (SourceForge)

Version 1.3.1 of DSpace, a Java-based Digital Asset Management system, has been released. "This stable release includes the many new features developed by members of the DSpace community in 1.3 and fixes an installation problem."

Comments (none posted)

Desktop Applications

Audio Applications

Ecasound 2.4.2 released

Version 2.4.2 of Ecasound, a multi-track audio recording application, is out. The release notes explain the changes. "Ecasignalview user-interface has been improved. A set of new commands for modifying effect parameters was added to interactive mode. Many bugs have been fixed in documentation, JACK transport support, build system and elsewhere. A severe bug in the "reverse" audio object was fixed."

Comments (none posted)

JAPA Jack/Alsa Perceptual Analyser initial release

The initial release of JAPA, the Jack/Alsa Perceptual Analyser is available. "JAPA is a 'perceptual' or 'psychoacoustic' audio spectrum analyser. This means that the filters that are used to analyse the spectrum have bandwidths that are neither constant (as in JAAA), nor proportional to the center frequency (as in a 1/3 octave band analyser), but tuned to human perception."

Full Story (comments: none)

Rivendell Radio Automation System 0.9.48 released

Version 0.9.48 of the Rivendell Radio Automation System is available with bug fixes and new features. "Rivendell is a full-featured, copylefted broadcast automation system targeted for use in professional radio broadcast environments. It includes tools for acquisition, management and playout of audio content."

Full Story (comments: none)

Business Applications

Give Your Business Logic a Framework with Drools (O'ReillyNet)

Paul Browne looks at Drools on O'Reilly. "It's almost too easy to express your business logic as a spaghetti-code fiasco. The result is hard to test, hard to maintain, and hard to update. Rule engines offer an alternative: express your business logic as rules, outside of your Java code, in a format even the business side of the office can understand. Paul Browne uses the open source Drools framework to introduce the idea."

Comments (none posted)

Desktop Environments

GNOME 2.12 Beta 2 released

Version 2.12 Beta 2 (a.k.a. v2.11.91) of the GNOME desktop has been announced. "This release is a feature, user interface, and string frozen snapshot primarily intended for wide public scrutiny before the final GNOME 2.12 release in September. GNOME uses odd minor version numbers to indicate development status."

Full Story (comments: none)

GNOME Software Announcements

The following new GNOME software has been announced this week:

Comments (none posted)

KDE Software Announcements

The following new KDE software has been announced this week:

Comments (none posted)

KDE Commit Digest (KDE.News)

The August 5, 2005 edition of the KDE Commit-Digest has been announced. Here's the content summary: "KSpread improves range functions. KMobileTools adds addressbook import and export to VCard and KdeAddressBook. Umbrello adds Tcl code generator. KMail now has full text indexing. Kontact scripting (a Summer of Coding project). And the first (somewhat) working KDEMM backend based on aRts."

Comments (none posted)

KDE 3.5 Alpha 1 Finally on FTP (KDE.News)

KDE.News mentions the availability of KDE 3.5 Alpha 1. "To begin the KDE 3.5 release cycle, I uploaded KDE 3.5 Alpha 1 to the FTP servers. We're facing some trouble that is typical for an Alpha release, but it also brings some nice KDE 3.5 features to your desktop."

Comments (none posted)

PYWM 0.1.0 released

Version 0.1.0 of PYWM, a Python version of the FLWM window manager, has been announced. "PYWM is a small, simple python-programmable X window manager that's packed with features yet very easy to learn and use. Some window managers are mouse heaven and keyboard hell. Other window managers are the other way around. But PYWM aims to be very comfortable to use from either."

Comments (none posted)

Fonts and Images

Open Clip Art Library Release 0.16

Release 0.16 of the Open Clip Art Library, a collection of over 4000 images, is available. "This releases squishes a major bug that replaced valid keywords in the clip art files with some strange HASH memory location text. Most of the clip art in the library and this release is now repaired."

Full Story (comments: none)

Games

Phil's pyGame Utilities 1.0 released

Version 1.0 of Phil's pyGame Utilities, a collection of gui, engine, layout, text and HTML libraries, has been announced. Numerous changes are included.

Comments (none posted)

Imaging Applications

What The GIMP (GnomeDesktop)

GnomeDesktop.org looks forward to the GIMP 2.4 release. "Until now, creating a selection mask for an object was mostly equivalent to either a slow step-by-step approximation to a certain shape or a tedious manual drawing of the selection. SIOX ('Simple Interactive Object eXtraction') allows a semi-automatic pixel-accurate selection of typical foreground objects like portraits of humans, animals, or plants with only a few mouse clicks."

Comments (4 posted)

Interoperability

Wine Traffic

The August 5, 2005 edition of Wine Traffic is available. Topics include: a Xandros Review, AppDB improvements, PeekMessage and Performance and Turning off Anti-Aliasing.

Comments (none posted)

Music Applications

KMidimon 0.3 released

Version 0.3 of KMidimon has been released with several new features. "KMidimon is an application to monitor MIDI events coming from a MIDI external port or application via the ALSA sequencer. It is especially useful if you want to debug MIDI software or your MIDI setup."

Full Story (comments: none)

liboscqs 0.0.3 - An OSC Query System

Version 0.0.3 of liboscqs has been announced. "liboscqs is a library to provide a Query System and Service Discovery for applications using the Open Sound Control (OSC) protocol."

Full Story (comments: none)

Office Suites

OpenOffice.org build 1.9.121.1 released

Build 1.9.121.1 of OpenOffice.org has been announced. Changes include bug fixes and a few new features.

Full Story (comments: none)

PDA Software

jSyncManager v3.2 beta 01 released (SourceForge)

Version 3.2 beta 01 of jSyncManager has been announced. "The jSyncManager Development Team is pleased to announce the releases of version 3.2 beta 01 of the jSyncManager Core Application Set, API, and Core jConduit Bundle. This beta release is considered feature complete, and requires user testing to ensure that new functionality added in this release cycle functions correctly. The jSyncManager is a pure Java protocol stack, development environment, and application set for synchronizing PalmOS-based handheld devices. It contains its own object-oriented protocol stack, and thus does not rely upon any platform-specific code to synchronize data."

Comments (none posted)

Miscellaneous

Gourmet 0.8.5.10 released (SourceForge)

Version 0.8.5.10 of Gourmet, a recipe manager for the GNOME Desktop, is available. "Version 0.8.5.10 fixes a lag when adding ingredients by hand. Gourmet Recipe Manager is a recipe-organizer that generates shopping lists and allows rapid searching of recipes. It imports mealmaster & mastercook files and exports webpages & other formats."

Comments (1 posted)

OmegaT 1.4.5.03 released (SourceForge)

Version 1.4.5.03 of OmegaT, has been announced. "OmegaT project is proud to announce the OmegaT 1.4.5.03 -- a high performance Java based Computer Assisted Translation tool featuring Fuzzy matching, Translation memory, Keyword search, Glossary term identification, and Translation leveraging into updated projects. Release 1.4.5.03 features a German Manual (thanks goes to Martin Wunderlich) and a small usability bugfix."

Comments (none posted)

Languages and Tools

Caml

Caml Weekly News

The August 9, 2005 edition of the Caml Weekly News is online. Topics include: ocamlsdl natively for Windows?, ocamllex problem and right-associating infix application operator camlp4 extension.

Full Story (comments: none)

Haskell

Haskell Weekly News

The August 9, 2005 edition of the Haskell Weekly News is online with this week's Haskell news. Highlights of this week's issue include new bindings for GnuTLS and OpenLDAP, a new version of Haddock, and discussions on parsing other languages in Haskell.

Comments (none posted)

Lisp

Status reports of Lisp projects for Summer of Code

Some status reports for Lisp projects from the Google Summer of Code event are online.

Full Story (comments: none)

Perl

POE 0.32 Released (SourceForge)

Version 0.32 of POE, a networking and multitasking framework for Perl, is available. "Version 0.32 is mainly a bugfix and portability release: Better support for ActiveState Perl and Cygwin were added, and several bugs were removed."

Comments (none posted)

This Week in Perl 6 (O'Reilly)

The August 8, 2005 edition of This Week in Perl 6 is online with the latest Perl 6 development news.

Comments (none posted)

Tcl/Tk

Dr. Dobb's Tcl-URL!

The August 10, 2005 edition of Dr. Dobb's Tcl-URL! is out with the latest Tcl/Tk news and resources.

Full Story (comments: none)

XML

Appreciating Libxslt (O'Reilly)

Bob DuCharme explores libxslt on O'Reilly. "The two most well-known XSLT processors are probably the Apache project's Xalan (available in both a Java and C++ version) and the Java-based Saxon, which was written by XSLT 2.0 specification editor Michael Kay. If those are the only two XSLT processors you currently use, it's worth checking out Daniel Veillard's libxslt. Its origins (and that of libxml2, the XML processor that it uses) in the GNOME project give it a higher profile in the Linux world, but Windows and Macintosh ports are easy to install and use."

Comments (none posted)

Cross Assemblers

gputils 0.13.3 released

Version 0.13.3 of gputils, the GNU PIC Utilities, is out with bug fixes.

Comments (none posted)

Profilers

Valgrind 3.0.0 (for x86 and amd64) is available

Version 3.0.0 of Valgrind, a suite of simulation based debugging and profiling tools, is out. "3.0.0 is the first Valgrind to support both x86-linux and amd64-linux. Support for ppc32-linux is also integrated but does not work well enough to be useful yet. There have been many other improvements and refinements relative to the 2.4.X line."

Full Story (comments: none)

Test Suites

Programming Tools: FitNesse (Linux Journal)

Reg. Charney looks at FitNesse on Linux Journal. "FitNesse is a collaborative tool based on a wiki that allows users, developers and testers to define, modify and delete tests. These tests are more like usage scenarios. You define what you expect to put into the system and what you expect to get out. The FitNesse framework runs your test and displays the results on a wiki page. To make it all work, FitNesse comes with its own simple server, so no other software is required.

Comments (none posted)

Version Control

Monotone 0.22 released

Monotone 0.22 is out. This is "mostly a bug fix and smoothing-things-out release", but it does also include a switch to the botan cryptographic library. Some configuration changes may be required when upgrading; see the announcement for details.

Full Story (comments: none)

Page editor: Forrest Cook

Linux in the news

Recommended Reading

Qt, the GPL, Business and Freedom (OfB)

Open for Business looks at Qt, the GPL, Business and Freedom. "To me FOSS as Richard Stallman has set in motion with the GNU GPL is about the greater good of humanity as opposed to the selfish greed of a few people. The GPL has insured the freedom of users while showing that the closed development model has real flaws. Let's not lose site of what's important. Our community provides the moral center at probably the most pivitol point in history. 500 years ago the printing press ended the dark ages with an unprecedented sharing of ideas. The internet offers dramatically more potential."

Comments (37 posted)

Foolproofing Open Source (Business Week)

OSDL CEO Stuart Cohen has written a BusinessWeek column on the GPLv3 process and software patents. "The idea is that a pool of software licenses and software patents (issued and pending) are held in something like a virtual trust for the benefit of both developers and users of open-source software. In general, the vendors who make this pledge are promising not to litigate against people and companies whom they might otherwise sue... We like this idea so much that we're about to take it one step further. We're establishing an OSDL patent commons project that aims to centralize the good works of these vendors, as well as future individuals and organizations who may wish to pledge patents."

Comments (1 posted)

Trade Shows and Conferences

OSCON: Sun, Yahoo, Google -- and maybe you (NewsForge)

NewsForge presents coverage of the O'Reilly Open Source Convention. "After two days of tutorials, O'Reilly's OSCON Open Source Convention began in earnest yesterday by highlighting some unusual approaches to open source software development and use, including Sun's contention that OpenSolaris should be compared to Linux less on ideology and more on a technical basis. Sun COO Jonathan Schwartz asserted that his company's recently opened operating system was bringing more competition and choice to the community and that beyond ideological differences, was comparable to Linux. "Let's compare them," he said. "It's no longer about competing with a social movement. Let's get the politics out of the way we talk about competition.""

Comments (6 posted)

Business for Geeks at OSCON 2005 (O'ReillyNet)

O'ReillyNet covers Marc Hedlund's tutorial on starting a small business and getting funding, at OSCON 2005. "Marc Hedlund, O'Reilly Media's entrepreneur-in-residence, says that if you are like most engineers, you will have twenty slides about the product and maybe one describing the team. Hedlund explains that this is not the way to raise money. There are many practical decisions you will need to make if you want to start up a business around a product or service."

Comments (none posted)

OSCON 2005: Know When to Fold 'Em (O'ReillyNet)

O'ReillyNet covers an OSCON keynote comparing the development of origami to the development of open source software. "But much about origami changed as we entered the modern era of folding about fifty years ago. Akira Yoshizawa created new figures of artistic beauty. His new creations were certainly groundbreaking and pushed the art in new directions, but Lang explained that an even more important contribution was Yoshizawa's language for communicating designs. "He developed a written instructional language. A way of presenting origami information. This was the Hypertext Transfer Protocol of origami. It was created in 1950 and we've had 50 years to build on it.""

Comments (none posted)

Getting in touch with the feminine side of open source (NewsForge)

NewsForge wraps up OSCON with a look at a panel discussion about women in open source (or the lack thereof). "One key theme of the discussion was the fact that women in open source tend to be involved in management, marketing, and leadership roles, but they do not tend to excel in the more technical aspects of software development, with some notable exceptions, including Allison Randal, a key Perl developer and president of the Perl Foundation."

Comments (29 posted)

Linux World - the articles

Here is a small selection of today's LinuxWorld articles:

Comments (1 posted)

Linux Shows Its Maturity (IT-Director)

IT-Director looks at some corporate announcements from LinuxWorld. "These announcements, and many others at the show, accurately illustrate just how rapidly Linux has moved from being a techie's plaything to become a mature, enterprise-class operating platform. The suppliers of Linux solutions are now moving beyond the development of pure technology features into delivering usable solutions to mainstream business issues."

Comments (none posted)

Database start-ups bet on open source (News.com)

News.com reports on the state of open source database systems from LinuxWorld. "The growing number of technology companies betting their businesses on open-source database products reflects a gradual shift in corporate spending patterns, according to analysts and industry executives. With many companies familiar with Linux, the Apache Web server and open-source development tools, databases are an obvious next step."

Comments (none posted)

On the Extreme Fringe of XML (O'Reilly)

Roger Sperberg covers the Extreme Markup Languages 2005 conference on O'Reilly. "The "X" in XML stands for "extensible." It doesn't stand for "expert" or "extreme." But when I think of XML I always think of the Extreme Markup Languages conference as the place to become expert in XML. I say it's where the graduate seminars in XML are held."

Comments (none posted)

The SCO Problem

So, Now What Happens to SCO? (Groklaw)

Groklaw considers the future of SCO. "Novell's recent Answer and Counterclaims has some asking, now what happens? What does it mean? To help you out, I found two articles that I think grasp the possibilities. First, there's Frank Hayes's article, Novell to SCO Group: Drop Dead. At least one reporter has comprehended the magnitude of what Novell has done, I see, and found a simple way to express SCO's worst case scenario. Hayes begins like this: "You might not know it from some of the coverage, but The SCO Group now appears to be facing annihilation in its lawsuits against IBM, Novell, Red Hat and Linux users AutoZone and DaimlerChrysler.""

Comments (7 posted)

Linux Adoption

What's Driving Global Linux Adoption? (LinuxWorld.au)

LinuxWorld takes a look at some the driving forces behind Linux adoption. "India is home to more than 22 languages, many with unique alphabets. The impact this has on the production and distribution of textbooks for schoolchildren or the ability for local governments to collaborate on larger initiatives is gigantic. India sees opportunity in utilizing Linux and other open-source technologies to educate its population. With low overhead investment, Linux provides a pathway to e-education, enabling access to information for all students -- students who speak different languages and students who live in remote areas of the country. In the same way, Linux can enable e-medicine, e-governance and e-business throughout India."

Comments (none posted)

Legal

Will Congress Ban Municipal WiFi? (O'ReillyNet)

O'Reilly covers new legislation that could disallow municipal wireless systems in the US. "The recently introduced U.S. Senate bill, called the Broadband Investment and Consumer Choice Act of 2005, may spell the end for municipal wireless. Among other things, the bill says that when there is a case of competing bids between a private company and local government, preference will be given to the private company. Richard Koman reports on the implications of this bill and what it could mean for consumers long-term."

Comments (15 posted)

Suspicions fade over Linux trademark move (ZDNet)

ZDNet Australia looks into a legal situation involving the Linux trademark. "Linux Australia (LA) has moved to reassure the community that letters sent out by a lawyer acting on behalf of Linus Torvalds are part of a legitimate process to ensure the open source software's creator maintains control of the 'Linux' trademark. Perth-based lawyer Jeremy Malcolm has recently written to Australian Linux vendors asking them to relinquish any legal claim to the name Linux and purchase a licence for its use from the worldwide trademark owner. LA's president Jon Oxer acknowledged there had initially been some suspicion about the legitimacy of the letters and pointed worried community members to his recent blog entry on the subject."

Comments (none posted)

New legal code (Spectrum)

IEEE Spectrum returns to the software patent debate with a suggestion. "There is no sensible means of reconciling an industry that has massive independent invention with a law that makes independent invention a liability. So what's the solution? How can we protect programmers and companies that invest in developing innovative new software from being ripped off--without tying the entire software industry up in red tape? The answer is copyright." (Thanks to Mark H. Weaver).

Comments (none posted)

Who'll Fill the Gap in the Gateway Security Market? (eWeek)

Here's an eWeek article about the Trend Micro antivirus patent and a possible open source victim. "In fact, ClamAV is a particularly interesting problem, at least if Trend Micro decides to pursue it. ClamAV has become somewhat popular among the 'roll your own gateway security' crowd, and I think it's fair to say that ClamAV's main application is as an SMTP proxy. I would be surprised to see Trend go after ClamAV itself, and the ITC wouldn't be the place to do it, but I wouldn't be surprised to hear that letters have been sent to some of the other commercial redistributors of ClamAV, such as Apple." (Thanks to Barry Gould).

Comments (none posted)

Interviews

People Behind KDE: Nuno Pinheiro

The People Behind KDE present an interview with Nuno Pinheiro. "In what ways do you make a contribution to KDE? In as many ways as I can, but the thing I mostly work on is making Crystal icons. I also help as much as I can in making artistic documentation. I did some logos for realy cool projects, like Plasma, and also some layouts for KDE related web sites, like this one ;). Together with Robert Wadley we are making a Crystal icon set for OpenOffice.org. This work is mostly done now and it will enter a new development cycle, because many of the icons have to be improved. And last, I'm working with David Vignoni on a new icon set named Oxygen. I'm very excited about this."

Comments (none posted)

Mitchell Baker Quizzed on Mozilla Corporation (MozillaZine)

MozillaZine points to an interview with Chief Lizard Wrangler Mitchell Baker. The interview focuses on the creation of the Mozilla Corporation, is available as a podcast or MP3 download.

Comments (6 posted)

Featured Artist: Bastian Salmela (KDE-Artists.org)

KDE-Artists.org features an interview with Bastian Salmela. "Bastian Salmela, (aka basse) is best known in the KDE community for his Konqi artwork and his Magical Rope animated short. He also very active in the Blender community. Bastian is a long time Linux user who has done work on several games and recently has been selected as a lead animator for Orange "the Open Source movie project"."

Comments (none posted)

Resources

New Audio Libre Article on LinuxSampler and QSampler

Linuxaudio.org has a new Audio Libre article (in PDF format) on the LinuxSampler project and QSample entitled: Breaking out of the loop - LinuxSampler and QSampler.

Comments (none posted)

Reviews

The Arrival of NX, Part 3 (Linux Journal)

Linux Journal continues an examination of NX technology. This article delves into NX Compression, NX Cache and NX Roundtrip Elimination. "Before, we asked, "How important is round-trip elimination?" Now that you understand the basics of how X works across the network, the importance of being intolerant towards unnecessary roundtrips is obvious to you. You now should be aware of how much the latency of any link, especially a slow one, weighs in to make a remote connection feel slower with every additional roundtrip that takes place. Every roundtrip saved is a little boost for GUI responsiveness."

Comments (none posted)

Dia straights (and curves and network diagrams) (NewsForge)

NewsForge reviews Dia, a diagram creation program. "Are you designing a new program and need to put a process into a flowchart? Do you need an entity relationship diagram for a database? Do you need to document the management structure for a new department? If so, try Dia, a useful and usable open source diagramming application available for both Linux and Windows."

Comments (none posted)

Nexuiz: Open source deathmatch (NewsForge)

NewsForge reviews the game Nexuiz. "Nexuiz is free software, so anyone can download, modify, and share it as they see fit. It's put together by volunteer programmers and artists, and for the most part they did a great job on it. The program itself is stable, and it worked on most of the distributions I tested it on. The sound and animation are decent, though not up to modern standards. Playing Nexuiz will give you a Quake 3-like experience in terms of gameplay, graphics, and sound."

Comments (23 posted)

Page editor: Forrest Cook

Announcements

Non-Commercial announcements

CodeWeavers launches Wine Installer Challenge

CodeWeavers has announced the Wine Installer Challenge "We are on a mission to improve Wine until it can run nearly every Windows program, and we would like your help. Over the past year we've completed support for a set of technologies key to making Windows applications install: the Component Object Model (COM aka OLE) DLLs and the Microsoft Installer service (MSI). That work is now largely done, and we would like to start taking advantage of it to showcase what Wine can do. The basic idea is that if you send us a piece of software, we will commit to making it install. In exchange, we need you to promise to run a regression test of that installation, thereby insuring that it continues to install into the future."

Comments (none posted)

OSDL announces Patent Commons Project

Here is the announcement for OSDL's "patent commons" project. Details are scarce, but it looks like a way for individual developers to contribute patents to a pool where they would be licensed for use in free software - and, presumably, as a defensive weapon in the case of a patent-based attack on free software. The PR includes endorsements from Linus Torvalds and Eben Moglen.

Comments (12 posted)

Commercial announcements

Equilibrium announces dynamic MediaRich Server for Linux

Equilibrium has announced the availability of Equilibrium MediaRich(r) Server for Linux. Equilibrium MediaRich Server for Linux is server-based media templating software that automates image production and enables the dynamic delivery of visual assets to any Web server cache and multi-channel device.

Full Story (comments: none)

JasperSoft Unveils JasperReports DBA Dashboard for MySQL

JasperSoft has announced the release of JasperReports DBA Dashboard. "The open source JasperReports DBA Dashboard for MySQL is designed to give MySQL administrators the ability to monitor performance and use, plus identify problems across an unlimited number of MySQL database servers."

Comments (none posted)

Indiana Schools test desktop Linux machines

Linspire, Inc. has announced a test of Linux-based desktop systems by the Indiana school system. "Linspire, Inc. and Wintergreen Systems announced today that Indiana high schools are currently testing desktop Linux machines in school systems across the state as part of a plan to provide every public high school student with a computer. If successful, the plan, called the Indiana Access Program, will provide each high school student in the state with an individual desktop Linux computer for instructional use in each classroom they visit during the day -- meaning a potential 300,000 Linux machines could be deployed over coming years."

Comments (10 posted)

Novell Appoints Susan Heystee as President, Novell North America

Novell, Inc. has announced the appointment of Susan Heystee as president of Novell North America. "Heystee joined Novell in March 2004, as vice president and area general manager for the Midwest. She is an accomplished leader in the enterprise software and services industry, having held senior positions with SSA Global and Baan, where she was executive vice president, worldwide sales and delivery, and also served as president, Baan Americas."

Comments (none posted)

OSDL Claims Linux Making Major Gains in Global Retail Sector

Open Source Development Lab has announced that Linux is rapidly expanding in the $6 Trillion annual retail industry. ""We are seeing significant Linux adoption in the retail sector as companies look for flexibility, reliability and low cost as their legacy IT systems near end of life," said Stuart Cohen, CEO of OSDL. "The increasing availability of Linux-based solutions from both major vendors and ISVs is accelerating the trend. In retail, it's all about lowering costs, streamlining supply chains, and improving margins.""

Comments (none posted)

PathScale and Absoft release Software Development Kit for AMD Opteron Clusters

PathScale and Absoft have announced general availability of Absoft's new High Performance Computing Software Development Kit (HPC SDK) optimized for clusters based on AMD's 32- and 64-bit AMD Opteron processors running Linux and featuring Fortran and EKOPath C++ compilers from PathScale.

Full Story (comments: none)

REALbasic 2005 Release 2 Ships

A new release of REALbasic 2005, a cross-platform BASIC language IDE, has been announced. "REALbasic 2005 Release 2 is currently available for Windows and Macintosh. The REALbasic for Linux Public Beta has been also updated. REALbasic for Linux is scheduled for release later this month."

Comments (none posted)

Red Hat VP to Oversee Open-Source Software Practice for Squire, Sanders & Dempsey

The law firm of Squire, Sanders & Dempsey L.L.P. has announced that former Red Hat Vice President Bryan A. Sims has joined the firm to spearhead the firm's corporate and intellectual property law practice focused on the open-source computer software business.

Comments (none posted)

Trolltech Sponsors Major KDE Contributor (KDE.News)

Trolltech has announced their full-time sponsorship of KDE developer Aaron Seigo. "This arrangement will enable Aaron to devote his full time and attention to KDE software projects such as Plasma, which aims to reshape the desktop, as well as to engage in greater Open Source community participation and support."

Comments (1 posted)

Userful, Alacos and Win4Lin team on Desktop Linux effort

Userful, Alacos and Win4Lin, Inc. have sent out a combined LinuxWorld press release concerning their desktop Linux efforts. "A trio of desktop Linux companies have teamed up to provide a complete pathway to migrate enterprises to desktop Linux, a feat no single company has yet matched. These companies' solutions enable organizations large and small to cost-effectively leverage the Linux desktop and make it attractive and easy to move to the flexible and open desktop platform."

Full Story (comments: none)

LinuxWorld, San Francisco - the press releases

LinuxWorld Conference & Expo started today in San Francisco. As always many companies use the event as an opportunity to make announcements about their latest and greatest products. Here are a few of today's announcements:

Comments (none posted)

LinuxWorld, San Francisco - more press releases

LinuxWorld Conference & Expo started on Monday in San Francisco. As always many companies use the event as an opportunity to make announcements about their latest and greatest products. Here are some of Monday's announcements:

Comments (none posted)

Tuesday announcements from LinuxWorld

The LinuxWorld announcements continue to pour in. Here's subset of Tuesday's press releases:

Comments (2 posted)

Novell's LinuxWorld announcements

Novell has made several announcements, timed to coincide with LinuxWorld. Here is a subset:

Comments (none posted)

Darl sends a letter

Admit it: you've been wondering what happened to Darl McBride. Well, he's back; the SCO group has sent out an extended Darlgram (an "open letter") as a press release. "Conversely, when Linux customers run into problems and need professional technical support they really have only two choices. First, they can turn to the Linux distributor who played a big role in packaging the product but had nothing to do with its core development. Or second, they can turn to the Linux volunteer community. These volunteers were not paid to develop the product; and they received nothing from the Linux distributor, there's no obligation for that volunteer to support the product. Would you really want to trust the backbone of your business to the likely unpredictable response times of this Linux 'volunteer fire department' support model?" Somebody evidently forgot to tell Darl that the "no support" FUD line died out in the late 1990's.

Comments (29 posted)

New Books

Open Source for the Enterprise

O'Reilly has published the book Open Source for the Enterprise by Woods and Gautam Guliani.

Full Story (comments: none)

Protect Your Privacy Online, at Home and at Work

O'Reilly has published the book Protect Your Privacy Online, at Home and at Work by Dan Tynan.

Full Story (comments: none)

Resources

CodeZoo Adds Python and Ruby Components

New Python and Ruby sections have been added to the O'Reilly CodeZoo repository site. "Guido von Rossum, creator of Python, said, "Python developers have a well-deserved reputation for creating and using code efficiently. The new CodeZoo Python repository gives them a powerful new tool to speed up their development process." David Heinemeier Hansson, creator of Ruby on Rails, said, "Ruby's wealth of libraries and frameworks can't help the influx of programmers coming to the language of late if they don't know what's out there. CodeZoo helps shine light of all these great components and helps programmers reuse more and recode less.""

Full Story (comments: none)

Felten: Hollywood designing our computers

Ed Felten has posted some excerpts from a Microsoft white paper (available as a 2MB Word-format document) on "content protection" for Windows systems. It shows that the entertainment industry is now truly driving the design of our hardware and Microsoft's software. For example, before a new cipher for content encryption will be implemented: "The evidence must be presented to Hollywood and other content owners, and they must agree that it provides the required level of security. Written proof from at least three of the major Hollywood studios is required." The document as a whole is a worthwhile read - it shows the extent to which the industry is willing to go to protect our computers from their owners.

Comments (4 posted)

FSF Europe Newsletter

The August 6, 2005 edition of the FSF Europe Newsletter is online with the latest news from the Free Software Foundation Europe.

Full Story (comments: 2)

Open Source Press Release Database

opensourcexperts.com has launched a new Open Source Press Release Database site. "This system is specifically designed for organizations and companies who wish to promote their Open Source related products, services, and case studies in a journalist friendly form. Commercial announcements are welcome as long as they relate or are based "on-top-of" Open Source software."

Full Story (comments: none)

O'Reilly and Greenplum Launch Beta of O'Reilly Connection

O'Reilly and Greenplum have launched the O'Reilly Connection, a job-oriented social network site. "With the aim of "uniting the global geekforce," O'Reilly Connection is a tech-centric jobs and networking site for developers and those who want to hire them. The service was conceived and created by Greenplum, a company commercializing the open-source database PostgreSQL for Business Intelligence (BI)."

Full Story (comments: none)

Contests and Awards

Winners of the TuxMobil GNU/Linux Award 2005 Nominated

The winners of the first TuxMobil GNU/Linux Award 2005 have been nominated. "This year the award honors five Free Software projects, which are improving Linux for mobile computers."

Full Story (comments: none)

Upcoming Events

Blender Conference 2005 CFP

A call for proposals has gone out for the Blender Conference 2005. The event will be held on October 14-16, 2005 at De Waag in Amsterdam, the Netherlands. Presentations are due by August 15.

Comments (none posted)

goto10 at V2_ in September 2005

A reminder has gone out for the goto10 Audio Signal Processing workshop. The event will take place in Rotterdam, the Netherlands on September 4, 2005.

Full Story (comments: none)

Reminder: linux.conf.au 2006 - Call For Papers

Those interested in speaking at the 2006 linux.conf.au need to have their abstracts in by September 5, 2005. See this announcement (click below) for other important lca dates.

Full Story (comments: none)

Call for Papers -- OSS Database Conference

The Open Source Database Conference 2005 has issued a call for papers. Proposals are due by August 19. The conference takes place in Frankfurt, Germany November 7 - 9, 2005.

Full Story (comments: none)

UK Free Software conference, 13 AUG 2005

The UK Free Software conference will be held on August 13, 2005 in London, UK: "Conference to include talks on free software, topical issues and an all-day exhibition."

Full Story (comments: none)

Events: August 11 - October 6, 2005

Date Event Location
August 11, 2005LinuxWorld Conference and Expo(Moscone Center)San Francisco, CA
August 13, 2005AFFS Annual Conference(The Resource Centre)London, UK
August 20, 2005Free Audio and Video Event(FAVE)(Trinity Community and Arts Centre)Bristol, UK
August 27 - September 4, 2005aKademy 2005(University of Málaga)Málaga Spain
August 31 - September 2, 2005YAPC::EU::2005(University of Minho)Braga, Portugal
September 1 - 2, 2005Symposium on Security for Asia Network(SyScAN'05)(The Dusit Thani Hotel)Bangkok, Thailand
September 1 - 4, 2005GOTO10 ASP digital sound workshopRotterdam, the Netherlands
September 5 - 9, 2005International Computer Music Conference(ICMC 2005)Barcelona, Spain
September 14 - 16, 2005php|works(Holiday Inn Yorkdale)Toronto, Canada
September 16 - 18, 2005ToorCon 7(San Diego Convention Center)San Diego, CA
September 19 - 21, 2005Plone Conference 2005(Semper Depot, Lehargasse)Vienna, Austria
September 20 - 23, 2005New Security Paradigms Workshop(NSPW)(UCLA Conference Center)Lake Arrowhead, California
September 23 - 24, 2005Sixth Symposium on Trends in Functional Programming(TFP 2005)Tallinn, Estonia
September 26 - 29, 2005Hack in the Box Security Conference(HITBSecConf2005)Kuala Lumpur, Malaysia
September 28 - 30, 2005OpenOffice.org Conference 2005(OO.oCon)Koper (Capodistria), Slovenia
October 1, 2005Ohio LinuxFest 2005Columbus, OH
October 5 - 6, 2005LinuxWorld LondonOlympia, London, UK
October 6, 2005Fedora Users and Developers Conference(FUDCon London)(LinuxWorld Conference and Expo UK)London, UK

Comments (none posted)

Web sites

Qt Developer Blogs Launched (KDE.News)

KDE.News has announced the launch of the QDevBlog site. "QDevBlog has launched featuring the thoughts of all your favourite Trolltech engineers. Currently "the ramblings of engineers" has a lead entry from KDE founder and Qt lead developer Matthias Ettrich on some basic thoughts about KDE 4."

Comments (none posted)

Page editor: Forrest Cook

Letters to the editor

On the dangers Virtual Machines pose to freedom

From:  "Martin C. Atkins" <martin-AT-mca-ltd.com>
To:  lwn-AT-lwn.net
Subject:  Articlelet: On the dangers Virtual Machines pose to freedom
Date:  Thu, 4 Aug 2005 18:47:29 +0530

--- Start ---
        On the dangers Virtual Machines pose to freedom
                        Martin C. Atkins
 
There has been much enthusiasm surrounding the recent rise of Xen as
the OpenSource Virtual Machine Monitor (VMM, or hypervisor), most of
which I have joined in.
 
There have also been several comments along the lines of "Virtual
machines are the ultimate weapon against DRM/NGSCB/etc", since we
will just virtualise the controlled devices along with the virtual
processor. I used to think that too.
 
However, I recently realised that there are some significant dangers
lurking in these developments, especially when Intel's Vanderpool,
and AMD's Pacifica come into the picture.
 
How long will it be before Intel, or a BIOS manufacturer, puts a VMM
into the BIOS of a motherboard designed for a Vanderpool/Pacifica-capable
processor? This has many attractions, in addition to the "normal"
ones (multiple simultaneous OSs), for example, one would be able to
access BIOS/etc functionality, such as DVD playing, independently of any
OS, and without stopping the other operating systems that are already
running. One could also standardise many device interfaces, etc...
 
However, it is only a small step to a BIOS/VMM that *only* allows OSs
to run in virtual machines! Suddenly the VMM has immense power, and
the company who controls the VMM also has immense power! The VMM
becomes the natural seat for DRM technologies, and we wouldn't even
be able to argue that we couldn't boot Linux (or whatever) - but the
capabilities of any "untrusted" operating system could be severely
curtailed.
 
The next obvious step would be to put the VMM into ROM, rather than
flash memories, making it even more difficult to replace with a
"normal" BIOS. Ultimately, the VMM ROMS could be built into the CPU
chips, and we have (almost) completely unhackable computers, with a
semblance (but only a semblance) of openness. Complete control over
how we use the computer would rest in the CPU manufacturers'
hands [see also note2].
 
Lesser risks also include things like: does the VMM provide the
facilities I need?. An example would be: does the VMM guarantee
real-time responsiveness? If it does not, and you need guarantees,
well tough! Go and find another computer/architecture/planet!
 
Another potential risk is simply the quality (or lack of) of the VMM
code.
 
If you think this is far fetched, ponder for a moment the PS3, which
apparently always runs "applications", such as games and Linux, in a
virtual machine. To quote Ken Kutaragi in [1] "The kernel runs on
Cell (Cell OS hypervisor) and it takes the style in which multiple
OSes as applications run on top of that (virtual machine)". The
future is with us today!
 
I'm also reliably informed that IBM pSeries and iSeries mainframes
are already configured this way. I am told that the IBM hypervisor
(pHype) is (virtually) impossible to remove (no pun intended!).
Fortunately, DRM hasn't been high on the feature lists of these
machines thus far.
 
Executive summary: Virtual Machine Monitors are very nice, but we
need to have a real choice about whether or not to boot one and/or
which one to boot. Whoever controls this choice, controls the machine!
 
Notes:
 
[Note1] I've found that [2] touched on these ideas back in 2003, but
didn't, in my opinion, go nearly far enough.
 
[Note2] A more viable alternative might be to build a BIOS ROM
signature check into the CPU, so that only BIOSs signed by the CPU
manufacturer would run. This would allow field updates, bug fixes,
etc., but still make it (nearly) impossible to substitute a less
restrictive BIOS/VMM.
 
References:
[1] http://nixdoc.net/files/forum/about41506.html
[2] http://lwn.net/Articles/52189/
 
--- END ---

Comments (10 posted)

Ratings are fine (Open Enterprise, 9 August 2005)

From:  "Hyre, Max" <Max.Hyre-AT-cardiopulmonarycorp.com>
To:  <letters-AT-infoworld.com>
Subject:  Ratings are fine (Open Enterprise, 9 August 2005)
Date:  Wed, 10 Aug 2005 10:38:49 -0400
Cc:  <letters-AT-lwn.net>

   Dear Mr. McAllister:
 
   In your column ``Does a Ratings Standard Make Sense for Open
Source?'' (9 Aug. '05,
http://www.infoworld.com/article/05/08/08/32OPopenent_1.html) you
opine
 
          A rating says to potential users: Watch out. Think
          twice. Double check. Get the facts.
 
   It warns off potential users in exactly the way a full and
accurate bug list does: not at all---rather the reverse. In
both cases, you /are/ getting the facts: a clear, honest
evaluation of the program, something impossible to find for
proprietary packages.
 
   Users recognize and appreciate this: they know what they're
getting. They know most proprietary software has failings worse
(often far worse) than the most severe bug found in a Free
Software bug list.
 
      But if promoting open source is the goal, is it really the
      best message to lead with?
 
   Yes. Free Software is competing by different rules, ones
fairer to the user. Its ``promotion'' is so much more than
advertising budgets and PR departments.
 
 
 
                      Best wishes,
 
                      Max Hyre
 

Comments (none posted)

Page editor: Jonathan Corbet


Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds