Disclaimer: What you are about to read may contain inaccuracies. Feel free to discuss them somewhere else. This is also my opinion and as such it may change through time, maybe tomorrow, next month, next year, next decade or never. I do also make very few reviews (if any) of what I write here, so this article won’t be polished by any means. Contact me if you have anything to say.
The CentOS case.
As announced by Red Hat on December the 8th, the company behind the famous Red Hat Enterprise Linux (RHEL), and nowadays an IBM subsidiary which allows the blue giant to get a foot in the cloud money machine, they cease the release of the CentOS 8 distribution at the end of 2021, and all the CentOS’s team efforts will go to CentOS Stream instead. This is the statement from CentOS, and this one is Red Hat’s own announcement.
This means, users of CentOS version 7, will have updates and patches released until 2024 as scheduled in 2014. Remember CentOS matches the releases and maintenance windows of RHEL, and that has typically meant 10 years of support. However, CentOS 8 users were promised the same 10 year window, but they now find themselves with a much shorter lifespan, which ends the last day of 2021. CentOS 8 users are now redirected to use CentOS Stream, a variant of the project Red Hat and CentOS came up with in 2019.
If you find the articles in Adminbyaccident.com useful to you, please consider making a donation.
Use this link to get $200 credit at DigitalOcean and support Adminbyaccident.com costs.
Get $100 credit for free at Vultr using this link and support Adminbyaccident.com costs.
What is CentOS really in 2020?
Is plain CentOS a debranded, free in cost, exact distribution of RHEL? No, not exactly. Is it a 99% match? Hard to say but it’s close, very close to RHEL, assuring an almost 99% binary compatibility. Which is like saying yes, but this is a bit more complicated.
CentOS is a GNU/Linux distribution in the RHEL ecosystem which sits at the very tail of the development cycle of that realm. Fedora, another distribution, is where all the new ideas are put together and released. From that development branch Fedora represents, every three years, Red Hat developers make a cut which in the end becomes RHEL. Later comes CentOS which is blindly compiled with the same source of the RHEL release without the trademark and branding bits and without the proprietary software Red Hat uses for themselves. Mind this is done by a separate team that often have little to no contact with RHEL engineers. This cycle ends in 2021.
Fedora —> RHEL —> CentOS
Red Hat took the once independent CentOS project under their wing in 2014 and not only gave support, but they gave paid jobs to some of the community members directily involved in the project. They had a good agreement that benefitted everyone. CentOS was now an official part of the Red Hat family and the company was now closer to the community. But the developent model was the same as explained in the paragraph above until 2019, where the CentOS Stream project appeared. This new project set a new development model and it sits right between Fedora and RHEL development cycle, while regular CentOS remained at the very tail.
Fedora —> CentOS Stream —> RHEL —> CentOS
CentOS has been and is an understaffed project. It takes a month for every point release of RHEL to be rebuild as CentOS. Security patches are not handled equally in CentOS as in the more efficient RHEL releases. There’s been only two people dedicated in Red Hat for CentOS 8, Carl and Brian Stinson, while other members have been dedicated to CentOS 7, as it was stated in this podcast. Scott McCarty himself approximates the number of people working on CentOS at 10 members in a response to a comment in an article published by himself.
To make this dissertation short, CentOS has been understaffed, has been roll out at least a month later in the minor releases compared to RHEL and at worst three months later, also inheriting the still unfound bugs from RHEL blindly, getting less bug reports than RHEL and receiving less security patches than RHEL. Far from the RHEL quality clone some ideally praise it was. Almost a clone but without the quality badge many put on CentOS without realising it wasn’t really the case. A simple exercise to grasp this, is to look for the difference on security patches released by both entities during the same amount of time. For RHEL I count 160 patches released for the whole November 2020 and 8 days of December, versus 66 released for CentOS 6, 7 and 8. Count them yourself, here you can find the RHEL ones (select the product) and here you can find the CentOS ones.
Not sure already? Let’s take an specific example, so anyone can get a better view of the matter. Let’s take the vulnerability identified by the number CVE-2018-17189. This issue affects Apache HTTP, if you click on the link you’ll be able to read further detail. It’s not a critical vulnerability, it just qualifies as a medium one, but the risk of leaving this unpatched is suffering some sort of a Denial of Service (DoS) attack when using the newer HTTP2 protocol instead of the older 1.1 or even 1.0. How to mitigate/solve this one? Just apply the patch. In case you can afford to do so performance wise, while the patch isn’t available, just disable HTTP2 and use 1.1 and 1.0 versions. Now, is the patch available for CentOS?
Anyone who has administered any system dilligently will use some sort of auditing software. Or the security team will send an email stating there’s some yet to patch system. How they know this? Because they’ve launched a tool similar to Nessus, a tool which scans systems looking for missing patches, open ports, dangerous configurations, etc. A CentOS user had this same case in his hands, and had some trouble finding if the patch had been liberated and published for the CVE-2018-17189 on CentOS systems. Another user stated Red Hat Security Advisories were sufficient to track if a vulnerability had been patched in CentOS, which is plain wrong. Please, have a look if anyone can find any reference to this vulnerability in this year’s security advisories in CentOS, because I haven’t been able to. Contact me if you find it. To me, CentOS hasn’t released any patch and I don’t care if this package alledgely solves this, simply because the ‘Changelog’ doesn’t state a fix on the vulnerabiliy CVE-2018-17189 as of today December the 20th of 2020. Red Hat’s advisory clearly states what packages apply the patch to fix this. But CentOS’s doesn’t.
Because of this situation one may assume the patch has been applied, since CentOS seems to be just a blind recompilation of RHEL. But, is this assumption valid? How production ready is an OS that makes knowing if a certain vulnerability has been fixed or not this difficult? I’ve heard and read very bold claims on CentOS’s qualities but I may have a different approach to reliability as others do, since a system that takes weeks or months to be patched when the fix is ready doesn’t seem very reliable to me. I’m afraid other’s definition is rather odd. Mind I’m already accepting the assumption that the GNU/Linux camp makes of what an OS is, since Apache HTTP is just a third party application. However, CentOS as many others, provides compiled binaries and one has to swallow them blindly, hence extending the OS boundaries beyond logic. RHEL doesn’t seem to support self compiled binaries so… you need to accept what they give you, but at the same time you have to accept what CentOS is giving you as well. Like it or not.
With this example I am not saying your OS is less secure than my OS, or this other OS. I am trying to bring some CentOS users to the reality the’ve been living, where statements like ‘CentOS is free RHEL’ are not as true as their willingness have brought them to believe. I must add these are not a few paragraphs to blame the CentOS team, quite the contrary. I think this brings light to the difficulties of maintaing an up to date distro tracking another one. End of the example.
Is this all? No, of course not. CentOS has been great for many years and it has served so many along the years, countless people. However, the old approach before Stream made CentOS a merely consumption distribution. Individuals and companies have developed personal and enterprise projects while following track of CentOS which allowed them to have the assurance those projects were able to run onto RHEL flawlessly. In short, CentOS has been the base upon many have developed products, companies, organizations without the need of a RHEL license, being compatible at almost 100% rate with an enterprise grade GNU/Linux OS, and thus without the costs associated with it. Logically a community has developed around it. A community of non-paying customers, or a community of potential customers, whatever you like to call it.
As an example of how the community leverages this distribution, CentOS is also used alongside RHEL in many organizations, direct customers of RHEL. Critical systems are licensed to use RHEL but non critical ones are using CentOS to save costs and development licenses complications while maintaining the RHEL compatibility. This is over as many say but Red Hat says this isn’t over, quite the contrary, since Stream allows those as well as individuals to become contributors, not just mere consumers. Some say this is the murder of a distribution, some others qualify this as an upgrade, a big one if I may.
What is CentOS Stream, allegedly?
The official release notes of CentOS Stream state the following:
CentOS Stream is a rolling-release Linux distro that exists as a midstream between the upstream development in Fedora Linux and the downstream development for Red Hat Enterprise Linux (RHEL). It is a cleared-path to contributing into future minor releases of RHEL while interacting with Red Hat and other open source developers. This pairs nicely with the existing contribution path in Fedora for future major releases of RHEL. In practice, CentOS Stream will contain the code being developed for the next minor RHEL release. This development model will allow the community to discuss, suggest, and contribute features and fixes into RHEL more quickly.
From what Alex Kretzschmar explained in a podcast a few days ago, each CentOS Stream release will be 5 year support distribution, while major RHEL will be released every 3 years. CentOS Stream is a distribution sitting in between the fast development cycle of Fedora which incorporates the latest and greatest and the stable and corporate friendly Red Hat Enterprise Linux (RHEL). It’s not Beta testing software though, as many have wrongly claimed it is. As Johny Huges, a long time CentOS maintainer (and I must add my admiration for his work and perseverance), puts it in this way:
Stream is the RHEL sorce code for rhel + 0.1 .. so durng the 8.3 rhel cycle, stream will be rhel 8.4 source code. It is not very far ahead of the current code. It is indeed the code you will get in 6 months. It is not 'new shiny' .. it is newer enterprise. What are the benefits: 1) Many people (like Intel and Facebook) are providing feedback in real time. So can any user. They should have in place, before RHEL 9 development starts, the ability to accept public community pull requests into stream. 2) This code is still RHEL source code .. it is just not released in rhel yet. Almost all of it will be released in the upcoming RHEL point release. 3) Most bugs will get fixed faster, if the code is pulled into stream. Many times you don't get the fix until the next point release .. and this will be what stream is.
Source:
https://lists.centos.org/pipermail/centos/2020-December/352178.html
Rich Bowen, another CentOS contributor explains this in the first email that triggers a long list of answers in the mailing list.
CentOS Stream will also be the centerpiece of a major shift in collaboration among the CentOS Special Interest Groups (SIGs). This ensures SIGs are developing and testing against what becomes the next version of RHEL. This also provides SIGs a clear single goal, rather than having to build and test for two releases. It gives the CentOS contributor community a great deal of influence in the future of RHEL. And it removes confusion around what “CentOS” means in the Linux distribution ecosystem.
Source:
https://lists.centos.org/pipermail/centos/2020-December/352168.html
The Fedora project leader, Matthew Miller, further expands why CentOS Stream isn’t beta or testing quality software:
For others, note that the plan is for CentOS Stream to target upcoming RHEL minor releases. Between any two six months, the change delta should be just the same as it is in CentOS Linux now. It's not like it's going to become Fedora Rawhide. Everything going into it is intended to land in RHEL on a short timescale. It's not a beta or a playground for broken code.
Source:
https://lists.centos.org/pipermail/centos/2020-December/352254.html
I hope these extracts help you out understanding what CentOS Stream is, appart from the official Red Hat press release.
PR gone wrong.
Very wrong indeed. Rolling release, new development licenses, new offers, are just words that have appeared during this move to CentOS Stream anouncement. And they have all fall short.
Apparently Red Hat is planning more free RHEL licenses for personal use, universities and development, however none has been published, none appears in the recommended path of migrating to CentOS Stream, and none has been seen or speculated about from official or close sources. So, nothing in hand yet to understand the future. Wrong!
Explaining CentOS Stream as a rolling release distro has been not just a disaster but a half truth/half lie, leading to a huge confusion by almost everyone outside Red Hat. Something like this next would have been more accurate and understandable: CentOS will be a continuously delivered upstream version, by a 0.1 release positive margin of production RHEL. Explaning software versioning, as Scott McCarty explained in his blog entry, and giving identical references from Red Hat itsef would have greatly helped understanding the move and furthermore understand what CentOS is and has been.
Not giving examples of use cases, success migrations, and paths already walked on this move would have cleared out more than 70% of the uncertainty of the current CentOS users. Why haven’t you RH done this? It’s madness! Has anyone ever thought on CentOS users as potential RHEL ones? It doesn’t look like it. Maybe it wasn’t needed. Maybe it would have been. I don’t know.
I could go further but I won’t. It’s so obviuous communicating this has failed it’s not necessary to get into details here. Red Hat needs to massively improve on their communications. I hope this isn’t the typical flow with their customers and an isolated unfortunate case. Overall this has been an awful example of how not to communicate anything. The damage on the brand and the image it has beyond its current customer base will need to be addressed in the future, and it will have a significant difficulty many have already pointed out with good reasons.
Note: I wrote this paragraph above on December the 12th or so, and since then Red Hat and CentOS have been releasing more blog posts addressing the situation and giving details on different fronts. Take a read on those if this CentOS situation is so critical to you, you may find interesting and decisive clues.
My very personal take (going beyond).
Red Hat is the company that really moves GNU/Linux forward. Yes, there are others, but the one doing the heavy lifting and setting the standard is Red Hat. Many of us, as well as other distributions and companies have what I’d call a ‘parasitical relationship’ with Red Hat. This may be shocking and counter to the open source meaning notion. But I am afraid I have a good point, specially having in account the current situation, where many ask for software, not just free as in freedom but free as in beer as well. Hence ‘the party is over’ tittle in this article.
Anyone who has read me in the past knows I have a bias towards the BSDs, however, I must note I have used not just at work but privately too, a few GNU/Linux systems to different extends. I did also have, and still maintain, a very personal opinion on the modern GNU/Linux camp vs the open source UNIX one. In the particular case of the CentOS transformation to CentOS Stream, I am more inclined to accept the Red Hat side rather than the general public reaction. Over reaction I must point out.
Words like murder, death, betrayal feel to me an exageration of the alleged inconvenients that may or may not arise from this event. I understand how pissed many people are now about the change. And yes, this may result in many forthcoming issues but my question is: do you really think you were so good before? Have you realized of the lack of personnel working on CentOS even after Red Hat purchased the brand and gave a paid job to a few key people? Have you been aware of the late patching, which is a security risk on its own, but worst yet, the lack of security patches released when the two systems are compared? (I refer to the above explained example for CVE-2018-17189). Your answer is probably negative, but I beg you must think about this twice and come to your own conclusion.
To me, CentOS Stream is more of a ‘Release Candidate’ of RHEL distribution than anything else. Calling it a rolling release distribution has been a huge and utterly avoidable mistake. Scott McCarty, a manager working for Red Hat, agrees on this, further expanding the Release Candidate approach to an ‘RC with good visibility’. Source in this article.
The move does offer CentOS a very good opoportunity to grow. To incorporate patches (almost all of them by the way) before RHEL gets them, to have new tools for the cloud environments you are all obsessed with before RHEL does, to have a voice in the development of the product you were mere consumers. As it is been said CentOS Stream is the point release of RHEL before RHEL gets there. So, if RHEL is now on version 8.3, CentOS Stream is on the future RHEL 8.4. All of this at no cost. Is the CentOS party really over? I may say it’s not!
And no, this is not BETA quality software. With CentOS Stream Red Hat is using a very similar model of releases to Microsoft’s Windows 10 one. Windows 10 is now getting incremental improvements every month, having the hard cut every 18 months. And I haven’t seen anyone panicking as much on that, although IT personnel seems to have bad expectations from Microsoft anyway and a much higher tolerance with them.
How many donations has CentOS received throughout the years? Would the CentOS situation in 2014 had been different if those donations had flown to the project? Would have Red Hat acquired CentOS then if resources had been available at the time? This move allows an unprecedented openness to open source development from a private corporation, and lots of people seems to just want gratis software. Which is shameful to say the least. Have you already planned your donnations for 2020? Think about it.
When does this parasitical relationship we all have with Red Hat end? First when people starts donating real money to the developers of the software they use, like or whatever the reason they see fit. It’s ok if a company can’t afford to pay a fully fledged RHEL license but what about giving away one hundred bucks per year? How about that, huh? On the other hand, when another competing company appears from the open source side and kicks ass as much as Red Hat has. If Red Hat fails, the struggles for many other companies, even many with proprietary software, will be not just unprecedented but scary too. And no, forking is not the miraculous solution. The GPL, as implemented today, is a trap. Someone has to hold the burden, to carry the flag, and to suffer the costs. This entity is not just one company, right, but Red Hat holds the most weight of this Linux thing, doesn’t it? Google? Facebook? Who are those ones without the existance of RHEL? If Red Hat fails, the open source model fails, it’s that simple.
The IBM conspiracy theory that seems to have captivated the general public opinion is just nonsense. Even if true, it misses the main reason of this move. It’s not just money, it’s the Red Hat survival in the long run. Having a 10 year support window is great for enterprises but a pain, a huge one I might add, in the development cost and the carried technical debt. This policy can, an in fact I bet it has, slowed down the adoption of some technologies, the improvement of existing ones and it adds a difficulty level in the development cycle few know first hand, and some of us can only glimpse in the far distance. Fedora can kick the ball as hard as it wants now, and further expand the imagination and the possible forthcoming technologies, while CentOS Stream is the fundamental piece to land new and desired improvements on RHEL. Otherwise RHEL will start lagging fundamental technologies in a very competitive segment and strategic as the cloud is.
So, it’s not about forks, it’s about the model,at least in my view. If Red Hat fails, at the current state of affairs, the open source model is at risk in my view. We are not that far from the 90’s mentality, although it doesn’t seem to be the case. Certainly Google or other technology giants could take the Linux kernel and the GNU components and move them forward, continuing the development of such technologies. Will those companies then behave as Red Hat has? Why would be the reason to follow a model that would have failed? Very little. Furthermore, in my humble but strong opinion, the GPL has been hijacked by big companies. Very few remember it was precisely the IBM blessing in the very early two thousands that made Linux viable in corporations and hence its full development to unfold. It wasn’t just a couple thousand internet connected volunteers anymore. Something else had to happen and that was the approval of big tech corporations such as IBM.
The GPL hijack makes total sense in the modern corporate world, where competitiveness and the optimization of expenses beyond sanity is the norm. Why develop a competitive altenative product when I can rebuild a product from a competitor with absolute binary compatibility? Why bother competing? Why ‘wasting’ money and talent on something I can already get for free and with good quality? Yes, there is competition among programmers, but only on a big single project. Forks are expensive and the modern corporate world tends to oligopolyc behaviours, not pure, fair and old fashioned competition. At least this is my view of it today.
Last but not least, I find staggering up to nausea the prejudice against corporations. Anything the internet herd sees as success, as corporative, as a money making machine for people to make their way of living and add value and structure to society, tends to be quickly demonized and disregarded without much thought. Big mistake. Don’t get me wrong, make me sing an old school IBM song dressed in a suit and I quickly show you my middle finger. But I find disturbing the reactions and the words I’ve heard and read on this Red Hat move. Even a few companies have overreacted and dismiss the possibility of giving support to CentOS Stream, a decision that seems to me a bad signal to an unreasonable part of the ‘community’, and not a good product planning one. I find a sector in the community, who ought to have a better understanding of technology, development, and how business works, failing to calibrate this Red Hat change, even if the company has been so appallingly bad in communicating this. Who wants enemies when one can have this friendly people as allies?
Alternatives.
Other Linux distributions may be a desirable target to land on. From the more appropiate ones to the least these are a few ones.
CentOS Stream. Yes, you read it right. The number one distro you should land on is CentOS Stream. The drama I’ve been reading and listening about these days is not as big as it will surely end up being. You already know the beast, and you’ve been using the worst version of it for years. Give the new and better beast a try, you’ll find yourself at home. And remember, in the very close future software will be consumed in a more continuous manner. Realise you were consuming something that was not what you believed it was and now you have a better opportunity. Fail to get into this train now and you will loose precious time for your company, organization or yourself. You will regret not trying now and jumping on later.
Debian. Just because you are already used to old software. Fast patches? Your own product being licensed for… an enterprise grade OS? Wrong place. Yes, Debian is stable, reliable, has good community support, it’s well thought, well developed, has a fair amount of native tools. But again, weren’t you developing something for enterprise use and further licensing as such product?
Oracle Linux. This should be number two though. Similar to what you’ve been already consuming but better since now Oracle will have the opportunity to track CentOS Stream closer to get their stuff even quicker to you. Ain’t it great? You also get a newer Linux kernel, with improvements on the scheduler, patches, and memory management. Ain’t it great?
You have to understand Larry to use Oracle Linux or, in fact, any Oracle product. But also understand how rough business is made. I may even say, if drunk enough, Larry didn’t kill Solaris but Red Hat did. If you, greedy people who want software for nothing, were in the same situation as Larry and other at Oracle have been you would quite surely killed Solaris even quicker. Why bother with the costs of developing the best OS in the world when you can get a similar product with a quarter of the cost (you get it from the Red Hat source) and people are already convinced Linux is the way to go? Halt that expensive to develop thing called Solaris and give the masses the Linux they want. This is what happened. To understand this point further I suggest you have a read to my previous article on Linux vs open source UNIX.
Larry didn’t believe in the cloud back in 2009-2010. He stated the cloud was someone else’s computer. He was and is still right. This ‘mistake’ didn’t stop him making a u turn the next year at the main Oracle convention to say Oracle was going full throtle to the cloud. He realised he was wrong to what the market wanted and he quickly turned around. People tend to be stubborn, I know this because I am one too.
SuSE Enterprise Linux. Does this remind you of something? Yes, it reminds me of Red Hat, but in green. Don’t get me wrong, aside from CentOS Stream and if you hate Oracle (which you do), this should be your best bet. SuSE is the german cousin of Red Hat and as all german things it’s very oppinionated about how things ought to work. That said it is a brilliant distro, a very nice product indeed, with a smaller gap if you come from RHEL than to say Debian/Ubuntu.
Oh! Sorry… I forgot you have to pay for SuSE Enterprise Linux as in RHEL. Licenses seem cheaper though. But you can always rely on OpenSuSE Leap. Oh! I see, you don’t run ‘BETA’ software. Yes, because following your logic about CentOS Stream, OpenSuSE Leap is just that. However, it ins’t and you know it.
And you even considered Debian… Gosh!
Ubuntu. A much better alternative to Debian but with its own drawbacks too. Patches do almost come first in Debian, which in turn tend to come first from Red Hat or SuSE. I’ve spent one year of my life tracking CVEs from many OS vendors. You may not trust me on this. You should but my best recommendation is you do the work and see for yourself.
As you already know Ubuntu is the aspiring force to replace Red Hat’s dominance in the corporate world as far as Linux concerns. It has a good product, which in my view is just taking Debian Unstable and stabilizing it with lots of testing. Does this reming you of anything? A Stream of wind I might say.
Ubuntu is produced by a company called Canonical which is profitable on the server side of things, and gives away a desktop distribution which has caused losses but seems to be profitable in the long run to them since it provides an easy approach for the future IT developers and admins. How much development does Ubuntu in the GNU/Linux realm?
Furthermore, who is contributing the most into the Linux ecosystem when comparing distros? Oh! It turns out it is Red Hat by quite a margin.
Source:
https://www.phoronix.com/scan.php?page=news_item&px=RedHat-SUSE-Canonical-Kern-10s
Given this, why bother the move to Ubuntu anyway? By the way, if I were you, I’d have a close look on Canonical’s finance, just in case. Now that Ubuntu has a quite significant market invested in the cloud it could change its mind on how Ubuntu is acquired and charge a small amount for every download. Remember what Red Hat did back in 2004? They pulled the plug, didn’t they? Just a net profit of 11,1 million $ out of 110 could be the perfect reason to do so for Canonical. Specially when Ubuntu has 314K instances deployed in AWS and Red Hat has just 22K for RHEL, and the latter having a much larger profit with a net income of 259 million dollars in 2018. In other words, Canonical has 14 times more Ubuntu instances deployed than Red Hat has RHEL in the AWS cloud. However profit for Red Hat is 23,5 times the one of Canonical when counting all the business lines, not just the cloud, according to ZDNet’s figures from 2018. Ouch.
Notice the following if you are heavily invested into Ubuntu.
Canonical had 1,349,000 $ of benefit after taxes in 2019. The alleged number of Ubuntu instances running on AWS is 371,334 on December the 20th, 2020. If every instance had donated 50$, the earns for Canonical would be 18,566,700$. Had all those instances been charged the minimal amount of a RHEL license the eans would’ve climbed to a whooping 140,735,586 $.
More info on Canonical’s financial status here:
https://find-and-update.company-information.service.gov.uk/company/06870835/filing-history
The BSDs.
I am biased towards FreeBSD but hey, if I were in your circumstances I wouldn’t doubt it and I’d move to CentOS Stream without hesitation.
However, my view is, if you plan to move to FreeBSD for example, you may have to do some work. First, if you just maintain 50 web sites and a few databases here and there, an LDAP structure and some networking equipment, you can do it with all of the already mentioned products, so why worry of issues on the BSD side of life? Just use whatever you like. However, if you need commercial support, look somewhere else. But I am afraid many of you just weren’t on that front anyway.
If you plan to move away from CentOS to Debian, I believe the jump is higher than to the one to FreeBSD. This is a very personal approach but CentOS is very unixy, unlike Debian which tends to be… Debian. There’s another thing one must understand when landing on the BSDs though.
See, FreeBSD, OpenBSD are operating systems. And software runs on top. Unlike in the GNU/Linux distributions Samba isn’t ‘curated’ in here (it’s not ham either). You run your OS and on top you run Samba. Or Apache HTTP, or PHP. Think of Windows, the one OS you surely use at work. The OS is Windows, and Chrome is that software you run on top. You already do this, you understand this, you are familiar with this. Windows isn’t always the cause of issues to the software running on top. Quite often the software has an issue. Don’t blame the vendor if it isn’t its fault.
FreeBSD, and other BSDs, provide compiled binaries which tend to be pretty close (days or just few weeks away) to the lastest offered by such vendors. Yes, I called PHP a vendor, as much as Samba is another one. Call them producers if you wish. Furthermore you can manually compile the software you want from such vendors and choose the versions and what you compile.
FreeBSD does incorporate a second way to install software, not just plain binaries (which are installed with the ‘pkg’ tool). Ports is an infrastructure, that comes with the OS and allows your host to compile any software available for FreeBSD. And I imagine you will find most of what you already use since thre are roughly 40k packages available. You can easily and in a graphical way (via ncurses) compile your desired software from the original vendor, straight away. Say you want to compile NGINX, you can easily do it, setting the desired flags as you wish in a quick and graphical manner if you wish (CLI is also available) with FreeBSD Ports.
This site below can help you find if the software you use is available in FreeBSD land.
Furthermore you can even set your own repository with your ‘curated’ opinion on whatever the software you like to compile with Poudriere. You can set this piece and get it to automatically compile the software you want, with the options you want and consume it the way you want. This is a tutorial on Docean for that. Oh! I see, you need already compiled binaries that are also curated and ‘integrated’ into the OS you run. Go CentOS Stream then!
If still interested on FreeBSD just get the handbook so you can have a general idea of what you will find:
http://ftp.freebsd.org/pub/FreeBSD/doc/handbook/book.pdf
Oh! By the way… Licensing. Yes, if you want to develop software FreeBSD is a good choice, an alternative I may add, as other companies are already doing. NetApp develops software from FreeBSD, as Apple does it to develop macOS, as Juniper does for the OS in their network appliances, as Sony does grab some bits of the kernel to develop the PlayStation console, as many others do, basically.
The forks.
In every disaster, there’s opportunity. And some smart people sees such opportunities, and they have the insight to act quickly. I don’t have a very well formed opinion on those strategies but I am afraid at this moment, in the big picture and in the long run, given the circumstances this doesn’t help anyone, not even themselves. I may be very wrong though.
My strongest point against using any of the probably funciontal forks is the following. Why tracking a blind rebuild that will be sure late in patches which is clearly behind RHEL when you can get ahead and consume the next version of RHEL 6 months ahead, counting down and being monitored and fixed every day? There’s no reason to accept being behind when you can be ahead, also tracking RHEL, as you did but getting support and quick fixes, since Red Hat can’t afford a bad new RHEL release be it minor or major. This applies to everyone but specially to those basing their company or product on top of CentOS.
On the Rocky Linux front I must say I have serious trouble understanding why so many people are excited about it. Its leader abandoned the CentOS ship a while ago. Why should anyone follow him again on this ‘back to the future’ rock? Is there anything ready for such fork to work and operate quickly? No, there is not. So why the hype?
Fork as much as you want, as much as you like, and as much as you can. Enjoy it however it is.
Conclusion.
No one has ever had a free cost identical clone of RHEL with CentOS. CentOS was, and is, damn good close to RHEL. But CentOS not only lacks the customer support a paid RHEL license offers, it also lacks fast and current patching, not just feature wise but in security too (even if it’s just informational). CentOS Stream is a much better option for current CentOS users, as the code they use will land in RHEL 6 months later, patches will be made continuously, which is a good feat for any possible arising issues, and they will have the opportunity they never had to participate and give feedback to the company they praise their admiration for its reliable star product named RHEL. In other words current CentOS Stream 8.4 is what RHEL 8.3 will become in 6 months (obviously will be upgraded to RHEL 8.4 afterwards). Hence the similarity to a ‘release candidate’ product which, in my view, is far more accurate than ‘beta quality’ or ‘rolling release’.
Please, realize with the old model of CentOS you were already getting versions late, patches were late and not everything was landing in a good timing. Not to mention there are way too many servers that are not well maintained and patches lack their presence. A stellar behaviour many should be ashamed of. Furthermore. the most heard complain consists in the alleged impossibility to run CentOS Stream on a production environment. The fundamental argument consists on the lack of reliability and stability of such distro. However I find that reasoning contradictory to the general observed behaviour since, for quite a long time, many of the CentOS users have been running a distro which was understaffed, lately patched and did not get all the security improvements. Again, compare the patches released for RHEL and the patches released for CentOS on the same period of time. You’ve been running a bomb for quite a few years, haven’t you? And nothing happened! Or did it? According to your logic CentOS is an exact copy of RHEL, which is not. It would be if both were released on the same date from the same source, but they aren’t and patches don’t come in the same quantity.
CentOS Stream is the future RHEL by a 0.1 release, and it’s continually patched and looked after. How hard can that be to run in production? My guess is not harder than what you’ve been running up to this date in 90% of the cases. That is huge. And more importantly, CentOS Stream users will be giving back to the community continously.
To briefly summarize: Don’t panic. Test it, think about it, adjust if necessary and carry on.
PS: Just in case you haven’t realized about it. A FreeBSD user and proponent is telling you to keep on CentOS by using CentOS Stream. That’s a good one, huh?
PS2: Have you already planned your donations to support your favourite projects? I don’t have a plan but I donate when I can.
If you find the articles in Adminbyaccident.com useful to you, please consider making a donation.
Use this link to get $200 credit at DigitalOcean and support Adminbyaccident.com costs.
Get $100 credit for free at Vultr using this link and support Adminbyaccident.com costs.