Better compatibility for the binary release #1125
Description
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.
- 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
VSCodelike 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! - 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.
- 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-configuratorpkg 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.