6 ms·

Maybe it's a bit too obvious to spell it out, but 1. Red Hat Inc. does not want people to build and/or distribute gratis RHEL8 or clones. It would be trivial t

by em500 6y ago

Maybe it's a bit too obvious to spell it out, but 1. Red Hat Inc. does not want people to build and/or distribute gratis RHEL8 or clones. It would be trivial to just put the actual RHEL8 iso as an unsupported download on their ftp/www server and sell the support separately, like Oracle or Canonical do. Instead, they kept this ridiculous make work project called CentOS around, that involved non-trivial manual labor meticulously rebranding RHEL into RedHat owned CentOS-the-laggard-RHEL-clone, whose users apparently mainly value it for being as close to RHEL as possible without paying. To a distant observer, the whole setup looks quite absurd. I think it's actually good that they finally put an end to it. But they should have either not started CentOS 8 at all or rode it out till the end. Pulling the plug at 20% of it's lifetime is plainly a shitty move. 2. It appears that building a legal RHEL8+ clone is quite a task, and I'm guessing the amount of work involved is largely controlled by Red Hat Inc. I.e., they can make running/maintaining a project like Rocky or others more and more expensive if they choose to. I believe they going to test the limits of how difficult they can make building from their sources within the boundaries of the GPL. If you think I'm wrong, just put up a mirror of the RHEL8 (not CentOS8) SRPMs and see how long it stays up. Clearly they're not acting in the spirit of the GPL, even if they are in the letter. 3. Given the previous points, I believe any project like Rocky is a losing proposition. If the "community" really values enterprise stability so much, better put the effort into an extra-stable-extra-LTS fork of Debian or even Ubuntu, and preparing for transition away from RHEL. Or just pay up, if you really believes the RHEL stability is so valuable. Clone projects are by necessity extremely dependent on actions of Red Hat Inc which has largely opposite interests. I don't know why people would volunteer for that.

evol262 6y ago
> 1. Red Hat Inc. does not want people to build and/or distribute gratis RHEL8 or clones. It would be trivial to just put the actual RHEL8 iso as an unsupported download on their ftp/www server and sell the support separately, like Oracle or Canonical do. Instead, they kept this ridiculous make work project called CentOS around, that involved non-trivial manual labor meticulously rebranding RHEL into RedHat owned CentOS, whose users apparently mainly value it for being as close to RHEL as possible without paying. To a distant observer, the whole setup looks quite absurd. I think it's actually good that they finally put an end to it. But they should have either not started CentOS 8 at all or rode it out till the end. Pulling the plug at 20% of it's lifetime is plainly a shitty move. But [they do](https://developers.redhat.com/products/rhel/download https://developers.redhat.com/products/rhel/download). A subscription buys you updates and support. RHEL itself is free. In addition, considering that almost all of Red Hat's products are "upstream first", branding is generally a single additional RPM which changes some colors. It is _not_ hard to rebrand RHEL > 2. It appears that building a legal RHEL8+ clone is quite a task, and I'm guessing the amount of work involved is largely controlled by Red Hat Inc. I.e., they can make running/maintaining a project like Rocky or others more and more expensive if they choose to. I believe they going to test the limits of how difficult they can make building from their sources within the boundaries of the GPL. If you think I'm wrong, just put up a mirror of the RHEL8 (not CentOS8) SRPMs and see how long it stays up. Clearly they're not acting in the spirit of the GPL, if they are in the letter. The only case in which this has happened is changing the packaging of the kernel-sources SRPM so Oracle could not pick and choose particular patches, and instead had to deal with a single massive diff to make stuff like kpatch work. The "expensive" part of building an EL8 clone is standing up a bunch of Koji builders. That isn't necessary either, strictly. It just makes "turn this SRPM into an RPM and combine it with a bunch of others into a temporary repo we can dogfood/release" easier. As always, it comes down to cost. > 3. Given the previous point, I believe a project like Rocky is a losing proposition. If the "community" really values enterprise stability so much, better put the effort into an extra-LTS fork of Debian or even Ubuntu, and preparing for transition away from RHEL. Or just pay up, if you really believes the RHEL stability is so valuable. Clone projects are by necessity extremely dependent on actions of Red Hat Inc which has largely opposite interests. I don't know why people would volunteer for that. The problem with this, broadly, is that the "community" is comprised of a lot of Red Hat-employed engineers. This idea that Linux is a bunch of "community" people that RH/IBM/whomever siphon off is completely fallacious. Sure, they exist, but the vast majority of Linux development is commercial. Some bug is reported in a downstream product that a customer pays for, or a feature is requested by a major customer (or the technical debt involved in maintaining something gets too high, or whatever), and professional engineers who are being paid to work on it write the patches upstream. Once they're merged, they get picked downstream into some kind of productized version. Given that most of that happens in Fedora (or OKD, or oVirt, or whatever upstream is for a given product), CentOS being run by RH was pretty much the same embrace+extend+extinguish philosophy. The vast majority of RH engineers run Fedora, or an EL clone, and that isn't gonna change. What's different is that RHEL is no longer a growing revenue stream, and CentOS users didn't convert to RHEL at a large rate (or they reported CentOS bugs against RHEL, which is strictly against Red Hat's support policy). What customers values is indemnity and the ability to point their finger at someone external, plus normal stuff like a security response team and responsible+timely disclosure during major CVEs. What the community value(d|s) is the ability to run commercial software that the vendor supports on RHEL without actually _paying_ for RHEL. It's not that they value 'enterprise stability'. It's that they value being able to run SAS or whatever without hacking the hell out of the installer. That isn't offered by an extra-LTS fork of Debian or Ubuntu, and no amount of complaining on Hackernews is gonna change that.
- chillfox 6y ago
  I think one of the reasons people don't really value "enterprise stability" is because it is mostly a myth.
  - corty 6y ago
    Agreed. The reason is more "we are running supported software in a supported combination of hardware, OS and application". That's what auditors are looking for. I've yet to see a real benefit beyond the paperwork advantage.
- l2dy 6y ago
  * The free download is only "for Development Use". * Debranding is much more work than a single RPM. https://wiki.centos.org/About/Building_8 https://wiki.centos.org/About/Building_8 No you can't just "sed s'/Red Hat/CentOS/' (someone always offers that) There are times when you do replace and times when you don't.
  - evol262 6y ago
    That isn't how Red Hat does things in most of their projects. oVirt/RHV provides a reasonably "standard" example with their "rhevm-branding-rhev" package: http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en/RHEV/SRPMS/ http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en... It's a single package with relatively few additions, mostly color schemes in CSS. Anaconda documents this in /usr/share/branding RHEL puts a lot into subpackages of redhat-releasea But it isn't really the point. There are thousands of packages. Only a handful actually deal with branding. I was an engineer at Red Hat for 7.5 years, and I left last June. I'm intimately familiar with this, and while it's more complex than sed, it's much simpler than it sounds, and the CentOS people are definitely familiar with it. Branding is NOT their hurdle. It's the build system, as they repeatedly mention. And that is Koji, which is also open source: https://docs.pagure.org/koji/ https://docs.pagure.org/koji/ You're blasting Red Hat for making it seem like they're somehow opposed to clones. That's fatuous. A major engineering company with complex workflows uses their own build system. News at 11. They also make this free and document the hell out of it. Anyone who has ever built a package for Fedora is familiar with it. Anyone who has ever dealt with release management/engineering for a product inside Red Hat is extremely familiar with it, and that includes many of the core CentOS team, plus the Fedora RelEng SIG is easy to join if you want to learn. It's complicated, but it's not black magic or even hard information to get. CentOS ALREADY USES IT. It really doesn't matter whether the RHEL image is "for development use only" (you didn't want support anyway). Stop moving the goalposts.
jhatemyjob 6y ago
The way you describe it reminds me a lot of the iOS jailbreak community. There were some people that thought that it could overtake vanilla iOS but they failed to realize they are perpetually fighting directly with a large corporation and will probably burn out and lose. It sucks but that's reality
dralley 6y ago
> If you think I'm wrong, just put up a mirror of the RHEL8 (not CentOS8) SRPMs and see how long it stays up. Clearly they're not acting in the spirit of the GPL, even if they are in the letter. The GPL doesn't require you make the sources public to everybody, just the people to whom you are distributing your software. But Red Hat does provide sources, to everybody. They go above and beyond what the GPL actually requires.
- em500 6y ago
  The ftp site does not contain sources for RHEL 8 (it's just sources for a bunch of add-on packages). The RHEL 8 sources are in git.centos.org, though not in SRPM form. I know that GPL only requires Red Hat to provide sources on request to those receiving their binaries. But in principle the receiver can then legally redistribute those sources. Now AFAICT nobody's actually doing that redistributing. I don't know whether that's due to lack of interest, or due to some Red Had shenanigans that makes redistribution illegal/unattractive.
  - mbreese 6y ago
    RedHat has to permit the redistribution per the GPL. But there is nothing stating that your support contract can’t be cancelled if you do it. (I don’t have any first hand knowledge of this, just a guess).
    - bigbubba 6y ago
      Grsecurity also uses this 'loophole.' Seeing this scheme go mainstream is really disheartening; I feel that it really undermines the intent and social value of the GPL.
      - ikiris 6y ago
        It's supposed to be against the GPL, but no one is willing to chase it.
        6y ago
p1necone 6y ago
> better put the effort into an extra-stable-extra-LTS fork of Debian or even Ubuntu I've always thought of Debian LTS as basically the end all be all of Linux server OS stability (let's ignore the BSDs for this exercise), is the main draw of CentOS over that just the longer LTS period or is it also meaningfully more stable?
- bigbubba 6y ago
  From what I understand, it's not just a matter of longer support, but also training. A lot of companies have/had mixed RHEL/CentOS environments, with RHEL on the machines they really want RH support for and CentOS on everything else to save money. Having a mixed RHEL/Debian environment would probably be a pain in the ass for all your sysadmins.
  - garyrichardson 6y ago
    On top of this I also believe that companies prefer the RHEL opinionated implementation of a linux system vs Debian's. RedHat is a company that sells to other companies. Therefore it has to implement their linux and make decisions in a way that works well with how other enterprises think. Big companies aren't comfortable depending on "the community" to do the right thing for them.
    - johannes1234321 6y ago
      On top of all these companies want to run (commercial) software from other vendors, which sometimes is certified only on RHEL.
  - joana035 6y ago
    Not really, I have seen CentOS based infrastructure having more problems (xfs breaking docker, frankenkernel 3.10 in 2020?) whereas with Debian things just works and are not heavily patched to the point of breaking ABI.
    - Nullabillity 6y ago
dcdsc 6y ago
Red Hat stopped long ago of being an open source company with open source values unfortunately, not to mention that a lot of good talent had exodus long ago to FANG companies which are now driving most of development.
op00to 6y ago
> 1. Red Hat Inc. does not want people to build and/or distribute gratis RHEL8 or clones. Why does Red Hat release everything as source RPMs, and not, say, one big tarball of sources which would still meet the source requirement of the GPL?

by em500 6y ago

evol262 6y ago

> 1. Red Hat Inc. does not want people to build and/or distribute gratis RHEL8 or clones. It would be trivial to just put the actual RHEL8 iso as an unsupported download on their ftp/www server and sell the support separately, like Oracle or Canonical do. Instead, they kept this ridiculous make work project called CentOS around, that involved non-trivial manual labor meticulously rebranding RHEL into RedHat owned CentOS, whose users apparently mainly value it for being as close to RHEL as possible without paying. To a distant observer, the whole setup looks quite absurd. I think it's actually good that they finally put an end to it. But they should have either not started CentOS 8 at all or rode it out till the end. Pulling the plug at 20% of it's lifetime is plainly a shitty move. But [they do](https://developers.redhat.com/products/rhel/download https://developers.redhat.com/products/rhel/download). A subscription buys you updates and support. RHEL itself is free. In addition, considering that almost all of Red Hat's products are "upstream first", branding is generally a single additional RPM which changes some colors. It is _not_ hard to rebrand RHEL > 2. It appears that building a legal RHEL8+ clone is quite a task, and I'm guessing the amount of work involved is largely controlled by Red Hat Inc. I.e., they can make running/maintaining a project like Rocky or others more and more expensive if they choose to. I believe they going to test the limits of how difficult they can make building from their sources within the boundaries of the GPL. If you think I'm wrong, just put up a mirror of the RHEL8 (not CentOS8) SRPMs and see how long it stays up. Clearly they're not acting in the spirit of the GPL, if they are in the letter. The only case in which this has happened is changing the packaging of the kernel-sources SRPM so Oracle could not pick and choose particular patches, and instead had to deal with a single massive diff to make stuff like kpatch work. The "expensive" part of building an EL8 clone is standing up a bunch of Koji builders. That isn't necessary either, strictly. It just makes "turn this SRPM into an RPM and combine it with a bunch of others into a temporary repo we can dogfood/release" easier. As always, it comes down to cost. > 3. Given the previous point, I believe a project like Rocky is a losing proposition. If the "community" really values enterprise stability so much, better put the effort into an extra-LTS fork of Debian or even Ubuntu, and preparing for transition away from RHEL. Or just pay up, if you really believes the RHEL stability is so valuable. Clone projects are by necessity extremely dependent on actions of Red Hat Inc which has largely opposite interests. I don't know why people would volunteer for that. The problem with this, broadly, is that the "community" is comprised of a lot of Red Hat-employed engineers. This idea that Linux is a bunch of "community" people that RH/IBM/whomever siphon off is completely fallacious. Sure, they exist, but the vast majority of Linux development is commercial. Some bug is reported in a downstream product that a customer pays for, or a feature is requested by a major customer (or the technical debt involved in maintaining something gets too high, or whatever), and professional engineers who are being paid to work on it write the patches upstream. Once they're merged, they get picked downstream into some kind of productized version. Given that most of that happens in Fedora (or OKD, or oVirt, or whatever upstream is for a given product), CentOS being run by RH was pretty much the same embrace+extend+extinguish philosophy. The vast majority of RH engineers run Fedora, or an EL clone, and that isn't gonna change. What's different is that RHEL is no longer a growing revenue stream, and CentOS users didn't convert to RHEL at a large rate (or they reported CentOS bugs against RHEL, which is strictly against Red Hat's support policy). What customers values is indemnity and the ability to point their finger at someone external, plus normal stuff like a security response team and responsible+timely disclosure during major CVEs. What the community value(d|s) is the ability to run commercial software that the vendor supports on RHEL without actually _paying_ for RHEL. It's not that they value 'enterprise stability'. It's that they value being able to run SAS or whatever without hacking the hell out of the installer. That isn't offered by an extra-LTS fork of Debian or Ubuntu, and no amount of complaining on Hackernews is gonna change that.

chillfox 6y ago
I think one of the reasons people don't really value "enterprise stability" is because it is mostly a myth.
- corty 6y ago
  Agreed. The reason is more "we are running supported software in a supported combination of hardware, OS and application". That's what auditors are looking for. I've yet to see a real benefit beyond the paperwork advantage.
l2dy 6y ago
* The free download is only "for Development Use". * Debranding is much more work than a single RPM. https://wiki.centos.org/About/Building_8 https://wiki.centos.org/About/Building_8 No you can't just "sed s'/Red Hat/CentOS/' (someone always offers that) There are times when you do replace and times when you don't.
- evol262 6y ago
  That isn't how Red Hat does things in most of their projects. oVirt/RHV provides a reasonably "standard" example with their "rhevm-branding-rhev" package: http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en/RHEV/SRPMS/ http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en... It's a single package with relatively few additions, mostly color schemes in CSS. Anaconda documents this in /usr/share/branding RHEL puts a lot into subpackages of redhat-releasea But it isn't really the point. There are thousands of packages. Only a handful actually deal with branding. I was an engineer at Red Hat for 7.5 years, and I left last June. I'm intimately familiar with this, and while it's more complex than sed, it's much simpler than it sounds, and the CentOS people are definitely familiar with it. Branding is NOT their hurdle. It's the build system, as they repeatedly mention. And that is Koji, which is also open source: https://docs.pagure.org/koji/ https://docs.pagure.org/koji/ You're blasting Red Hat for making it seem like they're somehow opposed to clones. That's fatuous. A major engineering company with complex workflows uses their own build system. News at 11. They also make this free and document the hell out of it. Anyone who has ever built a package for Fedora is familiar with it. Anyone who has ever dealt with release management/engineering for a product inside Red Hat is extremely familiar with it, and that includes many of the core CentOS team, plus the Fedora RelEng SIG is easy to join if you want to learn. It's complicated, but it's not black magic or even hard information to get. CentOS ALREADY USES IT. It really doesn't matter whether the RHEL image is "for development use only" (you didn't want support anyway). Stop moving the goalposts.

jhatemyjob 6y ago

The way you describe it reminds me a lot of the iOS jailbreak community. There were some people that thought that it could overtake vanilla iOS but they failed to realize they are perpetually fighting directly with a large corporation and will probably burn out and lose. It sucks but that's reality

dralley 6y ago

> If you think I'm wrong, just put up a mirror of the RHEL8 (not CentOS8) SRPMs and see how long it stays up. Clearly they're not acting in the spirit of the GPL, even if they are in the letter. The GPL doesn't require you make the sources public to everybody, just the people to whom you are distributing your software. But Red Hat does provide sources, to everybody. They go above and beyond what the GPL actually requires.

em500 6y ago
The ftp site does not contain sources for RHEL 8 (it's just sources for a bunch of add-on packages). The RHEL 8 sources are in git.centos.org, though not in SRPM form. I know that GPL only requires Red Hat to provide sources on request to those receiving their binaries. But in principle the receiver can then legally redistribute those sources. Now AFAICT nobody's actually doing that redistributing. I don't know whether that's due to lack of interest, or due to some Red Had shenanigans that makes redistribution illegal/unattractive.
- mbreese 6y ago
  RedHat has to permit the redistribution per the GPL. But there is nothing stating that your support contract can’t be cancelled if you do it. (I don’t have any first hand knowledge of this, just a guess).
  - bigbubba 6y ago
    Grsecurity also uses this 'loophole.' Seeing this scheme go mainstream is really disheartening; I feel that it really undermines the intent and social value of the GPL.
    - ikiris 6y ago
      It's supposed to be against the GPL, but no one is willing to chase it.
      - 6y ago

p1necone 6y ago

> better put the effort into an extra-stable-extra-LTS fork of Debian or even Ubuntu I've always thought of Debian LTS as basically the end all be all of Linux server OS stability (let's ignore the BSDs for this exercise), is the main draw of CentOS over that just the longer LTS period or is it also meaningfully more stable?

bigbubba 6y ago
From what I understand, it's not just a matter of longer support, but also training. A lot of companies have/had mixed RHEL/CentOS environments, with RHEL on the machines they really want RH support for and CentOS on everything else to save money. Having a mixed RHEL/Debian environment would probably be a pain in the ass for all your sysadmins.
- garyrichardson 6y ago
  On top of this I also believe that companies prefer the RHEL opinionated implementation of a linux system vs Debian's. RedHat is a company that sells to other companies. Therefore it has to implement their linux and make decisions in a way that works well with how other enterprises think. Big companies aren't comfortable depending on "the community" to do the right thing for them.
  - johannes1234321 6y ago
    On top of all these companies want to run (commercial) software from other vendors, which sometimes is certified only on RHEL.
- joana035 6y ago
  Not really, I have seen CentOS based infrastructure having more problems (xfs breaking docker, frankenkernel 3.10 in 2020?) whereas with Debian things just works and are not heavily patched to the point of breaking ABI.
  - Nullabillity 6y ago

dcdsc 6y ago

Red Hat stopped long ago of being an open source company with open source values unfortunately, not to mention that a lot of good talent had exodus long ago to FANG companies which are now driving most of development.

op00to 6y ago

> 1. Red Hat Inc. does not want people to build and/or distribute gratis RHEL8 or clones. Why does Red Hat release everything as source RPMs, and not, say, one big tarball of sources which would still meet the source requirement of the GPL?