>
> Given we are not developing drivers or applications (other than websites
> and web applications), is the change a non-issue for my use-case? I've seen
> it written that CentOS Stream is the "development version" of RHEL but also
> that we shouldn't have considered RHEL to be the beta for CentOS. Others
> have said to think of CentOS more like RHEL RC-1. I just don't know how the
> stability will compare and we have historically always chosen CentOS for
> its stability (and of course price).
There's been a lot of information and mis-information being bandied
around on websites from people who don't really quite understand what's
going on. I hope I don't contribute to the confusion! It wasn't helped
by the, frankly, heavy-handed way it was handled by RH.
One of the problems is that people are trying to put a label on what 8-
stream is - such as development version, or RC, or beta version or
whatever. To be honest all we can do is to try and understand what RH
want. As far as I understand it, 8-stream accumulates new versions of
packages that will collectively go to make up the next point release of
RHEL8. We have been told, and we can only take it at face value, that
the versions that go into 8-stream will be final, QC'd packages: they
are not test, development or beta versions, nor are they "work in
progress". 8-stream will be a complete and functioning, stable distro.
So rather than waiting to get the new versions of things once every 6
months, 8-stream gets them when they are ready.
The confusion about the "development" label is that RH said that 8-
stream will be the distro used for their development process. So
internally things will be developed and compiled in an 8-stream
environment. They have never said that the development packages will
ever be visible or available in 8-stream itself until they are ready to
be set free.
TBH I would have thought that this exactly how RH operate internally at
the moment - they must have, say, a pre-8.3 environment that they put
packages in so that when new packages are developed that can be
compiled and everything is compatible. I really can't imagine that
packages are developed in isolation until there's a big 8.3 compile
time. All they are doing is making that internal system a public thing.
Now it's certainly possible that from RH point of view, releasing the
packages into the wild is a very good way of finding bugs that might
have slipped through QC - there is after all already a steady stream of
updates between point releases. So the benefit for RH is that paying
customers get potentially fewer updates between releases, but the
implication is that 8-stream will be no less stable than CentOS 8
currently is.
The rhetoric from RH is that the tooling of the 8-stream system is not
fully in place yet, but should be soon. Again, we can only take them
at their word and watch what happens. And I must stress that I am no RH
apologist: I think it was all handled incredibly badly by them and they
desperately need to get some change management experience!!
If you are considering using 8-stream then you need to understand that
there is no specific point-release configuration that you can base
things on - you cann't say that this is "equivalent to RHEL 8.5" or
whatever; this is important if you need to use 3rd party drivers during
install as they are based on specific configurations (but hey, install
CentOS 8.2 and move to 8-stream from there and upgrade). Also the
lifetime of 8-stream is half what you've been used to - so come 2024,
it will die; but 9-stream will have existed for at least a couple of
years by then, so there is a roadmap.
As for what you should do, than no one can really tell you. My advice
to others has been to watch, evaluate, test. If you are running bog
standard web servers with nothing exotic, then I have a feeling that 8-
stream will work; if you are running 3rd party apps on a web service
where versions matter, then you need to think carefully and consider
switching to one of the rebuild distros.
>
> Of course, a lot of this is somewhat dependent on what DigitalOcean will
> decide to provide image wise moving forward.
I suspect that as more and more things become containerised (and boy do
I dislike containers), the actual underlying OS will become
considerably less important.
P.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
