will not start

[funjspi]

When I try ./golemsp run I get this error:

-bash: ./golemsp: cannot execute binary file: Exec format error

Using a raspberry pi 3b. 64bit. is this written for 32 bit?

[adinetech]

No, it will only work in arm64 bit version of Pi4

[riccster]

I has a similar issue when I tried to run it on Raspian. When I tried on Ubuntu it was fine.

[MarijnStevens]

Some of the rust library requirements, and KVM support (I don't know but golem was pretty much Linux only at the time) was required and only supported (and I assume; instruction wise, still) under ARM64, forced the 64bit (READ: OS) requirement. However, the main point (at that time in 2021) for me, was to make an example of using other types of CPU's than x86_64, because (at the time) for a "virtual super computer", golem went for, I and somebody else wanted to provide some initial proof it could (and should) support arch-agnostic (x86/x86_64, or who knows, risk-v in the future? It was around the switch Apple made from Intel to ARM. It sounded like an awesome goal for the golem project. Not only increasing the value of the network, but also providing support for "obsolete" programs that still could be of value; running ON the golem network, without owning the hardware. Warning: COBOL

So the version I ran on my raspberry pi's (READ: both 3 and 4 versions) was the Arch distro build of linux for raspberry pi 3/4, that supports KVM (as default also).

However, the method Golem project uses to isolate the "compute+write to disk" program from the operating system (READ: because of security), is by running a headless version of the machine emulator, QEMU, and that is awesome, that emulator, it supports WAY more instruction sets than x86_64, see QEMU: Supported build platforms. After the initial booting of this emulating machine, it attepts to runs a version of Alpine Linux (AKA: Very small linux disk-wise (=but not busybox); I guess because of bandwith & ( Alpine Linux + program combined). Another part of that security, is isolation of disk space, as far as I know, they used a plan9 file-drivers for x86_64 in the Alpine image, that didn't exist for ARM64 Alpine image at the time, and so I ended up compiling my own (AKA: kernel upgrade+re-compile WHILE running ARM64 on a x86_64 machine... and eeeh.. I cant easily explain that to people, tl;dr: It was horrible).

However, it was pretty clear that it didn't work the other way around (I never assumed this; t.b.h, and also its not in line with the main goals for QEMU/Golem as I understood them; Your app takes 2 seconds to run on a 2Ghz x86_64 machine, but my ARM processor would take ... eeeh random guess, 5 minutes for the same task ? That would change the payment method), but QEMU is able to run x86_64 on ARM64, of course, slow; what wasn't the main point, but proved it could be agnostic in CPU instructions at least for the most part. So we got the x86_64 emulator working on our ARM64 processors. That worked for very simple programs (written in x86 or x86_64 instruction machine code)

@riccster I believe he is correct, there was an raspberry pi version of ubuntu that supported kvm as default for at least the 3 and 4 versions.

I tested this on a linux x86_64 machine running QEMU; running as BCM2837 (rasberry pi 3), using a disk image of arm-64-ubuntu; ran my repository under that (1 emulation level deep) and ran a task on the Golem's headless QEMU version to run an x86_64 task (2 emulation level deep). NOTE:: RBO64 didn't exist at the time.

To be clear: The goal was for always ARM64 programs to find ARM64 processors on the network, run the task, return the result, just like Golem already does with x86_64. (I had access to an s390x machine, so s390x programs for an s390x target machine, SPARC for SPARC targets, etc, t.b.h; feck it; PowerPC to PowerPC tasks, who cares ? If you don't have PowerPC hardware, but you want to run software for PowerPC, Golem could/should be a awesome solution to still run it, right ?).

Long story short, I did shared some task between our raspberry pi's, but they where little more than "hello world" and a "hacked" version of the calculate pi until 200 digits. (NOTE: both yagna runtimes had hacked versions to "find each other" on the network; We where unable to change upstream golem codes to append for this requirement). After that I tried to contact the developers (on golem's discord) to support an "arch" attribute in the job requirement, never had any support from them, (except from the community manager, Phillip (awesome dude in my opinion in the several m/h we shared), but if no code is merged; i'm pretty much useless).

The fact I suck at rust code didn't help at all, at that point I gave up, hopeful; but in the end; a failed attempt to flame a spark in other people to take over the touch and continue, some people made some PR and that helped; but to little too continue it in the long term.

The fact I responded 1 year later; the tl:dr explanation is life got in the way. As of this time I have no time to spend on Golem, and I really wished somebody would forked (and I asked in the discord about it) to take it over. But alas.