|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Sergey Lentsov 2:4615/71.10 19 Apr 2001 17:11:54
To : All
Subject : URL: http://lwn.net/2001/0419/letters.php3
--------------------------------------------------------------------------------
[1][LWN Logo]
[2]Click Here
[LWN.net]
Sections:
[3]Main page
[4]Security
[5]Kernel
[6]Distributions
[7]On the Desktop
[8]Development
[9]Commerce
[10]Linux in the news
[11]Announcements
[12]Linux History
Letters
[13]All in one big page
See also: [14]last week's Letters page.
Letters to the editor
Letters to the editor should be sent to [15]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 -L-7
and -L-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"
To:
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,
etc.
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
[16]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
ncm@nospam.cantrip.org
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
Hi,
People might want to read Dave Mason's report from GUADEC here:
[17]http://people.redhat.com/dcm/guadec.html
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 [18]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.
Havoc
From: Jim Dennis
To: lwn@lwn.net
Subject: MMU-less CPUs: ucLinux
Date: Sun, 15 Apr 2001 15:51:40 -0700
Regarding:
> 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 [19]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
[20]http://www.lynuxworks.com/products/linuxinitiative.html
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).
(*) [21]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:
[22]http://www.kernel.org/pub/linux/kernel/README
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.
_jd_
--
John D. Rowell <me@jdrowell.com> <jdrowell@appwatch.com>
[irc: jdrowell] [23]http://jdrowell.com [24]http://appwatch.com
[icq: 6273503 ] my GPL'd apps Free Software / Open Source
[pgp: [25]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:
Primates
/ \
/ \
/ \
/ \
/ \
Apes Monkeys
/ \ /|\
/ \ / | \
/ \
/ \
/ \
/ \
Lesser Great
Apes Apes
(e.g. Baboons) / \
/|\ / \
/ | \ / \
/ \
/ \
Orangatang /\
/ \
/ \
/ \
/ \
/ Gorilla
/
/\
/ \
/ \
/ \
Man /\
/ \
/ \
/ \
/ \
Bonobo Chimpanzee
[26]Eklektix, Inc. Linux powered! Copyright Л 2001 [27]Eklektix, Inc.,
all rights reserved
Linux (R) is a registered trademark of Linus Torvalds
References
1. http://lwn.net/
2. http://ads.tucows.com/click.ng/pageid=pageid=132-000-001-001
3. http://lwn.net/2001/0419/
4. http://lwn.net/2001/0419/security.php3
5. http://lwn.net/2001/0419/kernel.php3
6. http://lwn.net/2001/0419/dists.php3
7. http://lwn.net/2001/0419/desktop.php3
8. http://lwn.net/2001/0419/devel.php3
9. http://lwn.net/2001/0419/commerce.php3
10. http://lwn.net/2001/0419/press.php3
11. http://lwn.net/2001/0419/announce.php3
12. http://lwn.net/2001/0419/history.php3
13. http://lwn.net/2001/0419/bigpage.php3
14. http://lwn.net/2001/0412/letters.php3
15. mailto:letters@lwn.net
16. http://home.stny.rr.com/gizmodrome/bitbox.html
17. http://people.redhat.com/dcm/guadec.html
18. http://www.freedesktop.org/
19. http://www.uclinux.org/
20. http://www.lynuxworks.com/products/linuxinitiative.html
21. http://www.lynuxworks.com/bluecat/index.html
22. http://www.kernel.org/pub/linux/kernel/README
23. http://jdrowell.com/
24. http://appwatch.com/
25. http://jdrowell.com/pgpkey]
26. http://www.eklektix.com/
27. http://www.eklektix.com/
--- ifmail v.2.14.os7-aks1
* Origin: Unknown (2:4615/71.10@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
URL: http://lwn.net/2001/0419/letters.php3 |
Sergey Lentsov |
19 Apr 2001 17:11:54 |
|
|
