Re: [gentoo-hardened] kernel no longer in hardened-development overlay?

[Ed W]

>> I realise everyone has different needs, but perhaps try pulling your own
>> kernel down and applying your own patches - I think it's about easier to
>> maintain in most cases?
>
> * The ebuilds for e.g. hardened-sources do all the patching for you,
>   which is nice.

Hmm, it's a very weak one, but yes ok.

> * The fact that the kernel shows up in emerge output reminds me to
>   compile a new one.

OK, big thumbs up.  Yes this is a very good reason.

> * If a kernel is marked stable in Portage, it means that test dummies
>   have been running it for a while and they survived. It also means
>   no bugs were reported regarding integration with other in-tree
>   packages.

Actually, I'm just not buying this... The size of the coverage seems 
very small compared with the much larger coverage which simply fixes the 
problem and pushes the fix upstream?

I haven't done the research, but my gut feel would be that the latest 
iteration of your chosen kernel version would be competitive with 
someone of less than Redhat size trying to backport fixes into your much 
older kernel version?  I guess it's possible, but for the time being I 
tend to vote for newer kernel vs gentoo patched older kernel...

> * Other packages in portage can require certain (versions of) kernels.
>   If you compile your own, Portage doesn't know about it.

Not buying this one either... I haven't seen this working on the small 
number of systems I have and where it looks like it's supposed to be 
working it doesn't quite seem to be working as you would like it to.  eg 
udev seems to look at running kernel version (and can't parse my 
hardened version so it keeps telling me it's too old... It also seemed 
to upgrade happily in a way which it then expected to break my 
system!!).  Nvidia seems to use a mismash, but apparently guesses 
something and falls back to the tree in /usr/src/linux and usually 
simply dies horribly if the tree isn't as it expects.  Lirc has 
literally just failed to compile for me on a certain kernel version 
requiring me to downgrade to 2.6.32 on the machine I need lirc on.

I get the theory, but I'm not seeing this one work in practice.


So basically I would agree with:

- Easier for non hackers to do the patching
- Good reminder that your kernel is out of date.

I guess I concede the ebuilds are useful, but I would kind of expect 
most people on this list to be well within the capability to build their 
own kernel, so I would still recommend anyone who has avoided doing so 
to give it a whirl first hand?

Good luck

Ed W