Linux in the news
All in one big page
See also: last week's Back page page.
LWN, of course, is based in Colorado, and we're generally pretty happy with that. A look at the Bay Area Linux Events calendar, however, is almost enough to make one change one's mind. People over there have a lot of fun...
If you're not in the Bay area, or are stuck at home, the Linuxcare product comparisons page can be a good place to look to find some fun new software to play with instead. The breadth of the coverage is growing; this page is turning into a useful resource.
Section Editor: Jon Corbet
October 5, 2000
Nine years ago: October 5, 1991, was the day that Linus first released Linux to the world.
Two years ago (October 8, 1998 LWN): We asked "what will happen to the Linux VARs?" With companies like Dell making noises about getting into Linux, it looked like life could get harder for companies that sold Linux-installed computers. Two years later, most of those companies are still around and doing better than ever. But people still wonder what will happen when the Dells of the world get serious...
A new Linux news site called LinuxToday was launched by Dave Whitinger and Dwight Johnson.
Nice thought of the week:
The arguments are both noble and naïve. Linux has a cult-like following, matched only by that of the Macintosh OS and OS/2. It's a modern Unix! It's stable, superior, enriching! It's gonna get creamed. -- Richard Brandt, Upside.
Upside has since changed its tune on Linux, to say the least.
Oracle8 for Linux went up for free download. For a long time Linux supporters had heard people say that "when Oracle is available for Linux" they'll know it's serious. It was serious.
One year ago (October 7, 1999 LWN): Sun announce the release of the Solaris source code - under the Sun Community Source License. One year later, that source release has yet to make much of a splash.
Microsoft came out swinging with its Linux Myths page:
Linux is a higher risk option than Windows NT. For example how many certified engineers are there for Linux? How easy is it to find skilled development and support people for Linux? Who performs end-to-end testing for Linux-based solutions? These factors and more need to be taken into account when choosing a platform for your business.
Meanwhile, some people figured out that ssh 1.2.12 had been published under a free software license. People grabbed hold of it, and the OpenSSH project was born. OpenSSH is now the standard version for Linux systems.
Red Hat 6.1 hit the FTP servers, though the boxed version wasn't due out until October 18.
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: Thu, 28 Sep 2000 12:01:03 -0700 (PDT) From: Jonathan Walther <email@example.com> To: Dave Peacock <firstname.lastname@example.org> Subject: Re: Outrage at Debian dropping security for 2.1 If you want us to support security, perhaps you could propose some incentive? We are all volunteers here at Debian, interested in putting out a quality distribution. Your time is limited, otherwise I'm sure you too would love to fix and upgrade your distribution from source. But our time is also limited, and we want the most bang for buck out of it. That means not fighting the current of progress, and keeping up with new versions of software. If security updates are of concern to you, perhaps you could get your company to pay some Debian maintainers to work on the old distribution. If you have the time, perhaps you would like to volunteer to do some of that maintainership yours. The distribution we've just released is the culmination of 2 years of hard work for us. Try it. You'll like it. Unlike many other distributions which require a reinstall from scratch, Debian guarantees a reliable upgrade path. Sincerely, Jonathan Walther Debian GNU/Linux Developer
Date: Fri, 29 Sep 2000 14:22:22 -0700 (PDT) From: Seth Cohn <email@example.com> To: firstname.lastname@example.org Subject: Re: Outrage at Debian dropping security for 2.1 Branden Robinson: > Does Mr. Peacock expect Debian to provide security updates for Debian 2.0, > 1.3, 1.2, or 1.1? Does he expect, say, Red Hat, to provide security > updates for 6.0? How about 5.0? 4.2? 1.0? > If someone is willing to maintain reliable, net-accessible slink, hamm, bo, > rex, and buzz boxen for all architectures supported by those releases, then > perhaps we can do what Mr. Peacock expects. Otherwise... A few of us discussed this last night at our LUG meeting, and the obvious answer is that since the security fixes tend include source changes, someone can always grab the source for the 'security' fix from the later version and rebuild the package. Yes, some libraries etc might need to be changed, and this isn't 100% but anyone who is sticking with Slink for production purposes should be able to use Potato fixes in many cases. In the rare cases where things don't work, I'd bet if someone posted a request for a Slink package version of a new security fix, saying clearly that the existing Potato package didn't work, someone would repackage it to fit. In another vein, this clearly could be support revenue for someone interested. Supporting older Debian releases could be very lucrative for the right person(s). Maybe Debian's normal volunteer security team isn't interested, but someone might be if the price was right. Seth Cohn
Date: Thu, 28 Sep 2000 23:36:37 -0500 From: Branden Robinson <email@example.com> To: Dave Peacock <firstname.lastname@example.org>, email@example.com, Subject: Re: Outrage at Debian dropping security for 2.1 It was pointed out to me today that perhaps Mr. Peacock did not release that Debian 2.1, a.k.a "slink", is *not* the currently released version of the Debian system. The current version is Debian 2.2, a.k.a. "potato", which was released in July, and we certainly take security updates very, very seriously for this release (as well as other issues, such as usability, that merit an update to the released distribution). Perusal of the past several weeks' worth of Linux Weekly News will reveal that Debian is quite timely with security updates to our released current distribution. (The distribution currently in development, codenamed "woody", sees updates literally every day.) Does Mr. Peacock expect Debian to provide security updates for Debian 2.0, 1.3, 1.2, or 1.1? Does he expect, say, Red Hat, to provide security updates for 6.0? How about 5.0? 4.2? 1.0? Does Netscape continue to support Navigator 3.0? 2.0? 1.1? -- G. Branden Robinson | One man's "magic" is another man's Debian GNU/Linux | engineering. "Supernatural" is a firstname.lastname@example.org | null word. http://www.debian.org/~branden/ | -- Robert Heinlein
Date: Wed, 4 Oct 2000 17:12:50 -0700 To: email@example.com Subject: Security updates for Debian 2.1 "slink" From: Rick Moen <firstname.lastname@example.org> Dear Ms. Coolbaugh and Mr. Corbet: Last week's letter from Dave Peacock raises the interesting question of whether the Debian Project erred in discontinuing (effective Oct. 30) security updates for the former Debian-stable branch, 2.1/"slink", which was obsoleted by the new Debian-stable, 2.2/"potato", on Aug. 15. At first glance, Deve's outrage seems justified. His 2.1 machines appear destined to be left in the lurch. But this is a mirage, as can be best seen by an example: On August 1, Dave hasn't installed updates (including those for security) in a while. So, as root on each machine, he executes the following commands: apt-get update #Gets new available-package lists from a Debian mirror apt-get dist-upgrade #Upgrades all installed packages to current revs. apt-get clean #rm's package master files from /var/cache/apt/archives/ The packages retrieved are from the 2.1/slink branch, because on Aug. 1, 2.1 still bore the "stable" designation. Any security fixes will be among them, since they are merged into the mirror collections as the Debian Security Team releases them. Let us say that, on August 16, Dave runs the standard update command sequence again. Because the Debian Project switched the "stable" tag from 2.1 to 2.2, the previous day, Dave's systems now receive a few more package updates than usual, but not many. He may not even realise that he has auto-upgraded to 2.2 -- the upgrader tools' default configuration in /etc/apt/sources.list says "track stable", not "track 2.1". Because of Debian-stable's enforced package policy and emphasis on incremental upgrading without downtime, this late-2.1-to-2.2 upgrade is undisruptive, like prior ones within 2.1. So, on Sept. 21, when he writes his LWN letter expressing outrage that security updates for his 2.1 boxes wil cease in 1 1/2 months, those machines have already been 2.2 for more than a month. There _is_ ongoing security maintenance support for 2.1, you see: It's called "Keep using the routine Debian update mechanism to continue following 'stable', which recently moved past 2.1." It's possible that Dave was unaware of Debian's maintenance tools, and has been retrieving security updates by hand. (It is difficult otherwise to understand his machines remaining on 2.1.) If so, he'll be pleased to hear about those tools, as they require less effort and possibly even less bandwidth -- and yield markedly better results, e.g., minimising security-exposure windows by automatically implementing even security updates whose alert bulletins you haven't seen. I'll be glad to assist him (in e-mail) with any questions.  For pre-release access, add this line to sources.list: deb http://security.debian.org/ stable/updates main contrib non-free -- Cheers, "Teach a man to make fire, and he will be warm Rick Moen for a day. Set a man on fire, and he will be warm email@example.com for the rest of his life." -- John A. Hrastar
Date: Thu, 28 Sep 2000 12:34:56 +0100 From: firstname.lastname@example.org To: email@example.com Subject: GPL/BSD: alternative prisonners' dilemma The leading article on BSD/GPL in this week's LWN is not entirely fair. You focus on the release/ not release decision _once_ the choice of using a piece of open source software has been made, and changes have been developed. But will you reach the point where the decision you focus on has to be taken? A more interesting decision game is when the commercial company decides to use free software or not. We have two players: the open source Developer and the commercial Company, who cannot communicate with each other in the spirit of the prisonner's dilemma game -- and practically because these decisions are taken at different points in time by disjoint groups and are normally unrelated. Thus, the Developer has two choices for their release: (1) use BSD, (2) use GPL. Because the Developer has read your article (or does what the mainstream open source movement does) they rationally choose the GPL. The commercial Company has two choices, (1) exclude GPL software (prefer BSD or commercial or internally developed software instead of GPLed) or (2) also use GPL software. Because they know that the requirement to release _may_ put their competitive advantage at risk, they rationally decide not to use GPL software. They do that even if they are ready to release most code they do, because it usually has nothing to do with their competitive advantage, but they do not want to lose their future freedom to keep even a single line of their own code private, and lose that freedom forever. The outcome of the game is thus that the Company does not use the software of the Developer so the open source community loses all the possible non-competitive enhancements and the Company has extra effort to do if the GPL software is better than alternatively licensed. They both lose out in a classic example of the prisonner's dilemma, a situation created solely by the GPL. The game works as well if the Company is replaced by someone who values the freedom of everybody to do what their want with open code more highly than the narrow definition of freedom in the GPL, or people who simply oppose the GPL for ethical reasons -- be it the misanthropic nature of the GPL, or whatever. Of course, this game is as true as the one with the opposite result at the later stage. The results of the sum of these games seem hard enough to evaluate that they do not contribute much to the purely strategic question: does the GPL produce more or better open source code than alternative licences? Maybe we can keep on opposing or supporting the GPL on ethical grounds. -- Franck Arnaud ~ email: firstname.lastname@example.org
Date: Thu, 28 Sep 2000 13:17:51 -0700 From: Marc Matteo <email@example.com> To: firstname.lastname@example.org Subject: Your One Big Assumption (GLP less business-friendly friendly) In your editorial this week you make one *huge* assumption when you write: > A company that releases code under the GPL need not fear > what its competitors will do - the risk of competing against proprietary > enhancements is gone. This assumes that all parties are playing by the rules. The company that releases code under the GPL still needs to fear that their competitors will happily violate the GPL and take their GPLed code and make it proprietary. How would anyone know? How would you check? Cheers, Marc -- Marc Matteo Online Technology Leader, sacbee.com http://www.sacbee.com
Date: Sun, 01 Oct 2000 15:50:13 +1000 To: email@example.com From: Dark Fiber <firstname.lastname@example.org> Subject: this weeks 'Is the GPL really less business-friendly' editorial your a pro linux site, and thus pro gpl. why even bother with the useless editorial of the gpl vs bsd license stuck on the front page? dont you think you are preaching to the converted? an editorial is an opinion. i know exactly what i do and dont expect from a linux news site. but i have to wonder what you hoped to achieve with your editorial... especially running it as item #1. -Stuart George -df [ Dark Fiber <email@example.com> Running FreeBSD 4.1 ] [FAQ] Write Your Own OS http://www.mega-tokyo.com/os/ 3x3 Eyes Fan Fiction Archive http://www.mega-tokyo.com/pai/ Sarien Sierra Emulator http://www.mega-tokyo.com/sarien/
From: "Mark Christensen" <Mchristensen@htec.com> To: <firstname.lastname@example.org> Subject: RE: "Is the GPL more business friendly than BSD style licenses?" Date: Tue, 3 Oct 2000 16:52:11 -0400 Though I agree this issue is enormously important as more and more people depend on the production and maintenance of free software for their livelihood, I don't think you have framed the question properly. I doubt that the question you asked has a single answer. Different business objectives lend themselves to different licenses. As you mentioned one feature of the GPL is that it protects a company's intellectual product from being incorporated wholesale into a competitor's proprietary product, but this is not always an advantage. I reciently had a conversation with a couple developers at SGI, and they mentioned that as one of SGI's chief reasons for releasing a significant amount of code under the GPL. They believed that if they released their code under a LGPL, or Open BSD license, competitors like Sun Microsystems, and to a lesser extent Microsoft, would "steal the SGI crown jewels." Obviously SGI's objective was not merely to keep Sun from using their technology. They also want to support Linux as a competitor to Solaris, and promote integration between Linux and Irix. In this case, if SGI wants their code integrated into the Linux kernel, the GPL is the only choice. On the other hand, for stand alone software SGI's desire to support an alternitive to Solaris would be served either a BSD or GPL license. So, for SGI the choice of the GPL is the clear result of strategic decisions about how to achieve several significant business objectives. But for a different company under different circumstances the same kind of strategic thinking would lead to the choice of a BSD style license. For this example, let's take a look at a fictitious network security firm. They are primarily a professional services firm that audits the security of large heterogeneous networks. They have created several security tools to automate some of the work involved in large-scale security auditing on Unix an NT boxes. For our hypothetical security company these tools are not a primary source of income, in fact they only sell their software to current clients as part of a larger contract. Nor are they worried about their software being incorporated into proprietary products, because the software without the services is not particularly valuable to a highly security conscious company. All in all, they would much rather have long standing audit/monitoring contracts with fortune 500 companies, than sell a couple of hundred software licenses. In fact, they would see it as a great boon if their tools were included in distributions of Solaris, Irix, Free BSD, and Linux, since this would be a tremendous PR tool, as will as an easy path to a very tightly integrated security contract with a wide variety of Unix vendors. For this company, the use of a BSD style license is almost a forgone conclusion. And I expect that the ease of implementation across a variety of platforms motivated the use of the BSD style license used for the standard implementation of the Kerberos protocol. In the past I’ve heard, and even repeated the argument that the GPL would have protected the protocol from any attempt to co-opt the standard. And in one sense they would be right --the GPL would have set the bar higher. But Microsoft’s “clean room” re-implementation standard would have negated any of the obligations that come with re-use of GPLed code. So, GPLing the code would not have helped fight Microsoft (who had the resources to re-implement) but it would have slowed the acceptance of the protocol by smaller companies (who might clearly do not have the same kind of resources as Microsoft). My point in all of this is that the choice of licenses is very complex, and a wide variety of issues need to be weighed very carefully. And that, unfortunately, is why major license decisions need to be made with input from lawyers, PR people, marketing departments, in addition to programmers, and project managers.
From: <email@example.com> Date: Thu, 28 Sep 2000 01:33:07 -0600 To: firstname.lastname@example.org Subject: Privacy Foundation on :CueCat The privacy foundation said: ... the :CueCat software attaches a unique user ID to each scanned bar code. This unique ID number, along with the bar code, is then sent back to Digital:Convergence Corp. computer servers. This feature could potentially allow the company to track the :CueCat scans of every consumer who registers for the service. To which Digital Convergence Replied: Yes, it's true, and I would have gotten away with it, too if it hadn't been for THOSE DARN KIDS! Scoobie Doo references aside (The French demographic is probably thoroughly confused by now) this is another damn good reason (As if we needed another one) why it is not in our best interests to allow our rights to reverse engineer a product to be infringed. This sort of thing is already commonplace and will become more so if companies can arbitrairly hide behind arbitrairly restrictive hardware and software license agreements. As if being able to use a device that you purchased in the fashion you choose with your hardware wasn't already enough... If you're one of the people talking to Al Gore or George Bush on MTV, be sure to grill them thoroughly on this issue. -- Bruce Ide email@example.com http://www.paratheoanametamystikhood.net
Date: Thu, 28 Sep 2000 14:41:37 -0400 From: Derek Glidden <firstname.lastname@example.org> To: email@example.com Subject: IBM _really_ into Linux? >From your "Linux and Business" page of Sept 28: "Other companies announcing support for Red Hat Linux 7 and Red Hat Network include Computer Associates, IBM Corporation, Lotus, Novell and Tivoli." Or if you want to be more literal: "Other companies announcing support for Red Hat Linux 7 and Red Hat Network include Computer Associates, IBM Corporation, IBM Corporation, Novell and IBM Corporation." I guess IBM really likes Red Hat Linux 7. :) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- With Microsoft products, failure is not Derek Glidden an option - it's a standard component. http://3dlinux.org/ Choose your life. Choose your http://www.tbcpc.org/ future. Choose Linux. http://www.illusionary.com/