Does anyone know why Redhat persists lagging the gcc version in the dark ages? 4.8.5?, For gods sake version 8 is now out!
Does anyone know why Redhat persists lagging the gcc version in the dark ages? 4.8.5? For gods sake version 8 is now out!
It's not like they can use compiling 32bit for an excuse. Makes using it as a compute server a bloody nightmare. I can't find a why behind this anywhere. Debian is at like 6.4 I believe. |
Well, I used to have an issue with this at my last job. Apparently, according to one of my admins, they backport their software so the versions you see aren't really what you think it is. Might appear to be ancient but patched to current levels with their versioning scheme I guess.
|
major versions of software WILL NEVER CHANGE IN A RELEASE OF REDHAT !!!!
the major version in rhel6.0 will BE THE SAME in RHEL 6.9 and the same goes for RHEL 7 for the 10 year life span THEY WILL NOT CHANGE Now all security and bug fixes are backported this is what makes RHEL rock hard stable in all the years of using CentOS/ScientificLinux ( RHEL rebuilds ) i have only had ONE (1) crash and it was 100% MY!!!! fault this is why you have gcc 4.8 as the DEFAULT but you can also install gcc 7 or 8 if you really want and build less stable binaries |
The "why" is that Red Hat's business model is to provide stable and well-tested software to their customers. Therefore, software packages are typically "frozen" at a certain version, with patches "backported" from newer versions. More details here: https://access.redhat.com/security/updates/backporting
|
All times are GMT -5. The time now is 10:17 AM. |