> A common misconception about the Linux kernel is that it's secure, or that users can go a long time without worrying about security updates. Neither of these are even remotely true. New versions of Linux are released almost every week, often containing important security fixes among the other changes. These releases typically don't make explicit mention of which commits have security implications. As a result, many "stable" or "LTS" distributions don't know which commits should be backported to their old kernels, or even that something needs backporting at all. If the problem has a CVE assigned to it, maybe your distribution will pick it up. Maybe not. Even if a CVE exists, at least in the case of Ubuntu and Debian especially, users are often left with kernels full of known holes for months at a time. Red Hat and similar "enterprise" distros have the same problem and have been called out publicly about it on more than one occasion. Moreover, the Linux kernel security team doesn't request CVEs for any vulnerabilities, partly because there are just too many to track. Downstream's culture of trying to cherrypick security fixes in the name of stability does not work. Arch doesn't play the backporting game, instead opting to provide the newest stable kernels shortly after their upstream release.
[1]: https://vez.mrsk.me/linux-hardening.html (lots of linked sources in the actual paragraph there)
When even the creator of the Linux kernel has a very lax approach to security, and so the culture of Linux is the same way - I consider it an issue.
This is one of the nice things about arch I guess. Super simple to run mainline.
That, and updates are just a constant stream - there is always a new package to update every single day.
And as a separate issue, but the quality of software has taken a sharp decline lately as we all start switching to flatpaks and snaps (a correlation, not causative). More and more software is Electron-based and the quality of the non-Electron based software has more or less tanked.
Not many hobby programmers are making desktop software anymore.
That depends entirely on how well your state serializes to disk and restores. If nothing else, I occasionally make the mistake of getting a setup going that would just be a pain to recreate in terms of getting everything open again (too many windows open in a specific arrangement).
https://madaidans-insecurities.github.io/guides/linux-harden...
My only complaint is that I wished it went back 2 LTS releases. For example, the current project I'm working on settled on 20.04 and there are no more new hwe kernels being released for it despite the rest of the userland receiving updates.
We went with the latter because our minimal attack surface made it unlikely that we'd need to backport many fixes, but it was always looming.
As far as I can tell IBM officially nuked CentOS long term support in the same step it killed Red Hat compatibility with 7 being the last supported version.
The replacement for CentOS seems to be Rockit Linux, which continues with tracking Red Hat packages like CentOS did in the past.
Scientific Linux is no longer a thing, essentially; from wikipedia:
> In April 2019, it was announced that feature development for Scientific Linux would be discontinued, but that maintenance will continue to be provided for the 6.x and 7.x releases through the end of their life cycles. Fermilab and CERN will utilize CentOS Stream[4] and AlmaLinux[5] for their deployment of 8.x release instead.
Not quite. Back in 2003, when folks were first coming up with the idea of creating a distro that matched RHEL as closely as possible, Greg Kurtzer (the Rocky founder) explicitly stated that he would be interested in helping host it, but that he was "totally not interested" in leading it.
https://web.archive.org/web/20040909231336/http://www.caosit...
It wasn't until much later (~2019) that he started trying to retcon history by claiming he was the original CentOS founder.
CentOS Stream is just as "LTS" as Debian, Ubuntu, or OpenSUSE - supported for 5 years. This is admittedly not as generous as the 10 years CentOS provided previously (and what Alma / Rocky linux have promised to provide), but it's definitely still "long term" by the same definition everyone else uses.
And while CentOS Stream {8,9} does trend slightly ahead of RHEL {8,9} respectively in terms of bugfixes and features, it still maintains equivalent ABI with RHEL {8,9} and is compatible, though not precisely "bug-for-bug" compatible, which even CentOS / Alma / Rocky have never quite accomplished.
disclosure: I work for Red Hat
Oracle Linux 7 is guaranteed binary compatible with RHEL/CentOS 7, although there is only (a little over) a year of support left on the whole platform.
Scientific Linux was also on v7, but I thought there was some kind of ongoing apoptosis with this repackaged distro.
Neither Alma nor Rocky implemented v7. I thought that CentOS left that version untouched.
I wonder if the Oracle UEK has addressed these problems. If so, it would be a reason to run Oracle's kernel on CentOS, supported or not.
For those poeple who can tolerate neither these bugs nor Oracle's kernel, another option is ElRepo's "Kernel of Last Resort."
"We stress that we consider such kernels as a last resort..."
Rhel7 is running a v3 kernel; the UEK will have a lot less to do.
I will admit that they are with a few point releases on rhel9.
How many people maintain elrepo-ml?