Rocky Linux: A CentOS replacement by the CentOS founder
github.com
github.com
One of my colleagues caught some and put them in one of our lab freezers and forgot about them. Months later we remembered the jar... took it out of the freezer. Cockroaches thawed out and seemed to be fine... very active, almost like nothing happened.
Other experiments were performed as well... anyhow, cockroaches are hard to kill.
https://sciencenotes.org/can-cockroaches-survive-nuclear-bom...
But I think some just dismiss it based on the name. I think if I was going to build a startup, it'd be on the top of the list for database choices only thing I really wish it had was Full Text Search and CIText but I guess those will be added some day. I think it's a neat piece of engineering though so far!
Agreed. It's funny that people here are complaining "Rocky Linux" isn't a professional name and they won't be able to convince corporates clients to use it. Yet, there exists a billion dollar revenue company named "Red Hat" which clearly is a "professional" name.
It's widely accepted nowadays, it was pretty weird in 2004. I got my fair share of jokes in 2005-2007 from friends when talking about that "ubuntu" thing, and I'll spare you the examples.
Quite embarrassing for all involved.
A zillion times better than trying to explain what a "Suse", an "Ubuntu", or a "Manjaro" is, and that's before talking about the various types of hat-based distros.
I agree though its a perfectly fine name.
I want Bullwinkle Linux.
— Gregory Kurtzer, Founder
I am not even sure what is going on.
1. The Name has a meaning. As shown in the quote above. And it is tribute / honour to a founder, from a previously well known project ( CentOS )
2. That meaning and the linkage in itself is extremely marketable. Especially to the target audience which are using CentOS.
3. This message explaining its meaning has been there since Day 1 according to Github history.
4. But more than half of the comments ( 150 ) are pissing on its name.
5. Which suggest that either a) They didn't actually click on the link and read anything or b) They dont like name for whatever reason.
6. I will be judgemental, and I am willing to bet those who are complaining about the name has never done any professional marketing or sales for any decent period of time.
Having said all that, they are still entitled to their opinion. But it also shows why product development and marketing based on surveying doesn't really work.
Bingo.
Hell, my grocery store sells sausage bites made by Dietz & Watson that are called "Dietz Nuts".
Names are not destiny.
CentOS failed twice, it ran out of money in 2014 and was rescued back then by Redhat sponsership. Again in 2020. Another widely used RHEL respin was Scientific Linux which mothballed when RHEL 7 was released.
There seems to be lots of potential users but not lots of potential money for a RHEL respin.
CentOS just gave everything away for free and then is wondering why they're not making any money.
The free RedHat tier should have a shorter support window that's still long enough to attract users who want a stable platform to build long-lived appliances.
Self-Support: $350/yr Standard: $800/yr Premium: $1300/yr
Those are all starting points without including potential addons.
Without the absurdly high licensing fee. A more reasonable amount (be it a saas-like low monthly charge or one-off 3-digit fee) would probably go down fine with enough institutional users to generate a decent amount of money.
There is a some up/down depending on various rebates, volume licenses, support included/excluded, etc ("nobody pays sticker price"). But in general, RedHat is in the same order of magnitude as Windows but a little cheaper due to no per-core-pricing, no necessary CAL shenannigans or weird limitations on number of users/size of company/VM/PM and stuff.
But of course it's true that in domains like HPC or cloud computing, the huge number of licenses and machines involved make a few hundred bucks per year just too expensive in sum.
In fact, Ubuntu does too much development for its own good. People jumped on it because it was “a usable Debian updated more often”, and they got all sorts of crazy UX experiments.
Whether or not it is a good plan in theory, it clearly doesn't seem to be working that well for them in practice.
I know mentioning incentives and that people lie is not popular here but when the same thing happens to two different projects you have to be willfully blind to not see a pattern.
As for making it viable long term: a clear goal, community norms and quick removal of anyone not toeing the line.
I really think everyone should just say “fuck this”, abandon it and throw the time at LTS Debian. Red hat control way too much of the ecosystem at the same time so there needs to be a strong, stable, non-commercial alternative.
> Whats missing is an analysis of why CentOS failed.
But the terrific thing about the GPL, for all its flaws and despite its crazy founder, is that it ensures the health and longevity of a project despite well-funded attacks against it.
CentOS is actually Red Hat's greatest advertisement
If IBM Red Hat wanted to push for RHEL upgrades, they should have changed the CentOS support window from 10 years to 3-5 years. If they had to wind back the EOL for CentOS date from 2029, they should have at least move it back to eg, 2024 not 2021.
Whatever replaces it either needs a better business model (to pay for maintenance, RHEL, Ubuntu) or more community involvement (work for free, Debian). But when you’re effectively repackaging another distro, it’s probably hard to get other people excited enough to help.
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.
But [they do](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.
* Debranding is much more work than a single RPM. 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.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/
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.
That's true in a literal-but-useless sense. Developers-RHEL might be bit-identical to real-RHEL at some dates, but as a product it's of course very very different due to lack of interim updates. And that's aside of the smaller speedbumps of registration and having to involve Legal if you want to run in a company.
> 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. [...] 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.
I don't know how true that is, the CentOS wiki makes it sound like like the debranding part is non-trivial/manual labour intensive. So according to you the main bottleneck is hardware / buildservers? If that's true, one wonders why even the minor CentOS 8.x releases lag RHEL 8.x by 4 to 6 weeks.
I guess we'll get to see it soon, with Rocky Linux development.
> 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, I largely believe the long-running narrative that a lot of core Linux development is paid/done by Red Hat, and that most other distros, including Debian/Ubuntu are free-riding to some extend. That's why I not really behind the cheering for Rocky, and think it's fairer in the end to either pay up, or roll up the sleeves and do a real _community_ enterprise OS based on Debian instead of cloning RHEL.
> 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.
The first part might be true of RHEL customers, but I don't think it's true for CentOS customers. The customer base is of course diverse, but my guess is that for a very large part of the (CentOS, not RHEL) users, objections to moving to Debian/Ubuntu are practical (legacy/switching costs, maybe followed by maybe proprietary software support), much more than principled/legal.
Again, stop moving goalposts. Your comment was "why can't they just put it on FTP/WWW without support". That's exactly what they do. You aren't required to register it in any way, including downloading. You want a free "product". That isn't their business model. At least they make the sources for everything available, which took Canonical years for Landscape.
> I don't know how true that is, the CentOS wiki makes it sound like like the debranding part is non-trivial/manual labour intensive. So according to you the main bottleneck is hardware / buildservers? If that's true, one wonders why even the minor CentOS 8.x releases lag RHEL 8.x by 4 to 6 weeks.
This is literally the build system. I have real-life experience branding a number of Red Hat products, including rebranding Anaconda and the base system. See for example https://github.com/oVirt/ovirt-release/blob/master/ovirt-rel...
The lag is because Koji (which is also used internally) uses a hierarchical build/tag system. See https://docs.pagure.org/koji/using_the_koji_build_system/ and https://docs.pagure.org/koji/tag_inheritance/
For a base release, a mock root needs to be bootstrapped. This is more or less by hand, and does definitely require incremental builds of and the rest of the base system. I guarantee the CentOS releng team has scripts that do this, but I don't know where they'd keep them (I never worked directly with that team). Once they're in a koji buildroot, that buildroot can be used to bootstrap its way to a 'release' buildroot, with successive tags. Again, this is something that any build engineer should be familiar with.
The real wrench with 8 is modularity, which is also present in Fedora. If you really want to help CentOS go help them fix it:
https://lwn.net/Articles/805180/
Issues like "special version of RPM in the buildroot" are weird non-issues specifically related to how Koji works, but Modularity does have real problems.
> Sure, I largely believe the long-running narrative that a lot of core Linux development is paid/done by Red Hat, and that most other distros, including Debian/Ubuntu are free-riding to some extend. That's why I not really behind the cheering for Rocky, and think it's fairer in the end to either pay up, or roll up the sleeves and do a real _community_ enterprise OS based on Debian instead of cloning RHEL.
This is a no true Scotsman argument. I don't know what isn't "real" or "community" about CentOS other than the fact that there was/is overlap between CentOS maintainers and RH employees. Just because they have day jobs doesn't mean they can't be part of the community, too. Hand wringing about what's fair defeats the purpose of using a distro like a tool to accomplish goals.
> The first part might be true of RHEL customers, but I don't think it's true for CentOS customers. The customer base is of course diverse, but my guess is that for a very large part of the (CentOS, not RHEL) users, objections to moving to Debian/Ubuntu are practical (legacy/switching costs, maybe followed by maybe proprietary software support), much more than principled/legal.
You inverted this argument and you're asking the wrong questions. The question isn't "why aren't people moving off CentOS?", it's "why did they use CentOS in the first place?"
It's because they were already familiar with RHEL from previous jobs, and wanted familiar tooling (apt may be nicer than yum was, but dpkg is a dumpster fire for package maintainers compared to RPM, and RPM's tooling is much more cohesive than digging around in 10 different manpages for apt-cache || apt-file || dpkg -L || whatever to get information). Kickstart is nicer in many ways than preseed. Sure, the costs of swapping all of that are non-trivial both in the time investment for administrators to rewrite tooling and for the marginal loss in productivity until they re-learn tooling.
Going forward, container-first distros are getting the brunt of new deployments, which is exactly why RHEL isn't a growing revenue stream for Red Hat anymore, and why it doesn't make sense to keep pouring money into CentOS.
Red Hat is focused on OpenShift/OKD as the new "platform". Containers have their place, and it isn't everywhere for lowly end-users, but RH didn't drop CentOS to fuck over the community. They reduced support for the community because RHEL (and CentOS) are increasingly irrelevant to a company which has put their eggs in the CoreOS+Openshift basket as their future. That isn't specific to them.
All of the major vendors see the writing on the wall. What's better than making your systems easy to manage? Making it so they don't need management at all. Do everything in k8s and update a single system image quarterly (or whatever), and leave traditional workflows as an afterthought. Red Hat is lucky enough to already have RHEL, but if I were starting a new for-profit Linux company in 2020, I'd do exactly what CoreOS did or Rancher does.
That's exactly what they don't. You're the one who innocuous altered that to "without support and updates" which you know very well makes all the difference. If CentOS had the same non-update schedule as developer-RHEL, approximately nobody would use it in production. Contrawise, if RHEL did provide timely yum/dnf updates (and remove the murky "Development Use" clause), everyone would run that instead of CentOS. So now you're telling me to stop moving the goalposts back after you moved them to another field?
> You aren't required to register it in any way, including downloading.
Maybe I'm a bit dense, but I clicked on every download link on your page and they all led me to "Log in to your Red Hat account". Maybe you can post a direct URL to the ISOs?
> You want a free "product". That isn't their business model. At least they make the sources for everything available, which took Canonical years for Landscape.
No, I don't want a free product. I was stating from the first post that Red Hat Inc don't want people to have that. Which I'm completely fine with and fully support. You seem to be in complete agreement, so I don't know why you bothered with some quasi-rebuttal in the form of freebie Developer RHEL link which is very different from the CentOS/Rocky proposition.
> [details about the build process]
Ok, maybe the debranding part is not a big deal, I don't know. But my point only rests on the process being labour-intensive, hence expensive. Which I don't know you're disputing or agreeing with. If a CentOS rebuild is necessarily labour-intensive, I don't see a bright future for Rocky or similar projects. I think it is, since AFAICT almost every clone except Oracle gave up trying to keep up with RHEL 8. It's hard to prove things either way, but we'll find out soon enough if we follow the Rocky project.
> You inverted this argument and you're asking the wrong questions. The question isn't "why aren't people moving off CentOS?", it's "why did they use CentOS in the first place?" It's because they were already familiar with RHEL from previous jobs,
So inertia / legacy / switching costs, we're exactly in agreement.
> and wanted familiar tooling (apt may be nicer than yum was, but dpkg is a dumpster fire for package maintainers compared to RPM, and RPM's tooling is much more cohesive than digging around in 10 different manpages for apt-cache || apt-file || dpkg -L || whatever to get information). Kickstart is nicer in many ways than preseed. Sure, the costs of swapping all of that are non-trivial both in the time investment for administrators to rewrite tooling and for the marginal loss in productivity until they re-learn tooling.
Now this is a completely different argument, that the RHEL/CentOS tooling are intrinsically superior to Debian/Ubuntu's. I'm pretty skeptical, since it implies that organizations who do run Debian/Ubuntu could save a lot by switching to CentOS and a bit of retraining. But this is of course not a dispute that's going to be settled in a thread like this, so let's leave it at that.
> [something about containers, OpenShift, K8s, divining Red Hat's Grand Strategy]
This does not seem on topic, so no comment.
Maybe I just expressed myself badly, so let my try again. I predict that Rocky Linux will not be a big success, and don't think doing a free-beer RHEL clone (CentOS as most users understood it) is a worthwhile endeavor, despite a seemingly large audience. Yes, giving good stuff away for free is popular (and I do believe RHEL is a good product). Because they're largely dependent on RH, who 1) appear not very enthusiastic about the idea of people running RHEL for free even without support, 2) can largely determine how expensive running a clone project will be. That's why IMO it's better to analyze if users really need a strict RHEL clone, or if what they want from it (xLTS, better tooling, commercial software compatibility, whatever) could be better developed on top of Debian, whose incentives seem to class less. People who really really need a RHEL clone: time to pay up or go with the Stream (it probably really not-so-bad).
Now unlike you I have zero inside knowledge or experience, so maybe I'm just talking out of my ass. But I am willing to make a somewhat falsifiable prediction, that Rocky and similar clone projects don't have much chance of success. Maybe I'm all wrong and Rocky can with a handful of volunteers and some clever scripts, resurrect CentOS-as-people-understood-it. Or maybe some deep-pocket 3rd party with a better brand than Oracle will step up. We'll find out a year or so.
> Now unlike you I have zero inside knowledge or experience, so maybe I'm just talking out of my ass. But I am willing to make a somewhat falsifiable prediction, that Rocky and similar clone projects don't have much chance of success. Maybe I'm all wrong and Rocky can with a handful of volunteers and some clever scripts, resurrect CentOS-as-people-understood-it. Or maybe some deep-pocket 3rd party with a better brand than Oracle will step up. We'll find out a year or so.
So, let's try this. I agree that Rocky will not be a big success, but completely because I don't think there's a major market demand for a RHEL clone in 2020. New deployments will end up being a container Linux distro with deployments inside VMs or containers. (RH)EL8 is relatively new with low-ish adoption. We still had customers on EL6 six months ago when I left. Institutional customers aren't likely to move to EL8 until EL7 is nearing the end of phase 3 support, since the costs involved in reworking their applications to work (and their build/config management toolchain to work with modularity+etc. This has nothing to do with Red Hat's stance, which was (for the 7.5 years I was there, and still, from everyone I know who's still there) very overtly pro-upstream.
Users don't need a strict RHEL clone. They need a life raft until they can move to containers. It's not worth re-training administrators how to use some other package ecosystem. Rocky will fail, but for these reasons
I would love to see this too, but backporting security patches is not the kind of “sexy” programming we can motivate programmers to do “for fun and for free”, especially when we tell them to do it for X number of years without having a paycheck to motivate them.
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.
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.
Red Hat is overly protective of their trademarks, and this includes CentOS, Fedora, CoreOS etc
If you had been around in the late 90s, their lip service was that they were far more than just "providing sources to everybody" (as if that's some feat), and far more about the spirit of GPL and the triumph of FOSS than what the GPL letter requires...
Of course that was lip service, like Google's "Don't be Evil", but don't go around pretending Red Hat is some benevolent "above and beyond GPL" entity...
If half the userland is not available as source (patch and packaging included), a CentOS-like project would not be possible.
Effectively, if RedHat/IBM wanted, there are a lot of dick moves which could effectively kill Rocky.
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?
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.
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?
nah, it's not missing. Red Hat bought the project and more importantly the trademark, domains etc.
And it was mostly fine.
Then IBM bought Red Hat and things went south.
CentOS did not fail, CentOS was killed. It's different.
I think IBM had nothing to do with this one. People think Red Hat won't do anything like this. However, there exists a part of Red Hat which is capable of doing this. That part of Red Hat usually stays behind the scenes and comes to the fore to announce that a decision has been made and the developers (hired within Red Hat as well as the general community) who are involved in the day to day running of the projects will have no say. Plus they will throw in some confusion (like the limited use license that is in the works but not yet ready for CentOS use) around the future of the project being killed just to let the community expect something good to come out of this exercise. This is not new. They did the exact same thing to the JBoss community application server[1].
It did not fail. It succeeded too well! It was impacting RH’s bottom line, so they killed it.
How accurate that is, I don't know.
Other RHEL-compatible distros offer it, I believe.
More likely there'll be a simple script to swap from CentOS (or RHEL) to Rocky.. Or they could have a "rocky-release" package with `Obsoletes: centos-release, redhat-release` and a `yum install https://rockylinux.org/rocky-release-8.2-1.noarch.rpm ; yum upgrade` is all that'd be required to swap...
TL;DR: should be very easy, but there's minor variations in methods that I doubt are finalized.
[0] https://nts.strzibny.name/migrating-centos-to-oracle-linux/
I would think that rebranding CentOS as Rocky is a rather trivial process of replatforming all the codebase and replacing any “Centos” with “Rocky”.
I mean, if you think about it, all that's really needed is for a "s/CentOS/Rocky/g" over all of the repositories. Then, the other 99% of the project is just waiting for the packages to rebuild and get sync'd on all of the mirrors that they could just will into existence with their minds.
Really, though, let's be honest here: If they weren't spending so much time writing up press releases and commenting on issues on GitHub, they probably could've already basically been done, the new package repositories could've been published and mirrored, and half of the CentOS 8 boxes out there could've already been migrated over.
<sigh>
--
EDIT: To be clear, I am not serious. I thought the question I was replying to was completely f##king absurd but chose to respond with sarcasm (it seemed less likely to result in a warning from @dang than my initial reply).
You would also need I said if infrastructure servers that can scale to a large number of users for Yum/RPMs, etc.
Then you also need a set of servers for issue tracking and a way to break it out per package.
I wouldn't imagine that it is anything which can't be done, it just seems like there's a lot of little pieces that you would need to set up, and infrastructure you need to run.
Not saying all of the above is trivial but I'd think the code to do it literally exists and is itself open source.
In short, forking it is easy, but keep it attractive is not.
Btw: it doesn't seem to have been ported to RHEL 8 (?).
"This project was started long before CentOS or other projects were available."
I bet the have calculated that their work maintaining this is rather simple and well-worth it, or they would have changed over to CentOS a long time ago.
> The CentOS Marks are trademarks of Red Hat, Inc. (“Red Hat”).
Most servers that distribute current binary RPMs are mirrors operated by third parties. You can be reasonably certain that servers like www.centos.org, mirror.centos.org, vault.centos.org, or buildlogs.centos.org are paid for by Red Hat. Their IPs are mostly AWS.
https://www.redhat.com/ja/about/press-releases/red-hat-and-c...
Wow, I haven't been following this very closely - but isn't that Fedora they're describing? At least... traditionally...
Fedora was upstream, RHEL was stabalized in the middle, and CentOS was downstream - regarding patch releases and features, etc.
Is Fedora going away too?
I am not sure if this is still the case, but Redhat used to require 100% of its employees to use RHEL Workstation as the desktop.
Nope.
- Fedora is cutting edge/desktop.
- CentOS Stream is testing/RC area for RHEL patches.
- RHEL is the stable server for enterprise.
No more than 'current' rhel is testing for centos patches.
"Everything that goes into Stream is approved for a minor release in RHEL."
Source is here: https://news.ycombinator.com/item?id=25360352
Also it's interesting that some people defined Rocky as being 'unstable' when others read it as being 'solid as a rock'.
That has to be disappointing for the people who adopted CentOS for its stability and long-term support.
That said, I think the FAQ is missing an answer for a critical question: What ultimately drove CentOS to its regrettable fate and what will Rocky Linux do to avoid a similar misfortune?
One of the things that YC is always talking about is that founders looking for ideas should look to identify situations where most people think it’s going to turn out one way, but most people are wrong and it’s actually going to turn out another way. In the context of the late 90s, where virtually all software was proprietary, they bet on open source software and support plans, and made a sustainable company on it. They contributed to open source so that they would have the expertise, gave all the software away for free, and then sold the expertise through support plans.
And then the business people came along and they’re showing a deep misunderstanding of why Redhat was able to sell support plans in the first place. People on RHEL are going to stay on RHEL, but people on CentOS — the market of people who are not paying customers but could theoretically become customers, are almost certainly going to go to Canonical. This will kill Redhat.
1. Claim "IBM has no influence, this was all our own independent action, honest, believe use guys....
2. Red Hat employees instance that "CentOS 8 was never officially supported until 2029 so we did not go back on anything"
if people believe either of those I really need to get in real estate and start selling bridges
The thing though is that RedHat is responsible for that impression. Every previous version of CentOS before 8 has been supported until the upstream RHEL pulled the plug. CentOS’s official page said it would be supported until 2029 ( https://archive.is/7Qmtw ).
A reasonable person would infer that CentOS (now controlled by RedHat, so, yes, RedHat) made the same promise that they made (and kept) with every previous version of CentOS: That it would be supported for 7-10 years. Not just over 2 years.
I definitely inferred a decade of support. If I would had known that CentOS 8 would be cut off at the end of 2021 this summer, I would not had installed it. I would had installed Ubuntu 20.04 LTS.
Indeed, replacing my CentOS 8 installs with Ubuntu 20.04 is exactly what I have been spending all last week doing.
I'm fine with them getting more profit, as long as they stop ripping up the desktop.
Ubuntu’s big thing back in 2004 was that it was a well-heeled founder (and company), coming in to actually put time and money into the desktop experience on Linux in an opinionated way (obv. not everyone agrees with those opinions, but I would argue that being as opinionated as commercial/proprietary software was Ubuntu’s biggest strength in the beginning). Over the last 16 years, nearly all of the big bets on desktop development have failed. Ubuntu One (the cloud personal cloud service)? Failed (though in retrospect it was a really good idea. Too bad users didn’t pay.). Ubuntu Software Center? Failed and discontinued. Unity? Failed and discontinued. Ubuntu Phone/Touch (and Canonical had invested massively into mobile)? Failed and given to the community. Mir? Failed, probably for good reasons, but failed.
Where has Canonical made money? Enterprise and in the cloud.
I totally understand the attraction to Linux on the desktop, but every company that has approached it in a way that is focused on end-users and not the enterprise in a way that isn’t either volunteer driven or as a very small company has failed to make it any money off of it. I imagine Canonical will continue to deemphasize the desktop even more as time goes on.
Canonical made it easy to recommend linux as a desktop, but then have made it harder as time goes on, with controversies like Snap and the Amazon fiasco. I'm glad for what they have done, and wish them luck in the server space.
There are others who are now better positioned to pick up where Canonical left off on the desktop. ElementaryOS, Pop!_OS, Zorin, all of these are amazing projects that have picked up and pushed forward from where Canonical left.
Again, that isn’t a criticism — I’m friends with some members of the elementary team and absolutely love what they do — truly. But none of those projects can make the type of investment that Canonical did or that the other big Linux vendors who have all but abandoned the desktop (SuSE/Novell, Red Hat) did, or even now-bankrupt/sold for pennies to PE companies did (Mandriva (née Mandrake), Corel, Linspire (remember those crooks!)) or that some promised to do, but later abandoned (Steam).
Maybe that’s OK. Maybe the number of Linux desktop users is content with work being done and sustained largely by community volunteers or very small companies. But as good as the work many of those groups do is, I do think the lack of a Canonical type of company does hurt the whole ecosystems ability to grow, innovate, and reliably attract new users. On a personal level, I think that everyone should give up the pretense of Linux on the desktop ever evolving beyond an extremely niche thing, and be content that the Linux kernel is at least the basis for stuff like ChromeOS and Android (which while absolutely not Linux on the desktop or on mobile, are at least major desktop platforms), but that’s just me.
Deepin is interesting because it has a strong source of funding and developers/partners and has made really great moves on the UI front and it’s partnerships with ZTE and Huawei (Huawei even ships Deepin on many of its machines now). My personal concern with Deepin is the security and privacy with it — and I have those same concerns for any state-sponsored version of Linux or any operating system to be honest. Deepin is also very insular in its development (far more than even Ubuntu), and that might just be necessary to achieve the sort of polish it has, but that distinct lack of community could be a turn-off to many.
What I’m saying is, I don’t necessarily disagree with your assertion that Canonical should pull out from the desktop even more, but I think a lot of people underestimate just how big of a void that will leave in the desktop space and as good as those projects you mentioned are, I don’t think any of them individually or collectively can fill it. Especially financially.
And if that applies to you, that's plenty of time for Rocky Linux to get rolling. Just a thought.
I put together what we actually know about the CentOS -> Stream migration so far[0]. I personally might give stream a chance although if Rocky is released, I imagine it a no-brainer.
[0] https://nts.strzibny.name/migrating-centos-to-centos-stream-...
The most common argument (Oracle is evil and litigious. Therefore, using Oracle Linux will result in me being sued) honestly seems like FUD.
All RHEL downstream distributions rebuild the same SRPMs that RHEL provides. Doing a quick comparison over some common packages (kernel, httpd, openssl, etc.) between CentOS 8.3 (https://vault.centos.org/8.3.2011/BaseOS/Source/SPackages/) Oracle Linux 8.3 (https://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x8...) shows that they are indeed byte identical (with the exception of certain spec files including debranding patches).
What is the value of having a separate RHEL derivative? It isn't as if the "community" can propose/submit any changes, since any changes will cease to make the downstream distribution a "bug for bug" compatible RHEL derivative. If I actually wanted to participate in the larger RHEL-derivative community, I would need to actually submit my changes to the CentOS stream project.
1. On an entitled system, enable the source repos and download the packages.
2. In your account online, you can download the SRPMs for individual packages.
3. In your account online you can download a minor version release iso of the SRPMs.
4. You can use https://git.centos.org to clone the actual RPM patches/spec files, and use the get_source.sh script from the centos-git-common repo to pull the package source tarballs from dist-git (useful for projects like the kernel that don’t use actual upstream as their source).
With CentOS stream (particularly C9S that will be launching mid 2021) and the switch over to GitLab which will happen in the future, everything will be out in the open in git form.
Because there's a whole ecosystem (HPC and Scientific computing to be exact) which depends on CentOS (not RHEL, not Oracle, not Ubuntu, not Debian) primarily. A CentOS compatible distribution is not some FOSS pride thing.
IBM and RH really blew a sucker punch in this regard.
CentOS carries a legacy from Scientific Linux (which was RH compatible too) and has a lot of software packages developed for/on it. It might be a regular .tar.gz or RPM distribution but, they're validated and certified on CentOS. This is enough. Some middlewares used in collaborative projects (intentionally or unintentionally) search for CentOS signature. Otherwise installations fail spectacularly (or annoyingly, it depends).
I have to run my own application on every platform with a relatively simple test suite which checks results with 32 significant digit ground truth values. If these tests fail for a reason, then I can't trust my application's results for a particular problem. My code runs fast and it's relatively simple (since it's young). Some software packages' tests can run for days. It's not feasible to re-validate a software every time after compilation on a different set of libraries, etc. CentOS provides this foundation for free.
I think I understand a little better your point of view. CentOS became so important for the HPC community that most software is now validated against it. So even if RHEL itself were to become free (as in beer), people won't switch to it (or at least be reluctant).
My all personal systems are Debian, however when I install something research related, it's always CentOS. There's no question. I even manage a couple of research servers at my former university. They're CentOS as well.
Moreover service (web, git, documentation, etc.) servers are CentOS too to keep systems uniform even if there's no requirement. So it powers the whole ecosystem, not the compute foundation. That's a big iceberg.
Christ; it's either the 90s or kindergarten..
There is a movement to incorporate technologies like Singularity into the HPC workflow but for established projects, it often looks like a lot of bikeshedding for negative results compared to just running the code on bare metal.
Your users don't see the nodes. They submit jobs and wait for their turn in the cluster. A sophisticated resource planner / job scheduler tries to empty the queue while optimizing job placement so the system usage can be maximized as much as possible.
Also, users' jobs work in under their own users. You need to isolate them. Giving them access to docker or any root level container engine is completely removing UNIX user security and isolation model and running in Windows95 mode. This also compromises system security since everyone is practically root at that point. Singularity is user-mode and its usage is increasing but then comes the next point.
Performance and hardware access is critical in HPC. GPU and special HBAs like Infiniband requires direct access from processes to run at their maximum performance or work at all. GPU access is much more important than containerizing workloads. Docker GPU is here because nVidia wanted to containerize AI workloads on DGX/HGX systems. These technologies are maturing on HPC now.
In performance front, consider the following: If main loop of your computation loses a second due to these abstractions, considering this loops run thousand times per core on many nodes, lost productivity is eye-watering. My simple application computes 1.7 million integrations per second per core. So, for working on long problems, increasing this number is critical.
Last but not the least, some of the applications run on these systems are developed for 20 years now. So, these applications are not some simple code bases which are extremely tidy and neat. You can't know/guess how these applications behave before running them inside a container. As I've said, you need to be able to trust what you have too. So, we scientists and HPC administrators tend to walk slowly but surely.
Doing my job properly on the HPC side means my cluster works with utmost efficiency and bulletproof user isolation so people can trust the validity of their results and integrity of their privacy. Doing my job properly on the development side means that my code builds with minimum effort and with maximum performance on systems I support. HPC software is not a single service which works like a normal container workload. We need to evolve our software to run with minimum problems with containers and containers should evolve to accommodate our workloads, workflows and meet our other needs.
The cutting edge technology doesn't solve every problem with same elegance. Also we're not a set of lazy academics or sysadmins just because our systems work more traditionally.
Because you want what CentOS was and this is basically going to be what CentOS was. Different name, different people, but same prinicple.
Devil's response: nobody cares if you do. A lot of people know why they want it; the answer will in many cases be that it will fill the same niche and not be controlled by a shitty company. (If you think calling Oracle shitty is FUD, unprofessional or similar, that's fine: see 'Devil's response', above.)
It will stand or fall on its own, as a result of many different peoples' choices. For now, it is enough that something is growing in the niche from which Centos was uprooted.
What I've seen is "Oracle is evil", "don't trust Oracle", and something like "my prior history around Oracle has left such a lasting bad taste that I throw up a little in my mouth every time I touch something with Oracle in it, so I'd rather do almost anything but use something from Oracle, since using it on the daily would inevitably lead to permanent esophagus damage."
I mean... Oracle buying up MySQL was enough for MariaDB to be created and move to being the default. (well, and some of what Oracle did right afterwards).
It's a bit like if I'm in a party, and I briskly walk up to five people and each time I hit them in the face, and then it's your turn and you move away, and I say "what? the idea that I would hit you is FUD".
It's not FUD. It's a pattern of behaviour.
Avoiding overly litigious companies - where other as-good or better choices exist - is not overly cautious, it's just good sense. Where other as-good choices do not exist, it seems perfectly reasonable (depending on your risk profile) to work with others to create the better choice.
Of course, I say all this as someone who has worked in massive multinational corporations and now work in small startups. I'm now likely never going to use Rocky Linux for exactly the reason you've hinted to - in effect, it is not a usecase either of us care about. But for those people who do need this, I'm very happy that someone has championed the cause.
Besides isn't that pretty much the exemplar of FUD?
On the other hand, maybe Ubuntu is providing something special that Debian can't do - then it may make sense to go with Ubuntu and maybe even swallow Microsoft's fishing hook if it comes.
This is not the first time I've seen this prediction. What is its basis?
In fact I’ll go a step further and say Windows and macOS got this right, in that third party developers should do the work to “package” their apps.
It would be insane for Microsoft to maintain packages for every piece of software that ships on Windows, but somehow that’s the situation we’re in with Linux.
Hopefully Snap or Flatpak changes this!
And this is why installing ex. Filezilla on Linux is safe and easy, and doing the same on Windows is neither.
CentOS 8 was released few days ago with kernel 4.18, which not even LTS is, and is older than the current Debian stable kernel(!).
If you need to install anything besides the base distro you need elrepo, epel, etc which I'm not sure can be counted as part of the support.
I always wonder how many major vulnerabilities are introduced into these super old distros due to backporting bugs.
[1]: https://old.reddit.com/r/netsec/comments/ch86o6/vlc_security...
Software are always gonna have bugs, it's written by humans after all. The important thing is to acknowledge and work towards an ideal outcome.
It also helps that Red Hat employs a lot of core developers for those fast moving packages. :)
Plus, there are changes (especially around memory management or scheduling) that are fiendishly hard to do regression testing on, so they are backported more selectively.
If your use case doesn't consider avoiding noncritical behaviour changes for a decade to be a feature, you have other options.
People that run CentOS in prod are normally running ERP systems, Databases, LoB Apps, etc, and the only thing we need is the base distro and the the vendor binaries for what ever is service/app that needs to be installed, and probably an old ass version is JDK...
We need every bit of that 10 year life cycle, and we glad that we will probably only have to rebuild these systems 2 or 3 times in our career before we pass the torch to the next unlucky SOB that has to support an application that was written before we were born...
that is CentOS Administration ;)
This means that RHEL 7 using a "kernel version" from 2014 will still work fine with modern hardware for which drivers didn't even exist in 2014.
And for the same reasons that the affected users chose a "stable" and "supported" distro they were also unable to upgrade to one where the issue was fixed.
They bought some fancy new computers at work. Our procedures say to use CentOS 7, so we tried it, it ran like shit. Then we reinstalled CentOS 8, same. It worked, but the desktop was extremely slow. After much hair pulling I found the solution: add the elrepo-kernel repository, and update to kernel 5.x
No amount of backporting magic will make an old kernel work like a new kernel.
I would say a better reason is that while both are Linux distributions, they are distinct dialects and ecosystems. It isn't impossible to switch, but for institutions that have complex infrastructure built around the RHEL world, it is a lot of work to convert.
The main reason people choose Linux is due to its stability.
It is totally ok to run servers in 2020.
Also your statement seems the default cloud vendor lingo used to push people to adopt proprietary technology with high vendor lock-in.
Not everything can be highly ephemeral or a managed service, so running servers yourself is totally okay like you said.
But I agree I also get the tone of "servers should be cattle and not pets, just kill them and build a new one". Which can also be done on bare metal if you're using vms/containers. It seems like most people forget these cloud servers need to run on bare metal.
We have about 40. The oldest is around 17 years old. Our newest server is 9 years old. Our average server age is probably around 13 years old.
The most common failure that completely takes them out of commission is a popped capacitor on the motherboard. Never had it happen before the 10 year mark.
Never had memory failure. Have had disk failures, but those are easy to replace. Had one power supply failure, but it was a faulty batch and happened within 2 years of the server's life.
Also, most of my experience is with rented dedicated servers and they just give me a new one completely so I never really see if they're fully scrapped.
That's mental.
Ideally you'd never upgrade your software in the usual way. You'd simply deploy the new version with automated tooling and tear down the older.
Do you have any idea how much effort it is to change everything over to "treating your servers as disposable"?! It's going to eat up a third (to half) of my "fun time" budget for the foreseeable future!
Also, "running a server for ten years" does not need to mean that it has ten years of uptime. I think that wasn't meant.
If it is connected to the Internet, then I guess the kernel needs to be hot-patched need to be applied to avoid security issues.
Were hot kernel patches available ten years ago? I remember some company who did this (for Linux), and it was quite a while back, so it's possible. But I doubt it was mainstream.
I recall long ago that SunOS boxes had to be rebooted for kernel patches.
I don't remember about Solaris.
I'm not familiar with other Unices.
the 'usual way' is automated tooling
Consider an appliance that will be shipped to a literal cave for some mining operation. Do you want to build that on something that you would have to keep refreshing every year, so that every appliance you ship ends up running on a different foundation?
This.
A decade ago I was technical co-founder of a company [0] that made interactive photo booths and I chose CentOS for the OS.
There are some out in the wild still working and powered on 24/7 and not a peep from any of them.
We only ever did a few manual updates early on - after determining that the spotty, expensive cellular wasn't worth wasting on non-security updates - so most of them are running whatever version was out ten years ago.
Rock solid.
[0] https://sooh.com
You either need to upgrade or unplug (from the internet).
There are still places out there that are running WindowsNT or DOS even. Because they have applications which simply won't run anywhere else or need to talk to ancient hardware that runs over a parallel port or some weird crap like that. These machines will literally run forever, but you wouldn't connect it to the internet. Your hypothetical cave device would be the same.
Upgrading your OS always carries risk. Whether it's a single yum command or copying your entire app to a new OS.
Besides, if you're on CentOS 8 then wouldn't you also be looking at Docker or something? Isn't this a solved problem?
Why Docker has anything to do with this discussion?
How would I run our SAP ERP apps/databases without "running servers that long"?
And while it may be cumbersome or cause some downtime or headaches if that isn't the case, I find the very need of doing it once every 1-3 years forces your hand to get your shit together, rather than a once per decade affair of praying you migrated all your scripts manually and that everything will work, as your OS admins threaten your life because audit is threatening theirs.
That said, if you're really in the position of depending on a free project for over five years of security support, you probably will be totally fine with just ignoring the fact it's out of support. Just keep running Debian 6 for a decade, whatever. The code still runs. Pretend you've patched. Sure, there are probably some vulnerabilities, but you haven't actually looked to see if the project you're actually using right now has patched all the known vulnerabilities, have you?
(Spoiler, it hasn't: https://arxiv.org/abs/0904.4058)
And there is even commercial support for Extended LTS now [2]
Also, it's worth noticing that Debian provides security backports for a significantly larger set of packages and CPU architectures than other distributions.
> Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.
> Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.
> Thus the Debian LTS team takes over security maintenance of the various releases once the Debian Security team stops its work.
Centos was the rational other free choice, not that Red Hat hasn't made other equally strange decisions.
Sometimes I think we'd be better off rolling our own, like Amazon does.
Server side isn't open, and Canocial repeatedly claims wide industry support ... despite not having it.
I recommend the first step in any Ubuntu system you use is to disable snap. Use something portable like flatpak that does at least have some support, is open source, and seems to have a healthy eco system.
There is a large world of proprietary enterprise software that is tested, developed, and supported solely on RHEL. CentOS (and theoretically, Rocky Linux) can run these applications because they are essentially a reskin of RHEL. Debian and Ubuntu LTS cannot (or at least not in a supported state) because they are not RHEL.
The branding stuff was a plus to the sys-admins and Linux die hards.
We used CentOS as dev environments, and RHEL as production. It gave us the best of both worlds; an unsupported but compatible and stable dev environment we could bring up and throw away as much as we wanted _Without_ licensing BS. And when the devs were happy with it, the move of a project to RHEL was easy and uneventful.
And don't even get me started on the 'free' dev version of RHEL. It's a PITA to use, we've tried. It's also why we've halted our RH purchasing for the moment. Sure, it's caused our RHEL reps no end of consternation and stress but too bad. I've been honest with them, and told them that they are probably lying through their teeth (without knowing it) when they parrot the line that RH will have some magic answer for "expanded" and/or "reduced cost" Streams usage in "1st half of 21". That trust died when RH management axed CentOS8 like they did.
When I worked for a hardware vendor we had customers who ran hundreds of CentOS boxes in dev/test alongside their production RHEL boxes. If there was an issue with a driver, we simply asked that they reproduce it on RHEL (which was easy to do). If they had been running debian or ubuntu LTS the answer would have been: I suggest you reach out the development mailing list and seek out support there.
Whether you like it or not, most hardware vendors want/require you to have an enterprise support contract on your OS in order to help with driver issues.
I'm not familiar with Debian, do they have same infrastructure and documentation quality as RHEL? For example do they have anything like Koji [1] for easy automated package building?
This is something I don't think the wider community understands, nor do they understand the incredible amount of work it takes to back-port major kernel/etc features while maintaining a stable kernel ABI as well as userspace ABI. Every single other distribution stops providing feature updates within a year or two. So LTS, really means "old with a few security updates" while RHEL means, will run efficiently on your hardware (including newer than the distro) with the same binary drivers and packages from 3rd party sources for the entire lifespan.
AKA, its more a windows model than a traditional linux distro in that it allows hardware vendors to ship binary drivers, and software vendors to ship binary packages. That is a huge part of why its the most commonly supported distro for engineering tool chains, and a long list of other commercial hardware and software.
I think the gap is the question of how many people there are who want enterprise-style lifetimes but don't actually want support. If you're running servers which don't need a paid support contract, upgrading Debian every 5 years is hardly a significant burden (and balanced by not having to routinely backport packages). There's some benefit to, say, being able to develop skills an employer is looking for but that's not a huge pool of users.
I think this is the reason behind the present situation: CentOS' main appeal was to people who don't want to pay for RHEL, and not enough of those people contribute to support a community. That lead to the sale to Red Hat in the first place and it's unclear to me that anyone else could be more successful with the same pitch.
But lifetimes are support. Support isn't just, or even primarily, about making a phone call and saying "Help, it's broken." After all, there's nothing keeping someone from taking a snapshot of a codebase and running it unchanged for 10 years. Probably not a good idea if you're connected to the network, but certainly possible.
I'm not sure there are enough people left who have the “don't touch it for a decade” mindset, aren't working in a business environment where they're buying RHEL/SuSE/Amazon Linux/etc. anyway, and are actually going to contribute to the community. 100% of the people I know who used it were doing so because they needed to support RHEL systems but wanted to avoid paying for licenses on every server and they weren't exactly jumping to help the upstream.
Red Hat bought CentOS in the first place because they were having trouble attracting volunteer labor and I think that any successor needs to have a good story for why the same dynamic won't repeat a second time.
I think there are two primary reasons.
1.) A developer wants to develop/test against an x.y release that only changes minimally (major bug and security fixes) for an extended period of time.
2.) The point release model where you can decide when/if to install upgrades is just "how we've always done things" and a lot of people just aren't comfortable with changing that (even if they effectively already have with any software in public clouds or SaaS).
I largely agree with your other points.
Re: point 1, I'm definitely aware of that need but the only cases I see it are commercial settings where people have contractual obligations for either software they're shipping or for supported software they've licensed. In those cases, I question whether saving the equivalent of one billable hour per year is worth not being able to say “We test on exactly the same OS it runs on”.
Most developers use Ubuntu in their laptops. Virtualized on Windows, but Ubuntu nonetheless.
What is the vision for Rocky Linux?
A solid, stable, and transparent alternative for production environments, developed by the community for the community.
Although I'll be inclined to think of it as series of movies. Perhaps even split wood before installing Rocky 5?
"Thinking back to early CentOS days... My cofounder was Rocky McGaugh. He is no longer with us, so as a H/T to him, who never got to see the success that CentOS came to be, I introduce to you...Rocky Linux"Is always good to have diversity and a community driven project.
Edit: actually Rocky was the flying squirrel.
Hmm, to me, "rock" has connotations of "solid", but that ending "y" changes the the connotations completely - "rocky" makes me think of uncertainty, risk and peril.
Seriously though, I am very happy about the name and its creation.
If you don’t like the name, launch your own CentOS replacement. There’s no better time than now. If there’s one thing this project does not need right now, it’s armchair marketing experts.
If you do care about a viable CentOS replacement, do something. Contribute code, money or expertise. The last thing any new and vulnerable project needs is another “idea guy” or a new logo.
(It’s not ancient. I made it up. But it’s sadly true.)
This is the reason why many excellent projects remain obscure while marketing-driven products become famous... and often take credit for other people's ideas.
After a while, it's hard to refrain from telling people to just screw off.
edit: Personally, I've been a heavy user and supporter of CentOS but I've almost never referred to it as CentOS. Because the point is to be binary compatible with RHEL, and it's then naturally almost the same thing as Oracle Linux and Scientific Linux, etc. So I would simply refer to "EL5" or "EL6" in code or other places. This probably won't be any different.
It's all grounded human nature I'm sure, but man it is terrible.
We all are frustrated by that behavior ourselves, why do it to other people?
Bikeshedding-type comments come to dominate conversations because they take less time and effort to compose and express, and therefore tend to get in ahead of and (especially in a synchronous communication medium) crowd out more substantive contributions. While the expertise and temperament of the individual conversation participants may be contributing factors, the dominant one is simply the size of the group.
I was reading some discussion where someone was writing some part of a website for a product. They chose a framework and the whole thing was spammed with 'why does it have to be x' type contributions. No help, no technical discussion, just these empty one off sentiments spewed at the person who has to actually do the thing. It was just sad.
My second thought was Rocky Balboa... but I figured that probably wasn't right.
Or with Rocky Road[0]. Tasty, tasty Rocky Road.
I mean, it’s Linux.
The good news? Debian's still going strong.
(Debian is actually a portmanteau of Deb(ra) + Ian...)
I'm confused why everyone is complaining about the "Rocky" part, which is a nice tribute and sounds pretty decent, when the actual problem is the "Linux" part. It should really be called "Rocky GNU/Linux", or "Rocky GNU+Linux", because the Linux kernel is only one component of a complete GNU-based operating system compatible with the POSIX standard.
It's called Linux because GNU is awful at naming things. The name "Gahnoo" is too awkward to pronounce and "Gahnoo plus Linux" is too long.
People shorten names for convenience. Deal with it or come up with a better name than GNU.
Without any experience myself (beyond some kernel build maybe 10 years ago), I gathered (from https://wiki.centos.org/About/Building_8) that the majority of work involves manually de-branding the RHEL sources. This apparently can't be automated, as it requires human judgement in which packages/files de-branding is required and in which it might actually break something.
Between major version jumps, e.g. from RHEL/CentOS 7->8 there's apparently also lots of work in getting the build environment up to date.
This raises numerous interesting questions, such as:
1. Where do the upstream RHEL sources live? CentOS sources are in https://vault.centos.org/8.3.2011/BaseOS/Source/SPackages/, but where do they get them upstream? I believe they're only available to RHEL subscribers, does this give RH a way to block clones?
2. Where / what are CentOS's actual build scripts / tools? Is there some howto or writeup how to make a CentOS iso (or cloud-image) on my own PC after downloading the source tree?
3. Do CentOS devs go through the entire manual de-branding exercise with every minor/major update? Presumably they are using some sort of automation/scripting/diffing somewhere. Are these processes/tools available or documented anywhere?
I hope at some point someone with some actual knowledge about this can chime in.
How'd they used to do it then? I assume they just became a subscriber?
Edit: just thought about it, couldn't they get them from CentOS? Would be pretty funny.
I would have thought that the GPL ensures that the customer can then freely redistribute them, but I've read that companies can still make that option very unattractive through other means (e.g. terminating the customer contract, mingling sources with proprietary stuff and making them hard to disentangle). I don't know if RH is playing such games, but the complete lack of non-gated RHEL7 and 8 source code on the web gives some strong hints.
edit: relevant thread: https://github.com/rocky-linux/rocky/issues/4
I'm actually surprised Red Hat has typically shipped SRPMS in bulk to it's customers. I think it's rare that customers would use them, and the GPL allows Red Hat to be far less accomodating. It allows you to charge for each copy of the source code you convey, it doesn't need to be in such a convenient form, it doesn't need to be available on-demand, it just needs to be available on-request.
Once a customer has it, yes - the GPL allows them to hand it to Rocky Linux and let them run with it. But I think the community has been fortunate so far just to get the distro sources they have in the way they've gotten them.
edit: Perhaps "fortunate" isn't the right word, since Red Hat benefits from the community and owes the community some reciprocation. I'm just saying that legally, if Red Hat wanted to be bigger douche bags, the GPL gives them some space to do so. And I'm glad they haven't fully taken advantage of that before.
Interesting wrinkle in the GPL's written offer option: the offer must be valid for "any third party", not only direct customers. But, it's certainly possible for the included written offer to reference an email address or website that is unique to each paying customer, such that valid request coming from a third party would be traceable to the intermediate paying customer whose support contract would then be canceled by Red Hat.
Does anyone know if Red Hat does this kind of watermarking of the GPL written offers, or if a licensee could share the offer anonymously, leak-style, and not get caught by the support contract people?
And in terms of rebuild ability, RHEL is not a self-hosting distribution. There are missing dependencies and packages that need to be built in order to create a fully serviceable distribution as Red Hat does not ship those packages.
Red Hat publishes it's sources on https://git.centos.org. Those are then used to build CentOS Linux packages.
In the future they'll do their development there, and build CentOS Stream and Red Hat Packages from there.
See also: https://crunchtools.com/before-you-get-mad-about-the-centos-...
> Remember, the source code at git.centos.org is basically read only, downstream code from RHEL. That’s how Red Hat complies with the GPL. Technically we go above and beyond because we are only legally required to provide code to customers, and not required to provide code for BSD/Apache/etc licensed code, only attribution.
Regarding question 2, CentOS has a somewhat custom build system for each major version afaik, for 8 this would be https://koji.mbox.centos.org/koji/
Have you checked if this repo actually works as intended? Because I was wondering if the git repo has RHEL or CentOS sources (or both). So I tried to find out myself instead of just throwing the question out there. It went roughly as follows:
- Let me check the sources of dracut (the RHEL installer) in https://git.centos.org/rpms/dracut. Files: empty, Commits: empty, Forks: empty, Branches and Releases: judging by the names they seem to be CentOS, not RHEL sources. And they're using git.centos.org just as a code dump, not for development. Fair.
- Let's see the actual code.
git clone https://git.centos.org/rpms/dracut.git
Cloning into 'dracut'...
remote: Counting objects: 1673, done.
remote: Compressing objects: 100% (1632/1632), done.
remote: Total 1673 (delta 82), reused 1446 (delta 0)
Receiving objects: 100% (1673/1673), 1.60 MiB | 2.08 MiB/s, done.
Resolving deltas: 100% (82/82), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.
- Back to the web interface, https://git.centos.org/rpms/dracut/tree/c8 Reading .dracut.metadata, I guess the source is in SOURCES/dracut-049.tar.xz. But browsing the directory https://git.centos.org/rpms/dracut/blob/c8/f/SOURCES lists only patches, not the presumed source dracut-049.tar.xz
- Maybe it's under Releases? Let's check imports/c8/dracut-049-95.git20200804.el8 Clicking the source tree gets me back to the SOURCES dir with only patches, not good. Maybe the floppy-save button? https://git.centos.org/rpms/dracut/archive/imports/c8/dracut... -> 404-Not-Found. https://git.centos.org/rpms/dracut/archive/imports/c8/dracut... -> 404-Not-Found.
I'm not a professional dev, maybe I just don't understand. But is there a way to actually see/browse/download the dracut source code from CentOS 8.3 (let alone RHEL 8.3) from git.centos.org?
The build process is documented here: https://wiki.centos.org/action/show/Sources?action=show&redi...
This is the regex used in the watch file for Debian to fetch new upstream tarballs: http://www.kernel.org/pub/linux/utils/boot/dracut/dracut-([\...
For dracut, the spec file defines the source as http://www.kernel.org/pub/linux/utils/boot/dracut/dracut-049...
As if questioning whether a project name is any good suddenly equates to an application to be an "idea guy" or a logo designer.
If you don't like the majority opinion about something as trivial as a name, stop visiting this forum. Does that advice sound familiar? Perhaps it doesn't feel fair for someone to offer you only one of 2 extremes? Hmmmm.
The last thing this forum needs is another open source warrior patronizing everyone for participating here.
1: https://listserv.fnal.gov/scripts/wa.exe?A2=SCIENTIFIC-LINUX...
Happy to help wherever I can.
RHEL requires expensive licenses. CentOS was RHEL without the RedHat branding and without the expensive licensing.
By design, there was a nearly complete overlap between RHEL and CentOS. By "repurposing" CentOS into a "rolling release", RedHat (IBM) has broken the overlap so CentOS (free licensing) no longer competes directly against RHEL (expensive licensing).
Previously, CentOS was a rebuild of RHEL. In between RHEL releases, CentOS was exactly the same as RHEL. When RHEL had a release/fix/backpoint, CentOS trailed until it was rebuilt from the new RHEL source.
The "old" CentOS was exactly the same nearly always (nearly perfect overlap) and the "new" CentOS is exactly the same nearly never (almost no overlap).
This change makes CentOS so much closer to RHEL that it’s weird that people are acting like the opposite is happening.
If the current RHEL release is 7.x then you can think of CentOS Stream as 7.(x+1). You don't have to worry about it suddenly being 8.0. Fedora plays the role of the future RHEL 8.0.
- Fedora does its thing informed by but somewhat independently of RHEL.
- Red Hat chooses a Fedora release to be the base of RHEL, forks it, and starts working on it.
- This eventually becomes RHEL X.
- Red Hat then forks RHEL X to create the RHEL X.0 Beta and eventually the RHEL X.0 release. RHEL X keeps getting work done on it which eventually lead to another fork which creates RHEL X.1 Beta and RHEL X.1.
- After each RHEL X.y is released CentOS starts the process of rebuilding it from the sources and tracking upstream changes.
The new model puts CentOS where RHEL X is and so RHEL X.y are actually forks of CentOS.
This change matters a lot to you if you care a lot about the difference between the minor releases of RHEL because there won't be CentOS 7.1 CentOS 7.3 but just CentOS 7. If you just yum update on CentOS then you probably don't care since by default it will move you up minor versions. You have to try to stay on a specific minor version.
What's nice about this change is that anyone can peel off releases from CentOS the same way Red Hat will do to make RHEL and new features become available when they're ready instead of being batched.
There is also a use case for a production fork of RHEL as well. That's now gone. People who migrated to CentOS 8 because they thought they were getting a decade of support - that's now gone.
So what are you arguing, that the second group somehow doesn't get it?
The part I don’t think people really get is that if your goal was to have a fork of RHEL that was as close as possible to RHEL itself in absolute value that CentOS Stream is much better than CentOS is/was. CentOS always tracked far behind RHEL and now CentOS Stream will track closely in front of RHEL.
And I only recall CentOS significantly trailing RHEL at the major version updates (e.g. 6 and 7). Other updates seem pretty timely, and the major version lag doesn't leave me vulnerable.
I can see this being useful for developers who are building something that needs to be compatible with the next major release of RHEL, but I'm not sure who else it will be useful for.
Unless you're the kind of person who pinned to a specific minor version of CentOS (which isn't the default and not supported for very long) you can use CentOS Stream exactly the same as you currently are and it will be a strict improvement for you. Bugfixes, security updates, and new features will come to you before they're either batched for release in the next minor version of RHEL or back-ported to the current supported releases.
I'm sure they'll try not to break binary compatibility, but as it appears to be somewhat experimental and targeted to developers, breaking updates may occur. Isn't that the point of this distro -- so such testing can take place before updates are rolled into RHEL?
So, fine for a developer workstation, but I don't see how it can be stable enough to use in production.
Security fixes are not coming to CentOS Stream first. That's been in the announcement.
Since branding is so important this really seems like something that should go through focus groups or crowd sources somehow? Maybe a poll on hacker news? Unfortunately, I really think changing the name would be critical to the success of the project. Imagine you are a technical lead and you have to convince your boss to switch from RHEL to Rocky Linux...
Edit: I know the name is in tribute to Rocky McGaugh, but I still think "Rock Solid Linux" "named in tribute to CentOs co-founder Rocky McGaugh" would make the project more successful
That’s the point.
It’s a great tribute to one of the late Cent OS founders, but it comes with unfortunate marketing hurdles.
Also I feel naming it "Rock Solid Linux" would be a bit gaudy or arrogant.
I work on servers used in VFX rendering pipelines and some software will simply refuse to properly run if I don't give it at least a CentOS. And if I do manage to get it running on Debian/Ubuntu, automatically I'm voiding the company's support because I'm using an 'unsupported Linux distribution'.
sux.
And yeah, even though we have the platform agnostic VFX Reference Platform, pretty much everything in this industry revolves around RHEL/CentOS. Except SideFX, they are a golden exception, and explicitly support non-Red Hat family distributions.
- The old CentOS had a brand value, which Rocky Linux has to earn back all over again.
- The old Red Hat was nice to CentOS or at least wasn't particularly hostile. That does not mean IBM will be nice too.
- It may be too short a notice for current CentOS users to wait for Rocky Linux to come through. They may already move away to other alternatives like Debian or Ubuntu or Amazon Linux or whatever fits their use case.
- If because of some miracle, Rocky Linux turns out to be just as successful as CentOS, there is a chance that either Red Hat or a competitor will end up taking control of it too. Corporate sponsorship is too lucrative to decline. So, it will end up with the same fate as CentOS.
Same fate as CentOS, let me think... Can I replace a few system packages to convert it to a binary-compatible, patchable, community-supported distro, just differently branded? Okay, count me in.
Red Hat was not nice to CentOS when it was new.
The "same fate" as CentOS would mean surviving for 16 years.
Now, mature and much more popular alternatives have well established brand value.
CentOS users by nature want to stay on their current systems as long as possible. Many would have still been on CentOS 7. I doubt any will have moved away from CentOS already.
Spending my time fixing problems instead of doing actual work is fun, for a while.
Every damn time I start this one laptop with Linux, trying to get away from Windows 10, there's something to fix.
Oh, the undervolt is not being applied, time to build the whole thing again.
Oh, restart causes it to wank the hard drive indefinitely for some reason.
Oh, shutdown is still not working, glad I got a power button.
Nouveau glitches.
Bluetooth has disconnected and just refuses to work again.
Audio recording is not working again.
Video encoding is not working again.
Video playback is not working again...
And it runs so well in a virtual machine.
Why can't people just band together and create one good Linux distro for the desktop. Rhetorical question, I guess.
While your experiences with the desktop are unfortunate, on most common laptops (cheap and expensive ones) most Linux distros run well, even if some very specific devices have issues with the kernel drivers
I'm not sure where the idea that CentOS is for servers came from.
You don't like my design choices? I'll leave the project and make my own. You end up with lots of talented people reinventing the same thing forever.
This fills a specific need for "enterprise" customers, specifically, being very slow and very stable. It's not supposed to be a consumer OS for doing normal desktop activities on, although there's nothing stopping you from using it as such.
This isn't yet another slightly tweaked fork of Ubuntu or Arch Linux or some such, where maybe that attitude is more deserved.
Different users, different needs. Ubuntu and Archlinux definitely appeal to different people, for example.
One person might also use different distros depending on the intended use of a particular machine.
1. It's a mountain of work and loads of people involved are doing it in their limited spare time.
2. It's even more of a mountain of work because Linux developers have to write all the hardware drivers themselves too. On Windows drivers tend to be written by device manufacturers but that rarely happens on Linux because it's very difficult to write closed source drivers and they have fewer Linux users anyway.
3. A large proportion of Linux users and developers have drunk the Unix kool-aid and think that everything should stay exactly as it was in the 70s. Text based config files, services controlled by Bash scripts, etc. It's pretty much impossible to make a reliable modern system with Bluetooth, WiFi, external displays, hotplugging, etc. with that attitude.
4. Hardware makers only test on Windows so some of the bugs in stuff like suspend are probably hardware bugs that Windows happens not to trigger.
2. See above.
3. I am locked to a Windows desktop for work, but support Centos servers for backups and such. What is wrong with text-based config files? Are GUI checkboxes a better option? They may be more discoverable, but seem to me to be less configurable. Have you read the Unix Haters Handbook? Unix's greatest flaw and greatest strength are its flexibility.
4. I can't speak much to this, but aren't some manufacturers testing on Linux?
Yes.
It is less a standalone distro and more a free version of Red Hat Enterprise Linux.
> Nouveau glitches.
Then why are you using it? As much work as people are putting into nouveau, they have to work more often than not against NVIDIA instead of with. If you want a system that works just use the proprietary driver.
> Why can't people just band together and create one good Linux distro for the desktop.
In this case? commercial interest, people used CentOS in production instead of buying Red Hat Enterprise. So the people in charge decided to make it useless for that. Now we have Rocky to do the same, just with people in charge that are not financially connected to Red Hat.
In terms of DE. More focus and hard work is on building something "cool" than something stable and less buggy. I would have been happy with Gnome if the base OS is stable. Yes KDE turned out to be better, but that was the least important of all cases. Lots of work hours have gone into making XFCE, LXQT, KDE, Gnome, Guix, Cinnamon, XFCE, Mate etc etc. The choice argument is futile if I or someone cannot be productive in it and spends time in linux forums. 100 Choices will never make open source more popular. You just need 1 damn good choice that "just works". Time and energy is precious.
As much as Windows is criticised, you will rarely have any issues with it in terms of hardware compatibility.
Coming to Rocky-Linux, this is server side offering. Plus its model is different to general desktop linux you use for day-to-day.
You never hear anyone install macOS on a Dell and wonder why it isn’t working.
So why are you doing this for Linux?
Lenovo, Dell, and other manufacturers ship products that are fully supported by Linux. Use those. If you don’t, you’re on your own.
Why not just Rock Linux ? If you want corporate customers, use a corporate name.
To those who disagree, would you be comfortable telling your board of directors that you use "insert offensive word" Linux ?
I love new language gems. Thanks!
Taken from https://en.m.wikipedia.org/wiki/Ubuntu_philosophy
But yes, Ubuntu is based on Debian's Unstable branch.
As a Calgarian, the first thing I thought of was Rocky Mountains. Due to their proximity, you see the name is so many things and places here. For example, the area surrounding Calgary is called Rocky View County.
Ubuntu, a Bantu word, defines what it means to be truly human.
I just imagine going to the big boss and saying, "We're moving to Rocky Linux" is going to be a tougher sell based on the somewhat juvenile nature of someone's first name with a Y on the end of it.
Clearly I seem to be in the minority, however. I guess time will tell.
And regardless I am not really sure how I feel about the professionalism of backronyms in general.
"Enterprise" isn't right in the name. "ent" is.
Until a few weeks ago, I didn't know what the "Cent" part of "CentOS" meant, mostly because I didn't care. I somewhat assumed it meant the same as "penny".
Rocky Linux actually sounds good to me. Like a solid, rocky foundation on which to build your house.
We're arguing about a frigging name. Rocky Linux; you know what Madrake sounds to an Italian? https://www.youtube.com/watch?v=KguscIm8N0Y
I think, especially around Linux and open source projects, people care much less about naming than we tend to believe. Product reputation and the endorsement of IT/developers matters far more, in my experience, than a name.
We are literally on the web. Look out for spiders!
— Gregory Kurtzer, Founder of Rocky Linux and Co-founder of CentOS
It's written in Repo's README
Ignore the peanut gallery, it is a fine name.
That seems a pretty specious argument for not using a product.
Especially since the name was used to honor one of the founders of CentoS who is now dead.
That seems like a pretty good reason for a name to me.
What's more, I'd be more concerned about functionality than a name. But that's just me.
I agree. I mean, who would take something called "Red Hat" seriously?
, ,
/( )`
\ \___ / |
/- _ `-/ '
(/\/ \ \ /\
/ / | ` \
O O ) / |
`-^--'`< '
(_.) _ ) /
`.___/` /
`-----' /
<----. __ / __ \
<----|====O)))==) \) /====
<----' `--' `.__,' \
| |
\ /
______( (_ / \______
(FL) ,' ,-----' | \
`--{__________) \/ "Berkeley Unix Daemon"