MESSAGE
| DATE | 2008-03-16 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] Re: [nylug-talk] Benefits/drawbacks of building Linux as a package [was: Looking for recommendations on Linux Distro]
|
On Sat, Mar 15, 2008 at 09:49:38PM -0400, Chris Knadle wrote:
> 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.]
>
The configuration issue is with having the both images remain in the boot
director, and for both images configured in grub or lilo. Then there is
the issues with mkinitrd or whatever program you have to do the same step
as well as consistency in the modules.
All of these issues have been vastly improved over the last 5 years, and
yet all of them still remain so NEVER be suprised if when loading a new kernel
with a package manager that you can't actually reboot. The few times a successful
kernel swap has worked for me I've been in near shock. I've got to be feeling
pretty lazy to even attempt it and it has to be a hugely non-criticle device.
Frankly, when I need to upgrade a kernel that is a huge sign that it is time to
upgrade the whole distro.
> > 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.
If you care to go that route, by all means, go for it. It seems just as easy
at that point to just compile the thing and be done with it unless you need to
do a rollout of a thosand other machines. Then I agree with you 100%. You'd had
better make package, preferably one that works like kickstart on a bearwolf cluster.
>
> > 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.
If your compiling from source, does it matter? I've not run into a kernel that
wouldn't compile. I will, however, repeat that the task is getting so arduous
at this point that using preconfigured packages is looking more and more inviting
with every passing month.
>
> 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.
>
The amount of hardware driver for depairent uses makes an obvious dividing line on
a great chunck of stuff at this point. I'd start listing a ton of it if I could
remember what the heck they were since I'd never heard of the stuff before.
But at the next NYLXS installfest, I'd be glad to sit down with you and compile
a kernel with you and we can both likely shake our heads together trying to
figure out what all that stuff is at this point.
The kernel has become like NYC government. Its so bloated by special interests
that you need a degree in electrical engineering and 20+ years of experience to
know what the heck its asking. There was a time I was familiar with every single
hardware that was being discussed in the config, and that wasn't that long ago.
BTW - there is a work around in the config gui force the external modules to
show up, but I'd need to research it to find it again. I believe I stumbled
on it when I downloaded the latest ALSA drivers from the ALSA site and patched
it into the new kernel.
In fact, I think I had to start with a fresh new kernel because it was the requirments
of the new alsa drivers.
Reuvain
"> I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."
© Copyright for the Digital Millennium
|
|
