Hacker News new | past | comments | ask | show | jobs | submit login

It's RedHat's 2.6.32 kernel, which is not the vanilla Linux 2.6.32 kernel. It's been getting backported fixes since the tree began. RedHat does not release what patches they include in their kernels, but luckily for us, Oracle maintains a project called RedPatch which publicly documents the patches going into the RHEL kernels.

As an example of how this kernel is not the 2.6 tree: On April 14, 2014, in RedHat's 2.6.32-431.23.3.el6 kernel tree [1] , there was recently a patch included [2] that affects the ipv4 subsystem. You can find that same patch [3] was originally applied to the Linux kernel on April 14, 2014. This is common practice, and so RedHat kernels more closely resemble modern kernels like 3.12 than anything else.

[1] https://oss.oracle.com/git/?p=redpatch.git;a=shortlog;h=rhel... [2] https://oss.oracle.com/git/?p=redpatch.git;a=commitdiff;h=c0... [3] http://www.serverphorums.com/read.php?12,912195




    RedHat does not release what patches they include in their kernels
Stupid question here: aren't kernel patches considered derivative works? If so, then isn't RedHat legally obligated to released them under GPL?


They provide the complete source, as required by the GPL. However, they do not provide patch sets neatly broken out like they used to; that's what the parent is referring to.


The patched source is there for others to rebuild (e.g. CentOS and other RHEL derivatives), just not separated out into nice patches.


I understand that, but my point is that the only way to make this project succeed (out of your business of course) is to push to upstream (LKML).

Stick with 2.6 and backported patches are not near of newer kernels distributed as part of RHEL 7 (3.10.x).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: