Hello
I've recently discovered the announcement regarding the change in direction for the CentOS project and I imagine like many others, I'm confused and concerned about what this means moving forward.
I work for a small web development agency and we offer hosting as part of our package to clients who need it. We have many CentOS 7 web servers (DigitalOcean droplets) (LAMP/LEMP) that I look after and today I'm thankful I have only migrated one of those to CentOS 8, given the recent announcement about its curtailed EOL. I literally just went to the Wiki today to confirm the EOL date for EL7 and boy am I glad I spotted it.
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).
Sure, I could migrate to Ubuntu (I use this locally in WSL), but I've become somewhat "comfy slippers" with CentOS and have built our setup around it (including custom ansible scripts etc) and don't want to change everything unncessarily.
Of course, a lot of this is somewhat dependent on what DigitalOcean will decide to provide image wise moving forward.
I'm sorry if this has already been answered, I spent a good few hours reading through the respective threads in the devel list and ended up more confused than I started.
Cheers, Jamie
On 05/01/2021 19:32, Jamie Burchell wrote:
Hello
I've recently discovered the announcement regarding the change in direction for the CentOS project and I imagine like many others, I'm confused and concerned about what this means moving forward.
I work for a small web development agency and we offer hosting as part of our package to clients who need it. We have many CentOS 7 web servers (DigitalOcean droplets) (LAMP/LEMP) that I look after and today I'm thankful I have only migrated one of those to CentOS 8, given the recent announcement about its curtailed EOL. I literally just went to the Wiki today to confirm the EOL date for EL7 and boy am I glad I spotted it.
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).
Sure, I could migrate to Ubuntu (I use this locally in WSL), but I've become somewhat "comfy slippers" with CentOS and have built our setup around it (including custom ansible scripts etc) and don't want to change everything unncessarily.
Of course, a lot of this is somewhat dependent on what DigitalOcean will decide to provide image wise moving forward.
I'm sorry if this has already been answered, I spent a good few hours reading through the respective threads in the devel list and ended up more confused than I started.
Cheers, Jamie
Hi Jamie,
Unfortunately no one can advise you as to what may be a suitable operating system for your business needs.
One thing is clear, the operating system you are currently running (CentOS Linux) is being brought to end of life, version 7 in 2024 and version 8 in 2021.
That gives you at least a year (for 8) if not longer to consider and evaluate alternatives. As your current OS will no longer exist, I would start with a blank sheet, look at the OSes that do exist and evaluate each based on it's merits and suitability for your business needs and requirements.
Cheers, Phil
Hmm, I see a relation here.
C7Linux - 2024 C8Linux - 2021
So I assume: C6Linux - 2027 C5Linux - 2030 C4Linux - 2033 ...
Interesting.
On Tue, 5 Jan 2021, 21:44 Phil Perry, pperry@elrepo.org wrote:
On 05/01/2021 19:32, Jamie Burchell wrote:
Hello
I've recently discovered the announcement regarding the change in
direction
for the CentOS project and I imagine like many others, I'm confused and concerned about what this means moving forward.
I work for a small web development agency and we offer hosting as part of our package to clients who need it. We have many CentOS 7 web servers (DigitalOcean droplets) (LAMP/LEMP) that I look after and today I'm thankful I have only migrated one of those to CentOS 8, given the recent announcement about its curtailed EOL. I literally just went to the Wiki today to confirm the EOL date for EL7 and boy am I glad I spotted it.
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).
Sure, I could migrate to Ubuntu (I use this locally in WSL), but I've become somewhat "comfy slippers" with CentOS and have built our setup around it (including custom ansible scripts etc) and don't want to change everything unncessarily.
Of course, a lot of this is somewhat dependent on what DigitalOcean will decide to provide image wise moving forward.
I'm sorry if this has already been answered, I spent a good few hours reading through the respective threads in the devel list and ended up
more
confused than I started.
Cheers, Jamie
Hi Jamie,
Unfortunately no one can advise you as to what may be a suitable operating system for your business needs.
One thing is clear, the operating system you are currently running (CentOS Linux) is being brought to end of life, version 7 in 2024 and version 8 in 2021.
That gives you at least a year (for 8) if not longer to consider and evaluate alternatives. As your current OS will no longer exist, I would start with a blank sheet, look at the OSes that do exist and evaluate each based on it's merits and suitability for your business needs and requirements.
Cheers, Phil
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Given we are not developing drivers or applications (other than websites and web applications), is the change a non-issue for my use-case?
If you decide to go with Stream, you will need to test carefully each version and use some kind of repository management - as there will be no older version of the packages. Thankfully the 'Boom boot manager' is now fully working, so you can easily roll back an OS update.
If you decide that you don't want to fight with updates and the short life cycle of Stream, you got plenty of clones that are available: - Springdale Linux - Oracle Enterprise Linux
And 2 more expected to come: - Rocky Linux (founder of the original CentOS -> Gregory Kurtzer) - Lenix (backed by CloudLinux)
I would prefer the full lifecycle of a RHEL clone instead of Stream.
Best Regards, Strahil Nikolov
The question for me, too is going to be, what will the VPS providers do? Digital Ocean, Vultur, etc. I'll be at their mercy, without trying to create my own image, if that's even possible.
Hopefully something emerges as the popular replacement (e.g. "Rocky"), and they support spinning up with the replacement.
Anyone have agues/opinion on the most popular emerging path those providers will use, I'm all ears.
Scott
I guess we need to wait and see how the dust settles. For those lucky enough to still be on CentOS 7, there's a bit of breathing space although these things take time to plan and implement of course. Those unlucky enough to have updated to CentOS 8 have less than a year to decide to move to stream or another distro. It's a good job that there's not a global pandemic disrupting work commitments so we have plenty of time to deal with these decisions from above!
I'm sure it's my lack of understanding, but there feels too much hope pinned on "Rocky", which seems like one person (albeit a key person) going it alone with the hope of a community following of disgruntled people. I see a single readme file in the repo. I think I'd feel more comfortable using Stream at this point.
The uncertainty is frustrating and unsettling.
On Tue, 5 Jan 2021 at 21:18, Scott Techlist techlist06@msxc.com wrote:
The question for me, too is going to be, what will the VPS providers do? Digital Ocean, Vultur, etc. I'll be at their mercy, without trying to create my own image, if that's even possible.
Hopefully something emerges as the popular replacement (e.g. "Rocky"), and they support spinning up with the replacement.
Anyone have agues/opinion on the most popular emerging path those providers will use, I'm all ears.
Scott
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Tue, Jan 5, 2021 at 3:32 PM Jamie Burchell mail@jamieburchell.com wrote:
I'm sure it's my lack of understanding, but there feels too much hope pinned on "Rocky", which seems like one person (albeit a key person) going it alone with the hope of a community following of disgruntled people. I see a single readme file in the repo. I think I'd feel more comfortable using Stream at this point.
The uncertainty is frustrating and unsettling.
If you still think Rocky is one guy going it alone then you haven't been paying any attention to it at all. The slack that it started on is so active that messages were falling off the 10k scroll back limit in a matter of days. It's quieted down some since they have been making use of their forums and working on moving to Mattermost, but that sure isn't the activity of one person.
The repo you refer to is just a holding one, with the readme in many translations. Go up one level and you'll see the 17 repos thay have for infrastructure and other needs. https://github.com/rocky-linux
Consider me firmly schooled and I apologise if I have caused any upset with my comment. My understanding of the situation was the result of pouring over countless threads where it's difficult to filter out the facts and reality. It's encouraging for sure that there's potentially at least one ship to jump to.
On Tue, 5 Jan 2021 at 21:48, Jon Pruente jpruente@riskanalytics.com wrote:
On Tue, Jan 5, 2021 at 3:32 PM Jamie Burchell mail@jamieburchell.com wrote:
I'm sure it's my lack of understanding, but there feels too much hope pinned on "Rocky", which seems like one person (albeit a key person)
going
it alone with the hope of a community following of disgruntled people. I see a single readme file in the repo. I think I'd feel more comfortable using Stream at this point.
The uncertainty is frustrating and unsettling.
If you still think Rocky is one guy going it alone then you haven't been paying any attention to it at all. The slack that it started on is so active that messages were falling off the 10k scroll back limit in a matter of days. It's quieted down some since they have been making use of their forums and working on moving to Mattermost, but that sure isn't the activity of one person.
The repo you refer to is just a holding one, with the readme in many translations. Go up one level and you'll see the 17 repos thay have for infrastructure and other needs. https://github.com/rocky-linux _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Tue, 5 Jan 2021 21:32:18 +0000 Jamie Burchell wrote:
The uncertainty is frustrating and unsettling.
I certainly agree with you on this point!
Personally, while I haven't made an actual decision on which way I'm going with my own projects, I'm currently leaning toward Oracle Linux. I installed it on a laptop a couple of days ago and what I got was exactly what I get when I install Centos on a laptop. Even my little script to convert a stock installation into my custom setup worked as-is, and what I ended up with was exactly what I was expecting to see.
I don't have any particular love for Oracle, but since they pay X number of people to keep Oracle Linux current with RHEL and updated, they shouldn't have any problems with burn-out or a lack of long-term interest on the part of volunteers that may (or may not) become an issue over the course of time with a community-driven distribution like Rocky.
But for the moment I'm more-or-less just sitting on my hands, waiting to see how all of this shakes out over the course of the next few months before I take any action to change anything.
Frankly, I'm kind of hoping that Rocky turns out to be "the new Centos", but it seems too early in the game to make the decision to depend on it. That may change over the course of the next few months.
but it seems too early in the game to make the decision to depend on
it. That may change over the course of the next few months.
Yes this is how I feel but conveyed badly in my last. It's currently a concept and not a viable distro to move to and in some cases there is only a year to make the move.
At this stage I'm not totally dismissive of Stream either. We already automatically update our systems with yum-cron / dnf automatic and I'm reading that if we're already doing that, Stream isn't going to be a departure i.e. minor version bumps - but I'm still trying to make sense of the impact in real-terms i.e. what actually changes if we move to Stream.
On Tue, 5 Jan 2021 at 21:59, Frank Cox theatre@sasktel.net wrote:
On Tue, 5 Jan 2021 21:32:18 +0000 Jamie Burchell wrote:
The uncertainty is frustrating and unsettling.
I certainly agree with you on this point!
Personally, while I haven't made an actual decision on which way I'm going with my own projects, I'm currently leaning toward Oracle Linux. I installed it on a laptop a couple of days ago and what I got was exactly what I get when I install Centos on a laptop. Even my little script to convert a stock installation into my custom setup worked as-is, and what I ended up with was exactly what I was expecting to see.
I don't have any particular love for Oracle, but since they pay X number of people to keep Oracle Linux current with RHEL and updated, they shouldn't have any problems with burn-out or a lack of long-term interest on the part of volunteers that may (or may not) become an issue over the course of time with a community-driven distribution like Rocky.
But for the moment I'm more-or-less just sitting on my hands, waiting to see how all of this shakes out over the course of the next few months before I take any action to change anything.
Frankly, I'm kind of hoping that Rocky turns out to be "the new Centos", but it seems too early in the game to make the decision to depend on it. That may change over the course of the next few months.
-- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 1/5/21 2:27 PM, Jamie Burchell wrote:
We already automatically update our systems with yum-cron / dnf automatic and I'm reading that if we're already doing that, Stream isn't going to be a departure
I'd have said the same: If you trust CentOS enough to update automatically, then Stream will be an easy migration for you. You'll get a distribution that's just as trustworthy, with the added benefit that you'll get security fixes much sooner than CentOS did.
but I'm still trying to make sense of the impact in real-terms i.e. what actually changes if we move to Stream.
You'll get updated versions of software when they're ready, rather than once every 6-8 months. They'll be roughly the same versions that RHEL will get later.
In that case, it sounds like a non-issue for the way we currently use CentOS.
As there's a simple migration from CentOS 8 to Stream and Digital Ocean currently provide CentOS 8 images, it'll be interesting to see what they do moving forward.
Le 05/01/2021 à 22:59, Frank Cox a écrit :
I don't have any particular love for Oracle, but since they pay X number of people to keep Oracle Linux current with RHEL and updated, they shouldn't have any problems with burn-out or a lack of long-term interest on the part of volunteers that may (or may not) become an issue over the course of time with a community-driven distribution like Rocky.
Similar situation here. Carefully maintaining my servers running CentOS 7, slowly moving to Oracle Linux while keeping an eye on Rocky Linux.
Glad I based my last two Linux books on CentOS 7 and not 8. When volume 1 was still a manuscript, someone on this list made fun about it not being based on CentOS 8 and therefore reflecting Linux in the past. As things are, all 40 chapters are now valid until 2024 instead of 2021.
Cheers,
Niki
On 1/5/21 11:32 AM, Jamie Burchell wrote:
is the change a non-issue for my use-case?
Probably. For a lot of users, Stream is a drop-in replacement that's better than CentOS was, because it gets updates consistently and doesn't suffer from periods in which no updates are available, including security updates.
If security was a priority for you, as it was for me, then CentOS wasn't really suitable for public-facing services, but CentOS Stream might be.
If you're building software that you intend to deploy on RHEL, Stream might not be a suitable build root for you. Compiling software in a Stream build root may result in a binary that has dependencies which aren't yet available in RHEL. And if you're building kernel modules (like Phil @elrepo), then there is the issue that the kernel isn't subject to RHEL's ABI policy, but Red Hat developers have expressed interest in making the kernel interfaces more stable and using external kernel module builds as a test to flag interfaces that have changed. So that situation may improve...
If security was a priority for you, as it was for me, then CentOS wasn't
really suitable for public-facing services
You mean in terms of security patch release time presumably?
If you're building software that you intend to deploy on RHEL
We're not building or compiling software.
On Tue, 5 Jan 2021 at 22:51, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/5/21 11:32 AM, Jamie Burchell wrote:
is the change a non-issue for my use-case?
Probably. For a lot of users, Stream is a drop-in replacement that's better than CentOS was, because it gets updates consistently and doesn't suffer from periods in which no updates are available, including security updates.
If security was a priority for you, as it was for me, then CentOS wasn't really suitable for public-facing services, but CentOS Stream might be.
If you're building software that you intend to deploy on RHEL, Stream might not be a suitable build root for you. Compiling software in a Stream build root may result in a binary that has dependencies which aren't yet available in RHEL. And if you're building kernel modules (like Phil @elrepo), then there is the issue that the kernel isn't subject to RHEL's ABI policy, but Red Hat developers have expressed interest in making the kernel interfaces more stable and using external kernel module builds as a test to flag interfaces that have changed. So that situation may improve...
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Probably. For a lot of users, Stream is a drop-in replacement that's
better than CentOS was
We will need to (manually) migrate to Stream 9.x after 5 years instead of 10 though?
On Tue, 5 Jan 2021 at 22:51, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/5/21 11:32 AM, Jamie Burchell wrote:
is the change a non-issue for my use-case?
Probably. For a lot of users, Stream is a drop-in replacement that's better than CentOS was, because it gets updates consistently and doesn't suffer from periods in which no updates are available, including security updates.
If security was a priority for you, as it was for me, then CentOS wasn't really suitable for public-facing services, but CentOS Stream might be.
If you're building software that you intend to deploy on RHEL, Stream might not be a suitable build root for you. Compiling software in a Stream build root may result in a binary that has dependencies which aren't yet available in RHEL. And if you're building kernel modules (like Phil @elrepo), then there is the issue that the kernel isn't subject to RHEL's ABI policy, but Red Hat developers have expressed interest in making the kernel interfaces more stable and using external kernel module builds as a test to flag interfaces that have changed. So that situation may improve...
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Tue, Jan 5, 2021, 5:03 PM Jamie Burchell mail@jamieburchell.com wrote:
Probably. For a lot of users, Stream is a drop-in replacement that's
better than CentOS was
We will need to (manually) migrate to Stream 9.x after 5 years instead of 10 though?
Well that's the part that hasn't fully been laid out, stream to me just becomes like another disto lts release, at least with Debian flavors I feel confident in the upgrade path but the 10 year cycle is what makes RHEL nice. Stream is not an option for me, I will move to Springdale or Rocky if it matures. For what I need Springdale has been around long enough that I know they will continue and it also looks like Fermilab may be doing something also maybe they will get behind one of the new entries.
Off topic for sure, but it's a shame this has to be a manual process of destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
On Tue, 5 Jan 2021 at 23:20, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/5/21 3:02 PM, Jamie Burchell wrote:
We will need to (manually) migrate to Stream 9.x after 5 years instead of 10 though?
Yes. CentOS Stream has a lifecycle comparable with other LTS distributions.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Tue, Jan 05, 2021 at 11:31:34PM +0000, Jamie Burchell wrote:
Off topic for sure, but it's a shame this has to be a manual process of destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
I'm not sure how it will go. Fedora now has a very good upgrade tool that has worked for me through a few versions. So, hopefully, RH, and CentOS will have one too, who knows, maybe in time to migrate to Stream-9.
Am 06.01.21 um 03:01 schrieb Scott Robbins:
On Tue, Jan 05, 2021 at 11:31:34PM +0000, Jamie Burchell wrote:
Off topic for sure, but it's a shame this has to be a manual process of destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
I'm not sure how it will go. Fedora now has a very good upgrade tool that has worked for me through a few versions. So, hopefully, RH, and CentOS will have one too, who knows, maybe in time to migrate to Stream-9.
Fedora's package set is quite "stable". You can expect that a package is in the next release. This is not so valid for EL. Deprecated packages (ImageMagick in EL7 but not in EL8) make such upgrade path difficult ...
-- Leon
Am 06.01.21 um 03:01 schrieb Scott Robbins:
On Tue, Jan 05, 2021 at 11:31:34PM +0000, Jamie Burchell wrote:
Off topic for sure, but it's a shame this has to be a manual process of destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
I'm not sure how it will go. Fedora now has a very good upgrade tool that has worked for me through a few versions. So, hopefully, RH, and CentOS will have one too, who knows, maybe in time to migrate to Stream-9.
Fedora's package set is quite "stable". You can expect that a package is in the next release. This is not so valid for EL. Deprecated packages (ImageMagick in EL7 but not in EL8) make such upgrade path difficult ...
It's anyway hard to understand how an enterprise grade Linux can be shipped without things like ImageMagick or Tomcat. For quite some time now it gives me the impression that we're not the targeted audience anymore.
That's really sad because the competitors still include such important software as first class citizens. Maybe our requirements are just too old school?
Simon
On Wed, 6 Jan 2021 at 07:50, Simon Matter simon.matter@invoca.ch wrote:
Am 06.01.21 um 03:01 schrieb Scott Robbins:
On Tue, Jan 05, 2021 at 11:31:34PM +0000, Jamie Burchell wrote:
Off topic for sure, but it's a shame this has to be a manual process of destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
I'm not sure how it will go. Fedora now has a very good upgrade tool that has worked for me through a few versions. So, hopefully, RH, and CentOS will have one too, who knows, maybe in time to migrate to Stream-9.
Fedora's package set is quite "stable". You can expect that a package is in the next release. This is not so valid for EL. Deprecated packages (ImageMagick in EL7 but not in EL8) make such upgrade path difficult ...
It's anyway hard to understand how an enterprise grade Linux can be shipped without things like ImageMagick or Tomcat. For quite some time now it gives me the impression that we're not the targeted audience anymore.
The issue is that 'Enterprise' is an overloaded term without the nuance it needs. In the 'small' enterprise you have a lot of use of ImageMagick and TomCat. In the large enterprise of 100,000+ servers.. it isn't. As more of the large enterprises moved into RHEL, the amount of usage for a lot of 'leaf' programs became rounding errors without enough usage to justify the bug-fixing needed when compared to the load of bugfixing/enhancements/etc in the 100k customers.
That's really sad because the competitors still include such important software as first class citizens. Maybe our requirements are just too old school?
An additional problem is a generational one. We have a lot of programs which do various things 'well' enough written 10-30 years ago, and we of a certain age use them for the hammers to every nail problem. However, the problems fleets of 100k systems have are more welding versus hammering. So we are in a situation where we do need to retrain some of our hammers to be rivet guns. There is also a similar industry problem that anything older than 2 years ago is not sexy anymore because VC and investors aren't going to dump money into it. [You see a similar issue in the various 'popular mechanics' press that all homes in the next generation will only be built with metal and hammers and wood are a thing of the past. What you see instead is a wave of it and then a realization that you end up needing to do a little of each.]
Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Wed, 6 Jan 2021 at 07:50, Simon Matter simon.matter@invoca.ch wrote:
Am 06.01.21 um 03:01 schrieb Scott Robbins:
On Tue, Jan 05, 2021 at 11:31:34PM +0000, Jamie Burchell wrote:
Off topic for sure, but it's a shame this has to be a manual process
of
destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
I'm not sure how it will go. Fedora now has a very good upgrade tool that has worked for me through a few versions. So, hopefully, RH, and
CentOS
will have one too, who knows, maybe in time to migrate to Stream-9.
Fedora's package set is quite "stable". You can expect that a package
is
in the next release. This is not so valid for EL. Deprecated packages (ImageMagick in EL7 but not in EL8) make such upgrade path difficult
...
It's anyway hard to understand how an enterprise grade Linux can be shipped without things like ImageMagick or Tomcat. For quite some time now it gives me the impression that we're not the targeted audience anymore.
The issue is that 'Enterprise' is an overloaded term without the nuance it needs. In the 'small' enterprise you have a lot of use of ImageMagick and TomCat. In the large enterprise of 100,000+ servers.. it isn't. As more of the large enterprises moved into RHEL, the amount of usage for a lot of 'leaf' programs became rounding errors without enough usage to justify the bug-fixing needed when compared to the load of bugfixing/enhancements/etc in the 100k customers.
Thanks for confirming that RHEL is the wrong OS for SME businesses these days. It's not really good for SME servers and not really good for SME clients. Something between Fedora and RHEL could be it but it doesn't exist.
BTW, servers? Who needs servers in the days of clouds and serverless computing :-)
Simon
That's really sad because the competitors still include such important software as first class citizens. Maybe our requirements are just too old school?
An additional problem is a generational one. We have a lot of programs which do various things 'well' enough written 10-30 years ago, and we of a certain age use them for the hammers to every nail problem. However, the problems fleets of 100k systems have are more welding versus hammering. So we are in a situation where we do need to retrain some of our hammers to be rivet guns. There is also a similar industry problem that anything older than 2 years ago is not sexy anymore because VC and investors aren't going to dump money into it. [You see a similar issue in the various 'popular mechanics' press that all homes in the next generation will only be built with metal and hammers and wood are a thing of the past. What you see instead is a wave of it and then a realization that you end up needing to do a little of each.]
Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-- Stephen J Smoogen. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Wed, 6 Jan 2021 at 11:17, Simon Matter simon.matter@invoca.ch wrote:
On Wed, 6 Jan 2021 at 07:50, Simon Matter simon.matter@invoca.ch
wrote:
Am 06.01.21 um 03:01 schrieb Scott Robbins:
On Tue, Jan 05, 2021 at 11:31:34PM +0000, Jamie Burchell wrote:
Off topic for sure, but it's a shame this has to be a manual process
of
destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
I'm not sure how it will go. Fedora now has a very good upgrade tool that has worked for me through a few versions. So, hopefully, RH, and
CentOS
will have one too, who knows, maybe in time to migrate to Stream-9.
Fedora's package set is quite "stable". You can expect that a package
is
in the next release. This is not so valid for EL. Deprecated packages (ImageMagick in EL7 but not in EL8) make such upgrade path difficult
...
It's anyway hard to understand how an enterprise grade Linux can be shipped without things like ImageMagick or Tomcat. For quite some time now it gives me the impression that we're not the targeted audience anymore.
The issue is that 'Enterprise' is an overloaded term without the nuance
it
needs. In the 'small' enterprise you have a lot of use of ImageMagick and TomCat. In the large enterprise of 100,000+ servers.. it isn't. As more
of
the large enterprises moved into RHEL, the amount of usage for a lot of 'leaf' programs became rounding errors without enough usage to justify
the
bug-fixing needed when compared to the load of bugfixing/enhancements/etc in the 100k customers.
Thanks for confirming that RHEL is the wrong OS for SME businesses these days. It's not really good for SME servers and not really good for SME clients. Something between Fedora and RHEL could be it but it doesn't exist.
I didn't say or mean that. My answer is that it is complicated and more meant that the software you expect requires more than the industry in general is willing to pay to keep going. 10-20 years ago they were and so the software was able to be 'mainstream'. As less people use it, and less people are willing to pay for its maintenance the harder it is to keep 'running safely'. Tomcat and Imagemagick have had a LOT of severe security problems over the years and the general way the software is written makes anyone who does work on them say it will have it for years in the future. As less of the industry uses that software, the cost to keep the software running is going to cost more.
So please don't take my statement to confirm your preconceived notion.
BTW, servers? Who needs servers in the days of clouds and serverless computing :-)
Simon
That's really sad because the competitors still include such important software as first class citizens. Maybe our requirements are just too old school?
An additional problem is a generational one. We have a lot of programs which do various things 'well' enough written 10-30 years ago, and we of
a
certain age use them for the hammers to every nail problem. However, the problems fleets of 100k systems have are more welding versus hammering.
So
we are in a situation where we do need to retrain some of our hammers to be rivet guns. There is also a similar industry problem that anything older than 2 years ago is not sexy anymore because VC and investors aren't
going
to dump money into it. [You see a similar issue in the various 'popular mechanics' press that all homes in the next generation will only be built with metal and hammers and wood are a thing of the past. What you see instead is a wave of it and then a realization that you end up needing to do a little of each.]
Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-- Stephen J Smoogen. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Wed, 6 Jan 2021 at 11:17, Simon Matter simon.matter@invoca.ch wrote:
On Wed, 6 Jan 2021 at 07:50, Simon Matter simon.matter@invoca.ch
wrote:
Am 06.01.21 um 03:01 schrieb Scott Robbins:
On Tue, Jan 05, 2021 at 11:31:34PM +0000, Jamie Burchell wrote: > Off topic for sure, but it's a shame this has to be a manual
process
of
> destroying and rebuilding every X years. Even Microsoft has gone
the
> Apple > way and just perpetually updates Windows 10 now.
I'm not sure how it will go. Fedora now has a very good upgrade
tool
that has worked for me through a few versions. So, hopefully, RH, and
CentOS
will have one too, who knows, maybe in time to migrate to
Stream-9.
Fedora's package set is quite "stable". You can expect that a
package
is
in the next release. This is not so valid for EL. Deprecated
packages
(ImageMagick in EL7 but not in EL8) make such upgrade path
difficult
...
It's anyway hard to understand how an enterprise grade Linux can be shipped without things like ImageMagick or Tomcat. For quite some
time
now it gives me the impression that we're not the targeted audience
anymore.
The issue is that 'Enterprise' is an overloaded term without the
nuance it
needs. In the 'small' enterprise you have a lot of use of ImageMagick
and
TomCat. In the large enterprise of 100,000+ servers.. it isn't. As
more of
the large enterprises moved into RHEL, the amount of usage for a lot
of
'leaf' programs became rounding errors without enough usage to justify
the
bug-fixing needed when compared to the load of
bugfixing/enhancements/etc
in the 100k customers.
Thanks for confirming that RHEL is the wrong OS for SME businesses these days. It's not really good for SME servers and not really good for SME clients. Something between Fedora and RHEL could be it but it doesn't exist.
I didn't say or mean that. My answer is that it is complicated and more meant that the software you expect requires more than the industry in general is willing to pay to keep going. 10-20 years ago they were and so the software was able to be 'mainstream'. As less people use it, and less people are willing to pay for its maintenance the harder it is to keep 'running safely'. Tomcat and Imagemagick have had a LOT of severe security
I'd like to correct myself, ImageMagick was not simply removed but replaced by GraphicsMagick. From what I read it should be a usable solution as it's a fork from IM.
For the Tomcat thing, I don't agree. Tomcat is widely used and I think the security concerns are not the real reason to remove it. It more likely that RedHat simply likes to sell more JBoss EAP. It's their right to do so but it's a removal of important functionality of the base RHEL package.
Regards, Simon
On Wed, 6 Jan 2021 at 12:42, Simon Matter simon.matter@invoca.ch wrote:
On Wed, 6 Jan 2021 at 11:17, Simon Matter simon.matter@invoca.ch
wrote:
On Wed, 6 Jan 2021 at 07:50, Simon Matter simon.matter@invoca.ch
wrote:
I didn't say or mean that. My answer is that it is complicated and more meant that the software you expect requires more than the industry in general is willing to pay to keep going. 10-20 years ago they were and so the software was able to be 'mainstream'. As less people use it, and less people are willing to pay for its maintenance the harder it is to keep 'running safely'. Tomcat and Imagemagick have had a LOT of severe
security
I'd like to correct myself, ImageMagick was not simply removed but replaced by GraphicsMagick. From what I read it should be a usable solution as it's a fork from IM.
For the Tomcat thing, I don't agree. Tomcat is widely used and I think the security concerns are not the real reason to remove it. It more likely that RedHat simply likes to sell more JBoss EAP. It's their right to do so but it's a removal of important functionality of the base RHEL package.
I honestly have no idea how much Tomcat is used anymore. The various places that I worked previously or have contacts with have killed it off by moving whatever used it to external cloud services versus JBOSS or anything else. That is just an anecdata but it is all I have on the subject.
Regards, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Wed, Jan 6, 2021 at 7:43 PM Stephen John Smoogen smooge@gmail.com wrote:
I honestly have no idea how much Tomcat is used anymore. The various places that I worked previously or have contacts with have killed it off by moving whatever used it to external cloud services versus JBOSS or anything else. That is just an anecdata but it is all I have on the subject.
Red Hat still has one of its offering based on Apache and Tomcat, named JBoss Web Server: https://www.redhat.com/en/technologies/jboss-middleware/web-server
and the latest update available (5.4, based on upstream Tomcat 9) in November 2020, had the bits for RH EL 6, 7 and 8. See also docs entry page here: https://access.redhat.com/documentation/en-us/red_hat_jboss_web_server/5.4/
So it is non considered a dead technology, even for business use cases....
Gianluca
On Wed, 6 Jan 2021 at 13:48, Gianluca Cecchi gianluca.cecchi@gmail.com wrote:
On Wed, Jan 6, 2021 at 7:43 PM Stephen John Smoogen smooge@gmail.com wrote:
I honestly have no idea how much Tomcat is used anymore. The various
places
that I worked previously or have contacts with have killed it off by
moving
whatever used it to external cloud services versus JBOSS or anything
else.
That is just an anecdata but it is all I have on the subject.
Red Hat still has one of its offering based on Apache and Tomcat, named JBoss Web Server: https://www.redhat.com/en/technologies/jboss-middleware/web-server
and the latest update available (5.4, based on upstream Tomcat 9) in November 2020, had the bits for RH EL 6, 7 and 8. See also docs entry page here: https://access.redhat.com/documentation/en-us/red_hat_jboss_web_server/5.4/
So it is non considered a dead technology, even for business use cases....
OK it looks like whatever I say is going to be taken to extremes so this will be my last email on this.
I am not saying Tomcat is a dead technology. It is a technology which has certain use cases and deployments which the people I knew who used it are replacing with a different technology/service.
EOF
Gianluca _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Wed, Jan 6, 2021 at 7:59 PM Stephen John Smoogen smooge@gmail.com wrote:
OK it looks like whatever I say is going to be taken to extremes so this will be my last email on this.
I am not saying Tomcat is a dead technology. It is a technology which has certain use cases and deployments which the people I knew who used it are replacing with a different technology/service.
EOF
My considerations were only to balance the phrase "The various places that I worked previously or have contacts with have killed it off" and to enforce that Tomcat could still have its place nowadays; no intention to contrast you personally. Sorry if they gave this impression. And in fact you correctly wrote down "I honestly have no idea how much Tomcat is used anymore." and "That is just an anecdata".
Gianluca
On Tue, Jan 5, 2021 at 6:32 PM Jamie Burchell mail@jamieburchell.com wrote:
Off topic for sure, but it's a shame this has to be a manual process of destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
Do you use tools like ansible/chef? If you can put the time in, you can make your webservers rather distro agnostic. I would even put terraform on the table. It is not like your customers will know the difference.
On Tue, 5 Jan 2021 at 23:20, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/5/21 3:02 PM, Jamie Burchell wrote:
We will need to (manually) migrate to Stream 9.x after 5 years instead of 10 though?
Yes. CentOS Stream has a lifecycle comparable with other LTS distributions.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
We use Ansible "to a point" in that it sets up what we consider to be our preferred server (Droplet) for a specific purpose, then we deploy projects on them and tweak non-Ansible managed project configs. It's not old-school scripts and it's not quite a one-liner to deploy everything. It's somewhere in the middle. So in reality, providing we have control over a customer's DNS or we use floating IPs, migrating to another major release isn't as time consuming as doing everything from scratch.
On 6 Jan 2021, at 13:17, Mauricio Tavares raubvogel@gmail.com wrote:
On Tue, Jan 5, 2021 at 6:32 PM Jamie Burchell mail@jamieburchell.com wrote:
Off topic for sure, but it's a shame this has to be a manual process of destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
Do you use tools like ansible/chef? If you can put the time in,you can make your webservers rather distro agnostic. I would even put terraform on the table. It is not like your customers will know the difference.
On Tue, 5 Jan 2021 at 23:20, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/5/21 3:02 PM, Jamie Burchell wrote:
We will need to (manually) migrate to Stream 9.x after 5 years instead of 10 though?
Yes. CentOS Stream has a lifecycle comparable with other LTS distributions.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Wed, Jan 6, 2021 at 8:30 AM Jamie Burchell mail@jamieburchell.com wrote:
We use Ansible "to a point" in that it sets up what we consider to be our preferred server (Droplet) for a specific purpose, then we deploy projects on them and tweak non-Ansible managed project configs. It's not old-school scripts and it's not quite a one-liner to deploy everything. It's somewhere in the middle. So in reality, providing we have control over a customer's DNS or we use floating IPs, migrating to another major release isn't as time consuming as doing everything from scratch.
Good to hear. I myself have been using ansible to deploy basic systems -- DNS, mail, my hardware test environment -- so I can then do the clever -- decide how I want to run my experiments for instance -- stuff. Without going over my opinions -- I am very opinionated -- about the centos thingie, I think you having your playbooks will allow you to wait and see how this unfolds. If it goes horribly wrong you can still switch.
With that said, I think your real concern is you can't afford centos stream going boink on you. Your customers may not be as understanding as Darth Vader if that happens.
Here is my opinion: Redhat said you have normal centos 8 until the end of the year. I would stick to it until, say, October, while keeping an eye on how centos stream unfolds. Maybe even running a test centos stream to replicate production (or have it in production where it is ok if it goes boink). If by then your confidence on stream is high, switch to it (*should* be easy). If not, plan to move your customers. In the meantime, slowly ensure your ansible playbooks can handle the other usual suspects (at least debian and one of the other RH-derived distros). And plan the order you will move your customers if you have to.
On 6 Jan 2021, at 13:17, Mauricio Tavares raubvogel@gmail.com wrote:
On Tue, Jan 5, 2021 at 6:32 PM Jamie Burchell mail@jamieburchell.com wrote:
Off topic for sure, but it's a shame this has to be a manual process of destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
Do you use tools like ansible/chef? If you can put the time in,you can make your webservers rather distro agnostic. I would even put terraform on the table. It is not like your customers will know the difference.
On Tue, 5 Jan 2021 at 23:20, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/5/21 3:02 PM, Jamie Burchell wrote:
We will need to (manually) migrate to Stream 9.x after 5 years instead of 10 though?
Yes. CentOS Stream has a lifecycle comparable with other LTS distributions.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I'll be the first to admit I don't like change and arguably I'm in the wrong industry for that, but that's another matter. However I don't want to throw away years of experience with CentOS/Fedora and time invested (mine personally and my company's) learning and perfecting setups of which I have now around 50. A fair few of my Ansible setup are EL only, both from Galaxy and custom. I'm used to the layout, the packages, and what you'd expect after ~10 years of working with it.
At the moment my question possibly would have been better phrased "Why isn't Streama suitable platform for a production web server".
I get that everyone including myself is frustrated by the situation and so I'm trying to filter out the doomsayers and those who want to annoy RH by saying they are jumping to another distro like Debian. To me, I'm thinking at least for my situation and has already been said, Stream might actually be a positive but I shall wait and see what happens. And as for the 5 years LTS, that will be the same for every distro anyway.
Cheers Jamie
On 6 Jan 2021, at 17:56, Mauricio Tavares raubvogel@gmail.com wrote:
On Wed, Jan 6, 2021 at 8:30 AM Jamie Burchell mail@jamieburchell.com wrote:
We use Ansible "to a point" in that it sets up what we consider to be our preferred server (Droplet) for a specific purpose, then we deploy projects on them and tweak non-Ansible managed project configs. It's not old-school scripts and it's not quite a one-liner to deploy everything. It's somewhere in the middle. So in reality, providing we have control over a customer's DNS or we use floating IPs, migrating to another major release isn't as time consuming as doing everything from scratch.
Good to hear. I myself have been using ansible to deploy basicsystems -- DNS, mail, my hardware test environment -- so I can then do the clever -- decide how I want to run my experiments for instance -- stuff. Without going over my opinions -- I am very opinionated -- about the centos thingie, I think you having your playbooks will allow you to wait and see how this unfolds. If it goes horribly wrong you can still switch.
With that said, I think your real concern is you can't afford centos stream going boink on you. Your customers may not be as understanding as Darth Vader if that happens.
Here is my opinion: Redhat said you have normal centos 8 until the end of the year. I would stick to it until, say, October, while keeping an eye on how centos stream unfolds. Maybe even running a test centos stream to replicate production (or have it in production where it is ok if it goes boink). If by then your confidence on stream is high, switch to it (*should* be easy). If not, plan to move your customers. In the meantime, slowly ensure your ansible playbooks can handle the other usual suspects (at least debian and one of the other RH-derived distros). And plan the order you will move your customers if you have to.
On 6 Jan 2021, at 13:17, Mauricio Tavares raubvogel@gmail.com wrote:
On Tue, Jan 5, 2021 at 6:32 PM Jamie Burchell mail@jamieburchell.com wrote:
Off topic for sure, but it's a shame this has to be a manual process of destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
Do you use tools like ansible/chef? If you can put the time in,you can make your webservers rather distro agnostic. I would even put terraform on the table. It is not like your customers will know the difference.
On Tue, 5 Jan 2021 at 23:20, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/5/21 3:02 PM, Jamie Burchell wrote:
We will need to (manually) migrate to Stream 9.x after 5 years instead of 10 though?
Yes. CentOS Stream has a lifecycle comparable with other LTS distributions.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Wed, Jan 6, 2021, 2:44 PM Jamie Burchell mail@jamieburchell.com wrote:
I'll be the first to admit I don't like change and arguably I'm in the wrong industry for that, but that's another matter. However I don't want to throw away years of experience with CentOS/Fedora and time invested (mine personally and my company's) learning and perfecting setups of which I have now around 50. A fair few of my Ansible setup are EL only, both from Galaxy and custom. I'm used to the layout, the packages, and what you'd expect after ~10 years of working with it.
At the moment my question possibly would have been better phrased "Why isn't Streama suitable platform for a production web server".
I get that everyone including myself is frustrated by the situation and so I'm trying to filter out the doomsayers and those who want to annoy RH by saying they are jumping to another distro like Debian. To me, I'm thinking at least for my situation and has already been said, Stream might actually be a positive but I shall wait and see what happens. And as for the 5 years LTS, that will be the same for every distro anyway.
Cheers Jamie
Or you could move today to Springdale linux or Oracle or one of the new RHEL clones that will still be based on RHEL and have the same 10 year release cycle. Springdale and Oracle are options today and there are a couple more that are supposedly going to come online 1st or 2nd quarter, there are options.
At the moment my question possibly would have been better phrased "Why >isn't Streama suitable platform for a production web server".
It is , but expect rough edges. The differences will be : - Shorter lifetime .If you skip the first 2 minor releases -it will be shorter - No chance to "yum history undo last" as there are no older packages . You have to use Boom boot manager to rollback OS updates - More testing is needed as the chance that someone broke something is bigger
Best Regards, Strahil Nikolov
On 1/6/21 8:01 PM, Strahil Nikolov via CentOS wrote:
- No chance to "yum history undo last" as there are no older packages
I've seen that mentioned as a change pretty frequently, but I don't think it is in any meaningful sense.
In CentOS Stream, package versions may be rebased periodically, and the public repos will no longer have older packages to install when using "undo" or "rollback".
In CentOS, package versions may be rebased at minor releases, and the public repos will no longer have older packages to install when using "undo" or "rollback".
It's true that you might be able to roll back a simple patch in CentOS in between minor releases, but those are the updates that everyone seems to regard as being the safest, and least likely to cause problems, and therefore the least likely to need undo/rollback. The only rational conclusion I can come to is that it doesn't matter if you're talking about CentOS today or Stream in the future: If you want to be able to roll back, you need a private mirror that keeps the package versions that you use. If you don't want a mirror, then you need to build, test, and deploy complete images rather than making incremental changes to mutable systems. None of this is new, it's always been this way and people have just accepted it.
Didn't the CentOS Vault repo ensure that every package ever published was still available?
On 7 Jan 2021, at 07:03, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/6/21 8:01 PM, Strahil Nikolov via CentOS wrote:
- No chance to "yum history undo last" as there are no older packages
I've seen that mentioned as a change pretty frequently, but I don't think it is in any meaningful sense.
In CentOS Stream, package versions may be rebased periodically, and the public repos will no longer have older packages to install when using "undo" or "rollback".
In CentOS, package versions may be rebased at minor releases, and the public repos will no longer have older packages to install when using "undo" or "rollback".
It's true that you might be able to roll back a simple patch in CentOS in between minor releases, but those are the updates that everyone seems to regard as being the safest, and least likely to cause problems, and therefore the least likely to need undo/rollback. The only rational conclusion I can come to is that it doesn't matter if you're talking about CentOS today or Stream in the future: If you want to be able to roll back, you need a private mirror that keeps the package versions that you use. If you don't want a mirror, then you need to build, test, and deploy complete images rather than making incremental changes to mutable systems. None of this is new, it's always been this way and people have just accepted it.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Jan 7, 2021, at 3:47 AM, Jamie Burchell mail@jamieburchell.com wrote:
Didn't the CentOS Vault repo ensure that every package ever published was still available?
You should come to realizing that things changed. They are not what they were. With all fairness no one can say what will be true in a short future to come.
Valeri
On 7 Jan 2021, at 07:03, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/6/21 8:01 PM, Strahil Nikolov via CentOS wrote:
- No chance to "yum history undo last" as there are no older packages
I've seen that mentioned as a change pretty frequently, but I don't think it is in any meaningful sense.
In CentOS Stream, package versions may be rebased periodically, and the public repos will no longer have older packages to install when using "undo" or "rollback".
In CentOS, package versions may be rebased at minor releases, and the public repos will no longer have older packages to install when using "undo" or "rollback".
It's true that you might be able to roll back a simple patch in CentOS in between minor releases, but those are the updates that everyone seems to regard as being the safest, and least likely to cause problems, and therefore the least likely to need undo/rollback. The only rational conclusion I can come to is that it doesn't matter if you're talking about CentOS today or Stream in the future: If you want to be able to roll back, you need a private mirror that keeps the package versions that you use. If you don't want a mirror, then you need to build, test, and deploy complete images rather than making incremental changes to mutable systems. None of this is new, it's always been this way and people have just accepted it.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 07/01/2021 09:47, Jamie Burchell wrote:
Didn't the CentOS Vault repo ensure that every package ever published was still available?
Yes, it did, but that is not the intention for CentOS Stream moving forward. Only packages in CentOS Linux are moved to the vault at point release time. CentOS Stream only ever has the LATEST package version and nothing else.
There is a bug filed for this issue here:
https://bugzilla.redhat.com/show_bug.cgi?id=1908047
If it is likely to be an issue for you, please make that known. The more people this affects, the more likely it may be addressed.
On 7 Jan 2021, at 07:03, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/6/21 8:01 PM, Strahil Nikolov via CentOS wrote:
- No chance to "yum history undo last" as there are no older packages
I've seen that mentioned as a change pretty frequently, but I don't think it is in any meaningful sense.
In CentOS Stream, package versions may be rebased periodically, and the public repos will no longer have older packages to install when using "undo" or "rollback".
In CentOS, package versions may be rebased at minor releases, and the public repos will no longer have older packages to install when using "undo" or "rollback".
It's true that you might be able to roll back a simple patch in CentOS in between minor releases, but those are the updates that everyone seems to regard as being the safest, and least likely to cause problems, and therefore the least likely to need undo/rollback. The only rational conclusion I can come to is that it doesn't matter if you're talking about CentOS today or Stream in the future: If you want to be able to roll back, you need a private mirror that keeps the package versions that you use. If you don't want a mirror, then you need to build, test, and deploy complete images rather than making incremental changes to mutable systems. None of this is new, it's always been this way and people have just accepted it.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 1/7/21 9:53 AM, Phil Perry wrote:
On 07/01/2021 09:47, Jamie Burchell wrote:
Didn't the CentOS Vault repo ensure that every package ever published was still available?
Yes, it did, but that is not the intention for CentOS Stream moving forward. Only packages in CentOS Linux are moved to the vault at point release time. CentOS Stream only ever has the LATEST package version and nothing else.
There is a bug filed for this issue here:
https://bugzilla.redhat.com/show_bug.cgi?id=1908047
If it is likely to be an issue for you, please make that known. The more people this affects, the more likely it may be addressed.
This exists:
I think at some point there is a plan to make builds from koji also available, though we can't right nwo (only the production instance is available and we can't open it to alld/l because of bandwidth).
On 7 Jan 2021, at 07:03, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/6/21 8:01 PM, Strahil Nikolov via CentOS wrote:
- No chance to "yum history undo last" as there are no older packages
I've seen that mentioned as a change pretty frequently, but I don't think it is in any meaningful sense.
In CentOS Stream, package versions may be rebased periodically, and the public repos will no longer have older packages to install when using "undo" or "rollback".
In CentOS, package versions may be rebased at minor releases, and the public repos will no longer have older packages to install when using "undo" or "rollback".
It's true that you might be able to roll back a simple patch in CentOS in between minor releases, but those are the updates that everyone seems to regard as being the safest, and least likely to cause problems, and therefore the least likely to need undo/rollback. The only rational conclusion I can come to is that it doesn't matter if you're talking about CentOS today or Stream in the future: If you want to be able to roll back, you need a private mirror that keeps the package versions that you use. If you don't want a mirror, then you need to build, test, and deploy complete images rather than making incremental changes to mutable systems. None of this is new, it's always been this way and people have just accepted it.
On Tue, Jan 05, 2021 at 11:31:34PM +0000, Jamie Burchell wrote:
Off topic for sure, but it's a shame this has to be a manual process of destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.
Red Hat is working on this with a tool called "Leapp" for RHEL 7 to 8 upgrades. I have no idea if this or something similar is going to be available for the Stream 8 to 9 transition, but it'd definitely be useful and I think in everyone's interest (because Red Hat wants as many Stream users as possible on the latest release).
https://www.redhat.com/en/blog/upgrading-rhel-7-rhel-8-leapp-and-boom
On 1/5/21 5:19 PM, Gordon Messmer wrote:
On 1/5/21 3:02 PM, Jamie Burchell wrote:
We will need to (manually) migrate to Stream 9.x after 5 years instead of 10 though?
Yes. CentOS Stream has a lifecycle comparable with other LTS distributions.
And as someone mentioned, these other distributions have long great record of system upgrade from one release to another. CentOS has no record (and probably no upgrade engineered yet). In that respect CentOS Stream is way behind Debian (and clones) LTS. Not to mention other potentially problematic areas as no package version rollback, compatibility (potential) with EPEL, and other things I don't what to attempt to think about. As everything with newly architectured distribution which hasn't proven itself during long time suitable for specific things.
No disrespect intended. To the contrary: GREAT THANKS to hard working CentOS team for all your past work! And best wished to establish viability of absolutely new - and different - distribution: CentOS Stream.
And while people still ask and the list still tolerates, I will mention the system I fled my servers from Linux 6 or 7 years ago to:
FreeBSD
On average update requiring FreeBSD reboot happens as rarely as once 7-8 Months (Linux on average every 45 days: kernel or glibc security update --> reboot).
Good luck everybody who didn't arrive at final decision yet to find you way for the future.
Thanks again, CentOS team for the great system you gave us for decades up until now!
Valeri
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 1/5/21 3:39 PM, Valeri Galtsev wrote:
And as someone mentioned, these other distributions have long great record of system upgrade from one release to another. CentOS has no record (and probably no upgrade engineered yet). In that respect CentOS Stream is way behind...
In that respect, CentOS Stream is identical to CentOS.
Not to mention other potentially problematic areas as no package version rollback, compatibility (potential) with EPEL
CentOS Stream will be compatible with EPEL to the same extent that new point releases are compatible with EPEL.
The vast majority of interfaces in RHEL (and Stream) are guaranteed stable within a major release, and only a small number of interfaces that aren't. It's possible that one of the latter interfaces might change, in which case you'd expect yum to not update the dependency until EPEL's packages have been rebuilt:
https://access.redhat.com/articles/rhel-abi-compatibility#Appendix
On Jan 5, 2021, at 6:22 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/5/21 3:39 PM, Valeri Galtsev wrote:
And as someone mentioned, these other distributions have long great record of system upgrade from one release to another. CentOS has no record (and probably no upgrade engineered yet). In that respect CentOS Stream is way behind...
I do not like “creative editing” that changes what I said, this is the only reason I reply. Here is my original full phrase:
And as someone mentioned, these other distributions have long great record of system upgrade from one release to another. CentOS has no record (and probably no upgrade engineered yet). In that respect CentOS Stream is way behind Debian (and clones) LTS.
In that respect, CentOS Stream is identical to CentOS.
I was not comparing CentOS Stream with CentOS (former 10 year life cycle system), I was comparing CentOS Stream with Debian (and clones) LTS. And my comparison was about the fact that Debian (and clones) LTS have proven known to work through several releases easy way to in place upgrade from one release version to next one (for that matter FreeBSD is the same and too has since forever known trouble free way to in place upgrade to next major release version).
CentOS never had in place upgrade, and I for one would insist it will be improper to expect that. CentOS Stream, that didn’t go through even a single in place major release upgrade, can not sport having that, and only after two such upgrades happen trouble free for the whole community of CentOS Stream users, only then CentOS Stream will be on the same level with Debian and clones. This is regular simple truth of life: if you want, psychology is such that only after this NEW, DIFFERENT, system: CentOS Stream, goes through a couple of releases, with easy in place upgrades, only then the trust of common folk like humble sysadmin (meaning here myself), who does not consider oneself any sort of expert is operating systems, only then the trust will be of the same level as trust currently is to Debian (LTS or regular, and clones), or to FreeBSD, as far as easy in place upgrade to next release is concerned.
I know, CentOS team are great bright people, so knowing that and writing what I had to write above gives me extra pain. But that is the reality, and how users will value CentOS Stream couple of release cycles down the road when compared to Debian LTS, we will see. After long good record of trouble free upgrading (and other things that may rightfully or wrongfully trouble people now) there may be another factor, like huge collection of software Debian has in their repository, which may put some weight after all other comparison factors become equal. CentOS did beat all (excluding commercial MS Windows) by 10 year life cycle. Now that that is gone, CentOS (with Stream in name) stopped being unique, and people will mention huge choice of software collections in Debian and clones, comparably huge macports for MacOS (sorry about mentioning commercial system) and same huge FreeBSD port collection.
Not to mention other potentially problematic areas as no package version rollback, compatibility (potential) with EPEL
CentOS Stream will be compatible with EPEL to the same extent that new point releases are compatible with EPEL.
I understand that your hard work will insure it WILL be compatible, trouble free etc. But the same psychology factor is why I mentioned that. Trust will come only a couple of releases down the road.
We are sure CentOS team will keep doing great job on this absolutely different system CentOS Stream is, and if this new system couple of release down the road will be in similar demand as Debian (and clones) will be, - we will see. As I perceive it now, Debian (and clones), all other factors equal, will have much larger collection of packages that they have in their repositories as additional comparison factor.
And once again:
Huge thanks to brilliant hard working CentOS team for all you gave us during last couple of decades.
Valeri
- CentOS user for almost decade and a half, who moved servers (but only servers) to FreeBSD about 8 years ago.
The vast majority of interfaces in RHEL (and Stream) are guaranteed stable within a major release, and only a small number of interfaces that aren't. It's possible that one of the latter interfaces might change, in which case you'd expect yum to not update the dependency until EPEL's packages have been rebuilt:
https://access.redhat.com/articles/rhel-abi-compatibility#Appendix
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 1/5/21 6:30 PM, Valeri Galtsev wrote:
I was not comparing CentOS Stream with CentOS (former 10 year life cycle system), I was comparing CentOS Stream with Debian (and clones) LTS.
The original message came from a CentOS user who asked "is the change a non-issue for my use-case?"
So, I'd have to ask you how Debian is relevant to that question.
As I said, in terms of upgrade from one major version to another, CentOS Stream and CentOS are identical. If CentOS was suitable, then the change to CentOS Stream is a non-issue in the context of major version upgrades, because the change to CentOS Stream has no material impact on that concern.
The question being asked is not "what operating system should I use", to which discussion of Debian or FreeBSD might be relevant, it's "will the change to CentOS Stream impact my current processes?" Comparisons to Debian or FreeBSD are non-sequiturs in the context of this conversation.
On Jan 6, 2021, at 12:53 AM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/5/21 6:30 PM, Valeri Galtsev wrote:
I was not comparing CentOS Stream with CentOS (former 10 year life cycle system), I was comparing CentOS Stream with Debian (and clones) LTS.
The original message came from a CentOS user who asked "is the change a non-issue for my use-case?"
So, I'd have to ask you how Debian is relevant to that question.
As I said, in terms of upgrade from one major version to another, CentOS Stream and CentOS are identical.
Yes, my apologies, I did miss the word “Stream” in my phrase (no excuse even though I obviously spoke about NEW type of CentOS system).
If CentOS was suitable, then the change to CentOS Stream is a non-issue in the context of major version upgrades, because the change to CentOS Stream has no material impact on that concern.
Yes, indeed, if CentOS Stream is identical to CentOS as far as “in place upgrade” is concerned, which is not possible in case of both CentOS incarnations, then the comparison to other systems with comparable 5 year life cycle insists to be mentioned.
This only comes as I do care about CentOS at least recognizing benefits we had (I for one for about decade and a half). So, caring about CentOS, one imminently has to mention:
1. 5 year life cycle (of Stream): unique 10 year life cycle (not mentioning MS Windows which is commercial) is gone
2. same life cycle Debian and clones (LTS): have easy in place upgrade. Not Stream (as far as I know). If it will be, then only 2 releases down the road people will trust in place upgrade (pure psychology)
3. [continuing comparison with similar LTS alternatives]: Debian and clones have much larger package collections than CentOS + EPEL (and so do FreeBSD and clones: meaning their ports)
4. By the moment people will know CentOS Stream exists for decently long time, so can be trusted, quite some userbase will be lost. But looking at the comparisons above, there also is no obvious advantage over alternatives, who beat CentOS Stream in several respects.
This is not to annoy anyone, just to express sadness of the loss, and though for me it was like stating obvious, it still looks like not everyone considers it that obvious. If I didn’t care [what I run on my machines], then I wouldn’t care to write this. But as I do… there it is.
The question being asked is not "what operating system should I use", to which discussion of Debian or FreeBSD might be relevant, it's "will the change to CentOS Stream impact my current processes?" Comparisons to Debian or FreeBSD are non-sequiturs in the context of this conversation.
Well, in my book whenever one is trying to access future usability of something newly changed, it is always advantageous to step up above it, look at a wider picture and other possibilities. Not locking oneself into what one used (but changed forcing you to re-evaluate). I know, the existence of alternatives annoys, and it really hurts when they have advantages, especially once the advantage CentOS had (10 year life cycle) is gone…
And again, GREAT THANKS to brilliant CentOS team for great work you did for last couple of decades. With sadness of the loss (even if CentOS team does not perceive it as loss),
Valeri
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Le 06/01/2021 à 01:22, Gordon Messmer a écrit :
CentOS Stream will be compatible with EPEL to the same extent that new point releases are compatible with EPEL.
And in the past, things have been known to break. Activate the CR repository, and suddenly libmagick is broken because it hasn't been rebuilt yet against the new version.
This is the kind of thing you *hate* when you're a server admin. And this is exactly where CentOS Stream is heading.
On 1/5/21 10:47 PM, Nicolas Kovacs wrote:
And in the past, things have been known to break. Activate the CR repository, and suddenly libmagick is broken because it hasn't been rebuilt yet against the new version.
Are you describing an actual problem, right now, or is that an invented example? Can you provide the specifics of what yum does, or what the application does after updates?
Le 06/01/2021 à 08:06, Gordon Messmer a écrit :
Are you describing an actual problem, right now, or is that an invented example?
No, this was an actual problem I had back in April 2020. Upgrading from CR broke imagemagick, so I couldn't use the corresponding PHP modules, so my Roundcube installation was broken for a few weeks.
One of the things I like about Oracle Linux is that they maintain their own EPEL repo, most probably to prevent these things from happening.
On Wed, Jan 06, 2021 at 08:31:34AM +0100, Nicolas Kovacs wrote:
No, this was an actual problem I had back in April 2020. Upgrading from CR broke imagemagick, so I couldn't use the corresponding PHP modules, so my Roundcube installation was broken for a few weeks.
To be fair it was only broken because you kept it broken; you could have backed out the CR updates and waited for the point release to go GA and be on ABI parity with EPEL.
One of the things I like about Oracle Linux is that they maintain their own EPEL repo, most probably to prevent these things from happening.
I would be careful of expectations around that partial EPEL rebuild; it's not complete and some of the builds are quite dated.
John
Le 06/01/2021 à 08:48, John R. Dennison a écrit :
To be fair it was only broken because you kept it broken; you could have backed out the CR updates and waited for the point release to go GA and be on ABI parity with EPEL.
I used the CR updates because back then the official repositories were lagging far behind with security updates. But that's a different story.
Trying to roll back from this update resulted in a complete disaster.
On 1/5/21 11:31 PM, Nicolas Kovacs wrote:
No, this was an actual problem I had back in April 2020. Upgrading from CR broke imagemagick
At the time, you described that problem as:
I got an alert from Yum-Cron this morning: Failed to check for updates with the following error message: Failed to build transaction: sclo-php72-php-pecl-imagick-3.4.4-1.el7.x86_64 requires libMagickCore.so.5()(64bit)
I don't have enough information to say why imagemagick or php would be broken, as you said it was.
What I do see is that the sclo-php72-php-pecl-imagick has a dependency on libMagickCore.so.5()(64bit), which is recorded in the rpm package. If you have a package from a third party repository (either EPEL or SCLO, or others), and it depends on one of the few packages in CentOS Stream (or CentOS, or RHEL) that aren't guaranteed to be stable, and which Red Hat changes, then yum will warn you that the update would result in unresolvable dependencies, and it won't upgrade the package. Your system will keep the old imagemagick package and the old php-imagick package until the dependencies are resolved in the two repositories, and it'll update them after that.
Stream doesn't change that.
Le 06/01/2021 à 18:08, Gordon Messmer a écrit :
What I do see is that the sclo-php72-php-pecl-imagick has a dependency on libMagickCore.so.5()(64bit), which is recorded in the rpm package. If you have a package from a third party repository (either EPEL or SCLO, or others), and it depends on one of the few packages in CentOS Stream (or CentOS, or RHEL) that aren't guaranteed to be stable, and which Red Hat changes, then yum will warn you that the update would result in unresolvable dependencies, and it won't upgrade the package. Your system will keep the old imagemagick package and the old php-imagick package until the dependencies are resolved in the two repositories, and it'll update them after that.
Stream doesn't change that.
On the contrary. Stream will ensure that your systems are perpetual moving targets so that situations like the one described will keep your blood pressure high.
Broken packages explained away are still broken packages.
</rant>
On 1/6/21 9:20 AM, Nicolas Kovacs wrote:
Broken packages explained away are still broken packages.
I'm not sure how your system got in to a broken state, though. If you have a working system, and one repo updates a package to remove a dependency of a currently working package, those packages will normally continue working. rpm typically knows (as it did in the warning that you posted) when applying updates would break a system, and it won't apply them. Working systems will continue working, even in the rare case that one of the unsupported ABIs changes.
On Wed, Jan 6, 2021 at 1:22 AM Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/5/21 3:39 PM, Valeri Galtsev wrote:
And as someone mentioned, these other distributions have long great record of system upgrade from one release to another. CentOS has no record (and probably no upgrade engineered yet). In that respect CentOS Stream is way behind...
In that respect, CentOS Stream is identical to CentOS. [...]
No, definitely not. With CentOS you need to perform this exercise every ten years. With Stream every five years. This is a 100% effort/ costs difference which becomes a significant factor when you run more than a static web server.
Kind regards Thomas
Am 05.01.21 um 23:51 schrieb Gordon Messmer:
On 1/5/21 11:32 AM, Jamie Burchell wrote:
is the change a non-issue for my use-case?
Probably. For a lot of users, Stream is a drop-in replacement that's better than CentOS was, because it gets updates consistently and doesn't suffer from periods in which no updates are available, including security updates.
I often read this statement here that it "is better" because of not having "periods of missing updates" like in CentOS Linux.
Is it maybe more worsed? Some one said that security updates will be ASAP in Stream because the rolling process is build on top of such fixes. But what about leaf packages?
C8S: firefox-78.3.0-1.el8_2.x86_64.rpm C8: firefox-78.5.0-1.el8_3.x86_64.rpm RHEL8: firefox-78.6.0-1.el8_3.x86_64
The divergence exits because the C8->C8S migration process is not completed and we have still C8 as the base for the distrosync to C8S (and the compose process uses both repos).
The time after EOL of C8 will show that priorities will be on development - as it was stated. I would expect that Stream will diverged in two directions ...
If security was a priority for you, as it was for me, then CentOS wasn't really suitable for public-facing services, but CentOS Stream might be.
If you're building software that you intend to deploy on RHEL, Stream might not be a suitable build root for you. Compiling software in a Stream build root may result in a binary that has dependencies which aren't yet available in RHEL. And if you're building kernel modules (like Phil @elrepo), then there is the issue that the kernel isn't subject to RHEL's ABI policy, but Red Hat developers have expressed interest in making the kernel interfaces more stable and using external kernel module builds as a test to flag interfaces that have changed. So that situation may improve...
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
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.
On 05/01/2021 20:32, Jamie Burchell wrote:
Hello
I've recently discovered the announcement regarding the change in direction for the CentOS project and I imagine like many others, I'm confused and concerned about what this means moving forward.
<snip>
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).
<snip>
Well, let me just quickly chime in this thread ... If you have already automated things (or not btw) for CentOS 8, current Stream (8-stream) will continue to just work.
For CentOS Infra, I started to deploy Stream nodes and it continues to work fine.
Fun fact : new coming Stream buildsystem infra *is* build exclusively on top of CentOS Stream ... hopefully that would give people confidence about platform (dog fooding) :)
Will there be some changes suddenly happening faster than in usual major.minor releases lifecyles ? yes
Will it differ really ? well, it's what coming in the same major.minor version that people *are* waiting for ..
Is it perfect *now* ? probably not, but there is a chance to look at it and it's up to (and not tied to Stream vs Linux effect imho) sysadmin/devops engineers/$pick-your-title-here in charge of infra to have validation platform before rolling out versions/updates/etc ... (nothing *should* change here, except if one still manage single box like in the 90's) ;-)
With my SysAdmin hat on, I'd say that the only real impacting bit is the shorter lifetime (5y instead of 10), but with overlap between stream versions, so one would have time to have a look, reflect in automation, reinstall/migrate, enjoy
Just my 0.02$ here
Il 2021-01-08 10:01 Fabian Arrotin ha scritto:
With my SysAdmin hat on, I'd say that the only real impacting bit is the shorter lifetime (5y instead of 10), but with overlap between stream versions, so one would have time to have a look, reflect in automation, reinstall/migrate, enjoy
One key question, which seems to be somewhat unresolved, is if a clear in-place upgrading path from Stream-8 to Stream-9 will exist. Any news about it?
Thanks.
On 8/1/2021 11:01 π.μ., Fabian Arrotin wrote:
With my SysAdmin hat on, I'd say that the only real impacting bit is the shorter lifetime (5y instead of 10), but with overlap between stream versions, so one would have time to have a look, reflect in automation, reinstall/migrate, enjoy
With my sysadmin hat on, I'd say wait for a bit of time for Rocky Linux (or whatever will be finally called) or Lenix to mature and check adoption, and if not satisfied (which I consider unlikely) move to Oracle Linux.
Just forget all this cooking with Stream.
If you wear another hat, you can see things differently, but as a sysadmin, to me the above course of action is clear.
Cheers, Nick
Le 08/01/2021 à 10:01, Fabian Arrotin a écrit :
With my SysAdmin hat on, I'd say that the only real impacting bit is the shorter lifetime (5y instead of 10)
10 years of support instead of 5 has been the main argument here for using CentOS instead of Debian with the LTS repositories.
-
Fabian Arrotin -
Frank Cox -
Gianluca Cecchi -
Gionatan Danti -
Gordon Messmer -
Jamie Burchell -
John R. Dennison -
Johnny Hughes -
Jon Pruente -
Leon Fauster -
Matthew Miller -
Mauricio Tavares -
Nicolas Kovacs -
Nikolaos Milas -
Pete Biggs -
Phil Perry -
Ruslanas Gžibovskis -
Scott Robbins -
Scott Techlist -
Simon Matter -
Stephen John Smoogen -
Strahil Nikolov -
Thomas Bendler -
Tom Bishop -
Valeri Galtsev