CentOS 8.x Navy Linux

Navy Linux will release its Navy Linux release on 01-07-2021.
Navy Linux will be rpm compatible with Red Hat Enterprise Linux.

A nice add-on is that they start their own EPEL named SELR: Stable Enterprise Linux Repository.

This is the fourth release to fill the CentOS 8 gap, as CentOS Linux 8 ends in December 2021. Always good to see more options being added.

---

 

I don't think so. Compiling software with a newer GCC may give new, specific GCC10 based bugs, errors, compatibility or other GCC related problems. As Red Hat compiles its own software using the default 8 GCC. There is no knowlage base for GCC 10. So in case of problems who or what do you consult?

It is unlikely that a small team like Navy is going to repackage thousands of packages with a newer GCC.

In addition, it could also be that Navy Linux is no longer 100% compatible with RHEL.
Therefore it is also highly unlikely that they would try this.

I think the GCC 10 is in git to make it faster to repackage, or semi automate this task. I won't be surprised if they add the GCC 8 and 9 branch later.

 

The default EL8 gcc 8 is at the Navy's git now, as expected.

Packaging / gcc · GitLab

 

I don't think Navy will release Navy Linux on July 1.
No activity on their git for ages.

 

Navy Linux Release 8.4 Beta released.

Respect for the small team to rebuild a large distro.
It seems so easy. But it is secretly a lot of work.

 

Navy Linux stable release date in all likelihood, will be August 1st 2021

 

Navy Linux 8.4 Now Available!
Good to see that there is plenty of replacement for CentOS.

 

Yup plus extra kudos for Navy Linux Selr if you need extra packages, for example the latest Samba without Red Hat restrictions.

And if you want the latest, stable Fedora Linux kernel on EL, Navy Linux also got that feature covered.

 

KernelCare focuses on the supported stable distro kernel so I don't think that's a problem about eating into its own product. It also targets customers running the stable kernel.

Apart from that, I'm not such a fan of KernelCare or related products.

Why do you want to run none or 0-day tested 0 day code on Kernel, Glibc & OpenSSL in an enterprise system?

As can be read on the website, KernelCare focuses on: "large enterprise Linux infrastructures".

With a large infrastructure, everything runs redundantly or perhaps even more.
Then there is absolutely no reason to run these kinds of tools.

Because of the redundancy, you can easily pull out some systems or even cages full of systems to update (hardware and software) with official hardware and updates. Without downtime of the service that you are running.

 

Of course.
Why would you want to run a 5.x (Fedora) kernel on an Enterprise system anyway?

It is not hardware certified, not supported. So in debugging. For example, in case of problems. You are on your own.