LWN.net Weekly Edition for July 2, 2009

Stallman warns about C# and Mono dependence

Since its inception, Mono has always been controversial, largely because Microsoft—creator of the .NET framework that Mono implements—is not trusted by a large segment of the free software community. The concern is that, at some point, Microsoft will start asserting patent claims against Mono or applications that use it. Richard Stallman recently stirred the pot with a brief warning that reliance on Mono, or applications that are written in C#, is a "serious danger". That, in turn, has led to a number of discussions about how real that danger actually is, and what, if anything, distributions should do about it.

Certainly, the patent non-assertion agreement that Microsoft and Novell signed in 2006 gives the appearance that Mono users—those who are not Novell customers anyway—could be subject to patent harassment—or worse—from Microsoft. So far, nothing like that has materialized, but it is difficult for anyone with even the tiniest bit of cynicism (along with a historical perspective) to be completely unconcerned about the problem As is typical, Stallman is particularly blunt, or alarmist, depending on one's perspective:

It would seem that Debian's recent addition of the Mono-based Tomboy note-taking application to one of its GNOME meta-packages—though only for the Squeeze (testing) release so far—is what prompted Stallman's warning. Some are advocating shipping the Gnote re-implementation of Tomboy in C++, instead of Tomboy, which might be a solution for note-taking. As Debian developer Josselin Mouette points out, though, there are no replacements for other Mono-based applications, such as F-Spot and GNOME Do, so Mono may well be required by other default applications down the road.

Some distributions, such as Fedora for the upcoming Fedora 12, have removed Tomboy in favor of Gnote for default installations. This effectively removes Mono from the default, though the reasons are not necessarily related to any potential patent issues—Gnote has a much smaller footprint. But, there is the recent patent suit against TomTom—and efforts to work around the patent—to remind folks that the patent threat is real, and that Microsoft, which had largely stayed away from pressing patent claims, can and will pursue free software implementations of its patented technologies.

Any patent action against Mono may subject the plaintiff to a countersuit from the Open Invention Network (OIN), which is a patent pool to defend free software. By adding Mono to its list of protected applications, OIN allowed various distributions, Fedora for example, to become comfortable enough to start shipping Mono at all. There are still risks, of course, not least from patent trolls who don't implement anything that could be subject to a countersuit, but the OIN coverage provides enough of a threat to potential patent attackers that Mono is available for nearly all distributions.

Unlike many earlier complaints about Mono and C#, Stallman is not arguing against the existence of Mono, his view is more nuanced than that:

The mention of DotGNU Portable.NET is confusing to some: how can Stallman be warning against C# in the same message where he touts a GNU implementation of the language? But Stallman evidently doesn't see it that way; providing the tool is not the same as encouraging its use. His solution is to discourage new development in C#, find alternative applications written without Mono, and to not include Mono in the default installations of Linux distributions. As more C# applications come along, particularly those without a "Mono-free" alternative, that could pose some serious difficulties.

The most in-depth defense of Mono, in general, as well as arguments for its inclusion in Debian, Ubuntu, and other distributions comes from Jo Shields. In a lengthy blog post, which was a response to a challenge on Linux Today, he also notes that it is the applications that are driving the adoption of Mono, not the technology in and of itself. He has a well-thought-out list of reasons that users should not be worried about the patent threat. He is clearly exasperated—or worse—with the shrill "anti-Mono" contingent:

This issue has been simmering for a long time, but it has really flared up over the last two or three weeks, prompting the Ubuntu Technical Board to issue a position statement saying that it "sees no reason to exclude Mono or applications based upon it from the archive, or from the default installation set". While some distributions may remove Mono from their default installs and Live CDs—for space reasons if nothing else—there are few, if any, mainstream distributions that will completely remove Mono from their repositories, as there are clearly useful applications that depend on it. An interesting exception to that, however, is Red Hat Enterprise Linux (RHEL), which doesn't package Mono at all.

C# is an international standard, as both Ecma International and ISO have adopted C# specifications. Those bodies require patents that are held by their members, and that cover an adopted standard, be licensed under "reasonable and non-discriminatory" (RAND) terms. Depending on what those terms actually are, they may not be "non-discriminatory" towards free software implementations, particularly if they require royalties. But, it may well be that patent enforcement actions by Microsoft against Mono (or DotGNU for that matter) are unlikely. Microsoft might also be leery of the various regulatory bodies that tend to keep an eye on its anti-competitive behavior. All of those things may make the probability of a patent suit vanishingly small, but it doesn't reduce it zero—and that is what Stallman and others are worried about.

Of course, Microsoft could make its intentions clear, and remove the doubt. That it chooses not to, and lets the free software community twist in the wind, speaks volumes about its tactics—whether it truly thinks it might ever use the patent weapon or not. Rather than any active enforcement, a more likely scenario is that Microsoft hopes it can shake down more companies in deals like it made with Novell. From that standpoint, the internal free software community bickering about Mono serves its purposes as well as any "fear, uncertainty, and doubt" campaign it might be able to conjure up.

There are perfectly legitimate reasons to be concerned about Mono: it is resource-hungry, is always playing catch-up with whatever new features Microsoft chooses to add, and could increase the danger from patent suits. At the moment, though, those kinds of arguments are being drowned out by a loud group that doesn't want to see Mono exist at all.

This rabid anti-Microsoft segment of the free software community has not done the rest of the community any favors with its behavior regarding this issue. There are certainly reasons to be wary of Microsoft, but there is no reason to believe that the Mono developers and proponents are interested in anything other than the technology itself. The C# language and .NET libraries have benefits that they see, and wish to use. Disagreeing with that, on a technical—or political—level is all well and good, but calling for people to be fired or somehow expelled from the community for their opinions, as Shields describes, is absurd. Freedom cuts both ways.

The root problem is, of course, software patents, and the uncertainty they bring. This is clearly a growing problem within our community, and one that is not going to go away soon. While a patent attack from Microsoft over Mono may be unlikely, there are certainly other patent trolls out there trying to figure out how to leverage their "valuable intellectual property" against Linux and free software. Where the next attack comes from is unclear, but we can be sure that it's coming.

Comments (70 posted)

RealtimeKit and the audio problem

Skip-free audio and video playback is a fundamental expectation for many - if not most - Linux users. Given the importance of this feature and the increase in hardware performance over the years, one would think that the audio latency problem would have been solved some time ago. The recent posting of (and mixed reception for) the "RealtimeKit" mechanism shows that this issue remains open, though, and that we are still short of a consensus on how it should be solved.

Audio skipping can have a number of causes. If the stream is traveling over the net, those causes may be entirely external to the system involved. The rest of the time, resource contention is usually the problem. And, often, the limiting resource is the CPU. The response time requirements for audio are not especially tight, but, if the processor gets busy with something else for too long, it's still possible that the system will fail to get audio data to the hardware before the stream runs dry. If the sound card runs out of sound to play, it will go silent, thus introducing a skip into the audio stream. Even if the skip improves the material being played (one of the current flood of Michael Jackson retrospectives, say), users still tend to get unhappy.

Efforts to improve audio latency have taken several forms. One is the ongoing effort to identify and fix latency problems throughout the kernel. New scheduling algorithms (the completely fair scheduler, for example) have also helped. But, even after all that work has been done, there seems to be little alternative to running core audio processing code with realtime scheduling priority. And that is where the trouble starts.

More than four years ago, the audio community came forward with its proposed solution to the problem: the realtime security module. This module used the Linux security module (LSM) API to allow the system administrator to grant realtime scheduling privileges to specific users and groups. This solution slightly reduced the security of the system (opening it up to denial of service attacks by the privileged users), but it also solved the latency issues in ways which made audio developers happy.

Kernel developers didn't like this approach, though. The seeming misuse of the LSM API - which is supposed to only limit privileges, never enhance them - was part of the problem. But the realtime module just looked like an ad hoc solution that would not stand the test of time. It was never merged; the kernel developers, instead, opted for an approach based on resource limits. As of 2.6.12, any process is allowed to set a realtime priority up to the value of its RLIMIT_RTPRIO limit. By default, this limit does not allow any realtime scheduling at all, but the system administrator can change the default for specific users or groups by editing the limits.conf file read by the PAM subsystem.

This feature would seem to solve the problem, and, indeed, the media-focused distributions make good use of it. The major distributions tend not to use RLIMIT_RTPRIO, though, because it makes it so easy for a process (malicious or just buggy) to completely freeze the machine. Once a process with realtime priority goes into a tight loop, there is little that the user or administrator can do to stop it short of hitting the reset button. That sort of behavior creates unhappy users and inflammatory bug tracker entries - both things that distributors hate. So those distributors have mostly avoided enabling this feature.

More recent kernels have seen the addition of features which could mitigate this problem somewhat. A new limit (RLIMIT_RTTIME) sets an upper bound on the amount of time a realtime process can monopolize the CPU; after that time, it must make a blocking system call or, eventually, be killed by the kernel. This limit solves the rogue process problem, but it does little against deliberate denial-of-service attacks, which can get around the limit by continually forking new processes. As a result, RLIMIT_RTTIME doesn't make nervous distributors feel much better.

The other feature of note is realtime group scheduling, which allows a group of processes to be given a "realtime bandwidth" value limiting the amount of available CPU time the group can use at realtime priority. That, in turn, limits ability of the group as a whole to completely take over the system. The group scheduling feature looks like it should be a complete solution to the problem; it allows groups of processes to be given access to the realtime scheduler while limiting their ability to affect the overall operation of the system.

When Lennart Poettering set out to solve the audio skipping problem, though, he didn't use any of the above solutions. The security issues associated with resource limits were more than he was willing to deal with, and he describes the group scheduling feature this way:

It is true that a process cannot simultaneously be in a container-related control group and an audio-related control group if both groups want to control scheduling-related parameters.

Lennart's proposal is a new daemon called "RealtimeKit"; it has already found its way into the Fedora Rawhide distribution. The RealtimeKit daemon has a relatively simple job: it grants realtime scheduling priority to processes in response to requests sent via D-Bus. There are, of course, some catches:

• Any process requesting realtime priority must have the RLIMIT_RTTIME limit set to ensure that it cannot completely take over the system.

• There are administrator-set limits on the number of processes which can be running with realtime priority at any given time.

• The requesting process must have the SCHED_RESET_ON_FORK policy flag set in the kernel.

The SCHED_RESET_ON_FORK flag is implemented by a kernel patch written by Lennart and accepted into Ingo Molnar's "tip" tree; this patch has not, as of this writing, been merged for 2.6.31. This flag, when set, prevents any child processes from inheriting any enhanced scheduling priorities from the parent. It thus is effective against fork bombs and other multi-process attacks; it allows RealtimeKit to give realtime priority to a single process in the knowledge that this priority will not be passed on to any others.

As a solution, RealtimeKit looks like it should work, but its reception in the audio development community was chilly at best. As Paul Davis put it:

There are a number of reasons for the objections to RealtimeKit. It adds a dependency on D-Bus regardless of whether audio developers want it. It's far from a POSIX interface. RealtimeKit takes certain decisions (such as whether to use the round-robin or FIFO scheduling classes) out of the developers' hands. It's not sufficient for the needs of pro audio users. And so on. But the real complaints would appear to be these:

• The audio community feels a little burned. They were told four years ago that they needed to drop their preferred solution (the realtime security module) in favor of the rlimit-based solution, which is now, in turn, being pushed aside for RealtimeKit. How long will it be, they wonder, until yet another solution is put forward as the real answer?

• Nobody asked the audio developers how they would like a solution to look; instead, RealtimeKit was simply presented to them as the new way to go.

Lennart's response suggests that he's not likely to go asking the Linux audio development ("lad") community for input in the future:

More seriously, he points out that RealtimeKit does not break the existing rlimit-based system. Instead, it just adds an option for distributors who want to make realtime scheduling available to specific processes in a safe way. So nothing which works now will stop working under RealtimeKit. That is little comfort, though, to developers and users who feel that they will be forced to run RealtimeKit to use their audio applications in the future.

The Linux audio community contains no end of highly talented and highly motivated developers. But audio support under Linux still falls short of what it should really be. Audio development has suffered from a lack of consensus on solutions, a lack of communications between different development communities, and a lack of a maintainer with a view of the full problem. So it is not surprising that our audio applications don't always play well together and don't always work as well as we would like.

Lennart has dedicated a good part of his life toward improving this situation. A certain amount of controversy and pain has accompanied this work; one need not look very far to find no end of PulseAudio horror stories. But PulseAudio seems to be getting better, and Linux may well be getting closer to having basic (non-professional) audio "just work" out of the box. The goals of this work are hard to criticize, and criticism of the results might just be on the wane.

Perhaps RealtimeKit is the missing link which will enable distributors to improve audio responsiveness; Fedora looks to be the laboratory in which this particular experiment will be conducted. If RealtimeKit works as advertised, the audio community will eventually move to make use of it - regardless of whether they were asked ahead of time or not. For better or for worse, that's often how our community works: problems are solved not by talk, but by a determined developer who creates code that works.

(See this README file for more information on RealtimeKit).

Comments (67 posted)

VFAT patent avoidance and patent workarounds

Back in May, the proposed "no long file names" patch got a hostile reception on the linux-kernel mailing list. This patch, presumably aimed at working around Microsoft's VFAT patents, made the kernel unable to create long file names on VFAT filesystems. It was seen by many as a reduction in functionality without any sort of well-explained justification, and it was not merged. Now there is a new patch which takes a different approach on both the technical and political fronts. Its fate remains to be seen, but it demonstrates a method for dealing with patents which is worthy of wider consideration.

The VFAT format is undeniably a hack. It allows the FAT filesystem to be extended beyond its traditional 8.3 upper-case file name limit by creating additional file entries - which look invalid to older filesystem implementations - containing a longer name. Depending on the length of the name, several of these additional entries may need to be placed in the directory ahead of an entry holding a traditional short file name. The first patch simply disabled the ability to create these long name entries; since the relevant patents all make claims about the creation of long file names, a system which does not create them cannot infringe. A Linux kernel with this patch in place (and enabled at configuration time) would be able to read filesystems with long names, but it would be unable to add any more long names to it.

The new patch takes an entirely different approach based on a close reading of the patent. In truth, it's not the creation of long file names which is covered; instead, the patent claims the technique of creating both long and short names. So the current patch takes away that ability; it can create a long name or a short one, but never both for the same file. The result is almost complete interoperability with other systems using long names; the one exception is archaic systems which only have short name capability. Such systems are relatively rare, though.

There is an interesting trick required to make all this work. The FAT format requires that the short-name directory entry be present, so Linux cannot simply leave it out. Instead, that entry is created with a name which is clearly invalid. The "short name" starts with a space and a NUL byte, continues with some random characters, and finishes with an extension containing a slash. The end result cannot be listed as part of the directory, cannot be used to open the file, and may not even be unique within the directory. It is, thus, not a name for the file.

Assuming that reasoning holds up in court, this patch creates a kernel which cannot be said to infringe upon the VFAT patents. Given that the patch has clearly seen some legal review (see the associated FAQ), and given that it comes from a source (IBM) with extensive experience and expertise in patent law, its chances are probably best described as "better than average."

There are still those who will question this whole approach, though. Changing the kernel in a way which reduces interoperability looks like an acknowledgment of the validity of the patents; wouldn't it be better, some ask, to put those resources into fighting the patents instead? For those who do not wish to play this game at all, putting hackish-looking workarounds into the kernel seems like the wrong way to go.

The problem is that invalidating a patent is a long, expensive, and uncertain undertaking. "Long" means years, "expensive" means potentially millions of dollars, and "uncertain" means exactly that. The US patent system (which is of the most relevance in situations like this) is unwilling to invalidate patents in general; even when it does, the patent is merely put back into the review process from which it can arise, zombie-like, to terrorize again. In the mean time, companies subject to attacks under that patent are suffering under extreme legal costs and potential injunctions which keep them from selling their products. For most companies, that's a death sentence. It is unsurprising that most companies lacking a massive patent portfolio of their own quickly settle when subjected to patent attacks.

[PULL QUOTE: If we choose not to make use of patent workarounds, we will clearly increase our chances of losing the larger fight. END QUOTE] Workarounds are a worthwhile alternative to settling and long battles of attrition. A proper workaround effectively invalidates a patent without all of the associated costs. This is especially true if the workaround so clearly avoids the target patent that any attacks can be disposed of quickly via summary judgment. In any long fight, one must choose battles carefully; workarounds can allow us to avoid numerous costly battles and focus our energies on truly disruptive patents. If we choose not to make use of patent workarounds, we will clearly increase our chances of losing the larger fight.

The FAQ makes an important point related to workarounds that the community should hear: publicly questioning the effectiveness of a workaround can have fatal results. The goal of a good workaround is to avoid a patent infringement trial altogether. If a patent holder can point to email from prominent community members suggesting that a given workaround might, in fact, not avoid the patent, said holder may create enough doubt in a judge's mind to defeat a summary judgment motion and force a case to go to trial. Most defendants cannot afford that, and will thus be forced to capitulate. The right way to express concerns of this nature is via private communication.

We have been hearing warnings about software patents for many years, but, for most of those years, the threat seemed distant. During that time, it is said, numerous companies have been quietly shaken down for patent money. The TomTom suit brought that process out into the open, making it clear that powerful companies are willing and able to press patent infringement claims against companies using Linux. The sad fact is that we cannot opt out of playing this game, so we're simply going to have to get good at it. This patch is part of the process of figuring out how this game - so much of which is played via secret maneuvers - can be handled in an open community. It also represents a serious attempt by a large player in the patent game to help the community avoid a couple of threatening patents. Perhaps it's not the patch we want to merge in the end, but it (and its goals) deserve serious consideration.

Comments (47 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Mozilla's Content Security Policy; New vulnerabilities in git, kdelibs, moodle, pam_krb5, ...
• Kernel: Soft updates, hard problems; Perfcounters; The fanotify API.
• Distributions: Ubuntu archive reorganization; openSUSE 11.2 Milestone 3 and YDL v6.2 released
• Development: VA API slowly -- but surely -- making progress, gcc-in-cxx phase 1, new versions of MySQL, PostgreSQL, Nagare, SuperCollider, Firefox, PHP, Python, Pycairo, bzr.
• Press: NetworkManager and ConnMan, How Linux News gets buried, talk by Jim Zemlin, Nvidia chooses Windows CE, Berlin art colleges choose Linux, reviews of Ksplice, KTechLab, Shuttle XS29f, Sugar on a Stick, AndroidFox speculation.
• Announcements: GNOME election results, Open Database License, LCA cfp, PostgreSQL conf cfp, LinuxCon program, Ohio Linux Fest, pyArkansas, SciPy student sponsorships.

Next page: Security>>