CentOS is dead, long live CentOS Stream
When CentOS Linux 8 (the rebuild of RHEL8) ends, your best option will be to migrate to CentOS Stream 8, which is a small delta from CentOS Linux 8, and has regular updates like traditional CentOS Linux releases. 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."
More information can be found in this FAQ. "CentOS Stream
will be getting fixes and features ahead of RHEL. Generally speaking, we
expect CentOS Stream to have fewer bugs and more runtime features than RHEL
until those packages make it into the RHEL release.
"
Update: see also this
blog post from Chris Wright.
Posted Dec 8, 2020 15:49 UTC (Tue)
by mattdm (subscriber, #18)
[Link] (1 responses)
(I can also answer non-Fedora questions but with varying degrees of authority.)
Posted Dec 9, 2020 10:38 UTC (Wed)
by JoergSimon (subscriber, #69785)
[Link]
Posted Dec 8, 2020 16:05 UTC (Tue)
by kragil (guest, #34373)
[Link] (96 responses)
Posted Dec 8, 2020 16:22 UTC (Tue)
by iwan (subscriber, #108557)
[Link]
Posted Dec 8, 2020 16:25 UTC (Tue)
by mattdm (subscriber, #18)
[Link] (55 responses)
Posted Dec 8, 2020 16:35 UTC (Tue)
by kragil (guest, #34373)
[Link] (54 responses)
They still say CentOS 8 would be supported until 2029: https://endoflife.software/operating-systems/linux/centos
And it still calls itself: The CentOS Linux distribution is a stable, predictable, manageable and
I thought it was a real community that you could rely on. I guess it just some IBM drones now.
Posted Dec 8, 2020 16:48 UTC (Tue)
by GhePeU (subscriber, #56133)
[Link] (53 responses)
Posted Dec 8, 2020 19:14 UTC (Tue)
by kragil (guest, #34373)
[Link] (52 responses)
I guess Red Hat sold its soul to IBM beancounters.
One thing we can do now is sign:
Posted Dec 8, 2020 20:36 UTC (Tue)
by pebolle (guest, #35204)
[Link] (1 responses)
Another thing we could do is ask for a refund.
Posted Dec 9, 2020 14:44 UTC (Wed)
by kragil (guest, #34373)
[Link]
Red Hat is IBM now. Same shit as Oracle, Microsoft, Google, Apple, same difference.
Posted Dec 8, 2020 20:45 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (39 responses)
CentOS was acqui-hired because Red Hat's upstream for layered products (at the time mostly RDO and oVirt) 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.
And that's it. It may not be a pleasant change for everyone, but it's a change that has strictly technical motives.
Posted Dec 8, 2020 22:13 UTC (Tue)
by Depereo (guest, #104565)
[Link] (38 responses)
Yes, CentOS was not suitable to meet those needs. It wasn't trying to meet those needs.
That makes this less of a 'technical motive' and more of an accounting one. Red Hat didn't want to commit new resources to servicing their new use-case, so have re-purposed an existing project to deliver an adjusted product that meets their new use-case. The old use-case will no longer be met.
Posted Dec 8, 2020 23:10 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (29 responses)
So if people were using CentOS as a free rebuild of RHEL they're having a bad surprise. If they were using CentOS or RHEL itself to develop applications for RHEL, it will be better for them because they'll be able to contribute bugfixes to CentOS Stream early, or have early access to kernel updates (I'd estimate that 20-30% of the upstream kernel changes are backported for every RHEL minor update). If they were developing their own rebuild of RHEL, it will be better for them. Granted, there's lots of people in the first category; all I'm saying is it isn't about IBM and it isn't about someone wanting to fire someone else to save money.
Posted Dec 9, 2020 6:00 UTC (Wed)
by kragil (guest, #34373)
[Link] (5 responses)
That is just lying and a dick move PERIOD
Fool me once ...
Posted Dec 9, 2020 7:35 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (4 responses)
Posted Dec 9, 2020 21:31 UTC (Wed)
by khim (subscriber, #9252)
[Link] (3 responses)
It's the same issue as with GPLv3, it seems. If you read even the initial announcement you see the following text there: Red Hat anticipates that taking a role as a catalyst within the CentOS community will enable it to accelerate development of enterprise-grade subscription solutions for customers and partners, such as Red Hat Enterprise Linux, Red Hat Enterprise Linux OpenStack Platform, Red Hat Cloud Infrastructure, Red Hat Enterprise Virtualization, Red Hat JBoss Middleware, OpenShift by Red Hat, and Red Hat Storage.
So it looks like RedHat always considered CentOS as “a development vehicle for RHEL”. Just like FSF always considered GPL as “a tool to ensure software freedom”.
In both cases changes looked perfectly normal and logical when viewed by principal authors. In both cases changes looked like betrayal to large community because they used these for radically different reasons: CentOS as “free clone of RHEL without support” and GPLv2 as “tit-for-tat software development model”. And changes broken both quite radically.
Posted Dec 9, 2020 22:44 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (2 responses)
RedHat did NOT create CentOS. They may have - from the point of purchase on - considered it as a testbed for RHEL, but that was not how the creator saw it. And by re-purposing it, RH have broken the unspoken contract between *creator* and users.
Cheers,
Posted Dec 10, 2020 8:24 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
But creator is now on Rocky Linux, no?
Thus RedHat have only changed what it owns. More like Ethereal/Wireshark thingie than anything else if you ask me.
Unfortunate, but not that rare.
Posted Dec 21, 2020 13:44 UTC (Mon)
by cortana (subscriber, #24596)
[Link]
Posted Dec 9, 2020 19:57 UTC (Wed)
by k8to (guest, #15413)
[Link] (22 responses)
This doesn't actually address Linux developer needs.
Posted Dec 9, 2020 21:41 UTC (Wed)
by khim (subscriber, #9252)
[Link] (17 responses)
Nah. It's not exactly “valueless”. It's actually very common in Enterprise world. That's why Microsoft offers various programs where you get SDKs for future versions of Windows. And why it provides cheap yet limited versions of SQLServer, Exchange and many other Enterprise products.
You make your team use that “preview/development” environment and then, when you know product behaves as it should — you can buy some few licenses for real Enterprise product (often there are some cheap licenses for testing where you need, e.g., to reinstall your OS every 90-180 days… RedHat hints these are coming soon), to test and and ship the result.
RedHat (well… IBM now, I guess), naturally wants to provide the very same model. Where you couldn't use “development version” to actually host your goods in production, but only can use it for development… in conjunction with a few copies of actual “Enterprise OS”, of course.
Perfectly logical move if you only consider CentOS a vehicle for development and don't care at all for people who may use it to host something in production…
Posted Dec 10, 2020 16:43 UTC (Thu)
by mvdwege (guest, #113583)
[Link] (16 responses)
These people aren't paying, so why should Red Hat care? You want an RHEL clone, you can do what the CentOS team used to do: fork it, remove the branding, and maintain it yourself. Or pay someone to do that, or ultimately, just hope that someone does it. What you can't do, is blame Red Hat for being a perfectly normal business or even demand that Red Hat supports free riders.
Posted Dec 10, 2020 16:50 UTC (Thu)
by mattdm (subscriber, #18)
[Link] (4 responses)
Posted Dec 10, 2020 17:04 UTC (Thu)
by mvdwege (guest, #113583)
[Link] (3 responses)
And I posit that Red Hat should not have to care about that particular small audience.
Posted Dec 10, 2020 21:34 UTC (Thu)
by kragil (guest, #34373)
[Link] (2 responses)
They lied (2029) and killed a perfecly good project.
Posted Dec 10, 2020 21:37 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
Spoken by someone who has clearly not paid any attention to Oracle's antics for the past decade. If ever.
Or IBM, for that matter.
Posted Dec 10, 2020 21:47 UTC (Thu)
by kragil (guest, #34373)
[Link]
There is absolutely no reason to trust them anymore.
Posted Dec 10, 2020 20:54 UTC (Thu)
by LightDot (guest, #73140)
[Link] (9 responses)
Posted Dec 10, 2020 21:11 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
It was the other way around; RHEL users were CentOS's beta testers.
> I wonder why the backslash...
Folks that were providing a great deal of work for free have decided to stop doing that in favor of an approach that meets their internal needs better.
Similarly, Folks that were getting something completely for free won't be getting exactly that any more.
Posted Dec 10, 2020 21:54 UTC (Thu)
by LightDot (guest, #73140)
[Link]
Posted Dec 10, 2020 21:31 UTC (Thu)
by mvdwege (guest, #113583)
[Link] (6 responses)
And the rules have always been the same: you get what you pay for, in money or labour. So you made the choice to make yourself dependent on the CentOS project; it could have folded, leaving you in exactly the same spot.
You want support? You pay for it, either by doing the work yourself, or by paying Red Hat. Nothing has changed except that CentOS is now the upstream for RHEL, and only one point release ahead at that. Instead Red Hat bought it and supports it.
The fact is that Red Hat went out of its way to provide resources to the community; and I see a lot of people complaining that that is still not enough, even though there is no contractual obligation, and by providing what it has done so far, Red Hat has IMO more than fulfilled its moral obligation.
Posted Dec 10, 2020 21:35 UTC (Thu)
by kragil (guest, #34373)
[Link] (5 responses)
Posted Dec 10, 2020 21:43 UTC (Thu)
by pizza (subscriber, #46)
[Link] (4 responses)
We're talking about software here. Free Software, both Gratis and Libre.
I think you need to step back and consider your words more carefully.
Badmouthing those that you are *demanding* do work for you, for *free*, is never going to get you what you want. They owe you precisely nothing, legally and morally.
Posted Dec 10, 2020 21:53 UTC (Thu)
by kragil (guest, #34373)
[Link] (3 responses)
Big corps are shitty by design, they will throw you or the planet under the bus if some beancounter thinks it will be worth it. IBM obviously forced CentOS to go this way and abandon their users and they obviously lied (2029).
No badmouthing here.
Posted Dec 10, 2020 22:08 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
So I take it you've never broken any sort of promise, ever?
> IBM obviously forced CentOS to go this way and abandon their users and they obviously lied (2029).
You are "obviously" incorrect; this is pretty much a textbook definition of badmouthing.
Posted Dec 10, 2020 22:19 UTC (Thu)
by kragil (guest, #34373)
[Link] (1 responses)
But I am not American, where people vote for you when you do nothing but ly all day.
In America you are great business success when you ly and make money at the expense of others. That is the most important thing it seems.
Posted Dec 10, 2020 22:20 UTC (Thu)
by corbet (editor, #1)
[Link]
Thank you.
Posted Dec 10, 2020 21:41 UTC (Thu)
by kragil (guest, #34373)
[Link]
Posted Dec 9, 2020 21:42 UTC (Wed)
by mattdm (subscriber, #18)
[Link] (3 responses)
CentOS Stream isn't meant to meet all needs. If the thing that's needed is "exactly RHEL", then "exactly RHEL" is always going to be a better solution than CentOS Stream or the CentOS rebuild.
I personally wish the timing here had been such that the other initiatives which are part of this same effort had been announced _first_, because it'd be an easier conversation. But here we are now.
Posted Dec 10, 2020 15:11 UTC (Thu)
by k8to (guest, #15413)
[Link] (2 responses)
Posted Dec 10, 2020 16:06 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
Posted Dec 10, 2020 16:14 UTC (Thu)
by mattdm (subscriber, #18)
[Link]
Posted Dec 8, 2020 23:11 UTC (Tue)
by pizza (subscriber, #46)
[Link] (7 responses)
I suspect that, for a substantial portion of CentOS users, the new Stream paradigm will represent a significant net improvement.
Red Hat is supposedly going to provide zero-cost access to RHEL to cover some of the old use-cases (ie "CentOS == Free RHEL").
But at the end of the day, someone has to pay the piper.
Posted Dec 9, 2020 5:43 UTC (Wed)
by mcon147 (subscriber, #56569)
[Link] (6 responses)
Posted Dec 9, 2020 12:54 UTC (Wed)
by pizza (subscriber, #46)
[Link]
I agree that is usually the case, but in this case it's "register and click download"
Posted Dec 9, 2020 17:03 UTC (Wed)
by mattdm (subscriber, #18)
[Link] (4 responses)
The RHEL business folks really really really do not like anyone to ever say "free RHEL". RHEL is not free; it is very valuable. So, you get weaselly-sounding wording like "no-cost" or "zero-cost". But the thing they're trying to avoid isn't actually the thing you and probably everyone else assumes when they see/hear the corporate-speak. It's a different worry altogether! And although it sounds a little silly to me (like the big deal made over "project vs product" nomenclature), the people to whom it is important have sold billions of dollars of RHEL so I trust that they know what they're talking about.
Anyway, the fact is that none of this is done with the expectation of converting masses of CentOS users into paid RHEL users. I'm pretty sure that seems as unlikely to the business folks as it does to all of the rest of us. The goals really are what the FAQ says they are.
Posted Dec 9, 2020 22:01 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (3 responses)
Posted Dec 10, 2020 17:08 UTC (Thu)
by mcatanzaro (subscriber, #93033)
[Link] (2 responses)
In contrast, traditional CentOS was *downstream* of RHEL, entirely different. It seems fair to say that Red Hat is no longer interested in this space anymore.
Posted Dec 12, 2020 16:54 UTC (Sat)
by johannbg (guest, #65743)
[Link] (1 responses)
Like ripple effects in water, the repercussions of a loosing a community's trust is that RH cant be trusted in *any* community be it Gnome, be it Fedora, be it some upstream project etc. because people will never know if RH has been sharpening it's knives preparing to going back on it's word and backstab the community it's involved in or responsible for so to speak.
That said what is interesting pattern in this thread is how people are quickly jumping the gun and blaming IBM for Red Hat's own management issues and poor decision making.
Posted Dec 13, 2020 15:49 UTC (Sun)
by mcatanzaro (subscriber, #93033)
[Link]
True.
> Like ripple effects in water, the repercussions of a loosing a community's trust is that RH cant be trusted in *any* community be it Gnome, be it Fedora, be it some upstream project etc. because people will never know if RH has been sharpening it's knives preparing to going back on it's word and backstab the community it's involved in or responsible for so to speak.
That seems a little extreme. We'll see....
Posted Dec 9, 2020 17:21 UTC (Wed)
by jccleaver (guest, #127418)
[Link] (1 responses)
Neither CentOS nor WBL nor the other rebuilds before them were ever much of a "community" except in terms of released support. The community can answer questions, write guides, and provide advise, but is unable to make any changes or adjustments in response to needs (except for the tiny subset of packages that have trademark issues).
There is definitely a *place* for the broader, RPM-based Enterprise Linux ecosystem to have a development community that can help actively guide and inject tickets into enterprise development, but that's not what "CentOS Linux" was, and "CentOS Stream" always, even when first announced, seemed like a conflation of two very different goals by the folks at RedHat.
Removing "CentOS Linux" is a slap in the face for those who've come to need something that fills that niche, and the slap itself makes the non-profit licensing use of RHEL slightly un-trusted, and the direction from RedHat to do so is very obviously a grab and not a reflection of truly limited resources.
Whatever Fedora is, its role as the source of the next Enterprise Linux seems to be at odds with its desire to break core elements to fit the sole needs of the laptop-using Freedesktop crowd. When the echoes of RedHat Linux were still present, it could be trusted to be just a slightly advanced version of what would become RHEL. But modern-day Fedora has caused a lot of pain points for downstream EL users years later.
Fedora is much more Ubuntu than it is Debian.
Posted Dec 9, 2020 18:12 UTC (Wed)
by mattdm (subscriber, #18)
[Link]
So, this is a key reason we decided to create the Editions split. See the other LWN article just published for some about that. :) https://lwn.net/Articles/839214/
> Fedora is much more Ubuntu than it is Debian.
I like to think of it as much more Fedora than it is either of those things. :)
Posted Dec 9, 2020 18:55 UTC (Wed)
by amit (subscriber, #1274)
[Link] (6 responses)
But I've always thought the CentOS-RHEL model was backwards. RHEL did not have any upstream to base itself off for the 10 years of its life once it branched from Fedora. So, going the Streams way made a ton of sense. RHEL finally has an upstream.
As for CentOS the downstream of RHEL, that doesn't bring any value to Red Hat's customers or the RHEL product; and forcing the CentOS userbase to CentOS Streams this way does seem like the better move - to ensure the CentOS community's bug reports, requests, etc., eventually feed into RHEL. This can also make the add-on efforts like EPEL more of a first-class citizen; and it's now RHEL's responsibility to pick-and-choose from its upstream for the duration of the RHEL release, rather than just doing it at the branch-off point from Fedora.
I get that RH made billions and is now owned by some bigger company, but attributing malice to everything is getting tiring -- especially when the company is still working in the open and contributing all code in the public domain even after that acquisition -- that's much better for all of the software ecosystem, and us, and we should rather reserve our hatred for the truly blood-sucking and inhumane companies out there.
Posted Dec 9, 2020 19:08 UTC (Wed)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted Dec 9, 2020 19:24 UTC (Wed)
by amit (subscriber, #1274)
[Link] (2 responses)
Posted Dec 9, 2020 19:32 UTC (Wed)
by mattdm (subscriber, #18)
[Link]
Before, we used to take the stale cookies and set them out by the dumpster to be repackaged and given to users. Now we're offering users free cookies right off of the factory line.
Posted Dec 9, 2020 19:54 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Dec 9, 2020 21:49 UTC (Wed)
by basmevissen (guest, #54935)
[Link] (1 responses)
IMHO, it does bring a lot for RHEL customers: a free to use distro to build all kinds of development and test infrastructure on. No hassle with licenses. Just build a scratch install and delete it when done. Even if you unexpectedly need to deploy it, you don't need to take care of any licensing issues.
Posted Dec 10, 2020 1:26 UTC (Thu)
by Fowl (subscriber, #65667)
[Link]
* Software availability - Developers won't build their apps for your OS if there are no users. No one will run your OS if there are no apps.
Posted Dec 14, 2020 7:49 UTC (Mon)
by alexarnaud (guest, #139344)
[Link]
It's one of the reasons why some proprietary program are better than there open-source counterpart, we lack financial resources.
There are plenty of company-sponsored source-code in the Linux kernel and everyone benefits to it. Red Hat invests a lot in open-source and I'm thankful to them.
How we have an open-source office suite? Because the Sun company buys StarOffice and releases it to open-source. So many companies still invests in LibreOffice.
Posted Dec 8, 2020 16:26 UTC (Tue)
by OdyX (guest, #58768)
[Link] (1 responses)
(afraid to be stating the obvious…)
Posted Dec 9, 2020 20:03 UTC (Wed)
by k8to (guest, #15413)
[Link]
Posted Dec 8, 2020 16:52 UTC (Tue)
by epa (subscriber, #39769)
[Link]
I think that the rebranding adds just the right amount of FUD for some corporate types to start paying for a RHEL subscription. I don't think it necessarily makes much difference in the real world. But then, personally I would be quite happy to run Fedora on production servers and rebuild them every six months, on a "cattle, not pets" basis.
Posted Dec 8, 2020 16:53 UTC (Tue)
by lmb (subscriber, #39048)
[Link] (1 responses)
Posted Dec 8, 2020 16:59 UTC (Tue)
by dilawars (guest, #126621)
[Link]
Posted Dec 8, 2020 17:22 UTC (Tue)
by jimi (guest, #6655)
[Link]
Posted Dec 8, 2020 18:06 UTC (Tue)
by re:fi.64 (subscriber, #132628)
[Link]
Posted Dec 8, 2020 18:31 UTC (Tue)
by chasil (guest, #143539)
[Link] (5 responses)
Oracle has a converter script for CentOS 7 that allows you to purchase Oracle support for the OS:
https://linux.oracle.com/switch/centos/
The converter has not been updated for CentOS 8.
Oracle also has an EPEL mirror which is relatively current, and their "UEK" kernel variant is much better than stock (much more recent, returns hardware support that RHEL removes, btrfs, etc.).
Posted Dec 8, 2020 19:43 UTC (Tue)
by adam820 (subscriber, #101353)
[Link] (4 responses)
Proposing Oracle Linux kinda misses that "without paying" portion.
Posted Dec 9, 2020 4:58 UTC (Wed)
by linuxrocks123 (subscriber, #34648)
[Link] (3 responses)
Posted Dec 9, 2020 17:47 UTC (Wed)
by adam820 (subscriber, #101353)
[Link] (2 responses)
Posted Dec 9, 2020 18:15 UTC (Wed)
by Chousuke (subscriber, #54562)
[Link]
As far as I can tell, Oracle Linux is completely free to use if you don't need support: https://yum.oracle.com/oracle-linux-8.html
Then again, it's Oracle. I find it difficult to trust them.
Posted Dec 21, 2020 13:57 UTC (Mon)
by cortana (subscriber, #24596)
[Link]
But I can't trust Oracle to keep it that way. As soon as they figure they will make more money by shutting down the Free option, they will.
Consider how you'd feel if, 5 years after a migration over to Oracle Linux, you found that 'dnf upgrade' began to fail with an error message telling you that access for non-paying customers is no longer available. And if, upon trying to purchase support, you discovered that the contract required Oracle to perform a full audit of your entire organization for unlicensed Oracle products.
Even I can forsee that eventuality, and I'm just some idiot on the Internet; I'm sure Oracle's lawyers will come up with much more insidious ways to induce conversion of free customers to paid.
Posted Dec 8, 2020 18:52 UTC (Tue)
by ceplm (subscriber, #41334)
[Link]
Posted Dec 8, 2020 20:15 UTC (Tue)
by Seirdy (guest, #137326)
[Link]
Your options: Slightly less slow/stable but still decent options:
Posted Dec 9, 2020 14:17 UTC (Wed)
by pwl0lwp (guest, #143556)
[Link]
Posted Dec 9, 2020 14:42 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (12 responses)
Depends what you mean by "does not change a lot". CentOS Stream doesn't change a lot - it's the packages that will go into the next RHEL point release, just earlier, so today's CentOS Stream is somewhere between RHEL 8.3 and 8.4.
If you need something that does point releases (i.e. no changes at all for 6 months at a time unless you do an explicit operation to pull in a targeted fix), then you'll need to look elsewhere - openSUSE Leap, Ubuntu LTS, Debian or even a private rebuild of RHEL.
But it does depend on what you mean by "stable distro that does not change a lot"; RHEL is static for 6 months at a time between point releases, unless you pull in targeted fixes. CentOS Stream is long-lived (roughly 4 years between releases, and we don't know if there will be a Stream 8 and Stream 9 when RHEL 9 comes out - which would increase the support time), but changes continuously with small changes. Ubuntu LTS offers continuous changes akin to CentOS Stream; I've not looked at openSUSE Leap in enough detail to know if it follows the RHEL model or the CentOS Stream model - it looks like it follows the RHEL versioning model, BICBW.
Posted Dec 9, 2020 16:25 UTC (Wed)
by kragil (guest, #34373)
[Link] (4 responses)
But don't take my word for it:
To be exact, CentOS Stream is an upstream development platform for ecosystem developers. It will be updated several times a day. This is not a production operating system. It's purely a developer's distro. Wright encourages, "users that want to be more tightly involved in driving the future of enterprise Linux, however, to transition to CentOS Stream as the new 'pace-setting' distribution."
Posted Dec 9, 2020 19:38 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (3 responses)
You can (and Facebook does) gate Stream into production yourself - it has literally the same packages as RHEL 8.4 will have.
So it's faster moving than RHEL point releases (because it's the upcoming packages for future RHEL point releases), but the stability guarantees are the same as existed for RHEL point releases. And I've read Chris's words - he's saying that if you want the absolute maximum stability and minimum risk, go for Red Hat Enterprise Linux. If you're happy to move a little faster, at about the same pace as Ubuntu LTS, then CentOS Stream is OK for you.
Posted Dec 9, 2020 20:00 UTC (Wed)
by kragil (guest, #34373)
[Link] (2 responses)
Posted Dec 9, 2020 20:03 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
It's no fantasy - it's based on looking at the package updates I get on an Ubuntu 20.04 LTS VM and on a CentOS Stream VM - they're very similar change lists.
CentOS Stream is RHEL 8.x packages; Ubuntu 20.04 LTS has a similar set of updates to RHEL 8.x.
Perhaps you should look at what changes in Ubuntu 20.04 LTS and CentOS Stream for yourself, rather than being rude from ignorance?
Posted Dec 10, 2020 17:25 UTC (Thu)
by mcatanzaro (subscriber, #93033)
[Link]
Comparing CentOS Stream with Ubuntu LTS is very fair. Now, I'd say Stream has somewhat more changes than Ubuntu LTS by nature of the fact that RHEL has always had somewhat more changes than Ubuntu LTS -- albeit held back for 6-month minor releases -- but they're hardly incomparable.
Posted Dec 9, 2020 23:05 UTC (Wed)
by RedDwarf (guest, #89472)
[Link] (6 responses)
Excuse my ignorance. But how exactly does this work?
Let's say I have RHEL 8.2. "no changes at all for 6 months"? Surely there must be security fixes at the very least, right?
Then RHEL 8.3 is released... now what?
Posted Dec 10, 2020 9:44 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (5 responses)
The way it works varies depending on how much you want to pay Red Hat.
RHEL 8.2 is a fixed set of versions; Red Hat will offer you security and bug fixes, and it's up to you to decide if you take them or not. The offered fixes are a subset of the packages they're preparing for RHEL 8.3; when RHEL 8.3 is released, it's bug fixes, security fixes and minor functionality updates (genuinely minor - things like performance improvements, added - but not removed - ciphers in crypto libraries, that sort of thing).
When RHEL 8.3 is released, RHEL 8.2 gets one last blast of general security updates. You can pay Red Hat to keep providing security updates for RHEL 8.2 - the price just becomes prohibitive if you want updates for more than a short period.
Moving to 8.3 should be safe in almost all cases; the ABI is the same (including kernel ABI), and the updates are supposed to be low-risk throughout the RHEL 8 lifetime. You might find that (e.g.) you have access to new library functions, command line arguments, or performance improvements after an update from 8.2 to 8.3, but nothing should break unless you were relying on a bug.
The really big thing that you gain by sticking to named RHEL point releases is commercial support from other vendors; RHEL 8.2 and RHEL 8.2 with security updates are very tightly defined things for a vendor to support their product on, and Red Hat define a bright line between "Red Hat supported packages, we will fix for our mutual customer" and "you support this bit, you will fix for our mutual customer". This is why I don't think that losing CentOS 8.3 and replacing it with CentOS Stream (effectively 8.4) is a big deal - the big thing you lose is the ability to pay a vendor to support their application atop an RHEL system, and then replicate that configuration across CentOS systems without paying Red Hat more money.
Posted Dec 11, 2020 9:32 UTC (Fri)
by ewen (subscriber, #4772)
[Link] (4 responses)
Maybe more people tracking RHEL 8.x-devel (ie CentOS stream) would catch things like this earlier, and let them be rolled back “before release”. Or maybe CentOS becoming a “testing” release means only OEMs end up tracking it closely, and anything affecting other software still only gets caught post-release. I guess time will tell how this plays out.
Ewen
Posted Dec 21, 2020 14:07 UTC (Mon)
by cortana (subscriber, #24596)
[Link] (3 responses)
(After checking myself)...
https://access.redhat.com/documentation/en-us/red_hat_ent...
No mention of the database format version change. Yikes!
(Out of interest, was the problem that the database files migrated during the upgrade, making downgrades tricky? Or were you dumped with a krb5kdc that failed to start because the database files were too old for it to understand?)
Posted Dec 21, 2020 23:58 UTC (Mon)
by ewen (subscriber, #4772)
[Link] (2 responses)
In the case of the upgrade attempt where I stumbled over this issue, the problem was that there were krb5kdc database files on disk that were "too old" for krb5kdc to read, so it failed to start (as best I could tell it was doing a strict "exact version" check). With more investigation (including RedHat Consulting, and RedHat Support), the original advice we'd received from RedHat Consulting about holding (IdM/FreeIPA) packages back from regular upgrade was revised, and we were able to successfully upgrade from RHEL 8.2 to RHEL 8.3, with no held packages. (My *guess* is that what was happening when the upgrade failed was that some other IdM/FreeIPA related package, previously held back, was writing krb5kdc database files onto disk in the old format, and then krb5kdc couldn't read those, or some IdM/FreeIPA automatic database-rewrite step was being missed due to the package holds.)
FWIW, there were other incompatible changes between RHEL 8.2 and RHEL 8.3 also not mentioned in the release notes, eg in the IdM/FreeIPA API for "User ID overrides" it changed from always showing SIDs to always showing user@domains, which we needed to work around. Given the scale of updates made, it's not surprising some things are missing from the release notes. But it does hint at the scale of things changed.
So I now consider RHEL 8.2 to RHEL 8.3 to be more like Ubuntu 20.04 to Ubuntu 20.10 than like the Debian 10.6 to 10.7 update. Ie, it's a new release version that's "fairly similar" but not just a rollup of previously issued patches like Debian does with its minor version releases.
Hopefully the RHEL "conservative versions" policy (versus, eg, Fedora) would mean most of the changes are small enough that fixing anything that breaks isn't too big a deal for someone following "CentOS" stream (ie, the RHEL equivalent of Debian Testing -- stablised package changes, but not fully tested for production readiness).
Ewen
Posted Dec 22, 2020 11:41 UTC (Tue)
by cortana (subscriber, #24596)
[Link] (1 responses)
I suppose in a perfect world you'd pay extra for EUS and stay on, say, 8.2 until you've tested with 8.3. I'd certainly like to be able to do that with my FreeIPA setup (even going so far as to install new ipa-servers on 8.3, and tearing down the 8.2 servers once I was happy). But I just can't afford it!
Posted Dec 22, 2020 23:12 UTC (Tue)
by ewen (subscriber, #4772)
[Link]
FWIW, having a mixed RHEL 8.2 / RHEL 8.3 IdM cluster did seem to work okay (at least for very light use; we deliberately avoided making schema/database changes while in that mixed state, and did all the upgrades over the course of about 24 hours). There's something in the older IdM guides about spinning up a stand alone test instance of IdM, to test upgrades, which might make sense in some contexts. But I didn't want to do that here as it seemed likely to get the Active Directory trust out of sync with either the stand alone node or the production cluster (or both). VM snapshots/reverts (so long as they're fairly quickly done) with possibly a forced database resync on the reverted node seems a better rollback option in the case of a bad upgrade experience.
But it does mean that, eg, CentOS Stream is probably not going to be ideal for running FreeIPA or the like. At minimum you'd want to freeze the cluster in time, and then maybe only upgrade it as part of a whole cluster staged patching cycle, to identical versions.
Ewen
Posted Dec 14, 2020 14:32 UTC (Mon)
by sam.thursfield (subscriber, #94496)
[Link] (3 responses)
Maintaining such a thing is rather boring work, in my opinion. Why would someone volunteer to do it for you for free?
Posted Dec 14, 2020 16:42 UTC (Mon)
by amacater (subscriber, #790)
[Link] (2 responses)
There are backports from Testing to Stable if you wanted to move some packages to newer versions, including backport kernels which may run newer hardware. Ubuntu's LTS versions are done by pulling from Debian and then hammering them flat for a while before release. All that said - it's a significant change of focus but it's not infeasible for folk to do it.
Most importantly, the development is in the open. Pop across to the LWN distributions page - huge numbers of Debian (and Ubuntu) derivatives, Red Hat, Fedora and four or five CentOS derivatives ...
Posted Dec 15, 2020 2:50 UTC (Tue)
by pabs (subscriber, #43278)
[Link] (1 responses)
Posted Dec 15, 2020 3:20 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
RHEL does a major release now every three years and maintain it for 10 (or even more if you really want that) with significantly more backporting for the initial several years. Other commercial vendors can do anywhere between 5 to 10 or so. Even rebuilding RHEL without any additional changes like CentOS used to do purely on a volunteer basis was not a smooth ride. It is not sustainable to expect volunteers to maintain a distro for 10 years for free. If you want that long lifecycle, support it by paying for it.
Posted Dec 15, 2020 14:07 UTC (Tue)
by csense (guest, #143662)
[Link] (5 responses)
If this is for enterprise use, I would suggest to pay a little for Rhel which is just 250$ per year per socket pair.
I don't think companies can raise ethic claims or right to receive products they don't pay, specially when when they don't contribute back to communities or and don't provide some kind of free service to society.
Open source and communities is a symbiotic ecosystem where everybody get benefit from collective work.
Posted Dec 15, 2020 21:44 UTC (Tue)
by Bickelball (guest, #143671)
[Link]
It still seems to me that with the value Red Hat provides of a stable product with timely security patches, support people and engineers to take escalations calls and deliver patches, while also keeping thousands of hardware and software products compatible, is worth paying them for. In addition they employ some of the best engineers in the world and still contribute all their source code to the open world.
Red Hat has said they will have offers for developers and the non-profit type places. The CentOS product seems to have become a charity, and is not an open source development community in my view. A development community works to improve a product and build something. A rebuild for people to use for free, of something that is valuable sounds kinda ugly actually. And hurting one of the leading open source companies in the world. I would hope some in the world see this as a way to help Red Hat be more successful. Count me in.
Posted Dec 15, 2020 23:34 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
For example, we can launch several thousand nodes on AWS for a large calculation task. The license costs for these would be in hundreds of thousands of dollars (there is RHEL pay-as-you-go licensing on AWS, but it's hard to use). And the additional value of RHEL in this case is zero.
In my previous company we were paying for RHEL for developers but were deploying on CentOS. Since CentOS is binary compatible with RHEL, there was very little friction. This model also won't work now.
Posted Dec 16, 2020 18:29 UTC (Wed)
by Bickelball (guest, #143671)
[Link] (2 responses)
When people say "I used CentOS for production because it was compatible with RHEL but free of any cost or restriction" or variations of that, it strikes me as unfair to Red Hat. If people say I use Ubuntu or Debian since they are fully free of any cost or restriction, that is good with me. They are not using them because they are fully compatible with a product that costs money. I think for Ubuntu there are many, many variants out there. And if people are using free Ubuntu versions that are fully compatible with the Canonical LTS versions, they also should question if that will always be free, given it does not appear Canonical is a successful business.
Posted Dec 16, 2020 18:39 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Canonical has supposedly been profitable since 2018:
https://www.zdnet.com/article/mark-shuttleworth-on-ubuntu...
Posted Dec 16, 2020 19:25 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Apparently, Ubuntu has been profitable. And they went out of their way to make it easy to use on clouds.
Posted Dec 8, 2020 16:15 UTC (Tue)
by donbarry (guest, #10485)
[Link] (2 responses)
I wonder whether they'll add additional poison pills in an attempt to keep the community from forming another?
Fortunately, having seen the writing on the wall when Redhat played this theme with variations the first time in discontinuing Redhat Linux after release 9 in favor of "Fedora," I jumped ship in 2003 to Debian Woody and have never looked back.
Posted Dec 9, 2020 19:11 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Dec 10, 2020 15:23 UTC (Thu)
by jeremiah (subscriber, #1221)
[Link]
Posted Dec 8, 2020 16:30 UTC (Tue)
by aklaver (guest, #62352)
[Link] (2 responses)
"Given this, we’ve informed the CentOS Project Governing Board that we are shifting our investment fully from CentOS Linux to CentOS Stream."
The Governing Board is not. The community is IBM.
Posted Dec 8, 2020 17:10 UTC (Tue)
by amacater (subscriber, #790)
[Link] (1 responses)
If you've been using CentOS to up-skill because your enterprise uses Red Hat - walk away. If you can't afford to deploy Red Hat on a large scale - walk away and take up Ubuntu or Debian. If you want Red Hat self-paced training, be prepared to pay as much for it as if you were running Solaris years ago. If you run HPC - maybe you should have listened 20 years ago :)
If you were a Fedora Linux developer unsure of your place in the Red Hat ecosystem when CentOS was brought into the mix - well you know now. If you're one of the relatively small number of independent CentOS developers - you know how much your influence has been sought. CentOS 6 has just gone EOL: I see nobody bothered much with a release announcement for CentOS 8.3 - that's how much the community communicates..
Scientific Linux dropped the workload of maintaining a Red Hat-alike in favour of recommending CentOS 8 - I wonder what they'll do now. Red Hat is all Kubernetes and similar now: Jim Whitehurst (immediately ex-Red Hat and IBM president) must have absolute certainty that this is a good course of action but I can't see it.
Posted Dec 8, 2020 18:53 UTC (Tue)
by mattdm (subscriber, #18)
[Link]
I don't think this is what you are trying to say, but... yes, that's very much what this announcement brings for me. When Red Hat brought CentOS inside, Red Hat was in the midst of a transition from being a single-product company to a porfolio-product one. This caused a lot of friction between Fedora and what were then called "layered products". CentOS as a closer-to-RHEL base was seen as a solution for this. The hope was that CentOS would provide a more-RHEL-like community place for work like RDO (OpenStack) or oVirt or OpenShift to happen. That was partially successful, but the plan wasn't really realized.
From a Fedora point of view, "Fedora is failing at a thing we need so we'll turn to CentOS" wasn't a healthy dynamic for either project, but the overlap has been uneasy and sometimes confusing. There was talk of waterfalls and virtuous cycles and something about a coffee percolator, but mostly it was just a mess. I mean, just look at the title of this talk: https://www.youtube.com/watch?v=t6jHWC2MrZg.
The CentOS Stream arrangement makes everything much more clear. We no longer need to resort to impossible geometry to describe the relationships!
There was an internal presentation featuring a "layer cake" model which I really liked, which went something like this:
Blue: Community space | Fedora Linux | community engineering decisions | community support
Purple: Shared space | CentOS Stream | transparent Red Hat engineering decisions with community input | community support
Red: Product | Red Hat Enterprise Linux | Red Hat engineering decisions with customer input | product support
Now, "Red Hat engineering decisions" might seem a bit scary, but consider that in CentOS Linux, all of the distro-contents engineering decisions were also made by Red Hat, but inside without any transparency. And if you're unsure about community engineering decisions and Fedora's independence … buy me a beverage sometime and ask me about Btrfs!
Posted Dec 8, 2020 17:04 UTC (Tue)
by davidstrauss (guest, #85867)
[Link] (27 responses)
Posted Dec 8, 2020 20:44 UTC (Tue)
by pebolle (guest, #35204)
[Link] (26 responses)
Phase 1 Restart Scientific Linux as a project
Posted Dec 8, 2020 22:07 UTC (Tue)
by mmcgrath (guest, #44906)
[Link] (1 responses)
Posted Dec 12, 2020 22:46 UTC (Sat)
by bgpepi (guest, #77064)
[Link]
Posted Dec 8, 2020 22:12 UTC (Tue)
by davidstrauss (guest, #85867)
[Link] (23 responses)
Posted Dec 8, 2020 22:32 UTC (Tue)
by pebolle (guest, #35204)
[Link] (22 responses)
Posted Dec 8, 2020 23:58 UTC (Tue)
by davidstrauss (guest, #85867)
[Link] (20 responses)
> Phase zero would be to offer answers to questions like:
Fedora serves as a fertile proving ground for technologies RHEL may want to adopt. It provides RHEL a fresh stream of battle-tested implementations and changes suitable to incorporate into the long support cycles RHEL needs. It prevents Red Hat from committing to support software or designs that prove to be faddish (because Fedora will implement and retire them) while still staying fresh (because Fedora is a rapid-adoption sort of distro).
> - how did CentOS came to be?
CentOS emerged from the practical reality that Red Hat effectively provided RHEL to the world for free as long as you were willing to build it (and, to distribute, strip branding). Red Hat went far beyond their GPL/BSD/etc. license obligations by providing SRPMs for the entire RHEL stack. CentOS professionalized the building and community distribution of what you could get from that.
Red Hat, in response, wasn't too hostile. So, it stuck. People -- including me -- used it, knowing that they could always switch to RHEL later.
> - how did Scientific Linux came to be?
Created around the same time as CentOS but for research purposes, the origin story and product are also similar to CentOS. This is why they decided that the labs backing Scientific Linux would switch to CentOS starting with version 8; there wasn't much purpose to Scientific Linux with CentOS, especially a Red Hat-backed CentOS, which looked like it would be a path forward indefinitely.
> - why did Red Hat decide to fund CentOS?
It started around when Ubuntu LTS traction was really picking up. Red Hat faced a perceived disadvantage in market adoption compared to Ubuntu because Ubuntu LTS was free. Putting their weight behind CentOS provided a way to achieve both: preservation of RHEL as the flagship but with a free product that would spurn community uptake, developer interest, and development of compatible software.
> - why did Scientific Linux close shop?
I mentioned this earlier, but the purpose of the project was demonstrably filled -- at the time of the decision -- by CentOS.
> - what made Red Hat decide to initiate CentOS Stream?
They may want a slower-cycle option for stabilizing software and configurations than Fedora. RHEL releases have, in the past, been cut from a hybrid of two or more Fedora releases. CentOS Stream would provide an opportunity to perform that sort of integration outside of the primary development cycle for a new RHEL release.
A less charitable take is that they want to support something that doesn't cannibalize their RHEL business. I've certainly seen members of our community suggest that.
Certainly, CentOS Stream doesn't satisfy key reasons why people use CentOS today. People use CentOS for reasons that Stream can't fulfill:
(1) Rigorous compatibility with RHEL
Amazon Linux might also be able to step up to fill the gap, but it's still not *rigorous* compatible with RHEL, to my knowledge. Oracle's Linux might be another, though unlikely, contender. Oracle's distro offers a configuration mode that is rigorously RHEL-compatible, down to the kernel patches.
Posted Dec 9, 2020 0:24 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (17 responses)
No offense intended but your answers to these two are wrong. In both cases the answer is that Red Hat needed a platform to develop software that would run on RHEL, software that would be turned into products later, for example like this:
Posted Dec 9, 2020 0:40 UTC (Wed)
by walters (subscriber, #7396)
[Link] (1 responses)
Posted Dec 9, 2020 1:19 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link]
Posted Dec 9, 2020 0:53 UTC (Wed)
by davidstrauss (guest, #85867)
[Link] (14 responses)
No offense taken, but it's hard for me to understand where CentOS Stream fills a role that Fedora cannot. Is Fedora upstream to CentOS Stream? The closest I've seen to answering this question is an oblique reference to CentOS Stream being "between" Fedora and RHEL, but that's unclear for whether it's conceptually between or in the sense that CentOS Stream will cut from Fedora ELN.
What's particularly confusing to me is that Fedora, itself, is in the process of figuring out the relationship between its own more rolling releases (IOT, CoreOS) and interval releases (Workstation, Silverblue, Server). I guess that's just a (good) sign of independence between Fedora and Red Hat, but what I really want is a graph of the whole Fedora + Red Hat + CentOS ecosystem in terms of upstreams, when each downstream gets cut, and what's changing from prior practice.
Posted Dec 9, 2020 1:17 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (3 responses)
CentOS Stream is *always* going to be what the next RHEL update (~6 month cadence) will look like.
Posted Dec 10, 2020 20:46 UTC (Thu)
by davidstrauss (guest, #85867)
[Link] (2 responses)
I do foresee some tension, though, if a RHEL point release is the gatekeeper of a more invasive change -- say, one that wouldn't go into an existing Fedora release -- and it just casually goes out to CentOS Stream users. It's not unheard of for RHEL to deprecate functionality or change moderately substantial things in point releases. Will that philosophy change much, knowing that CentOS Stream users may find such changes disruptive if they occur without warning?
My current impression is that CentOS Stream is not one base+updates channel but rather is paired with corresponding RHEL release streams. Is that correct? Specifically, what happens to CentOS Stream as RHEL 9 matures and gets released? I suspect some confusion in the community may be from the impression that it will yank you forward to the RHEL 9 stack. It seems that, even for Red Hat's purposes, you'll want a CentOS Stream for RHEL 8 even once RHEL 9 is out.
Posted Dec 11, 2020 12:58 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link]
Those do happen, agreed. It's very rare however that these do not go through a deprecation period, and the deprecation will usually last until RHEL(n+1).
The effort that is put into keeping RHEL nightlies (and therefore CentOS Stream) stable is substantially greater than a few years ago, and processes have been put in place to ensure it---even at the cost of extra work on part of RH developers. Whatever goes into CentOS Stream has seen substantial automated and manual testing.
I think the main risk factor for CentOS Stream users will be kernel updates because despite the version number RHEL is quite on the bleeding edge for many subsystems. But even that has been improved a lot in the past years, and things will only get better in the remaining year of CentOS Linux 8's life.
Posted Dec 11, 2020 12:59 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link]
Yes, there will be multiple CentOS Stream releases in parallel.
Posted Dec 9, 2020 14:30 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (9 responses)
There are now 4 things involved in Red Hat distributions, forming a rough funnel (if you squint from far enough away, and ignore all the human details).
Fedora itself is at the top of the funnel - it's the fast moving, up to date distro with very little in the way of support guarantees, more targeting integrating the most recent of everything on a 6 monthly schedule. This has lots of non-Red Hat involvement, and produces a regular release plus "Rawhide" which is the development branch.
Next is Fedora ELN; this is open development of RHEL next (currently RHEL 9, since RHEL 8.3 is current), where Red Hat employees (mostly) work in public, using Fedora Rawhide as a source of packages, to get to a supportable RHEL next release. There are no releases here - when ELN is ready, it'll become RHEL 9 (then 10 etc).
Then, we have CentOS Stream - this is the development stream for the next RHEL point release (currently RHEL 8.4, since 8.3 is current). There are no releases here, either - this is the latest packages for the current RHEL version, including ones that haven't yet been in a point release.
Finally, at the bottom of the funnel, is RHEL (and formerly CentOS and Scientific Linux). This releases regularly, providing both major releases and point releases (which are supposed to be just bug fixes).
So, in terms of what we've lost, we had CentOS point releases that exactly matched RHEL point releases. Those are gone. We had older CentOS versions (currently 7 and 8 are on offer); that's going. We still have an RHEL stability gratis distro (CentOS Stream, which is going to always be the upcoming point release of RHEL, and slightly ahead of any RHEL point release). We have acquired ELN, which is a view into RHEL next development.
From a user perspective, I'm not sure that we've lost anything significant; CentOS Stream and RHEL current are very closely related, with the only thing lost being exact package version matches to RHEL; if you really need to know precisely what binaries your customers are running, you now need to pay for RHEL or use something else. CentOS Stream is approximately equivalent to Ubuntu LTS - it's still an LTS, it just doesn't make regular point releases any more, preferring to give you packages continuously.
Posted Dec 11, 2020 23:21 UTC (Fri)
by nknight (subscriber, #71864)
[Link] (8 responses)
CentOS Stream has been explicitly called out by Red Hat employees as "development/testing". It is, by definition, NOT stable, certainly not RHEL-stable. That is what this is all about. Red Hat is trying to back out on promises they JUST MADE at the release of CentOS 8, which tons of us relied on, and turn the CentOS community into their beta testers, and like any corporate monolith, they've decided if they just avoid one magic word, "beta", they'll fool us.
They haven't. They lied. We all know it. I'm actively working to get all traces of RHEL and its derivatives out of our systems as quickly as possible, before they decide to go back on even more promises. Why should I believe they'll wait a year to shut down CentOS 8? Why should I believe 7 will still be supported for its lifespan? There is no reason to at all.
Posted Dec 12, 2020 1:06 UTC (Sat)
by pizza (subscriber, #46)
[Link] (5 responses)
In other words, you don't actually use RHEL.
(Because if you were an actual RHEL customer, you'd have nothing to complain about, as nothing here has anything to do with Red Hat and their contractual obligations to their paying customers)
> Why should I believe they'll wait a year to shut down CentOS 8? Why should I believe 7 will still be supported for its lifespan? There is no reason to at all.
Why should you believe anyone else's promises either?
You get what you pay for.
Posted Dec 12, 2020 23:24 UTC (Sat)
by nknight (subscriber, #71864)
[Link] (3 responses)
My software licensing budget going back to 2006 disagrees. It’s about to get a lot smaller. This disgusting disrespect for your paying customers is not helping you.
Posted Dec 13, 2020 0:22 UTC (Sun)
by pizza (subscriber, #46)
[Link] (2 responses)
Then it wasn't ever that large to begin with. At my last gig, we averaged about $50K/person/year in licensing fees for the EDA tools we were using. Adding RHEL on top of that increased our licensing costs a whopping 0.35%.
Those tools were certified to run on "RHEL" not "mostly/sorta RHEL". If we weren't using a certified/supported base operating system, the EDA vendor wouldn't support us.
> This disgusting disrespect for your paying customers is not helping you.
How exactly is Red Hat "disrespecting" its customers? Absolutely nothing has changed for them.
Posted Dec 13, 2020 2:07 UTC (Sun)
by nknight (subscriber, #71864)
[Link] (1 responses)
Precisely. We don't have the budget to play your games.
Posted Dec 13, 2020 2:43 UTC (Sun)
by pizza (subscriber, #46)
[Link]
Um, what exactly are "my games" here?
Meanwhile, what you do with your budget is of course your prerogative. Well, budgets (plural) -- all too often Time is discounted.
Just keep in mind that whatever distro you migrate to will have its own share of "broken promises" and other quirks that will bite your migration effort in the posterior.
Posted Dec 13, 2020 2:10 UTC (Sun)
by johannbg (guest, #65743)
[Link]
My experience dealing with RH support is that you actually you dont when if it involves any actual fixing in a component which arguably is what paying customer rely on ( unless they are relying on RH for moral support and perhaps documentation/configuration issues ).
In my case I was faster figuring out the bug myself ( faster than the RHEL maintainer responding ), ping upstream and getting it fixed ( which happened within an hours ) rebuild the affected component with the patch, test it and push it on the affected production servers at the end of the work day. The fix itself landed in Fedora quickly ( within the week ) but not in RHEL until after several months.
Granted this was couple of years back so maybe RH support has gone better but I highly doubt it.
So is it worth paying RH for the subscription and support?
Posted Dec 12, 2020 13:41 UTC (Sat)
by farnz (subscriber, #17727)
[Link] (1 responses)
It is not RHEL point release stable; it is RHEL-stable, because it's where RH develops the next point release.
If you need the absolute sine qua non of stability, your choices appear to be paying for RHEL or SLES; now that I've looked, the stability guarantees in openSUSE Leap are the same as CentOS Stream, as are the stability guarantees in Debian Stable and Ubuntu LTS.
Sure, this is faster moving than RHEL point releases - but it's the same level of stability or better that you'll get from any other gratis distro.
Posted Dec 13, 2020 0:19 UTC (Sun)
by nknight (subscriber, #71864)
[Link]
For small companies, non-profits and academics operating within strict budget limitations, running branded, paid RHEL on all systems is simply non-starter. This change means they either must accept less stability everywhere, or split their infrastructure between paid RHEL and Stream. The costs of that latter scenario are also a non-starter in both a monetary and effort sense.
This leaves CentOS Stream everywhere. Well, now we won't pay for RHEL anywhere, but we don't have the stability we need, either.
Which leads inevitably to the conclusion: CentOS Stream is operationally equivalent to Ubuntu LTS.
I can get paid support from Ubuntu for less than I can from Red Hat, can use it everywhere I use both RHEL and CentOS without change, it's widely available and used on public clouds, and has nearly as good third-party vendor support (better, even, for some cases of interest to me specifically).
And maybe the best part? Ubuntu actually takes community contributions directly into the main distribution. No hopping through the Fedora mess.
Red Hat just destroyed CentOS's key differentiator. If nobody but me cares, fine, but don't try to tell me the naked emperor has clothes.
Posted Dec 9, 2020 0:29 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link]
What you are describing is actually pretty much Fedora ELN, which right now is a Rawhide rebuild but which will morph into the next major RHEL release, and will do so in the open.
CentOS Stream instead is targeting the next RHEL *update* release.
Posted Dec 9, 2020 10:06 UTC (Wed)
by pebolle (guest, #35204)
[Link]
> People use CentOS for reasons that Stream can't fulfill:
Both CentOS Linux and CentOS Stream fulfil:
Any project aiming to do what CentOS Linux does, needs to find a way to support that - I think - rather large effort. Unless community ponies show up - which I don't see happening - money must be spend. I'm guestimating that can easily be more that € 1M per year. That kind of money, even if it is split over multiple organizations, means that someone needs to evaluate the wisdom of that investment: "Should our employees spend their time and our money on this?"
Is it likely that Scientific Linux will be rebooted, or a succesor project will be started, successfully for years on end? I doubt it.
Posted Dec 9, 2020 12:18 UTC (Wed)
by eru (subscriber, #2753)
[Link]
Posted Dec 8, 2020 18:19 UTC (Tue)
by walex (guest, #69836)
[Link] (24 responses)
Posted Dec 8, 2020 19:53 UTC (Tue)
by amacater (subscriber, #790)
[Link] (22 responses)
Posted Dec 8, 2020 21:44 UTC (Tue)
by walex (guest, #69836)
[Link] (21 responses)
That Ubuntu is a derivative is not the point, and neither is that DDs are volunteers. The point is how much economic support flows from Canonical (or Google, as another comment points out) to Debian, so that existing and future DDs continue to volunteer on more full time basis. That is a pretty big deal: the number of DDs (and probably that of active DDs) has peaked, and a Fedora guy wrote some years ago that he was not sure that distributions had any future in terms of volunteers because the cool kids today just volunteer on forking Github projects and on language specific "rolling" collections of largely source-level stuff, like for Python, JavaScript, Ruby, Rust, etc. Eventually
Posted Dec 9, 2020 10:26 UTC (Wed)
by lobachevsky (subscriber, #121871)
[Link] (18 responses)
Looking at the outdated Chromium package, the heavily patched polkit and the long-outstanding ITP for dbus-broker it all seems missing progress.
Posted Dec 9, 2020 11:11 UTC (Wed)
by dottedmag (subscriber, #18590)
[Link] (13 responses)
The tools are so anachronistic I couldn't bring myself to relearn them after a hiatus.
Posted Dec 15, 2020 13:14 UTC (Tue)
by calumapplepie (guest, #143655)
[Link] (12 responses)
I am interested in doing work on some of the tools.
Posted Dec 15, 2020 13:31 UTC (Tue)
by lobachevsky (subscriber, #121871)
[Link] (2 responses)
When looking at a spec file or a PKGBUILD, everything is mostly shell snippets and I can easily follow it, whereas in Debian everything is hidden behind an abstraction layer of debhelper magic, that I then need to hunt down to understand what it does.
I guess this might be just a matter of preference, but in terms of ease of understanding my ranking is (using the systemd packaging as an example)
Posted Dec 16, 2020 1:20 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (1 responses)
My criticism of debhelper is that it doesn't go far enough in automating the tedium of packaging, but there are some complementary things going on that help further automate things.
Posted Dec 16, 2020 10:25 UTC (Wed)
by lobachevsky (subscriber, #121871)
[Link]
One might argue, that this is all due to Debian's high requirements in regard to package quality. While this might be argued compared to Arch, a point I don't share, it will surely not hold true for Fedora and the RH ecosystem.
My point is, that I think, that other packaging systems than Debian's have a lower barrier to entry. I see seasoned Debian sysadmins use tools like fpm [1] instead of bothering with the "proper" tools. To put it succinctly (and maybe too much on the nose), all the debhelper magic might be so much (syntactic) sugar, that it's giving Debian bad teeth.
Posted Dec 15, 2020 15:49 UTC (Tue)
by dottedmag (subscriber, #18590)
[Link] (8 responses)
I'm sure some of the problems have solutions, but figuring out how to convert an existing package was just not worth it.
Posted Dec 15, 2020 16:27 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
What if you download a source package in .deb or tarball form?
Posted Dec 15, 2020 16:31 UTC (Tue)
by dottedmag (subscriber, #18590)
[Link] (3 responses)
I don't care about separate "source packages", this idea was useful in 1995.
Posted Dec 15, 2020 16:49 UTC (Tue)
by pizza (subscriber, #46)
[Link] (2 responses)
"This isn't a problem for me so clearly it isn't a problem for anyone else."
Debian generates and distributes separate, standalone source packages. Therefore a standalone 'clean up the mess' make target is necessary.
Posted Dec 15, 2020 17:18 UTC (Tue)
by dottedmag (subscriber, #18590)
[Link] (1 responses)
I know that, I am a DD.
You miss the very important question: WHY?
> Therefore a standalone 'clean up the mess' make target is necessary.
Yes, if nobody ever questions the motives why things are done one way or another, then this is going to perpetuate, sinking Debian further into irrelevance.
Posted Dec 15, 2020 17:30 UTC (Tue)
by pizza (subscriber, #46)
[Link]
To comply with the GPL.
> Is this reason still relevant?
Yes.
> If it is, can the packages be created in a way that does not require busywork from the maintainers?
Absolutely.
Posted Dec 16, 2020 5:34 UTC (Wed)
by calumapplepie (guest, #143655)
[Link] (2 responses)
To resolve the other two complaints, Debian policy would need to officially endorse packaging with Git. We're moving in that direction, with gbp, git-debrebase, ect. However, since the best way to do this would probably be with a fourth source-format type, git, we need to standardize on a couple tools first. GBP is popular, but many prefer the other techniques. Until we can find a way to permit both patches-applied and patches-unapplied workflows with the same tool, I don't see one tool becoming standard anytime soon.
Not to mention how DEP-14 isn't even standardized yet: we still don't have a common definition for what git branches should look like. Until that occurs, trying to build Git into policy will be impossible.
Posted Dec 16, 2020 10:15 UTC (Wed)
by dottedmag (subscriber, #18590)
[Link] (1 responses)
Anything beyond that is just a waste of time.
Posted Dec 31, 2020 18:34 UTC (Thu)
by calumapplepie (guest, #143655)
[Link]
If you want to apply patches directly to upstream using git, use git-debrebase: it allows you to commit freely on your debian branch, then generate the patches later.
As for uploading packages with signed tags, that would require a massive amount of infrastructure changes, and risk increasing the number of accidental uploads for those who (like me) auto-sign all tags. For easier uploads, look at dgit: it integrates with debrebase, and does everything quite efficiently.
Posted Dec 9, 2020 16:09 UTC (Wed)
by lsl (subscriber, #86508)
[Link] (3 responses)
Debian continues to ship an ancient version of polkit (based on 0.105 from 2012) whereas the rest of the world has long moved on. This has been going on for many, many years and over multiple Debian releases. Even today's sid/unstable still has that ancient version. Newer versions are packaged in experimental but they just stay there.
It's kind of annoying as the configuration format is incompatible with anything released by upstream (and other distributions) within almost a decade. It sucks when upstreams break compatibility but this just makes it worse.
Posted Dec 9, 2020 16:27 UTC (Wed)
by lobachevsky (subscriber, #121871)
[Link] (2 responses)
The short story is, that the Debian maintainers don't like the Javascript based config format and want to stick with the INI format that polkit hat until version 105. Since then they've backported everything from upstream releases except for the removal of the localauthority backend and the new JS config format. Holding the package hostage in their preferred state.
They are opposed to the new format, because they think a declarative format is better. While this is a sensible argument, there's some things that the INI format cannot do, e.g. finegrained policies for managing systemd units and the JS snippets are short enough to be easily reasoned about.
They also argue, that there is no migration path from the INI format to JS snippets and haven't answered yet after somebody provided a script to do just that.
Another point of critique is the JS engine embedded in policykit, which currently is mozjs. They would like to see a different one. There is an upstream PR working on it, but I don't know the current status of that.
The funny thing about all of this is, is that a lot of Debian packages actually ship polkit rules in the JS snippet format and if one install the polkit from experimental, which is the regular upstream version, everything works out of the box and even some things for which Debian maintainers forgot INI-style rules suddenly have them.
I guess nothing changes, because nobody cares all too deeply about this, to get a larger conversation about this started in Debian.
Posted Dec 12, 2020 10:49 UTC (Sat)
by flussence (guest, #85566)
[Link] (1 responses)
Fortunately it's not hard to avoid polkit on a source-based distro. You have to give up on Gnome or KDE SC, but that's not much of a loss, IMO.
Posted Dec 12, 2020 12:02 UTC (Sat)
by lobachevsky (subscriber, #121871)
[Link]
Posted Dec 9, 2020 16:00 UTC (Wed)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted Dec 9, 2020 17:09 UTC (Wed)
by walex (guest, #69836)
[Link]
But the issue is the number of active DDs. As to the number of current applicants, just as "everybody knows" that if one gets half a dozen patches submitted to the kernel one is likely to get a job offer from one of the big names, "everybody knows" that DDs are much more likely than others to get a job offer from Canonical or Google etc. The question is how many would like to become DDs and keep working as active DDs if that did not mean a much higher chance of a high-value job offer from big names that directly or indirectly sponsor Debian.
Posted Dec 8, 2020 20:48 UTC (Tue)
by mbanck (subscriber, #9035)
[Link]
This was true in 2004-2010 maybe, but I don't think it's true anymore. True, they still employ a few DDs, but probably not more than e.g. Google.
Posted Dec 9, 2020 10:28 UTC (Wed)
by RedDwarf (guest, #89472)
[Link] (5 responses)
https://www.centos.org/centos-stream/ says "Continuously delivered distro that tracks just ahead of Red Hat Enterprise Linux (RHEL) development", and that's more or less what's described everywhere.
I use Fedora. From those descriptions it sounds as if I enable to "updates-testing" repository (which gives me access to updates before they are officially released) then I'm not using "Fedora 33" any more, now I'm using "Fedora Stream 33". I mean, that's what "just ahead" means, no? I get access to the changes slightly earlier...
Now, enabling the "updates-testing" repository obviously doesn't convert my Fedora 33 distribution into a different distribution. So I guess "CentOS Stream 8" is actually something different to "CentOS Linux 8 + updates-testing repository", which raises the question... what exactly CentOS Stream is???
Posted Dec 9, 2020 12:45 UTC (Wed)
by pizza (subscriber, #46)
[Link] (4 responses)
That is essentially what CentOS stream is intended to be.
Fedora is branched to create a new RHEL release. When RHEL N is released, CentOS Stream N is released, and receives continual updates. Every 6 months, RHEL N.M is branched/released off of CentOS Stream N.
Posted Dec 9, 2020 14:55 UTC (Wed)
by RedDwarf (guest, #89472)
[Link] (3 responses)
But from what I understand CentOS Stream did already exist. So this announcement has nothing to do with CentOS Stream, it's not "CentOS is dead, long live CentOS Stream" it's just "CentOS is dead"... "by the way, unrelated, but did you know about CentOS Stream?".
What I don't get is why there is still a "CentOS". The difference between "RHEL N" and "CentOS Linux N" is simply that if you use RHEL you have a "right to complain" (simplified, but..) to Red Hat, right? So why it isn't:
- Access to RHEL N is available to everybody for free (so it is what "CentOS Linux" was).
I guess we will have to wait to see what those "low- or no-cost programs for a variety of use cases" are to see how far we will be from "RHEL N is available to everybody for free". But I would have waited to have those ready before announcing any change at all.
Posted Dec 9, 2020 22:00 UTC (Wed)
by khim (subscriber, #9252)
[Link] (2 responses)
Your first step just doesn't make any sense. If you make RHEL available for free then you, suddenly, lose almost all revenue.
Most RHEL users don't ask for “something to be fixed”. They pay for the ability to ask that. Kinda like insurance: most insurance payers wouldn't ever ask insurance company to pay for car repair because they have no accidents.
Posted Dec 9, 2020 22:38 UTC (Wed)
by RedDwarf (guest, #89472)
[Link] (1 responses)
Posted Dec 9, 2020 22:57 UTC (Wed)
by amacater (subscriber, #790)
[Link]
So today, CentOS 8.3 is fully Red Hat compatible: CentOS Streams is preparing for Red Hat 8.4 (and CentOS 8.4 at that point - probably April/May 2021). CentOS 8.5 will be released November / December 2021 if the six monthly release cycle is maintained and that will be it. CentOS Streams will be used for Red Hat 8.6 and so on but as a rolling release with no guarantee of stability.
Lots of folk use CentOS to develop for Red Hat paid for systems: lots of ISPs use CentOS for hosting because it's binary compatible and they don't have to worry about numbers of virtual servers for licensing, for example. People have used CentOS in order to train for Red Hat certifications. Folks feel let down by the implicit loss of eight years of guaranteed lifecycle, whether that's justifiable or not.
Posted Dec 9, 2020 11:27 UTC (Wed)
by c0r3dump3d (subscriber, #121602)
[Link]
Posted Dec 9, 2020 17:36 UTC (Wed)
by tvannahl (subscriber, #134292)
[Link]
I am all for it if this brings the current development cycles and operations closer together. Never heard about CentOS Stream before.
But still, given CentOS long living Ecosystem, this has been mediocre communication. We all probably know rooms in which a two years in advance notice may cause havoc. :-D
Posted Dec 9, 2020 18:20 UTC (Wed)
by burki99 (subscriber, #17149)
[Link]
Gregory Kurtzer says:
I am considering creating another rebuild of RHEL and may even be able to hire some people for this effort. If you are interested in helping, please join the HPCng slack (link on the website hpcng.org).
Greg
Posted Dec 9, 2020 18:32 UTC (Wed)
by LightDot (guest, #73140)
[Link] (1 responses)
Upside: CentOS packages will be available immediately, no need to wait for any kind of rebuild.
Downside: supporting a custom mirror and scripting.
Should the mirror be made public, CentOS might require copyright changes... or would it? It would simply be a select subset of CentOS Stream...
Posted Dec 9, 2020 20:13 UTC (Wed)
by pjtait (subscriber, #17475)
[Link]
Posted Dec 9, 2020 21:37 UTC (Wed)
by basmevissen (guest, #54935)
[Link]
Being a Red Hat user from the beginning, having ran all Red Hat, Fedora and CentOS versions, I really start to question my distro of choice. I want to have the same "family" for all workstation, server and container installs I work with.
As a side note, I generally like the idea of CentOS Streams. I would definitely considered them as an alternative for some CentOS Linux or Fedora server/container installs. But what are the chances they go away with a years notice?
I hope (and count on) the community backlash will make them revert this decision, but still the damage is done.
CentOS Stream and Fedora
CentOS Stream and Fedora
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
For many use cases, RHEL. See particularly this part of the FAQ:
CentOS is dead, long live CentOS Stream
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.
CentOS is dead, long live CentOS Stream
"Release Release date End of life "
"CentOS 8 September 24, 2019 May 31, 2029"
reproducible platform derived from the sources of Red Hat Enterprise Linux
(RHEL).
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
https://www.change.org/su/p/centos-governing-board-do-not...
CentOS is dead, long live CentOS Stream
> https://www.change.org/su/p/centos-governing-board-do-not...
CentOS is dead, long live CentOS Stream
Beancounters without morals that only care for money.
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
Wol
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
> These people aren't paying, so why should Red Hat care?CentOS is dead, long live CentOS Stream
Red Hat should care for "these people" as much as it would like "these people" to care about Red Hat.
Consider the CentOS user base, their profile and numbers. CentOS users are largely members of the industry, members of the academia. Some of them are authors and contributors to various projects and software that Red Hat ships. Some of them are researchers, educators, decision makers.
Red Hat made certain promises when it acquired CentOS, both direct and implied. CentOS made certain promises when CentOS 8 was released as a RHEL clone, with a 2029 EOL.
The relationship between Red Hat and the users of CentOS must have seemed fair to both sides in the past, or it wouldn't last this long... and now what, a sudden decree to end CentOS as we know it?
There were other ways to present this, offerings to prepare that weren't prepared, timing that could be better chosen.
CentOS users in general seem to be badly informed about CentOS Stream. They seem to think that they are let down.
I'm not really sure the Red Hat decision makers thought this through. It seems ill planned and poorly executed.
> What you can't do, is blame Red Hat for being a perfectly normal business or even demand that Red Hat supports free riders.
Well, "these people", "free riders", or how ever you wish to insult the CentOS users, are apparently still worthy of being beta testers but not worthy enough to properly explain to them as to why is this a fair deal or why might it even be beneficial to them.
I wonder why the backslash...
CentOS is dead, long live CentOS Stream
>> Well, "these people", "free riders", or how ever you wish to insult the CentOS users, are apparently still worthy of being beta testersCentOS is dead, long live CentOS Stream
>
> It was the other way around; RHEL users were CentOS's beta testers.
>
I was unclear, I suppose... I wasn't trying to suggest that they were beta testers before but rather that they are apparently still good for something.
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
> No badmouthing here.
CentOS is dead, long live CentOS Stream
I'm thinking this back-and-forth has gone about far enough; can we please stop it here?
Let's stop here
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
It does sound like that. But it's genuinely not.
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
As for CentOS the downstream of RHEL, that doesn't bring any value to Red Hat's customers or the RHEL product
But before RH acquihired it, the point of CentOS was to bring value to its users. Apparently they don't matter any more.
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
** If developers they use it themselves, almost "by default" their software will work on your platform .
* Talent - more systems out there mean more admins, means a larger pool of people recommending it.
* Knowledge - more users means more answers on google/forums, means less support calls.
* Bugs - more users means bugs are experienced faster. Hopefully these overlap with your paying customers.
How do you pey your bills at the end of the months?
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, maybe switch your distro to Oracle Linux
CentOS is dead, maybe switch your distro to Oracle Linux
CentOS is dead, maybe switch your distro to Oracle Linux
CentOS is dead, maybe switch your distro to Oracle Linux
CentOS is dead, maybe switch your distro to Oracle Linux
CentOS is dead, maybe switch your distro to Oracle Linux
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
Old school CentOS isn't going anywhere. Stream is available in parallel with the existing CentOS builds. In other words, "nothing changes for current users of CentOS."
https://www.zdnet.com/article/red-hat-introduces-rolling-...
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
- Does RHEL 8.2 keep getting security updates?
- How safe is is to move to 8.3? What can change between 8.2 and 9.0 that can't change between 8.2 and 8.3?
- Is 8.3 ABI compatible with 8.2?
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
If you don't want to pay a cent, go with CentOS Stream and contribute testing it.
A model where a company invests and makes all the effort and others obtain benefits without contribution is not sustainable.
With free Centos identical to Rhel everybody will move to Centos. Rhel would end and without Rhel, there is no Centos. End. Dot
CentOS is dead, long live CentOS Stream
From truly non-production, or non-profit type environments, to cost sensitive environments, to people embedding it in software or hardware solutions, a whole range of developers, and all the way up to mission critical production environments. Friends who work at a major cloud provider tell me that the largest numbers and %'s are production environments from companies or entities that are "not" non-profit or cost sensitive type operations. Saying that the numbers are staggering, and that some are 100% CentOS and many are 5-10% RHEL and 90-95% CentOS.
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
I think Red Hat likely got sick of people riding for free, when they employ a lot of people and contribute a lot of open source code. And they price their products pretty fairly compared to the costs of the other elements of a hardware/cloud and additional software stack (databases, etc..).
Just sayin
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
I wonder whether they'll add additional poison pills in an attempt to keep the community from forming another?
The scientific community will have to, somehow. Rolling release is totally incompatible with the sort of intense stability needed for reproducible numerical results. (And, of course, Scientific Linux did just this, before it stopped because CentOS did the same job. I guess it has to come back again.)
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
[Personal view, not reflecting any other affiliation.]
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
Phase 2 ?
Phase 3 Profit
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
- why does Red Hat fund Fedora?
- how did CentOS came to be?
- how did Scientific Linux came to be?
- why did Red Hat decide to fund CentOS?
- why did Scientific Linux close shop?
- what made Red Hat decide to initiate CentOS Stream?
CentOS is dead, long live CentOS Stream
> - why does Red Hat fund Fedora?
(2) The stability of RHEL's tested configuration
(3) Usability of RHEL documentation
> - why did Red Hat decide to fund CentOS?CentOS is dead, long live CentOS Stream
> - what made Red Hat decide to initiate CentOS Stream?
RHEL --> OpenShift (Red Hat product)
| ^
v |
CentOS ---> OKD (free/open source)
now replaced with
Stream ---> OKD
| |
v v
RHEL --> OpenShift
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
Based on my experience I would say no I was not getting what was being paid for but ymmv.
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
>
> (1) Rigorous compatibility with RHEL
> (2) The stability of RHEL's tested configuration
> (3) Usability of RHEL documentation
(0) It's free (in both meanings of the word, I think)
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
Hopefully also SUSE will continue to have a good attitude and keep supporting OpenSUSE too which is very nice. Hopefully also the other "major" distributions will continue to attract good people to work on them.
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
"Debian is developed by volunteers: Canonical choose to pay some of them - but the dynamic is that much of Ubuntu is drawn directly from Debian."
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
1. https://github.com/archlinux/svntogit-packages/blob/packa...
2. https://src.fedoraproject.org/rpms/systemd/blob/master/f/...
3. https://salsa.debian.org/systemd-team/systemd/-/blob/debi...
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
– Upload via magical something tool? I have to remember the incantation to get the set of packages to upload just right — was it binary-only, or source-only, or something in between? Can't be bothered to remember.
– Quilt for patches. This is a big one. Now there is a VCS on top of VCS.
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
> I don't care about separate "source packages", this idea was useful in 1995.
CentOS is dead, long live CentOS Stream
What was the reason to create separate standalone source packages when Debian was created?
Is this reason still relevant?
If it is, can the packages be created in a way that does not require busywork from the maintainers?
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
applicants.
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
- If you want something fixed submit patches to "RHEL Stream" and it will be available in RHEL N.(M+1).
- If you want something fixed and can't bother to submit a patch, or you want it ASAP as a RHEL N.M update, pay Red Hat to do it.
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
December 8, 2020 at 4:27 pm
(original founder of CentOS)
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream
CentOS is dead, long live CentOS Stream