4 ms·
> Just because upstream doesn't have it doesn't mean you couldn't compile it yourself True, but if you are managing production machines, compiling kernels for
by ams6110 8y ago
> Just because upstream doesn't have it doesn't mean you couldn't compile it yourself
True, but if you are managing production machines, compiling kernels for every errata and security update is pretty low on the list of things you get enthusiastic about. Also a lot of commercial or scientific linux software is only "certified" and supported on stock RHEL kernels.
- cozzyd 8y agoThere's always http://elrepo.org/tiki/kernel-ml http://elrepo.org/tiki/kernel-ml (and also kernel-lt) so you don't have to compile things yourself. But things like VMWare and various proprietary device drivers will break.
- geofft 8y agoOn the other hand, if you're making or losing money on latency (e.g., you're a high-frequency trader), compiling kernels for every potential performance improvement is a thing you're enthusiastic about, a lot of security fixes (local privilege escalations, drivers for desktop hardware, etc.) don't apply to you, and you don't care about things being "certified" because you have the expertise to fix problems in-house as necessary. And from the other direction, if you're making or losing money on security, expecting distro kernels to turn around security fixes in a timely manner seems like a mistake. At least know how to rebuild your distro kernel with a local patch.
- rb2k_ 8y agoThe amount of filesystem/networking issues I've seen fixed and all the performance improvements I got from just updating a kernel probably make up for the time that it caused issues. I guess it needs a critical mass + certain infrastructure maturity that running on whatever the latest kernel is makes sense. As for the 'certified on stock RHEL kernel' software... I try to keep away from those, but I'm picky and pretty lucky when it comes to job selection :)