ALHP just launched a repo for x86_64-v4 rebuilds

ALHP just launched it’s x86_64-v4 - repositories which contain a complete rebuild of the Arch stable repositories but with the x86_64-v4 feature level as compile target.
For those who don’t know what ALHP is: It is on the Arch unofficial Repository list found here:

If you don’t know what feature levels are:

I have already used his v3 - repo’s for many months, and while the packages don’t do wonders, they also don’t harm and in some edge cases especially in games provide some extra performance compared to stock EndeavourOS/Arch packages. (And I read that some others already use ALHP repositories, too.)

The only other one that I know of who offers feature-Level targeted rebuilds is CachyOS but there only the Kernels are build for v4, and he has his own Distribution in mind which is Arch based but even further away from Arch then Manjaro is, so his packages come with some issues and especially the kernels are experimental (at least they were in the 2 weeks I used CachyOS repo’s).

For more information check out the official information at:

Arch Dev’s have already discussed if they want to offer v3 packages officially, but they could not yet find a solution on how to not make dev’s wait twice as long for their package updates so users have to rely on people like the one behind ALHP if they want to use the feature-level based optimizations without rebuilding all packages on their own :wink:

I created this topic in Community Contributions because I think that ALHP is a great community-based addition to the Arch world. If it better fits elsewhere, Mod’s please move the topic.

1 Like

Aaactually CachyOS has core and extra as v4 too now. They still consider it very new and therefore not promoting it officially yet. But you can add the repos if you are inclined to test them.

Glad to see further development in that regard. Hopefully Arch is able to migrate its infrastructure and support v3 in the future too.

yeah, but cachy also includes some of his own decisions, especially in the kernels and he also ships his own firefox fork with quite some custom patches. Personally I don’t recommend using his repo’s.

ALHP on the other hand simply takes the PKGBUILD’s from Arch and rebuilds them without adding own patches.

And some more news on the matter from Ubuntu:

Well yes, Cachy offers a lot of patched kernels and provides its own patched browser. And since Cachy aspires to be its own distro those come per default if you install from the CachyOS iso. But if you just add the Cachy repos afterwards there’s no difference to ALHP.

Cachy’s unique packages all have a unique name and you have to install them deliberately. Up to the point that afaik linux, linux-lts and linux-zen gives you the original Arch package on Cachy, but you will receive the ALHP version adding the ALHP repo.

well, you realized it on your own:

so by default, it leaves you with THE core component un-optimized or you go with his experimental kernels. Or you add yet another source for the kernels. not a good solution

Have they fixed the issues with kernel-install yet?

We have had several people end up with unbootable systems due to switching to ALHP.

Never had that issue but I use /boot/efi for ESP with systemd-boot

Edit: is that the issue?
Looks “fixed” for me Edit2: Meaning that this problem should not appear any more in the current state of the issue.

That’s a scale and a question of how you want to define things. At least you have the “unoptimized” and “non-experimental” fallback. But if your preferred choice is “unoptimized” but “non-experimental” anyway what is the point of using those repos?

Personally I switched several times between Arch/EndevourOS, ALHP and Cachy, never experienced an unbootable system. Maybe I just got lucky with my setups.

I use alhp because it provides optimized non-experimental packages, including kernels and caters to stock arch instead of an even-worse-then-Manjaro arch-based distro

Glad you found something you like and are happy in that space. Guess we just have different opinions on that one.

There’s choice, and choice is usually good. I didn’t come to argue which is “better” or “right”.

Yeah. Was kind of in a bad mood yesterday, sorry. The thing with CachyOS is that the maintainer is apparently in over his head. In the two weeks I used his mix of v4 and v3 repo’s on EndeavourOS (that’s what he recommended back then), I tried to use his kernels because I liked the idea of different schedulers, i have good experience with the -ck patchset and others, but even the most conservative kernel he offered on CachyOS had severe stability issues that even lead to minor data corruption on my system.

I found out later on that he took several patches for memory handling and file system handling, that were in the very first steps of getting upstreamed on the Linux Kernel Mailing List LKML and they had major issues that were only squared away when they were included in the RC builds, but still they were included in ALL CachyOS Kernels months before that.

Just in case you are not familiar with it, when developers want to upstream something, they send the patches to the mailing list to start a discussion and getting feedback on what needs to be changed, improved or what can cause issues. When the patches are in a state that the Kernel Devs think they can possibly get upstreamed, the patches are committed to the Linux-next tree, where the Kernel Dev’s responsible for the relevant Kernel part further review the patches and either dismiss them (back to step 1) or forward them to Linus Torvalds in the next merge window that happens before the RC phase of a new major kernel so that he can review them and decide if he wants to merge them or thinks that they still need some work (they stay in linux-next then until the developer has improved them enough and then they get forwarded to Linus again)

Taking Patches from the very first discussions on the LKML and including them in all Kernels of your distribution is just bad practice, especially if you promote your distribution as Power Up Your Computing with Robust Kernel Support
Given how bad he is with picking his custom kernel patches, I really don’t want to know what else he does in his other packages. After all, he does not just recompile stable arch but uses his own PKGBUILD’s for that.

That’s basically the main reason why I will not recommend using his repositories ever.
ALHP just has the way more sane/safe/secure approach to providing Feature Level optimized builds.

OK, this is my viewpoint:


  • Has a lot of unique and interesting kernels - robust is certainly up for interpretation
  • The kernels offer patches that are not part of the official linux kernel or even in process of a merge. I feel that’s the nature of many of the offered kernels and tweaks. That makes them interesting though because you don’t find them anywhere else - at least precompiled.
  • Afaik all changes are public incl. the few changed pkgbuilds. And actually I would prefer if some packages are not vanilla Arch. As an example svt-av1 should be compiled with AVX512 support on v4, which is not the case with Arch’s pkgbuild.
  • On a scale between “stable/non-optimized” and “non-stable/many optimizations” CachyOS is clearly positioned on latter extrem end
  • It feels like a project of maybe one or two enthusiasts. So yeah, there maybe not enough eyes or judgement to prevent some f’ups. On the other hand that’s how niche Linux distros start.


  • Seems to be a lot more conservative
  • The scope is much narrower and just provides a v* compiled version of the Arch package

ALHP just has the way more sane/safe/secure approach to providing Feature Level optimized builds.

So imho there’s no question that we can agree on that statement.

You want to be super save stay with vanilla Arch. One notch higher is zen or xanmod. One notch higher is using feature optimized packages maybe with ALHP. And if you want to go one notch higher there’s Cachy. And every notch has tradeoffs.

it’s friday… let’s try this alhp, what can go wrong, secure boot is disabled, it should be fine

I am thinking of setting up an Arch system and enable ALHP repos for testing and perhaps for using as my daily driver.

I wondered if you have used this system as your main system, your daily driver?
Has your system been running stably?

Any caveats, downsides, heads-ups you want to share? Any risks (for breakage or else) that I should be aware of?

I’v never heard of that before, but it looks like features that can be supported by your cpu. Like these ones?

Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt t
sc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear fl
ush_l1d arch_capabilities

Does that mean those packages are compiled for a specific x86_64 version, your cpu has to support that level in order to use them. If so what’s the advantage to using a version of x86_64 other than that you are using knew technology or instruction sets?

Yes, they target specific architecture feature-sets.

I’m currently on Fedora so not sure if the lib location is the exact same, but you can check your system’s support with:
/usr/lib64/ --help
(if you get no such file or directory you just need to locate the lib under Arch)

Example output from my laptop:


Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

The claimed benefit is performance improvements under specific loads.
But the general consensus seems to be that this claim is debatable and inconsistent…

From past discussions on Arch mailing list I doubt that the official default level will be raised any time soon for Arch Linux, which means that to benefit from such builds you have to go for alternative repos with all the drawbacks that may bring (eg how much you trust Arch packagers vs ALHP packagers or CachyOS).

There’s probably a couple of distros that have officially (partially?) enabled them, like openSUSE and I read recently that CentOS Stream forces x86_64-v3 now, which means that RedHat and its ecosystem might or might not follow suit in the future.

1 Like

Keep in mind that CachyOS also uses -O3 Link Time Optimization, so these benchmarks are not necessarily representative of ALHP repos (not limited to v3/v4 feature-sets).

That said, please do correct me if I’m wrong or have misunderstood Cachy’s optimization process.

I have tried it out, it can’t launch dx11 games with -march=native proton-ge-custom from AUR, had no problems before with the native flag. If I remember correctly x86_64-v3 had some issues too, probably the same.
Also I can’t compile the proton AUR package with the native flag at all. Have to use x86_64-v3, but it launches dx11 games.

I had no issues with the native flag before.

No man’s sky crashed 2-3 times since I have installed(since my previous entry in this thread), not a big deal.
I can’t launch warframe, fallout4, witcher 3, d:os 2 with proton-ge, they are all dx11.

They work with the built in proton experimental and the proton-ge-custom-bin from AUR.

Did you ever play around with proton compilation on ALHP?

ALHP is -03 too

1 Like