Re: Tumbleweed - Move to x86-64-v2 is the worst possible option

Hi, The more I think about it, the more wrong this approach looks to me. To get one thing out of the way: I'm fine with moving support for 32bit HW outside of openSUSE:Factory. That's truly legacy now and there are visible benefits by dropping it or making it "secondary". However, the decision to make openSUSE:Factory x86_64-v2 only has practically only downsides. Either we drop x86_64-v1 HW support completely, or introduce a project to build the distro for x86_64-v1 separately. At this point it looks like the latter is inevitable. That means: - It doubles the amount of builds and test runs (power, storage, time) - It doubles the release effort (looking at openQA, handling product changes, all the infrastructure) - It makes it necessary to migrate affected users over, which needs to work seamlessly but also inform them about this topic - It will be treated as a second-class distro, with bug reports getting less attention if "LegacyX86" is mentioned - There will be loss of functionality when some parts are not explicitly looked at for x86_64-v1. There might no longer be MicroOS/Live CDs/whatever built. (Which also means that "LegacyX86 solves your problems" is not true, at least not for long) - Various projects are not able to distinguish between x86-64 "levels", so it's not possible to seamlessly provide x86_64-v1 container and Vagrant images. (OCI/Docker can tell armv[5678] apart, but all amd64 is just amd64). What are the actual benefits of moving openSUSE:Factory to x86_64-v2 that make all this worth it? - "It's faster!": By how much? A lot of performance critical code already uses runtime dispatching, even Qt does that. It looks like x86_64-v2 alone does not have much performance improvement, based on the opinion of experts on this ML and (little) available data. At the highest end (HPC), custom builds with -march=native are preferred anyway. - "ALP wants us to because of 'Factory First'": The point of Factory First is to avoid extra work by addressing issues or adding features once for both upstream (oS:F) and downstream (SLE/ALP). In this case I don't think there's much (if any) benefit for ALP if Factory switches over. ALP will be built and tested separately anyway. If ALP hits some bug caused by x86_64-v2 and fixes that, this fix should be sent to openSUSE:Factory as well - that is Factory First! Switching to -v2 now also implies that there will be a switch to -v3 or later at some point in the future. Then we'll have this discussion all over again. That then implies dropping support for -v2, so we can only do that after -v2 is no longer relevant, which is much later than other distros which might already provide -v3+ binaries next to -v1/-v2. Am Dienstag, 6. Dezember 2022, 17:12:03 CET schrieb Lars Marowsky-Bree:

On 2022-12-05T17:07:43, Martin Jambor wrote:

...

Often they don't. To get the performance advantage you'd have to build the programs yourself of install them from a source which compiles them targeting a more recent ISA.

So I can see there may be some applications or libraries that do show significant improvement. Alright.

Would it be possible to have those few in an additional repo, or as .x86_64_vX architecture or something that gets pulled in when needed?

It really should be doable to build -v3 alongside -v1 (all of the distro or a hand-picked selection) and install the matching packages on capable hardware. That already works with i586/i686 and armv6/armv7 as well. That allows to be much more flexible and we'll be able to offer -v4+ support instantly as well. If there are concerns about additional build/test efforts - those will be less than with the current LegacyX86 design. Cheers, Fabian

Regards, Lars