Linux in the news
All in one big page
See also: last week's Back page page.
Kuro5hin is another open-source related news site on the net, superficially similar to a number of others. It gets an interesting mix of stories, however. Perhaps that is a result of its interesting editorial setup: registered users of the site can look at pending stories and vote on which ones should actually make it onto the front page.
Another approach has been taken by Advogato, which has been up and running since last November. Advogato carries a certain number of free software and freedom-related stories; it also hosts diaries for its readers. A look at the site on any given day will show new diary entries from a number of well-known Linux personalities. There is also an interesting "certification" mechanism which establishes a reputation value for each member.
Section Editor: Jon Corbet
May 11, 2000
Letters to the editor should be sent to email@example.com. Preference will be given to letters which are short, to the point, and well written. If you want your email address "anti-spammed" in some way please be sure to let us know. We do not have a policy against anonymous letters, but we will be reluctant to include them.
Date: Tue, 9 May 2000 20:18:39 +0200 From: Ragnar Hojland Espinosa <firstname.lastname@example.org> To: email@example.com Subject: http://www.lwn.net/2000/0504/ Kerberos protocol - sort of. You can only get the information in the form of a self-extracting executable file, which puts up an intimidating "click wrap" license first. It seems that the Kerberos That's not true. You just have to open the file with winzip and, oh lookie, a pdf :) -- ____/| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." hkp://keys.pgp.com Handle via comment channels only.
Date: Fri, 5 May 2000 13:26:51 -0400 From: "Jay R. Ashworth" <firstname.lastname@example.org> To: email@example.com CC: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: LoveBug worm I'm quite disappointed to see that none of today's coverage of this topic points out that the reason this worm spread so far so fast is that -- as it always has -- Microsoft has chosen to favor convenience over security in the default configurations of most of its operating system and applications software. In many cases, poor Outlook users didn't even *have to open* the attachment, Outlook would be "helpful" and do it for them. This is not the first time this has happened... but it's also not the first time the *general* press has failed to make it clear that the fault lies as much with Microsoft as it does anywhere else. The technical press seems to do a slightly better job of getting it right, although they're not perfect either. In any event, until people (by which I mean the highly paid network administration staffs of Fortne 500 companies just as much as individual PC owners) start to think security -- or switch from Microsoft software to better designed programs (like Eudora and Netscape Messenger) and operating systems (like Linux and the Mac OS), this sort of thing will continue to occur... and people will continue to find out the hard way that stupidity is supposed to be expensive. Cheers, -- jra -- Jay R. Ashworth email@example.com Member of the Technical Staff The Suncoast Freenet Tampa Bay, Florida http://baylink.pitas.com +1 888 806 1654
Date: Thu, 4 May 2000 14:47:11 -0700 From: Nathan Myers <firstname.lastname@example.org> To: email@example.com Cc: firstname.lastname@example.org Subject: Tucows download stats In this week's LWN, while discussing Tucows download statistics, Liz observes: The really startling note from the three months worth of data, still a small sampling, is the lead that the two RPM-based distributions have on the rest of the pack. It will be an interesting trend to watch. Considering that Corel and Stormix are basically Debian plus some add-ons, it's worth looking at the statistics with the three combined. February Linux-Mandrake 46% Red Hat 27% Debian+ 18% SuSE 3% Slackware 3% Caldera 3% March Debian+ 36% Linux-Mandrake 31% Red Hat 14% Caldera 6% SuSE 5% FreeBSD 4% Slackware 1% April Red Hat 31% Debian+ 29% Linux-Mandrake 29% Caldera 4% FreeBSD 3% SuSE 3% Slackware 2% Yellow Dog Linux 1% Here we have the Debian/Apt-packaged family easily keeping up with the more heavily-promoted commercial distributions. March is interesting in that Debian downloads far exceed Mandrake's much-hyped popularity. Perhaps once Potato is out, Debian will just take over the world; then all those people working on proprietary distros can go home and do something productive instead. :-) Nathan Myers email@example.com
Date: Thu, 4 May 2000 15:37:24 +0100 (BST) From: Dunstan Vavasour <firstname.lastname@example.org> To: email@example.com Subject: Kernel Releases, Feature Creep, etc. The process Sun use for developing OS releases (so a fairly reliable source told me) is to have two development teams, each producing alternate releases. So the team which had just released Solaris 2.4 immediately started work on the new stuff to go in Solaris 2.6, while the other team worked on Solaris 2.5. Then when Solaris 2.5 was released, that team then merged in the new features which were already included in the upcoming 2.6, and moved on to develop Solaris 2.7. By contrast, when the feature freeze comes down on a Linux development kernel tree, it means that excluded features won't be in a production kernel until perhaps two years down the road. If, on the other hand, the new development kernel started when the "near production" kernel hit feature freeze then it would take off the pressure to cram features under the wire. All that then leaves is the need for people to work on the latter stages of the kernel development rather than the more exciting earlier stages, but I would guess that the "near release" kernel would be more widely used and deployed, giving it the usage and testing which is needed at that stage, while the early stage kernel might attract more developers where more effort is needed. When the 2.4 (say) kernel is released then the 2.7 development kernel would start, either with the 2.4 code base, and the new stuff in the 2.5 kernel being merged in, or it would take the current 2.5 kernel (unstable) and add features while the 2.5 kernel is stabilised for release as 2.6. Clearly the two development teams would need to share bug fixes, but they could work with a large degree of autonomy without being a code fork. The need to talk like this shows just how important the Linux kernel now is. Dunstan Vavasour firstname.lastname@example.org
Date: Thu, 04 May 2000 00:31:45 -0700 From: David Clatfelter <email@example.com> Subject: Where is the 2.4 kernel? To: firstname.lastname@example.org In your May 4th edition, you noted a number of articles which have begun to ask the question - Where is the 2.4 kernel? Let me state first that while I am not a developer, I think I agree with most Open Source developers, that software is like fine wine - it should never ship before its time. But what I find most humorous is that these authors have chosen to question the release schedule of the kernel. I mean, how many of them will be consciously aware of the benefits of 2.4? Is it just me, or is it somewhat absurd to compare the release of 2.4 to something like the release of Win2K? Why aren't these authors clamoring about the release date of KDE 2.0 or the next version of GNOME? That seems like the more apt comparison, but nobody ever seems to make it. Anyway, thanks for letting me voice my opinion. David Clatfelter
Date: Thu, 4 May 2000 10:31:35 -0400 (EDT) From: Clemmitt Sigler <email@example.com> To: firstname.lastname@example.org Subject: Open Source software release schedule. Hi Jonathan and Elizabeth, The solution to the problem of Open Source release "delays" that you addressed on last week's front page seems really simple to me. But given the nature of Open Source hacking, it may be hard to achieve. In the case of the Linux kernel, when 2.4 comes out Linus and Alan and other kernel "fathers" need to sit down on IRC or in person and decide just one thing: Which new features should be included in the 2.5 development kernel series. This needs to be planned _before_ hacking on 2.5 starts. The list of features to be included should be short, high priority, high feature win, and achievable. Then comes the hard part -- having the discipline to stick with it. Some modifications to the list are to be expected, but inclusion of totally new features not planned should be forbidden. We know the nature of Open Source hacking is to code what you love as much as what needs to be done. This makes such discipline hard, and might even lead to the dreaded "code fork" if someone gets extremely frustrated that his/her pet project won't be included in the kernel. So it seems to me to be a choice between the current long development cycle, or losing/redirecting hacker interest in the Linux kernel. It would be nice if there was a common ground somewhere in between these two extremes, but this can't be easy to find. Clemmitt Sigler
From: email@example.com To: firstname.lastname@example.org Date: Fri, 5 May 2000 13:32:29 -0600 Subject: 2.4 -- What's the big deal? No one who matters made any promises and as always the kernel will get done when it gets done. Open source development isn't in the death march that commercial shops are in and if commercial acceptance of Linux is going to require us to get into that mode, I'd as soon give the various companies the finger. We're not shipping a piece of software with 64 thousand bugs in it, here. We have our reputations to think about, after all. If you need a newer kernel, the dev kernels have been relatively stable (I'm running one at home right now.) I fail to see what the big deal is, or who finds it a big deal. I assume some crack smoking marketroid. The marketroids always choose (usually unreasonable) deadlines over quality. Well I got news for you, one of the biggest reasons to use Linux is because of its quality -- the number one reason people quote for using it over windows is that it never crashes. I know that the important people (The Kernel Developers) are smart enough to know that this is a non-issue and pay it the attention that it truly deserves. I wish the rest of the Linux media would follow suit. -- Bruce Ide email@example.com IBM PSC Software Developer
Date: Thu, 4 May 2000 14:42:20 -0400 To: firstname.lastname@example.org Subject: Software testing in the Open Source world From: Zygo Blaxell <email@example.com> > In 20 years of development, having worked for 7 different > companies ranging in size from a 5 man startup to the behemoth that is > Samsung, this is the first time I've seen software released to the world with > no formalized testing applied. I wish I could read the rest of this article, but the web server is returning error messages to me at the moment. In 8 years of development, having worked for 6 different companies ranging in size from a 5 man startup to a behemoth that I won't name, only one of those companies released software to the world _with_ formalized testing applied, and that company's policy was to ship the revision of the product with the lowest number of known severe defects when the release date arrived. The same company also had no plans to correct the software after shipment even when the problems were severe, corrections were available, their application to existing systems in the field was feasible, and ongoing support was paid for by the customer--an inconvenience which usually outweighed the small quality benefit from the pre-release testing in practice. Your mileage may vary, I guess. This perception be the result of different semantics surrounding the word "formalized." All of the companies maintained some level of defect tracking, ranging in complexity from stacks of paper with handwritten bug reports to a customized cross-platform client-server database application, and in all cases at least one employee spent part of their time documenting defects as they were found. To me, this is not "formalized testing"--it's "informal testing" at best, and IMHO it's a stretch of the meaning of the words to even call the behavior of some of these companies "testing" at all. Contrast with e.g. CVS, EGCS, Perl, or Tcl, all of which have significant formalized (and mostly automated) test suites. In particular the CVS and EGCS projects publish their test results on mailing lists where anyone who wants to know can see exactly how well the developers are doing. Also contrast with the Linux kernel and the Debian distribution. Formalized testing definitely does occur on subsets of these projects, as sophisticated end users and even a few developers run their own test suites and benchmarks on each new revision, although the code coverage is by no means complete. To say that no testing exists in open-source software at all is a gross overstatement. Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D