[lug] debian

[Peter Hutnick]

David Morris said:
> On Thu, Sep 18, 2003 at 04:39:30PM -0600, Peter Hutnick wrote:
>> David Morris said:
>> > On Thu, Sep 18, 2003 at 02:26:47PM -0600, Peter Hutnick wrote:
> Yes and no.  True, you don't need to load modules, but not
> everything is always compiled as a module.  If it hasn't
> been compiled as a module, the code is *always* loaded....no
> choice about that.  Linux also does not auto-detect and load
> modules (except during probing at installation sometimes, or
> with special toos). RH puts a *lot* of drivers compiled into
> the stock kernel....Debian has fewer compiled in.  I
> frequently compile my own kernel (especially for a laptop)
> and drop out 90% of the stuff in the stock kernels simply
> because I will never need them (a near guarantee on a
> laptop!).

Simply untrue.  As an experiment I did:

   # ls -R -1 | grep .o | grep -v ./ | wc -l
(Note:      ^that's a one                  ^that's a little L.

in /lib/modules/2.4.20-20.9.  It said "957".  I don't know how many
components of the tree they are using are available as modules, but this
is by no means a "kitchen sink" kernel.  To the contrary, it is modular to
the extreme.

The kernel in question is 3.1M.  Granted, that is big, but it is still
negligible (from a performance standpoint) on any system likely to have a
contemporary nVIDA card . . .

If we assume that a minimal kernel is 512k, and you will spot me the .1M
we can say that 2.5M is whopping 2% of the RAM on a 128M system.

> RH does have helper programs to auto-probe hardware and help
> minimize user intervention in the setup process, but they
> still have a larger stock-kernel then I peersonally like on
> my systems.

One of us is missing the point.  I personally like apple pie.  What does
that have to do with the ease of getting relatively new hardware working?

> This all means more memory is used.  If you have a system
> with effectively unlimited reasources (i.e. a new system),
> this means system performance is not effected.  I (and
> *many* people I know) are running Linux on computers that
> qualify as something out of the dark ages in terms of
> computer years.  This isn't a problem (one of the wonderful
> things about linux!), but a bloated kernel *does* effect
> system performance simply because it is huge.

Again, those aren't the systems we are discussing.

>> But even if that were not the case I am skeptical about
>> your claim that a system would run more slowly with
>> extraneous modules loaded anyway.  They wouldn't produce
>> any interrupts and they would consume a negligible amount
>> of memory.
>
> Not only that, a stock kernel is not tuned to your
> hardware....it is usually compiled for the
> lowest-common-denominator.  Used to be all kernels (except
> for Mandrake) were compiled for a 386....this is no longer
> true, and all distros have at least compiled kernels
> 486/586/686/etc. They do not, however, tune performance to
> hardware specifics......for instance, in the 2.4 kernel
> there is an option to check for "Dell Laptops".  You have to
> compile your own kernel for this, but in return you get a
> few added minor features and a tad better performance (if
> I'm recalling the details of the option correctly). Also, if
> you *do* compile drivers into the kernel rather than loading
> them as modules they use less memory.  I could be wrong, but
> I believe in some cases they run faster as well.
>
> You are right though Peter, extra drivers loaded in and of
> themselves don't slow the system down....its other factors
> combined.

You have simultaneously drifted off point and demonstrated that you aren't
very familiar with Red Hat.

You're off point because the idea of a tuned kernel and the idea of
hardware "just working" are diametrically opposed.

Allow me to illuminate you on a few of Red Hat's kernel /binaries/.

ncftp> open ftp.redhat.com
Connecting to 66.187.232.30...
Red Hat FTP server ready. All transfers are logged. (FTP)
Logging in...
Login successful. Have fun.
Sorry, I don't have help.
Logged in to ftp.redhat.com.
ncftp / > cd /pub/redhat/linux/updates/9/en/os/
ncftp .../linux/updates/9/en/os > ls
athlon/  i386/    i586/    i686/    noarch/  SRPMS/
ncftp .../linux/updates/9/en/os > ls athlon/
kernel-2.4.20-18.9.athlon.rpm          kernel-smp-2.4.20-18.9.athlon.rpm
kernel-2.4.20-19.9.athlon.rpm          kernel-smp-2.4.20-19.9.athlon.rpm
kernel-2.4.20-20.9.athlon.rpm          kernel-smp-2.4.20-20.9.athlon.rpm
ncftp .../linux/updates/9/en/os > ls i686/
glibc-2.3.2-27.9.i686.rpm              kernel-bigmem-2.4.20-20.9.i686.rpm
kernel-2.4.20-18.9.i686.rpm            kernel-smp-2.4.20-18.9.i686.rpm
kernel-2.4.20-19.9.i686.rpm            kernel-smp-2.4.20-19.9.i686.rpm
kernel-2.4.20-20.9.i686.rpm            kernel-smp-2.4.20-20.9.i686.rpm
kernel-bigmem-2.4.20-18.9.i686.rpm     nptl-devel-2.3.2-27.9.i686.rpm
kernel-bigmem-2.4.20-19.9.i686.rpm     openssl-0.9.7a-5.i686.rpm

You are, of course, always still welcome to download the source RPM for
the RH patched kernel, or any of the other kernels out there (even
Debian's) and build it locally.

So, I am willing to concede that Debian is superior in millions of
possible circumstances if you will reciprocate by allowing me my opinion
that this ain't one of them.

-Peter

PS: I dub thee "Debianista Supremo" ;-)