On the Desktop
Linux in the news
All in one big page
See also: last week's Letters page.
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.
August 30, 2001
From: Garry Knight <email@example.com> To: firstname.lastname@example.org Subject: Linux's birthday Date: Thu, 23 Aug 2001 14:11:27 +0100 Dear Sirs I see from your front page on Thursday 23 August that there's some controversy over exactly when Linux's first birthday will be. You quote August 25 and October 5 as possible candidates. On page 87 of Linus's autobiography, "Just for Fun", Linus himself says: "There's a protocol for numbering releases. It's psychological. When you think a version is truly ready to be released, you number it version 1.0. But before that, you number the earlier versions to indicate how much work you need to accomplish before getting to 1.0. With that in mind, the operating system I posted to the ftp site was numbered version 0.01. That tells everybody it's not ready for much. "And yes, I remember the date: September 17, 1991." Could this be a better candidate for a birthday? -- Garry Knight email@example.com ICQ: 126351135 Linux registered user 182025
From: "Robert A. Knop Jr." <firstname.lastname@example.org> To: <email@example.com> Subject: Sad about Source Forge Enterprise Edition Date: Fri, 24 Aug 2001 10:26:34 -0500 (CDT) Before I say this, I must say that I don't fault VA Linux. However, seeing them going to selling proprietary extentions to an open source project makes me sad. Not because I think that VA Linux has sold out or anything-- but because it's yet one more nail in the coffin of what I had hoped would be the software model of the future. That model was much like FSF's: software would be free, and users (large and small) who wanted it would pay for maintainance and support. The argument always went something like, what if we're a large company, and we want to buy a lot of hardware and have it just work? The answer was, buy your hardware from somebody like VA Linux, and then buy a support ocntract for all the software. If you find that the support you're getting is unsatisfactory, the software is free, so you can find another company (say, Red Hat) to support your software installation. You're not locked into mandatory support contracts forever more from one single monopoly. Or, if you're a smaller site, find an outfit with a smaller plan, or hire a Linux Geek who will both support your installation as well as contribute back to the efforts of free software programmers (and, thusly, be enough in the community to draw on the de facto software support that comes from it). Alas, VA Linux, like Red Hat, was a sort of poster child for this. They were a hardware vendor who sold hardware with (at least mostly) free software. But now that model is gone, and to survive, they feel that they have to go selling and supporting proprietary software. As long as VA Linux does continue to support and contribute to the Open Source community as they do now, with things like Sourceforge and keeping Eric Raymond on staff, I won't fault them or bear ill will towards them. But their selling of proprietary extentions to the Sourceforge software does seem to be one more strike agains those of us who still want to think that the Free Software/Open Source model of software development is one that can work and that ultimately will be the best for everybody. -Rob
From: David.Kastrup@neuroinformatik.ruhr-uni-bochum.de To: firstname.lastname@example.org Subject: Stallman and things Date: 23 Aug 2001 11:59:39 +0200 The problem of Stallman is that of many a great revolutionary: once the idea they have so painfully nurtured and fostered and kindled has finally caught on and is spreading like a wild fire, they cannot simply leave it to itself and restrain the urge to control what needed their care for a long time. Sort of a children and parent problem. Stallman is no fool, but a bit out of touch with reality. Apply the proper grain of salt when listening to him. He has deserved it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: David.Kastrup@neuroinformatik.ruhr-uni-bochum.de
From: Kapil Hari Paranjape <email@example.com> To: firstname.lastname@example.org Subject: Freedom zero and all that Date: Sat, 25 Aug 2001 12:41:23 +0530 Dear LWN, I read with interest your editorial this week ("Let's beat up on Richard Stallman") and the articles by O'Reilly and the others. Of course this has led to another series of postings in various fora and the debate will rage on. Here is my 2 paise worth. 1. RMS < FSF < GNU < GPL. But we are often guilty of equating them. In particular, each time RMS makes a statement that people object to they use it as an excuse to beat up on the FSF and sometimes the GPL as well. Of course, RMS himself is guilty of over-reaching on some of these inequalities... 2. The GPL is about the user's freedom. What O'Reilly (and open source) is talking about is the developer's freedom. But the distinction between users and developers is a grayscale and not black and white. We all start as (l)users and (should) try to attain some sort of mastery. The GPL says that every developer *must* help a user in this by letting the user (a) use the program (b) study and adapt it (c) get friends involved in this ativity (d) carry on the work of developers that came before by helping others too. 3. If developers grant themselves the "freedom"/"power" to stop helping users in this way *or* users grant themselves the right to expect "readymade" fixes from developers forever, it is only a matter of time before the division is created and made permanent. Unfortunately, O'Reilly's "freedom zero" is easily distorted into a freedom for developers such as in (3). The response from RMS/BMK also too easily interpreted to mean a user's "right to expect" as in (3). A cliche (actually the title of an Indian soap opera) may help! "Sans bhi kabhi bahu thi" (A mother-in-law was also a daughter-in-law once). Kapil Paranjape.
From: Michael Alan Dorman <email@example.com> To: firstname.lastname@example.org Subject: Thanks for cutting through the rhetoric! Date: 23 Aug 2001 07:27:05 -0700 Your "Should we be talking about freedom?" section on the Main Page of this week's issue is something that I would hope many people will read and remember and refer back to. Although I'm personally happy I work on "Debian GNU/Linux" rather than "Debian Linux"---I got started using GNU software before I started using Linux (heck before Linux existed), and I *do* think the GNU part is really important---it's a point on which reasonable people may disagree. The value of freedom, however, is one thing which I would hope people would recognize is essential and Richard Stallman is our conscience on this matter, with all that implies: an inability to compromise, a tendency to nag, and hundreds of other annoyances that one must, nevertheless, tolerate because he is also our benchmark---you may not share his values, but you always have a fixed, absolute point from which to navigate. I will, however, spare you with my jeremiad against Eric Raymond, including my analysis of why his response to Stallman and Kuhn is obviously slanted against them, and why I don't think Eric Raymond really cares deeply about any freedom other than that of gun ownership. :-) Mike. -- "One does not write satire anymore; one merely tries to stay half a step ahead of reality." -- Jon Carroll
From: Stuart Thayer <email@example.com> To: firstname.lastname@example.org Subject: Eric Raymond Date: Thu, 23 Aug 2001 13:14:16 -0400 Folks: I think Eric Raymond's missive to Stallman and Riley bends backwards too far to be fair. Fairness is, most would agree, a noble thing. But he seems naive, at least for the sake of making his point, about American politics. There is a far greater chance of outlawing open source than outlawing proprietary software, so the power play isn't as equal as it may seem. U.S. politics is based on bribery. We don't call it that, of course; we call them campaign contributions. Even our illustrious Supreme Court tries to bamboozle us by calling them free speech, thus protected by the First Amendment. The U.S. may be the only country in the world where bribery enjoys constitutional protection. Owners of proprietary software, with their profits, are thus in a far better position to bribe U.S. lawmakers to make free software illegal than developers of free software, with few profits, are to persuade, cajole, jawbone, or otherwise plead -- with no monetary incentive -- lawmakers into making proprietary software illegal. I'll leave it to you to decide which poses the greater danger.
From: David Gibson <email@example.com> To: firstname.lastname@example.org Subject: Flerbage Date: Wed, 29 Aug 2001 13:08:46 +1000 Cc: email@example.com, firstname.lastname@example.org The FSF's use of the word "freedom" might be confusing, but Eric Raymond's flerbage argument is certainly a straw man. Eric postulates that a law banning proprietary software has been passed. Thus, he argues he could now be thrown in jail for offering people software under the same proprietary license as he did before the ban, which would indeed seriously diminish his flerbage. But why on earth would anyone pass a law making it a jailable offence to offer a proprietary license, when all that is necessary to effectively "ban" proprietary licenses is to modify copyright law so that they are unenforceable. Essentially Eric's argument assumes that it is possible to offer proprietary licenses, whereas the point of banning them would be to make it impossible, rather than to punish people merely for making the attempt. So let us suppose instead that proprietary software was "banned" in this much more sensible way. Now, in such a world, I could go and offer software under a proprietary license to whomever I pleased. Of course, whoever I did offer it to is quite likely to either a) laugh in my face, or b) take the software and then do whatever they please with it, since they know I can't enforce my license restrictions. Still, I'm not going to be dragged off to prison for it. So, while this state of affairs might be unfortunate for me if I was planning to live off license sales, it hasn't affected my flerbage. Note that in the above I haven't actually touched on the issue of whether banning proprietary licenses would be a good idea or not. That's a much more subtle issue, and one that can't be decided on matters of flerbage alone.  Strictly there are two things which would have to be done - first make explicitly restrictive licenses unenforceable and second remove the built-in restrictions imposed by copyright .  Before anyone points out that this would probably also make the GPL unenforceable, that's strictly true, but irrelevant. A ban on proprietary licensing would give many of the rights (e.g. unrestricted duplication and modification) that the GPL grants automatically and while someone could promulgate binaries but not sources to a formerly GPLed program, there would be little incentive to do so. -- David Gibson | For every complex problem there is a email@example.com | solution which is simple, neat and | wrong. -- H.L. Mencken http://www.ozlabs.org/people/dgibson
From: firstname.lastname@example.org To: email@example.com Subject: /dev/random silliness Date: Thu, 23 Aug 2001 09:32:03 -0700 Folks: The vast majority (perhaps all) of the people who use /dev/random to the exclusion of /dev/urandom in their crypto applications are doing so out of ignorance, and are not making their application any safer for their users. Assume that the random pool has been initialized with 160 bits which no attacker can guess. (That assumption is the hard part, but if it is wrong then /dev/random can fail just as easily as /dev/urandom can. Note that this implies that /dev/urandom *must* block or otherwise signal an exception if this precondition is not met.) Now for an attacker to guess the output of /dev/urandom he must accomplish one of the following: 1. perform roughly 2^160 work (i.e. guess-and-check for all possible initial states) 2. exploit a flaw in the cryptographic underpinings of the /dev/*randoms (e.g. SHA1) 3. penetrate the computer and read the state of the random pool 4. exploit a flaw in the code that implements the /dev/*randoms In practice, some combination of these might enable an attack, although obviously #1 will never happen, as long as the attacker is confined to using conventional (Turing machine) computers. Now my point is that /dev/random can fall to an attack like this just as easily as /dev/urandom can! In fact, the added complexity of implementing the /dev/random behavior makes #4 *more* likely for /dev/random than for /dev/urandom. Not to mention that /dev/random's specification *requires* the applications that use it to become susceptible to a DoS attack by sucking down the "entropy estimate" count. Here's the real kicker: with the exception of a true One Time Pad, any application that uses /dev/*random is going to also use some cryptographic primitives like a block cipher, stream cipher, secure hash, public key cryptosystem etc., now each of *those* primitives themselves are susceptible to a massive, impossible brute-force attack (attack #1, above), just like /dev/urandom is! Therefore, there is absolutely no improvement in using /dev/random over /dev/urandom, and then feeding the results into a block cipher which is itself susceptible to an impossible (e.g. 2^128) brute force attack. The bottom line is: if you are not implementing a true One Time Pad that utilizes no cryptographic primitives -- it uses only XOR -- then you shouldn't be using /dev/random. To do so opens you up to a DoS attack, and makes the security of your app depend on more complex code, but gives you no real-world improvement in security. Regards, Zooko
From: Leandro =?ISO-8859-15?Q?Guimar=E3es?= Faria Corsetti Dutra <firstname.lastname@example.org> To: email@example.com Subject: Kernel /dev/random entropy only adds to security worries Date: Thu, 23 Aug 2001 16:03:00 -0300 > Once again, nobody has ever gotten close to demonstrating an attack of > this nature, but if security people didn't worry they would have little to > do. It seems to me that it wasn't intentional, but this sentences sound to me like the author meant that security people had to worry about very improbable events in order to get occupied. It sure can be construed like that, and that's certainly not true, as bad security practices almost everywhere already give them surely plenty of labor. -- _ / \ Leandro Guimar„es Faria Corsetti Dutra +55 (11) 246 96 07 \ / http://homepage.mac.com./leandrod/ BRASIL +55 (43) 322 89 71 X http://tutoriald.sourceforge.net./ mailto:firstname.lastname@example.org / \ Campanha fita ASCII, contra correio HTML mailto:email@example.com
From: "Tom Poe" <firstname.lastname@example.org> To: <email@example.com> Subject: RH and Proprietary Software Comment Date: Thu, 23 Aug 2001 22:14:41 -0700 Hello: You mention the issue of proprietary software being written specifically for RH, this week. You mentioned that there might be some straying from LSB by RH, which then would have the market move away from other distributions in order to have access to proprietary software written for Linux. My comment is, that such a path is going to be followed, only if the software is critical to a business. If it's not critical, CFO's are going to have to have some other compelling reason to become vendor inmates once again, don't you think? Further, it's my humble opinion, that RH has already crossed the line into proprietaryville. I can't help but feel they look like a duck, smell like a duck, talk like a duck, walk like a duck, and are a proprietary product at this point. Maybe it's time they're called a duck/proprietary product, and need to be recategorized by Open Source folks, or whatever. Tom
From: Robert Bihlmeyer <firstname.lastname@example.org> To: email@example.com Subject: Debian and proprietary software Date: 24 Aug 2001 14:16:35 +0200 > However, if a business chooses to run Debian and also chooses to use > a proprietary software product shouldn't this combination just work? Why should it? While Debian states that it supports its users even when they're running proprietory software, no claims are made that no work on the users's part will be required. Making proprietory software easy to run on Debian is certainly not a primary goal of the project. Debian developers and users may of course choose to make this their goal, and support it independently. > Should that business be forced to use a different distribution just > because it is tied to a third party product? This is a mode of > operation more reminiscent of certain proprietary operating systems > than of Linux. Oh, come on! What is Debian doing to /force/ its users to a different distribution? Certainly, some of them may be faced with the choice between easily installable proprietory software on the one hand, and whatever advantages one sees in Debian over, say, redhat. Debian is simply omitting a feature that many Debian users can do without, not actively prohibiting others from using it the way they like. Is redhat /forcing/ Sparc owner to Debian for not providing an appropriate port of their distro? Perhaps, what you really want to see is a distribution with the same technical featureset as Debian, but a different social agenda. Fine by me, but please let's make this a new distribution, not a future Debian. > World domination [...] ... is more reminiscent of certain proprietary operation system vendors, no? -- Robbe
From: Leon Brooks <firstname.lastname@example.org> To: email@example.com Subject: Simple example of Unix flexibility Date: Sun, 26 Aug 2001 13:47:16 +0800 Many LWN readers will not need to delve into the guts of their systems to do what they want done, and may miss most of the goodness in their systems. Many similarly inclined non-LWN-readers may wonder what all the fuss is about with Linux, and with Unix and general, and why geeks get so hyped over it. I ran across a little example just now which shows how useful the flexibility of the Unix every-program-is-a-tool attitude can be. The problem: I have an ISO image of some Open Source software CDs in files on a hard disk, and I want to get them out and burn some copies onto CD-R media. The partition that the ISOs are in is ReiserFS format instead of the traditional Linux ext2. Windows users can think in terms of a Win2k partition instead of NT-4.0-level NTFS. the tools I have to achieve this with are an unlimited supply of Windows 9X boxes, one Mandrake Linux 8.0 box [ohso] which can read ReiserFS but can't be shut down to have a hard disk installed, and one RedHat Linux 7.1 box [archenland] which can't read ReiserFS and also can't be shut down to be taught how, but does have a CD burner. All on the same LAN. The solution, step by step (follow the bouncing ball): * Plug the offending hard disk and a Linux Router Project (LRP) floppy into a random Windows 98 box [aravis]. * Boot aravis under Linux. LRP can't read ReiserFS either. * From ohso, "ssh -x aravis 'cat /dev/hda5' >hda5.image" to copy the 2GB partition across the LAN from the LRP box. * "mkdir 1; mount -t reiserfs hda5.image 1" to make a temporary directory and attach the local copy of the partition to it. * "scp 1/*.iso archenland:" to copy the ISO images to the box with the burner. * From archenland, "cdrecord dev=0,4,0 -eject -speed=6 first.iso" (and repeat for each ISO). If that had been a Windows-based problem, I would have had to go out and find a working machine that had an OS capable of reading the hard disk, and a CD burner. Else just cry into my peppermint tea (I'm a weird Aussie, I don't like beer). Did I mention that this is on a Sunday and in the middle of the Australian outback, 1400km from the city? A couple of things worth noting: I can burn those CDs in a machine several hundred meters away, securely and with no special software, and have a computer illiterate feed CD-R blanks for me as required; archenland is UW SCSI so can safely burn about 12-14 CDs at once; authors of newer Gnome and KDE packages tend to make them specialised rather than flexible - please don't; Microsoft have finally remembered that mounting is useful, and have implemented it for XP; Does anyone have a useful standalone version of NT, 2000, or XP that fits on one floppy? For those interested in LRP, I took the EigerStein2BETA image from http://lrp.steinkuehler.net/, wrote an IDE-enabled kernel on it, added modules for all of the network cards used here, lost the DHCP, DNS and web packages, added sshd, made a key and lost keygen, added hdsupp. Hand-edited syslinux.cfg then used lrcfg to "backup" all packages and reboot to test. If anyone wants to host a copy of the finished product, just ask. This LRP floppy is used for recovering vital stuff from dead Windows boxes before reGhosting, and for quick network solutions (random box + extra LAN card + floppy == instant router, add another floppy for a proper webserver or the like). More powerful LRP-like bootable CDs are also available for machines that actually have CD drives. We hope that you enjoyed the show.