<div class="gmail_quote">Thanks Tim,<br><br><br>On Mon, Jan 23, 2012 at 13:36, Tim Young <span dir="ltr"><<a href="mailto:Tim.Young@lightsys.org">Tim.Young@lightsys.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have done a number of custom kernels.  I usually recommend against it for a number of reasons, unless you really find it will help...<br></blockquote><div><br>That's pretty much the point of my question - what is the compelling reason?  I wasn't really coming up with a very good excuse to build a custom kernel. <br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The default kernel has lots of "modules", each module is the driver for certain sets of hardware.  A custom kernel allows you to have hardware that is not-by-default supported on your release.<br>
<br></blockquote><div>This - along with the security patches, etc. you mentioned - gets more to the heart of what I am after - that compelling reason.  In Windows, you typically just install the vendor's driver, rather than having to build a custom kernel to load that driver.  Even then, I think most drivers can actually be loaded as loadable modules, as opposed to being part of the kernel, no?  I would think that, between SELinux, Xinetd, Apparmor, possibly ACLs, aide, etc., one should generally be in a good position with respect to security (from a software perspective, anyway).<br>
<br>I think if I tried to explain the advantages of building a custom kernel to, say, a Windows user, their response would be to the effect of, "uh-huh.  And your point is?"<br></div></div>