5 ms·

> That pretty much sounds like freeloading to me. I'll bite. The value in RHEL was supposed to be in the support. CentOS helped establish and maintain RHEL as

> That pretty much sounds like freeloading to me. I'll bite. The value in RHEL was supposed to be in the support. CentOS helped establish and maintain RHEL as the defacto standard that everyone targetted and prevent the development of another. I mean if Debian becomes the default that actual reduces RHEL's value proposition for their paying customers. Reinforcing a platform's dominance is contributing value.

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 ago
  A 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 ago
      CentOS 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 ago
        CentOS 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 ago
        Thanks, 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.
ptoal 3y ago
The value in RHEL is not just in the ability to call Red Hat for support. I submit that much more of the value of RHEL is in the packaging and maintenance processes. Selecting software, making sure it's enterprise ready, patching it, backporting fixes, QA and regression testing, etc. From my view inside the machine, Red Hat is still committed to an opensource development model, and I don't see that changing any time soon. The thing Red Hat is trying to do is find the balancing point between capturing, and giving away value, as Scott McCarty explains in this post: https://opensource.com/article/21/2/differentiating-products-upstream-suppliers https://opensource.com/article/21/2/differentiating-products... Since before I became a Red Hatter, I have used CentOS for my personal servers and projects. I have struggled with CentOS Stream for that application, for example packaged kernel drivers from ELRepo. I can understand why many are upset about this. As a casual user, I am not upset, because I still have lots of options (RHEL Dev sub, Fedora, Ubuntu, Arch, etc.) If I had given a lot of time and effort that benefited the EL community, and in turn, Red Hat. I would probably be more upset. I find myself torn on this issue. On one hand, I really want there to be a vibrant Enterprise Linux community where nobody has doubts or trust issues in participating. On the other hand, I also want Red Hat to continue to have a viable business model around RHEL so that the community continues to be able to benefit from all of the expertise that it gets from all of the people who get to make it their main focus because they can rely on a steady paycheck by doing so. I think that when Red Hat was growing fast, it was easy for them to have a laissez-faire approach to downstream rebuilds. Now that the business is contracting, people have had to start making hard decisions. There's no more difficult decision to make, than to lay off people. I would not want to have a leadership role at Red Hat right now. I don't expect it's much fun. I really worry about the impact that this has on goodwill. I think most people at Red Hat are also concerned about this. The ecosystem around RHEL will not be the same. EPEL, ELRepo, and all of the other communities that have flourished around the downstream builds are going to be impacted. Trust, when broken, is very hard to rebuild. Jeff's comments ("fool me once...") underscore the rift that is driving away good people. I worry about the long-term effects of this. I hope that this will not "kill Enterprise Linux" as many have suggested. I do believe, though, that it has been wounded. Disclosure: I am currently employed by Red Hat.
- realitythreek 3y ago

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 ago
A 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 ago
    CentOS 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 ago
      CentOS 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 ago
        Thanks, 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.

ptoal 3y ago

The value in RHEL is not just in the ability to call Red Hat for support. I submit that much more of the value of RHEL is in the packaging and maintenance processes. Selecting software, making sure it's enterprise ready, patching it, backporting fixes, QA and regression testing, etc. From my view inside the machine, Red Hat is still committed to an opensource development model, and I don't see that changing any time soon. The thing Red Hat is trying to do is find the balancing point between capturing, and giving away value, as Scott McCarty explains in this post: https://opensource.com/article/21/2/differentiating-products-upstream-suppliers https://opensource.com/article/21/2/differentiating-products... Since before I became a Red Hatter, I have used CentOS for my personal servers and projects. I have struggled with CentOS Stream for that application, for example packaged kernel drivers from ELRepo. I can understand why many are upset about this. As a casual user, I am not upset, because I still have lots of options (RHEL Dev sub, Fedora, Ubuntu, Arch, etc.) If I had given a lot of time and effort that benefited the EL community, and in turn, Red Hat. I would probably be more upset. I find myself torn on this issue. On one hand, I really want there to be a vibrant Enterprise Linux community where nobody has doubts or trust issues in participating. On the other hand, I also want Red Hat to continue to have a viable business model around RHEL so that the community continues to be able to benefit from all of the expertise that it gets from all of the people who get to make it their main focus because they can rely on a steady paycheck by doing so. I think that when Red Hat was growing fast, it was easy for them to have a laissez-faire approach to downstream rebuilds. Now that the business is contracting, people have had to start making hard decisions. There's no more difficult decision to make, than to lay off people. I would not want to have a leadership role at Red Hat right now. I don't expect it's much fun. I really worry about the impact that this has on goodwill. I think most people at Red Hat are also concerned about this. The ecosystem around RHEL will not be the same. EPEL, ELRepo, and all of the other communities that have flourished around the downstream builds are going to be impacted. Trust, when broken, is very hard to rebuild. Jeff's comments ("fool me once...") underscore the rift that is driving away good people. I worry about the long-term effects of this. I hope that this will not "kill Enterprise Linux" as many have suggested. I do believe, though, that it has been wounded. Disclosure: I am currently employed by Red Hat.

realitythreek 3y ago