Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
Kind Regards,
John
Sent from my iPad
On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
I have 3 systems which are capable of the AVX instruction set fortunately in my home lab. However unfortunately not other parts of the v3 base line.
Sent from my iPad
On 7 Jan 2024, at 15:44, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
-- 真実はいつも一つ！/ Always, there's only one truth!
Those 3 same systems will be affected by disabling the megaraid storage controller, as they are using Dell PERC H710p mini.
Sent from my iPad
On 7 Jan 2024, at 15:49, John Cooper johnpcooper@icloud.com wrote:
I have 3 systems which are capable of the AVX instruction set fortunately in my home lab. However unfortunately not other parts of the v3 base line.
Sent from my iPad
On 7 Jan 2024, at 15:44, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
-- 真実はいつも一つ！/ Always, there's only one truth!
I was directed to those hardware following recommendations in videos, and from professional hardware refurbishes as it was within my budget.
Sent from my iPad
On 7 Jan 2024, at 15:52, John Cooper johnpcooper@icloud.com wrote:
Those 3 same systems will be affected by disabling the megaraid storage controller, as they are using Dell PERC H710p mini.
Sent from my iPad
On 7 Jan 2024, at 15:49, John Cooper johnpcooper@icloud.com wrote:
I have 3 systems which are capable of the AVX instruction set fortunately in my home lab. However unfortunately not other parts of the v3 base line.
Sent from my iPad
On 7 Jan 2024, at 15:44, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
-- 真実はいつも一つ！/ Always, there's only one truth!
Specifically my hardware is only capable of the first generation AVX cpu instruction set. Not the FMA and the VEX instruction sets so I will be left behind as I will be unable to upgrade the new requirements.
Sent from my iPad
On 7 Jan 2024, at 15:54, John Cooper johnpcooper@icloud.com wrote:
I was directed to those hardware following recommendations in videos, and from professional hardware refurbishes as it was within my budget.
Sent from my iPad
On 7 Jan 2024, at 15:52, John Cooper johnpcooper@icloud.com wrote:
Those 3 same systems will be affected by disabling the megaraid storage controller, as they are using Dell PERC H710p mini.
Sent from my iPad
On 7 Jan 2024, at 15:49, John Cooper johnpcooper@icloud.com wrote:
I have 3 systems which are capable of the AVX instruction set fortunately in my home lab. However unfortunately not other parts of the v3 base line.
Sent from my iPad
On 7 Jan 2024, at 15:44, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
-- 真実はいつも一つ！/ Always, there's only one truth!
I may have come up with an answer to this quandary - dynamic baseline! It’s a technology based on a System having its CPU(s) instruction sets assessed at first boot, then re-assessed when necessary. There would be a minimum base with the maximum baseline being set in software at the time of major release, but can be updated during feature updates if desired. Following assessment the results would be used, to set the baseline for that system other instructions below that won’t be seen or used outside of assessment.
When assessment isn’t required the results file would be used to maintain the same assessed baseline, unless re-assessment is needed.
The results of the assessment would be stored in a file, along with a note of the current CPU(s) installed
Sent from my iPad
On 7 Jan 2024, at 16:35, John Cooper johnpcooper@icloud.com wrote:
Specifically my hardware is only capable of the first generation AVX cpu instruction set. Not the FMA and the VEX instruction sets so I will be left behind as I will be unable to upgrade the new requirements.
Sent from my iPad
On 7 Jan 2024, at 15:54, John Cooper johnpcooper@icloud.com wrote:
I was directed to those hardware following recommendations in videos, and from professional hardware refurbishes as it was within my budget.
Sent from my iPad
On 7 Jan 2024, at 15:52, John Cooper johnpcooper@icloud.com wrote:
Those 3 same systems will be affected by disabling the megaraid storage controller, as they are using Dell PERC H710p mini.
Sent from my iPad
On 7 Jan 2024, at 15:49, John Cooper johnpcooper@icloud.com wrote:
I have 3 systems which are capable of the AVX instruction set fortunately in my home lab. However unfortunately not other parts of the v3 base line.
Sent from my iPad
> On 7 Jan 2024, at 15:44, Neal Gompa ngompa13@gmail.com wrote: > > On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel > centos-devel@centos.org wrote: > > Dear Sir/Madam, > > You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers. > > The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing! > > Just something to consider during RHEL 10’s development. >
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
-- 真実はいつも一つ！/ Always, there's only one truth!
On 07/01/2024 15:51, John Cooper via CentOS-devel wrote:
Those 3 same systems will be affected by disabling the megaraid storage controller, as they are using Dell PERC H710p mini.
Sent from my iPad
That's not a big issue - elrepo.org have kmod packaged drivers to support the megaraid storage controller for RHEL at their repository and can release drives to support this hardware on RHEL 10 if Red Hat choose to end support. As you have identified, CPU support is the main issue here.
Personally, I'm in favour of a move to x86_64-v3, but I understand why others may not be.
--Phil
On 7 Jan 2024, at 15:49, John Cooper johnpcooper@icloud.com wrote:
I have 3 systems which are capable of the AVX instruction set fortunately in my home lab. However unfortunately not other parts of the v3 base line.
Sent from my iPad
On 7 Jan 2024, at 15:44, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
-- 真実はいつも一つ！/ Always, there's only one truth!
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Hi Phil,
I accept that you would be for the v3 base line, however the v3 base line would obliterate the 3 system home lab. I entered the home lab community in the last 2 years at most, the Dell PowerEdge R620 are my very first home lab servers. What’s more they were gifts.
Sent from my iPad
On 7 Jan 2024, at 19:46, Phil Perry pperry@elrepo.org wrote:
On 07/01/2024 15:51, John Cooper via CentOS-devel wrote:
Those 3 same systems will be affected by disabling the megaraid storage controller, as they are using Dell PERC H710p mini. Sent from my iPad
That's not a big issue - elrepo.org have kmod packaged drivers to support the megaraid storage controller for RHEL at their repository and can release drives to support this hardware on RHEL 10 if Red Hat choose to end support. As you have identified, CPU support is the main issue here.
Personally, I'm in favour of a move to x86_64-v3, but I understand why others may not be.
--Phil
On 7 Jan 2024, at 15:49, John Cooper johnpcooper@icloud.com wrote:
I have 3 systems which are capable of the AVX instruction set fortunately in my home lab. However unfortunately not other parts of the v3 base line.
Sent from my iPad
On 7 Jan 2024, at 15:44, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
-- 真実はいつも一つ！/ Always, there's only one truth!
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 07/01/2024 19:56, John Cooper via CentOS-devel wrote:
Hi Phil,
I accept that you would be for the v3 base line, however the v3 base line would obliterate the 3 system home lab. I entered the home lab community in the last 2 years at most, the Dell PowerEdge R620 are my very first home lab servers. What’s more they were gifts.
I'll also repeat here what was said on IRC. RHEL 9 is x86_64-v2 and also has the megaraid_sas driver that supports your controller. RHEL 9 works on an R620 withg an H710p RAID controller and is not going away until 2032 so you are safe to use your hardware on RHEL 9 until then. At that point a Dell R620 will be approximately 20 years old and if you haven't already replaced it with something newer then you probably should do. Your hardware will continue to function on RHEL 9 until then.
Trevor
On 07/01/2024 19:56, John Cooper via CentOS-devel wrote:
Hi Phil,
I accept that you would be for the v3 base line, however the v3 base line would obliterate the 3 system home lab. I entered the home lab community in the last 2 years at most, the Dell PowerEdge R620 are my very first home lab servers. What’s more they were gifts.
I'll also repeat here what was said on IRC. RHEL 9 is x86_64-v2 and also has the megaraid_sas driver that supports your controller. RHEL 9 works on an R620 withg an H710p RAID controller and is not going away until 2032 so you are safe to use your hardware on RHEL 9 until then. At that point a Dell R620 will be approximately 20 years old and if you haven't already replaced it with something newer then you probably should do. Your hardware will continue to function on RHEL 9 until then.
But, if he later wanted to run RHEL 10 on it in a VM, this would still not be possible, right?
IMHO the whole IT industry and community does quite a bad job here making systems obsolete on a large scale with no real technical requirement. Technically, it would be possible to implement complete operating systems and applications in a way which makes them dynamically select and use the offered capabilities of the underlying hardware. We really should never forget that.
Regards, Simon
On 2024-01-08 01:43, Simon Matter wrote:
IMHO the whole IT industry and community does quite a bad job here making systems obsolete on a large scale with no real technical requirement. Technically, it would be possible to implement complete operating systems and applications in a way which makes them dynamically select and use the offered capabilities of the underlying hardware. We really should never forget that.
I don't think anyone has forgotten that, or that they don't know how to support both. Red Hat's stated reasoning seems to be that they want to reduce the burden of testing multiple code paths when older systems continue to be supported:
https://developers.redhat.com/articles/2024/01/02/exploring-x86-64-v3-red-ha...
"if RHEL 10 requires the x86-64-v3 baseline, ISVs will be able to rely on it, too. This reduces maintenance cost for some ISVs because they no longer need to maintain (and test) AVX and non-AVX code paths in their manually tuned software."
"if RHEL 10 requires the x86-64-v3 baseline, ISVs will be able to rely on it, too. This reduces maintenance cost for some ISVs because they no longer need to maintain (and test) AVX and non-AVX code paths in their manually tuned software."
I'm not really convinced by this statement.
If an ISV is really investing the effort to manually tuning their software for AVX and non-AVX scenarios then this means to me that this specific software is something that is performance critical and profits siginficantly from having AVX. This makes it very likely that the vast majority of their customers also have an eye on performance and most probably have invested in new server hardware.
So it wouldn't be an issue for the ISV to say that they support RHEL10 and they additionally require a x86_64-v3 (or AVX) capable CPU for their software.
The only thing that requiring x86_64-v3 for RHEL 10 as baseline would make easier for this ISV is that the ISV doesn't have to put the text "requires a x86_64-v3 capable CPU" into their datasheet/manual. And maybe adding a small script to their installer that complains if x86_64-v3 is missing.
Kind regards,
Gerd
Speaking on behalf of a non-profit (OSU Open Source Lab) that uses a lot of older generation systems to support our infrastructure, I too am concerned about moving the v3 base line as a requirement for EL10. Our hardware budget is very limited so getting newer generation systems can take quite a bit of time or just luck (someone decides to donate gear).
If there's a way to make this work both ways, that would be great.
On Sun, Jan 7, 2024 at 11:56 AM John Cooper via CentOS-devel < centos-devel@centos.org> wrote:
Hi Phil,
I accept that you would be for the v3 base line, however the v3 base line would obliterate the 3 system home lab. I entered the home lab community in the last 2 years at most, the Dell PowerEdge R620 are my very first home lab servers. What’s more they were gifts.
I'm sure that keeping x86-64-v2 baseline support will be an interesting additional value provided by freeloading rebuilders.
Jean-Marc Liger
Le 08/01/2024 à 22:33, Lance Albertson a écrit :
Speaking on behalf of a non-profit (OSU Open Source Lab) that uses a lot of older generation systems to support our infrastructure, I too am concerned about moving the v3 base line as a requirement for EL10. Our hardware budget is very limited so getting newer generation systems can take quite a bit of time or just luck (someone decides to donate gear).
If there's a way to make this work both ways, that would be great.
On Sun, Jan 7, 2024 at 11:56 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Hi Phil, I accept that you would be for the v3 base line, however the v3 base line would obliterate the 3 system home lab. I entered the home lab community in the last 2 years at most, the Dell PowerEdge R620 are my very first home lab servers. What’s more they were gifts.-- Lance Albertson Director Oregon State University | Open Source Lab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 1/10/24 5:43 PM, Jean-Marc Liger wrote:
I'm sure that keeping x86-64-v2 baseline support will be an interesting additional value provided by freeloading rebuilders.
Can we hold ourselves to a higher standard than this, please?
If the proposed change go through and invalidates scores of non-compliant hardware, I think it would be interesting to see if any community SIGs or downstream distributions make an attempt at this. Whether its trying to support them via just not bumping up from x86_64-v2 or via a hwcaps packaging method, etc.
Le 10/01/2024 à 23:57, Mike Rochefort via CentOS-devel a écrit :
On 1/10/24 5:43 PM, Jean-Marc Liger wrote:
I'm sure that keeping x86-64-v2 baseline support will be an interesting additional value provided by freeloading rebuilders.
Can we hold ourselves to a higher standard than this, please?
The brutal truth is a higher standard, it helps saving time and money by focusing on what is essential, like what you bring in your additional comment below
If the proposed change go through and invalidates scores of non-compliant hardware, I think it would be interesting to see if any community SIGs or downstream distributions make an attempt at this. Whether its trying to support them via just not bumping up from x86_64-v2 or via a hwcaps packaging method, etc.
Anyway can elrepo supply also as early boot driver disk images please? As if it gets disabled then I won’t be able to install let alone boot.
Sent from my iPad
On 7 Jan 2024, at 19:46, Phil Perry pperry@elrepo.org wrote:
On 07/01/2024 15:51, John Cooper via CentOS-devel wrote:
Those 3 same systems will be affected by disabling the megaraid storage controller, as they are using Dell PERC H710p mini. Sent from my iPad
That's not a big issue - elrepo.org have kmod packaged drivers to support the megaraid storage controller for RHEL at their repository and can release drives to support this hardware on RHEL 10 if Red Hat choose to end support. As you have identified, CPU support is the main issue here.
Personally, I'm in favour of a move to x86_64-v3, but I understand why others may not be.
--Phil
On 7 Jan 2024, at 15:49, John Cooper johnpcooper@icloud.com wrote:
I have 3 systems which are capable of the AVX instruction set fortunately in my home lab. However unfortunately not other parts of the v3 base line.
Sent from my iPad
On 7 Jan 2024, at 15:44, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
-- 真実はいつも一つ！/ Always, there's only one truth!
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Yes, elrepo ships Driver Update Disk (DUD) iso images for use during installation:
https://elrepo.org/linux/dud/el8/x86_64/ https://elrepo.org/linux/dud/el9/x86_64/
--Phil
On 07/01/2024 19:58, John Cooper via CentOS-devel wrote:
Anyway can elrepo supply also as early boot driver disk images please? As if it gets disabled then I won’t be able to install let alone boot.
Sent from my iPad
On 7 Jan 2024, at 19:46, Phil Perry pperry@elrepo.org wrote:
On 07/01/2024 15:51, John Cooper via CentOS-devel wrote:
Those 3 same systems will be affected by disabling the megaraid storage controller, as they are using Dell PERC H710p mini. Sent from my iPad
That's not a big issue - elrepo.org have kmod packaged drivers to support the megaraid storage controller for RHEL at their repository and can release drives to support this hardware on RHEL 10 if Red Hat choose to end support. As you have identified, CPU support is the main issue here.
Personally, I'm in favour of a move to x86_64-v3, but I understand why others may not be.
--Phil
On 7 Jan 2024, at 15:49, John Cooper johnpcooper@icloud.com wrote:
I have 3 systems which are capable of the AVX instruction set fortunately in my home lab. However unfortunately not other parts of the v3 base line.
Sent from my iPad
On 7 Jan 2024, at 15:44, Neal Gompa ngompa13@gmail.com wrote:
On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
-- 真実はいつも一つ！/ Always, there's only one truth!
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
I pointed this out as well when the request for "feedback" for RHEL 10 was initially sent out (2023-03-09), but our (CERN's) concerns were dismissed. The decision to raise the baseline is forcing us to migrate away from RHEL for all the industrial control systems that manage the experiments and accelerators, and it may well precipitate further changes.
Cheers, Alex
On 1/7/24 16:44, Neal Gompa wrote:
On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
I do think the SuSE method of dealing with this is significantly better and I wish RH would adopt it rather than just deprecating otherwise working hardware:
https://www.theregister.com/2023/03/09/opensuse_finds_x86_64_solution/
Trevor
On 08/01/2024 10:53, Alex Iribarren wrote:
I pointed this out as well when the request for "feedback" for RHEL 10 was initially sent out (2023-03-09), but our (CERN's) concerns were dismissed. The decision to raise the baseline is forcing us to migrate away from RHEL for all the industrial control systems that manage the experiments and accelerators, and it may well precipitate further changes.
Cheers, Alex
On 1/7/24 16:44, Neal Gompa wrote:
On Sun, Jan 7, 2024 at 10:36 AM John Cooper via CentOS-devel centos-devel@centos.org wrote:
Dear Sir/Madam,
You’re currently exploring raising the instruction set base line, which will exclude some systems and also people (who are unable to afford to upgrade to reach the new baseline). I however want to draw your attention to the plans, to disable or remove megaraid based hardware from Dell. Doing so will cause issues and leave behind people in the home lab community behind. Also there’s also videos circulating from as recently as during 2022 recommending the Dell PowerEdge R620 rack servers.
The people in the home lab community are in essence a source of recommendations for people considering whether or not to acquire Red Hat’s services. So having them on side is a very good thing!
Just something to consider during RHEL 10’s development.
I will also point out with my contributor hat on, I would have some serious trouble with a raised baseline to x86_64-v3, as I only have one computer that is capable of it (barely). The rise to x86_64-v2 was painful enough, but -v3 would be quite a problem for me and result in throwing away even more hardware, which is not exactly a very environmentally friendly thing to do...
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 1/8/24 12:46, Trevor Hemsley via CentOS-devel wrote:
I do think the SuSE method of dealing with this is significantly better and I wish RH would adopt it rather than just deprecating otherwise working hardware:
https://www.theregister.com/2023/03/09/opensuse_finds_x86_64_solution/
FWIW Fedora is currently considering this as well: https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Arch...
As far as the idea (glibc-hwcaps) is concerned, both are pretty much the same.
I think https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-... is a good read. It's fresh and it might be appropriate to read it first before entering the deeper discussion.
If Fedora manages to maintain baselines, the downstream might follow (CentOS Stream, RHEL 10). I don't think it will be mainstream the other way around. Also if production started it might be hard to push such a huge change ¯_(ツ)_/¯.
Best, Alex
On 1/8/24 12:49, František Šumšal wrote:
On 1/8/24 12:46, Trevor Hemsley via CentOS-devel wrote:
I do think the SuSE method of dealing with this is significantly better and I wish RH would adopt it rather than just deprecating otherwise working hardware:
https://www.theregister.com/2023/03/09/opensuse_finds_x86_64_solution/
FWIW Fedora is currently considering this as well: https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Arch... _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
unless I misunderstand something (which is entirely possible), the Suse "solution" is only a partial solution... they will compile shared objects for each of the instruction set possibilities and load the one that is applicable on the current machine.
but doesn't that mean that all the base apps need to be compiled for the lowest common denominator? In the examples people (in this thread) are worrying about, that would be "v2".
Fred
On Mon, Jan 8, 2024 at 7:45 AM aleksander.baranowski via CentOS-devel < centos-devel@centos.org> wrote:
As far as the idea (glibc-hwcaps) is concerned, both are pretty much the same.
I think
https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-... is a good read. It's fresh and it might be appropriate to read it first before entering the deeper discussion.
If Fedora manages to maintain baselines, the downstream might follow (CentOS Stream, RHEL 10). I don't think it will be mainstream the other way around. Also if production started it might be hard to push such a huge change ¯_(ツ)_/¯.
Best, Alex
On 1/8/24 12:49, František Šumšal wrote:
On 1/8/24 12:46, Trevor Hemsley via CentOS-devel wrote:
I do think the SuSE method of dealing with this is significantly better and I wish RH would adopt it rather than just deprecating otherwise working hardware:
https://www.theregister.com/2023/03/09/opensuse_finds_x86_64_solution/
FWIW Fedora is currently considering this as well:
https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Arch...
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Mon, Jan 08, 2024 at 01:05:51PM -0500, Fred wrote:
unless I misunderstand something (which is entirely possible), the Suse "solution" is only a partial solution... they will compile shared objects for each of the instruction set possibilities and load the one that is applicable on the current machine.
but doesn't that mean that all the base apps need to be compiled for the lowest common denominator? In the examples people (in this thread) are worrying about, that would be "v2".
In case of Fedora, anyway, the idea is to compile multiple times for apps that would benefit from this - for the baseline and for any higher compilation targets.
Best,
Michel
Fred
On Mon, Jan 8, 2024 at 7:45 AM aleksander.baranowski via CentOS-devel < centos-devel@centos.org> wrote:
As far as the idea (glibc-hwcaps) is concerned, both are pretty much the same.
I think
https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-... is a good read. It's fresh and it might be appropriate to read it first before entering the deeper discussion.
If Fedora manages to maintain baselines, the downstream might follow (CentOS Stream, RHEL 10). I don't think it will be mainstream the other way around. Also if production started it might be hard to push such a huge change ¯_(ツ)_/¯.
Best, Alex
On 1/8/24 12:49, František Šumšal wrote:
On 1/8/24 12:46, Trevor Hemsley via CentOS-devel wrote:
I do think the SuSE method of dealing with this is significantly better and I wish RH would adopt it rather than just deprecating otherwise working hardware:
https://www.theregister.com/2023/03/09/opensuse_finds_x86_64_solution/
FWIW Fedora is currently considering this as well:
https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Arch...
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Hi,
I would also like to voice my concerns about requiring x86_64-v3 for RHEL 10.
In the blog post https://developers.redhat.com/articles/2024/01/02/exploring-x86-64-v3-red-ha... Florian writes:
"... and adopting x86-64-v3 will exclude some systems from being able to run RHEL 10, just as the choice of x86-64-v2 for RHEL 9 excluded some systems."
I would like to point out a major difference between what was done on RHEL 9 and what is now planned for 10: the last CPU core designs that did not include support for x86_64-v2 were Intel Cedar Trail and AMD Bobcat. While it is hard to find reliable discontinuation dates, it looks to me like they were both discontinued in 2014. So when RHEL 9 was released in 2022, the affected systems were already 8 years or older. So they were already aging systems.
With the plans for RHEL 10 this is a completely different matter: as Florian writes in the blogpost, Intel still released new CPU variants without support for x86-64-v3 in 2023 so it is very likely that new CPUs without x86-64-v3 will be still sold by the time RHEL 10 will be released. This is of course in addition to the systems sold in the last years without x86-64-v3 and that won't be able to upgrade.
I don't think it is a good idea to raise the minimum requirements so much that even systems sold as new don't meet them.
Also the impacts of such a decision on the environment should be considered. When you believe for example the figures in https://www.tomshardware.com/software/windows/microsofts-draconian-windows-1... then the hardware requirements decided on by Microsoft for Windows 11 alone will lead to hundred thousands of tons of additional electronic waste. I think Linux vendors should set a better example in this regard.
It is these two points that lead me to believe that the raising the baseline to x86-64-v3 should not be implemented in RHEL 10. Instead further research&development should go into hwcaps and should then be reviewed by the time RHEL 11 will be branched.
Kind regards,
Gerd
Additionally I don’t know how many of you can get or read the PC Pro publication. However in one of their issues last year they were providing options for what people can do when Windows 10 comes to the end of its support lifecycle.
One of the options was to switch to Linux they only mentioned Ubuntu Linux and Linux Mint. Though that doesn’t preclude people switching to RHEL on their ex-Windows 10 computers when that point is reached. Though there’s the options of RHEL 8 and RHEL 9 it would be advantageous in several respects including environmental ones, to take it into account for RHEL 10. It may even be a basis for a conversion campaign involving compatible systems that were once Windows 10, to promote conversion from Windows 10 to RHEL 10.
Just think of the irony of going from Windows 10 to RHEL 10 as your new operating system on the computer!
Sent from my iPad
On 8 Jan 2024, at 23:13, Gerd v. Egidy lists@egidy.de wrote:
Hi,
I would also like to voice my concerns about requiring x86_64-v3 for RHEL 10.
In the blog post https://developers.redhat.com/articles/2024/01/02/exploring-x86-64-v3-red-ha... Florian writes:
"... and adopting x86-64-v3 will exclude some systems from being able to run RHEL 10, just as the choice of x86-64-v2 for RHEL 9 excluded some systems."
I would like to point out a major difference between what was done on RHEL 9 and what is now planned for 10: the last CPU core designs that did not include support for x86_64-v2 were Intel Cedar Trail and AMD Bobcat. While it is hard to find reliable discontinuation dates, it looks to me like they were both discontinued in 2014. So when RHEL 9 was released in 2022, the affected systems were already 8 years or older. So they were already aging systems.
With the plans for RHEL 10 this is a completely different matter: as Florian writes in the blogpost, Intel still released new CPU variants without support for x86-64-v3 in 2023 so it is very likely that new CPUs without x86-64-v3 will be still sold by the time RHEL 10 will be released. This is of course in addition to the systems sold in the last years without x86-64-v3 and that won't be able to upgrade.
I don't think it is a good idea to raise the minimum requirements so much that even systems sold as new don't meet them.
Also the impacts of such a decision on the environment should be considered. When you believe for example the figures in https://www.tomshardware.com/software/windows/microsofts-draconian-windows-1... then the hardware requirements decided on by Microsoft for Windows 11 alone will lead to hundred thousands of tons of additional electronic waste. I think Linux vendors should set a better example in this regard.
It is these two points that lead me to believe that the raising the baseline to x86-64-v3 should not be implemented in RHEL 10. Instead further research&development should go into hwcaps and should then be reviewed by the time RHEL 11 will be branched.
Kind regards,
Gerd
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Am 09.01.24 um 00:52 schrieb John Cooper via CentOS-devel:
Additionally I don’t know how many of you can get or read the PC Pro publication. However in one of their issues last year they were providing options for what people can do when Windows 10 comes to the end of its support lifecycle.
One of the options was to switch to Linux they only mentioned Ubuntu Linux and Linux Mint. Though that doesn’t preclude people switching to RHEL on their ex-Windows 10 computers when that point is reached. Though there’s the options of RHEL 8 and RHEL 9 it would be advantageous in several respects including environmental ones, to take it into account for RHEL 10. It may even be a basis for a conversion campaign involving compatible systems that were once Windows 10, to promote conversion from Windows 10 to RHEL 10.
Just think of the irony of going from Windows 10 to RHEL 10 as your new operating system on the computer!
That would be funny but - it seems that RH's agenda does not have a focus on workstation scenarios anymore. Main productivity applications are already marked as deprecated. So, they will not be included in a future major release:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
Am 09.01.24 um 00:52 schrieb John Cooper via CentOS-devel:
Additionally I don’t know how many of you can get or read the PC Pro publication. However in one of their issues last year they were providing options for what people can do when Windows 10 comes to the end of its support lifecycle.
One of the options was to switch to Linux they only mentioned Ubuntu Linux and Linux Mint. Though that doesn’t preclude people switching to RHEL on their ex-Windows 10 computers when that point is reached. Though there’s the options of RHEL 8 and RHEL 9 it would be advantageous in several respects including environmental ones, to take it into account for RHEL 10. It may even be a basis for a conversion campaign involving compatible systems that were once Windows 10, to promote conversion from Windows 10 to RHEL 10.
Just think of the irony of going from Windows 10 to RHEL 10 as your new operating system on the computer!
That would be funny but - it seems that RH's agenda does not have a focus on workstation scenarios anymore. Main productivity applications are already marked as deprecated. So, they will not be included in a future major release:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
I'm working for a company in the retail business and we're running exclusively on (RH)EL/clones for the lasts decades. Also running remote desktops using our own solution based on NX libs. It was a pain to realize that RHEL is drifting away more and more from providing what is required in our environment. It became clearer and clearer that our future road will go away from RHEL despite maintaining quite a large inhouse repo for all kind of our own packages of software used, from development to normal office to server applications.
Simon
On Tue, Jan 9, 2024 at 7:17 AM Simon Matter simon.matter@invoca.ch wrote:
Am 09.01.24 um 00:52 schrieb John Cooper via CentOS-devel:
Additionally I don’t know how many of you can get or read the PC Pro publication. However in one of their issues last year they were providing options for what people can do when Windows 10 comes to the end of its support lifecycle.
One of the options was to switch to Linux they only mentioned Ubuntu Linux and Linux Mint. Though that doesn’t preclude people switching to RHEL on their ex-Windows 10 computers when that point is reached. Though there’s the options of RHEL 8 and RHEL 9 it would be advantageous in several respects including environmental ones, to take it into account for RHEL 10. It may even be a basis for a conversion campaign involving compatible systems that were once Windows 10, to promote conversion from Windows 10 to RHEL 10.
Just think of the irony of going from Windows 10 to RHEL 10 as your new operating system on the computer!
That would be funny but - it seems that RH's agenda does not have a focus on workstation scenarios anymore. Main productivity applications are already marked as deprecated. So, they will not be included in a future major release:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
I'm working for a company in the retail business and we're running exclusively on (RH)EL/clones for the lasts decades. Also running remote desktops using our own solution based on NX libs. It was a pain to realize that RHEL is drifting away more and more from providing what is required in our environment. It became clearer and clearer that our future road will go away from RHEL despite maintaining quite a large inhouse repo for all kind of our own packages of software used, from development to normal office to server applications.
None of these packages are a surprise though: Qt 5 is being replaced with Qt 6[1], Motif is dead, Xorg is being replaced with Xwayland[2], LibreOffice transitioned to the community in Fedora in the summer[3], GTK2 is EOL upstream, gedit is replaced with gnome-text-editor[4][5], etc.
If people care about using RHEL as a workstation as customers, they should be making that known through their contacts with Red Hat Sales and Red Hat Support. What I've gathered so far is that this is happening for some of them because they believe customers aren't really using them and so the effort is wasted. Some of them are for other reasons (Motif/GTK2 being dead, Wayland being the future, etc.), but dedicated RHEL workstation priority use-cases are counted through purchases of RHEL subscriptions for that purpose. If you're not doing that, then it's no surprise they think nobody is using them.
[1]: https://github.com/minimization/content-resolver-input/commit/8959634466ac7f... [2]: https://www.redhat.com/en/blog/rhel-10-plans-wayland-and-xorg-server [3]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [4]: https://github.com/minimization/content-resolver-input/commit/96adc43a66980f... [5]: https://github.com/minimization/content-resolver-input/commit/de060482154617...
-- 真実はいつも一つ！/ Always, there's only one truth!
Am 09.01.24 um 13:49 schrieb Neal Gompa:
On Tue, Jan 9, 2024 at 7:17 AM Simon Matter simon.matter@invoca.ch wrote:
Am 09.01.24 um 00:52 schrieb John Cooper via CentOS-devel:
Additionally I don’t know how many of you can get or read the PC Pro publication. However in one of their issues last year they were providing options for what people can do when Windows 10 comes to the end of its support lifecycle.
One of the options was to switch to Linux they only mentioned Ubuntu Linux and Linux Mint. Though that doesn’t preclude people switching to RHEL on their ex-Windows 10 computers when that point is reached. Though there’s the options of RHEL 8 and RHEL 9 it would be advantageous in several respects including environmental ones, to take it into account for RHEL 10. It may even be a basis for a conversion campaign involving compatible systems that were once Windows 10, to promote conversion from Windows 10 to RHEL 10.
Just think of the irony of going from Windows 10 to RHEL 10 as your new operating system on the computer!
That would be funny but - it seems that RH's agenda does not have a focus on workstation scenarios anymore. Main productivity applications are already marked as deprecated. So, they will not be included in a future major release:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
I'm working for a company in the retail business and we're running exclusively on (RH)EL/clones for the lasts decades. Also running remote desktops using our own solution based on NX libs. It was a pain to realize that RHEL is drifting away more and more from providing what is required in our environment. It became clearer and clearer that our future road will go away from RHEL despite maintaining quite a large inhouse repo for all kind of our own packages of software used, from development to normal office to server applications.
None of these packages are a surprise though: Qt 5 is being replaced with Qt 6[1], Motif is dead, Xorg is being replaced with Xwayland[2], LibreOffice transitioned to the community in Fedora in the summer[3], GTK2 is EOL upstream, gedit is replaced with gnome-text-editor[4][5], etc.
If people care about using RHEL as a workstation as customers, they should be making that known through their contacts with Red Hat Sales and Red Hat Support. What I've gathered so far is that this is happening for some of them because they believe customers aren't really using them and so the effort is wasted. Some of them are for other reasons (Motif/GTK2 being dead, Wayland being the future, etc.), but dedicated RHEL workstation priority use-cases are counted through purchases of RHEL subscriptions for that purpose. If you're not doing that, then it's no surprise they think nobody is using them.
I just gave a hint and also mainly about "productivity applications" (not widget toolkits). For instance, Libreoffice is gone in the future (EL10). Evolution (nativ e-mail client) is deprecated already. rhythmbox not in EL9 anymore. Even my tech docs written in LaTeX can't be build anymore (missing TeX parts). I could investigate more scenarios where RHEL as workstation would not fulfill the requirements (its off-topic already). Just a week ago, I build gnome-network-displays for EL9 locally to stream my display to a screen for productivity proposes.
Someone could argue that this should be all in containers (its the future right? - My prediction is, that some day RHEL will be an Immutable OS).
On the other side and for the sake of fairness; RH is pushing Wayland (as you already said) and working on HDR/GPU support [1] and thats great!
I don't think that RH thinks that nobody is using RHEL on desktop computers. Its just a matter of resources that pushes such decisions. So, you a right, if just the half of the server variant subscriptions would exist for the workstation variant ...
[1] https://www.redhat.com/en/blog/rhel-10-plans-wayland-and-xorg-server
On Tue, 9 Jan 2024 at 14:16, Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
Am 09.01.24 um 13:49 schrieb Neal Gompa:
On Tue, Jan 9, 2024 at 7:17 AM Simon Matter simon.matter@invoca.ch wrote:
Am 09.01.24 um 00:52 schrieb John Cooper via CentOS-devel:
Additionally I don’t know how many of you can get or read the PC Pro publication. However in one of their issues last year they were providing options for what people can do when Windows 10 comes to the end of its support lifecycle.
One of the options was to switch to Linux they only mentioned Ubuntu Linux and Linux Mint. Though that doesn’t preclude people switching to RHEL on their ex-Windows 10 computers when that point is reached. Though there’s the options of RHEL 8 and RHEL 9 it would be advantageous in several respects including environmental ones, to take it into account for RHEL 10. It may even be a basis for a conversion campaign involving compatible systems that were once Windows 10, to promote conversion from Windows 10 to RHEL 10.
Just think of the irony of going from Windows 10 to RHEL 10 as your new operating system on the computer!
That would be funny but - it seems that RH's agenda does not have a focus on workstation scenarios anymore. Main productivity applications are already marked as deprecated. So, they will not be included in a future major release:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
I'm working for a company in the retail business and we're running exclusively on (RH)EL/clones for the lasts decades. Also running remote desktops using our own solution based on NX libs. It was a pain to realize that RHEL is drifting away more and more from providing what is required in our environment. It became clearer and clearer that our future road will go away from RHEL despite maintaining quite a large inhouse repo for all kind of our own packages of software used, from development to normal office to server applications.
None of these packages are a surprise though: Qt 5 is being replaced with Qt 6[1], Motif is dead, Xorg is being replaced with Xwayland[2], LibreOffice transitioned to the community in Fedora in the summer[3], GTK2 is EOL upstream, gedit is replaced with gnome-text-editor[4][5], etc.
If people care about using RHEL as a workstation as customers, they should be making that known through their contacts with Red Hat Sales and Red Hat Support. What I've gathered so far is that this is happening for some of them because they believe customers aren't really using them and so the effort is wasted. Some of them are for other reasons (Motif/GTK2 being dead, Wayland being the future, etc.), but dedicated RHEL workstation priority use-cases are counted through purchases of RHEL subscriptions for that purpose. If you're not doing that, then it's no surprise they think nobody is using them.
I just gave a hint and also mainly about "productivity applications" (not widget toolkits). For instance, Libreoffice is gone in the future (EL10). Evolution (nativ e-mail client) is deprecated already. rhythmbox not in EL9 anymore. Even my tech docs written in LaTeX can't be build anymore (missing TeX parts). I could investigate more scenarios where RHEL as workstation would not fulfill the requirements (its off-topic already). Just a week ago, I build gnome-network-displays for EL9 locally to stream my display to a screen for productivity proposes.
Someone could argue that this should be all in containers (its the future right? - My prediction is, that some day RHEL will be an Immutable OS).
FWIW, containers are a great solution if you can't find a package for your given distro (it's the first alternative I look to). Most UI applications work great these days in a container via toolbox/distrobox.
On the other side and for the sake of fairness; RH is pushing Wayland (as you already said) and working on HDR/GPU support [1] and thats great!
I don't think that RH thinks that nobody is using RHEL on desktop computers. Its just a matter of resources that pushes such decisions. So, you a right, if just the half of the server variant subscriptions would exist for the workstation variant ...
[1] https://www.redhat.com/en/blog/rhel-10-plans-wayland-and-xorg-server
-- Leon
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 1/9/24 9:16 AM, Leon Fauster via CentOS-devel wrote:
I just gave a hint and also mainly about "productivity applications" (not widget toolkits). For instance, Libreoffice is gone in the future (EL10). Evolution (nativ e-mail client) is deprecated already. rhythmbox not in EL9 anymore. Even my tech docs written in LaTeX can't be build anymore (missing TeX parts). I could investigate more scenarios where RHEL as workstation would not fulfill the requirements (its off-topic already). Just a week ago, I build gnome-network-displays for EL9 locally to stream my display to a screen for productivity proposes.
Something to keep in mind is the intended target of RHEL Workstation. It's not really meant as a general desktop replacement kitted out with apps for the average users' workloads. Per the product page[0]:
* Red Hat® Enterprise Linux® for Workstations is optimized for high * performance graphics, animation, and scientific activities–with all * the capabilities and applications workstation users need to focus on * their tasks and not workstation administration.
As a sysadmin in the animation industry, none of the usual non-core applications get used within our workloads unless by accident. We use dedicated, industry oriented tools in our environments for playback, image viewing, etc. Generally speaking, Files, GNOME Terminal, and GNOME Text Editor are really the only provided tools used. Eye of GNOME does get opened for image types that aren't redirected to our tools, but it's pretty much just used to quickly view reference images downloaded from the internet.
Workstation is really focused on providing a solid platform for end users and administrators to build and integrate their specific workloads onto. It's part of the reason why Fedora is commonly recommended for more general purpose scenarios, even within Red Hat. That's not to say it can't be used for such workloads, but it's not a core focus. The direction being taken became pretty clear after RHEL Desktop was dropped from the product lineup with RHEL 8 (necessitating an upgrade to Workstation subscriptions).
Some of the traditional applications being dropped/deprecated are also seeing a shift from distribution packaging to Flatpaks provided directly by the upstream providers. LibreOffice and Evolution are good examples of this, along with other GNOME apps in general. Some of them are also a royal pain to maintain for packagers, so this lifts a burden off of Red Hat engineers to focus on more customer-valued components.
That being said, Red Hat also has their own experimental Flatpak registry[1] containing a handful of applications as well as the RHEL runtime and SDK. Currently, there is:
- GIMP - Inkscape - LibreOffice - Firefox - Thunderbird - Red Hat Platform (8/9) - Red Hat SDK (8/9)
I do not know what the future plans for this registry are.
Someone could argue that this should be all in containers (its the future right? - My prediction is, that some day RHEL will be an Immutable OS).
These are my own thoughts, but I'm not expecting a RHEL Silverblue any time soon. It's not outside of the realm of possibility, though. As a former Red Hat Solution Architect, the way we approached immutability was really around edge and server workloads using the Image Builder toolset[2,3]. RHEL for Edge isn't a prebuilt distribution, but a toolset enabling users to create their own platforms to best serve their workloads.
I don't think that RH thinks that nobody is using RHEL on desktop computers. Its just a matter of resources that pushes such decisions. So, you a right, if just the half of the server variant subscriptions would exist for the workstation variant ...
Looping back to my first section, this is really what it is. Workstation usage is definitely less than Server and its needs are driven by its customer base. If a non-trivial segment of the base isn't actively using or relying on certain applications, those are development resources Red Hat could reallocate towards projects that matter to their customers.
[0] https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/work...
[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
[2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
[3] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
My company has available Red Hat Linux available for SWE, and SRE workstations along side with Macs. The main reason being compatibility with security and other compliance tools. Fedora couldn't be an option because of that.
As far as I know RedHat used to target Developers too with their Workstations. We also use FlatPak, and third party official repos for some software.
When buying Workstation computers, we look for those that are certified for RedHat. My guess is that when RHEL 10 comes with the new micro-arch requirements, the Certified Hardware program will adjust accordingly.
I also see a general trend for "Immutable OS", keeping only a core of applications, and unloading the burden of packing to the upstream. OpenSUSE, and Ubuntu are sort of doing it already with alternative distros. The question is whether the users would accept and receive that change.
Regards, Carlos.
On 1/10/24 16:54, Mike Rochefort via CentOS-devel wrote:
On 1/9/24 9:16 AM, Leon Fauster via CentOS-devel wrote:
I just gave a hint and also mainly about "productivity applications" (not widget toolkits). For instance, Libreoffice is gone in the future (EL10). Evolution (nativ e-mail client) is deprecated already. rhythmbox not in EL9 anymore. Even my tech docs written in LaTeX can't be build anymore (missing TeX parts). I could investigate more scenarios where RHEL as workstation would not fulfill the requirements (its off-topic already). Just a week ago, I build gnome-network-displays for EL9 locally to stream my display to a screen for productivity proposes.
Something to keep in mind is the intended target of RHEL Workstation. It's not really meant as a general desktop replacement kitted out with apps for the average users' workloads. Per the product page[0]:
- Red Hat® Enterprise Linux® for Workstations is optimized for high
- performance graphics, animation, and scientific activities–with all
- the capabilities and applications workstation users need to focus on
- their tasks and not workstation administration.
As a sysadmin in the animation industry, none of the usual non-core applications get used within our workloads unless by accident. We use dedicated, industry oriented tools in our environments for playback, image viewing, etc. Generally speaking, Files, GNOME Terminal, and GNOME Text Editor are really the only provided tools used. Eye of GNOME does get opened for image types that aren't redirected to our tools, but it's pretty much just used to quickly view reference images downloaded from the internet.
Workstation is really focused on providing a solid platform for end users and administrators to build and integrate their specific workloads onto. It's part of the reason why Fedora is commonly recommended for more general purpose scenarios, even within Red Hat. That's not to say it can't be used for such workloads, but it's not a core focus. The direction being taken became pretty clear after RHEL Desktop was dropped from the product lineup with RHEL 8 (necessitating an upgrade to Workstation subscriptions).
Some of the traditional applications being dropped/deprecated are also seeing a shift from distribution packaging to Flatpaks provided directly by the upstream providers. LibreOffice and Evolution are good examples of this, along with other GNOME apps in general. Some of them are also a royal pain to maintain for packagers, so this lifts a burden off of Red Hat engineers to focus on more customer-valued components.
That being said, Red Hat also has their own experimental Flatpak registry[1] containing a handful of applications as well as the RHEL runtime and SDK. Currently, there is:
- GIMP
- Inkscape
- LibreOffice
- Firefox
- Thunderbird
- Red Hat Platform (8/9)
- Red Hat SDK (8/9)
I do not know what the future plans for this registry are.
Someone could argue that this should be all in containers (its the future right? - My prediction is, that some day RHEL will be an Immutable OS).
These are my own thoughts, but I'm not expecting a RHEL Silverblue any time soon. It's not outside of the realm of possibility, though. As a former Red Hat Solution Architect, the way we approached immutability was really around edge and server workloads using the Image Builder toolset[2,3]. RHEL for Edge isn't a prebuilt distribution, but a toolset enabling users to create their own platforms to best serve their workloads.
I don't think that RH thinks that nobody is using RHEL on desktop computers. Its just a matter of resources that pushes such decisions. So, you a right, if just the half of the server variant subscriptions would exist for the workstation variant ...
Looping back to my first section, this is really what it is. Workstation usage is definitely less than Server and its needs are driven by its customer base. If a non-trivial segment of the base isn't actively using or relying on certain applications, those are development resources Red Hat could reallocate towards projects that matter to their customers.
[0] https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/work...
[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
[2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
[3] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
On Tue, Jan 9, 2024 at 7:17 AM Simon Matter simon.matter@invoca.ch wrote:
Am 09.01.24 um 00:52 schrieb John Cooper via CentOS-devel:
Additionally I don’t know how many of you can get or read the PC Pro publication. However in one of their issues last year they were providing options for what people can do when Windows 10 comes to the end of its support lifecycle.
One of the options was to switch to Linux they only mentioned Ubuntu Linux and Linux Mint. Though that doesn’t preclude people switching
to
RHEL on their ex-Windows 10 computers when that point is reached.
Though
there’s the options of RHEL 8 and RHEL 9 it would be advantageous in several respects including environmental ones, to take it into
account
for RHEL 10. It may even be a basis for a conversion campaign
involving
compatible systems that were once Windows 10, to promote conversion
from
Windows 10 to RHEL 10.
Just think of the irony of going from Windows 10 to RHEL 10 as your
new
operating system on the computer!
That would be funny but - it seems that RH's agenda does not have a focus on workstation scenarios anymore. Main productivity applications are already marked as deprecated. So, they will not be included in a future major release:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
I'm working for a company in the retail business and we're running exclusively on (RH)EL/clones for the lasts decades. Also running remote desktops using our own solution based on NX libs. It was a pain to realize that RHEL is drifting away more and more from providing what is required in our environment. It became clearer and clearer that our future road will go away from RHEL despite maintaining quite a large inhouse repo for all kind of our own packages of software used, from development to normal office to server applications.
None of these packages are a surprise though: Qt 5 is being replaced with Qt 6[1], Motif is dead, Xorg is being replaced with Xwayland[2], LibreOffice transitioned to the community in Fedora in the summer[3], GTK2 is EOL upstream, gedit is replaced with gnome-text-editor[4][5], etc.
If people care about using RHEL as a workstation as customers, they should be making that known through their contacts with Red Hat Sales and Red Hat Support. What I've gathered so far is that this is happening for some of them because they believe customers aren't really using them and so the effort is wasted. Some of them are for other reasons (Motif/GTK2 being dead, Wayland being the future, etc.), but dedicated RHEL workstation priority use-cases are counted through purchases of RHEL subscriptions for that purpose. If you're not doing that, then it's no surprise they think nobody is using them.
What I'd be interested to know is what Red Hat is using internally these days to run their business.
In the past I really thought they may be using their on RHEL product line for their corporate use. But today I start to believe they may probably use the same industry standard crap everybody is using.
Would be really interesting to be a mouse in Red Hat's own offices and headquarters :)
Regards, Simon
On Tue, Jan 9, 2024 at 9:19 AM Simon Matter simon.matter@invoca.ch wrote:
On Tue, Jan 9, 2024 at 7:17 AM Simon Matter simon.matter@invoca.ch wrote:
Am 09.01.24 um 00:52 schrieb John Cooper via CentOS-devel:
Additionally I don’t know how many of you can get or read the PC Pro publication. However in one of their issues last year they were providing options for what people can do when Windows 10 comes to the end of its support lifecycle.
One of the options was to switch to Linux they only mentioned Ubuntu Linux and Linux Mint. Though that doesn’t preclude people switching
to
RHEL on their ex-Windows 10 computers when that point is reached.
Though
there’s the options of RHEL 8 and RHEL 9 it would be advantageous in several respects including environmental ones, to take it into
account
for RHEL 10. It may even be a basis for a conversion campaign
involving
compatible systems that were once Windows 10, to promote conversion
from
Windows 10 to RHEL 10.
Just think of the irony of going from Windows 10 to RHEL 10 as your
new
operating system on the computer!
That would be funny but - it seems that RH's agenda does not have a focus on workstation scenarios anymore. Main productivity applications are already marked as deprecated. So, they will not be included in a future major release:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
I'm working for a company in the retail business and we're running exclusively on (RH)EL/clones for the lasts decades. Also running remote desktops using our own solution based on NX libs. It was a pain to realize that RHEL is drifting away more and more from providing what is required in our environment. It became clearer and clearer that our future road will go away from RHEL despite maintaining quite a large inhouse repo for all kind of our own packages of software used, from development to normal office to server applications.
None of these packages are a surprise though: Qt 5 is being replaced with Qt 6[1], Motif is dead, Xorg is being replaced with Xwayland[2], LibreOffice transitioned to the community in Fedora in the summer[3], GTK2 is EOL upstream, gedit is replaced with gnome-text-editor[4][5], etc.
If people care about using RHEL as a workstation as customers, they should be making that known through their contacts with Red Hat Sales and Red Hat Support. What I've gathered so far is that this is happening for some of them because they believe customers aren't really using them and so the effort is wasted. Some of them are for other reasons (Motif/GTK2 being dead, Wayland being the future, etc.), but dedicated RHEL workstation priority use-cases are counted through purchases of RHEL subscriptions for that purpose. If you're not doing that, then it's no surprise they think nobody is using them.
What I'd be interested to know is what Red Hat is using internally these days to run their business.
In the past I really thought they may be using their on RHEL product line for their corporate use. But today I start to believe they may probably use the same industry standard crap everybody is using.
Would be really interesting to be a mouse in Red Hat's own offices and headquarters :)
They switched to Fedora for their preferred Linux distribution for workstations last year.
On Tue, Jan 9, 2024 at 9:19 AM Simon Matter simon.matter@invoca.ch wrote:
On Tue, Jan 9, 2024 at 7:17 AM Simon Matter simon.matter@invoca.ch wrote:
Am 09.01.24 um 00:52 schrieb John Cooper via CentOS-devel:
Additionally I don’t know how many of you can get or read the PC
Pro
publication. However in one of their issues last year they were providing options for what people can do when Windows 10 comes to
the
end of its support lifecycle.
One of the options was to switch to Linux they only mentioned
Ubuntu
Linux and Linux Mint. Though that doesn’t preclude people
switching
to
RHEL on their ex-Windows 10 computers when that point is reached.
Though
there’s the options of RHEL 8 and RHEL 9 it would be advantageous
in
several respects including environmental ones, to take it into
account
for RHEL 10. It may even be a basis for a conversion campaign
involving
compatible systems that were once Windows 10, to promote
conversion
from
Windows 10 to RHEL 10.
Just think of the irony of going from Windows 10 to RHEL 10 as
your
new
operating system on the computer!
That would be funny but - it seems that RH's agenda does not have a focus on workstation scenarios anymore. Main productivity
applications
are already marked as deprecated. So, they will not be included in
a
future major release:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
I'm working for a company in the retail business and we're running exclusively on (RH)EL/clones for the lasts decades. Also running
remote
desktops using our own solution based on NX libs. It was a pain to realize that RHEL is drifting away more and more from providing what is
required
in our environment. It became clearer and clearer that our future
road
will go away from RHEL despite maintaining quite a large inhouse repo for all kind of our own packages of software used, from development to normal office to server applications.
None of these packages are a surprise though: Qt 5 is being replaced with Qt 6[1], Motif is dead, Xorg is being replaced with Xwayland[2], LibreOffice transitioned to the community in Fedora in the summer[3], GTK2 is EOL upstream, gedit is replaced with gnome-text-editor[4][5], etc.
If people care about using RHEL as a workstation as customers, they should be making that known through their contacts with Red Hat Sales and Red Hat Support. What I've gathered so far is that this is happening for some of them because they believe customers aren't really using them and so the effort is wasted. Some of them are for other reasons (Motif/GTK2 being dead, Wayland being the future, etc.), but dedicated RHEL workstation priority use-cases are counted through purchases of RHEL subscriptions for that purpose. If you're not doing that, then it's no surprise they think nobody is using them.
What I'd be interested to know is what Red Hat is using internally these days to run their business.
In the past I really thought they may be using their on RHEL product line for their corporate use. But today I start to believe they may probably use the same industry standard crap everybody is using.
Would be really interesting to be a mouse in Red Hat's own offices and headquarters :)
They switched to Fedora for their preferred Linux distribution for workstations last year.
So, their HR, the bean counters in finance, the marketing specialists and graphical designers, they're running on Fedora these days?
Of course Fedora is better suited for such office tasks than EL but on the other side, stability is key in the corporate world, so I'm still a bit wondering how they are doing it with Fedora.
Simon
On Tue, Jan 9, 2024 at 10:07 AM Simon Matter simon.matter@invoca.ch wrote:
On Tue, Jan 9, 2024 at 9:19 AM Simon Matter simon.matter@invoca.ch wrote:
On Tue, Jan 9, 2024 at 7:17 AM Simon Matter simon.matter@invoca.ch wrote:
Am 09.01.24 um 00:52 schrieb John Cooper via CentOS-devel: > Additionally I don’t know how many of you can get or read the PC
Pro
> publication. However in one of their issues last year they were > providing options for what people can do when Windows 10 comes to
the
> end of its support lifecycle. > > One of the options was to switch to Linux they only mentioned
Ubuntu
> Linux and Linux Mint. Though that doesn’t preclude people
switching
to
> RHEL on their ex-Windows 10 computers when that point is reached.
Though
> there’s the options of RHEL 8 and RHEL 9 it would be advantageous
in
> several respects including environmental ones, to take it into
account
> for RHEL 10. It may even be a basis for a conversion campaign
involving
> compatible systems that were once Windows 10, to promote
conversion
from
> Windows 10 to RHEL 10. > > Just think of the irony of going from Windows 10 to RHEL 10 as
your
new
> operating system on the computer! >
That would be funny but - it seems that RH's agenda does not have a focus on workstation scenarios anymore. Main productivity
applications
are already marked as deprecated. So, they will not be included in
a
future major release:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
I'm working for a company in the retail business and we're running exclusively on (RH)EL/clones for the lasts decades. Also running
remote
desktops using our own solution based on NX libs. It was a pain to realize that RHEL is drifting away more and more from providing what is
required
in our environment. It became clearer and clearer that our future
road
will go away from RHEL despite maintaining quite a large inhouse repo for all kind of our own packages of software used, from development to normal office to server applications.
None of these packages are a surprise though: Qt 5 is being replaced with Qt 6[1], Motif is dead, Xorg is being replaced with Xwayland[2], LibreOffice transitioned to the community in Fedora in the summer[3], GTK2 is EOL upstream, gedit is replaced with gnome-text-editor[4][5], etc.
If people care about using RHEL as a workstation as customers, they should be making that known through their contacts with Red Hat Sales and Red Hat Support. What I've gathered so far is that this is happening for some of them because they believe customers aren't really using them and so the effort is wasted. Some of them are for other reasons (Motif/GTK2 being dead, Wayland being the future, etc.), but dedicated RHEL workstation priority use-cases are counted through purchases of RHEL subscriptions for that purpose. If you're not doing that, then it's no surprise they think nobody is using them.
What I'd be interested to know is what Red Hat is using internally these days to run their business.
In the past I really thought they may be using their on RHEL product line for their corporate use. But today I start to believe they may probably use the same industry standard crap everybody is using.
Would be really interesting to be a mouse in Red Hat's own offices and headquarters :)
They switched to Fedora for their preferred Linux distribution for workstations last year.
So, their HR, the bean counters in finance, the marketing specialists and graphical designers, they're running on Fedora these days?
Neal described the standardized Linux distribution in place, not who is using it. We generally don't comment on internal systems dynamics.
Of course Fedora is better suited for such office tasks than EL but on the other side, stability is key in the corporate world, so I'm still a bit wondering how they are doing it with Fedora.
Like everyone else using Fedora.
josh
-
aleksander.baranowski -
Alex Iribarren -
Carlos Rodriguez-Fernandez -
Eric Curtin -
František Šumšal -
Fred -
Gerd v. Egidy -
Gordon Messmer -
Jean-Marc Liger -
John Cooper -
Josh Boyer -
Lance Albertson -
Leon Fauster -
Michel Lind -
Mike Rochefort -
Neal Gompa -
Phil Perry -
Simon Matter -
Trevor Hemsley