@nevel we built the vault Linux binary with musl libc so I’m hopeful this will work on something like a Rasberry pi - do let us know if this is the case if you get to try (I don’t have one to test with).
With the cli clients we hit some problems trying to build them with musl libc and we’ll need to spend more time on that, but definitely something on our to do list.
I just built the safe_authenticator_cli on a raspberry pi4, it works like a charm with the shared vault
Account was created successfully!
SafeKey created and preloaded with test-coins. Owner key pair generated:
Public Key = didyouexpectIwouldpastethis
Secret Key = andthistoo?
Exposing service on 127.0.0.1:41805
Not sure if this is related to the move to musl but on Debian 9 I got a GLIBC_2.25 not found error when running safe_auth. Fixed it by following the final post in this thread. Leaving this here in case anyone has similar issues.
The authenticator isn’t built with musl yet - only vault is for now. We have plans to remove a C dependency that is currently preventing us from building safe_auth and safe with musl, but we’re not quite there yet.
I think you will also need to compile for the ARM (v7?) processor architecture for Raspberry Pi etc. I’m trying to find topics on this atm. With Rust cross compilation this is fairly straightforward (famous last words).
Here’s one - I believe you can ignore all the stuff up front about libsodium now so it might be trivial!
I can’t remember but there may be other topics that I didn’t find. I’ll check my in notes in case they have more info.
@chriso update: I have a long page of notes which suggest I did get things linking although I can’t be certain. Also note that it was in the very early days. The notes include the following (I can PM them all if it might help):
Static libsodium build:
…/…/configure --enable-static LDFLAGS=-static --build=x86_64-unknown-linux-gnu --host=arm-unknown-linux-gnueabihf --target=arm-unknown-linux-gnueabihf
sudo make install
sudo ln -s /home/mrh/src/libsodium-1.0.3/target/arm-unknown-linux-gnueabihf/src/libsodium/.libs/libsodium.a /usr/local/lib
Any maidsafe examples built (with libsodium.a in /usr/local/lib) with have libsodium statically linked in and not need anything else to run on the target.
Dynamic libsodium build:
Honestly, this is a great feature not a bug. There is ABSOLUTELY NO NEED for the native vault code to be supported by the devs on Windows at this stage or any future time. The reasons for this are too many to list.
The virtual machine issue is separate, and I would be surprised that it isn’t working as usual on an Ubuntu host or debian host in something like virtualbox. Vault operators intent on using windows as the native host to try out SAFE software can then be directed to a debian or centos virtual machine on top of vbox, which are all FOSS. So Everyone is included and given an easy onramp, just in a more streamlined fashion that makes the development less of a hassle or induce other more serious bugs…
To summarize, I succesfully managed to build the vault, the safe-authenticator-cli and the safe-cli from git on the raspberry pi4, simply using cargo build
In order to satisfy dependancies I just had to apt install libssl-dev
The safe cli now gives me a sweet
Authorising CLI application...
SAFE CLI app was successfully authorised
Credentials were stored in whereithastobestored
With Windows making up 80% of the desktop OS market it would be mad to exclude it if the aim is to get as many vaults as possible operating in the shortest possible time. Most non-Mac-owning non-techies I know wouldn’t go anywhere near Linux or Virtualbox. It’s a huge additional barrier, even if arguably a psychological one.
It comes from experience. The host OS endpoint is the weakest link in the SAFE network. A late night Windows update leading to 80% of desktop vaults going offline is not acceptable. It’s why we will need SafeOS.
That wasn’t what I was suggesting. Not sure about you, but any windows machine I ever used suffered and glitched when updates are happening in the background until one or four forced reboots later. Anyway, you all win… I regret using CAPS.