Enhanced EL Distro Comparison

[Noam-Alum]

To resolve this issue, I added a chart given to me by @carlwgeorge and an explanation describing the relationship between the different distributions.
In conjunction with the issue, @carlwgeorge and I had some changes in mind for the preexistent comparison table:

• Remove CentOS Linux: won't be relevant soon.
• Combining all the architectures: No need for a row for each architecture.
• Change CentOS Stream lifecycle to 5.5 Years: @carlwgeorge mentioned this is more accurate than writing 5-6 Years.
• Change the "Production Version" row to "First release": First release is less confusing than Production Version.
• Change RHEL compatibility values: It would be more accurate to write "CentOS Stream - major version compatible" and "Alma, Oracle, Rocky - minor version compatible"
• Remove the “Regular updates delay” row: There isn't a significant difference.
• Remove the "FIPS compliance" row: FIPS is per-component and per-version (both distro and fips itself), we can't just write yes or no, and it's hard to summarize in one cell.
• Remove the "SecureBoot" row: There isn't a significant difference.
• Combine "Owned By" row and "Owned by org type" row under one row named “Backing organization”: e.g. “AlmaLinux OS Foundation (501c6 non-profit)”
• Add RHEL to the table: since we are benchmarking against RHEL might as well add RHEL to the table.

All of the changes are given as suggestions but I think some of them are important.

[bennyvasquez]

Sorry for my insane delay here, friends! In addition to the review, I want to discuss some of the changes you made:

• Remove CentOS Linux: won't be relevant soon.

Since CentOS Linux is still VERY widely adopted (and it will take quite some time for folks to migrate away) I don't think this is the right move. Once 7 hits EOL it's definitely appropriate to add a note about the fact that it's very out of date, but it's still worth keeping there.

• Combining all the architectures: No need for a row for each architecture.

Combining them makes it much harder to parse, to my eye. It looks like Oracle Linux is the only one that's different. Is there another way to present this data that is easy to parse but doesn't require multiple rows?

• Change CentOS Stream lifecycle to 5.5 Years: @carlwgeorge mentioned this is more accurate than writing 5-6 Years.

Works for me!

• Change the "Production Version" row to "First release": First release is less confusing than Production Version.

I like it, that's much more clear. Should we perhaps include version numbers here as well?

• Change RHEL compatibility values: It would be more accurate to write "CentOS Stream - major version compatible" and "Alma, Oracle, Rocky - minor version compatible"

Let's add definitions of both of these, since this won't really fix the confusion that folks get when trying to figure out what those mean.

• Remove the “Regular updates delay” row: There isn't a significant difference.

agreed.

• Remove the "FIPS compliance" row: FIPS is per-component and per-version (both distro and fips itself), we can't just write yes or no, and it's hard to summarize in one cell.

I don't think removing is the right move here, as I still think this is a question that gets asked a ton. Perhaps we include links to the relevant components or other information?

• Remove the "SecureBoot" row: There isn't a significant difference.

This one also gets asked of us, and I'm worried that omitting it will just increase the question. What about adding a note under the table that says something like "Previous versions of this table included a row for SecureBoot, but all distros now offer it, so it was removed."

• Combine "Owned By" row and "Owned by org type" row under one row named “Backing organization”: e.g. “AlmaLinux OS Foundation (501c6 non-profit)”

I like it! However, we'll want to include the org types for the others as well. Right now only ours is included.

• Add RHEL to the table: since we are benchmarking against RHEL might as well add RHEL to the table.

I'm not opposed to that at all! It makes sense to me, for sure.

[bennyvasquez]

I'd like to see this image updated to be AlmaLinux-specific. If that's outside your wheelhouse, let me know! I can create one for you.

[Noam-Alum]

It would be great if you could create one, I tried creating something prior to this PR but it was horrible 😆.

[carlwgeorge]

Since CentOS Linux is still VERY widely adopted (and it will take quite some time for folks to migrate away) I don't think this is the right move. Once 7 hits EOL it's definitely appropriate to add a note about the fact that it's very out of date, but it's still worth keeping there.

While it is true that it is still widely adopted, I do think it makes sense to drop it from this table. Nobody referencing this table is evaluating moving to CentOS Linux. They're comparing their options about what they are migrating to next after it goes EOL. Of course this isn't my call if it's included, but that's just my outlook on it.

Combining them makes it much harder to parse, to my eye. It looks like Oracle Linux is the only one that's different. Is there another way to present this data that is easy to parse but doesn't require multiple rows?

I think it's visually bloated to have a line per architecture, with almost every field being "yes". It was my suggestion to combine them into a list of supported architectures. None of these have more than four architectures, so I think it works to have a short list like aarch64, ppc64le, s390x, x86_64. That's not even the longest field in the chart. The only alternative I can think of would be to only have rows for architectures with differences, meaning ppc64le and s390x rows, with "yes" in every column except Oracle. I could see that leading to questions about if the distros listed support architectures that don't have a row, like aarch64. I'm open to other ideas here, but I do think the list of architectures makes the most sense.

I like it, that's much more clear. Should we perhaps include version numbers here as well?

Sounds good to me.

Let's add definitions of both of these, since this won't really fix the confusion that folks get when trying to figure out what those mean.

Major vs minor is much more clear than the variety of descriptions we have now, which we aren't even using consistently. I think major vs minor works pretty well, but if we do want to include a foot note of a definition, I would phrase it like so:

• major version compatible: aims for compatibility with the corresponding major version of RHEL
• minor version compatible: aims for compatibility with the corresponding minor version of RHEL

I don't think removing is the right move here, as I still think this is a question that gets asked a ton. Perhaps we include links to the relevant components or other information?

None of the distros are validated for all modules in all versions, which is why yes/no doesn't work. I agree that linking to more details would be appropriate. But the link text within the table should not indicate "yes" when a distro doesn't have validated modules. Claiming "yes" when a distro's modules are still on the "implementation under test" list or "modules in process" list is not accurate. As best I can tell, only RHEL and Oracle have validated modules. There should probably also be a footnote on this one about whether using FIPS validation securely (i.e. staying on an old minor version with updates) requires paying for a vendor's extended patching product, like RHEL EUS or TuxCare ESU.

This one also gets asked of us, and I'm worried that omitting it will just increase the question. What about adding a note under the table that says something like "Previous versions of this table included a row for SecureBoot, but all distros now offer it, so it was removed."

Maybe this one would be better under an FAQ than in this comparison chart? I don't think this chart has to answer every possible question.

[bennyvasquez]

I fail at git-ing, but made a bunch of suggested changed and couldn't figure out how to get them into this PR as suggestions (rather than just overwriting what y'all had worked on) easily. https://github.com/AlmaLinux/wiki/pull/453/files is the one I mistakenly created, but the changes are also part of this PR now. @Noam-Alum @carlwgeorge how do y'all feel about this?

[Noam-Alum]

I fail at git-ing, but made a bunch of suggested changed and couldn't figure out how to get them into this PR as suggestions (rather than just overwriting what y'all had worked on) easily. https://github.com/AlmaLinux/wiki/pull/453/files is the one I mistakenly created, but the changes are also part of this PR now. @Noam-Alum @carlwgeorge how do y'all feel about this?

From what I can see, you've hit everything we were shooting for! Great job! 😊