Hacker News Reader

Comment by all2 | Hacker News Reader

Because Valve's target is deterministic (relatively, hardware revisions not-withstanding) pacman is actually perfect for their use-case.

You can nail down a new release on your local hardware using a bash script that calls pacman against specific packages and specific package versions. Once your local dev works, push that to the update tool. Hopefully you caught all the bugs. :)

View on HN

Surely Valve would be better served by having some immutable system partition and maybe even A/B image based updates?

We're about 2 years out from having that work with most packages though, aren't we?

I'm not convinced packages need to care. Most config users care about on a SteamDeck is going to be Steam or game specific, so Valve are in a good position to put that on some mutable partition.

For the system data, which could be immutable, they could either take an A/B approach with two different partitions, or perhaps use either btrfs or ZFS to allow the new version to be applied over the old version as a 'diff' of the system partition. On a failed update, or to rollback for any other reason the system partition would simply be rolled back to the last snapshot.

Valve (as they did with Debian based previous versions of SteamOS) will maintain their own curated repository of packages, so they can control the versions of packages directly, no need to mess about forcing versions via pacman.

You're one step away from the venerable buildroot. You get deterministic builds of complete OSs from the Linux kernel up.

Reply on news.ycombinator.com