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: https://wiki.archlinux.org/title/unofficial_user_repositories#ALHP
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
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.
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.
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.
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
Never had that issue but I use /boot/efi for ESP with systemd-boot
Edit: is that the issue? https://somegit.dev/ALHP/ALHP.GO/issues/174
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
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.
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.
ALPH:
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.
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/ld-linux-x86-64.so.2 --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-v4
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.
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?
