Re: bloat thread

Khimenko Victor (khim@sch57.msk.ru)
Sun, 31 Jan 1999 16:49:37 +0300 (MSK)


In <19990131061729.17120.qmail@defiant.cqc.com> pacman (pacman-kernel@cqc.com) wrote:
> Michael Loftis writes the following:
>>
>>In any event I'm very disappointed. If this is how many of you still are
>>it's no wonder scoop (for freshemat.net) was going to call it quits. This
>>is BS you guys. If you rip on people you don't know, who could possibly
>>HELP YOU LATER then you, and many others will LOSE OUT.

> Don't let a few rude responses discourage you. If you have ideas on how the
> kernel build process can be improved to provied better support for compiling
> on a near-full disk, send in your diff -u.

He does not have plans to do ANYTHING to help in kernel development. He think
that Linux is just pub where you could grab free beer "Linux" for free and
where a lot of peoples will help you for free while you'll not help anyone.

-- cut --
Now I'm remembering why I decided I was going to NEVER EVER develop
anything for the Linux kernel (at least nothing that I'm releasing
publicly... I've done some neat magic w/ MP3 and the SB16 sound card as
well as 'midi-font' technology on same HW), and I think this will stay true
forever.
-- cut --

It's no matter how many years of programming expirience you have. It's no
matter if you are expert or novice in Linux. But stating that you are plan
to use any possible help from Linux community while not contributing back
is best way to get situation when noone will want to help you.

> Here's what I'd like to see:

> + Ability to build from sources located on a readonly NFS mount, so the
> target machine only needs to hold its .o's. Maybe you can already do this
> with a symlink tree. Has anybody tried it? If it worked, then all we'd need
> would be a group of public untarred NFS exported source trees.
> lndir /mnt/nfs.us.kernel.org/pub/linux/v.2./LATEST-untarred/ /usr/src/linux
> cd /usr/src/linux
> cp ~/mysavedconfig /usr/src/linux/.config
> make oldconfig clean dep zImage modules modules_install

> + Some convenient alternative to "make modules_install" which makes sense
> when compiling on a machine other than the target machine. I suggest
> "make modules_tarball" which creates a tarball containing the
> lib/modules/2.2.X/*/*.o directory structure.

> If there was a patch available which could do these in a non-intrusive way,
> the big-disk bigots would at least have to think a little bit harder before
> flaming.

> Of course now the natural question to ask is why *I* am not submitting
> patches :) the answer is that according to Documentation/Changes, I have a
> dozen other things to upgrade before I can even consider 2.2 on my
> "small"-disk machine.

-
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/