A lot of ALARM core repositories are out of date, their extra repositories are even worse. chromium has been broken for like 1.5 year or so (I think it's fixed recently). Can't really blame them, they need to support older armv7 hardwares. Their packages are also for armv7 instead of the aarch64 architectures used by a lot of tablets/PC nowadays, so there's a huge performance/compatibility tradeoff they're making.
Arch linux aarch64 port is as the name says, aarch64 only, the people don't really care for older RPi. And because their work lives on the official arch linux repo, the pkgbuilds by definition won't be out of date. However package building are still community maintained, and will be out of date in that regards.
Cool! More digging to do. I used ALARM to build some rpi images, it worked really well but alas we ended up going back to the base rpi os (Debian) due to the rolling release schedule making reproducible builds more difficult. I’m still thinking through the conceptual correct solution for an appliance…
As much as I am an avid arch linux fanboy, I don't think it's a good choice for "an appliance", the frequent update might cause unnecessary wear and tear for the storage chips if they use flash memory/sd card.
Lazy me would often update pacman database and upgrade just a few packages. Living dangerously but often times it doesn't really matter
If reproducible build is important maybe consider NixOS?
steamos holo was the codename for steamos 3. this project is called holo core because its the core for a new steamos version that will run on aarch64. the fact that its shipping on a vr device first is just a coincidence.
valves long term plan is a big transition from x86 to arm for all their hardware, steam frame is the first one because its made for streaming first so people wont complain if some pc vr games dont run on device.
the main reason is they dont want to stay locked to amd. intel is technically an option but they have a history of bad drivers and treating linux as a liability. arm gives a license to just about anyone so the market is wide open and valve can even make their own silicon if they feel like taking on a challenge.
How does this compare to https://archlinuxarm.org/? I'm surprised to not see a reference to this prior art in the article.
Archlinuxarm is a fork. The name is confusing because it's a fork with the same name and logo, but they have got permission to do so
Arch linux aarch64 port is not a fork, it uses the same upstream PKGBUILD which contains minimal aarch64 specific conditional compilation and config
https://ports.archlinux.page/
I think even this project was not being mentioned so maybe they are not aware of each other
> Arch linux aarch64 port is not a fork, it uses the same upstream PKGBUILD which contains minimal aarch64
I was under the impression that that's what ALARM was. And that seems supported by https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/R... (and the small number of packages in that repo). Was I mistaken?
I posted about this here https://charon.konekopi.com/posts/archlinux_on_arm/
But to answer your question:
A lot of ALARM core repositories are out of date, their extra repositories are even worse. chromium has been broken for like 1.5 year or so (I think it's fixed recently). Can't really blame them, they need to support older armv7 hardwares. Their packages are also for armv7 instead of the aarch64 architectures used by a lot of tablets/PC nowadays, so there's a huge performance/compatibility tradeoff they're making.
Arch linux aarch64 port is as the name says, aarch64 only, the people don't really care for older RPi. And because their work lives on the official arch linux repo, the pkgbuilds by definition won't be out of date. However package building are still community maintained, and will be out of date in that regards.
Cool! More digging to do. I used ALARM to build some rpi images, it worked really well but alas we ended up going back to the base rpi os (Debian) due to the rolling release schedule making reproducible builds more difficult. I’m still thinking through the conceptual correct solution for an appliance…
As much as I am an avid arch linux fanboy, I don't think it's a good choice for "an appliance", the frequent update might cause unnecessary wear and tear for the storage chips if they use flash memory/sd card.
Lazy me would often update pacman database and upgrade just a few packages. Living dangerously but often times it doesn't really matter
If reproducible build is important maybe consider NixOS?
Arch Linux arm is great and collabora guys are great (thanks for mainlining rk3588).
I'm using this one for my desktop and it's very smooth for a passive cooling thing.
Holo Core vs Holo Lens, sometimes there is no imagination in naming.
steamos holo was the codename for steamos 3. this project is called holo core because its the core for a new steamos version that will run on aarch64. the fact that its shipping on a vr device first is just a coincidence.
valves long term plan is a big transition from x86 to arm for all their hardware, steam frame is the first one because its made for streaming first so people wont complain if some pc vr games dont run on device.
the main reason is they dont want to stay locked to amd. intel is technically an option but they have a history of bad drivers and treating linux as a liability. arm gives a license to just about anyone so the market is wide open and valve can even make their own silicon if they feel like taking on a challenge.
Steam frame exists, right?
Soon™