Rocky Linux 8.4 Achieves First General Availability Release, Proves Popular (rockylinux.org) 40
"When Red Hat killed off CentOS Linux in a highly controversial December 2020 announcement, Gregory Kurtzer immediately announced his intention to recreate CentOS with a new distribution named after his deceased mentor," Ars Technica reported in February.
And this week, "The Rocky Enterprise Software Foundation has announced general availability (GA) of Rocky Linux 8.4," reports ZDNet. "It's an important milestone because it's the first Rocky Linux general availability release ever." Huge companies, including Disney, GoDaddy, Rackspace, Toyota and Verizon, relied on CentOS, and they were reportedly not happy about RedHat's decision... It turns out that Kurtzer's decision has been a popular one. Besides quickly building up an army of hundreds of contributors for the project, Rocky Linux 8.4 - which follows the May 18 release of Red Hat's RHEL 8.4 - was downloaded at least 10,000 times within half a day of its release... "If we extrapolate the count to include our other mirrors we are probably at least 3-4x that (if not even way more)!" boasts Kurtzer in a LinkedIn post. "Lots of reports coming in of people and organizations already replacing their CentOS systems (and even other Linux distributions) with Rocky. The media is flying off the hook and business analysts also validating to me personally that Rocky Linux might soon be the most utilized Linux operating system used in enterprise and cloud!"
Rocky Linux 8.4 took seven months for the newly formed community to release, and is available for x86_64 and ARM64 (aarch64) architecture hardware in various ISOs.
"Sufficient testing has been performed such that we have confidence in its stability for production systems," explains a blog post at RockyLinux.org, adding that free community support is available through the forums as well as live chat avaiable through IRC and Rocky Linux Mattermost. "Paid commercial support is currently available through CIQ..."
"Corporations come and go, their interests as transient as they are self-serving. But a community persists, and that's who we dedicate Rocky Linux to: you." Rocky is more than the next free and open, community enterprise operating system. It's a community. A commitment to an ideal bigger than the sum of its parts, and a promise that our principles — embedded even within our repositories and ISOs — are immutable...
This is just the beginning, and the Rocky Enterprise Software Foundation is more than just Rocky Linux — it's a home for those that believe that open source isn't just a switch that can be toggled at will, and that projects that many rely on not be subject to the whims of a few. To this point, you can easily find all of our sources, our build infrastructure, Git repositories, and everything else anyone would need to fork our work and ensure that it continues if need be...
When we announced our release candidate, we asked you to come build the next free, open, community enterprise operating system with us. Now we're asking you for more: join us as we build our community.
They also thanked 11 sponsors and partners for contributing "resources, financial backing, software, and infrastructure."
And this week, "The Rocky Enterprise Software Foundation has announced general availability (GA) of Rocky Linux 8.4," reports ZDNet. "It's an important milestone because it's the first Rocky Linux general availability release ever." Huge companies, including Disney, GoDaddy, Rackspace, Toyota and Verizon, relied on CentOS, and they were reportedly not happy about RedHat's decision... It turns out that Kurtzer's decision has been a popular one. Besides quickly building up an army of hundreds of contributors for the project, Rocky Linux 8.4 - which follows the May 18 release of Red Hat's RHEL 8.4 - was downloaded at least 10,000 times within half a day of its release... "If we extrapolate the count to include our other mirrors we are probably at least 3-4x that (if not even way more)!" boasts Kurtzer in a LinkedIn post. "Lots of reports coming in of people and organizations already replacing their CentOS systems (and even other Linux distributions) with Rocky. The media is flying off the hook and business analysts also validating to me personally that Rocky Linux might soon be the most utilized Linux operating system used in enterprise and cloud!"
Rocky Linux 8.4 took seven months for the newly formed community to release, and is available for x86_64 and ARM64 (aarch64) architecture hardware in various ISOs.
"Sufficient testing has been performed such that we have confidence in its stability for production systems," explains a blog post at RockyLinux.org, adding that free community support is available through the forums as well as live chat avaiable through IRC and Rocky Linux Mattermost. "Paid commercial support is currently available through CIQ..."
"Corporations come and go, their interests as transient as they are self-serving. But a community persists, and that's who we dedicate Rocky Linux to: you." Rocky is more than the next free and open, community enterprise operating system. It's a community. A commitment to an ideal bigger than the sum of its parts, and a promise that our principles — embedded even within our repositories and ISOs — are immutable...
This is just the beginning, and the Rocky Enterprise Software Foundation is more than just Rocky Linux — it's a home for those that believe that open source isn't just a switch that can be toggled at will, and that projects that many rely on not be subject to the whims of a few. To this point, you can easily find all of our sources, our build infrastructure, Git repositories, and everything else anyone would need to fork our work and ensure that it continues if need be...
When we announced our release candidate, we asked you to come build the next free, open, community enterprise operating system with us. Now we're asking you for more: join us as we build our community.
They also thanked 11 sponsors and partners for contributing "resources, financial backing, software, and infrastructure."
Hey Rocky! (Score:1, Funny)
Watch me pull a rabbit outta my hat!
Re: (Score:2)
Watch me pull a rabbit outta my hat!
Yet, no one, ever, named a, hopefully, innovative update Bullwinkle... We've been programmed by the whim of a cartoon plot to prefer the tree rat to the largest member of the deer family.
Re: (Score:2)
Glee club. (Score:2)
Lots of reports coming in of people and organizations already replacing their CentOS systems (and even other Linux distributions) with Rocky. The media is flying off the hook and business analysts also validating to me personally that Rocky Linux might soon be the most utilized Linux operating system used in enterprise and cloud!
Optimistic much?
Re: Glee club. (Score:2, Interesting)
As soon as Redhat announced that change, we started looking at other distributions which would run our EDA tools.
Iâ(TM)ll be installing this first in a VM and then on standby server to start testing.
RHEL isnâ(TM)t our first choice for many reasons over
Re: Glee club. (Score:5, Informative)
Me, too. RHEL 8 is a release to skip. Its failures include:
* The python3 migration is ill-managed and already out of date with python 3.6, which was already 4 years old when RHEL 8 was published.
* Ignoring EPEL's standard and publishing python 3.6 as "python3" packages, instead of "python36", which made it ridiculously difficult to effectively publish a parallel python38 or python39 later.
* Modularity, which *everyone* hates.
* Splitting the primary yum repos into 5 distinct repos with overlapping contents,
* Hiding critical "-devel" packages in a distinct and inaccessible "Devel" channel to prevent people from compiling alternatives for Red Hat commercial offerings, such as discarding FreeIPA in favor of Samba with the domain controller features enabled.
Then, after all that, hold a secret meeting that says "oh, we're going to replay the bad decisions of Red Hat 9 and discard point releases, *again*, and pretend that directly updating with a a recent reference release is safe". It's compelling hundreds if not thousands of customers to set up their own internal mirrors with locked release versions. And it's not like Red Hat doesn't actually publish point releases, they're on the revised release media and clearly stated in /etc/redhat-release for configuration reference. Somebody came up with a scheme and power point slides, and no one was left who remembered how badly this failed with Red Hat 9.
CentOS 8 is now a "stream", all right, its now the beta testing land for RHEL, which was *not* why people used it. It would have been faster to simply fire the CentOS developers Red Hat fired a few years ago and send the money to CERN for them to knock out a Scientific Linux 8. CERN is angry, their Scientific Linux admins had agreed not to publish SL 8 in favor of just using CentOS, and they had the rug pulled out from under them. *No one* is updating to RHEL 8 or CentOs 8 if they can avoid it, and there have been so far no compelling reasons to do so.
Re: (Score:2)
To boot, CentOS 8 being a stream doesn't have many advantages over Fedora. If you want a "production" OS, you don't want a stream, and for a streaming OS, CentOS doesn't have btrfs, and a lot of other useful features Fedora comes with.
The parent summed it nicely. Other than a later end of support date, I don't see any real reason to use CentOS 8, as well as RHEL 8. In fact, I'm seeing a lot of development just give up on the Red Hat ecosystem altogether and move to the Debian/Ubuntu universe, because it
Re: (Score:2)
It looks to me like CERN is switching to Ubuntu. Does anyone working there have a better knowledge than the number of published guidelines to use Ubuntu at CERN? Given the better support for Ubuntu in WS, and no official support for CentOS, This looks very bad for Red Hat.
Re: Glee club. (Score:1)
Unfortunately none of the EDA and simulation tools we need to use will work on Ubuntu. Itâ(TM)s RHEL or SUSE all the way.
I would love to be to switch to Ubuntu just for LLVM support, alas, itâ(TM)s just not viable right now.
Re: (Score:2)
To boot, CentOS 8 being a stream doesn't have many advantages over Fedora.
The thing is, CentOS was always just as much a stream as it is now. All they did was stop issuing point releases.
Have you ever cared whether a server was on CentOS 7.3 or 7.4? I certainly haven't, they have always been upgraded to whatever is latest. Everyone makes it out like CentOS 8 is going to turn into CentOS 9 or 10 overnight, but that will still require a traditional non-stream upgrade.
Re: (Score:2)
Then, after all that, hold a secret meeting that says "oh, we're going to replay the bad decisions of Red Hat 9 and discard point releases, *again*, and pretend that directly updating with a a recent reference release is safe"
I'm not going to say I saw it coming because I didn't, but I had a deep feel of fuckery was afoot back in 2014 when Jim Perrin had mentioned turning it upstream at FISL and shortly after that talk the CentOS SIG was formed. CentOS was cutting into sales of RHEL long before IBM got there and folks in RedHat often mentioned how to reposition things. But I feel that talk he gave in 2014 and then them forming a special group shortly after, it was just too one right after the other and gave me serious unease a
Re: Glee club. (Score:2)
Re: (Score:3)
...but I had a deep feel of fuckery was afoot back in 2014....
My Deep Fuckery alarms went off with RHEL 5, when they introduced the license key that wasn't a license key. I was convinced that was the beginning of a long downward spiral at Red Hat, and I haven't been disappointed. We were knee-deep into Red Hat at that point, and undertook the transition from RHEL to Debian about two years later. It has proven time and again to have been the right choice.
I can only imagine the panic that ensued among Red Hat's customers after IBM bought it. At least, those Red Hat cus
Re: (Score:2)
It's compelling hundreds if not thousands of customers to set up their own internal mirrors with locked release versions.
I could spend *all day* refuting various points here, but I'll just pick one for now.
CentOS has never, *ever*, provided the capability of building reproducible systems from its yum repos. If you need reproducible builds, then you have various options. You can run a local mirror with stable or controlled changes, possibly with Katello, but maybe with more rudimentary tools if you prefer. You can build deployable images (such as AMI or VM images). You can build container images.
You can't, however, rely on
Don't do it! (Score:2)
Do *not* install this release!
Doesn't anyone remember that Rocky gets knocked out, and doesn't win until the sequel?
Beware!
Don't forget AlmaLinux 8.4 (Score:4, Informative)
Don't forget AlmaLinux [almalinux.org], which has similar goals, it's backed by Cloud Linux, and has been out since late March. They also have an official Vagrant box, which makes it easy to try out.
Re: (Score:2)
I've been running a couple test servers at work on AlmaLinux - seems pretty stable, as you'd expect. I'm probably going to start moving most of our existing CentOS 7 stuff over wholesale in fall (too busy to tackle it right now).
Re: Don't forget AlmaLinux 8.4 (Score:3)
Apparently the AlmaLinux 8.4 official Vagrant box [vagrantup.com] is not alone. Rocky Linux seems to have released theirs [vagrantup.com] five days ago.
Re: (Score:1)
Yep, I've got both AlmaLinux and Rocky running at present; both installed OK**, both seem fine, nothing significant to report really (which is a good thing).
For those who need it, AlmaLinux has got secure boot sorted out; Rocky is still working on it but shouldn't be long.
**Rocky produced a few weird errors during the initial boot including one service failing to start, but this all went away after going through the 'first run setup' stuff and rebooting.
Huge companies (Score:5, Insightful)
Huge companies, including Disney, GoDaddy, Rackspace, Toyota and Verizon, relied on CentOS, and they were reportedly not happy about RedHat's decision
There's your problem - if you can fucking afford it, pay for it. Open Source doesn't exist for free. You shouldn't have been relying on CentOS, since no one was obligated to keep it running unchanged.
Re:Huge companies (Score:4, Interesting)
There are all kinds of fuckery with Red Hat.
There were other enterprise class systems out there. The point the GP was making is why are companies specifically picking a vendor's free product instead of their enterprise product for their enterprise applications.
It would be different if turned out these companies were huge Redhat donors, but somehow I suspect you'll find they weren't. They only thing these companies donated to is unemployment numbers in the USA as they outsourced IT to lower cost countries.
Re:Huge companies (Score:4, Insightful)
The one you were replying is referring to the fact that it even if you weren't charged by redhat, it is more work to deploy and manage redhat than centos (or oracle, rocky, alma, or ubuntu) but on par with a lot of big name commercial software vendors. So if you completely put aside the money going to RedHat, RedHat is *still* more of a pain than the free alternatives.
For redhat you have to be meticulous about what channels each installation is entitled to, and registering all the systems with software to track your entitlement. Not only do you have to pay, you have to also do extra work to make sure you are only using what you pay for. This causes weird fragmentation, like RedHat UBI which is an acknowledgement there's no way to do entitlement tracking for transient containers, but also limiting packages in UBI to keep it from being 'too useful'. Some package I might randomly install is 'missing', oh, it's in a channel that this specific system isn't entitled too. It requires more nuanced awareness of what packages come from which channels, planning to make sure you get the right channels in the right places, and all the micromanagement that entails.
For the unregistered systems, you can freely and trivially do whatever without having to also prove that you are entitled to do what you are doing.
I know quite a few people with small deployments that would fall under the 'no charge, even for production use' criteria for 'real' RedHat, but you'd still have to have an rhn account and use your rhn account to register the systems for those systems to receive updates. They still don't want to run RedHat even if free, because it's more work for no additional benefit.
In fact, I believe CloudLinux (behind Alma) and CtrlIQ (behind Rocky) have declared intention to have Oracle Linux/Canonical like commercial support, where you have no restrictions imposed on what you install, but you pay for support if you want it.
Re: (Score:2)
The one you were replying is referring to the fact that it even if you weren't charged by redhat, it is more work to deploy and manage redhat than centos (or oracle, rocky, alma, or ubuntu) but on par with a lot of big name commercial software vendors. So if you completely put aside the money going to RedHat, RedHat is *still* more of a pain than the free alternatives.
When you're running *any* OS in a critical Production environment, cost ultimately comes down to that horrific day when something bad happens and you need support. As in 3rd party professional support on the other end of a 1-800-SHTF-HELP phone line, because the COO is standing on your desk.
Because of that, I *do* find it very odd that large corporations were reliant on CentOS, but they obviously had their reasons for choosing it (cost is the most obvious one, but it's highly likely that's not the only re
Re: (Score:2)
Sure, I was just elaborating on why someone would post that dealing with RedHat is a pain beyond having to pay for it.
I would say it's not so much skill, as it is tedium and frustration knowing the hoops you are having to jump through are not even present in other builds of the exact same code. There may be reasons (like RedHat needing to know which teams to invest support more in than others), but the purpose of the micromanagement and tracking that you the user has to do is for the benefit of the vendor,
Re: (Score:1, Troll)
There's your problem - if you can fucking afford it, pay for it. Open Source doesn't exist for free. You shouldn't have been relying on CentOS, since no one was obligated to keep it running unchanged.
Wrong. Open source does exist for free. That's the whole point of it. If you're involved with Open Source and expect people to pay you then you need to provide something other than the source code that people want to give you money for. Red Hat tries to do that with services and enterprise products. If you don't want those enterprise products then you're under no obligation to give them any money.
CentOS is available for free - free as in free beer. That is its purpose.
Paying Red Hat some amount of money for
Re: (Score:2)
Wrong. Open source does exist for free.
No it isn't. NO open source definition includes "requires no payment" or "free development effort from programmers." Not even GPL (and Stallman) is against commercial use.
Re: (Score:1)
Wrong. Open source does exist for free.
No it isn't. NO open source definition includes "requires no payment" or "free development effort from programmers." Not even GPL (and Stallman) is against commercial use.
And by similar extention, NO open source definition includes "requires payment".
It is necessary to understand what can and cannot be charged for. The GPL, for example, doesn't prevent you from using code commercially but it does prevent you from keeping the benefits you've gained from open source to yourself - IF you need to modify existing code (or in some cases use via libraries.)
You're right that open source doesn't come with "free development effort from programmers", but just the same, there's no fee t
Re: (Score:2)
The quandary open-source faces is also the one piracy faces in that there's no artificial scarcity to leverage. Be it the law saying there's no scarcity, or technological means denying it, it all ends up the same.
Re: (Score:2)
There is a natural scarcity to it, but it's kind of weird.
Sure, once produced, the body of software that comprises RHEL8.4 is only as scarce as we feel like making it, so that particular sequence of binary data has no natural scarcity. However the effort that will be done to produce RHEL8.5 is scarce, it requires that people do work to create that very first copy. We don't have limitless manpower.
So we have this conundrum about how do we make it worth our while to do the *next* thing in the face of the real
Re: (Score:2)
The stated point is that generally open source on the scale of CentOS doesn't exist for free, it cost money to develop it. If you are a large business concern with a lot riding on the availability of a distribution, and couldn't in theory start building an internal Linux distribution indefinitely, then perhaps you are the audience that should pay for a vendor to support your Linux usage. You can be unhappy about the change, but it is something worth considering. You may want to switch to a different commerc
Re: (Score:3, Insightful)
The stated point is that generally open source on the scale of CentOS doesn't exist for free, it cost money to develop it.
If I buy support for CentOS, does the payment reach the programmers for gawk, fdisk, ls, etc, or does it stop with Red Hat? If I pay RH $99/year per VM and they only contirbute 1% of the software to the end product, why are they getting 100% of the money? An answer might be that they don't deserve it (like record labels don't deserve to keep so much of music artist money). Another might be that you pay for Linux kernel development when you buy an Intel CPU and that all of the money thtat gets spent on a num
Re: (Score:2)
If I buy support for CentOS, does the payment reach the programmers for gawk, fdisk, ls, etc, or does it stop with Red Hat?
While they don't employee the developers for all the software they provide, they do employee a large number of them. Notably, in my dealings with them, they are actually pretty hard core 'not invented here' for newer projects, and their preferred strategy is to create a clone and push it instead (e.g. podman v. docker) and if ultimately this fails acquire the 'winner' (e.g. RedHat pushed Gluster hard and dismissed Ceph, until ultimately they acquired Ceph and only then did they publicly treat Ceph as a vali
Release dates (Score:1)
RHEL/CentOS and alternatives 8.4 update availability:
May 21 – RHEL
May 26 – AlmaLinux
May 27 – Oracle Linux
June 3 – Springdale Linux
June 4 – CentOS
June 21 – Rocky Linux
Re: (Score:2)
It will be interesting to see how things evolve. While Rocky does have one of the original CentOS founders, he and his team hadn't been doing it in a while. So they needed to get back into 'how do we build this'. CloudLinux team (Alma) had been doing it all along, so it was a far easier thing for their org to get things done.
Once Rocky gets their sea legs (e.g. their 8.4 is technically not the same as 8.4, as they spun it from a slightly updated package set and they haven't gotten SecureBoot sorted yet), it