Future of x86_64-v2 support

[mnv]

Hello everyone,

I’m posting this on AltArch, since it’s what that will become soon, somehow.

I see RedHat seems to be going on with their plan to increase their baseline to x86_64-v3 for RHEL 10, do you have any plans to keep supporting older ISAs (specifically v2, as v1 seems to already have been dropped) with your next major release? Will you be investigating hwcaps like Fedora is doing?

TIA

[nazunalika]

@mnv

I see RedHat seems to be going on with their plan to increase their baseline to x86_64-v3 for RHEL 10, do you have any plans to keep supporting older ISAs (specifically v2, as v1 seems to already have been dropped) with your next major release?

From a Release Engineering point of view: There are no plans. From a Special Interest Group point of view: I do not think they’re interested at this time.

As we’ve already been building Rocky Linux 10 by following CentOS Stream 10, only x86-64-v3 is supported. To support x86-64-v2, it would require us to rebuild glibc and then the rest of 2k+ packages. And I do not think this Special Interest Group would be interested in doing any parallel builds on the side just for this support, just as Release Engineering does not want to spend time rebuilding everything just to support it.

[bkhomuts]

I know AlmaLinux plans to do it. Maybe we can copy their setup?

[jlehtone]

Are you happy with the packages in Rocky?
Do you perhaps use third-party repos like EPEL too?
AFAIK, EPEL 10 will build for x86-64-v3. I.e. not for x86-64-v2 el10 distros.

Besides, there has been claims that el10 will drop “non-essential” packages,
like Firefox and LibreOffice (delegated to flatpaks). I have no idea how flatpaks
are built, i.e. do they depend on distro’s glibc, etc.

[bkhomuts]

EPEL is a third-party project. Yes, for my use the base Rocky packages are sufficient.

For the community it is important to not follow the enterprise Linux, because paid Linux customers may afford buying new hardware. For our users, I suggest keeping the support of old hardware, otherwise we risk losing the “market” share to Alma.
Not following the EL may be implemented as a separate build of packages, which use x86-64-v3 instructions, or by other mechanism allowing to run the v3 code on v2 processors.

[bkhomuts]

I think I can even help realizing the concept. It’s all about the compile flags in the end. Web hosting providers will be happy . Think also about schools and universities in the “third” world.

[bkhomuts]

Hello,

I have opened another initiative for support of old x86_64 hardware on Rocky10:

Run Rocky10 on x86_64-v2, x86_64-v1, x86_64-v0 initiative

Hello, RockyLinux is a great project, but unfortunately, newer versions reduce the hardware support, in contrast to Debian, which runs on older hardware as well as on the newest. I’m proposing to do a rebuild of packages for Rocky Linux 10 to support x86-64-v2, and then on x86-64-v1 and x86-64-v0 (AMD64). This should be no problem as long as there is no unconditional AVX instructions the assembly code. The idea is to people, who use old systems for one or another, have a choice to run Rocky. I…

[iwalker]

@bkhomuts

I know AlmaLinux plans to do it. Maybe we can copy their setup?

AlmaLinux are ABI-compatible or binary compatible now. Therefore they are not direct 1:1 with RHEL like Rocky is. If we do what Alma does, then we are no longer 1:1 with RHEL. So no point copying what they do.

Since Rocky maintains to be 1:1 with RHEL, changing and adding this no longer stays compatible with that ethos.

You should really be talking to @neil and @nazunalika first.

[bkhomuts]

@iwalker ,

I’m talking about x86_64-v2 support claimed here: Kitten 10 | AlmaLinux Wiki . The binary compatibility may not be needed for people using those older systems anyway

This effort wouldn’t break the ethos more than getting RISC-V support enabled before RHEL.

[iwalker]

I’ll close this thread, so it can be continued here: Run Rocky10 on x86_64-v2, x86_64-v1, x86_64-v0 initiative

Otherwise discussions get fragmented.