Since the SDK is kind of a pain to get running on Linux distributions like NixOS [1] I've been working to make the SDK available as a package, which works fine so far with just one remaining problem: The "Disk" directory is inside of the SDK directory, which is located in a read-only file location, hence my wish to somehow have this either configurable or to at least respect free desktop standard directories for such things like (env) "XDG_CONFIG_HOME". This probably also affects other SDK packaging efforts since usually application files in Linux are stored in directories the user does not have write permissions for.
I've been thinking of how we can package up the Sim on linux to make it work better with standard install paths. However, as you've noted, standard install locations are read-only so it causes issues. I have some ideas and ultimately would like to get it put together as a flatpak but it's a low priority at the moment. Really, the entire SDK folder needs to be writable if users would like to hack on the sample code, etc, so just moving Disk into a writable location isn't a full solution.
I feel like as far as the "standard approach" for something like example projects go, you either put them on a git repo and people pull them down or well just copy them out of the associated directory I don't think the average Linux user would expect you to be able to edit them in-place anyway and while I'd appreciate a Flatpak this would not solve this issue either.
My current idea would be on first launch, it would ask for a writable location to copy the SDK folder to which would allow the user to put it in their desired location instead of dumping it into .config or whatever.
Ah yeah XDG_CONFIG_HOME isn't the right place for this i guess, although XDG_DATA_HOME would probably be better, although this is merely a suggestion.
To make it possible for us to package the SDK for package managers there has to be a way to change the location of "Disk". Since NixOS does not support the Unix FHS the SDK will not work there OOB either way (a lot of things don't) which is why I'm so keen on packaging the SDK myself