How To Compile A Kernel - Debian Etch

Recently, a Debian kernel maintainer' decision has made compiling my own kernel a priority again, after 6 years of not compiling a kernel, and not once on Debian in 12 years of use:

The Nvidia kernel module is not GPL; The "paravirtualization" kernel API is tagged as "GPL Only" inside the kernel; Debian has "paravirtualizaiton" turned on in the precompiled kernels; The Nvidia kernel module, for whatever reason, accesses that API;

Therefore, the Nvidia kernel module will not compile with Debian binary kernels >=2.6.20.

So here is a perfect example as to why someone would want to compile their own kernel, even if it is solely for the purpose of turning off one single option.

But seeing kernel compile HowTos is scary to business types that just want it to work. It feeds the FUD that one must be technically astute just to run a Linux based system, which secretaries and corporate executives simply do not need to be. Nor do they _want_ to be. They have work to do, and a system that gets in their way is not satisfactory.

...which is why theraputic reboots of Windows machines, not to mention random hangs, surprise reboots and data loss, are all excellent reasons for such people to get off of Windows ASAP and onto a system that "just works".

Bob -

And -- the process, from source acquisition to install and bootloader setup, is a little different for different distros, at least if you are trying to fit into that distros scheme.

There is another solution, which I took about 7 years ago when Debian was all goofy over KDE -- switch distros.

Debian is the wrong distro to use with anything "impure" anyway. Their politics will always leave you at risk of needing sleight-of-hand to keep your machines running smoothly.

The other alternative, of course, is to ask whether you really need to use the non-free bits. A back-room server, for example, certainly doesn't need the nvidia driver.

Just stick at kernel 2.6.19 until the Nvidia module has been rewritten to avoid those GPL APIs.

Not a back-room server. Personal laptops.

And the reason for going to 2.6.21 is for the updated and working bcm43xx driver, which does not compile on 2.6.18.

So by not compiling my own kernel, I had a choice of wireless or video working, but not both. I choose both.

My real point is that while kernel compiling really isn't all that difficult (mere requiring attention to details), the very thought of it makes those who don't already understand what a "distribution" is uncomfortable.

I've been compiling the nvidia driver since 2003 for my machine, it's no big deal to do it for the other laptop. In fact, the Nvidia source from Nvidia worked exceptionally well. Save for the "paravirtualization" API, it installed itself just as easily and effectively as any Windows device driver install.

I don't like that my car runs better on mid-grade gas either, but for the same reason I don't use the libre "nv" driver, I don't run low-grade gas in my car. I _prefer_ how the machine works with that little bit of effort on my part.

Actually, NVIDIA's module doesn't include the paravirtualization module, but is implicitly included. They removed the GPL only bit on 2.6.22, so when that comes out, it'll work just fine again.

I'm actually still at 2.6.18, because nvidia does work, and I don't have a broadcom wireless card.

What's the difference in the bcm43xx driver in 2.6.21? I recently updated my laptop (gentoo of course) to 2.6.20 recently and the bcm43xx driver there seems to work fine as far as I can tell (once I got the proper firmware for the silly thing).

The firmware does seem to be the "big" difference, but as far as I can tell from the searching results trying to get the card working, the driver in 2.6.18 was, to quote the most often used phrase, "worthless".

I will be very happy to be able to use the stock kernel again in 2.6.22. Thanks for the heads-up.

As for Debian's politics, I like them. It "keeps people honest", even if things are a bit inconvenient at times. Certainly I would do things differently were I King, for instance I would make non-free and contrib much easier to get packages into.

But I'm not King, something I'm sure several people are very happy about.

Yeah, I had to use the external driver until I updated to 2.6.20. I was quite happy that the internal one works there. 2 out of the 3 wireless cards I have are using in-kernel drivers now. Internal bcm43xx and USB Zyxel AG-225H (zd1211 driver). Still have to use the external module for my Zonet ZEW2500P (rt2570 driver - not real stable, but works now and then).

FWIW, all of them work with Kismet. :) The zd1211 driver has some bugs and tends to generate junk data (i.e. you "find" lots of things that aren't really there)

I do kinda wish gentoo had policies to make it easier to be as pure as one wants easily. It would be nice if non-free packages were clearly marked somehow (maybe a non-free use flag on them or some such).

I'm reading this whole thread as a lot of practical reasons against closed proprietary junk in the kernel. As opposed to characterizing the wish for open, Free drivers as "idealistic" or "purist."

>as a lot of practical reasons against closed proprietary junk in the kernel.

Or, as a practical reason not to pin your computing on the work of a collective of idealistic whackos.

"Or, as a practical reason not to pin your computing on the work of a collective of idealistic whackos."

He thought you'd follow old Obi Wan on some damn-fool idealistic crusade, like your father did.

But then I'm an anarchist. I think voluntary collectives are just fine.