Linux in the news
All in one big page
See also: last week's Back page page.
The CLUE Linux Centre is an actual bricks-and-mortar place, but it's worth an electronic look as well. Based in Toronto, their purpose is to become a permanent research and demonstration center for Linux - the first in the world, they claim. They have also undertaken the "Learnux" project - taking old castoff computers, installing Linux, and donating them to schools and students.
The Linux Bulletin Board is set up to host Linux-related discussions on a number of topics. The number of messages thus far is low...let's see of LWN readers can stir things up a bit for them...
Section Editor: Jon Corbet
September 16, 1999
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.
To: email@example.com, firstname.lastname@example.org Subject: Debian FSG vs. DNS Security license for BIND Date: Thu, 09 Sep 1999 23:22:22 -0700 From: John Gilmore <email@example.com> As the person who negotiated the DNSSEC license that permits BIND to use patented RSA technology, let me clarify the intent involved. Debian is free to put in as much effort as it wants in eliminating this 'DNSsafe' code, but I believe it won't exist in BIND after the patent expires in October 2000 anyway. I therefore suggest living with it for a year as the easiest and most beneficial course. The reason the BIND authors licensed the code, and the reason RSA licensed them to use it, was for the mutually beneficial purpose of jump-starting a public key infrastructure centered on the Domain Name System. Debian should not undermine this goal if it can see a way to support it. The DNSsafe code is copyrighted by RSA and requires custom licensing, unlike the rest of BIND. If the BIND authors continued to use the RSA code in BIND even after the patent expired, it would make BIND distribution and maintenance more cumbersome. They are far more likely to replace it with code that is unencumbered. Debian contributors could perhaps best use their time by writing a free, compatible, and extremely fast replacement for this code. This would provide ISC with a ready-made free alternative as soon as they are released from having to license the patent. Given the US Commerce Department's erratic interpretation of the export regulations, I recommend having a non-US contributor write it, even though the regulations make it clear that authentication code is not covered by US export controls. (An earlier prototype of BIND that used RSAREF for authentication was denied access to the authentication exemption; this denial was administratively appealed by Hugh Daniel, the applicant, and is awaiting a determination from the US Bureau of Export Administration.) As a firm believer in free software I don't want Debian to undermine their stand for freedom. The question at hand is what's the best response when the unfree code is temporary. John
From: "David Jao" <firstname.lastname@example.org> Date: Thu, 9 Sep 1999 03:44:40 -0400 (EDT) Subject: Caldera and GPL To: email@example.com > Caldera says "Ok, if you want to get your hands on this CD you've > got to sign this piece of paper which says that you have decided to > not exercise your rights under the GPL Section 6 of the GPL (attached below) states very clearly that under no circumstance may Caldera impose _any_ further restrictions on the end-users rights under the GPL, even if the end user has signed a document permitting Caldera to do so. The end user has no legal authority to give up their end-user rights. Those rights are mandated by the original licensor (i.e., the software author), and only the original licensor of the software can give permission for Caldera to restrict those rights. > 6. Each time you redistribute the Program (or any work based on > the Program), the recipient automatically receives a license from > the original licensor to copy, distribute or modify the Program > subject to these terms and conditions. You may not impose any > further restrictions on the recipients' exercise of the rights > granted herein. You are not responsible for enforcing compliance by > third parties to this License. The end user can certainly agree not to sue for their rights, but the original licensor is under no such restrictions. No matter what the end user has signed, the original licensor of the software could sue Caldera, and would have a pretty strong legal case. -David
Date: Thu, 09 Sep 1999 13:51:45 -0600 From: Bruce Ide <firstname.lastname@example.org> To: email@example.com Subject: Security and Kernel Modules Please note that at the time the kernel module is installed, the intruder already has root access to your system. I think a bigger issue is the simplicity of obtaining root access once you've compromised a user account. In my humble opinion, distribution maintainers are far too free with those setuid bits. Packages requiring setuid access to the system should undergo thorough and documented third party source code auditing, as should the C library itself and any other components that the setuid package relies upon directly. Closing the buffer overflow hole would be a huge step in the right direction too, perhaps through the implementation of something like the Linux-Privs project. No one takes security seriously enough and I believe that a major disaster is going to be the result of this lazyness. I'm not talking about just Linux either. Will it take a bank losing several billion dollars or some group shutting down a huge portion of the nation's electrical grid before we start taking security seriously? Will we take security seriously even if that happens? It's only a matter of time before something like this happens, and I only hope there won't be a huge loss of lives in the process. As far as kernel modules go, perhaps some mechanism could be put in place to allow cryptographic signing of the modules and the execution of only signed modules. Of course, this would be pretty difficult to implement given the US Government's asinine stance on crypto but I'm sure our friends in free countries like Finnland or Russia could come up with a set of patches that could be downloaded and applied to a kernel. -- ---------------- Bruce Ide firstname.lastname@example.org
To: "LWN letters" <email@example.com> Date: Thu, 09 Sep 1999 10:15:33 -0700 From: " " <lkollar@my-Deja.com> Cc: Subject: Kernel feature thrashing > The natives on linux-kernel are starting to get > restless. These patches are considered necessary > by many just to get a working system. Why do they > not find their way into the mainstream kernel? That's a valid question, but IMHO another question that should be asked is "are people upgrading because they have to, or because a new version is out?" One of the reasons people use Linux and other open-source software is to step off that "upgrade treadmill." Why apply that commercial-software thinking here? If the kernel you're using does the job you need, maybe you should consider keeping it until you have a good reason to upgrade -- especially if you have to hand-patch in features you consider essential. Old habits die hard, I guess. I guess the anti-Linux camp will have a field day with this issue. I can see the quotes now: "Linux is having growing pains" or "Linux is collapsing under its success" or "Linux failures underscore need for commercial support." Yuuuuuck-o. All this <b>really</b> means is that Linux users should examine their needs and determine whether a new kernel release meets those needs before upgrading. (If you want to be a guinea pig to help the cause, that's a different story.) After all, it's not like you won't be able to find working software just because you don't have version 2.2.10 or greater. In fact, you could use kernel 2.0.37 and not be left behind, except for a few specialized admin tools. This <b>is</b> Linux we're talking about, not Windows. Larry "Dirt Road" Kollar
Date: Thu, 09 Sep 1999 10:13:04 +0200 From: Michael Thayer <firstname.lastname@example.org> To: email@example.com Subject: New code in stable kernels I can see that people are reluctant for major changes to be made in stable kernels. However the RAID and NFS problems might be solved by creating a new stable line (something like 2.2b) when 2.2 has settled down - a sort of "half major" release like Debian is planning. Yours, Michael Thayer
To: firstname.lastname@example.org Subject: User space utilities that depend on kernel version Date: Thu, 09 Sep 1999 14:12:30 +0100 From: Andrew Stitcher <email@example.com> It has seemed to me for as long as I have been using Linux (since 0.99 and SLS days) that there is a problem in the way that utilities that are intimately bound up with the kernel are distributed. There are quite a number of user space utilities that depend on a particular version of the Linux kernel to function and vice-versa for some things the kernel depends on the correct user space program - for instance update, insmod, ps, procinfo. mount and similar things. As the kernel and these utilities can't really be separated it makes sense (to me at least) that they should all be distributed together and maintained in the same source tree, that is the kernel source tree. If this were done the days of getting a kernel patch to fix NFS or RAID say and then needing to go search the web for the correct versions of the user space tools would be over. What do other people think? Andrew
Date: Sat, 11 Sep 1999 21:41:00 -0500 (CDT) From: <firstname.lastname@example.org> To: email@example.com Subject: Thoughts on sort-of-open-source Star Office (long) I've been brewing over this Star Office deal for a while and have come up with some thoughts on the matter... I've always had sort of an ambivalent attitude towards Sun the corporation. While they do produce some really good software (about an order of magnitude better than MS's usual crud), and have played an extremely important role in the Unix world, their political plays in the free software world leaves me wondering. Sun seems to want to have their cake and eat it too. On the one hand Sun played a key role in helping to legitimatize Linux in a number of ways. They were one of the early players to join up with Linux International. They sponsor an excellent service at http://www.sunfreeware.com by providing packages for the GNU tools so that us poor saps who have to administer Sun boxen don't have to recompile the tarballs all the time. All this and many other "small favors" do add up in the long run. But on the other hand we got this SCSL thing: all the disadvantages of commercial software combined with none of the advantages of free software. Why? Let me elaborate a bit: Back in the dawn of the century, there was a popular type of music called Ragtime that was all the rage with younger folks (and was condemned as Satan's music by some older folks :^). If you actually took a close look at Ragtime music, you noticed two immediately apparent things. One, the inherent structure of the music was hideously complex. Two, all ragtime tunes were hideously complex in a rather identical manner. In other words if you wanted to write a ragtime song, you had to follow some rules that were set down in stone. Ragtime did not entirely allow for a lot of flexibility. Needless to say, ragtime didn't last for very long. For one, all the songs sounded the same (go figure :^), and so it got a little old with the listeners. For another, song writers had mostly migrated to a new type of music that was gaining ground: Jazz. Jazz was nice in that you could pretty do what you wanted to do. Granted, there were some basic rules you had to follow, but the flexibility of Jazz allowed it to survive for nearly a century (and it's still going strong). Similarly, Rock music has the same sort of flexibility (more or less), and thus it too has lasted decades longer than ragtime could ever hope to. Which brings me back to the SCSL. Now the SCSL is Sun's answer to free software. They say "We give you the source, but we control everything you do, and you have to play by our rules." Well, having rules is fine. But the restrictiveness of the license puts Sun's license in the same position that Ragtime had when Jazz started to become really popular. The GNU license provides flexibility in that if, say, Red Hat ever decides for whatever reason to drop GNOME, a group of developers can pick it up and continue using it and working on it. Not so with Star Office. I am at Sun's mercy, which is no better than being at MS's or AOL's mercy. Heck I got into Linux because I was no longer shackled by what some faceless corporation thought was best for me. That's why I feel that Star Office, though it may end up being somewhat successful, won't take the steam out of any free software office suite. There's more flexibility and freedom over there. :^) Just like how I might be able to listen to a Ragtime song or two every now and then, I'll pick one of the many flavors of Jazz that have come down the pipe over the decades to listen to any day. - Dave Finton