[LWN Logo]

 Main page
 On the Desktop
 Linux in the news
 Linux History
All in one big page

See also: last week's Letters page.

Letters to the editor

Letters to the editor should be sent to letters@lwn.net. 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.

April 19, 2001

From:	 Charlie Stross 
To:	 letters@lwn.net
Subject: Free downloads of CD images
Date:	 Thu, 12 Apr 2001 12:17:13 +0100

Apropos the lack of a SuSE 7.1 downloadable CD image ...

Here in the UK, I rent a colocated server. Bandwidth costs between 7
and 15 (i.e. $10-$22) per gigabyte per month. Thus, if I were to provide
an FTP service, downloadable CD images would cost roughly $5-$10 a pop.

Of course, by buying bandwidth in bulk (my very own OC3 line!) I could
probably cut the cost by an order of magnitude. And bandwidth costs
in Europe are higher than in the US; again, it's an order of magnitude
cheaper where you're standing.

Nevertheless, the key fact is that those distributors who provide FTP-able
CD images are providing a service which costs them money to run. In the
beginning, when they were poor, they sold CD's. Then they floated or
otherwise became cash rich, and could afford to run FTP servers with
enormous bandwidth. Now that the economy is looking gloomy, is it any
surprise that they're seeking to transfer the burden of costs back onto
the shoulders of the consumers (who are, after all, the people who used
to pay them by purchasing CD's)?

There's a lot to be said for Tannenbaum's Law: "never underestimate the
bandwidth of a pick-up truck travelling cross-country with a trunk full
of magnetic tapes" -- or, in its contemporary incarnation, the bandwidth
of a FedEx parcel full of DVD-ROMs.

NB: I just did the following:

  dd if=/dev/cdrom of=suse-7.1.1.iso
  bzip2 -9 suse-7.1.1.iso

This compressed the image file from 601,997,312 bytes to 507,265,922.
Which suggests to me that there's still a bit of slack space in those
filesystems full of oh-so-compressed RPMs. Given that enhanced
compression would cut the cost (to the distributors!) of running a
download service by up to 15%, maybe it's about time someone looked
into the best way of providing a CDROM image. Maybe a tiny bootable
Rock Ridge partition followed by a highly compressed filesystem?

-- Charlie Stross

I are sigfile disease!!
All your quote are belong to us.
Copy us every "sig"!

From:	 "Lou Grinzo" 
Subject: "End of free beer"
Date:	 Fri, 13 Apr 2001 10:05:08 -0400

I think your coverage in the "end of free beer" piece was very fair and
enlightening.  But I do want to add one comment: Companies blaming bandwidth
for the need to charge are being disingenuous, to say the least.  There's a
perfectly good way for them to distribute ISO images with very little
bandwidth requirement on their part: They can break them up into pieces and
distribute them via newsgroups.

There are already tools available for doing this, including the
closed-source RAR and my own open-source BitBox, and the process has been
very well worked out a long time ago by the people who exchange things like
CD-size anime movies and other binaries in newsgroups.  All SuSE or anyone
else has to do is upload their ISO image once every two weeks (a very
simple, automated process), and the download burden would be spread across
hundreds or thousands of newsgroup servers around the world.  It also makes
it easier for the user to grab really huge packages, like entire distros, in
pieces, without the hassle of trying to connect to a swamped ftp server,

I'm amazed that no one in the open source community is routinely doing this,
and I've been trying to convince people to give this approach a chance.
(See my web page for BitBox at
http://home.stny.rr.com/gizmodrome/bitbox.html, for example.)

In fact, I think it might be a good idea to get a few broadband users (like
myself) to band together (The Broadband Band? <g>) and take turns uploading
packages like various distros, the binaries for the latest KDE, GNOME,
Ximian, or whatever.  This should be restricted to just those packages that
can be uploaded legally, of course, but that would clearly help a lot of
people gain better access to free software.

Take care,
Lou Grinzo

From:	 Nathan Myers 
To:	 letters@lwn.net
Subject: Wind River Systems' liability
Date:	 Thu, 12 Apr 2001 02:15:19 -0700 (PDT)

From: Nathan Myers <ncm@nospam.cantrip.org>
Re: WRS (alleged) perfidy, and what to do about it

To the editors,

Last week LWN published a letter hinting that Wind River Systems may 
have deliberately violated the GPL.  Readers may wonder, suppose that 
happened to me, what could I do about it?  (Disclaimer: I'm not a 
lawyer, but this is my understanding.  Further, I am only using WRS 
as an example here; I have no personal knowledge of any violations.)

First, if Wind River didn't give you the binaries, they don't owe you
the changed sources.  They are only obliged to offer the sources to 
somebody who got the code from them.

Second, if you're not the copyright holder, you don't have "standing"
to enforce it.  Only the copyright holder and whoever they empower has 
the right to sue.  (In the case of Gdb, I believe this is the FSF.)  
If the FSF decides not to enforce it, they are effectively extending 
additional rights to Wind River Systems beyond what is in the GPL.  
They may choose to demand money from WRS in exchange for that 
extension, e.g. as part of an out-of-court settlement.

Third, if you are the copyright owner of code accepted into Gdb, you 
assigned rights to that code to the FSF, so you still depend on them 
to enforce it.  However, you may have standing to file a suit if the 
FSF just can't be bothered, but will testify that they haven't offered 
WRS any additional rights.  FSF could, in principle, undermine your 
case any time by settling separately with WRS.  Similarly, WRS might 
pay their customer(s) not to testify on your side, making it harder 
to prove your case.  These risks might make it hard to find a lawyer
to take the case "on spec".

Fourth, if WRS does this with a product in which you own code and for
which you *haven't* assigned rights to the FSF, you can sue.  (The Linux 
kernel is an example of a GPL'd work for which copyright assignments 
are not collected.)  Besides forcing WRS to release the code, you might 
collect substantial damages for past violations.  Or, something might go 
wrong (e.g. you miss filing some paper, or you draw a crooked judge) in 
which case you could end up owing various people lots of money.

In summary, it can be pretty hard, and can be dangerous, to enforce 
the GPL.  

Nathan Myers

From:	 Richard Stallman 
To:	 eric@brouhaha.com
Subject: Wind River violating the GPL
Date:	 Sat, 14 Apr 2001 22:12:54 -0600 (MDT)
Cc:	 letters@lwn.net

    I left that company before I could pursue the matter any further.  But
    others have told me that they've had the same experiences with Wind
    River since then.

If anyone has had this experience, he should inform the FSF.  We can
enforce the GPL, if we have people who can swear to the particulars of
a violation.  In general, when you know of a violation of the GPL, you
should always inform the copyright holders of the program in question,
because they are the ones who have "standing to sue" if the license
is violated.

From:	 Havoc Pennington 
To:	 editor@lwn.net
Subject: guadec interoperability progress
Date:	 14 Apr 2001 12:03:35 -0400


People might want to read Dave Mason's report from GUADEC here:

Two notable things, first we had a group of KDE hackers at GUADEC and
a keynote by Matthias Ettrich, and a lot of good interaction/planning
went on; second the GNOME Foundation Board of Directors adopted the
following statement:

  We believe that for GNOME to be successful, it needs to interoperate
  with other computing environments and services platforms. Thus we
  are in favor of increased collabration with KDE to insure end users
  will be able to seamlesly mix KDE and GNOME applications.

The fact is that one primary virtue of open source software, and our
big selling point vis-a-vis the proprietary world, is that we put the
needs of the user first - we put the customer in
control. Interoperability is a specific customer need that's
underserved by the proprietary world. So we are making
interoperability - not just with KDE, but with Windows, Java, etc. - a
primary concern of the GNOME project.
A second motivation for our statement is the observation that ISVs are
often scared off by press reports of the GNOME/KDE conflict, and they
fear that they will select the wrong desktop to support with their
applications. Thus we are joining with the KDE project to commit to
interoperability, and to ensure that selecting a development platform
for an application will not mean selecting one or another group of
users. That is, ideally, users using GNOME or KDE should not care what
toolkit was used to develop an application. This will be our goal, and
already the GTK+ and Qt teams have been working together on various
initiatives. And of course it's already true that apps written with
GTK+ or Qt will work fine on either desktop; the remaining challenges
are primarily cosmetic.

This is not to say there can't be friendly competition between GNOME
and KDE. But it should be comparable to the competition between
various window managers; they all work with all apps, and the choice
is up to users. Users should even be able to choose some of the
lower-profile desktops such as XFCE or GNUStep if they
like. It's just a harmless user preference. 

Competition on this level is beneficial, a good way to ensure progress
continues - witness the stagnation in Motif/CDE once the "desktop
wars" were over, and compare it to the constant advances made by GNOME
and KDE. But competition must be accompanied by a firm commitment to
interoperability. So we are making that commitment and following
through by working closely with the KDE team.

This isn't all new at GUADEC; see http://www.freedesktop.org where
work has been going on for some time. But progress at GUADEC I hope
makes our seriousness of purpose very clear.  We are firmly committed
to the view that the real war is between free software and proprietary
software. The war between GNOME and KDE is decidedly over, with users
and free software as the victors.


From:	 Jim Dennis 
To:	 lwn@lwn.net
Subject: MMU-less CPUs: ucLinux
Date:	 Sun, 15 Apr 2001 15:51:40 -0700


> Opinion: Inder Singh on The ELC Platform Specification (LinuxDevices)
>  Press, April 14 (Saturday)

> Dr. Inder Singh has written this opinion piece on why he believes
> the ELC Platform Specification will succeed where the POSIX effort
> failed. "Now, there is a real opportunity for Linux to fulfill the
> promise of UNIX and POSIX. Linux is already available from many
> vendors, and since all the different versions start with the same
> kernel, there is a high degree of compatibility and interoperability
> between different embedded Linux distributions. At the same time,
> Moore's law has largely eliminated the resource constraint issue. In
> fact, with the falling prices and increasing power of system-on-chip
> (SOC) devices and memory, and the growing software complexity of
> embedded applications, a Linux style of operating system with its
> process model is an excellent fit for today's high volume embedded
> devices compared to the legacy flat address space real-time
> operating systems that can work with MMU-less CPUs."

 I feel the need to point out that Linux (uCLinux) can run on 
 CPUs which lack MMUs (paging and virtual memory support).

 Naturally more info on uCLinux can be found at http://www.uclinux.org

 It concerns me that Dr. Singh would express such ignorance of
 such an important segment of his own field.  uCLinux is one of the
 major forces in embedded systems.  He re-iterates his lack of 
 interest in non-MMU CPUs in this white paper at

 Anyway. That's a nitpick I suppose.  Hopefully Lineo (the company
 with the greatest commercial interest in uCLinux) will use their 
 position on the ELC to ensure that uCLinux is not slighted in 
 drafts of this ELC Platform Spec.

 On another note, here are some of my personal comments on 
 Linux and embedded systems.

 In discussing Linux and embedded systems I think it's useful to 
 distinguish between systems that use the Linux kernel in their
 target hardware, and though that use a tool chain hosted on Linux 
 to support other kernels on the target platform.  

 I'm sure Dr. Singh is familiar with this issue since BlueCat Linux
 is used as a development host for both the LynxOS kernel and for 
 the BlueCat Embedded target.  Perhaps the oversight is deliberate
 since it appears that LynxOS has no support for systems with no MMU.
 (Though one might infer that the BlueCat embedded target might, 
 considering its references to the ARM7 *with MMU*, and other references 
 to other ARM7 and ARM9 systems which don't specify their MMU support).
    (*) http://www.lynuxworks.com/bluecat/index.html

 Once upon a time I perceived a distinction between "turnkey" and 
 "embedded" systems which seems to have been lost.  Perhaps it was
 a misperception on my part.  

 Traditionallly it seemed that the term embedded system referred to
 software/firmware which was incorporated into devices which served
 some primary function that was *not* related to computing or information
 processing.  For example, devices which are "embedded" into a microwave
 oven, or the many MCUs and CPUs that are built into a typical modern
 automobile.  Often these devices have been designed under significant 
 constraints on memory, storage, power consumption, heat dissipation,
 RF emissions and or sensitivity, tolerance to physical vibration and
 G-forces, heat and other hostile environmental factors.

 The term "turnkey" seemed to be applied to dedicated computing 
 devices that were primarily intended to manage data.  Thus POS
 (point-of-sale), and telephony switchgear were traditionally referred
 to as "turnkey" systems rather than embedded systems.  This distinction
 was additionally useful since "turnkey" systems generally were less
 constrained (relative to common desktop and laptop computing equipment).
 In other words the design contraints placed on a telephone switch or
 a POS terminal (cache register) aren't significantly more onerous than
 those placed on a quality server or desktop.  (Oddly enough there are
 somewhat tighter constraints placed on telco equipment regarding RF and
 sound emissions; but they aren't much different).

 By my reckoning a PDA would be a turnkey system.  Like a laptop, it
 is primarily a data/information management device (although it does
 have significant power consumption, heat dissipation, and physical
 size/weight and computing (RAM/storage) footprint constraints.

 However, a cell phone fits into an interest gray area.  It's primary
 function is communications but many ancillary computing functions
 (such as WAP/WML browsers) have been incorporated into new cell 
 phones (with more on the way).
 Perhaps this blurring of terminology has occurred because of a 
 blurring and blending of requirements and applications.

From:	 "John D. Rowell" 
To:	 letters@lwn.net
Subject: You would think they would know better by now
Date:	 Fri, 13 Apr 2001 21:43:18 -0700
Cc:	 Henry Kingman ,
	 Rick Lehrbaum 

In the "Linux gets embedded (ZDNet)" story on LWN today ("Press, 
April 13 (Friday the 13th)"), you reserved a paragraph to mock the use of
"clone" as the relationship between Linux and Unix, as a display of
how theoretically incompetent the source of the article was.

May I recommend that the LWN Editors take a moment to check out the 
following quite authoritative link:


or simply open up the README file in the root directory of _any_
Linux kernel (2.4.3-ac5 for instance, if the above link doesn't
seem to be up to date enough), and pay special attention to the
paragraph under "WHAT IS LINUX?".

I guess the old saying _is_ true, nobody reads the documentation
anymore. sigh.


John D. Rowell      <me@jdrowell.com>        <jdrowell@appwatch.com>
[irc: jdrowell]     http://jdrowell.com      http://appwatch.com
[icq: 6273503 ]     my GPL'd apps            Free Software / Open Source
[pgp: http://jdrowell.com/pgpkey] "I see fat people!"
From:	 M Carling 
To:	 lwn@lwn.net
Subject: Correction
Date:	 Thu, 12 Apr 2001 13:58:25 -0700 (PDT)
Cc:	 michael@helixcode.com

Bonobos are not monkeys.  They are apes.  BTW, "very good at coupling" is
a great euphemism.  Bonobos mate about 20 times per day.  Also, Bonobos
and humans are the only mammals that can mate face to face.

The family tree looks like this:

                               /  \
                              /    \
                             /      \
                            /        \
                           /          \
                         Apes        Monkeys
                         /  \          /|\
                        /    \        / | \
                       /      \
                      /        \
                     /          \
                    /            \
                 Lesser         Great
                  Apes           Apes
             (e.g. Baboons)      /  \
                  /|\           /    \
                 / | \         /      \
                              /        \
                             /          \
                        Orangatang      /\
                                       /  \
                                      /    \
                                     /      \
                                    /        \
                                   /       Gorilla
                                /  \
                               /    \
                              /      \
                             Man     /\
                                    /  \
                                   /    \
                                  /      \
                                 /        \
                              Bonobo    Chimpanzee



Eklektix, Inc. Linux powered! Copyright © 2001 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds