3 ms·
The problem with that is that I'd argue it is "safer" to run a kernel.org stable kernel rather than RHEL, since it's sheer impossible to keep up with the amount
by burb_xry 8y ago
The problem with that is that I'd argue it is "safer" to run a kernel.org stable kernel rather than RHEL, since it's sheer impossible to keep up with the amount of fixes that eventually land in stable kernels every few weeks. And it is unclear which of the stable fixes are security relevant ones even if they did not get a CVE number and the like. QAing all these is another mammoth task that often requires expertise in several areas. I'm actually glad that (upstream) Linux doesn't have a stable kernel ABI, if you've ever looked into what gross hacks are required in the RHEL kernel only to keep that intact, well, good luck.
- kjeetgill 8y agoThat's not the choice customers have. The parent gave examples for why companies often need predictability and stable ABIs. They're choosing between no kernel upgrades and RHEL's. What good is a fresh kernel if a binary driver you need but can't change breaks?
- techntoke 8y agoRight.. it's like they haven't managed to automate a CI pipeline to handle these changes for them. Other distros do it just fine, and I've had far more things break in CentOS or Red Hat than Arch.
- slrz 8y agoThat CI pipeline would need to be placed not at Red Hat but at their big customers and their hardware vendors. To RH's benefit, those tend to suck at that and prefer to pay big dollars over having to keep up with kernel development or getting rid of their crappy out-of-tree drivers. If you have the appropriate CI pipelines as well as the kind of developers capable of directly consuming the upstream community outputs, by all means, do that. Many companies aren't like that though and prefer talking to tech support people over diving into the source code themselves. I guess we should just be happy about the fact that they fund Linux development at Red Hat.