*Changing topic to a new, 'Catch-All' subject for these types of discussions ... *
Traditionally Exim has at least half the Internet relays, and Debian (and direct distributions, like HP hLinux, et al.) are just going to get the call. I do Postfix, but I've done a lot of Exim in the past, both with and outside of HP *[A1]* And I don't want to make this into a distribution discussion. But ... it's unavoidable that we have to sometimes, as part of any *'Software Use Survey' */ *'Package by Popularly,' *hit up the actual *'use cases'* where some distributions are popular, and how their default packages are or are not used. Hosting relays, web, etc... services are already quite Debian, with a good amount of CentOS. But I do see CentOS Stream *[A2]*, even OpenELA distributions *[A3]*, losing marketshare. How much I will not speculate, but for anyone running Fedora and Stream, or tracking Fedora EPEL packages, there has been significant withdrawl from both contributions and mirroring. That hasn't been good. Not even positive words about Stream from Rocky's Founder *[1] *will help that perception at this point. Stream will have to perform, just like Fedora, because Red Hat utterly screwed up the messaging on Stream, just like they did Fedora two decades earlier. I don't think anyone can argue how good Fedora has been, far better than Red Hat Linux before it, and it made RHEL much better as a result too. Stream *[2] *will always exist. Without Stream, RHEL doesn't exist. Every backport to the same package version in RHEL, is what Stream is. It's nothing like Fedora (version forward rebasing). The only time Stream is not RHEL, is when the next release (not update, but release) comes out. E.g., Stream 10 publicly replaces the old, non-public RHEL 10 Alpha (internal/major partners only), and then becomes RHEL Beta, then GA (e.g., RHEL 10.0), at some point. People confuse the two, because neither Fedora nor Red Hat do a great job explainnig that (which is why I need to do another article). But the damage is done. And the SRPMs getting yanked only destroyed any consideration. Poor messaging combined with a horrendous, anti-Oracle (but also very anti-community) decision. I think Maddog did the best job of addressing this in his LPI blog post. *[3]* - bjs P.S. Even as an individual, I've avoided talking about this on LinkedIn, and was glad with Maddog *[3] **'weighed in,' *and I left it at some 'additional commentary' *[3a]*. Even though I was no longer sitting on the LPI Board, let alone it's been several years since Red Hat directly contracted me, I still don't *'feel comfortable*' because most people won't read the *'long story' *required to understand. I.e., IBM v. Oracle, with IBM just finally doing things Red Hat wouldn't, given the community collateral that no one Red Hat employee, at least those with a 4 digit employee number or less (like myself), wanted. And I want to always be 100% productive at all times, and my goal has always been to help explain and understand, to the point I've long been called a *'Red Hat Apologist,'* or a *'GNU Apologist,' *even as an *'individual' *not speaking for anyone but myself (an aging, Gen-X American). After all, I didn't just spend time with customers, but partners and even internal associates, literally explaining things that aren't covered in orietntation. *REFERENCES:* *[1] CentOS Stream: 'I was slow on the uptake, but I get what they are doing now,' says Rocky Linux founder* *(Greg Kurtzer c/o The Register)* - https://www.theregister.com/2021/07/09/centos_stream_greg_kurtzer/ *[2] Why You Should Have Already Been on CentOS Stream Back in 2019 (Bryan J Smith c/o LinkedIn)* - https://www.linkedin.com/pulse/why-you-should-have-already-been-centos-stream-back-2019-smith/ *[3] IBM, Red Hat and Free Software: An old maddog’s view (Maddog c/o LPI)* - https://www.lpi.org/blog/2023/07/30/ibm-red-hat-and-free-software-an-old-maddogs-view/ *[3a] I know many of you have asked me to 'weigh in' on this. I'm purposely avoiding such, and -- admittedly -- 'deflecting' ...* - https://www.linkedin.com/feed/update/urn:li:activity:7092521607788703744/ *[A]NECDOTAL NOTES: * *[A1] HP (hLinux) - *while with Red Hat, I was sub'd to HP (or HP subsidiaries, even left briefly for a Red Hat-benefiting situation) and then finally just finally hired fully away from Red Hat,, during their failed OpenStack+DevOps strategy, I'll spare you that debacle other than it was a great community-open source execution that everyone benefited from (even Red Hat uses a lot of that HP code now, copyrights sold to SuSE), but a total sales disaster that was preventable (again, I'll spare you other than to say HP hired me for my 'early customers adopter' experience, then sales promptly ignored me, and when they didn't like the answer, had me verbally reprimanded only to be completely counter-reprimanded 6 months later when it all came true, and I had it all documented). I even predicted they would sell to SuSE during my exit, and they waited too long and got quite a bit less for it than I recommended (*"Either put in the $1-2B sales-services investment now, loss leader for adoption, or sell it while it's still worth quite a bit to SuSE"*). Understand HP overtook Red Hat in contributions on OpenStack, and literally built a lot they never benefited from (again, great open source leadership, horrendous customer-sales engagement ... it's not a *'sale line item' *but a *'strategic plan'*). HP is so lovable (community efforts), yet frustrating (turning that into money for sustainment), all-in-one. Even Oracle is starting to build a head of an open source leadership position out of necessity (IBM cutting them off from Red Hat). *[A2]* *Stream* - I wanted a public CentOS Stream since well before it was announced, and [RHEL] Stream when it was not public, especially for Internet facing servers, which I could only get access to if I was at a major account. All backports to RHEL go into Stream first, with the same unit, integration, regression testing, as well as ISV/IHV test suite. They just aren't *'held back' *by an artificial date, after a Beta period, which is a major source of frustration if you're not a major account. After all, Facebook and Twitter wanted to get the same backported customer hotfixes that we had at Goldman-Sacs and others. We also didn't want a security fix being backported and released for RHEL because someone said, "Okay, this is important enough to release." We just wanted it. We're smart enough to decide. nVidia and other kernel modules also built. Most things that wouldn't build on Stream wouldn't build on RHEL itself either, and required the add-on RHEL EUS (even *cough*IBM*cough* stuff) which wasn't in CentOS. I received great feedback on my Stream article a few years back *[2]*, and because both Fedora and Red Hat continue to not provide a good article on the 2 purposes of Stream (next update, and next release), I really need to pen another article covering that ... with an unifying graphic that explains most of it. *[A3] OpenELA* - I just don't see how anyone can reproduce the sheer mindshare of Red Hat Engineering in the Upstream and tracking patches, for even just rebuilds ... even CentOS could not, and they went *'yelp' *to Red Hat by 2014 as RHEL got bigger and bigger (plus they didn't rebuild entire swathes of RHEL by 2011+, enough that EPEL was becoming a problem where it was CentOS compatible, but not RHEL). I.e., Just like Rocky, I'm not impressed with OpenELA as a viable solution, especially in compliance environments, because Red Hat literally *'cut Oracle's legs from underneath them' *(and, sadly, the community's). Previously Red Hat had only done things like taking out patchsets in their SRPMs, so it hurt Oracle from modifying them, but didn't hurt CentOS (and the community) because it was just rebuilding 1:1 (not modfying). But there's a difference between getting updates, and being able to track CVEs and Remediations. To Rocky's credit, it's founder was very honest *[3]*, admitted their tracking issues 2 years in, and really tried, far more than Alma and others ... he really did, and even he was impressed with Stream becoming public. *[1]*. The problem is, the sheer manpower required. When CentOS reached out to Red Hat in 2014 for help (Red Hat Legal had long provided services to CentOS pro-bono, especially when some users of CentOS tried to make legal issues for them, having a S&P500 legal council helped counter that), there was the strategy that CentOS would start rebuilding a lot more than the core of RHEL, including RHEV (not use oVirt from EPEL), JBoss (not use Wildfly), so it was even more 1:1. Unfortunately, as more and more Red Hat engineers had their time *'sucked up'* just in rebuilds, testing, tracking things in rebuild CentOS, separate from RHEL, the obviousness of the truth *'showed up.' * Why do all this extra work, instead of just using all the RHEL Engineering efforts *'as-is?' *That right there, finally sold the idea of making Stream public. Because Engineering does Stream as their daily duties, they have to pull patches from the Upstream, usually patching both Fedora (although that's less backports, more rebasing to newer versions) and Stream (backports to RHEL package versions, rarely rebasing), it was obvious ... why not just make Stream public, where everyone gets all customer bugfixes and security patches as they pass the full test suite? I just thought CentOS 8 would be the *'last traditional' *CentOS, alongside CentOS 8 Stream being the first, and future Stream. IBM decided otherwise, and killed CentOS 8 ... without much warning, although most people still had a yerar. SRPMs destroys it all. And I don't see OpenELA doing any better than CentOS + Red Hat Engineering. In fact, if you read the *'fine print,' *OpenELA will only maintain *'best effort' *RHEL 8 & 9 compatibility. OpenELA >9 (16?) will likely be SLES 16 based, not RHEL. On Thu, Jan 25, 2024, 14:04 Jeroen Baten <[email protected]> wrote: > Hi > > On 25-01-2024 20:17, Bryan Smith wrote: > > Debian is likely the future of the community, > > Although completely off topic, after I've been doing open source myself > since 1998, I do agree with this. > > Would be nice though if Debian would have some infrastructure tools too > for managing large groups of servers. > > Other than that, I thinkit has the best cards for the long game. > > My 2 cents of course. > > -- > Jeroen Baten | EMAIL : [email protected] > ____ _ __ | web : www.i2rs.nl > | )|_)(_ | tel : +31 (0)648519096 > _|_/_| \__) | Frisolaan 16, 4101 JK, Culemborg, the > Netherlands > >
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
