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
Did you have a look at alpine-linux ? I realize it is a bit out of the ordinary… no bash but busybox, no glibc but musl-libc and no systemd… 
Lean and mean , would not surprise me the hole DC could run in RAM…
Really feels like running old-style efficient software on modern hardware: small, fast and up to date !!
Use alpine-containers regularly and they can be spun up with nspawn if you wish. 
Agree…
However, because the arm gcc 4.8.x compiler lags a bit behind @ GLIBCXX versioning eager to move forward from el7. Used CentOS8-Stream around the time CentOS-Llinux was on 8.1 on all arch’s: utterly unusable!
Every time fingers crossed DNF could resolve the dependencies, best=0 - best=1 did not help, and note that was not the fault of DNF! the repo was just a mess. 
Moved away within a week.
Will revisit, not optimistic though.
2 Likes
There are newer gcc compiler versions from x86_64 sclo. Didn’t check arm availability…
We use devtoolset 9 here:
No, but I’d like to do it.
1 Like
Hi
I’ve used Alpine, and Alpine based Distros, like http://www.eisfair.org/ .
Eisfair used to be called fli4l, in case anyone recalls that. It’s still alive!
Alpine really is compact, neat and very current.
My 2 cents
Andy
4 Likes
getting a bit off-topic, but hey tis is a chat…
No official SCL’s releases although devtoolsets for arm are build.
Even with those not able to (re)build most of the node.js and golang stuff… (as a mater of fact: evebox we are running on NS-arm is build on fedora )
I bet you be amazed… I mean it, for a single use chroot/container it is a serious proposition. Alpine is around for more than a decade, its used as docker’s default container. As said “a bit out of the ordinary”, IMHO not far fetched. 
1 Like