6 ms·

What a rug pull. This is something expected from one man distros but it suck for everyone to be tossed into what now pile.

by sh4un 5y ago

JKCalhoun 5y ago
Was that kind of fast?
- agsnu 5y ago
  Normally RHEL/CentOS releases are supported for 10y - CentOS 6 was 2010-2020, CentOS 7 is 2014-2024. 8 was released in 2019 so you might expect it to be supported through 2029, a year ago they announced it would be brought forward by 8 years.
- chasil 5y ago
  Converting to Rocky, Alma, or Oracle Linux will extend support to 2029 with minimal changes to the installed system. Most CentOS 8 users would likely have done this by now. Red Hat also offered a conversion procedure the last time I looked, but it replaced every installed RPM with equivalents from its own repositories. This is quite violent, and it would be far from my first choice for a critical system.
  - rubyist5eva 5y ago
    I can vouch for Alma linux personally, we switched and it was painless.
  - bityard 5y ago
    > but it replaced every installed RPM with equivalents from its own repositories. This is quite violent The whole point of CentOS was to be 100% compatible with RHEL, right down to the packages and binaries. For literally this kind of scenario. I don't see how that's "violent." I'm also not sure how you can expect to convert from one distro to the other without replacing all (or at least most) of the packages.
    - yjftsjthsd-h 5y ago
      > I'm also not sure how you can expect to convert from one distro to the other without replacing all (or at least most) of the packages. The thing is, they were almost exactly the same distro, so in any meaningful sense you could switch from one to the other by switching the release files, some yum support stuff, I think the kernel?, and some miscellaneous branding if you cared. But 99% of packages were functionally the same, so yeah I don't see replacement being a problem per se, but it also didn't seem very necessary.
    - dralley 5y ago
      Ehhhhh. The code is the same, yes. The "binaries" are not, necessarily. The build environment isn't exactly the same and there have been bugs experienced in CentOS that weren't in RHEL and vice versa. So it was never 100% compatible, more like 99.5%. The exceptions are rare edge cases but they do exist.
- josephcsible 5y ago
  It was a little fast, but that's not why it was a rug pull. It was a rug pull because IBM retroactively shortened its lifespan after a bunch of people had already started using it in production.
  - rubyist5eva 5y ago
    Saw it coming a mile away when CentOS was acquired. You don’t acquire your free competitor to keep them around exactly as is simply out of the goodness of one’s heart.
    - yjftsjthsd-h 5y ago
      > Saw it coming a mile away when CentOS was acquired. That was 2014; if this was the original plan, they took their sweet time with it.
      - rubyist5eva 5y ago
        Maybe it wasn’t but I don’t see how any business acquires their free competitor and then keeps it around to cannibalize their own potential market. Just doesn’t make any sense. It was inevitable - initially intentional or not. It’s just capitalism.
    - 5e92cb50239222b 5y ago
      And they got at least two new competitors, three if you count Oracle. You really think they did not foresee that?
      - rubyist5eva 5y ago
        They probably didn’t expect as much backlash to Stream and expected people to just use that or buy RHEL. I’m sure the amount of users they expected to lose to new forks was part of their risk analysis, they just blew it IMO.
rubyist5eva 5y ago
It was announced a year in advance, if that’s a rug pull your org has bigger problems.
- yjftsjthsd-h 5y ago
  EL variants are most popular in companies that consider project turn around to start at the six-month mark for fast work. It's popular precisely because you can settle on one version of one distribution and use it for literally a decade. So yes, one year is a rug pull.
- pfranz 5y ago
  Maybe I've always worked at larger employers than most, but a one year surprise to reevaluate and transition your operating system sounds incredibly disruptive when the original promise was support through 2029 and the "successor" is very different. In my experience major updates like this are discussed annually with eval, testing, and milestones set weeks and months apart. The transitions are often pushed a year or more when issues come up. Resources are dedicated to all of this. It sounds like there are a lot of similar options with relatively easy transitions (away from Red Hat), but you still have to choose who you trust going forward and carryout the transition.
  - rubyist5eva 5y ago
    If you’re relying on the free offering that’s competitive directly with their enterprise offering and your organization is so large that it’s going to take over a year to switch - you should have probably been paying for RHEL to begin with. My midsize outfit that was running from top to bottom on centos did everything you described over the course of about 2 months to switch to Alma Linux. Hundreds of servers managed by an amount of guys I can count on one hand. Sorry not sorry, but large outfits expecting to coast on a free offering don’t get sympathy from me.
- wolverine876 5y ago
  Many organizations, especially larger ones, have investments with much longer time cycles than 1 year.
sheepdestroyer 5y ago
It was announced a while back and there is an easy migration procedure to Centos Stream 8. The argument made is that, overall, there should be less bugs in Centos Stream than in Centos of old because bug fixes are there first now and coming faster than ever was possible.
- throw0101a 5y ago
  > The argument made is that, overall, there should be less bug in Centos Stream than in Centos of old […] The bug level or not of CentOS was not its selling point, but compatibility: > Rocky Linux is an open-source enterprise operating system designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux®. * https://rockylinux.org https://rockylinux.org * https://en.wikipedia.org/wiki/Bug_compatibility https://en.wikipedia.org/wiki/Bug_compatibility If I want a better balance between stability and longevity I run Ubuntu/Debian, which have LTS releases every two years: code that isn't too old, nor 'too new'.
  - sheepdestroyer 5y ago
    Can you explain in what case being exactly bug for bug compatible with a given set of RedHat rpms (which are also in flux all the time with regular updates) is actually more important to you than having less bugs in total? I understand that if your goal was to use CentOS to validate a specific and highly critical workload for eventually running in production on Redhat systems (taking into account the version lock dance to make sure that you indeed have the exact same package versions on both environments, meaning a lot more hassle and delays in bug fixes and security updates that simply following the regulars updates), then Rocky/Alma/AnyRebuild will be better for you. If your goal was already to run production on CentOS, with frequent updates for security, the theory would be that you will be even better served by CentOS Stream. My take is that it is the most popular case. What am I missing?
    - someperson 5y ago
      CentOS Stream is a "rolling release" that's serves a specific purpose of being bleeding-edge test environment to test new changes for future integration into RedHat's stable releases. Many high-availability workloads require a fixed operating-system baseline, where the only changes are security updates and high-priority bug fixes. And even these changes may need to be triaged to determine if the updates are even worth risking uptime. One example would be a hospital network with medical equipment workstations and backend servers. You don't want your ultrasound or key-hole surgery not working because a CentOS Stream update bug. Fixed operating baselines are important for many users.
defanor 5y ago
Such expectations depend on heuristics; to me it didn't look good after RedHat started slowly eating CentOS in 2014, and was eaten by IBM in 2018. Actually even before that, dependence on a single commercial company was a red flag: cancelling products is something that commercial companies do regularly.

What a rug pull. This is something expected from one man distros but it suck for everyone to be tossed into what now pile.

by sh4un 5y ago

What a rug pull. This is something expected from one man distros but it suck for everyone to be tossed into what now pile.

JKCalhoun 5y ago

Was that kind of fast?

agsnu 5y ago
Normally RHEL/CentOS releases are supported for 10y - CentOS 6 was 2010-2020, CentOS 7 is 2014-2024. 8 was released in 2019 so you might expect it to be supported through 2029, a year ago they announced it would be brought forward by 8 years.
chasil 5y ago
Converting to Rocky, Alma, or Oracle Linux will extend support to 2029 with minimal changes to the installed system. Most CentOS 8 users would likely have done this by now. Red Hat also offered a conversion procedure the last time I looked, but it replaced every installed RPM with equivalents from its own repositories. This is quite violent, and it would be far from my first choice for a critical system.
- rubyist5eva 5y ago
  I can vouch for Alma linux personally, we switched and it was painless.
- bityard 5y ago
  > but it replaced every installed RPM with equivalents from its own repositories. This is quite violent The whole point of CentOS was to be 100% compatible with RHEL, right down to the packages and binaries. For literally this kind of scenario. I don't see how that's "violent." I'm also not sure how you can expect to convert from one distro to the other without replacing all (or at least most) of the packages.
  - yjftsjthsd-h 5y ago
    > I'm also not sure how you can expect to convert from one distro to the other without replacing all (or at least most) of the packages. The thing is, they were almost exactly the same distro, so in any meaningful sense you could switch from one to the other by switching the release files, some yum support stuff, I think the kernel?, and some miscellaneous branding if you cared. But 99% of packages were functionally the same, so yeah I don't see replacement being a problem per se, but it also didn't seem very necessary.
  - dralley 5y ago
    Ehhhhh. The code is the same, yes. The "binaries" are not, necessarily. The build environment isn't exactly the same and there have been bugs experienced in CentOS that weren't in RHEL and vice versa. So it was never 100% compatible, more like 99.5%. The exceptions are rare edge cases but they do exist.
josephcsible 5y ago
It was a little fast, but that's not why it was a rug pull. It was a rug pull because IBM retroactively shortened its lifespan after a bunch of people had already started using it in production.
- rubyist5eva 5y ago
  Saw it coming a mile away when CentOS was acquired. You don’t acquire your free competitor to keep them around exactly as is simply out of the goodness of one’s heart.
  - yjftsjthsd-h 5y ago
    > Saw it coming a mile away when CentOS was acquired. That was 2014; if this was the original plan, they took their sweet time with it.
    - rubyist5eva 5y ago
      Maybe it wasn’t but I don’t see how any business acquires their free competitor and then keeps it around to cannibalize their own potential market. Just doesn’t make any sense. It was inevitable - initially intentional or not. It’s just capitalism.
  - 5e92cb50239222b 5y ago
    And they got at least two new competitors, three if you count Oracle. You really think they did not foresee that?
    - rubyist5eva 5y ago
      They probably didn’t expect as much backlash to Stream and expected people to just use that or buy RHEL. I’m sure the amount of users they expected to lose to new forks was part of their risk analysis, they just blew it IMO.

rubyist5eva 5y ago

It was announced a year in advance, if that’s a rug pull your org has bigger problems.

yjftsjthsd-h 5y ago
EL variants are most popular in companies that consider project turn around to start at the six-month mark for fast work. It's popular precisely because you can settle on one version of one distribution and use it for literally a decade. So yes, one year is a rug pull.
pfranz 5y ago
Maybe I've always worked at larger employers than most, but a one year surprise to reevaluate and transition your operating system sounds incredibly disruptive when the original promise was support through 2029 and the "successor" is very different. In my experience major updates like this are discussed annually with eval, testing, and milestones set weeks and months apart. The transitions are often pushed a year or more when issues come up. Resources are dedicated to all of this. It sounds like there are a lot of similar options with relatively easy transitions (away from Red Hat), but you still have to choose who you trust going forward and carryout the transition.
- rubyist5eva 5y ago
  If you’re relying on the free offering that’s competitive directly with their enterprise offering and your organization is so large that it’s going to take over a year to switch - you should have probably been paying for RHEL to begin with. My midsize outfit that was running from top to bottom on centos did everything you described over the course of about 2 months to switch to Alma Linux. Hundreds of servers managed by an amount of guys I can count on one hand. Sorry not sorry, but large outfits expecting to coast on a free offering don’t get sympathy from me.
wolverine876 5y ago
Many organizations, especially larger ones, have investments with much longer time cycles than 1 year.

sheepdestroyer 5y ago

It was announced a while back and there is an easy migration procedure to Centos Stream 8. The argument made is that, overall, there should be less bugs in Centos Stream than in Centos of old because bug fixes are there first now and coming faster than ever was possible.

throw0101a 5y ago
> The argument made is that, overall, there should be less bug in Centos Stream than in Centos of old […] The bug level or not of CentOS was not its selling point, but compatibility: > Rocky Linux is an open-source enterprise operating system designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux®. * https://rockylinux.org https://rockylinux.org * https://en.wikipedia.org/wiki/Bug_compatibility https://en.wikipedia.org/wiki/Bug_compatibility If I want a better balance between stability and longevity I run Ubuntu/Debian, which have LTS releases every two years: code that isn't too old, nor 'too new'.
- sheepdestroyer 5y ago
  Can you explain in what case being exactly bug for bug compatible with a given set of RedHat rpms (which are also in flux all the time with regular updates) is actually more important to you than having less bugs in total? I understand that if your goal was to use CentOS to validate a specific and highly critical workload for eventually running in production on Redhat systems (taking into account the version lock dance to make sure that you indeed have the exact same package versions on both environments, meaning a lot more hassle and delays in bug fixes and security updates that simply following the regulars updates), then Rocky/Alma/AnyRebuild will be better for you. If your goal was already to run production on CentOS, with frequent updates for security, the theory would be that you will be even better served by CentOS Stream. My take is that it is the most popular case. What am I missing?
  - someperson 5y ago
    CentOS Stream is a "rolling release" that's serves a specific purpose of being bleeding-edge test environment to test new changes for future integration into RedHat's stable releases. Many high-availability workloads require a fixed operating-system baseline, where the only changes are security updates and high-priority bug fixes. And even these changes may need to be triaged to determine if the updates are even worth risking uptime. One example would be a hospital network with medical equipment workstations and backend servers. You don't want your ultrasound or key-hole surgery not working because a CentOS Stream update bug. Fixed operating baselines are important for many users.

defanor 5y ago

Such expectations depend on heuristics; to me it didn't look good after RedHat started slowly eating CentOS in 2014, and was eaten by IBM in 2018. Actually even before that, dependence on a single commercial company was a red flag: cancelling products is something that commercial companies do regularly.