https://github.com/filecoin-project/bacalhau/issues/836
https://github.com/filecoin-project/bacalhau/issues/1661
https://github.com/filecoin-project/bacalhau/issues/1834
https://github.com/filecoin-project/bacalhau/issues/1835
linux/amd64 is a platform that will use amd64 CPU instructions and a linux operating system.Bacalhau currently has no knowledge of either job platform or node platform. Offiically, we say in the documentation that only the amd64 architecture running linux operating system is supported, although this is only because all of our officially-hosted compute nodes use this. If a user submits a job that can’t be run by a linux/amd64 compute node, the job can still be scheduled there and will fail at runtime.
In reality, the picture is a lot more complex. Docker imposes a variety of restrictions (same arch is required but different OS is possible) but WASM can be run on any architecture. So Bacalhau jobs and nodes can already be run on different architectures (see Raspberry Pi examples for a non-supported compute node) but this is more of a fluke than deliberate support.
Users do want to run jobs from different architectures. We have seen a number of examples (from our partners!) of people building their Docker iamges on an M1/M2 Mac running the arm64 architecture and then trying and failing to run these jobs on Bacalhau.
We also know there is interest in Bacalhau as a distributed test/CI system, which could run the same jobs across a wide variety of hardware installations. This will be impossible until we do architecture-aware job scheduling.
Platform is commonly assumed to be a combination of the operating system and CPU instruction set – so that a platform might look like linux/amd64. However the required “platform” can vary wildly depending on what sort of job you are running.
In Docker land, it’s possible for e.g. a Windows machine to support linux/amd64 and/or windows/x86_64. In WebAssembly land those strings make no sense, and you are more likely to see wasm32/wasi or wasm64/wasi.