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

[intelfx]

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

Transparent compression won't necessarily help with fat binaries, unless maybe you sort the binary' contents by symbol name.

Files stored on file systems have to be seekable, thus transparent compression algoritms typically compress files in very small blocks (because you cannot seek within a compressed stream). Between blocks, all compressor context is lost. Thus, if two variants of the same code are too "far" from each other, they will not benefit from dictionary compression (which is what should help the most with fat binaries, since most of the code will likely remain the same).

[bug77]

Yes, please.

[pininety]

Hope they go with v2, if i understand it correctly, v3 would remove support for my trusty T530 thinkpad

[intelfx]

Hope they go with v2, if i understand it correctly, v3 would remove support for my trusty T530 thinkpad

I hope for the opposite, cause I want to properly use my shiny new hardware

[Grinch]

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.

Ehh ? I use UEFI with GRUB, are you saying they will deprecate GRUB in v3 ? Could you point me to where you read this ?

[intelfx]

Ehh ? I use UEFI with GRUB, are you saying they will deprecate GRUB in v3 ? Could you point me to where you read this ?

No. But going UEFI-only opens up that possibility.

Anyway this is obviously a very far call, because as long as you continue to somehow support x86_64-v1 (and thus BIOS) you aren't going to be UEFI-only.

[cbxbiker61]

My build server builds all three versions. My client machines check to see which version is most appropriate and installs it. The only downside in my setup is that it takes three times as long to build packages. If a client gets updated to more capable hardware the monthly updates will gradually (within 3 months) migrate it to the packages for the more recent hardware.

[pininety]

I hope for the opposite, cause I want to properly use my shiny new hardware

I can understand that but the speed benefit from forcing AVX2 over AVX1 in general use does not seem that big. Oh well, maybe someone will come along and make a v2.5 and then i will be covered.

[dekernel]

Personally I don't have a dog in this race anymore, but I used to use Arch for my personal machine. I picked Arch because it was targeting new CPUs which was nice, and it did feel like it snappier than both SUSE and RedHat at the time. The fact that they now are targeting such old CPUs seems odd to me since even v2 is still an 8 year old architecture, and possibly moving to that is causing heated discussions.

[StanGenchev]

I get that we should raise the minimum requirements, as it doesn't make any sense to run 2021 OS and software on late 90s and early 2000s hardware but why are they pushing AVX as minimum?

Does it really matter on OS-level? What are the benefits?
Also, there are new CPUs from both Intel and AMD that do not have AVX. For example Intel Pentium Gold G6600 was released in 2020 and AMD A8 7680 was released in 2019.

Are the benefits so big that we are willing to abandon new CPUs?