lkml.org 
[lkml]   [1999]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel tarball size
Hi Mark.

>> the way they're currently done because he's used to it and feels
>> that what suits him automatically suits everybody else.

> don't be petty; it's you who are assuming that your interests
> automatically suit everyone else.

Nope, that was a summary of the beliefs expressed in about three dozen
separate emails when I first proposed the idea, nothing more and
nothing less.

I'll be quite clear about my stance on this issue: I earn good money
sorting out the mess made by newbies who install a Linux distribution
(any distribution, that makes little difference), then try to upgrade
via tarballs that all extract into the same directory, the way the
Linux kernel tarballs do, along with a small number of the other
utilities.

Invariably, by the time I get called in, they've extracted the latest
kernel tarball, tried to compile it, failed, extracted an earlier
tarball into the same tree, tried to compile that, ended up with
something that's a mixture of the two, and somehow managed to get the
system to boot off this composite kernel!!! Ditto with probably a
dozen of the other major utilities.

If Linus was to start doing what he should've been doing for years,
and making each kernel tarball extract into a separate directory tree,
and the various utility authors were all to do the same, my earnings
would fall through the floor. As a result, I'm more than happy for
Linus and the other authors to continue with their current practice.
I'd be a fool to be otherwise.

> in particular, lots of people don't give a damn about a few megs
> of never-compiled sources, certainly not enough to ever screw
> around with the costs of potentially inconsistent "factored"
> sources. there is no bandwidth argument either (patches).

Your email address suggests that you're one of the lucky ones to get
free Internet access, in which case your above comment is more than
understandable. It's just a pity it isn't also true.

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.224 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site