Arch Linux Developers Discuss Idea Of Providing An x86-64-v3 Port

[phoronix]

Phoronix: Arch Linux Developers Discuss Idea Of Providing An x86-64-v3 Port

While recently Arch Linux developers and stakeholders were discussing the possibility of raising the x86-64 base requirements for this Linux distribution to the "x86-64-v2" micro-architecture feature level that roughly correlates to Intel Nehalem and newer, now the discussion has shifted to keeping the same x86-64 base level while potentially offering a "x86-64-v3" port for those with newer Intel/AMD CPUs...

https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-x86-64-v3-Port-RFC

[skeevy420]

Very nice. Modern Linux. I hope that goes through.

[TemplarGR]

Personally i would prefer the previous suggestion. The new proposal increases the work required to maintain a different port. If the Arch devs are fine with having to maintain 2 versions of their distro then who i am to argue, BUT i feel that this might make both versions weaker as a result. They do not have infinite resources, eventually most would end up using the newer port anyway and they would maintain the "older" variant for nothing. And cutting it off by then would get even more "outrage" since it would cut off much more hardware, AVX2, while relatively old at this point, still does not exist in even some recent cpus.

I think the best way is to keep maintaining only 1 version and raise the requirements to v2 like the initial suggestion said. There are not many that would be cut off by v2 (and those cpus which lack sse4.2 are too old at this point) and the workload for the devs won't increase at all. A few years down the line they can increase it to v3.

[flower]

Personally i would prefer the previous suggestion. The new proposal increases the work required to maintain a different port. If the Arch devs are fine with having to maintain 2 versions of their distro then who i am to argue, BUT i feel that this might make both versions weaker as a result. They do not have infinite resources, eventually most would end up using the newer port anyway and they would maintain the "older" variant for nothing. And cutting it off by then would get even more "outrage" since it would cut off much more hardware, AVX2, while relatively old at this point, still does not exist in even some recent cpus.

I think the best way is to keep maintaining only 1 version and raise the requirements to v2 like the initial suggestion said. There are not many that would be cut off by v2 (and those cpus which lack sse4.2 are too old at this point) and the workload for the devs won't increase at all. A few years down the line they can increase it to v3.

except for a only few packages i think it's only a recompile with different flags.
so imho its more about computing resources than manpower

[skeevy420]

Personally i would prefer the previous suggestion. The new proposal increases the work required to maintain a different port. If the Arch devs are fine with having to maintain 2 versions of their distro then who i am to argue, BUT i feel that this might make both versions weaker as a result. They do not have infinite resources, eventually most would end up using the newer port anyway and they would maintain the "older" variant for nothing. And cutting it off by then would get even more "outrage" since it would cut off much more hardware, AVX2, while relatively old at this point, still does not exist in even some recent cpus.

I think the best way is to keep maintaining only 1 version and raise the requirements to v2 like the initial suggestion said. There are not many that would be cut off by v2 (and those cpus which lack sse4.2 are too old at this point) and the workload for the devs won't increase at all. A few years down the line they can increase it to v3.

While Alan didn't go into it, v3, from what I can tell, is also UEFI-only. That, to me, is a bigger game changer than new CPU instructions. Being free of GRUB opens up a lot of possibilities and will allow development to move a lot faster. Think of how many things in the file system and encryption world alone are hampered by legacy systems needing GRUB. Being able to standardize around what is essentially "dump stuff into a ramdisk on an fat32 EFI" opens up a lot of things.

[Nille]

Why not go the FatBinary approach. Compile different Versions and link them in one file. And let the CPU Dispacher choose the correct codepath for the system. Full Compatibility with best performance, just for the price of a bit more space required on mass storage.

[zamadatix]

While Alan didn't go into it, v3, from what I can tell, is also UEFI-only. That, to me, is a bigger game changer than new CPU instructions. Being free of GRUB opens up a lot of possibilities and will allow development to move a lot faster. Think of how many things in the file system and encryption world alone are hampered by legacy systems needing GRUB. Being able to standardize around what is essentially "dump stuff into a ramdisk on an fat32 EFI" opens up a lot of things.

Most UEFI installs still use GRUB though?

[skeevy420]

I'm quoting someone who quoted me who is shadow banned

Being able to standardize around what is essentially "dump stuff into a ramdisk on an fat32 EFI" opens up a lot of things.

bullshit as long as you maintain the old stuff too

How many years did it take GRUB to pick up LUKS2? What about when file systems pick up new features? The bullshit is the long-term maintenance burden and the risk of system breakage because the bootloader has to accommodate 10+ year old hardware you or your company will never use again. What we really need is a BIOS loader that looks for crap in a Fat32 EFI. Everyone could be treated pretty much the same and then the bulk of the maintenance would be moved over to the system side while the loader would be made simplified.

FWIW, I don't necessarily like the Fat32 choice above. I'd prefer Ext4. AFAIK, UEFI happens to use Fat32 everywhere except Apple.

[skeevy420]

Most UEFI installs still use GRUB though?

For compat reasons, yes. It's easier to deal with GRUB for all than to deal with multiple boot loaders for some.

At least that's been my experience with major distributions.

[skeevy420]

Why not go the FatBinary approach. Compile different Versions and link them in one file. And let the CPU Dispacher choose the correct codepath for the system. Full Compatibility with best performance, just for the price of a bit more space required on mass storage.

Especially with compressible file systems being all the rage. That should help offset some of extra space requirements while leaving repos open for all.