On Mon, 21 Dec 2009 20:50:15 -0600 Stan Hoeppner <s...@hardwarefreak.com> wrote:
> Celejar put forth on 12/21/2009 8:22 PM: > > > 1) Faster booting, since irrelevant drivers aren't loaded and won't > > spend time probing. > > Correct. And not just drivers. Prebuilt kernels usually include netfilter > support (for iptables), which increases the size of the kernel substantially, > along with mdraid support, and some other capabilities most desktop users > don't > need. Using a custom kernel allows you to eliminate the need for an initrd, I run desktops / laptops, and I always build netfilter - I run shorewall on all my boxes. > speeds up the boot process by compiling all the drivers your hardware needs > directly into the kernel, and cuts down the kernel's memory footprint. On Hm, I tend to build everything that I possibly can (that I'm building at all, that I plan to actually use) as modules. Perhaps I should try building them into the kernel to see if there's a performance gain, but one reason that I like modules is that it makes for easy resetting of a driver - 'modprobe -r somemodule && modprobe somemodule'. Is there generally a way to do this with built-in modules? > current systems with multiple gigs of ram and large CPU L2/L3 caches, > admittedly, the size of the kernel isn't a big issue for most desktop and > server > class systems these days. It most certainly is critical for embedded > applications, where processors have relatively low performance, with tiny > caches, and small system memories. > > > 2) Security - one of these null pointer dereferences that they keep > > discovering can't hurt you if it's in code that hasn't been included. > > This is a valid point, though others would argue the opposite, that pre > compiled > kernels lacking modules can't easily have the driver code updated with a > security fix, without compiling a new kernel. I personally will take my > chances > with my precompiled kernel. I'm not sure that I understand this - how is it easier to provide a security fix for a standard kernel than for a custom built one? In both cases, one needs to obtain fixed code, build it, and replace the bad code with the good. [I'm not arguing with you, just expressing my confusion.] ... > > 4) Flexibility and control > > Yes and no WRT flexibility. Yes because you an choose exactly what does and > does not go into your kernel. No, because once it's built, if you want to > add a > new hardware device later, you might have to build a new kernel. With the > modular prebuilt kernels, you can plug in just about anything and it'll likely > be recognized. Then again, there's nothing keeping one from building his/her > own kernel and including drivers in anticipation of future needs. The > downside > to this is kernel bloat for hardware you're not using "right now". I > obviously > agree that you have more control doing your own kernel. Agreed, and I get bitten by this all the time. Worse, often I disable some feature that I actually need, and then spend much time and aggravation figuring out why something is suddenly broken ... Well, I guess that's part of the valuable learning process that we discussed earlier :/ Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
