5 ms·
"CentOS helped establish and maintain RHEL as the defacto standard" Not exactly. Maintain, perhaps, but Red Hat Linux was the standard before RHEL existed and
by jzb 3y ago
"CentOS helped establish and maintain RHEL as the defacto standard"
Not exactly. Maintain, perhaps, but Red Hat Linux was the standard before RHEL existed and everybody wanted a clone of Red Hat AS/RHEL to continue enjoying the free ride.
Let's also not forget that CentOS had a rocky (no pun intended) few years before Red Hat stepped in later on. A lot of folks gloss over the fact that there were periods of disarray with CentOS that involved some long gaps between updates, a whole kerfuffle about a founder disappearing and the domain ownership being in question...
CentOS, as a project independent of Red Hat, existed for about 10 years. This included several long periods of slow updates to minor versions and long waits for major versions of RHEL. (e.g. it took almost 3 months for CentOS to push out 5.6 after RHEL 5.6, and even longer to get CentOS 6 out of RHEL 6).
Before Red Hat took over CentOS a chief point of criticism was that CentOS took too long to update and the core group wouldn't let new folks in to contribute. (See: https://lwn.net/Articles/435744/ https://lwn.net/Articles/435744/ and https://web.archive.org/web/20190402181426/http://www.linux-mag.com/id/8608/ https://web.archive.org/web/20190402181426/http://www.linux-...)
Now, users have Stream which is pretty much everything you'd have wanted except the ability to claim that it's exactly specific RHEL release. In my book a major improvement, unless what I want is the ability to get support for RHEL from vendors without actually paying for RHEL.
- ndiddy 3y agoA CentOS Stream release only gets updates as long as its equivalent RHEL release is in its "full support" period. In practice, this means that the support duration is cut from 10 years to 5 years. Additionally, CentOS Stream updates often lag behind RHEL updates. This is because Red Hat won't commit an embargoed security update to CentOS Stream until after it ships in RHEL, so the developers responsible for the update will sometimes forget to commit it to CentOS Stream until a week or two after it's shipped. You end up in a weird position where you get most updates faster than RHEL users, but you often have to wait to get critical security updates. I would be wary about using a system like this in production.
- vetinari 3y ago> forget to commit it to CentOS Stream until a week or two after it's shipped. Or months, even. See httpd and php right now, and the CVEs solved this year. CentOS Stream doesn't have it, Alma has.
- bonzini 3y agoCentOS Stream is on a different httpd patch release, it gets the fixes from upstream instead of backporting them. If you have a specific CVE number that you're thinking about, I can check the status internally.
- vetinari 3y agoCentOS Stream 8 is on: * httpd-2.4.37-54.module_el8.8.0+1256+e1598b50 (released 2022-12-08) * php-7.4.30-1.module_el8.7.0+1190+d11b935a (2022-08-04) Almalinux 8 is on: * httpd-2.4.37-56.module_el8.8.0+3560+c8e5e57e.6 (released 2023-04-27) * php-7.4.33-1.module_el8.8.0+3477+f828cbb0 (2023-01-13) So meanwhile, for httpd the following was released: * 2.4.37-56.6 - Resolves: #2190133 - mod_rewrite regression with CVE-2023-25690 * 2.4.37-56.4 - Resolves: #2177748 - CVE-2023-25690 httpd:2.4/httpd: HTTP request splitting with mod_rewrite and mod_proxy * 2.4.37-56 - Resolves: #2162499 - CVE-2006-20001 httpd: mod_dav: out-of-bounds read/write of zero byte; #2162485 - CVE-2022-37436 httpd: mod_proxy: HTTP response splitting; #2162509 - CVE-2022-36760 httpd: mod_proxy_ajp: Possible request smuggling * 2.4.37-55 - Resolves: #2155961 - prevent sscg creating /dhparams.pem For php: * 7.4.33-1 - rebase to 7.4.33, fix: due to an integer overflow PDO::quote() may return unquoted string There are already issues filled in bugzilla: * https://bugzilla.redhat.com/show_bug.cgi?id=2217408 https://bugzilla.redhat.com/show_bug.cgi?id=2217408 * https://bugzilla.redhat.com/show_bug.cgi?id=2217409 https://bugzilla.redhat.com/show_bug.cgi?id=2217409
- bonzini 3y agoThanks, I've forwarded this. _EDIT_: looks like it's not intentional, there are bugs that got to MODIFIED state despite the updates having not been pushed, and then got stuck there.