4 ms·
If you're interested in async I/O, keep an eye on the io_uring changes.
by mehrdadn 6y ago
If you're interested in async I/O, keep an eye on the io_uring changes.
- jeffbee 6y agoEasily 5-10 years before most of us can expect to use that in a work context.
- mehrdadn 6y agoI assume you mean because of the time it'll take to trickle down to production kernels? Does that take 5-10 years?
- jeffbee 6y agoWell, when I quit the place we both worked, the production kernel was 3 years behind and rolling forward at .5 years/year, so that implies 6 years to get current. The next company I joined is using RHEL's 2.6.32 in production, more than 10 years after its release.
- geofft 6y agoHave you asked whether you're able to use newer kernels, at least on your subset of hosts? I've been having pretty good luck at work just asking for kernel updates - though it helps that I'm willing to stare at oopses and kcore dumps and userspace regressions (they happen!) on the canary machines.
- jeffbee 6y agoI see you don't have FIPS 140-2 certification.
- geofft 6y agoAh, yes, but all software is 10 years old and full of exploitable security holes and weak algorithms if you're constrained to FIPS, so the kernel isn't a special case :)
- jeffbee 6y agoOnly if your organization submits to the stupidity of the FIPS 140-2 consultant scam. Google has this level of certification and they obviously aren't using vendor kernels (or vendor anything). At Google the production kernel was, in many ways, newer than the one you could download from kernel.org
- tssva 6y agoyou state that "Google has this level of certification" as if it is a certification which applies to organizations. It does not. Specific hardware and software cryptographic modules are given FIPS 140-2 certification. Google currently has 8 cryptographic modules which have active FIPS 140-2 certifications. 5 hardware and 3 software. The software modules are all versions of BoringSSL. Google can replace their kernel as they wish because they don't use the cryptographic api's in the kernel for anything which requires the use of a FIPS140-2 cryptographic module. Not everyone is in that position or they use a commercial Linux OS in which the non-kernel certified cryptographic module provided is available on only certain releases. If they want support for their OS they must therefore use the kernel provided with that release of the OS.
- jeffbee 6y agoThanks for expanding on my simplistic remark. Have you considered offering your services as a FIPS consultant? Because my ex-Google experience with this aspect of the industry is that management hires a consulting firm who come in and says things like everyone must use this RHEL kernel, this (incredibly broken) openssl and so forth. Those consultants are not offering the nuanced perspective to the management, who aren't technical enough to understand it anyway. So the word comes down from the top that we're married to kernel 4.15 until the end of days.
- mschuster91 6y ago> The next company I joined is using RHEL's 2.6.32 in production, more than 10 years after its release. This one is frighteningly common in embedded stuff.
- gizmo686 6y agoIt depends on your domain. RHEL7 has another year[0] of support left (until August 30, 2021), and is based on kernel 3.10 [1], which was released in 2013 [2] RHEL 8 is expected to see support through 2029, and is based on kernel 4.18, which was released in 2018. Redhat does backport changes, but tends to avoid backporting feature changes. If you want to be able to use "recent" features of software, you are probably not running running Redhat But, many companies prefer the stability of systems that have been battle tested, and so are perpetually years behind the bleeding edge in terms of features. [0] https://access.redhat.com/support/policy/updates/errata/ https://access.redhat.com/support/policy/updates/errata/ [1] https://www.redhat.com/en/blog/what-latest-kernel-release-my-version-red-hat-enterprise-linux https://www.redhat.com/en/blog/what-latest-kernel-release-my... [2] https://kernelnewbies.org/LinuxVersions https://kernelnewbies.org/LinuxVersions
- wwright 6y agoI don’t mean to start an off-topic debate on this, but I just have to say that personally, I run into issues caused by using old software on our EL7 boxes all the time. For example, cgroup memory limits are broken on Red Hat 7 kernels as far as I can tell (most versions have a memory leak, but iirc the most recent has a panic instead). They’re missing all sorts of features that are useful for usability or reliability. I’m just personally not convinced we really win much with the trade off as a society :p
- jeffbee 6y agoMemory control group code is replete with bugs throughout 4.x kernels, way beyond RHEL 7. This is one of the big problems with getting locked into "LTS" kernels. It takes a long time to discover all the nameplate features that don't actually work.
- mlindner 6y agoAre there any "RHEL considered harmful" posts? That project is one of the most damaging things for the Linux ecosystem IMO. It forces companies on to ancient outdated compilers and library versions that are full of bugs.
- hvis 6y agoCould some of us use it in leisure context earlier?
- KMag 6y agoYou can use it right now as long as you're using Linux 5.1 or later. It's going to be a bit before these kernels work their way through enterprise deployment schedules, and longer before io_uring is widely deployed enough that more conservative places are comfortable using io_uring in production.
- xenonite 6y agosee also: https://news.ycombinator.com/item?id=22794396 https://news.ycombinator.com/item?id=22794396