Better compatibility for the binary release

[wucke13]

Hi, unfortunately iNAV doesn't run in my distro of choice out of the box. The issue is that iNAV ships as a dynamically linked binary, without some of the needed so files. While doing so is very common in the nwjs world, this hurts the compatibility. I have a few Ideas how this could be further improved, and I would like to get feedback on them.

1. Expose the iNAV gui via http optionally. This is very cool, because then it is very simple to build iNAV in any container and ship it that way. The container could be OCI/Docker, LXD, Systemd Nspawn or really whatever, almost all container technologies support tcp traffic from host to container. code-server is such a port for running a VSCode like editor in the web browser. I was really impressed how well it worked, and it is my main reason to believe that this is a viable step with only moderate changes involved!
2. Ship iNAV as snap, AppImage or Flatpak. This should resolve remaining issues with compatibility. I do not like this approach so much, as it requires actively choosing one of the aforementioned vendors.
3. Ship iNAV in such a way that it can easily be executed in the nwjs version which is shipped by the distro. This is what we do with the betaflight-configurator pkg in NixOS ATM - we extract all the files needed for running the configurator and run it with our nwjs packet. Unfortunately I do not know how to do this with the iNAV-configurator binary release, as it seems that most files are embedded in the ELF file itself, making it difficult to run it with an externally provided nwjs.

Please let me know what you think of the above mentioned. I would like to have a robust way of running iNAV configurator and I would prefer having a iNAV configurator package in NixOS. Please bear in mind that while the 3. point is specific to NixOS, the general issue is not, and 1. and 2. offer solutions which are not related to NixOS at all.

[skorokithakis]

I would be in favor of an AppImage.

[wucke13]

Appimage sometimes suffers the same issue with dynamic linking and implicit dependence on system libraries. However, if done correct, it works just fine!

[mmosca]

I did a quick attempt at this to add flatpack, but it is having issues with the arm binaries.

So, unless I find a way to make it work only for x86_64, it is unlikely that we will add flatpack support any time soon.