Better packaging for older hardware?

Michael K. Johnson johnsonm at redhat.com
Sat Oct 18 14:05:41 UTC 2003


On Sat, Oct 18, 2003 at 01:36:48PM +0200, M. Fioretti wrote:
> On Sat, Oct 18, 2003 05:51:05 at 05:51:05AM -0400, Alan Cox (alan at redhat.com) wrote:
> > 386/486 kernel RPMs make sense but you probably also want to think
> > about that as a seperate kernel with less options selected and
> > without the more high end tuning Red Hat has.
> 
> Absolutely. The problem is that we realize this would be a very good
> thing, but, almost by definition, have not enough expertise,
> bandwidth, and CPU power to investigate all the possible
> alternatives.
> 
> Please have a look to the archives of the Linux Kernel Mailing List:
> less than a week ago I started a thread there, called "unbloating the
> kernel". I almost explicitly say there that few things would make me
> happier (software wise, of course) if some real kernel hacker spends
> some day explaining to us how to tweak for RULE scenarios the
> *official* SRPMs of Red Hat, soon Fedora kernels.
> 
> We can walk (almost) alone after that, just need a very good initial
> push in the right direction. Right .config, proper /proc settings,
> whatever.

It wouldn't be hard for us to provide an appropriately trimmed
config file in the kernel srpm, automatically maintained to follow
generic changes to the config files but with specific slimming
changing, even if we didn't build that kernel by default.  It
might break without our noticing in that case, but then that could
always be fixed...

However, the only "slimming" bits we have expertise of any sort in
is summed up in the BOOT kernel config file, so we'd need a pretty
good idea of what kinds of changes we were going to make that would
really satisfy most everyone...  That's the real hard part.

michaelkjohnson

 "He that composes himself is wiser than he that composes a book."
 Linux Application Development                     -- Ben Franklin
 http://people.redhat.com/johnsonm/lad/





More information about the fedora-devel-list mailing list