muep

It's indeed an inconvenience with developing with Flatpak, but assuming someone still wants to do it, here's what one can do to make it practical (as far as it can be):

Get your development tools as a flatpak runtime extensions

Try to do everything inside the flatpak'ed tool (so e.g. with VSCode, use the terminal built in it, rather than a separate one)

If you need some tooling from the host, you can bind-mount them in. Just note that they probably have to be somewhere outside /usr because that's where Flatpak mounts its usual runtime

Instead of desiring atomic maps, would it work here to give each task its own map and then merge those after the parallel processing has ended? I have have absolutely no experience of CUDA, so no idea how applicable that approach would be. However, it seemed pretty practical and effective when I tried a parallel implementation of this challenge on plain CPUs.

Oulu, a 200k town in Finland, claims to have 600 km. It still could do with some more bike paths and improvements to the existing ones, but it is at a level where almost all places are reasonably easy to access by bicycle.

E.g. Fedora has for years been using for RPi the same close-to-mainline kernel source that is used for other ARM boards and x86-64 and any other supported hw platform.