For about 5 to 20% more performance/efficiency in systems newer than ~8 years old, especially for those affected by recent mitigations, you can use these v3 repositories.
This guide is by all means unofficial and incomplete, but enough packages can be replaced to make a difference.
What do they contain:
- CachyOS - Optimized kernel called
linux-cachyos, and builds of some programs like
LibreWolf, Wine, FileZilla etc.
- ALHP - An almost complete replacement of Arch's
extra. Has libsystemd components so
it requires artix-archlinux-support.
To ease the process I won't bother you with mirrorlists since I don't use them either, so just 2 servers per each will probably suffice, with the cdn mirror first to ensure reliability.
Installation:
1. If you want to use ALHP add their key (or install alhp-keyring from AUR):
# pacman-key --recv-keys E3D0D2CD3952E298 --keyserver keyserver.ubuntu.com; pacman-key --lsign-key E3D0D2CD3952E298
2. If you want to use CachyOS add their key...
# pacman-key --recv-keys F3B607488DB35A47 --keyserver keyserver.ubuntu.com; pacman-key --lsign-key F3B607488DB35A47
...and add this to the Architecture line in /etc/pacman.conf:
3. Add their repositories:
#
# REPOSITORIES
#
[system]
Include = /etc/pacman.d/mirrorlist
[world]
Include = /etc/pacman.d/mirrorlist
[galaxy]
Include = /etc/pacman.d/mirrorlist
[cachyos-v3]
Server = https://mirror.cachyos.org/repo/$arch_v3/$repo
Server = https://aur.cachyos.org/repo/$arch_v3/$repo
[extra-x86-64-v3]
Server = https://alhp.krautflare.de/$repo/os/$arch
Server = https://alhp.dev/$repo/os/$arch
[extra]
Include = /etc/pacman.d/mirrorlist-arch
*Info: For safety's sake they are place below Galaxy in this example. You can try to add them above at your own risk, for more replaced packages at the cost of maybe a few small conflicts down the line.
If you're more adventurous, cachyos-v3 can be added even further towards the top (as it's a smaller repo without libsystemd stuff), it replaces some more potentially useful pkgs. depending on your usage.Upgrade, reboot and that's it. Stability has been fine for me, for the past year or so already, so I can recommend this. :-)
I have updated the guide for the recent repo changes since last month and tested a while. If you want to try this it will be most likely trouble free, especially with the custom kernel if you don't want to touch anything else.
Just tried this out and its working well so far on kde/runit, thanks for this guide.
Using cachy kernel and their binaries for mesa, radv, wine, and a few others.
Thank you so much! I won't use any extra repos but my "architecture" option in "/etc/pacman.conf" was set to "auto" and I read the manual, and it says that when it's set to that, it will get the value given by the "uname -m" option and for me, that was "x86_64" so, I wasn't getting the "v3" options!
One question! Why setting both "x86_64" and "x86_64_v3" and not just the latter?
I have Architecture = auto and I do get the v3 packages from ALHP.
The reason you might need both is there are not v3 versions of all packages provided by ALHP. I assume CachyOS is similar?
You can see the package statuses at https://status.alhp.dev/
Their github also has more info https://github.com/an0nfunc/ALHP
Thank you for the reply! I will try CachyOS repos!
If i'm not wrong the reason CachyOS repos need a separate arch. entry is because they chose to follow the standard to specify the compile flags directly in the root directory of their host, which for convenience sake ALHP has skipped (thus their arch. line stays the same, variants v2/3/4 are named in the repo title instead).
Leaving just x86_64_v3 means of course the normal repos don't get fetched, although it won't probably be that hard to mirror the artix gitea and make an own build server with these flags. (I want to but lack time and server gear)
Thank you so much! All that was very helpful!
If both ALHP and CachyOS provide the same packages, which one should I choose for optimal usage? I wonder if there could be some external patches and fine-tuning that I can’t find information on.
I use ALHP but not CachyOS.
Both just use custom flags when compiling vanilla Arch PKGBUILDS's but CachyOS also has a custom patched kernel.
Maybe CachyOS has other customized PKGBUILD's ? Not totally sure. To the best of my knowledge ALHP is all vanilla PKGBUILD's
More information
https://github.com/CachyOS/linux-cachyos
https://github.com/an0nfunc/ALHP
eh
I thought I’d try Cachy Browser since it’s based on Librewolf+x86-64-v3 but they’ve disabled unsigned addon usage and there's no way to reenable it, which is stupid as hell since I can’t use my own inhouse addons that I created, hell no, no way am I giving those to mozilla. Quite sad.
I noticed that there's a huge problem while updating the packages when you use x86-64-v3 repos that I'm not sure how to solve...
So, let's set up a scenerio:
- Arch support enabled
- x86_64_v3 ALHP/CachyOS repos enabled
- Repo order:
[system]
[world]
[galaxy]
[cachyos-v3]
[extra-x86-64-v3]
[lib32]
[extra]
[multilib]
Let's take mpv for example, it's available in:
world/mpv
extra-x86-64-v3/mpv
extra/mpv
I explicitly installed extra-x86-64-v3/mpv at version 1:0.38.0-5.2 at some point, some time passes, I want to update my Artix.
I was kinda bummed when some of packages were pulled from vanilla repos even tho I installed the x86-64-v3, but it makes perfect sense, it's setup as it is above, and pacman simply adheres to it.
What should I do to update all my stock packages + update explicitly installed packages from the exact repo they are?
Because pacman -Syu will pull mpv 1:0.38.0-6 just as it should from world, not from extra-x86-64-v3 even when mpv 1:0.38.0-6
.1 is available. Now well, imagine that we setup several packages to be x86-64-v3, it'd replace all of those HP packages, because of the top-down priority, but the thing is, we're running Artix, it needs to be setup as it is in the OP post.
I tried searching for a solution, but scavenging for info on this somewhat hard due to people just simply gaslighting people into saying shit is unsupported/"you shouldn't do that" ;/
Any ideas?
@Shoun2137 I don't think you can achieve this automatically simply.
But there's things you can do to help with varying degrees of automation.
If you uncomment VerbosePkgLists in /etc/pacman.conf you get to see which repos packages are being pulled from on updates.
If you add the packages you want to come from extra-x86-64-v3 to IgnorePkg you'll get a warning when a upgrade is available and can then explicately install them from the repo you want.
You can create a pacman (libalpm) hook that triggers whenever packages you specify get updated and tells you to reinstall them from extra-x86-64-v3.
You can't unfortunately make the hook reinstall the packages automatically as until the pacman process exits its lockfile prevents it running again. (there is a convoluted way of getting round this but I've never managed to get this to work with sudo, only a root shell)
You can create a cron job (or possibly another hook) to run a script to manage a local repo containing only the packages you want from extra-x86-64-v3 and put it at the top of the list.
I have no idea with CachyOS but for ALHP there's an API (https://api.alhp.dev/) you can query for info about packges
This python function returns a dict of all the -v3 pkgbase's
def get_alhp_data():
resp = requests.get('https://api.alhp.dev/stats')
resp_dict = resp.json()
number_packages = resp_dict['failed'] + resp_dict['skipped'] + resp_dict['latest'] + resp_dict['queued']
resp = requests.get(f"https://api.alhp.dev/packages?offset=0&limit={number_packages}")
alhp_pkgs = resp.json()['packages']
alhp_pkgs = [pkg for pkg in alhp_pkgs if not pkg['repo'].endswith(('x86-64-v2', 'x86-64-v4'))]
alhp_pkgs.sort(key=lambda x: x['pkgbase'])
return alhp_pkgs
It would be nice if there was a simpler way, but to the best of my knowledge there isn't.
I've poked around for solutions, but those either turned to be very slow when trying to poll/organise packages, because you have to rummage through all of them to make sure those are actually v3/v4 manually so it's a shame this particular pacman dev doesn't care about actually basic stuff that should be on Arch from day one (https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/150#note_171225). With this feature, it'd be trivial to identify by just reading local pacman db file directly. As for CachyOS fork of pacman, yes, it'd be way easier due the patch above, but you have to install it before any v3/v4 package, so that it actually keeps track of what you install. If you do it after that, well, the damage is done, you don't have that info embedded in local db. Also you still need to write a wrapper of some sort that will update v3/v4 packages first, and then do normal update (and then aur at last) ;/
I didn't even try to poll by ALHP API because the effort required would outweigh all the pros for so little benefit, it'd also mean that you need internet connection just to verify what you actually run on your device... pointless and useless.
So sadly I can't recommend running v3/v4 packages on Artix simply due to the fact that it's really hard to track packages, if you plan to replace significant part of the system + most of the packages are linked against systemd so breakage is unavoidable. The performance difference doesn't make up for the effort. Thank you for the tutorial.
It's really not hard to check if a package in the local database is from Artix, Arch or ALHP.
As the discussion around the merge request you linked stated it's trivial to discover the organisation behind an installed package using the 'packager' field.
The point of accessing the ALHP API would be to check for updates to ALHP packages already installed locally and then download them and add them to the local repo. Which is going to require an internet connection anyway. To check the packager in the local database does not require an internet connection.
To the contrary most are not linked against systemd.
I enjoy playing around with this stuff.
This shows where my installed packages come from:
$ getdistro.py [18:11:34]
Statistics:
Artix 401 18.64 %
any 55 37.67 %
x86 91 62.33 %
re-compiled znver3
lto 240 94.12 %
O3 15 5.88 %
std 0 0.00 %
Arch 360 16.74 %
Alhp 1306 60.72 %
Mine 5 0.23 %
Unknown 79 3.67 %
Total packages 2151
Sometimes you have to make your own.
I have various scripts to help me.
But in the main I won't be sharing them on here as it's likely people will break their systems and then blame me no matter how many warnings I include.
Plus I worry that some of what I do personally could be seen as disrespectful to the Artix devs if I try and promote it. So I don't.
It is pointless when you add CachyOS repos to the mix, there's no API for that, when writing my script I went with generic local db probing instead.
Yeah, I did write a solution to that, I initially wanted to post it here, but it's just not worth the effort for so little performance uplift in my case and a waste of time waiting for tracking verification to finish so I just abandoned the idea without optimising it.
I don't know the lore around your work here, I don't think anyone would be offended by a python script, but meh, the world has become so fragile in recent years that I’ve simply lost faith in people
Don't add it into the mix then.
You lost me there ?
That makes two of us.
A sad statement, yet a sentiment I unhappily share. Though with the prefix 'many' people
so after adding their repos and installed some pkgs from there, I think it will be ok to use the vanilla version pacman instead of cachyos team's modded one, it looks like this :
:: Searching AUR for updates...
:: Searching databases for updates...
-> findutils: local (4.10.0-2.1) is newer than system (4.10.0-2)
-> fzf: local (0.55.0-1.1) is newer than world (0.55.0-1)
-> gsmartcontrol: local (1.1.4-1.1) is newer than world (1.1.4-1)
-> gvfs-gphoto2: local (1.56.0-1.1) is newer than world (1.56.0-1)
-> hdparm: local (9.65-2.1) is newer than system (9.65-2)
-> lld: local (18.1.8-1.1) is newer than world (18.1.8-1)
-> usbmuxd: local (1.1.1-4.1) is newer than world (1.1.1-4)
-> Packages not in AUR: cachyos-keyring cachyos-mirrorlist cachyos-v3-mirrorlist
-> Missing AUR Debug Packages: unzip-zstd-debug
-> Flagged Out Of Date AUR Packages: parabolic xnviewmp
there is nothing to do
So in my understanding, the pkgs from cachyos-v3 repo will always append .1 version to it, making it newer to the pkg from artix/arch repos. So as long as cachyos-v3 repo has this pkg built and ready first, I will always have this pkg updated from their repo?
have to put cachyos-core-v3 below [system],
and cachyos-extra-v3 below [galaxy],
otherwise they bring in systemd complaints , or segmentation fault
This is also partly a limitation of pacman to blame, if it's e.g. the exact same version number in both repos it will not be fetched.
To fetch these above packages run -Syyuu, pacman thinks it will "downgrade" them.
Alpine based distros just slap .9999 to ports for it to pass always :)
Tried to use pacfree with it's from which repo rules, now it works very nice for upgrading existing installed packages.
Just add rule for any package needs systemd to come from Artix world/galaxy etc repo instead of cachyos repos.
For installation of new packages, pacfree doesn't seem to respect the rules. So need either to use yay then select from which repo, or switch to a normal pacman.conf to install a big meta package, then switch back to cachyos repos and use pacfree to update and upgrade. This way any packge needs systemd will be blocked and packages don't need systemd will be fetched from cachyos repos.