Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One of the main reasons we use CoreOS is that it ships stable and state of the art features from the latest Linux kernels, so features and infrastructure like eBPF are available and can be used without problems. RHEL kernels (e.g. speaking of RHEL7) on the other hand are ancient and heavily outdated, and only backport some of the newer features from upstream kernels, so user space making use of it cannot be run anymore preventing latest innovation (or killing Linux kernel innovation through supporting bypasses like DPDK).

Oracle's RHEL clone on the other hand ship their UEK kernel which is a recent, commercially supported kernel based on (almost) latest upstream. There, the situation is at least better than with native RHEL, but I truly hope Red Hat has an answer to that with brand new Linux kernel's on RH CoreOS side. Please don't let innovation coming from the kernel die by dictating ancient RHEL kernels to majority of users. CoreOS enables innovation, please make sure it continues to do so.

By the way, there was a good summary on this point with regards to RHEL kernel considered harmful here: https://medium.com/@sargun/red-hat-enterprise-linux-consider...



I totally agree with your points, especially with awesome projects like Cilium[0] solving real problems in the Kubernetes ecosystem and, you know, getting updates to the kernel primitives that actually isolate containers. RH CoreOS is not going have a kernel that is synchronized with the RHEL release cycle. We're working to find out what types of requirements for certifications that we want to support and, using that as a guideline, we'll be shipping the freshest possible kernel. The nice thing about supporting both RHEL and CoreOS as the OS for OpenShift is that customers that require government-tier certifications will be told to use RHEL and everyone else can enjoy CoreOS.

We also now have access to the vast kernel engineering resources at Red Hat, so CoreOS should be able to get emergency fixes like those for Spectre and Meltdown out to customers much more quickly.

[0]: https://github.com/cilium/cilium


This is really awesome to hear, thanks a lot jzelinskie! Keep up the good work!


RHEL is an LTS distro. Red Hat also develops Fedora as a bleeding edge distro, and there is plenty of innovation going on there.

https://getfedora.org/


I switched from Ubuntu to Fedora on my development machines and it has been amazing.

Stability is superb and a lot of the niggles I had with Ubuntu just went away.

Fedora Cinnamon is damn close to perfect as a development desktop for my needs. I literally can't think of anything I'd improve outside of its multi-monitor support (it's fine with fixed monitors but plugging my 4K on displayport on the ThinkPad requires some finessing but so did windows).


You are missing the point. It's not at all about Fedora itself here. What I was trying to say is that today CoreOS (even in) stable is using Linux kernel 4.14.32 (https://coreos.com/releases/) and therefore enabling deployments to use the latest and greatest features, performance optimisations and innovation from the Linux kernel community in enterprise environments. Going back to RHEL kernel would be a major step backwards preventing a wide user base from access to what CoreOS enables them to do today. I genuinely hope that CoreOS folks at RH don't give up on continuing to deliver this sort of innovation. That is all what I was trying to get across.


We really try to avoid being a "bleeding edge" distro, and prefer to focus on leading edge. We don't always do every thing absolutely before anyone else; we try to be the first to provide integrated, tested, usable versions of innovative open source.


Upgrading the Linux kernel opens a huge can of worms. Driver regressions happen all the time. The only things I think are worth backporting in an enterprise kernel are hardware enablement changes and security fixes. If a customer wants to use to a LTS kernel they can compile it by themselves. There is nothing stopping a customer that wants a new kernel from compiling it, and running it on RHEL. Red Hat has to pick their battles, I imagine a very small amount of users care about this for workstations or servers.


This is where we'd love to have your community input on Fedora/CentOS versions. Fedora Atomic Host has had very recent kernels available, and I don't see why that wouldn't continue with the Fedora version of the new OS.




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

Search: