The progress that the steam frame will bring is more important than the steam frame itself.
The work they put into aarch64 will be really helpful for laptops, and potentially mobile devices. I am really hoping that for mobile phones, becauase the community that came from the steam decks popularity really made more community gaming focused fixes, and programs show up on github. There was life and hope that kind of encourages more people to give a shit or contribute to a community because they believe there is a community.
Fex is going to be the most important. Right now fex can be utilized to play red dead 2 at 720p 60fps on a midrange pocco phone. And that was from months ago when I last checked on progress. Even if we aren’t directly using arch on arm phones, fex itself can be used on Android which is still helpful.
This is great stuff and, though I’ve not much insight into Arch, I think a big contriubuiton back for the project/community.
That said, the Frame is the first electronics project in the last… 10 years? that I’ve been anticipating the release of, while theres lots of signs of life (more games Verified for Frame, more shipments) some of the news makes the realise itself feel very far away.
I’m well aware I’ve invested way too much, personally, in a product launch, but there’s no unwinding it now.
Same. It’s going to massively benefit handheld Linux gaming.
They, uh, didn’t even mention the ALARM project?
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
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.
Man, if it was that simple, ALARM wouldn’t exist and arch would have (at least) allowed aarch64 packages in the AUR years ago.
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.
Did ALARM have reproducible builds? They go into that in the article.
