CentOS Project shifts focus to CentOS Stream
lists.centos.org
lists.centos.org
https://news.ycombinator.com/item?id=25345428&p=2
https://news.ycombinator.com/item?id=25345428&p=3
(This message will eventually self-destruct.)
I personally run a CentOS 7 server (as do members of my family), and was planning on upgrading them all to 8. Luckily, I didn't get round to it yet. I guess I'll have to consider an alternative. For my server I want a boring, stable OS, so I'm definitely not using Streams. This is going to ripple throughout the whole industry, as CentOS is used all over the place, from regular home users to businesses (and things like CloudLinux).
It's very disappointing that Red Hat can't see the damage they'll do not only to the community, but to themselves too. Someone will come along and take the CentOS user base, and it won't be Red Hat :(.
A really big chunk of the world's traditionally shared hosted websites run on CentOS, because most commercial control panel packages and hosting automation systems are built for that. A rebadged CentOS is also AWS's default distro.
Wonder of the hosting industry, AWS included, will build a new stable clone of RHEL 8's upstream security patches. There are some big companies, like GoDaddy in there, whose business models are unlikely to accommodate for RHEL support subscriptions.
This is truly a bummer, and if someone doesn't pick up the pieces and continue offer RHEL rebranded, there's no(?) open sauce operating system with a decade-long support lifecycle. I wonder if this might cause an increase in unpatched servers and appliances when the alternatives offer five years at best.
My best hope is that the major hosting vendors, or maybe some industry consortium might offer resources for this.
But the point is indeed that there are resources and infrastructure, so one might be hopeful that there will be a good outcome.
One possible outcome would be increased demand and resources for Debian and/or Ubuntu and I definitely wouldn't mind that (five years of support isn't all that much in IT). Realistically though, a lot of people need RHEL for free and I suspect there will be a way.
On the first point you are correct. It's not exactly RHEL7.
On the second point, Amazon provides images for running on prem[0]. We run a lot of dev AmazonLinux2 VMs on prem so that the local computing environment matches the deployed EC2 environment.
0: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-l...
Other RHEL-clones: Oracle Linux (best one), Springdale Linux.
Other alternatives: openSUSE Leap and Debian. I am not even listing Ubuntu because I hate it since snaps.
But something like Springdale, given resources, might be able to provide. They're still tracking RHEL 7, though.
Debian and Ubuntu, which offer five years of Long Term Support are the next best thing available, and that's already kind of tight for long-term deployments of self-hosted, old-fashioned business software.
Debian is particularly impressive, since they, on paper, aim to support all packages with security fixes, whereas Ubuntu's main repo is a lot more limited.
OpenSUSE Leap versions seem to get three years, which really isn't enough software that needs to just work for a long while.
Here's the full ISO for 8.1: http://puias.princeton.edu/data/puias/8.1/x86_64/iso/
And then you can add the repos to update to 8.3: http://puias.princeton.edu/data/puias/8.3/
Or you can take the small ("boot") ISO and install 8.3 directy: http://puias.princeton.edu/data/puias/8.3/x86_64/os/images/
In fact, they are even building Springdale Linux 8 for i386, which RHEL and CentOS never did.
If you need more than three years on openSUSE Leap, then you need to upgrade to SUSE Linux Enterprise Server.
I claim no deep expertise on this, and I assume Canonical has more money to throw at this. Or are there contributions to Debian security in the form of paid personnel?
This is actually quite interesting to me, anyone with real knowledge of the subject is welcome to interject.
What are the track records of the claim?
I'm sure Ubuntu will patch stuff up if some vulnerability shows up outside of main that gets patched upstream or elsewhere.
I claim no deep expertise on this, but for a distribution of 56k packages, this looks quite good https://security-tracker.debian.org/tracker/status/release/s...
To anyone here who's worked secops and has to track these things, I'm really interested to hear opinions about how well Debian follows up on this
Remember that, in Ubuntu, the majority of packages are actually ONLY supported for nine (9) months -- not the full 5 years!
Q: What does this mean for users of CentOS Linux?
The creation of CentOS Stream provides a new mechanism for partners and community members to add innovation to the next version of RHEL as it’s being built instead of after it’s built. We also recognize that there are different kinds of CentOS Linux users, and we are working with the CentOS Project Governing Board to tailor programs that meet the needs of different user groups.
In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers. We’ll share more details on these initiatives as they become available. For those converting to RHEL, there is guidance available today for converting from CentOS Linux to RHEL.
[0] https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10
I think that's a gray area. For example RHEL has some support branches where they'll produce security updates for minor updates. For example you can pay a lot of money and you'll get RHEL 7.2 with security updates. They won't release sources for those packages unless you'll ask for those packages (you, as a paid client, not you as nobody in the Internet). But if you'll ask sources and then publish those sources in the internet again and again, so other entity like CentOS or whatever could pick them up and build CentOS 7.2 LTS, they will terminate your contract.
So that's a weakness in GPL. You won't break any law, but they'll just terminate contracts with those who publish those sources. So those sources are effectively unavailable for a large public.
Currently they publish their mainstream branch sources to the public. But they could stop doing that any time and only provide those sources to their clients on request.
If the code in question is licensed under the GPL and Red Hat isn't the owner of the code, then I as a rando on the Internet can ask them for the source and if they don't provide it, the person who does own the code can sue them and revoke their license to distribute said code. And I'd say that the majority of code in RHEL is not owned by Red Hat.
>3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
> b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
Everyone was doing network distribution of GPL software long before GPLv3 came out, effectively treating a download as a medium customarily used for software interchange. Not a physical one, but GPLv2 does not say anything about that.
This is why the cloud providers can get away with custom in-house patches to the Linux kernel.
ScientificLinux and CentOS rules all HPC clusters. Clusters are like enterprise servers. Big, monolithic, rarely upgraded. They're upgraded in one big-fell swoop and left to run.
There'll be another clone of RHEL since HPC can't accept CentOS Stream as the alternative. The whole infra is too big to move to Debian too.
So with today's announcement, a new distro is born. Also Greg (CentOS' founder's) domain (HPCng) is very telling...
We'll see. We're in for a hell of a ride. If you excuse me, I need to dust-off my XCAT servers...
There is a page describing the conversion: https://linux.oracle.com/switch/centos/
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
Put another way, if you jump ship from CentOS because IBM caused Red Hat to change it into a funnel to pay them money, if you landed on Oracle, you might be setting yourself up to do it all over again fairly soon.
You're underselling it: Oracle grab money in a way that I would describe as "aplomb ruthlessness". They've managed to fuck no less than 3 orgs I've worked for.
If they ask you for a license count or how many cores are in use, ignore them. Larry Ellison doesn't need another boat.
"Unlike many other commercial Linux distributions, Oracle Linux is easy to download and completely free to use, distribute, and update. Oracle Linux is available under the GNU General Public License (GPLv2). Support contracts are available from Oracle. "
Writing like this makes me very wary of putting Oracle Linux anywhere near my employer's systems
https://www.computerworld.com/article/2992597/law-firm-warns...
https://blog.dbwatch.com/how-to-avoid-oracles-licensing-trap...
Then there's the famous lawn mover quote from Bryan Cantrill https://news.ycombinator.com/item?id=5170246
Been burned by them before. Not at liberty to give details, but the outcome is that I never choose Oracle for anything for the rest of my career. Even if it would save time and money.
Community based sounds better to me.
> But if you're here, you're a CentOS user. Which means that you don't pay for a distribution at all, for at least some of your systems. So even if we made the best paid distribution in the world (and we think we do), we can't actually get it to you... or can we?
We only need RH equal of Debian, since the software we use generally have explicit CentOS/RHEL support.
"Out of the frying pan into the fire"
And I'll forever hate them for what they did to Java (and in setting the precedent that APIs can be copyrighted).
- Brought MaximeVM of research and creating GraalVM
- In the process of adding value types to Java
- In the process of adding support for explicit SIMD in Java
- In the process of adding co-routines to Java
- Added type inference support
- Added pattern matching
- Added record types
- Integrated J/Rockit support for JIT caches
- Made Flight Recorder available in OpenJDK
- In the process of making AOT compilation work, instead of requiring you to fork money for a JDK with AOT compiler like Sun used to do
- Integrated almost pauseless GC with support for TB sized heaps
- Long term roadmap to replace C++ with Java on the JDK, as yet another proof of Java capabilities
- In the process of having a JNI replacement
And plenty more, https://openjdk.java.net/jeps/0
I hope they squash Android Java, Google had the opportunity to buy Sun after screwing them up.
Anything else is just FUD.
Oracle creates cool tech in the legacy of Sun because it impresses the right people who can influence the decision makers.
To recap: "Hey, Oracle's these new toys are capable and fun to use. We can do much more with them. Can you buy these for us, engineers so we can be happy like children again?"
I guess the "community" would love to keep using Java frozen in version 6.
[0] - Only IBM considered it, which from these threads people here wouldn't be happy anyway.
They're not a nice entity unless you pay money to them and they're greedy. They always want more. Also, their hardware can fail in strange ways and they'd shrug it off.
I've met with some nice people who migrated from Sun but they all say that the terms they work are draconian.
I like Java too but, developing a nice language doesn't make Oracle good. Don't get distracted [0].
> I guess the "community" would love to keep using Java frozen in version 6.
Python doesn't stop. C++ doesn't drop. Even brainfuck doesn't stop. It'd have prevailed. OpenJDK is one fruit of the project. After removing patent encumbered image processing stuff, OpenJDK just took off. Yes, it's still part of Oracle in a sense but, OracleJDK is compiled from OpenJDK, not vice versa. Again, don't get distracted [0].
IBM, Microsoft, Google, Apple, Oracle, Amazon, Sony, Nintendo
So much better.
These companies employ people who contribute to these programming languages. So the model is somewhat different.
I'm not that oblivious about the real/programming world.
Oracle's governance is different from this. C++ is an ISO committee. Python has a lot of working groups, etc.
Java is much more centralized when you compare with others.
Should I also start listing the dark sides of each company that seats at ISO C and ISO C++ table?
Python working groups also need money from those corporations, and Python is yet to provide the performance levels of Java, so much for free beer development.
I know Java has stakeholders but, what I'm trying to say is the table is at Oracle's HQ, not somewhere else.
> Should I also start listing the dark sides of each company that seats at ISO C and ISO C++ table?
A primer would be nice, actually.
> Python working groups also need money from those corporations, and Python is yet to provide the performance levels of Java, so much for free beer development.
I've never alleged that Python takes no money from corporations and, Python doesn't aim the performance of Java. Their byte-code even doesn't get optimized. Instead Python prefers native libraries for performance. SciPy, NumPy, PyTorch and others obtain native performance on any system they run and, it's enough for Python.
No need to move the goalposts and compare apples to oranges. Python is never meant to replace Java. Java is not meant to replace system programming languages like C/C++. You may like Java and it might help you to pay the bills but, pushing other languages around just because they don't fill your needs from your point of view is not the correct stance.
Microsoft, the evil company over here, that keeps being compared to Oracle. Several C++20 features like Modules and co-routines were driven by their VC++ implementations.
Apple, the company hated over here by bringing the end of open platforms, without it LLVM and clang wouldn't ever exist.
Google, the spying company and forking Linux with Android, the second major clang and llvm contributor.
IBM and Red-Hat, with their own Linux agenda pushing stuff like systemd hated over here, major GCC contributors.
You are missing the whole point with Java, it isn't about Java, rather all mainstream languages just like Java only move forward with dirty money (from HN point of view), but hey it is cool to hate Oracle.
Hint they are one of the first enterprise contributors to the Linux kernel and have been ever since.
Do you also feel like removing Oracle contributions from the Linux kernel?
All big companies have a number of dirty deeds in their history, that's right. But I'm not a person who generalizes this to overall companies, incl. Oracle.
I personally don't use Microsoft OSes, however I have several licenses since my family uses them. I also have a personal lincense (albeit it's booted once a year) for some odd application I may need if stars align on the Friday, 13th. OTOH, I always have praised them for their ergonomics research, resulting hardware and their choice for keeping Kinect open back in the day. I won't ever trust them but, I'm not delusional.
I don't use Android devices or Chrome. Only some Google services. However day by day, I'm using their services less and contemplating to switch over to something like Proton. Also I loathe them for making pseudo-open stuff and closing it later. However, they're pioneer of software defined network due to sheer size of their networks.
I have Apple laptops and iPhones but, my main desktops/workstations are vanilla Debian boxes and always will be.
> You are missing the whole point with Java, it isn't about Java, rather all mainstream languages just like Java only move forward with dirty money (from HN point of view), but hey it is cool to hate Oracle.
No, I don't hate Oracle per se. I only hate their money greed. Especially the money greed via Java. I've used their ZFS appliances after they acquire Sun. They were nice up to a point. I applaud them for the enterprise ecosystem around their OracleDB. I like how they managed to fuse Sun's hardware with their software. But I don't like their greed. Maybe this greed is required from their point of view, but I don't like it.
Similarly I'm not keen on nVidia's strong-arming everyone and pushing people around. Also I don't like their arrogance. Yes, CUDA is nice, it's the de-facto standard for now but, it doesn't justify bullying others around.
Microsoft also contributes to Linux Kernel, I'm aware who's doing what.
> Do you also feel like removing Oracle contributions from the Linux kernel?
No, but I feel like you may like replacing it with a Java re-implementation running on a bare-metal HotSpot VM.
Not liking a part of something doesn't need to spread all over that thing. Do you leave your car to a junkyard because you dislike the engine sound at a particular RPM? Do you change your PC because its USBs are a little slow to a similar model? Same idea.
That said, their supported versions of Java and Graal are expensive. Some things never change.
I just hope that it's true. We really need that.
The supported versions of Java and Graal are the same price as any other enterprise product.
They put the effort, someone has to pay for it.
Where are the free beer JIT, AOT and GC implementations for free beer languages that outperform Java?
If I understood it correctly, a programming language has some foundational design decisions (including its memory and execution model) to attack a particular set of problems?
The people capable of achieving that, naturally have bills to pay.
Not always. As I aforementioned in another thread, we also need C/C++, Python, Perl, etc. as is since they fill different roles and attack different problems.
I've written Java, C, C++, Python, Perl, PHP. Had to abuse some of them to fit roles which they're not designed to do. At the end of the day, these languages satisfy different needs and solve different problems in different scenarios. Java wouldn't be able to do all of them. Neither C++, nor Python.
As I said, you may like Java but, it's not the king of every programming language. No programming language is king of everything BTW.
PHP was mostly driven by Facebook needs.
None of them is any different from Oracle.
And apparently you fail to understand who has contributed to state of the art implemetnations of AOT compilation to toolchains like LLVM, hint the companies that HN loves to hate, it weren't weekend and late night coders.
I'm pretty aware that nearly all clang/LLVM development is driven by apple.
On the other hand you apparently fail to understand my point of view about Oracle and Java ecosystem. I'm neither against Oracle nor Oracle's development of Java or Java's development in the interest of Oracle mainly.
I'm only against Oracle's motives about making Java a walled garden and usage of this programming language to extort license money from others.
On the other hand, I personally use OpenJDK runtime countless times every day, knowingly or unknowingly. I'm written Java in the past and have no reservations or bad things to say about it. Contrary to your view about other programming languages, I'm pretty neutral against every other programming language.
> C and C++ development is sponsored by the corporations of Apple, Microsoft, IBM, Oracle, Google.... PHP was mostly driven by Facebook needs.
There are no news for me here either. Development of a programming language or any tool with input from its users is a non-issue. Also, every user has needs from the products they use, so they will provide feedback and communicate their needs.
The difference, I want to highlight and highlight again, none of these corporations can use C++ or PHP or Python to extort license money from their customers. PHP is owned by Zend, so they may try. C++ is almost public domain now. LLVM is under apache license. Either way I use GCC which is GPL. Python is 20+ years old and is also almost public domain.
Contributing to a tool to get what you want is different from owning a tool and to use it to extort licensing money is different.
Either way, as aforementioned, I have nothing against Java, contrary to your views against other programming languages.
Do you really think that would be a reasonable thing to happen, and good for technology and the world in general? It seems disproportionately punitive, and the "right" thing to happen only if all you care about is watching things burn.
And you haven't addressed the precedent that's been set that APIs are now copyrightable. Do you like that precedent? Do you ever use anyone else's APIs in your daily development, and do you like how that now opens you to huge potential liability? Is all of this worth it just because Google didn't acquire Sun??
The license for RH precludes you from running unlicensed RH, if you have any licensed RH. I don't believe SuSE does the same.
Seems like the kernel was last updated in May.
$ uname -r -v
3.10.0-1127.8.2.el7.x86_64 #1 SMP Wed May 13 10:45:47 CDTScientific applications can be very picky about the libraries they use or need, down to minor version since the results they produce are very, very precise. Even if not very accurate, you need to know the inaccuracy. An optimization in a math library can change this and, it's not something we want. Also program verification and certification generally includes versions of the libraries used.
Piecewise upgrades are a no go too. Your cluster generally can't work well in heterogeneous configurations (due to library mismatches) and draining a node is not a straightforward task (due to length of the jobs). If your cluster has a steady stream of incoming jobs, reducing resources also means queue bloat and recovering it is not easy sometimes. If you want to drain the whole cluster, it takes almost 2-3 weeks so, you lose ~1 month of productivity. When you start an empty cluster to churn its queues, its saturation takes time so, it doesn't go to 11 directly.
Also, worker nodes are highly isolated from the user's point of view. No users can log-in, only known people submit jobs, etc. Unless there's a rogue academic trying to do nefarious things, the place is pretty safe and worry-free. In past 15 years, we got two rootkit infections due to a server which can be world-accessible by design. Other than that, nothing ever got infected.
At the end of the day, this approach has some valid reasons to be alive. It's not that we're a bunch of lazy academics who refrain from applying good system administration practices. :D
Addendum: The images generally get updated when new hardware is added, since new processors tend to work better with newer kernels. Also sometimes we bit the bullet and update all the cluster at once. XCAT helps a lot in this space. If your image is sane, you can install batches of 150+ servers in 15 minutes while sipping your coffee.
All repo settings will look to local repo so we'd have no dependency problem or version creep if we need to install an additional package.
Didn't completely think how to handle the occasional emergency update though.
Also, we need to compile in some packages. Hope they won't break. High performance stuff needs optimized/customized compilations.
I just want to add: Hope that the packages in CentOS stream won't end up too cutting edge for the scientific software community. These communities move slow due to stability requirements. We'll certainly see but it might be another potential problem.
I think HN is the only place where you can casually provide feedback and get answers about an OS project from one of the core people in it. Fun!
Glad to meet you, BTW.
Whether or not Red Hat "has to", Red Hat is an all open source company and does and will.
IBM is open source friendly, but the days of RH being an "all open source company" ended in July 2019.
https://aws.amazon.com/amazon-linux-2/#Resources
AL has had enough work put into it over the years that, while it may have been inspired by CentOS/RHEL originally, calling it a rebadged CentOS is not accurate these days. A full and competent team maintains it. While it's clearly made similar architectural choices, those are also for compatibility reasons.
However I doubt that support is available for anyone not running it on AWS, at least not from AWS -- but then again folks running CentOS weren't paying for support from RHEL either.
I also wonder if the announcement is as bad as people make it sound. I'm not an expert in Linux distros, but my understanding is that AL2 also uses a streams-like model, in that it provides long term support (patches for existing software) while also making new software available. My understanding was that, while it is inevitably versioned by making artifacts like VMs and containers available over CDNs ( https://cdn.amazonlinux.com/os-images/2.0.20201111.0/ ), the expectation is that most users will always launch the latest version, relying on its backward compatibility. Perhaps someone who knows more about the specifics of its release model could comment.
Works ok on a RPi.
I'm really curious whether Amazon Linux is accepted by Linux guru or not. It seems that there are very little docs for a distribution.
Either that, or Debian's user-base will grow a lot within the next few months. :)
So a few years ago when Debian decided to have faster release cycles I migrated all my VM to CentOS: once the OS is installed I don't want to think about it for the next 10 years.
I still didn't finish my Windows 7 to 10 on all my desktops, I'm swamped with users wanting to do Zoom / Teams / Skype / Whatever visio conferences, I have 3 new dev projects for 2021 and now I have to migrate all my CentOS VM...
Yeah, thank you RedHat I won't forget / forgive that.
https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10
I have nothing against you in particular, but if you know the guys that made this decision tell them the same words that Linus Torvalds said to Nvidia.
I will never touch anything Red hat ever again because I will remember how after a quite sucky 2020, Red Hat made sure my 2021 would not disappoint either.
No, they won't migrate to paid RHEL. This is massive goodwill burn for RH.
You've burned people. Don't expect to then sell them Aloe Vera.
I think people would panic less if the CentOS Linux cancellation were announced at the same time as these upcoming announcements. Without them, there's a lot of uncertainty and it's hard for anyone depending on CentOS 8 to plan.
Well, you've panicked people who are/were moving forward with CentOS 6/7 to 8, and not on RHEL because no budget. "Don't worry, sometime in the next 6 months there might be useful info for you, or there might not".
People aren't going to stick around waiting for that information. You've pulled the rug out from under us and we need to plan sooner rather than later. RHEL isn't do-able due to cost, CentOS isn't do-able because you've just killed it, so away we have to go.
Here [1] is an example of what I dislike. That page doesn't explain if a subscription is for 1 host or all my hosts and it doesn't explain if it needs to be renewed annually or if I get a perpetual license after the first year of support.
I currently have 11 (extremely light usage) CentOS VMs running, but almost everything is Docker containers. I could likely consolidate it onto a single, bare-metal host if I wanted. It would be worse for me, but I could get a single $800 license instead of $8800 for 11 licenses. It's a moot point though. $800 is already too much for the value I'm getting out of it.
I could use the developer program, but I use an issue tracker to track work I do and I back up the whole system nightly. Technically that's production (to me), and I've seen IBM bait and eviscerate someone for licensing using extremely unethical tactics, so I'll never use something that isn't very explicitly free for production.
I think RHEL is technically superior to Ubuntu, but Ubuntu is a far better product when it comes to support lifecycle, licensing, and support. I can spin up an Ubuntu server and unlimited VMs with the promise of a reasonable lifecycle and the option to click a button and buy support.
Where is that in the RedHat world? If RedHat would have released a product like CentOS Stream, but with RHEL branding and a dead simple way to go from a free, community supported version to a paid, commercially supported version then for people like me it makes sense to be the "beta" tester. I think it's a fair trade. Downtime doesn't have a huge impact on me and I'm willing to spend time bug hunting / reporting bugs.
TLDR; The licensing is a massive hassle and is a terrible value proposition for small users. You're not winning any mindshare unless it's as simple as Ubuntu makes it.
1. https://www.redhat.com/en/store/red-hat-enterprise-linux-ser...
It kind of does matter, though, because at least for me, I am much more familiar with my home systems than what I use at work.
I started out using Redhat at work, so I migrated my home lab to CentOS to gain more familiarity, which meant that when new projects started, I advocated for Red Hat. But if I'm forced to migrate to a different production grade distro at home and develop expertise with it, the next time there's a question about what OS to use for a new project, I can imagine myself pushing for the one I will have spent the last few years tinkering with at home by that point instead.
Sadly, the danger of running on free software.
Even more sadly, this puts a bad taste in peoples mouths, making them hesitant to start new projects on free software.
CentOS offered free software, but with unpaid community support, which isn’t guaranteed at all as there’s no contract.
This is an unpopular opinion but this is why I prefer Ubuntu over Debian - there’s a corporation on the other end that’s being paid to update software, and if you choose, you can always upgrade to paid support that is backed by a legally binding contract.
We could debate forever about whether fault lies with projects overpromising, or users having unrealistic expectations, or whatever else, but I don't think that changes the situation.
If you have are paying someone for the software/support, shit still happens, but you have a relationship and ways to get recourse.
I think the movement to this outcome already started in January 2014 with this event:
https://www.zdnet.com/article/red-hat-incorporates-free-red-...
The hypothetical you posed is the actual situation, I am now learning, I have apparently forced on my team. We've ramped up labor 3x revenue preparing product launch in 90 - 180 days. We created an image containing centos 8 , Java , postgres and tomcat a year ago and that what is deployed to beta clients and what we've been testing.
What's ironic is that I sort of went out on a limb with my team by forcing us to go with Linux over Windows and the way I allayed concerns was to ask them to just "wait and see" in hopes that the performance differential would make it a moot point.
edit: after a little thought it seems that moving to RHEL might cost us the least amount of money and downtime. Still sucks and not what we need to be working on right now.
https://web.archive.org/web/20201101131417/https://wiki.cent...
As a sysadmin i have never heard of this and es tun 800 VMs.
That's like polar opposites of stability and bleeding edge.
I will argue that there is less maintenance when handling virtual machines images, because it uses less bandwidth and need less tooling around it comparing with container image based infrastructure.
But in general both are nothing more than the golden image concept.
And that is exactly what IBM is counting on. Vendor lock in.
We are switching to Debian-based distros because, frankly, we don't trust IBM not to knife us in the back even on RHEL for more money. Of course we have the advantage of being able to take the time to convert.
CentOS was acqui-hired because Red Hat's upstream for layered products (at the time mostly RDO/OpenStack and oVirt/RHEV) could not use Fedora because it was too far from RHEL a year of two after RHEL was released, could not use RHEL because upstream contributors would have to pay, and could not use CentOS because its releases had too large delays. The solution was to make CentOS releases happen timely by paying people to make them.
These days a RHEL downstream is not enough for the layered products. Some of them require the kind of bleeding edge feature that is backported every six months to the RHEL kernel, and corresponding userspace changes (BPF, virtualization, etc.) and cannot afford waiting for the CentOS release because development must be done in parallel with RHEL. So the solution was to move CentOS from happening after RHEL to before RHEL which is what CentOS Stream is.
I can confidently say that the reasons are technical because other CentOS downstream have the same needs (e.g. Facebook's) and they also want to send patches to CentOS for bugfixes or features themselves, instead of waiting for Red Hat to find out about that bug, or decide they need the same feature. Plus there's no reason for rebuilds to disappear. The SRPMs will still be released by Red Hat.
CentOS was a community project whose leadership and control was taken over (acqui-hired as you say) by Red Hat and then it's core use case for the majority of people actually using it was discontinued. That is a statement of facts that happened as I understand them, not some spin on my part.
If Red Hat had not stepped in, perhaps some of CentOS problems (trouble getting releases out on time) would have been worse, or perhaps some other companies would have stepped in. We don't know, but we do know that CentOS has not been changed to be something different than it was before. It used to be a free re-spin of RHEL. Going forward it's something entirely different.
Red Hat always had the option to stop funding/providing resources to CentOS and name their new thing something else, but they didn't, and now they've effectively co-opted CentOS to be something different than it was originally intended to be.
Because they don't need it anymore. CentOS Linux or other rebuilds can still exist (just not using the name; I disagree with that but I can understand Red Hat doesn't want its name attached to something that might have large delays in security fixes in the future) if somebody funds it or volunteers to do it, just like CentOS still supports Xen but RHEL does not.
Also for what is worth there have been lots of engineering changes to RHEL in the past couple of years that make nightlies (and CentOS Stream) much more stable than they used to be, especially with respect to regressions. Running CentOS Stream is not going to be like Fedora Rawhide or Debian sid.
I understand the business reasons for doing so. I don't agree with anyone branding this as done for purely technical reasons. Having CentOS Stream may be needed for technical reasons. Stopping CentOS 8 is in no way a technical decision. They are unrelated in any technical sense.
If Red Hat just doesn't want to put resources towards CentOS as it traditionally existed anymore, that's their option, but they deserve any flak they get for taking over an open source project just to extinguish it, since CentOS is in no way really needs to be linked to their Stream product. They could just as easily called it RHEL Stream and said it's free, and it would be a less confusing and more direct funnel of people that want RHEL stability into RHEL subscriptions. Using the CentOS name is just a mind-share grab and screwing over an open source community. They control it so can do it, but that doesn't mean I'm not going to call them out for doing so.
If I effectively took control of the EFF and then a couple years later changed the website copy to say that the EFF is a vehicle for litigating cases that kbenson thinks are important, and then actually changed its actions to do so, would you argue the same points? How is this any different? Something that was a net good for many people has been taken over and eventually killed. I think we're all worse off for that.
I don't disagree.
Isn’t that the crux of the problem? CentOS used to be about “us” (the users), not “them.”
In particular I started doing that and I got to the Sep 2019-Dec 2019 range, around the time CentOS Stream was launched. At that time this:
> For users, we offer a consistent manageable platform that suits a wide variety of deployments. For open source communities, we offer a solid, predictable base to build upon
was changed to this:
> CentOS Linux is a consistent, manageable platform that suits a wide variety of deployments. For some open source communities, it is a solid, predictable base to build upon.
They're a business ... are you honestly and in good-faith actually confused about this outcome?
This is a really smart more on their part to get people to stop doing precisely this, and getting them to pay money for RH. Pepople who are not willing to pay (me included) are now rightly annoyed, but we were never their customers in the first place, so we don't really matter.
Now? “¯\_(ツ)_/¯“ Probably Debian.
I’ve always used CentOS for clusters, but part of the reason for that is that there are some research packages that support RPM installation, but not deb. At least this gas historically been the case.
If a large amount (maybe even a majority) of users have to switch away from CentOS and RPM packaging, I think we’ll see an acceleration away from RPM as a default option.
So, in that way, I think we do matter, but just not on the balance sheet.
I have a hard time imagining, and the only scenarios that come to mind are those where things have gone awfully haywire.
I'm sure I'm missing something. Enlighten me?
If you run a for-profit operation, and downtime is costly, you (or your VP of eng) want a way to pay for immediate assistance from the OS's maker / distributor, when (not if) things go wrong.
There is a difference between asking "how do I ensure there is one throat to choke when things go wrong?", and "how do I minimize the potential for things to go wrong?"
RHEL is a decent solution if you are trying to answer the former question (or both), but many budget conscious orgs focused on the latter and chose CentOS. Red Hat has now pulled the rug out from under them by trimming eight years off the EOL previously committed to with little notice.
EOL in this case means "no security updates" so even if your org was prepared, technically, to deal with a zero-day for example by rolling out an update in a timely manner without relying on paying a vendor for hand-holding, that option has now been eliminated.
Essentially, you now only get the stability and problem-minimization if you also pay the vendor for support. Otherwise you're stuck with a (relatively) unstable rolling release that will keep your internal teams very busy with a constant stream of minor issues, or potentially trying to roll-your-own updates or backports after the EOL for anything serious.
It's difficult to see this as anything other than a naked, money-grabbing betrayal of users.
Depending on how good is the source, its usefulness and dependencies, packaging it to Debian is pretty straight forward. The dh_* helpers[2] does the job automatically most of the time. There is also tools for helping with specific languages, like dh-make-golang, dh-python, etc...
[1] https://packages.debian.org/buster/alien
[2] https://manpages.debian.org/testing/debhelper/debhelper.7.en...
It’s not only the differences in the packaging format that you have to take care of. There’s also version differences, path differences, dependency handling, and many other stuff to take care of. These are the kind of tasks which can’t be automated away and require non-trivial amount of work.
For organizations that maintain tens, hundreds, or thousands of CentOS packages that spans multiple teams, moving to other distros would be time-consuming and costly. It would certainly pay off if it was driven by technical reasons, but for organizations that are forced to switch by this announcement, this is just pure overhead.
That's his stack...
>So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro,
It's not magic, just alien.
> That's his stack...
What’s your point and when did I ever mention Java?
> It's not magic, just alien.
Dumping the contents of an RPM archive on random distros is never going to work except for the most simple of cases.
That says allot about you packing hygiene, and you don't dump it..that you can do with tar alone. You convert it to a deb.
I suggest you read the source code too, because otherwise you can cause real damage if you use it without understanding how it works.
Though my experience with package manager is that dependency management is hell (rife with potential conflicts), so I do see the problem a bit better.
Still, it shouldn't take that long to fix? Like a few days of sprint to setup Nix or something like that?
As for pinning packages, that’s only practical if you’re using Nix. As much as I prefer Nix over RPMs, not all of us have the pleasure of using Nix at work. It’s kind of a bummer because Nix packages are so much easier to work with and maintain compared to the competition.
You build software, you ship it on an OS so it works, cool, this makes sense (I assume you need hardware and VM support, not just VM).
Why would you accept additional risk on the OS if you can easily reduce the risk, and ultimate cost, by going with an OS that has vendor support written into the actual contract? RHEL is 11-13 years total, Windows is... I'm guessing my grandkids will be using some form of Windows 10. CentOS is, and always was a community "best effort", with some serious delays occasionally (not often, but it happened).
A RHEL server license starts at $349, I have to assume that's at least an order of magnitude (or two or three) less than the cost of your software based on the technologies involved (sounds enterprise-solutiony). In other words a rounding error overall.
Cry me a river.
Have you considered Ubuntu Server? "Being boring" and "having no vision" are frequent critiques of Ubuntu, which(as we probably all know) can be the highest possible compliment in some scenarios, like servers. They also have pretty decent LTS.
It is like a completely new OS to me, and I've been hacking on UNIXes for 25 years now.
> In 2009, Red Hat decided to deprecate ifconfig as the default command line network interface management utility, because the “net-tools” package (which provides ifconfig) did not support InfiniBand addresses (commonly used interconnect in high-performance computing applications).
So, many of the things that make Ubuntu look like a new OS to you, were actually decisions made by RedHat years ago, and they will also be present in newer RHEL versions.
I find it easier to configure than SELinux.
Specifically in RHEL/CentOS/Fedora I like that everything in the base system is reasonably well confined out of the box - including random container images that users insist on downloading/running. I don't know if AppArmor is even capable of doing this:
https://access.redhat.com/documentation/en-us/red_hat_enterp...
i.e., if I 'docker run --rm -it debian:unstable sleep 300' twice, then:
$ pgrep sleep | xargs ps -Z LABEL PID TTY STAT TIME COMMAND system_u:system_r:svirt_lxc_net_t:s0:c563,c603 1595289 pts/0 S+ 0:00 sleep 123 system_u:system_r:svirt_lxc_net_t:s0:c25,c163 1595325 pts/0 S+ 0:00 sleep 345
Both containers are confined by the svirt_lxc_net_t domain, but since they have different labels, they aren't able to interfere with each other, or the host system, even if the process inside the container is running as uid 0.
So I defaulted back to CentOS 7. Which I now realize was lucky.
I fully expect this to happen again. CentOS will wither and die because no one actually needs the cutting edge repo -- Ubuntu has a way better process for this. RHEL is build on open source. They publish their SPRM packages. A bunch of people will grab these and start bootstrapping DentOS and everyone will move to this. IBM will be sliced up by PE and RedHat will be owned by someone else. 10 years will go by and RHEL will acquire the leading "DentOS" and today's DevOps will be tomorrow's greybeards and will patiently wait for EentOS to emerge.
I believe Red Hat is anticipating this movement and betting on other things. Playing the long game.
It's sad, the community is sad, the employees are sad. But company-wise it makes sense.
Shocking, because I'd never imagined they'd kill off CentOS 8 so early. CentOS 8.0 dates from Sept 2019, so it's killed in just the 3rd year of its presumed 10 year lifespan. I could read the tea leaves when they announced this Stream thingy recently, but I'd thought they would at least hold off till RHEL9 to pull the lever.
Blindingly obvious, of course, because Red Hat bought CentOS, presumably with real $$$, and IBM bought Red Hat for $34bln.
What's going to happen next? Microsoft buying Canonical and all businesses running either IBM Linux or Microsoft Linux? Crazier things have happened...
What happens in practice with this sort of "rolling release" is users end up patching endlessly in production, which no sane person or organization would ever want to do. This was the exact situation for another Redhat acquisition for years now. JBoss EAP and community editions (wildfly now I suppose), everyone who could moved off of JBoss long ago.
Ubuntu is already the default for people with ML pipelines and more and more vendors are targeting Ubuntu first for their software.
CentOS will be effectively dead for a lot of companies starting next year (or 2024). (At least we aren't planning on licensing 10^5 systems on RHEL...). I imagine for those same companies, RHEL isn't far behind it.
What's even worse here is that at least for us there are some things that we pay for RHEL for. If we switch all of our other servers, those RHEL licenses won't be continuing either.
Obvious, but stupid.
Canonical and RedHat are paying the salaries of the people steering the direction of Linux as a whole. They're forcing you to choose between the two.
That's pretty weak sauce even compared to the five years Debian and Ubuntu offer. And Debian actually supports all their packages, unlike Ubuntu which tricks people into installing unpatched garbage from 'universe'
Ubuntu followed Red-Hat's footsteps away from desktop into the server room, as there is no money to be done there, and it will follow it still, if there is still not enough money on the server.
Just installed OpenBSD for the first time the other day, and am loving it.
But I don't see BSD becoming practical as a platform to run (commercial enterprise) Linux software, when it's already a pain to get packages and support for anything that's not RHEL/CentOS.
Jails are awesome but not containers you're blocked there as well (if you need containers and the tooling around them).
Bhyve performs very well.
>Jails are awesome but not containers you're blocked there as well
What are containers? Ansible with OS-Virtualisation right? So with Jails and Salt/Ansible/puppet or Templates you have your Containers.
OR just take that:
if I remember right technically centos didn't really exist as an entity that could be bought, Red Hat just hired all the developers (there were only ever 3-4 people working on centos). I would guess they are now working on Centos Streams, or have moved on to other things entirely. Its not like Centos has been killed off either, so it didn't cost a lot and this wont really save anything, it's "just" a change of focus.
Microsoft buying ubuntu would be an interesting (and not impossible) move though.
Q4: How will CVEs be handled in CentOS Stream?
A: Security issues will be updated in CentOS Stream after they are solved in the current RHEL release.
They really lagged on the PLATYPUS CPU vulnerability for CentOS 7, because they were dealing with a backlog from the 7.9 bump. Took them several days to get the patches out.
CentOS Stream however is not a Free (beer) rebuild of RHEL anymore, it is an "upstream" for RHEL, so it would not be expected that this flow would work like described for an upstream product
RHEL security fixes for version X.Y may or may not fix security issues for version Z.A on CO, if the are not in sync.
I'm not sure where I claimed it was?
So you're getting some instability by being first in line for updates, but you're still second fiddle for security fixes.
I was trying to point out this isn't different from a security perspective. Yes the rest of the distro is going to almost reach a rolling state which is definitely not something I want in production.
https://oss-security.openwall.org/wiki/mailing-lists/distros
The linux kernel maintainers have a private list where they co-ordinate some of this stuff, and every major Linux distribution will have engineers on it.
That's partly why you see things like OpenBSD etc. being left on the margins. Certain maintainers have been quite vocal about not adhering to embargoes, which really doesn't help them. It's an idealist vs pragmatist thing going on there.
Over time, much of my tooling and deployment processes has come to presume CentOS. If the customer base overwhelmingly runs CentOS, you build process for CentOS.
Thankfully, though, Systemd--for all its faults--has narrowed the painful deltas between Linux distributions enough that a switch back to a Debian target won't be too painful.
Where's your God now, "CentOS is something we can depend on, it's not just a rag-tag band of open-source hippies"?
The December 31 2021 deadline is brutal for high-reliability infrastructure, but it principle the migration path is super simple, right?
I've run most all the flavors of linux and am on the Ubuntu train. Actually, I flirted with the RHEL / Fedora / CentOS workflows as current as last year for a few months. I love the predictability and stability of RHEL on workstations and the thought of something new on a laptop or what not. While I respect the hell out of RH and their products, it just didn't work for me. Fedora is WAY too experimental, lacks supports, and is prone to your system breaking. I know, I know, it is pretty stable and has a lot of support behind it. But after updating via yum and having my WIFI stop working on my 6 year old Thinkpad, that is a deal breaker. I think there is way too much disconnect between their projects. RHEL is super stable, but the packages are severely outdated. Fedora is too experimental, and is pretty much a home operating system and a playground. I know CentOS is free, but depending on your business is paying $300 / year / machine for legitimate support and ticketing really an issue? That's for everyone to decide on their own. I think Ubuntu LTS is the best middle ground for stability and new packages. And if you need paid support and professional help, you can pay Canonical as well.
I could see this coming. CentOS didn't really show a value proposition for RH picking up the tab and supporting it. CentOS was recompiling RHEL and shipping it off; RH needs to keep their PR and image inline and HAD to help, since the whole point of CentOS was "this is RHEL without RH graphics and copyrighted material." IMO, RH felt like they were doing the same thing twice; producing RHEL, then removing RHEL branding and helping package up and compiling CentOS. Due to this, I think the biz folks scratched their on why they needed money, and now we have Centos Stream. I have no doubt another project will spin up taking up the slack of just recompiling RHEL.
Different tools for different jobs. Maybe Centos Stream will be awesome! Maybe it can fill the gap between Fedora and RHEL.
Bear in mind that CentOS was originally an independent project until Red Hat acquired it.
It does support flatpaks.
There is no free openSUSE LTS. The LTS is called SUSE Linux Enterprise Server, costs some money (unless you are a developer, in that case you get free subscriptions) and the LTS lasts for a minimum of 13 years.
The root filesystem uses btrfs, so it's easy to roll back update problems. There is also a newer version that uses a read-only root filesystem and updates are applied to a new snapshot that takes over when you reboot. It's pretty cool.
suse cured my containerlinux wound. (if suse gets bought by ibm than I will be furious or if they kill microos)
Don't know if that applies to rhel
my biggest complaint about ubuntu server is that docker is packaged as a snap. But that takes 30s to fix (includding googling for a fix :) )
apt-get install docker.io(Learning Ubuntu since CentOS went broke their pinky promise to supply security updates until 2029)
If they're just transparently killing of the "free version of RHEL", that surely won't work in anything but name? There's an obvious need for a 1:1 RHEL clone, and due to the license of all software that RHEL builds on, there's no way IBM or Red Hat can stop people from actually building their own "new CentOS" and many companies and communities have done so in the past.
All we have now is Red Hat taking the CentOS branding and running with it. And even that point I don't get - they could have done this with plain RHEL or Fedora branding too.
I get why Red Hat or IBM doesn't like CentOS' existence, but I am fully expecting this won't kill "CentOS the concept". This sequence of events boggles my mind really.
Embrace, Extend, Extinguish.
They're probably banking on it taking a few years for a standard centos replacement to be established.
Yeah, it's all very confusing. The only thing I can think of at the moment is that CentOS has so much mind-share that RHEL wants to tap into that and funnel it back to themselves more effectively. It used to be people knew what Red Hat was and you had to tell them about CentOS, now so many people use and know CentOS I think there's probably a good chance a lot of them don't even know that it's a respin of RHEL.
All of this only makes sense to me if the whole point is to leverage the popularity of CentOS into more RHEL subscriptions by providing a product that's more annoying for most people that care about a stable server (because it's backing their business) to use because it's less static.
Personally, I think it doesn't matter why Red Hat bought CentOS, what matters is what they just did, and as I think that's purely self serving (and to the detriment of the public and community) and if there are apologist engineers here that work for RH, perhaps they should look closely at how management is managing them, because of course management is going to present it in a way that tries not to alienate their staff and community. The results speak for themselves though, CentOS in the form that so many people relied on is effectively dead in a year.
Also, conditions change. RH might have decided that Centos had become a bit too successful and was cannibalizing actual RHEL sales (covid year, everyone is hurting, people try to skimp on licenses...).
Does this mean that CentOS 8 is EOL come 2021? Weren't maintenance updates meant to go to 2029? What about everybody who built their product on the assumption that there would be a stable CentOS until then?
It used to be this. https://web.archive.org/web/20201101131417/https://wiki.cent...
That page is a Wiki and here is the diff between the current version and the previous: https://wiki.centos.org/action/info/About/Product?action=dif...
They've just eradicated almost all mentions of CentOS 8 from their main website. So: yes.
> What about everybody who built their product on the assumption that there would be a stable CentOS until then?
They just got what they paid for?
Haha, fair. To be honest, I'm surprised it took this long for it to happen after CentOS joined Red Hat. I wonder if the IBM acquisition had any influence on this.
Funny, but isn't this totally reasonable grounds for an adverse possession claim against RHEL?
If a business claims they're going to keep doing something, and you build your business on that claim, and then they change their mind, you can have grounds to sue. Or, at least, that's what I vaguely remember from reading about AP law.
Not really. If you depend on CentOS it is reasonable you would contribute to it. There has to be a nonzero number of CentOS users that contributed to the project ("paid") that are now left holding the bag.
Not really.
Just TRY to "contribute" to CentOS. You can't.
CentOS hasn't been a "community" enterprise operating system for years.
https://blog.centos.org/2020/12/future-is-centos-stream/#com...
https://join.slack.com/t/hpcng/shared_invite/zt-gy0st6mt-ijg...
I don't want to sound too "tin-foil headed" but I guess now that RedHat has hired the main CentOS dev(s?) this change comes from RedHat. I can't imagine the CentOS user base wants this direction for the CentOS project (or maybe thats just my lack of imagination...). People who use CentOS want a boring Linux distro like RHEL. They just don't want to pay for RHEL subscriptions.
There's a lot of people using CentOS indirectly, through CloudLinux. Whatever happens there, a lot of people will be affected.
My familiarity with Amazon Linux is about 4 years out-of-date these days, but it was a RHEL/CentOS clone with a number of the core libraries like glibc being updated and maintained by Amazon on an independent life cycle.
Is CentOS the upstream for Oracle Linux? Instead of which comes CentOS Stream and then the question is what will Oracle do? Would they even try to keep the old CentOS concept alive?
EDIT: This may be inaccurate; see https://news.ycombinator.com/item?id=25348496
I thought that Fedora was already serving this role
CentOS Stream is basically "the next x.y release of RHEL". Some updates, like GNOME updates and new hardware enablement, will be present in CentOS Stream a few months before they are released to RHEL and CentOS as part of a new x.y-release.
That is only true if CentOS continues to be widely adopted, with this move by RedHat i do not see that continuing, I am sure many org's right now are looking for options to move off CentOS / RHEL stacks.
How dare they want a free operating system?
Note that the announcement blog post points folks to using RedHat instead.
Embrace, Extend, Extinguish succeeded?
I use CentOS a lot for prototyping projects destined to be put on RHEL servers. I like it as a try-before-you-buy version of RHEL, and this change makes that use case a lot less useful.
So you can't make a proof of concept with the RHEL developer license in which you let "the business", customers, etc. toy around for a while.
The instructor told us if we wanted to try some of the things we were doing in class to experiment more, we could try it on CentOS. it was the practically the same. This was before Red Hat “ acquired” them.
However, doing this will effectively make CentOS as a server OS useless for the most of us. "But Facebook uses it" - well, yes, with thousands of engineers Facebook could run their own distro and still have success if they wanted. Most useless argument ever.
Time to move on and find something else. Maybe good old Debian.
Since Facebook actually uses kernels from Fedora Rawhide (necessary for btrfs support I guess), their systems are nowhere near the CentOS you and I would use.
I think the doom and gloom is a misunderstanding.
CentOS Stream
Continuously delivered distro that tracks just ahead of Red Hat Enterprise Linux (RHEL) development, positioned as a midstream between Fedora Linux and RHEL. For anyone interested in participating and collaborating in the RHEL ecosystem, CentOS Stream is your reliable platform for innovation.
That doesn't seem to be what you think it is, at least in my eyes. I'm definitely not looking to run something positioned between Fedora and RHEL. There's already enough updates every month (including multiple kernel updates a month sometimes) that it's hard to keep the fleet updated. I definitely don't need stuff ahead of RHEL where I can assume I'm a bit of a guinea pig to test out the coming RHEL update.
"Q6: Will there be separate/parallel/simultaneous streams for 8, 9, 10, etc?
"A: Each major release will have a branch, similar to how CentOS Linux is currently structured; however, CentOS Stream is designed to focus on RHEL development, so only the latest Stream will have the marketing focus of the CentOS Project.
"Because RHEL development cycles overlap, there will be times when there are multiple code branches in development at the same time.This allows users time to plan migrations and development work without being surprised by sudden changes.
"Specifically, since the RHEL release cadence is every 3 years, and the full support window is 5 years, this gives an overlap of approximately 2 years between one stream and the next."
Also from Q2:
"We will not be producing a CentOS Linux 9, as a rebuild of RHEL 9. Instead CentOS Stream 9 fulfills this role. (See Q6 below regarding the overlap between concurrent streams.)"
So it sounds to me like my assumption is correct: There will be separate streams reflecting each RHEL release.
Read the whole FAQ. This is not what people think it is.
Right now, in RHEL 8.2, if a package needs a bug fix, it will be back-ported so that you get the fix in the existing running version of that package that was shipped in 8.2. On point releases, RHEL (and thus CentOS) may choose to back-port a feature, functionality, or choose to update the version of the package that is running to a newer version that has those features or functionality (or to bring it in-line with back-patches, I assume). When you update to a new point release, this gives you a single large update set that you can test to make sure functions well in your infrastructure. There have been points in the past where changes in point releases have required us to make changes to our configs or setup to deal with the RHEL/CentOS's point release changes (even though it's supposed to be rare, it happens, but it's mostly contained to these big testable update sets).
CentOS mirrored this exactly, because it mirrored RHEL.
Now CentOS is going to do something different, and these updates that would be relegated to point releases look like they are going to come down continuously. While not as problematic as something like Fedora, this is still something that groups specifically chose CentOS to avoid.
It's nice that Red Hat is offering something to allow people to get fixes and features sooner than at point release times, but to switch CentOS to only providing that is extremely problematic to the very large community that expects otherwise, supported CentOS, and has done both since prior to Red Hat hiring some of the main CentOS developers and effectively controlling the project, and is notably different than what CentOS has always traditionally attempted to provide.
Rolling forward to the head is required to get the most recent security updates. Which isn't that far away from how centos works today. With rhel you get security updates for the point releases (8.1,8.2,etc) for a while after the new point release comes out. With centos, the day that the newer version drops, they don't tend to roll security updates into the older ones.
Q4: How will CVEs be handled in CentOS Stream? A: Security issues will be updated in CentOS Stream after they are solved in the current RHEL release. Obviously, embargoed security releases can not be publicly released until after the embargo is lifted. While there will not be any SLA for timing, Red Hat Engineers will be building and testing other packages against these releases. If they do not roll in the updates, the other software they build could be impacted and therefore need to be redone. There is therefore a vested interest for them to get these updates in so as not to impact their other builds and there should be no issues getting security updates.
"If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options."
Of course no one want to run CentOS Stream because it's going to be broken / unstable, completely the opposite of what CentOS is.
Fedora -> RHEL -> CentOS
with the addition of CentOS stream it was becoming
Fedora -> CentOS Stream -> RHEL -> CentOS
now what it is
Fedora -> CentOS Stream -> RHEL
This is just a rebranding move to push businesses that were using CentOS to actually buy a RHEL license, lol.
RHEL is nearly identical in practical use because they use the same libraries and tooling for the most part. I guess I've always just assumed CentOS was "Free RedHat".
So basically not what your comment is trying to imply here. Also, what is "lol" about it?
I could be missing something and I don’t think the motivations are strictly mercantile, but this does make CentOS Stream much less appealing (compared to RHEL) than CentOS 7/8. I am personally not that affected by all this (my org uses RHEL) but it’s a huge hassle for a good number of serious CentOS users.
...sounds like what they expect
> it removes confusion around what “CentOS” means in the Linux distribution ecosystem
This justification for the change seems like a solution to a problem that doesn't yet exist but probably will soon!
I've been leaning on Debian-based distros for my own servers for a while now, but I still use CentOS in the lab. Hopefully RedHat provides an easy way to legally develop on RHEL without messing with a license.
_In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers._
I believe we were one of the first 10 or so, but I don't remember exactly when it started.
Your only option is to migrate away from RHEL/CentOS, period. It's likely that Red Hat doesn't care much about us smaller orgs with only 100-200 servers/VMs though. Sad day.
Summarizing the FAQ:
- the bits are the same, the differences are the terms of use and the self-support level
- one subscription per user
- allowed to use on 1 physical system (up to 2 processor sockets, 16 VMs)Maybe they have some grand scheme I'm not seeing but it feels short sighted.
- CENTOS fills a need, that many users have and superficially it looks like Red Hat (IBM) is now abandoning addressing it. On the other hand Red Hat does offer RHEL for free (gratis) [0] and that should fill the needs of CENTOS users (right?). However it would have been much better if that option was mentioned in the announcement.
- I thought Fedora was upstream of RHEL. However after thinking more about it I realised that RHEL has a significant delta over Fedora. I 'm guessing CENTOS stream will be partway between Fedora and RHEL. It makes sense from Red Hats open development approach to have the delta between Fedora and RHEL happen in the open. Done right that should strengthen RHEL.
- Why the rush to drop support for CENTOS 8? I m sure some people are using it in production and they are unlikely to to want to move to this new CENTOS stream. It's a new OS distribution with a philosophy different to the one that was right for them!
Overall I 'd prefer if the new thing was called RHEL stream and provided for free (gratis) as CENTOS stream is. Also making more explicit the RHEL availability for free instead of having competing brands would be good. Now that there are competing vendors (Amazon Linux, Oracle Linux) trying to entice users it'd be better to strengthen RHEL brand rather than dilute it with multiple offerings. Unless RedHat/IBM plans to pull the plug on option [0].
[0]: https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-d...
They offer a no-cost "developer subscription" of RHEL, but I'd wager the majority of users are running CentOS on servers.
Disclaimer: not affiliated with Oracle in any way. This is just the closest thing to a plain RHEL8 clone I know of, other than CentOS8.
Speaking entirely for myself, opinions my own, may not reflect my employer etc. etc:
I came in to this job expecting OL to just be a CentOS clone, and not really expecting much from the kernel they ship with it.
It is both a CentOS clone, and a bunch more. Oracle takes the CentOS packages and applies bug fixes etc. that upstream RedHat has failed or refused to apply, so I've actually found OL to suffer from fewer problems than CentOS, and we've even had to apply mitigations for CentOS 6 for stuff we haven't had to do to any other OS we distribute. For entirely selfish reasons, I was really glad to see CentOS 6 go end of life last month.
On top of that the OL team hires a significant number of upstream kernel developers, including the core maintainers for a number of components, like XFS, Xen, and so on, and produces the Unbreakable Enterprise Kernel (a really curious choice of marketing terminology), that incorporates mainstream bug and security patches, while being closer to mainstream than RHEL/CentOS, and the kernel patches submitted upstream by OL devs.
I would point out, I'm not in the OL org, I have absolutely no idea what this change means for Oracle Linux. Oracle Linux is based off the CentOS sources as that's the only way that RedHat was making the source code to their distribution available (there way of meeting the terms of the GPL). RedHat has to make their source code available in one form or another so I can't imagine that this would have any impact on OL, but that's entirely guess work.
If that's true, I wonder how Oracle got some of their 8.x releases out much earlier than CentOS. (Oracle Linux 8.3 2020-11-13 vs CentOS 8.3 2020-12-08, Oracle Linux 8.0 2019-07-19 vs CentOS 8.0 2019-09-24.) I'm assuming here without verification that both track the RHEL 8 point releases.
>Yes, but only one no-cost Red Hat Developer Subscription can be added to a user account. While it is possible to have each developer register for their own account, this is not ideal from a management or efficiency standpoint. For example, if a company wanted no-cost Red Hat Developer Subscriptions to cover 100 developers, each developer would need to individually register and independently create 100 accounts that need to be tracked and maintained. For enterprises that use Red Hat Satellite to manage multiple systems, all 100 accounts would need to be added individually. Accepting the terms and conditions and renewing the subscription annually would need to be done individually and manually for all 100 accounts. Staff turnover in the development team would create additional management challenges with individual accounts. Therefore in terms of lost productivity, managing individual no-cost subscriptions will not be cost-effective for many groups.
Many development organizations benefit from having Red Hat Developer Support. Cost effective bundles are available that include support with a pack of 25 Developer Suite subscriptions that can be managed from a single account. Each of these subscriptions is based on systems, rather that users.
I had a bad feeling about the CentOS project when Redhat became involved as more than an upstream RPM source. I hope CentOS isn't turned into another Fedora.
I'm sure many of you will be happy to tell me that I'm wrong. Please do.
My ideal outcome would be if they would allow using real RHEL for any hobby projects and for commercial projects with income below some threshold, so I can start and grow with RHEL and then switch to paid option when I'd have enough income to warrant it.
But it's IBM, so probably I'll have to switch to Debian which is good enough, but I'd miss SELinux, better systemd integration and more polished packages.
Not exactly unexpected, but disappointing: if you want to continue using something like CentOS, pay for RHEL. Lots of web hosting providers will be quite concerned.
I don't think this will hurt RedHat at all. How many RHEL customers are actually generated as a result of providing CentOS for free? Not many I suspect.
Those who want to learn about RHEL can still get Fedora, or CentOS Stream, or a RedHat developer license.
Now the closest alternative is Canonical with Ubuntu Server which can be installed wherever with no strings and support purchased as required.
I think I'm going back to Debian for my servers. i wish they add 10 years lts though.
If you want guaranteed updates backed by a contract, choose Ubuntu or RHEL.
I really don't get this fascination with 10 year LTS. Why is it so hard to upgrade in half a decade ? I mean this is such an arbitrary number. If RHEL started offering 50 year support, people will complain that Debian is 1/10th of RHEL.
If you want to know more I wrote about it in another comment: https://news.ycombinator.com/item?id=25348914
The ideal situation is never having to upgrade: you buy your computer, install the operating system, and it works the same until you retire it. If your computer has a 5 year warranty, you expect to use it for at least 5 years before retiring it.
A 5 year LTS is only 5 years if you install the moment it's released, but that's not usually the case; for instance, there's a new Ubuntu LTS release every 2 years, so in the worst case your LTS installation will last only 3 years. Now consider the "10 year" RHEL LTS: in the worst case (you installed RHEL 7 just before RHEL 8 was released), your LTS installation will last 5 years, perfectly matching the warranty period.
Most of those hosting customers are not tech companies building fractionally "innovative" CRUD SaaS apps. They're SMEs who use their apps and databases to do real work: organizing their employees, procurement, running payroll, managing delivery routes, order and stock management — boring stuff like that. They very much do not want to have to significantly rewrite the back-office systems their businesses rely on because the OS changed under them. They want it to keep working for decades with as little redevelopment as possible.
Security patches are not backports, they are security patches that obviously should be for free, Redhat is making loads of money off free software already.
If RedHat promised to keep CentOS 8 around for 9 more years, then yes, that is very disappointing. It was a stupid promise to make in the first place, but still disappointing.
```There are different kinds of CentOS users, and we are working with the CentOS Project Governing Board to tailor programs that meet the needs of these different user groups. In the first half of 2021, we plan to introduce low- or no-cost programs for a variety of use cases, including options for open source projects and communities and expansion of the Red Hat Enterprise Linux Developer subscription use cases to better serve the needs of systems administrators. We’ll share more details as these initiatives coalesce.```
Probably should have had their ducks in a row there to announce both things at once, I think.
This way they can keep up the illusion that they do everything with good intentions and did not expect people would get angry. “We are not the baddies, here’s some sweetener to prove it!”
Q: is the sky blue? A: no. it's blue.
more bugs, surely....
This announcement is a kick in the teeth to those customers, as the transition to RHEL 8 for these pre-production environments will feel very much like a shakedown.
I feel this is tremendously damaging for Red Hat's reputation and the goodwill developers had towards them.
Pre-2014 it was fairly obvious that a full clone of a commercially supported product, with the proverbial 'just a search-and-replace of the product name', was going to attract interest & action from upstream.
OTOH in the ~25 years I've been using Debian, I've never been (rudely) surprised by one of their announcements. Their social contract [0] is clear on every point that's relevant to users of an OS, especially users looking to commit long term to a platform.
A revived Scientific Linux could easy suffer the same fate. No one truly want to maintain a RedHat clone for little to no pay, while at the same time dealing request and complaints from companies who wants the benefits of RHEL, but no pay for the development and maintenance works done by RedHat.
Realistically it's some bean counter at IBM who asked why RedHat is giving away the very same thing they're trying to sell. Said bean counter do have a point in my opinion.
Goodwill. I use CentOS and until now if I had a project were Linux support had been important I would have gone with Redhat. They can rot in hell now.
IBM strikes again.
> Easy remote management.
Just out of curiousity, are you SSHing in directly, or installing the Teamviewer RPM on all of them?
Plus, I'm running Pi-Hole in docker and I ssh to upgrade it from time to time, (docker pull, docker-compose down/up, etc.). I haven't bothered automating this because some things change between releases and I still end up doing manual configuration changes.
Also, I am not one of the highest upptity-ups in the company or anything, but from the inside: I see no evidence whatsoever that this is the result of IBM anything.
Fedora Silverblue could be interesting alternative to regular Fedora then, since you can boot into or roll back to a previous release. You can also pin a known-good OSTree commit, so that one could always boot that version.
In my experience (just went through that, F32 -> F33), it's painless but definitely not "an automated thing that happens while you go for coffee"; each machine took a whole day, it's a huge download (many gigabytes) and the install itself seems to be severely fsync-limited (several hours while the progress bar slowly fills and the disk light is lit all the time; after the fact, "journalctl -b -1" shows it was installing/cleaning package by package all that time).
That should address most of the issues you mention. :)
CentOS 8 had been mostly working well for me, barring a few missing packages that were easy to port over myself, and I was really thinking of moving all my boxes to CentOS. I'm glad this news came out before I did; I don't know what I'll use instead, but it definitely won't be CentOS/RHEL.
I haven't tried CentOS Stream, but out of curiosity: if it's similar to the RHEL patch releases, how will major (like from RHEL 8 to 9) changes be handled?
Most people (including me) never looked closely at "CentOS Streams"; from what you said, it seems like it's "a preview of the next RHEL 8.x". The announcement today made it appear as if it were "a preview of RHEL 9.0", which is a much bigger change for those who (like me) expect to install a CentOS 8 box somewhere and keep it mostly untouched (just applying the updates) for ten years.
Does this mean that CentOS 8 is EOL come 2021? Weren't maintenance updates meant to go to 2029? What about everybody who built their product on the assumption that there would be a stable CentOS until then?
1. They can start paying RedHat
2. They can hire/delegate someone to maintain patches for them
3. They can migrate to something else ;)
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
(My opinions are my own, and do not necessarily reflect those of my employer; I'm in support at the moment, so foresee myself having to deal with the aftermath of this CentOS decision a year from now)
Every time a corporation takes over an open source project it absolutely ruins it. We need some kind of "enterprise open source cabal" of people who can work on open source projects without any IP or copyright going to the company so the companies can't unilaterally screw the project.
At risk of angering the beehive, I will pre-emptively remove my benefit of the doubt to Microsoft as well before I become too dependent on VS Code and its proprietary extensions. I had been ignoring that red flag and with these news my gut instinct has turned to a fight or flight response.
Nobody needs or wants another Fedora.
This seems like a round-a-bout way of killing the only RedHat alternative to the expensive commercial version of RedHat.
If there is no Centos9, I'll probably move over to a Debian alternative. Just because of the principle of the thing. Better that than validate the "acquire and destroy" strategy that seems to be used by every big tech company like IBM, Microsoft, Facebook and Google.
And to top it off, today was the day when a CentOS 8 kernel update broke ZFS. Again.
This issue? https://github.com/openzfs/zfs/issues/11307
For comparison, I have a Debian 10 box running since February. Also runs ZFS, updates and restarts every day, and absolutely 0 issues with that setup.
I've been experimenting with openSUSE lately. So far so good. Only if zypper can download packages in parallel, I don't have to wait for eons to build images.
I seam to have more issue at work dealing with older versions of packages on CentOS that lag behind up to date packages on "unstable" distros.
As a fan of rolling release (btw I use arch), I will love not having to deal with EOL CentOS upgrades at work.
I'm very pessimistic on what this means for the RHEL ecosystem as a whole...
If I understand correctly, CentOS Stream 8 should be relatively stable just after a RHEL 8.x release, because the pipeline will contain just minor updates. But as the next "x+1" release approaches, the pipeline will contain whatever is being tested for inclusion in it. This makes CentOS Stream unsuitable for the vast majority of people that currently use CentOS in production (i.e. the people that choose CentOS over something else like Debian Stable or Ubuntu LTS).
One can argue that these people can go buy RHEL licenses, but they most likely don't do that already because they see support as the value added by RHEL-proper and they can support themselves just fine. Many will also have RHEL instances along CentOS on systems that need vendor support, but pushing them to license everything may also push them into another direction altogether. Suddenly, standardizing on Ubuntu LTS (with paid support for a subset of instances) starts to make sense.
I think Red Hat (or maybe IBM) is vastly underestimating the value of CentOS in keeping the whole RHEL ecosystem competitive. They may be setting themselves up to be another SUSE.
And we're all worse off for it.
Thanks, for all the fish, CentOS. The city of Tuttle, Oklahoma is grateful.
Oh man, I had completely forgotten about that (although I suspect most people have by now)... since reading your comment, though, I have been sitting here giggling like a little kid just thinking about it. Thank you!
--
For anyone who reads this and doesn't understand the reference to Tuttle, Oklahoma, well, go seek out the answer and prepare to be entertained, my friend!
--
UPDATE: Actually, I'll save you some trouble, since I decided to go re-read all the details again myself:
Start here, with a story from The Register that summarizes what happened: https://www.theregister.com/2006/03/24/tuttle_centos/
Afterwards, you'll almost certainly want to read the entire e-mail thread yourself. Fortunately, the Internet Archive has us covered: https://web.archive.org/web/20060326091856/https://www.cento...
Finally, thank bubblethink (with an extra Internet point, of course) for reminding us all of this incident!
The thing though is, developers actually involved in this project had strong opposition to the way this was handled, but none of it was heard and the "decision was already done" by people who hardly had any role to play on the day to day community involvement with the project. I am pretty sure it was the same with this CentOS decision.
If you work in an industry or corporation that is highly security conscious, i.e. that prizes risk mitigation over using the cutting edge or getting to market first above all else, then you won't be able to use nightlies.
Security policy will dictate that you use use a stable versioned release, that the release be vetted through scripts/STIGs, and that the release be installed by Security+ certified and blessed admins.
I just successfully pitched we go with Centos 8 at work. Tomorrow I have to go in and explain why we need to choose Centos 7, or Ubuntu. In my industry this kills Centos, it's as dead as Mr. Praline's Norwegian Blue [1]. I suspect that was IBM's intent all along, though it's only suspicion.
> Security policy will dictate that you use use a stable versioned release, that the release be vetted through scripts/STIGs, and that the release be installed by Security+ certified and blessed admins.
I'd be quite surprised if your "security policy" has all of that and yet doesn't have a requirement for "commercial support" (i.e., Red Hat Enterprise Linux).
Besides, if $employer "is highly security conscious", your machines are almost certainly airgapped and getting their updates from a Satellite server that you're already paying Red Hat for.
AFAIK, CentOS is not now -- nor has it ever been -- "certified" for anything. Did that change at some point without me noticing?
* You can use reposync to update a copy of EPEL, PowerTools, etc.
* You can use yum -q deplist PACKAGENAME to list dependencies
* You can copy the necessary RPMs to a DMZ and apply security scans/tests, then take them to your boxes and install them
Also, any corporation or organization like I'm talking about has internal approval/certification of software as usable on their networks. The Army formalized this as the CoN, Certificate of Networthiness.
Of course, with this it might be even slower, in that first RHEL pushes out the security update, and then people will start looking whether that change needs to be forward-ported to CentOS stream, or whether it can be used as-is etc.
I assume CentOS Stream will be based on the previous RHEL minor version release which would be stable and puts improvements for the next minor version release before RHEL releases it which doesn't sound like the end of the world like some people seem to think.
You actually get improvements earlier than later and you also get to throw feedbacks in before the next minor version gets released which feels more community oriented.
Unless your server needs absolute stability like RHEL (in which case you might as well just pay for RHEL), then it seems ok to use Stream.
For those that need absolute stability but have no decent flow of income, then you might be burned but I suppose a new community supported RHEL clone would come out sooner or later.
That said, I think a lot of issues I've seen would be helped by people not being so afraid of rolling release , so maybe reconsider the fundamentals before being too chicken little. Also, I suspect this could be the kick we all need to start pushing nix and guix more seriously.
I like stream. A handful of my side projects are running it now, but IBM done fucked up with this move.
ps: please, dont go trusting oracle
I'm debating whether or not to downgrade to CentOS 7 to at least keep going until 2024, instead of 2021 with CentOS 8.
Hopefully, some other player steps up and creates a similar offering.
Also, I've been irked lately about them deprecating virt-manager and pushing podman. I don't mind alternatives, just keep the feature parity when you switch. Cockpit is fairly limited compared to virt-manager.
https://linux.oracle.com/switch/centos/
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
I liked them because I could have a rock solid environment at work and play with technologies with centos at home.
Fuck all that I guess. If this is the game then I'm not renewing my RHCSA certification and I'll be considering definitively switching to Ubuntu.
I recently set up a digital ocean droplet with the default Ubuntu 20.04 Server image to host my web app. I don't like how I'm in charge of installing security updates and rebooting it (I don't really care about downtime), and I really don't like how I don't really remember what packages and commands I ran to install everything.
Presumably, this is what digital ocean app platform is for, where I could just provide a docker container. But the specs of the 5$ app platform container were half as good as the 5$ droplet, and I can run multiple things on the droplet in the future.
Too bad Scientific Linux was dropped in favour of CentOS. Perhaps scientific community will revive Scientific Linux or something like that. Cant wait for what comes out of this.
Makes sense commercially from RH's point of view. Boring and stable is now chargeable.
So maybe if this pans out, a lot of projects will now be able to use RedHat EL proper.
They also conveniently waited until right after EL6 EOL...
If RH doesn't release some "Academic Version" (but who would even trust that at this point?), then I suspect revival of Scientific Linux or adoption of shudders Oracle Linux is more likely than a switch to Debian. FreeBSD is probably a non-starter.
That has nothing todo with a Distribution, maybe with linux but Redhat...pff....Looong-LTS that was the plus.
Oracle Linux...no one and especially cern would ever risk that.
As stated in https://www.redhat.com/en/blog/centos-stream-building-innova...
"CentOS Stream now sits between the Fedora Project’s operating system innovation and RHEL’s production stability"
So if we compare to Debian, this means:
Fedora <=> Debian unstable (Sid)
CentOS Stream <=> Debian testing (currently Bullseye)
RHEL <=> Debian stable (currently Buster)
Rawhide <=> Sid
Fedora <=> Semi-stable-ish but short-lived and moves fast.
CentOS Stream <=> Bullseye but possibly less stable than Fedora in parts.
RHEL <=> Buster
FreeBSD 13-Current - Fedora Rawhide/Fedora
FreeBSD 12-Stable - CentOS Stream
FreeBSD 12.2-Release - RHEL
CentOS Stream will be the testing for the next minor release of RHEL, i think the closest in debian would be stable with the proposed repo fully enabled.
Between Debian and RH i see the following equivalency.
unstable (sid) - Fedora Rawhide
testing (bullseye) - Fedora, although not 100% equivalent as not all fedora releases became an RHEL, but fedora does act as testing for RHEL.
stable (buster) - RHEL
CentOS Stream is between testing and stable.
Jim Perrin explains it also here: https://jperrin.org/blog/thoughts-on-stream/
If you successfully fill that void, maybe you too can be acquired by IBM/RH in a few years as they repeat the cycle.
This is an opportunity. Imagine Amazon stepping in and funding the CentOS replacement. They'd capture a huge chunk of the SME market within two years.
Amazon already has its own distribution in the form of Amazon Linux, a derivative of RHEL. Seems like a short walk to provide an unsupported, Amazon branded, bare metal RHEL-based distribution that also happens to align its users with AWS. The really smart thing would be to start there but then fork slowly and eventually diverge from RHEL in fundamental ways.
As per the FAQ though I suspect there is more to this than meets the eye. Two things strike me: 1. The suggestion that low or no cost options for RHEL are coming for certain categories of user. 2. As much as Stream will be a rolling and "beta" channel, Fedora/CentOS/RHEL already have testing repos within their release process so Stream may not be as unstable as this might first suggest.
With local staged repository mirrors Steam may end up being less volatile than the existing point releases which were notorious for breaking things at times.
Seriously, think about it. Yes, users of CentOS Stream will be essentially be doing beta-testing for RedHat, but it's a type of beta testing that until now didn't even exist; any instability, conflict, or vulnerability that enters into CentOS Stream is one that would have entered into production RHEL systems otherwise. So the net effect is fewer of those for RHEL, but the same number as before for CentOS. CentOS users lose nothing they ever had.
Oracle Linux actually seems to be the best way out (at least for now)
/me shudders.
Actually just installing it on a new 5900x now after aborting CentOS due to it becoming abandonware and having its name stolen by IBM.
You'll either be forced to buy licenses or use a far less stable and secure version of stream. Or, of course, you can rent VMs with maintained distros from Amazon, Microsoft, Google, etc. on their cloud platforms.
IBM bought Redhat for a reason, and if history is any guide, they'll begin aggressively pursuing large companies, governmental, educational, etc. users of Centos and push them to buy support licenses of Redhat.
So if we compare to Debian, this means:
Fedora <=> Debian unstable (Sid)
CentOS Stream <=> Debian testing (currently Bullseye)
RHEL <=> Debian stable (currently Buster)
quote source: https://www.redhat.com/en/blog/centos-stream-building-innova... (linked from the article)
It's just a simple common-sense scheme, it's not the result of deep thought. What you're struck by is how marketing-oriented the RedHat repository naming scheme seems to be...
in debian testing is the next major version, while centos stream is testing for the next minor release.
It is fedora that is testing for next major release.
sid would be similar to fedora rawhide..
sid <=> fedora rawhide
testing (bullseye) <=> fedora, altough not every fedora became a rhel
stable (buster) <=> rhel
centos stream would be likely similar to having stable with the proposed repo fully enabled.
So now it is just "Operating System", maybe they should rename it IBMBetaOS or something like that.
In my corner of the world Ubuntu plays no role at all on servers. It's all CentOS/RHEL here.
At previous work they moved away from CentOS to use Ubuntu because libc was just to old, actually everything was old.
It'd be very interesting for us in terms of priorising supported distros. A bit of googling didn't lead to much.
You could be biased by your own job/experience. Most IT doesn't run on the Cloud or in Kubernetes (yet).
Those are numbers for EC2 so a fairly accurate measurement.
I work in higher ed and happily pay the premium for red hat.
We only have about 500 systems in our top 10 research/health based institution.
I’m really tempted to spin up an in-house replacement for CentOS. Not strictly to defer adoption of RHT, but instead to fill the necessary gap for those who have gone “all-in” with CentOS.
Those in higher ed have access to all the necessary components required to produce CentOS. All they need is leadership.
Looking for both volunteers or people who want to be paid for their efforts. Join us to secure Enterprise Linux as a free (as in beer and freedom) for the foreseeable future.
Yes, Oracle sucks but it’s a better RHEL build than CentOS was.
https://join.slack.com/t/hpcng/shared_invite/zt-gy0st6mt-ijg...
Ubuntu is already owned by a large corportation.
No mention of OpenMandriva as a alternative RPM distro.
The new CentOS "Stream" sounds like it will be more like Debian Testing.
As stated in https://www.redhat.com/en/blog/centos-stream-building-innova... (linked from the article):
"CentOS Stream now sits between the Fedora Project’s operating system innovation and RHEL’s production stability"
So if we compare to Debian, this means:
Fedora <=> Debian unstable (Sid)
CentOS Stream <=> Debian testing (currently Bullseye)
RHEL <=> Debian stable (currently Buster)
Perhaps the closest is "the DAK upload queue for Debian stable", but that tends to contain mostly security updates, and according to other posts in this thread that is the one case where CentOS Stream is not an upstream of RHEL.
CentOS Stream contains feature backports, which generally don't happen in Debian stable, but it's only very specific backports, not every package gets updated like in Debian testing.
I'd put it like:
Fedora rawhide <=> Debian unstable
Fedora <=> Debian testing
CentOS Stream <=> DAK upload queue for Debian stable
RHEL <=> Debian stable
I guess there are only so many ways to organize a distro.
Right now, I've got a bunch of CentOS 6 servers with 2.6.32 kernels that are freshly out of support this month. I was hoping to replace them with 8, but now I'll probably have to settle for 7. At least I can take consolation in the fact that I haven't been called in to troubleshoot any CentOS 5 servers lately.
deb http://deb.debian.org/debian buster-backports main contrib non-free
deb-src http://deb.debian.org/debian buster-backports main contrib non-freeThe major release of RHEL is usually forked from a Fedora version about a year before the major release, so with some exceptions software versions tend to be about a year behind those in a Fedora release initially, and then as RH backports patches rather than revving versions, drifts further.
It's the patches and smaller updates — and new hardware enablement in the full-support phase — that will be landing in CentOS Stream. Previously, this stuff was developed internally and only released to the world at the minor-release drop every six months. Now, it'll be developed in a shared space. So what you'll have in CentOS Stream is whatever is intended to ship in a RHEL minor update within six months.
There may occasionally be a situation where an update introduces bugs into Stream that would have been caught by QA before a public minor RHEL release and subsequent CentOS Linux rebuild. But I don't actually expect that to happen enough to worry about in any case where you can justify not paying for actual supported RHEL in the first place.
> CentOS Stream is focused on the next RHEL minor release. This means we are improving and influencing the shipping releases of RHEL. Fedora ELN is a testing area for changes that may occur in the next major release of RHEL.The CentOS Project cannot and does not speak for Fedora
CentOS Stream will be the upstream for RHEL minor branch development. This is actually a huge thing that I think people are missing: previously, once branched from Fedora, RHEL development did not happen in the public eye. With Stream, it will. This is huge and awesome good news. However, that development will still be entirely Red Hat curated. This is different from Fedora, where we make community decisions with Red Hat's engineering input as a stakeholder but not the decider. (See for example btrfs as the default filesystem.)
My guess is that Stream turned out way less popular than their sponsored hoped (who cares if it's developed in the public eye if it's entirely RH curated anyway). So CentOS 8.x had to die.
So why the negativity at this "huge and awesome good news"?
And you know that's not the reason for the negativity, so I don't know why you're being so flippant about this. Nobody has a problem with the idea of 'CentOS 8 Stream'. They have a problem with this being the replacement to CentOS 8 Linux because it doesn't fulfill the same use-cases.
* Use cases which actually despite the fears will be covered just fine by Stream * Use cases which will be covered by the upcoming expanded no-cost/low-cost RHEL programs * Use cases which, yeah, aren't covered
It's my estimation that the first two are actually the vast majority. I don't mean to be flippant (it was a long day). understand that people who are mostly in the third case are angry and disappointed, but from what I've seen in talking to people both when Stream was launched and after this announcement, at least some large number who are worried that that's their situation are going to be actually getting something better when the dust settles.
What's the current difference between RHEL and Oracle Linux? Our institution used to be an RHEL shop, but switched to OL -- I just assumed that RHEL was historical at this point.
[edit -- thanks for the answers. I realize now that my memory failed me... I mis-remembered that Oracle bought RedHat, not IBM.]
It's mostly for Oracle products and has the oracle yum repositories preconfigured iirc. So their database products can be installed out of the box.
But RHEL is considered the industry standard when it comes to corporate Linux distributions.
In essence.
Contrary to most commenters, I am actually optimistic. I switched to Arch on the desktop a decade ago because I was tired of having to often nuke and pave my install every 6 months. I am still with Arch all these years later, even for my work machine and I work as a programmer so instability wouldn't fly.
Obviously the support window for CentOS was much, much longer, but if they're careful we can perhaps have the convenience of a rolling release with the stability of RHEL, or close to then more power to them.
My only concern is the short EOL window for current CentOS 8 users.
What is the point of offering your software to the community as open source if the only end game is to make people dependent and then pull a fast one on them. Sigh
specifically if travis had the idea to pull a bait and switch always to the community, isnt that bad? why offer "free for open source" in the first place when you know it will cost them money and developers need to earn? no open source community is begging for handouts.
I read somewhere the founder of centos is thinking of forking. that'd be nice