Hello,
I just tried installing a VM from the stream ISO and it worked;
the only thing I would like to have changed as a default config is
GRUB_CMDLINE_LINUX=".... net.ifnames=0 ..."
the reason, I find eth0, eth1, eth2 easier to use than cryptic names like ens33 or ens0p3 or so;
Walter
p.s. can someone tell in as short as possible what this CentOS Stream is in comparison to CentOS 8?
On 12/9/20 8:41 AM, Walter H. wrote:
Hello,
I just tried installing a VM from the stream ISO and it worked;
the only thing I would like to have changed as a default config is
GRUB_CMDLINE_LINUX=".... net.ifnames=0 ..."
the reason, I find eth0, eth1, eth2 easier to use than cryptic names like ens33 or ens0p3 or so;
Walter
p.s. can someone tell in as short as possible what this CentOS Stream is in comparison to CentOS 8?
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.
On Dec 9, 2020, at 9:45 AM, Johnny Hughes <johnny@centos.orgmailto:johnny@centos.org> wrote:
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.
If this statement is exactly correct, then I think a lot of the issues in this thread may be easy to address. However, the question is whether it is really "That will become" or actually "That might become, if it turns out to be stable enough,"
I.e., to me the critical question is how often (in practice) will updates that have problems, and will not actually make it into RHEL, end up in CentOS Stream. Presumably all such updates will be superseded in Stream by corrected ones, before they're in RHEL.
In fact, would it be possible, to list the final versions of each package's update at the moment of the RHEL release, and only do the CentOS Stream update based on that list?
Noam
On 12/9/20 8:54 AM, Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote:
On Dec 9, 2020, at 9:45 AM, Johnny Hughes <johnny@centos.orgmailto:johnny@centos.org> wrote:
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.
If this statement is exactly correct, then I think a lot of the issues in this thread may be easy to address. However, the question is whether it is really "That will become" or actually "That might become, if it turns out to be stable enough,"
I.e., to me the critical question is how often (in practice) will updates that have problems, and will not actually make it into RHEL, end up in CentOS Stream. Presumably all such updates will be superseded in Stream by corrected ones, before they're in RHEL.
In fact, would it be possible, to list the final versions of each package's update at the moment of the RHEL release, and only do the CentOS Stream update based on that list?
There is one source for the source code that will be used. While in stream it will iterative (the push a bunch of changes today .. the build those change today). Those go through a CI process and get released into stream.
When it comes time to build rhel 8.4 it will come from the same source code.
On Wed, 9 Dec 2020, Johnny Hughes wrote:
On 12/9/20 8:54 AM, Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote:
On Dec 9, 2020, at 9:45 AM, Johnny Hughes <johnny@centos.orgmailto:johnny@centos.org> wrote:
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.
If this statement is exactly correct, then I think a lot of the issues in this thread may be easy to address. However, the question is whether it is really "That will become" or actually "That might become, if it turns out to be stable enough,"
I.e., to me the critical question is how often (in practice) will updates that have problems, and will not actually make it into RHEL, end up in CentOS Stream. Presumably all such updates will be superseded in Stream by corrected ones, before they're in RHEL.
In fact, would it be possible, to list the final versions of each package's update at the moment of the RHEL release, and only do the CentOS Stream update based on that list?
There is one source for the source code that will be used. While in stream it will iterative (the push a bunch of changes today .. the build those change today). Those go through a CI process and get released into stream.
When it comes time to build rhel 8.4 it will come from the same source code.
If a bug were to make it into CentOS Stream, and identified before RHEL 8.4 was released, would an updated/fixed package be produced and placed into CentOS Stream?
If a bug were to make it past CentOS Stream and into RHEL 8.4 and the bug is then identified and fixed after the release of RHEL 8.4 would an updated/fixed package be produced and placed into CentOS Stream in the same timeframe or only if/when updated packages and their dependencies were made/released into CentOS Stream for updated features for RHEL 8.5?
If the same happened in the previous question but was in a package or set of packages that was being rebased in 8.5 would it work the same way?
Thanks, Barry
On Wed, Dec 09, 2020 at 09:58:10AM -0600, Barry Brimer wrote:
If a bug were to make it into CentOS Stream, and identified before RHEL 8.4 was released, would an updated/fixed package be produced and placed into CentOS Stream?
Absolutely. The only path into RHEL minor releases that isn't through Stream is for CVEs and other embargoed changes. And those will go back into Stream as soon as they can.
If a bug were to make it past CentOS Stream and into RHEL 8.4 and the bug is then identified and fixed after the release of RHEL 8.4 would an updated/fixed package be produced and placed into CentOS Stream in the same timeframe or only if/when updated packages and their dependencies were made/released into CentOS Stream for updated features for RHEL 8.5?
It might depend on the situation, but I would expect the fix to land quickly in Stream.
If the same happened in the previous question but was in a package or set of packages that was being rebased in 8.5 would it work the same way?
Hmmm. I'm not sure I understand you. There won't be a dump of 8.5 packages into Stream at some point. They will be updated there as ready.
On Dec 9, 2020, at 1:22 PM, Matthew Miller mattdm@mattdm.org wrote:
On Wed, Dec 09, 2020 at 09:58:10AM -0600, Barry Brimer wrote:
If a bug were to make it into CentOS Stream, and identified before RHEL 8.4 was released, would an updated/fixed package be produced and placed into CentOS Stream?
Absolutely. The only path into RHEL minor releases that isn't through Stream is for CVEs and other embargoed changes. And those will go back into Stream as soon as they can.
Does that mean that it will always be possible to recreate the set of final RHEL point release packages by cherry-picking from Stream? If so, isn't that a solution (and, I'd argue, _the_ solution if there's some officially supported way of grabbing that set)?
Noam
On Wed, Dec 09, 2020 at 06:26:22PM +0000, Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote:
Absolutely. The only path into RHEL minor releases that isn't through Stream is for CVEs and other embargoed changes. And those will go back into Stream as soon as they can.
Does that mean that it will always be possible to recreate the set of final RHEL point release packages by cherry-picking from Stream? If so, isn't that a solution (and, I'd argue, _the_ solution if there's some officially supported way of grabbing that set)?
There might be some complexity I'm not seeing, but offhand I don't see why not.
On Wed, 9 Dec 2020 13:22:15 -0500 Matthew Miller mattdm@mattdm.org wrote:
On Wed, Dec 09, 2020 at 09:58:10AM -0600, Barry Brimer wrote:
If the same happened in the previous question but was in a package or set of packages that was being rebased in 8.5 would it work the same way?
Hmmm. I'm not sure I understand you. There won't be a dump of 8.5 packages into Stream at some point. They will be updated there as ready.
The scenario I imagine is this:
start out the same EL 8.4 foo-1.1.1-1 stream-8 foo-1.1.1-1
update stream for EL 8.5
EL 8.4 foo-1.1.1-1 stream-8 foo-1.2.0-1
CVE!
EL 8.4 foo-1.1.2-1 stream-8 foo-1.2.1-1
Result: foo-1.1.2-1 is in EL but not stream.
Jim
On 12/9/20 12:55 PM, James Szinger wrote:
On Wed, 9 Dec 2020 13:22:15 -0500 Matthew Miller mattdm@mattdm.org wrote:
On Wed, Dec 09, 2020 at 09:58:10AM -0600, Barry Brimer wrote:
If the same happened in the previous question but was in a package or set of packages that was being rebased in 8.5 would it work the same way?
Hmmm. I'm not sure I understand you. There won't be a dump of 8.5 packages into Stream at some point. They will be updated there as ready.
The scenario I imagine is this:
start out the same EL 8.4 foo-1.1.1-1 stream-8 foo-1.1.1-1
update stream for EL 8.5
EL 8.4 foo-1.1.1-1 stream-8 foo-1.2.0-1
CVE!
EL 8.4 foo-1.1.2-1 stream-8 foo-1.2.1-1
Result: foo-1.1.2-1 is in EL but not stream.
Sure .. they only time things will match 100% is at point release time. All the packages in 8.4 will have at some point been in stream when rhel 8.4 is released.
Packages in between point releases will not necessarily be in stream .. but their equivalent will be. It will have the CVE and/or bugfix .. it will not likely be the exact same envr, but the one that will be in the new point release.
On Wed, 9 Dec 2020, Johnny Hughes wrote:
On 12/9/20 8:54 AM, Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote:
On Dec 9, 2020, at 9:45 AM, Johnny Hughes <johnny@centos.orgmailto:johnny@centos.org> wrote:
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.
If this statement is exactly correct, then I think a lot of the issues in this thread may be easy to address. However, the question is whether it is really "That will become" or actually "That might become, if it turns out to be stable enough,"
I.e., to me the critical question is how often (in practice) will updates that have problems, and will not actually make it into RHEL, end up in CentOS Stream. Presumably all such updates will be superseded in Stream by corrected ones, before they're in RHEL.
In fact, would it be possible, to list the final versions of each package's update at the moment of the RHEL release, and only do the CentOS Stream update based on that list?
There is one source for the source code that will be used. While in stream it will iterative (the push a bunch of changes today .. the build those change today). Those go through a CI process and get released into stream.
When it comes time to build rhel 8.4 it will come from the same source code.
So if I understand this correctly, centos8 + will basically be a rolling release and we will never know what we are really running. Is this correct?
To put it another way all of the stability we are used to will be gone and in order to stay up to date with stream I could potentially need to reboot machines daily depending on what packages $REDHAT developer decides to work on that day.
Am I missing something?
Regards,
On Dec 10, 2020, at 11:50 AM, me@tdiehl.org wrote:
So if I understand this correctly, centos8 + will basically be a rolling release and we will never know what we are really running. Is this correct?
That's my understanding, iff you automatically install all CentOS stream updates the moment they become available. But I still don't see why nearly no one is going for the idea that there be some way (ideally automated) to tag all the packages at the point of the RedHat release, and install only those from Stream once the RHEL release is ready?
Noam
On Thu, Dec 10, 2020 at 12:02 PM Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS centos@centos.org wrote:
On Dec 10, 2020, at 11:50 AM, me@tdiehl.org wrote:
So if I understand this correctly, centos8 + will basically be a rolling
release
and we will never know what we are really running. Is this correct?
That's my understanding, iff you automatically install all CentOS stream updates the moment they become available. But I still don't see why nearly no one is going for the idea that there be some way (ideally automated) to tag all the packages at the point of the RedHat release, and install only those from Stream once the RHEL release is ready?
That's called CentOS 8, and it's been killed.
On Thu, Dec 10, 2020 at 05:02:17PM +0000, Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote:
That's my understanding, iff you automatically install all CentOS stream updates the moment they become available. But I still don't see why nearly no one is going for the idea that there be some way (ideally automated) to tag all the packages at the point of the RedHat release, and install only those from Stream once the RHEL release is ready?
Yeah, I have some sysadmin friends already working on exactly this for their deployment in a large-scale academic setting.
On Thu, Dec 10, 2020 at 12:09 PM Matthew Miller mattdm@mattdm.org wrote:
On Thu, Dec 10, 2020 at 05:02:17PM +0000, Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote:
That's my understanding, iff you automatically install all CentOS stream updates the moment they become available. But I still don't see why
nearly
no one is going for the idea that there be some way (ideally automated)
to
tag all the packages at the point of the RedHat release, and install only those from Stream once the RHEL release is ready?
Yeah, I have some sysadmin friends already working on exactly this for their deployment in a large-scale academic setting.
Do you not see the huge irony here?
Why should a sysadmin have to do this?
We shouldn't.
On Thu, Dec 10, 2020 at 12:11:51PM -0500, Phelps, Matthew wrote:
Yeah, I have some sysadmin friends already working on exactly this for their deployment in a large-scale academic setting.
Do you not see the huge irony here? Why should a sysadmin have to do this? We shouldn't.
Well, I don't think you have to. But it's open source and it's cool that you *can* do things like this if you want to.
On Thu, Dec 10, 2020 at 12:20 PM Matthew Miller mattdm@mattdm.org wrote:
On Thu, Dec 10, 2020 at 12:11:51PM -0500, Phelps, Matthew wrote:
Yeah, I have some sysadmin friends already working on exactly this for their deployment in a large-scale academic setting.
Do you not see the huge irony here? Why should a sysadmin have to do this? We shouldn't.
Well, I don't think you have to. But it's open source and it's cool that you *can* do things like this if you want to.
The blindness is absolutely amazing.
We don't look at this as a fun little project we can endlessly dick around with. The *vast* majority of CenOS installations are on servers/workstations in large *enterprises*. That's what the "E" in RHEL stands for. Remember?.
This is why we don't use your Fedora. It's too unstable. And the lifetime is *way* too short.
We need a stable operating system. We had one. We no longer do because of what your company did to us. And we can't afford $300+ per machine.
I respectfully request that you keep that in mind when discussing things in the CenOS list. Your viewpoint is from the Fedora side.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 10/12/2020 17:20, Matthew Miller wrote:
On Thu, Dec 10, 2020 at 12:11:51PM -0500, Phelps, Matthew wrote:
Yeah, I have some sysadmin friends already working on exactly this for their deployment in a large-scale academic setting.
Do you not see the huge irony here? Why should a sysadmin have to do this? We shouldn't.
Well, I don't think you have to. But it's open source and it's cool that you *can* do things like this if you want to.
LOL, did you do that deliberately or did you honestly not get what Matthew (Phelps) was saying?
On Thu, Dec 10, 2020 at 11:09 AM Matthew Miller mattdm@mattdm.org wrote:
On Thu, Dec 10, 2020 at 05:02:17PM +0000, Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote:
That's my understanding, iff you automatically install all CentOS stream updates the moment they become available. But I still don't see why
nearly
no one is going for the idea that there be some way (ideally automated)
to
tag all the packages at the point of the RedHat release, and install only those from Stream once the RHEL release is ready?
Yeah, I have some sysadmin friends already working on exactly this for their deployment in a large-scale academic setting.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
SMH, really lets jump through hoops based on an arbitrary decision made by somebody or somone, who really knows since no one has said how the decision was reached. I'm pretty sure that most are just going to pack up and find another home, if I have to spend time doing something i'd rather it be permanent vs who knows what decision is going to be made next by RH.
Am 10.12.20 um 18:09 schrieb Matthew Miller:
On Thu, Dec 10, 2020 at 05:02:17PM +0000, Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote:
That's my understanding, iff you automatically install all CentOS stream updates the moment they become available. But I still don't see why nearly no one is going for the idea that there be some way (ideally automated) to tag all the packages at the point of the RedHat release, and install only those from Stream once the RHEL release is ready?
Yeah, I have some sysadmin friends already working on exactly this for their deployment in a large-scale academic setting.
Will we know that point in time everytime before releasing? Because on release day the Stream repo is already a step forward. Albeit when this works then the situation are more worse then with CentOS Linux release work and the time shift compared to RHEL release. Why? Because 6 month updates are accumulated and not installed? Even cherry-picking is crazy. The audience here needs something different - but this was already stated elsewhere!
-- Leon
Am 10.12.20 um 18:02 schrieb Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS:
On Dec 10, 2020, at 11:50 AM, me@tdiehl.org wrote:
So if I understand this correctly, centos8 + will basically be a rolling release and we will never know what we are really running. Is this correct?
That's my understanding, iff you automatically install all CentOS stream updates the moment they become available. But I still don't see why nearly no one is going for the idea that there be some way (ideally automated) to tag all the packages at the point of the RedHat release, and install only those from Stream once the RHEL release is ready?
Evaluating all the fragmented informations (another topic; communication to community) I get the impression that CXStream will never have a state that reflects RHEL point releases (not 100%). Why? Well CVE are one reason and another will be the different parts that are moving differently forward and the late parts (CVE coming after RHEL release) and so on ...
-- Leon
On Thu, Dec 10, 2020 at 11:50:00AM -0500, me@tdiehl.org wrote:
So if I understand this correctly, centos8 + will basically be a rolling release and we will never know what we are really running. Is this correct?
No, this is not the case. There will be continuous updates, but all of these updates are ones that are planned to go into a RHEL minor release, with all of the normal things that will imply. As Brendan said, .y stream development is really not all that exciting.
To put it another way all of the stability we are used to will be gone and in order to stay up to date with stream I could potentially need to reboot machines daily depending on what packages $REDHAT developer decides to work on that day.
I mean, if there are updates you want that day, sure?
On 12/10/2020 9:08 AM, Matthew Miller wrote:
On Thu, Dec 10, 2020 at 11:50:00AM -0500, me@tdiehl.org wrote:
So if I understand this correctly, centos8 + will basically be a rolling release and we will never know what we are really running. Is this correct?
No, this is not the case. There will be continuous updates, but all of these updates are ones that are planned to go into a RHEL minor release, with all of the normal things that will imply. As Brendan said, .y stream development is really not all that exciting.
"[W]e’ll be shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just/ahead/of a current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021. CentOS Stream continues after that date, serving as the upstream (development) branch of Red Hat Enterprise Linux.... It gives the CentOS contributor community a great deal of influence in the future of RHEL."
Someone (or several someones) at RedHat is/are very confused.
As I wrote elsewhere, CentOS Whatever cannot be both upstream and downstream of RHEL and serve both roles adequately. If CentOS Stream remains just a CR/Early Access for updates that have passed all decision-making and QA processes and are well on their way to the upcoming RHEL point release, then there's no real input that can be had here, and there also appears to be no change from what CentOS Stream has been for this entire EL8 cycle.
If so, then the "great deal of influence" and "development/upstream branch" is meaningless drivel and the death of CentOS Linux (the rebuild) needs to be considered on its own merits as a distinct act by RedHat without distraction.
A true "Enterprise Upstream" distinct from Fedora, where the community has a snowball's chance at preventing laptop-focused Fedora-isms from destabilizing the core, is a niche begging to be filled. But that's not what's being presented to us, and telling SIGs to poke around on Stream instead of Linux does nothing for the vast majority of use cases external to RedHat.
If the decision-makers (not the CentOS board, clearly) are being presented these responses then they should realize that the community expects a real post-mortem and explanation here.
-jc
On 12/10/20 10:50 AM, me@tdiehl.org wrote:
On Wed, 9 Dec 2020, Johnny Hughes wrote:
On 12/9/20 8:54 AM, Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote:
On Dec 9, 2020, at 9:45 AM, Johnny Hughes <johnny@centos.orgmailto:johnny@centos.org> wrote:
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.
If this statement is exactly correct, then I think a lot of the issues in this thread may be easy to address. However, the question is whether it is really "That will become" or actually "That might become, if it turns out to be stable enough,"
I.e., to me the critical question is how often (in practice) will updates that have problems, and will not actually make it into RHEL, end up in CentOS Stream. Presumably all such updates will be superseded in Stream by corrected ones, before they're in RHEL.
In fact, would it be possible, to list the final versions of each package's update at the moment of the RHEL release, and only do the CentOS Stream update based on that list?
There is one source for the source code that will be used. While in stream it will iterative (the push a bunch of changes today .. the build those change today). Those go through a CI process and get released into stream.
When it comes time to build rhel 8.4 it will come from the same source code.
So if I understand this correctly, centos8 + will basically be a rolling release and we will never know what we are really running. Is this correct?
You will be running CentOS Stream 8.
It is not a rolling release in the sense of .. it moves from Stream 8 to Stream 9 .. it will be Stream 8 until you manually move to Stream 9 or we get to the EOL (Currently May 31 2024).
To put it another way all of the stability we are used to will be gone and in order to stay up to date with stream I could potentially need to reboot machines daily depending on what packages $REDHAT developer decides to work on that day.
Well .. they will be working on the next RHEL point release. So the package will be from 8.4 if the current release is 8.3 and you are running CentOS Stream 8.
It would be from 9.2 if the current release was 9.1 and you were on CentOS Stream 9.
Am I missing something?
Am 09.12.20 um 15:54 schrieb Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS:
On Dec 9, 2020, at 9:45 AM, Johnny Hughes <johnny@centos.orgmailto:johnny@centos.org> wrote:
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.
If this statement is exactly correct, then I think a lot of the issues in this thread may be easy to address. However, the question is whether it is really "That will become" or actually "That might become, if it turns out to be stable enough,"
I.e., to me the critical question is how often (in practice) will updates that have problems, and will not actually make it into RHEL, end up in CentOS Stream. Presumably all such updates will be superseded in Stream by corrected ones, before they're in RHEL.
In fact, would it be possible, to list the final versions of each package's update at the moment of the RHEL release, and only do the CentOS Stream update based on that list?
What should be also taking into account: - There is no "CentOS" (Linux or Stream does not matter) that have a life span of 10 years. Centos Stream 8 will be retired and deleted from the mirrors end of May 2024 Q1!
-- Leon
The companies that pay for RHEL licenses for production and use CentOS for test will be left with a large problem. They will either need to purchase double the number of RHEL licenses and switch to RHEL for testing or go to another distribution. RHEL + 1 will not work for testing application compatibility with patches.
No company will want to pay double the amount they are currently paying for RHEL licenses. This is not even addressing the cost and time it will take to switch over all the test servers.
This will cost Red Hat credibility with major companies that they might never recover from. This will cost Red Hat major business.
I will be recommending that my company change to Oracle Linux 8, instead of upgrading to RHEL 8. We will get the same model we are currently using, Paid support for production and free for test servers.
Andrea
-----Original Message----- From: CentOS centos-bounces@centos.org On Behalf Of Johnny Hughes Sent: Wednesday, December 9, 2020 8:45 AM To: centos@centos.org Subject: {EXTERNAL} Re: [CentOS] CentOS Stream from bottom works, what is this?
CAUTION: This email originated outside of BSWH; avoid action unless you know the content is safe. Send suspicious emails as attachments to BadEmail@BSWHealth.org.
On 12/9/20 8:41 AM, Walter H. wrote:
Hello,
I just tried installing a VM from the stream ISO and it worked;
the only thing I would like to have changed as a default config is
GRUB_CMDLINE_LINUX=".... net.ifnames=0 ..."
the reason, I find eth0, eth1, eth2 easier to use than cryptic names like ens33 or ens0p3 or so;
Walter
p.s. can someone tell in as short as possible what this CentOS Stream is in comparison to CentOS 8?
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months. _______________________________________________ CentOS mailing list CentOS@centos.org https://urldefense.com/v3/__https://lists.centos.org/mailman/listinfo/centos...
********************************************************************** The information contained in this e-mail may be privileged and/or confidential, and protected from disclosure, and no waiver of any attorney-client, work product, or other privilege is intended. If you are the intended recipient, further disclosures are prohibited without proper authorization. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden and possibly a violation of federal or state law and regulations. The sender and Baylor Scott & White Health, and its affiliated entities, hereby expressly reserve all privileges and confidentiality that might otherwise be waived as a result of an erroneous or misdirected e-mail transmission. No employee or agent is authorized to conclude any binding agreement on behalf of Baylor Scott & White Health, or any affiliated entity, by e-mail without express written confirmation by the CEO, the Senior Vice President of Supply Chain Services or other duly authorized representative of Baylor Scott & White Health.
On Wed, Dec 09, 2020 at 04:03:42PM +0000, Laack, Andrea P wrote:
The companies that pay for RHEL licenses for production and use CentOS for test will be left with a large problem. They will either need to purchase double the number of RHEL licenses and switch to RHEL for testing or go to another distribution. RHEL + 1 will not work for testing application compatibility with patches.
In the cases where RHEL + 0.1 (note not +1) won't work, I think it's incredibly likely that this will be covered by the expanded low- and no-cost RHEL offerings.
Part of the buried lede here is that with more RHEL accessibility, a lot of the function that CentOS served for users will not be necessary anymore.
No company will want to pay double the amount they are currently paying for RHEL licenses. This is not even addressing the cost and time it will take to switch over all the test servers.
Yeah, Red Hat knows this. Hence the above. If you have a specific case, please email the centos-questions@redhat.com address -- that goes to the people designing the new programs, not to sales.
On Wed, Dec 9, 2020 at 1:18 PM Matthew Miller mattdm@mattdm.org wrote:
On Wed, Dec 09, 2020 at 04:03:42PM +0000, Laack, Andrea P wrote:
The companies that pay for RHEL licenses for production and use CentOS
for
test will be left with a large problem. They will either need to purchase double the number of RHEL licenses and switch to RHEL for testing or go
to
another distribution. RHEL + 1 will not work for testing application compatibility with patches.
In the cases where RHEL + 0.1 (note not +1) won't work, I think it's incredibly likely that this will be covered by the expanded low- and no-cost RHEL offerings.
Part of the buried lede here is that with more RHEL accessibility, a lot of the function that CentOS served for users will not be necessary anymore.
No company will want to pay double the amount they are currently paying for RHEL licenses. This is not even addressing the cost and time it will take to switch over all the test servers.
Yeah, Red Hat knows this. Hence the above. If you have a specific case, please email the centos-questions@redhat.com address -- that goes to the people designing the new programs, not to sales.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader ______________________________________________
Don't you think it might have been a good idea to solicit these type of situations *before* killing CenOS 8?
After the complete and utter disaster RedHat has shat upon the World with the handling of this, there is no way anyone will ever trust that a "free" or "low cost" version of RHEL will stay that way for any length of time. To suggest so to this list, today, is ludicrous.
Unless there's a reversal of course here, I, and many others, will never recommend any RHEL product to my superiors from now on.
(I'm hoping the horse isn't dead yet.)
On 12/9/2020 10:18 AM, Matthew Miller wrote:
On Wed, Dec 09, 2020 at 04:03:42PM +0000, Laack, Andrea P wrote:
The companies that pay for RHEL licenses for production and use CentOS for test will be left with a large problem. They will either need to purchase double the number of RHEL licenses and switch to RHEL for testing or go to another distribution. RHEL + 1 will not work for testing application compatibility with patches.
In the cases where RHEL + 0.1 (note not +1) won't work, I think it's incredibly likely that this will be covered by the expanded low- and no-cost RHEL offerings.
Part of the buried lede here is that with more RHEL accessibility, a lot of the function that CentOS served for users will not be necessary anymore.
It's buried, but the decision-makers failed to understand that the suddenness of this decision, outside of the community expectation for CentOS Linux continuing to be a thing (remember: Scientific Linux continued supporting SL6 right up to the end even after announcing that there would be no SL8), calls into question the stability of a lot of RedHat's actions when it comes to distro decisions. Based on other emails, the CentOS Board perhaps understood this and the people issuing directions from RedHat perhaps did not. That does not bode well.
Enterprises, and enterprise users, need reliability and confidence that their choices are the correct ones. How will RedHat/IBM restore confidence in the longevity of the offerings it's producing?
-jc
On Wed, Dec 9, 2020 at 7:19 PM Matthew Miller mattdm@mattdm.org wrote:
[...] In the cases where RHEL + 0.1 (note not +1) won't work, I think it's incredibly likely that this will be covered by the expanded low- and no-cost RHEL offerings.
Part of the buried lede here is that with more RHEL accessibility, a lot of the function that CentOS served for users will not be necessary anymore. [...]
If RH plans to release a successor for CentOS 8 like RHEL 8 Free or so, this has become a communication disaster par excellence. The announcement with all the associated uncertainties and criticism was already picked up by the major press. I've no clue who is in charge of RH for the communication, but the team was quite bad in their job.
If I plan something like this I would say, listen, CentOS will be released as Stream only in the future but the deprecated CentOS versions will be replaced by X. Before we do this change we'll provide to you a script that transforms your current CentOS installation into the designated successor. I'm quite relaxed as I don't use CentOS anymore except for private stuff. But I can fully understand those who already upgraded to C8 with the assumption in mind that they can use CentOS for the next few years with the expected behaviour.
Changes are part of the IT and maybe the situation won't become as dramatic as the one or other may fear (especially if a kind of RHEL 8 Free will be released), but the communication around this change is a perfect example how you shouldn't do the communication.
Kind regards Thomas
On Wed, Dec 9, 2020 at 7:19 PM Matthew Miller mattdm@mattdm.org wrote:
[...] In the cases where RHEL + 0.1 (note not +1) won't work, I think it's incredibly likely that this will be covered by the expanded low- and no-cost RHEL offerings.
Part of the buried lede here is that with more RHEL accessibility, a lot of the function that CentOS served for users will not be necessary anymore. [...]
If RH plans to release a successor for CentOS 8 like RHEL 8 Free or so, this has become a communication disaster par excellence. The announcement with all the associated uncertainties and criticism was already picked up by the major press. I've no clue who is in charge of RH for the communication, but the team was quite bad in their job.
If I plan something like this I would say, listen, CentOS will be released as Stream only in the future but the deprecated CentOS versions will be replaced by X. Before we do this change we'll provide to you a script that transforms your current CentOS installation into the designated successor.
Do you mean something like this?
https://linux.oracle.com/switch/centos2ol.sh
I'm quite relaxed as I don't use CentOS anymore except for private stuff. But I can fully understand those who already upgraded to C8 with the assumption in mind that they can use CentOS for the next few years with the expected behaviour.
Changes are part of the IT and maybe the situation won't become as dramatic as the one or other may fear (especially if a kind of RHEL 8 Free will be released), but the communication around this change is a perfect example how you shouldn't do the communication.
Kind regards Thomas
Linux ... enjoy the ride! _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Thu, Dec 10, 2020 at 3:54 PM Simon Matter simon.matter@invoca.ch wrote:
[...] Do you mean something like this?
Haven't tried this one, but yes, this is from a principal point of view what I mean.
Kind regards Thomas
On 09.12.2020 15:45, Johnny Hughes wrote:
On 12/9/20 8:41 AM, Walter H. wrote:
p.s. can someone tell in as short as possible what this CentOS Stream is in comparison to CentOS 8?
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.
what does this mean in comparison to CentOS 8, which sources are used for this?
to be concrete:
I can download this ISO of CentOS 8
(1) CentOS-8.3.2011-x86_64-dvd1.iso
and this ISO fo CentOS Stream
(2) CentOS-Stream-8-x86_64-20201203-dvd1.iso
which sources are used for (1) and which for (2)?
and what does it mean of the update process be 'yum update'
e.g. if one would do this with CentOS 6, there is no way; the support ended;
with CentOS 8 this will haben one day (somewhat in 2029), and what is said about this of CentOS Stream?
Thanks,
Walter
On 12/9/20 11:01 AM, Walter H. wrote:
On 09.12.2020 15:45, Johnny Hughes wrote:
On 12/9/20 8:41 AM, Walter H. wrote:
p.s. can someone tell in as short as possible what this CentOS Stream is in comparison to CentOS 8?
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.
what does this mean in comparison to CentOS 8, which sources are used for this?
to be concrete:
I can download this ISO of CentOS 8
(1) CentOS-8.3.2011-x86_64-dvd1.iso
and this ISO fo CentOS Stream
(2) CentOS-Stream-8-x86_64-20201203-dvd1.iso
which sources are used for (1) and which for (2)?
and what does it mean of the update process be 'yum update'
e.g. if one would do this with CentOS 6, there is no way; the support ended;
with CentOS 8 this will haben one day (somewhat in 2029), and what is said about this of CentOS Stream?
CentOS Linux 8 is the source code from released current RHEL 8 .. for now 8.3. The EOL of CentOS Linux 8 is 31 DEC 2021
CentOS Stream 8 is the source cdoe from what be RHEL + 0.1 .. so currently 8.3 + 0.1 = 8.4. It will EOL in 31 MAY 2024
CentOS Linux 6 EOLed 30 NOV 2020.
Am 09.12.20 um 18:12 schrieb Johnny Hughes:
On 12/9/20 11:01 AM, Walter H. wrote:
On 09.12.2020 15:45, Johnny Hughes wrote:
On 12/9/20 8:41 AM, Walter H. wrote:
p.s. can someone tell in as short as possible what this CentOS Stream is in comparison to CentOS 8?
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.
what does this mean in comparison to CentOS 8, which sources are used for this?
to be concrete:
I can download this ISO of CentOS 8
(1) CentOS-8.3.2011-x86_64-dvd1.iso
and this ISO fo CentOS Stream
(2) CentOS-Stream-8-x86_64-20201203-dvd1.iso
which sources are used for (1) and which for (2)?
and what does it mean of the update process be 'yum update'
e.g. if one would do this with CentOS 6, there is no way; the support ended;
with CentOS 8 this will haben one day (somewhat in 2029), and what is said about this of CentOS Stream?
CentOS Linux 8 is the source code from released current RHEL 8 .. for now 8.3. The EOL of CentOS Linux 8 is 31 DEC 2021
CentOS Stream 8 is the source cdoe from what be RHEL + 0.1 .. so currently 8.3 + 0.1 = 8.4. It will EOL in 31 MAY 2024
CentOS Linux 6 EOLed 30 NOV 2020.
A related question: Since Stream 8 will EoL in MAY 2024, when RHEL 8 will enter the 5-year-Maintenance Support phase, in which way will the sources of the updates released for RHEL 8 (modifications / patches of Open Source codes) be released? Will these still go to git.centos.org, or on a new, to-be-created platform?
Cheers, Oliver
On 09.12.2020 18:12, Johnny Hughes wrote:
On 12/9/20 11:01 AM, Walter H. wrote:
On 09.12.2020 15:45, Johnny Hughes wrote:
On 12/9/20 8:41 AM, Walter H. wrote:
p.s. can someone tell in as short as possible what this CentOS Stream is in comparison to CentOS 8?
CentOS Stream is built from the currently released RHEL Source Code + 0.1
So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.
what does this mean in comparison to CentOS 8, which sources are used for this?
to be concrete:
I can download this ISO of CentOS 8
(1) CentOS-8.3.2011-x86_64-dvd1.iso
and this ISO fo CentOS Stream
(2) CentOS-Stream-8-x86_64-20201203-dvd1.iso
which sources are used for (1) and which for (2)?
and what does it mean of the update process be 'yum update'
e.g. if one would do this with CentOS 6, there is no way; the support ended;
with CentOS 8 this will haben one day (somewhat in 2029), and what is said about this of CentOS Stream?
CentOS Linux 8 is the source code from released current RHEL 8 .. for now 8.3. The EOL of CentOS Linux 8 is 31 DEC 2021
when doing 'yum update' regularly this would also be EOL the end of the following year?
CentOS Stream 8 is the source cdoe from what be RHEL + 0.1 .. so currently 8.3 + 0.1 = 8.4. It will EOL in 31 MAY 2024
this is much longer here, can I update this 'forever' just doing 'yum update' regularly?
why I am asking this, I need to choose one option, because my CentOS 6 VMs are EOL;
and I would practice this the same way I did, when my CentOS 4 became EOL, I installed CentOS 6 VM by VM - never used CentOS 5;
e.g. the first one was the DNS-VM, which I used CentOS 6.2, then the outgoing Mail-server-VM, I used CentOS 6.3 and by doing 'yum update' regularly they all became finally 6.10;
so which should I choose - CentOS 7: EOL in 2024 - CentOS Stream: EOL also in 2024 (CentOS 8 is no option I guess)
comparing to Windows, when using Win10, there is no install needed any more, every half year function update, and the other time security/bug fix update;
is doing CentOS Stream the same way?
Thanks,
Walter
-
Barry Brimer -
Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) -
James Szinger -
Japheth Cleaver -
Johnny Hughes -
Laack, Andrea P -
Leon Fauster -
Matthew Miller -
me＠tdiehl.org -
Oliver Freyermuth -
Phelps, Matthew -
Phil Perry -
Simon Matter -
Thomas Bendler -
Tom Bishop -
Walter H.