this post was submitted on 17 Jul 2026
102 points (99.0% liked)
Linux Gaming
26837 readers
173 users here now
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
No memes/shitposts/low-effort posts, please.
Resources
Help:
- ProtonDB
- Are We Anticheat Yet?
- r/linux_gaming FAQ
- Fork of an earlier version of the above
- PCGamingWiki
- LibreGameWiki
Launchers/Game Library Managers:
General:
Discord:
IRC:
Matrix:
Telegram:
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It doesn't appear to rely on ALARM, does it? I haven't dug through the sources thoroughly yet, but I haven't see anything there that indicates they're using ALARM stuff.
Yeah, they jumped straight into reinventing the wheel for some reason. Alarm forums may be dead but the project and repos are still getting updates. Why spin your own shit?
What's there to reinvent? Upstream Linux software already builds for ARM.
Package repositories, recipes, and support paths
The existing stuff needs to be adapted, not reinvented. In my time as packaging some software for my own use under openSUSE I barely seen software that needed adaptions in the package spec file for other CPU architectures. Emulators were the most common exceptions I encountered and even that changed a lot since then thanks to upstreams porting those to Android and Apple M processors. Collabora lists as main challenges the ability to access the upstream source codes for reproducibility, not "repositories, recipes, and support paths".
Man, if it was that simple, ALARM wouldn't exist and arch would have (at least) allowed aarch64 packages in the AUR years ago. There are other factors in play than what I listed above, but it's still weird to not even mention the existing community efforts.
Reproducible builds are one step closer than what ALARM was already providing. It's cool, but it's still just one step up, and a rewrite. I don't understand why Collabora went in this direction aside from having more billable hours.
Arch's policy is to offer only x64 binaries. They don't offer ARM packages because they don't want to. ALARM exists because Arch does not want the contributions.
While it's not zero work, your claim of reinventing the wheel overstates what compiling software that's already compatible with ARM requires.
I'm reading what Collabora wrote and nowhere is that blog post did they state that compiling stuff for ARM and the packaging are the hard parts. They explicitly called out the reproducibility parts, not the rest.
If your small community project with dead forums and broken logs (see below) can do it, a team of full time Linux engineers can do it in a relatively small amount of time, probably with logs.
I was only concerned with why they didn't try and work with the existing community effort.
Did ALARM have reproducible builds? They go into that in the article.