Bringing you the latest news from the Linux World.
Dedicated to keeping Linux users up-to-date, with concise news for all interests
Linux in the news
All in one big page
Here is the permanent site for this page.
See also: last week's LWN.
GNOME and .NET. It seems to have started with this article in The Register, which quotes Miguel de Icaza as saying that GNOME 4.0 should be based on Mono. It is not surprising that this statement has upset some people. A calmer look at the situation suggests that some of the fears are overblown.
Mono, of course, is a free implementation of parts of the .NET framework. In particular, Mono aims to provide a compiler for the C# language, an implementation of the "Common Language Infrastructure" (yet another virtual machine and remote procedure call implementation), and an extensive class library. In theory, Mono will help with the development of secure, highly interoperable applications.
Then again, there's Don Marti's inimitable characterization of the whole .NET framework:
If you break the whole mess down, as far as I can tell you get a rounded-scissors version of C++, a standard library for same, a virtual machine, and a Big Brother bank/authentication/anal probe system.
All of this stuff, of course, has been designed by Microsoft. Some of it has been proposed for ECMA standard status - but not all of it. The Mono implementation is progressing, but it remains far from a stable, complete state.
One thing that people should keep in mind before getting too upset over Miguel's statements is that he is talking about GNOME 3 or 4. The GNOME project has not yet released version 2.0, and Mono 1.0 is still a distant prospect. So any integration of GNOME and Mono will not happen for years. There will be plenty of time to see how Mono works out, how Microsoft manages its .NET standards, and whether the .NET framework truly helps the application development process.
Even then, Miguel is not pushing for a major rewrite of GNOME. Instead, he sees Mono as a way of making GNOME development go better in the future:
I am not asking anyone to rewrite any code. Indeed, I encourage people not to do so. But when it comes to extend a product, Mono might be a valuable tool. Valuable, because I believe that the major feature of .NET is reduction of development time and the reduction of the money we spend on developing those products.
Indeed, development time is one of the key factors behind this push:
Evolution: roughly 2 years of development, and at its peak had 17 developers working on it. [...]
.NET supporters cite a number of features which can help achieve this increase in development productivity: a comprehensive class library, the ability to easily integrate code in multiple languages, a garbage collection system which eliminates memory management problems, and more. It is also claimed that using the .NET framework will greatly increase the number of developers who can write for the Linux platform.
These claims, certainly, are worth the time to evaluate. Linux has far more applications than it did even a few years ago, but very few people would say that it does not need any more. If Mono can help bring about more free applications sooner, then it is worth a look.
The fact remains, however, that .NET is a standard created by Microsoft for its own ends. Adopting Mono could serve mainly to bring Linux systems into the whole HailStorm framework - an idea which lacks appeal. In the rush to develop more applications for Linux, it is worth taking some time to consider exactly what kind of applications we want.
Then, consider that there is nothing to keep Microsoft from "embracing and extending" its own standards. Some years from now, Mono could look much like the Wine project does now: forever chasing a set of shifting standards, and never being quite solid enough to completely serve its intended purpose. There also remains the issue of possible royalty claims or patent issues with .NET. Microsoft has not been entirely clear on the status of much of .NET, and unpleasant surprises are a real possibility. It is dangerous to base your applications on a standard controlled by a competing company.
Those worries are all speculation at this time, however. Given the amount of time that will pass before GNOME could even conceivably adopt Mono in any serious way, there will be ample opportunity to see how things play out. And, in the end, Miguel, while highly influential, lacks the ability to commit GNOME to any such course. The GNOME Foundation exists for a reason, and it's likely that its members will look hard before leaping onto the .NET bandwagon.
(See also: Miguel's "long reply" on this issue).
Who has more security problems? The folks at vnunet started some fun with this article claiming that Linux had more security problems than Windows in 2001. Here's their reasoning:
Although the statistics so far only go up to August 2001, aggregated distributions of the Linux operating system suffered 96 vulnerabilities while Windows NT/2000 suffered only 42. Breaking the figures down by distribution, Mandrake Linux 7.2 notched up 33 vulnerabilities, Red Hat 7.0 suffered 28, Mandrake 7.1 had 27 and Debian 2.2 had 26.
Any Linux user will immediately see the flaw in this reasoning: the same vulnerabilities are being counted up to four times. The real number of Linux vulnerabilities will certainly have to be a lot less. vnunet quickly backpedaled, noting that "all Linux distributions essentially use the same kernel, certain bugs are being counted more than once." Which still somewhat misses the point, since Linux distributions share far more than just the kernel.
We decided that it was time to try to get a handle on how many vulnerabilities were really suffered by Linux systems in 2001. To that end, we plowed through more security updates than any sane person would want to see in one day, and compiled the following table. Anybody who is proud of Linux's security should have a good look and weep - it is a very long list.
There is no end of caveats that apply to this table: it is hard to make a one-for-one comparison of security updates across distributions. Undoubtedly some updates have been joined that should not be, and others have been kept separate when they should be together. The table also does not distinguish between versions; an update for Red Hat Linux 6.2 makes the list, even if 7.x was available and not vulnerable. The picture is rough, but, we think, still interesting. Without further ado:
Whew. That is a total of 290 updates for 145 unique vulnerabilities. It would seem that the vnunet article actually underestimated the problem. A quick look at the totals suggests that Turbolinux is the most secure distribution with only 28 updates, while Debian and Mandrake top the list at 81. It must be time to put out a press release.
That is, of course, complete nonsense. Why do the different distributors have different numbers of updates? Here's a few reasons:
In other words, we are not yet at a point where we can make meaningful comparisons even between Linux distributions. Trying to compare Linux with Windows seems like a waste of time. In the end, there is only so much to be learned about the security of an operating system by counting its published vulnerabilities. One has to look at the seriousness of each, how it was discovered (internal audit or external exploit), how long users had to wait for a fix, and how many users were actually compromised as a result of the problem. We need better ways of understanding and comparing security response; simply counting vulnerabilities is not sufficient.
Inside this LWN.net weekly edition:
This Week's LWN was brought to you by:
February 7, 2002