[nylug-talk] Benefits/drawbacks of building Linux as a package [was: Looking for recommendations on Linux Distro]

[Chris Knadle]

On Saturday 15 March 2008, Ruben Safir wrote:
> Reinstalling the kernal from a packagemanager doesn't allow for both
> kernels to be exected through grub incase something goes wrong.

   I'm assuming you're talking about the 'savedefault' option.  
The 'update-grub' program uses what look like comments as options for itself, 
which is why the menu.lst file contains lines that are commented and others 
that are *double* commented.  So if you change:
    # savedefault=false

           to:

    # savedefault=true

then when a new kernel is added to the list by update-grub, *all* of the 
kernel entries will have 'savedefault' after them, which is I believe what 
you're looking for.  So I believe this particular thing is a configuration 
issue rather than a package management issue.  [Please correct me if I'm 
wrong on this.]

> In addition, the boot image is likely different in different distros and
> RPM's et al are frankly very bad at setting that up, not to mention the
> hell of module incongruencies, especially if you need new modules
> installed for updated hardware, which is the most common reason for
> installing a new kernel.
>
> Package managers by and large, actually all of them, suck in the first
> place. Your checklist is wishful thinking.  And I'm not talking out of my
> hat.  I'm talking from a SUSE 5.3 distro running on a P2 right now which
> has been continually patched by hand for a LOT of years now.
 
   Just to make sure we're on the same page: when I speak about installing 
kernels via package management, I mean *configuring and compiling your own* 
and having the build system automatically make it into a package for you.  
I.E. *NOT* using PRE-packaged kernels.

> The single biggest mistake someone can make aside from a dread aweful
> rm command in jest is to install the Kernel from anything but an
> authenticed source from kernel.org.

   And the .deb kernel packages I make are compiled from the git kernel source 
at kernel.org -- and if that isn't authenticated, I don't know what is.
You *DO NOT* have to use the packaged sources from the distro if you don't 
want to.  Personally I don't.

   However in the case of Ubuntu supporting AppArmor from vanilla kernel 
source isn't completely straightforward if you also want to build the 
external modules (nvidia-kernel-source, kqemu-source, squashfs-source, etc) 
from the Ubuntu sources.  This is because Ubutnu is using 2.6.22, the 
external modules won't compile when I use 2.6.24, and I haven't been able to 
find an AppArmor patchset that applies cleanly to the vanilla 2.6.22 sources 
from kernel.org.  There's a nice quilt AppArmor patchset for 2.6.24, though.
   Another thing I'm not thrilled about is that the 2.6.22 source from the 
Ubuntu package doesn't have certain kconfig options for config options that 
they're using; so for instance if you 'make xconfig', you can see certain 
config options drop out and thus not show up in the config menu.  :-/  So as 
a result I'm not terribly happy with how to support Gutsy Gibbon with vanilla 
source, and not happy with the packaged source, either.  Bleh.

   So as big as the kernel is (and I totally agree, at about 310 MB of text 
the kernel is huge), supporting external driver sources is frankly worse, 
IMHO.

> The only catch is that the Kernel itself has become so dreadfully large
> that this is becoming increasingly strenous.  When I compiled the new alsa
> modules with the new kernel a few months back it was almost 6 hours of
> clicking through pointless options.  I've come to believe that the main
> source tree needs to be forked at this point for at least three levels of
> usage, the workstation, server and big iron usages.

   Similar threads show up on LKML [the Linux Kernel Mailing List] along these 
lines, later to be corrected.  And if you could, what could you remove?  You 
can't remove video drivers, some servers might even run 3D X.  Sometimes 
Desktops are used also as Servers, and vice-versa.  I.E. There's no good way 
to split it up into separate branches that I can think of.


   Thanks for your thoughts.

   -- Chris

-- 

Chris Knadle
Chris.Knadle at coredump.us