I am really interested to know why should anyone go with this when Debian or Ubuntu LTS exist. The two later have not changed their policies in the last decade, and they have a clear path for upgrading. CentOS was always a clear choice for device drivers support, but I never understood the stability claims.
To system administrators and people managing large fleets of servers "stability" usually means "doesn't change much" rather than "doesn't crash". In that sense, RHEL tended to be more stable than Debian / Ubuntu. Though that may change somewhat with Ubuntu's recent 10 year LTS plans.
Agreed. I've used and advocated for RHEL/CentOS at work since version 5 because it was stable and predictible. That's gone now, and many of my users would prefer Ubuntu anwyay because it's what they use on their personal machines. So I'm making plans to move all our compute resources to Ubuntu LTS.
I'm wary of doing that, because in near future, Microsoft is likely to take over Canonical. You don't put all eggs into one basket. Always plan for escape, always have a plan B. Preferably one not relying on crystal-balling whims of a for-profit corporation. Rocky Linux, Alpine Linux, Debian, Gentoo, BSD, etc.
Moving a server from Ubuntu to Debian doesn't seem a very arduous task? I've got a box in a rack that came from the factory with Ubuntu installed, but there are Debian addresses in /etc/apt/sources.list.d
Besides isn't that pretty much the exemplar of FUD?
But it is still a task, isn't it? So, now you move to Ubuntu, then if things get south, you move to Debian. Or, you could move to Debian or other less risky distribution now and likely save some time and energy.
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.
there has been some collaboration between the two, however MS collaborates with other small companies and that speculation never arises. I wouldn't set a bet that they're uninterested in Canonical, but the desire to buy it has always been overstretched, it is much bigger chance that they buy some other specialized distro vendor instead (like Google buying Neverware). Ubuntu is too generic in that sense.
There have been some interesting observations on HN and elsewhere, that Canonical for a long time didn't know what it is doing, starting and cancelling projects, but in last years it is lowering interest in desktop and is more focused on providing cloud server software and foisting its new products and methodologies on its users(snap). Some people see this as indication that Canonical is positioning itself to be bought for the best price. It makes sense, as Canonical has a large Linux user base but can't make money there. Microsoft is making inroads in Linux world is the most likely buyer.
For packages like Kubernetes or big data packages one should not use anyone else's builds. I have been finding problems in Cray's modules and eventually we are using our own builds we can reproducibly support using Spack.
I would say for any piece of software, if the vendor themselves provide a package for your distro, use that, not the distro version.
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.
> 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.
And this is why installing ex. Filezilla on Linux is safe and easy, and doing the same on Windows is neither.
I am simply not a fan of Debian/Ubuntu's utilities, with the big one being the package manager (I like yum/dnf way better), but also other things like ufw vs firewalld.
Agreed, the packages in Centos / RHEL are all super old. The RHEL license structure changes all the time and depending on which one you get it may or may not include the extended repos.
Documented cases don't seem to be common, but what comes to mind is the Debian "weak keys" scandal (2008), and the VLC "libeml" vulnerability (2019)[1]
It's the opposite. Plenty of subsystems in the RHEL 8.3 kernel are basically on par with upstream 5.5 or so, as almost all the patches are backported. The source code is really the same to a large extent, and therefore security fixes apply straightforwardly.
The upstream for most other packages generally move much more slowly than the kernel. The fast ones (e.g. X11, systemd, QEMU) are typically rebased every other update or so (meaning, roughly once a year).
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 you need epel, or quicker life cycles then CentOS Stream should be just fine for you as well
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...
RHEL kernel versions are basically incomparable with vanilla kernel versions. They have hardware support and occasionally entire new features that have been backported from newer kernels in addition to the standard security & stability patches.
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.
That is not a good thing. RH frankenkernels can contain subtle breakage. E.g. the Go and Rust standard libraries needed to add workarounds because certain RH versions implemented copy_file_range in a manner that returns error codes inconsistent with the documented API because patches were only backported for some filesystems but not for others. These issues never occurred on mainline.
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.
True, but it is a matter of weighing risks. I can't find it now, but I remember a few years ago there was a news story about how an update to Ubuntu had caused hospitals to start rendering MRI scan results differently due to differences in the OpenGL libraries. For those sorts of use cases, stable is the only option.
I think this is a perfect use case for CentOS/RHEL as opposed to Ubuntu when the machine has only one job and nothing shall stand in its way, ie when you expect everything to be bug-for-bug compatible. But I fail to understand why a vendor of an MRI machine charging tens of thousands for installation/support cannot provide a supported RHEL OS which costs $180-350/yr in the cheapest config [1].
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.
Honestly that support is meaningless for some areas I know. In our Data Center we have hit problems with old packages and at the end you will end up with a lot of your own packages. In the end I find Debian to be a good base, and you build the rest by yourself. Even though I use Fedora for Desktop, I always have a feeling Debian is the server choice which I can extend further.
Arguably, no one should be running a server that long in 2020.
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.
Honestly, 10 years is a long time for a server. I would be honestly surprised if a server lasted 10 years.
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.
Really? We've colocated our servers for the past 18 or so years.
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.
The last time I worked with a ~8 year old server, it used to go through hard drives at a rate of 1 every 2 months. While we could replace them easily and it was RAID so there wasn't any data loss, I personally would've got fed up of replacing HDDs every couple of months.
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.
My read on that is that you should be treating your servers as disposable and ephemeral as possible. Long uptimes mean configuration drift, general snowflakery, difficulties patching, patches getting delayed/not done, and so forth.
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.
"Ideally" - that's the problem. I have half a dozen long tail side projects running right now on Centos 7, and a few still on Centos 6.
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!
Exactly, young devs here are completely out of touch with operations. Of course ideally something like standard 1TB HDD+32GB RAM system would be upgraded to newer OS and apps version by a central tool in 2hours, but we don't such FM technology yet.
I don't get this. If there are many servers, sure. But if it's something that runs on a single box without problem, why on earth should I tear it down?
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.
It's not really about running servers for 10 years. It's about having a platform to build a product on that you can support for 10 years. RHEL software gets old over time, but it's still maintained and compatible with what you started on.
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?
> Consider an appliance that will be shipped to a literal cave
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.
The "don't touch it if it's not broken" philosophy is fundamentally at odds with an internet-connected machine.
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?
"don't touch it if it's not broken" is not a philosophy, it is a slogan. Some people say it, because it is preferable to them to run old unpatched vulnerable systems rather than spend resources on upgrades. That's just a reality. Some care about up-to-date, some don't. Most people don't really care about security, and some of those don't care even about CYA security theatre. If they did care about security, they wouldn't run unverified software downloaded from the Internet.
Why Docker has anything to do with this discussion?
The point is the amount of "touching". Applying security patches to RHEL is still a change, but it's significantly less risky than upgrading a faster-changing system where you might not even get security patches at all for the versions of software you're using unless you switch to a newer major version.
I think it is mostly about running servers (standard services that don't change much) for 10 years (and more). You don't need 10 year LTS distribution for building a product. You take whatever version of OS distribution you like, secure local copy should the upstream disappear, and vendor it into your product and never deviate from it.
Of course there are use cases, but _ideally_, most workloads are staged, deployed, and backed up in such a way that it is a documented, reproducible procedure to tear down an instance of a server, rebuild, and redeploy services.
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.
How many simultaneously running machines can you keep updating with this method? If you run non-trivial workloads for hundreds of customers, this becomes high maintenance system already with two machines. It takes ages to upgrade all applications, then validate everything works, then actually migrate with no downtime.
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?
This is false. Debian provides LTS with a 5-years timespan. [1]
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.
Do you trust Debian LTS? As much as RHEL? The documentation about Debian LTS always made me think it is not a fully fledged thing. I've always felt like Debian releases reached EOL on their EOL date, not their LTS EOL date.
> 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.
Do you know something I don't? A few years back, Debian changed their LTS policy to 5 years in response to Ubuntu.
> 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.
Lately it seems to me Debian and Ubuntu have made some strange package decisions. They have morphed into a desktop oriented build with snap packages and auto-updates enabled by default (among other strange decisions). There's a ton of stuff we always end up disabling in the new release because it's super buggy and doesn't work well (I work at a small MSP). I'm not sure who replaced Ian Jackson, but Debian seems rudderless.
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.
Snap is proprietary and has a fairly broken implementation. Seems impressively good at preventing machines from booting, polluting the filesystem namespace (who wants 100 lines in every df?), doesn't seem to handle versioning or garbage collection well.
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.
Because CentOS on enterprise hardware is way more stable than Debian. I've worked for 6 years as a sysadmin for 300+ servers and we migrated everything from Debian to CentOS and our hardware related issues just went away. Overall we had much less trouble in our systems.
That's probably because lots of enterprise hardware is only ever tested and certified to work with RHEL, and in many cases only provided drivers in an RPM format that's intended to be installed in a RHEL-like environment.
> I am really interested to know why should anyone go with this when Debian or Ubuntu LTS exist.
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.
For me it's always been about stability and the long term support of a 'free' distribution. That has also historically been their bread and butter which got them wide-adoption.
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.
Apart from the long support, RHEL based distros also give you built in selinux support. Apparmor exists, but it's not comparable in features and existing policies.
The module itself is provided, yes. The policies are not really integrated into Debian systems. You can adjust them to work, but it's way more work than using ready ones on a RHEL-like system.
Rocky is going to be exactly what CentOS was: a free version of RHEL. The reason you would use this vs. Debian or Ubuntu is because you've got systems that need to mirror your production, but you don't want/need enterprise support on them.
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?
RHEL and its derivatives are the only linux distribution which maintains binary compatibility over 10+ years while getting not only security updates but feature additions when possible.
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.
That's the value pitch for RHEL, where it's understandable — whether or not you like the enterprise IT model of avoiding upgrades as long as possible, there's a ton of money in it.
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.
>who want enterprise-style lifetimes but don't actually want support
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 was thinking more about _why_ people want that. If you're changing the system regularly, upgrading is valuable because you don't want to spend your time dealing with old software or backporting newer versions. Most of the scenarios where you do want that are long-term commercial operations where you need to deal with requirements for software which isn't provided by the distribution, and in those cases they likely do want a support contract.
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 was thinking more about _why_ people want that.
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).
Re: point 2, I don't know how different that is for stable distributions — e.g. if you're running Debian stable you're in control of upgrades and you can go years without installing anything other than security updates if you want.
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”.
Have you worked in banking or aerospace? 10 years of needed support/stability/predictability is nothing unusual. The old if it ain't broke don't fix it mindset prevails.
What is the vision for Rocky Linux?
A solid, stable, and transparent alternative for production environments, developed by the community for the community.
Hence the name Rocky Linux, I suppose? Solid as a rock.
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"
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.
As others have pointed out, the name is a tribute to a late CentOS cofounder Rocky McGaugh. It would be sad if it had to be changed. We should perhaps emphasize the CentOS lineage in the name instead.
I doubt how successful this will turn out to be because of the following reasons:
- 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.
> 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.
I don't see how it would be too short a notice for current CentOS users really. At least for majority of users running CentOS in their production systems and relying on a long-term support. It's not like they just go and trash their production setup the very moment its running distro lifespan is shortened. I'd expect the opposite actually, since you're looking for something well supported.
Just like mysql had value, but much of the open source world has just moved on to MariaDB instead.
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.
I got the same impression. Do you think it would be too late to change the name to "Rock Linux" or "Rock Solid Linux"?
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
Given we are talking of branding, did you both completely miss the logo? To me it's clear the name is in reference to mountains, as in the Rocky Mountains.
One disadvantage of "Rock Solid Linux" is that it shortens poorly. I think "Rock Solid" or "RSL" would be ambiguous. On the other hand I think "Rocky" sounds nice and unique (at least in this space).
Also I feel naming it "Rock Solid Linux" would be a bit gaudy or arrogant.
The branding here I think is a big issue. The name "Rocky Linux" sounds too homebrew and unprofessional. CentOS sounds Enterprise-ish. I find it hard to believe any corporate client would take it seriously.
Ubuntu is a Nguni Bantu term meaning "humanity". It is often translated as "I am because we are", or "humanity towards others", or in Zulu "umuntu ngumuntu ngabantu" or in Xhosa, "umntu ngumntu ngabantu" but is often used in a more philosophical sense to mean "the belief in a universal bond of sharing that connects all humanity"
When they replied, what I originally had written was "Why is it bad branding?". I thought it would be obvious from the parent comment that I was talking about Ubuntu, but I think they thought I was talking about "Rocky Linux".
Oh, that's what you thought of! I was confused as why people take offence at Rocky.
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.
I actually think CentOS sounds pretty unprofessional (although familiar), while Rocky Linux sounds unfamiliar although at least has a meaningful inspiration. I would bet it could come to be equally as esteemed as a product called "CentOS" (or even "Red Hat") eventually.
CentOS is Community Enterprise OS. Enterprise is right in the name.
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.
Lots of decisions are made for arbitrary and, frankly, obtuse reasons. Often on a whim. I would just like to give the new distro the best chance to succeed.
Clearly I seem to be in the minority, however. I guess time will tell.
True, but is that really such an advantage? Consider telling the big boss: "We're moving to CentOS, but don't worry, the 'ent' actually stands for Enterprise".
And regardless I am not really sure how I feel about the professionalism of backronyms in general.
CentOS is Community Enterprise OS. Enterprise is right in the name.
"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.
no, the tough sell is telling your boss that you'll have to switch to paying Microsoft-range licenses for your server farm to an IBM subsidiary, whose name and logo are - literally - references to some random guy's clothing.
I've been using CentOS for at least a decade and only learned today that it was short for Community Enterprise OS.
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.
It is as resilient as cockroaches? I don’t see the problem. Postgres uses an elephant as a mascot because “elephants don't forget”. What’s the difference?
We are literally on the web. Look out for spiders!
I agree, don't get me wrong. But look up every single thread on CockroachDB to hit HN, and there's an inevitable subthread of people whinging about the name.
"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"
— Gregory Kurtzer, Founder of Rocky Linux and Co-founder of CentOS
Googol.com was older, and in the early days of Google featured a prominent "you're probably looking for these guys, not this site" on their front page. (It was, at the time, a math site dedicated mostly to the number.)
>The branding here I think is a big issue. The name "Rocky Linux" sounds too homebrew and unprofessional. CentOS sounds Enterprise-ish. I find it hard to believe any corporate client would take it seriously.
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'm quite sure some users have not adopted DDG because of the name. "I'm just going to duckduck the [search term]" does not roll that well from the tongue when compared to "I'm just going to google the [search term]". Google for most does not mean the word googlplex, but duck for sure refers to the bird.
>The branding here I think is a big issue. The name "Rocky Linux" sounds too homebrew and unprofessional. CentOS sounds Enterprise-ish. I find it hard to believe any corporate client would take it seriously.
I agree. I mean, who would take something called "Red Hat" seriously?
The only reason you think 'Rocky Linux' sounds unprofessional is because you are unaccustomed to hearing it in a professional context. Before I read where the name came from, I assumed it was named after the mountain range. Would that really be so strange, considering CPUs get named after lakes or MacOS releases named after cats or regions of California?
The reputation behind a name is earned, not given. CentOS sounds fine to you because it’s been around for years and years and has built a solid reputation, it didn’t become what it was because of a “good name”. I don’t care if the distro is called Bubblegum Naruto as long as it’s stable and reliable.
CentOS sounds amateur enough to me, and besides, that’s only a problem for cheap businesses that take CentOS as RHEL with a piracy waiver. Go pay for RHEL if you are looking for something professional.
Fortunately this is a server distro, and there definitely aren't enough of those around (stable trustworthy ones).
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
This distro is meant for servers, or maybe long term stable desktops you’d want in a classroom or something like that. People running servers don’t need any of the stuff you mentioned.
I didn’t say you can’t use it on a desktop, just that it’s not really what it’s meant for. The issues outlined above, like sleep, Bluetooth, etc. aren’t the main things focused on.
Rocky Linux is, I would say, emphatically not a Linux distro for the desktop. This is unrelated to your rhetorical question, but I think your exasperation at "yet another OS" is a bit undeserved here.
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.
As many people can attest, popular Linux distributions (like Ubuntu or Fedora) work just fine on select hardware, like ThinkPad X series, or Dell XPS. But Linux on desktop is fundamentally a tinkerer's OS: great if you like tinkering and flexible when you need it but otherwise a waste of time for a lot of people :) I like tinkering and use Linux ~exclusively but don't recommend it to most of my friends.
I agree it is a problem. I think there are several reasons:
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.
1. How others prioritize their time and how limited it is is an interesting call to make. Are you familiar enough with any of the contributors to know how much "spare" time they have and how they use it?
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?
Text-based config files are one of the best features of Linux. Duplicating and managing Windows software configurations is a nightmare by comparison. Making a reliable modern Linux system is pretty easy; usually you don't need to do anything much beyond installing, but if you do, the solid reliable text config and service management files make it easier than any other OS I've used.
They're really not. They prevent you from doing things like automatically responding to config changes, or changing settings programmatically, e.g. from a GUI or installer.
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.
The next CentOS will be where the core developers who are actually contributing to project will move. However, branding does matter if you want enterprise following. Rocky does sound unprofessional.
The fact that a majority of the comments are whining about the name really shows you the worst part about open source: the non-contributing but highly entitled part of the community.
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 very true and for a basic reason - one minute spent doing is one minute taken away from talking/writing.
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.
No, @hnarn is right. And you don't really "get" this until you start maintaining an OSS repo (I speak from experience). For years, I was very critical of Linus Torvalds and his brusque attitude. Then I started a few moderately-popular OSS projects, and the entitled masses started pouring in.
After a while, it's hard to refrain from telling people to just screw off.
I think this is one of those cases where one might say the customer (or user, in this case) is always right. But there are always customers who will just find something to complain about, and often (like when the product is a free community service) they're simply not worth having as customers.
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 maybe shouldn't but it always amazes me by how much developers (assuming that is who they are) will subject other developers to the same bikeshedding and minutia type hassles ... that suck for everyone.
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?
It's even more fundamental than human nature. Bikeshedding is better understood as an emergent behavior of groups of people than it is a thing that individuals do.
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.
Really? My first thought was the "Rocky Mountains" which seem like an apt metaphor for something slow, stable, and rock-solid. The logo even looks like a mountain peak.
My second thought was Rocky Balboa... but I figured that probably wasn't right.
Irony being they (Ian and Deborah) split up, Ian quit Debian and worked for Sun (arguably a competitor back then), Docker, ..., and unfortunately committed suicide.
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.
First, obvious troll is obvious. Second, complaining that the "GNU" part is awkward to pronounce when it's a regular English word unlike Linux amuses me. Linus Unix to Linux will forever haunt free software.
Right, infamous copypasta... forgive the pedantry, but the English word "gnu" (referring to the mammal) is pronounced "noo", while the non-English word "GNU" is pronounced "gah-noo"[0], as OP correctly pointed out.
I share your disappointment. Out of 150+ comments so far, I believe there has not been a single technical comment about the actual work involved in building a version-pinned RHEL clone.
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.
>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?
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.
From what I understand[1], up to RHEL6, Red Hat released their sources on public ftp, but after that they became customer/subscriber-only.
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.
>> I would have thought that the GPL ensures that the customer can then freely redistribute them
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.
The requirement to distribute source means you have to provide the exact source for any binary that you distributed, for three years. And the source is defined as " the preferred form of the work for making modifications to it". A pointer to the upstream tarball plus a poorly organized directory with 58 patches in it isn't "the preferred form of the work ...". SRPMs are an easy way to make sure that you got it right, that the source really corresponds to be binary. Attempting to add speed bumps risks getting it wrong and providing a way for pissed-off developers to make trouble.
I think the alternative which the other commenter had in mind was simply providing desired SRPMS to customers reactively upon request, possibly with a nonzero charge to cover, rather than proactively providing them to all customers in bulk. The GPL certainly allows this, as opposed to a tarball and patches which you're right is inadequate.
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?
I don't disagree, but I've seen other open-source companies view the tarball as their source release and I wouldn't be the least bit surprised if you could at least make enough of an argument to get a judge to go along with it long enough to make it prohibitively expensive to reverse.
The difficulty is that RHEL isn't a GPLed work. It's a mix of free software under various licenses and logos and other oddball things that are protected by trademark or copyright and are non-free (the non-free part is mostly icons and images identifying the system as RHEL). There isn't a lot of that, but it all has to be separated out to be legal to redistribute. If you go through all the work to do that, you wind up with the equivalent of CentOS. But RHEL's customers don't have the incentive to do that work.
RHEL source RPMs can be downloaded from http://ftp.redhat.com/pub/redhat/linux/enterprise. According to your link, CentOS doesn't use the source RPMs since 7 but uses git repos instead. I don't know where the git repos are located, however, or if it is still possible to build the whole OS from just the SRPMs.
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.
> 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?
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.
> 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/
> Red Hat publishes it's sources on https://git.centos.org. Those are then used to build CentOS Linux packages.
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.
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 git repository stores only the packaging related items (the specfile, the custom patches, etc.). The actual source is stored as a binary artifact that is downloaded by a `get_sources.sh` script.
That did it, thanks. From a cursory glance, it looks like it fetches indeed the RHEL (rather than CentOS) sources. It looks like the mains questions for the clone builders will be how RH is going to provide RHEL code drops for their point releases (and updates) in the future. Since right now there are separate 8 and Stream branches, but presumably the 8 will be discontinued at some point?
The RPM SPEC file in that repo will have a pointer to the actual upstream sources for the package. This is a typical scenario -- they are not re-hosting all of the sources to build a Linux distro, just the build steps needed to pull, patch, and build upstream sources.
So where do I actually get this upstream (RHEL8) source of say dracut? Because I was reacting to the comment "Red Hat publishes it's sources on https://git.centos.org. Those are then used to build CentOS Linux packages."
rpmbuild will download the sources listed in the spec file, apply the patches, and execute the build instructions to produce RPM and SRPM packages. The SRPM will contain the "as built" source tree.
Pffft. Imagine coming to a forum where people commonly give their opinions only to accuse them of "whining" and "entitlement" when they simply give an opinion that you don't like.
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.
Down to death your comment goes. That’s what you get for complaining about complaining about complaining about the name. Because obviously complaining about complaining adds much to the discussion, while complaining about those complaints about complaining draw away from it⸮
Don't know if it has been mentioned, but the name Rocky is from Rocky McGaugh, co-founder of CentOS. He passed away and they named the new effort after him.
First impressions and names matter. As much as we don't like it, human beings are irrational and emotionally driven. There's nothing wrong with discussing a name.
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).
This is so misinformed it's funny. CentOS and RHEL will now be down to the compiler flags compatible since RHEL minor releases will now just be point-in-time forks of CentOS with security fixes and backports from, you guessed it, CentOS.
CentOS and RHEL will only be exactly the same at the moment when RHEL is a point-in-time fork of CentOS. As soon ad RHEL forks from CentOS, CentOS will roll forward and will no longer be exactly the same as RHEL.
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).
You act like RHEL 7.1 is a fixed artifact — it’s constantly receiving updates, security patches, and backports. And CentOS always trails behind on those updates so it’s never exactly the same as RHEL either.
This change makes CentOS so much closer to RHEL that it’s weird that people are acting like the opposite is happening.
That's the whole point -- it's continually receiving updates that never break binary compatibility with existing apps/packages. For example, it's a safe target for vendors to target with binary packages, whereas CentOS stream won't be.
That's true of all RHEL major versions. You can safely target RHEL 6 or RHEL 7 without having to worry what minor version they might be running. The same will be true of CentOS Stream which is the upstream for the next minor release of RHEL. CentOS Stream isn't going to suddenly jump major versions.
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 a use-case for CentOS Stream, and if all Red Hat did was announced CentOS Stream and kept CentOS proper NO ONE would have any issue with that.
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?
I can’t defend cutting support for CentOS 8. That’s super shitty and I don’t really understand the move.
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.
CentOS will be useless as a replacement for RHEL. Without the guarantee of binary compatibility, any CentOS Stream update may break your locally installed applications.
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.
I replied to you in another thread but nonetheless CentOS Stream isn't going to break your binary compatibility for the same reason that RHEL 7.3 doesn't break binary compatibility with RHEL 7.2. CentOS Stream is spiritually always the next minor release of RHEL.
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.
They do specifically mention that some fixes may come to RHEL first.
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.
>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.
Security fixes are not coming to CentOS Stream first. That's been in the announcement.
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.
It's unlikely they would sabotage their only competitive advantage though, whereas Oracle has lots of reasons to maintain an enterprise linux distribution besides just succeeding CentOS.
In an earlier thread, some Oracle guy (not in the Oracle Linux team) mentioned that Oracle 8 actually builds from CentOS 8, rather than RHEL 8. I was a bit skeptical, since OL 8 usually releases much earlier than CentOS 8, but couldn't verify things either way. Someone else mentioned that RH actually only releases RHEL8 sources through CentOS8 sources. Again, I don't know how to verify, but if true they raise a lot of new questions about Oracle Linux 8 given the recent CentOS 8 announcement.
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.
> Devil's advocate: why should I choose this yet-to-exist distribution over something already existing, such as Oracle Linux?
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.
When you say that they depend on CentOS, are they using something CentOS-specific. Centos is supposed to be compatible with RHEL (minus the logos/trademarks) and shouldn't have additional fixes or features. ("bug for bug, feature for feature" <= centos wording :)). No?
CentOS don't have to have a specific feature to be preferred over RH. Being free in both beer and speech is important enough. People (incl. us) install 1000+ server clusters with CentOS. The absence of licensing fee allows us to buy more servers. The absence of licensing fee allows "small researchers" to have a verified platform to work with. If you don't have a verified platform, you cannot trust your results.
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.
In 2020 why aren't you packaging your apps as containers? Yeah, it sucks that ibm killed centos, but depending on some single distro's version of libm or libc or whatever is not their fault it's yours. Doing your job properly in this case means shipping you deps with your application, and the easiest way to do that these days is with containers..
Assuming based on GP that this is in a HPC environment, there is often a delineation between the people writing HPC software and the people maintaining the clusters and the software installed on them. Telling a brand-new graduate student with zero software development experience to just throw everything into a container results in running code that is not optimized for the hardware it's running on, which in turn negatively impacts the other users competing for compute time on HPC clusters.
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.
Because a cluster doesn't work like a normal computer.
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.
> Devil's advocate: why should I choose this yet-to-exist
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.
I haven't seen "using Oracle Linux will result in me being sued".
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).
I find it interesting that the argument that "X is FUD" is supposed to carry weight.
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.
I think the name and the logo is good. Don't listen to the people who just keep talking and not helping! Good to see that CentOS cofonder picked this up and now became a founder of Rocky Linux. This shows dedication and rock solid background. Rocky Linux will be a project to follow, help and use in production environment. Thank you for all your hard work!
Reminds me about how people don't even give CockroachDB a chance because of it's name. Every time it's mentioned on HN, people can't help but to bring up it's name.
Let's face it, idea for using word "gimp" probably came before they figured out what it stands for. Even now when everyone understands what that means and what consequences are behind using that word, there is still a lot of debate around that name and instead of changing it to something more marketable they are stubborn and are sticking to it. They even allow for bigger market fragmentation (Glimpse fork of GIMP) just to not change that name, that's childish.
I love it... Cockroaches are survivors. When I was in grad school my lab was in a subbasement in a 100 year old building. We had huge cockroaches...
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.
Diatomaceous earth is very effective at killing them. It's fascinating that they're so robust, but just a little inert powder can kill them. Though to be fair, at their scale, it may as well be a pile of razor blades.
One drop of dichloromethane does them in super fast. Their body metabolizes it into Carbon monoxide. A bit of a wake up call for those of us using dcm (our bodies do too, but less quickly)
Not sure if there are solid evidence established to prove this, but Cockroaches are believed to be capable of surviving large amount of radiations (like from nuclear bomb), hence they thought it would be apt for a geographically distributed DB.
I think Rocky is good. CockroachDB on the other hand is an awful name. Cockroaches are only associated with filth and are revolting to most people. Plus, you got that cock in the name which isn’t helping matters. You might think it’s obnoxious that people always point out the name without considering the product but tone deaf branding is a misstep and begs the question: what else are they screwing up if they could get the brand name so utterly wrong?
Many native English speakers don’t realize that ‘git’ is a slur somewhere between idiot and wanker. It’s somewhat comical how mundane the word has become in its new context.
A certain company, a few years ago, came very close to having a Global Information Technology Services department. Fortunately a few Brits made sure their voice was heard.
Ah yes, he was pissed off at the guy that typed in "help" after telneting to a BitKeeper repository, then using the docs that put out to make a clone of the client. Since he had a connection to the Linux Foundation, that caused McVoy to revoke the license for BitKeeper to the Linux community.
I think it is bad. You just cannot go to your manager and PR and tell them we are using CockroachDB. If you have a manager who would understand this though, then your manager still cannot go to his manager with that name.
Yeah, sounds like an awkward conversation but I know there's some huge companies using it. I guess they named it that way because cockroaches are believed to survived since the dinosaurs. I guess be the same if you named it BedBugDB, they are hard to get rid for some people too.
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!
Maybe its a clever tactic to reduce usage at companies that are controlled by non-technical people that are more worried about the name than the technology. Probably has a notable effect on the number of demanding/misinformed issues that they have to deal with ;)
> I think the name and the logo is good. Don't listen to the people who just keep talking and not helping!
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.
The notorious local news story about a woman who flunked out of college because her laptop came with Ubuntu comes to mind. I think that was in the mid 00s.
Same here. Things that come to mind: Rocky, the champion boxer who can "go the distance" and never gives up... the Rocky Mountains, which are, well, rocky and strong... Rocky Road ice cream, which tastes good.
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.
"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"
— 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.
Anyone believe that I will, at some point, be able to point my CentOS 8.x configuration at the Rocky Linux repo and just upgrade to it? That would be ideal. I realized GPG keys will need to be replaced, etc.
Worst case is might have to also manually replace a few "release" and "logos" packages (which is what's involved now for switching from RHEL to CentOS or OracleLinux)...
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.
Looking forward to give this a spin at home to see if it'll be the future of non-RH based linux servers, although it'll take a long time before people are willing to throw it in prod like they do with CentOS. No way to change that except time.
Also it's interesting that some people defined Rocky as being 'unstable' when others read it as being 'solid as a rock'.
I knew what CentOS was, but never followed it because I've never personally had use for it. Still, I appreciate what it did and was glad to have it as an option should I ever need a super stable distro in the future.
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?
The most frustrating thing about this is that Redhat was making a profit before IBM bought them. They had existed for 20 some years on a business model that business people didn’t understand, and they were able to do that because they understood what open source would become and how they could play a role in that.
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.
>CentOS 8 was never officially supported until 2029 so we did not go back on anything
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 mean, I hate to say this, but have we considered that a big part of the reason RedHat has been profitable is because it doesn’t care about the desktop? And no, Fedora really doesn’t count.
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.
Honestly, with the way things are going, I would like them to deemphasize the desktop.
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.
I agree with you on those projects and Mint, my only response is that they are all much smaller projects that lack the funding and size/force of will that Ubuntu was able to achieve. That isn’t to take away from them at all, but aside from System 76 (a boutique reseller who until recently has primarily just sold re-badged Taiwanese laptops (good laptops to be sure, Clevo is a solid ODM), most of them are either largely community projects or very nascent businesses with a few full-time employees.
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.
But Red Hat ended up being the exception that proved the rule that selling support for open source isn't a very lucrative business. There was room for one player in that space and Red Hat was it. Now with cloud providers selling support for open source bundled with the infrastructure to run it on, there isn't even room for one standalone player.
Sqlite devs have funded their development decades into the future by selling licenses to public domain software. It may not have made them a billion dollar multinational corporation, but must every company have such conqueror aspiration?
Obvious next question: what drove the CentOS devs to sell to Redhat. From previous discussions, I understood that it came down to lack of resources / devs to maintain and support it. So OP's question is on point: what will Rocky Linux do to avoid a similar misfortune?
There isn't any evidence anything causes anything else. Cartesian dualism is irrefutable. So for all we know we live in a world where IBM destroying everything they touch is purely the will of a malevolent daemon who wants to tarnish the good name of the company that enabled the holocaust.
> The CentOS project recently announced a shift in strategy for CentOS. Whereas previously CentOS existed as a downstream build of its upstream vendor (it receives patches and updates after the upstream vendor does), it will be shifting to an upstream build (testing patches and updates before inclusion in the upstream vendor.
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.
Fedora is desktop-focused. RHEL and CentOS are server-focused. I think there is a place for both. But who knows, maybe IBM will discontinue one, or both.
RHEL and CentOS are both server and desktop. The desktop is just not flashy or shiny or bleeding edge. The default install is/was Gnome 3 shell (For RHEL7 and CentOS 7).
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.
Does anyone know what exactly what were the legal/financial mechanics of RedHat 'absorbing' CentOS in the first place? Is "CentOS" a trademark? Is the CentOS logo trademarked?
Who exactly owned the servers that CentOS was distributed from? Did CentOS have people on the payroll who took jobs at RedHat? (Did CentOS have a payroll in the first place?)
> 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.
554 comments
[ 3.4 ms ] story [ 242 ms ] threadBesides 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.
[1]: https://www.redhat.com/en/store/linux-platforms
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.
[1] https://wiki.debian.org/DebianReleases
[2] https://wiki.debian.org/LTS/Extended
> 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.
https://wiki.debian.org/LTS
> 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.
https://wiki.debian.org/LTS
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.
https://blog.cpanel.com/centos-8-end-of-life-announcement/
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?
[1] https://koji.fedoraproject.org/koji/
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.
Although I'll be inclined to think of it as series of movies. Perhaps even split wood before installing Rocky 5?
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.
- 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.
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.
https://distrowatch.com/table.php?distribution=rock
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?
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.
I love new language gems. Thanks!
Debian = Deb + Ian.
Ian Murdoch broke up with Deb, and later he hanged himself.
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.
[0] https://en.wikipedia.org/wiki/Rocky_road_(ice_cream)
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.
0. https://www.gnu.org/gnu/pronunciation.en.html
https://stallman-copypasta.github.io/
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
[1] https://lwn.net/Articles/603865/
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.
??? There's nothing there.- 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...
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.
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.
https://www.xach.com/gg/1997/1/profile/1/
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.
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/
Also it's interesting that some people defined Rocky as being 'unstable' when others read it as being 'solid as a rock'.
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.
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.
This is what I understood from a reply to another comment of me in a similar thread.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
Cloud
Centralisation
Corporations
and invest time, money and energy into a different Linix eco system
> 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...