The table states only the LTS operation.
Three years normal release.
two years more as LTS.
Totals: 5 years!
Yeah, but then again they do not have Big Blue axing budgets in the background… 
3 Likes
Just to be clear the only problem with Debian, LTS, is not really problem. But the IBM problem with Centos stream is no big deal? Nethserver will run interference for all Centos Stream upgrade issues and breakage, this will happen much more frequently going forward with stream, in order to keep yum? so stuff like the below doesn’t happen with frequency?
1 Like
The matter is not the rolling release, but the change of goals.
Soon CentOS Stream and Fedora will become quite a duplicate (a little savior Stream, a little crazier Fedora), therefore one will be axed too. And it will be Fedora, just because main stakeholder has no current interest into client OS.
So instability of StreamOS will increase even more, because it will be used as a testbench. Just like Nethesis is doing with community version of NethServer, but without certain of support from RedHat in terms of user cases (they are certainly larger) or presence answering.
Because subscription is the same thing…
7 Likes
I do not know if NethServer will run on CentOS stream. We already have the problem you pointed on every single CentOS 7 point release. So the problem is already here and we are already dealing with it.
No it will not, at least this is what they said 
Fedora is the upstream for RHEL major releases, while Stream is the upstream for RHEL minor releases.
This is just a speculation. I’m not saying that Stream is better, but you do not know. I saw bugs on RHEL opened years ago and never fixed, while the patch was quite simple. I hope that developers will be able to send patches and get them accepted (or rejected) with an open process.
The main point is that CentOS 7 is quite stable, but it keeps breaking things during major and minor point releases, even during the lifetime of the same minor! NethServer users usually do not even know it, because NS developers fix the issue (well, they try to 
) before hitting general availability.
The same applies to other software. Let’s keep Nextcloud as an example: they have a great community and high quality code, but things still break between releases and NS developers tries to fix them for the end users
We will still need to do the same work, no matter if we are going on Stream, Debian, or even BSD 
4 Likes
well we have to rewrite everything from scratch 
This is not sustainable
Thanks for the feedback and responses @giacomo! So the biggest concern would be trusting IBM to do as they said, Stream reliability, upstream placement and then hoping the issues that you deal with now are not increased significantly in regards to bugs and the interference you run.
So trusting a company proven to break their word, versus a community in debian/freebsd. Entities that have different ultimate goals and certainly beholden to different interest groups. Shareholders, CEO’s and board members in one instance and the community of users at large in the other.
Mine is an educated guess as yours, which I highlighted in bold. So please, don’t sell it as speculation.
You don’t agree? Fine by me, it’s currently into realm of evaluations and outlooks due to personal experiences; which currently says “more revenue”, due to death of CentOS.
Next will be “cut costs”, and it’s quite easy to guess where costs are into a software company…
3 Likes
As they also said EOL will be 2029 !
Michel-André
1 Like
Speaking from the community arm-architecture side of this discussion can only give a +1 for Debian or Debian derivative . Simply because it is multi-arch in it’s gene’s. 
You know rhel/centos 8 is out there for a while and still awaiting a cross compiler to show up in the repo’s.
Other than that that I’m quite indifferent except if CentOS Stream turns out to be a developers playground.
An other slight worry is how they are going to pull this off after years of splitting packages into (dynamically linked) libraries. IMHO this is pushed a bit to far, making mass rebuilds every (point) release almost a necessity.
As @vesalius pointed out and something among this lines discussed at the epel mailing list: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/NYXQNQFAY44RNCJTP6WLYUGJSQX5XSIX/
From the bright site you can also argue the community at large gets more say where CentOS is going, not being restricted by delivering a bit for bit, bug for bug, rebuild of RHEL. Altough the latter probably is the unique selling point of CentOS in the first place. 
5 Likes
I’ve found an explanation about different linux distributions and how they work at the web. I think it’s additional to @danb35’s.
some excerpts
we had a CentOS Stream kind of delivery internally forever, that’s how we build RHEL. And now we are just doing it in the public and calling that CentOS Stream.
RHEL and CentOS Stream are basically the same thing but with very different delivery vehicles, life-cycle and update stream.
we acquired it (…) late 2013 or early 2014 (…), around that time CentOS was having some problems, they had troubles getting releases out at times and I just remember a few other non-flattering news stories from the time. (…) Red Hat needed better mind share and a couple things from CentOS that were useful to us, so we kind of brought them in, hired a lot of the core contributors, and have supported it for several years up until recently.
first, a lot of stuff has change since 2014 (…) containers (…) Universal Base Images (UBI) (…) a subset of proper RHEL content set. It is the actual rpm that we release. They are released under the terms that allow them to be redistributable, all kinds of stuff that starts to sound a lot like CentOS, and so now we got this thing that is not right for everybody but it is right for a lot of development use cases and partners and other things. And so that was kind of like one thing we did that CentOS Linux suddenly becomes less useful (…)
why we couldn’t just leave CentOS Linux alone? And there’s kind of two schools of though on that. One is CentOS Linux, now that we have all this other stuff, just isn’t being as helpful to Red Hat as we would have hopped it would be at this point. The community didn’t evolved in any way with the industry and just hasn’t been that useful for us. And so well, a lot of people asking us why are you ending CentOS Linux, the question we have been asking ourselves is why are we continuing to do CentOS Linux, like I’m the guy that has to go through and improve budget reports, budget requests and servers and you know, we’ve got hiring decisions, (…) We decided that it was not worth it anymore and we did that knowing the code is still out there and other people may spin up rebuilds (…) and we are fine with that.
(…) we are not trying to kill the community there, it is just we didn’t feel like we needed to be directly sponsoring and supporting it anymore.
1 Like
This pretty much sounds like the money quote–they aren’t trying to kill “the community”, but they are trying to kill the product.
He is saying
And
… I don’t fault the CentOS community for this … it is a kind of how we set it up that was not working for anyone , that bug that you have or even a feature request…
there nothing, no way for you to do anything about that bug…
we sell support we, specifically ignore problems that come in from CentOS…
Sounds to me as a self for filling prophecy giving it no chance .
Having Listened to this interview does not make me more optimistic…
He is also predicting the life span of CentOS Stream 8 or 9 will be 5 years or so.
Given my experience so far a major release of RHEL/Centos kind of needs settle of 1 - 1.5 years (EPEL X as an example) does not make me more optimistic either .
1 Like
Hi
IMHO: It took a flat minute for IBM/Red-Hat to become absolute pariahs in the open source community.
IBM couldn’t be trusted before, now - as expected - Red-Hat.
20 years of a good name, destroyed in seconds!
'nuff said!
My 2 cents
Andy
4 Likes
Those who are worried about “stability”: it really seems there are little changes from CL8 to CS8.
Both receive backward compatible packages upgrades, only scheduled at different times. At distro pont-releases the first, in a stream fashion the latter.
NS7 is downstream of CL7 and as many of you know, in the past we got some troubles with point-releases because many RPM changes happen in a few days. In this perspective the Stream model can produce a benefit for us because we get those increments gradually.
Furthermore the openess of the development process is interesting too. It seems a big improvement from what we have now.
I don’t know if I’ll ever need CS8 as a base for NS8, it’s too early to spend a word on that! However in the end I consider it an interesting project.
Instead, the CL8 branch looks already “stale” (which is just a “b” far from “stable”) because some package versions are already outdated. The world is moving way faster than 5 years ago.
2 Likes
So what are you suggesting? I think, we, as a project that aims to deliver an OS that has enterprise grade options like stability and support, just can not dive into the deep and build on a testing playground. This de-facto reduces the stability and quality of our project.
Then there are the other ‘problems’ that we encounter like the Samba4 packages. Ideally an OS that provides in Samba4 accountprovider packages, wants them installed on the OS and not as a bridged container as we have now. I know we had lengthy discussions in the past, but it becomes an issue again when the base distro is on the line.
2 Likes
I hope there will be interesting talks for our community event in February! Meanwhile I’m doing some experimental works on containers for another project where CL8 does not suit. I’ll be glad to share anything useful for NS8.
Reasons to run Samba in a container in NS7 is not only what CL7 provides. It’s also for backward compatibility with NS6.
All of this is OT here though. If I was a CL8 user I’d give a spin to CS8 at first before saying what it is and what it isn’t.
1 Like
Hi Robb
You mean with Samba4 something like this?
sudo apt-get install samba
samba -V
My 2 cents
Andy
4 Likes