Linux in the news
All in one big page
See also: last week's Back page page.
If ever needed to look for something that was posted to a mailing list somewhere, you'll likely appreciate the mailing list archive at The AIMS Group. It is a searchable, long-term archive of an unbelievable number of Linux-oriented mailing lists. Next time you need to search something out of, say, samba-vms or snort-devel, you'll know where to look.
Industrial Linux is aimed at administrators of Linux servers. It will be a portal with news and how-to information; there is also an Industrial Linux distribution in the works.
Section Editor: Jon Corbet
November 30, 2000
Two years ago (December 3, 1998 LWN): Digital Creations opened up the source code for Principa, its object-based web development platform, and integrated it with Bobo, its open-source web toolkit. The two projects were combined and renamed Zope, the rest is history.
There was some haggling over just who owned the trademark for the term "Open Source". The Open Source Initiative (OSI) and Software in the Public Interest (SPI) both claimed ownership of the term. Since then the term turned out not to be trademarkable, and SPI appears to have gone dormant (its last news item is from June, 1999).
The current development kernel was version 2.1.130, the basted turkey release.
Novell was investing in Caldera and had rumored plans to open up some of the Novell NDS source tree. IBM, by way of Transarc, made AFS available for Linux.
Some things never change:
"linux isnt secure and it isnt stable," my informant writes, with is usual bracing disdain for grammar and punctuation. "its a moving target that never really gets out of beta. sure people run production sites on linux. i know alot of these people. they dont get much sleep and have grown opaque from the lack of sunlight."
One year ago (December 2, 1999 LWN): Corporate acquisitions of Linux companies were busily happening, partly due to the high value of Linux stocks. SCO and Sun were both looking to buy a Linux distributor, possibly Caldera. Turnaround is fair play, Caldera is currently finishing the details of the purchase of SCO. Sun ended up buying a Linux hardware vendor, Cobalt. Red Hat was rumored to be considering the purchase of "anything that moves" and had recently acquired Cygnus.
Still, to some observers, the question of copyright and licensing -- the question, ultimately, of who controls the GNU software developers -- is the single most important question in the world of free software. Red Hat now bestrides that world, more than ever before, like a colossus. Even if most individual free-software developers appear unconcerned with the implications of the Red Hat-Cygnus merger, corporate competitors to Red Hat might have reason to be nervous.
Linux made a big splash at Comdex with the Linux Business Expo. One year later, the Linux Business Expo was even bigger and was still going strong. Network appliances were big at Comdex but the Embedded Linux boom was in its infancy.
The XFree86 project joined X.org, a fitting move since XFree86 has been the real center of X11 development for some time...
VA Linux Systems headed quickly toward its IPO, and announced a directed share program for Linux hackers. Participants in the program did very well...assuming, of course, they are not still holding on to the stock... VA also announced the hiring of Samba hacker Jeremy Allison as part of its new Professional Services Division.
Lynx Realtime Systems (now LynuxWorks) launched its "BlueCat Linux" embedded distribution.
And, don't forget the LWN Raccoon incident: just as we were about to celebrate a year of server uptime, a warmth-seeking Raccoon found its way into a nearby power distribution point and brought down our server (and much of a city block with it). One year later, the LWN server has, well, one year of uptime. Just in time to be powered down in favor of the new server...
Letters to the editor should be sent to firstname.lastname@example.org. 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: Wed, 22 Nov 2000 00:17:30 -0800 (PST) From: "Robert A. Knop Jr." <email@example.com> To: firstname.lastname@example.org Subject: Fingerprint scans & the "end" of passwords As I write letters to LWN, frothing at the mouth as I express alarm at various trends in modern society, I can't leave out biometrics. This is the use of your fingerprint (as mentioned in the "Security" section of LWN on November 23), retinal pattern, voice print, or even DNA as a way of authenticating yourself. They are widely touted as being superior to passwords for several reasons. First, nobody else can guess them. Second, they really do authenticate *you*. Thrid, you can't forget them. However, they suffer from one really huge flaw in comparison to passwords. If your password is stolen, you can change it. You can't change your fingerprint. Sure, stealing a fingerprint may be technically quite a bit harder than stealing a password-- but eventually it will be done. Maybe not to you, but the determined will find a way to do it to some. It is naive to assume otherwise. And, when it is, you're hosed. You can always get a new password, or a new card and PIN number, but if everything authenticates you on your fingerprint, you can never be secure again once your fingerprint has been stolen. Indeed, in certain circumstances, stealing a fingerprint may not be that hard. Most passwords are stolen today by network sniffers, grabbing unencrypted network traffic as it traverses the internet. To "steal" a fingerprint, you wouldn't have to spoof the fingerprint reader. You would only have to spoof the information that the fingerprint reader reports. This reduces it to exactly the same problem as stealing a password. Of course, a well-designed system could use a challenge-response protocol analogous to public key cryptography, which would make this sort of spoofing very difficult (just as ssh protects you from having your password sniffed). However, do you really trust the people creating the infrastructure of the ineternet to do this right? All they have to do is goof once, and huge amounts of unchangeable fingerprint data can be stolen. Look at the track record of companies like, say, Microsoft, when it comes to good security. In the dark day of laws like the DMCA and the UCITA, it will be easier for companies to sue people who complain about their security than it is for them to create a truly good security system. I think biometrics are a good idea for authentication-- *if* they are coupled with passwords or their equivalent. But biometrics by themselves are a startlingly bad idea. I like having different passwords for all of my sundery different accounts. I like being able to change them when I think one has been broken. I gladly accept the inconvenience of having to remember and type these passwords each time, in exchange for having an authentication system that can still work even after an individual authentication key is stolen. I find it alarming that so much of the popular media and the population seem to believe that biometrics will be a panacea for network security and authentication, and that passwords will go the way of the dinosaur. The only real drawback ever mentioned is cost, and that is going away. Doesn't anybody understand the utility of being able to change a password? -Rob Knop email@example.com
Date: Thu, 23 Nov 2000 16:55:51 +0100 To: Linux Weekly News <firstname.lastname@example.org> Subject: The European Software Patent Horror Gallery Hello, You wrote on the European Software Patent Horror Gallery and those stupid patents which have been granted in Europe. Although I still think that all software patents, not only these stupid ones, should be abandoned I would like to let you know that these patents are not defendable in European Courts as these patents are invalid in most European countries. Yes, indeed, it's strange perhaps for you to think on it. But the patent treaty denies in article 32 the European Patent Organisation (EPO) to grand patents on computer software. The EPO -as many greedy patent lawyers- is still trying to get the right to grant patents on software. It might make them rich. Best regards, Fred -- Fred Mobach - email@example.com - firstname.lastname@example.org Systemhouse Mobach bv - The Netherlands - since 1976
From: Julio Cesar Gazquez <email@example.com> Date: Sat, 25 Nov 2000 00:40:31 -0300 To: firstname.lastname@example.org Subject: Office consortium I think this is a very special, important moment, if the people involved takes advantage of it. StarOffice becomes open source. KOffice is being rapidly improved, and I guess that happen to other office apps, like Abiword, Gnumeric, etc. However, all these projects suffer a severe, even well-known problem. Even the best attempt to exchange data with MS-Office applications is very troublesome. There is no chance to share files of reasonable complexity back and forth between a MS-Office and StarOffice, even when StarOffice has the best filters out there. Of course, a brief analysis shows the reasons behind this: 1. Most people use MS-Office, so you should support its file format if you want some success. 2. The Office file formats are closed, so filters are created through reverse-engineering process. 3. Microsoft does its best effort to difficult filter creation, doing weird changes in each Office release. However, despite MS wishes and similar market share of Internet Explorer, we are still surfing the web with no much trouble. The key is, of course, HTML is open, and it was there long before Microsoft get into browser business. Unfortunately, the world never knew an open, well defined, free word processor nor spreadsheet file format. But now, we have at least three free word processors and three free spreadsheets. Star Office is free, and the other projects are probably mature enough to keep a stable architecture for a while, with well known technical needs. They should join to define common open formats for word processor and spreadsheet files. These formats should be able to include all the features their parent apps need, and allow a seamless interoperability between apps. A properly defined standard format can attract the interest of governments and corporations, as they are suffering the problem as any of us, and this Office consortium should encourage this, as this situation could force MS to adopt those formats as well. Anyway, common formats should give to the free office apps a combined market place that allows them to empower their individual chances to grow. -- Saludos Julio César Gázquez
Date: Wed, 22 Nov 2000 18:12:18 -0800 (PST) From: "Alan W. Irwin" <email@example.com> To: firstname.lastname@example.org Subject: Re: I'm alarmed about LinDVD I agree with much of what Robert A Knop said in his LWN back page piece. In particular: "If the stupid laws like the DMCA are going to stand despite how contrary they are to the concepts of freedom on which the USA was putatively founded, Linux users really have only two choices. Admit defeat and surrender to the proprietary commercial forces that many in the community have been resisting for so long, or boycott DVDs altogether." My wife and I feel so strongly about this that we boycott all Hollywood products. We encourage others to do the same since Hollywood companies are directly attacking the freedom that is so important to the Linux community. In the same paragraph Robert Knop goes on to say: "The latter will be difficult, because the format is the only game out there in its performance class, and because DVDs are becoming hugely popular. But the MPAA stranglehold on the *format*, which seems to prevent even the possibility of free drivers, is unacceptable." Personally, I don't feel quite so pessimistic about this. Hollywood may well have ruined the DVD format forever. But will they be able to control all data storage formats for the indefinite future? For example, there has been some recent news about FMD devices which potentially can store 140GB in a CD-sized disk with a recordable version planned for the end of 2001 (http://www.wirednews.com/news/technology/0,1282,40053,00.html). There may also be other large data storage formats/devices in development which are driven by the urgent need for viable backup solutions for today's large cheap hard disks. In summary, I don't believe Hollywood's narrow, selfish interests can ultimately stop technological development in an area where there is such a wide market-driven interest in finding a good solution for long-term storage of data. Help Hollywood to do The Right Thing by boycotting *all* their current products. Alan W. Irwin email: email@example.com phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________
Date: Tue, 28 Nov 2000 11:27:42 -0500 From: "Jay R. Ashworth" <firstname.lastname@example.org> To: email@example.com Subject: How the Grinch stole Linux? In this week's edition, you quote Michael Tiemann, CTO of RedHat as saying: "At the same time it's also important to note that we do have many of the guys who are doing a lot of the key kernel infrastructure that allows companies like Mandrake to write these things. If the Linux kernel did not support the API's that are needed by ReiserFS or it didn't support the capabilities needed by these other tools then the whole open source eco-system would collapse. So we think it's great that other people are doing open source development also." That's a fairly disingenuous comment, I think. Either that, or Mike forgets that there was a Time Before RedHat. How does he think that it came to be that there *was* a kernel to plug those API's into? "...we do have many..." Yeah? So what. So do VA, and Penguin, and for that matter SuSE, Turbo, and Mandrake. Let's face it, in the current environment, it's unlikely these guys would be begging. Perhaps RH got to the "employ kernel hackers to hack" well first, but that doesn't mean they own the well. "If the ... kernel didn't support the APIs..." Does *Linus* havea new job, and I missed it? I didn't think anyone else was unilaterally installing API's in the kernel. And as far as "So we think it's great..." Well, Mike? I'm glad to hear that. Us dahkies gonna go sing spirituals in the corner now. You might consider this letter in somewhat the same light as the interview that Tampa Bay Buc defenseman Warren Sapp gave to the St Pete Times last Saturday. You know: the one where he told the reporter how much he thought the Bucs offense was sucking lately? I think it's perhaps time for a slight reevaluation of mission -- as it regards interacting with the open-source/free-software/and, indeed, Linux-specific community -- on the part of the executive staff at RedHat. We made them. And we can *break* them, just as easily. The stockholders would, if they knew about it, probably find this lack of faith disturbing. Yo, Bob? Mike? Eric? You guys listening? Cheers, -- jra -- Jay R. Ashworth firstname.lastname@example.org Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 -----------------------------
Date: Wed, 29 Nov 2000 04:11:40 +0000 From: Dafydd Harries <email@example.com> To: firstname.lastname@example.org Subject: Re: Art vs. Craft Please excuse the length of this letter! In LWN on the 16th of November, in your development section, it was said: > But while these projects were formatted badly, they all seemed to work fine > (mostly). What coding standards bring isn't more stable code, just the > ability to more easily maintain projects. Coding standards work well for > larger organizations, especially spread across multiple development sites, > because you never know who will end up maintaining the code at some given > point in the future. In my opininon, good formatting and code standards (or lack of them) can make (or break) a project, simply for the reason that it makes it easier (or harder) to contribute. I myself have had itches with software that I use regularly, and have correspondingly tried to go through the source code of the program to work out how I could make changes. When I encountered masses of cryptic, unreadable code, however, I gave up. > Open source projects often start with someone with an itch and a spare > minute. Design isn't the goal - results are. Interestingly enough, that's > often true of successful proprietary projects as well. The need for > processes and standards comes with project maturity. Software is like > humanity - we like change less and less with age. But any change we do > accept needs definitive rules and order. Code needs to be clean to provide > extension and maintenance. But seldom is it that way from day one. A "spare minute" is more or less what I had - I didn't have the hours (or the patience) to work out how the program worked. Although writing messy code quickly will tend to have good short-term results, it will discourage participation in the project. On the other hand, if the source code of the program is clearly written - it doesn't even have to be to a coding standard - then people with itches will find it easier and quicker to scratch their itches and improve the software for everybody. Unfortunately, I can imagine that willing and able hackers are being prevented from contributing only too often when projects raise the bar of contributing too high. Apart from this, a clear, simple layout makes the overall structure of a program easier for everybody to understand, even the original author(s). This can be detrimental in deciding whether bugs are spotted - the "many eyes, shallow bugs" concept does not work so well if people cannot understand clearly how a program works. If Free software is to triumph over proprietary, projects must actively spend time to make it easier for people to hack them. Copious technical documentation (this is sadly an oxymoron, in my experience) and clear code are the way to a better future for everybody. A project which few people can contribute to is sure to undergo much less improvement than one that allows more people to help. Spaghetti projects are harder to debug than clear ones. This is important for new projects as well as mature ones - a project may never become mature unless it is easy for people to move it forward. As for the original title - "Art vs. Craft" - I believe the best programming is a mixture of both. Dafydd Harries