You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This isn't an urgent matter at all, I'm just posting for future discussion.
Is your feature request related to a problem? Please describe.
Problem: Distributing software for Linux platforms has always been painful compared to Windows and Mac. There are 2 conventional methods:
The developers offers source code and the user has to build it.
This approach burdens the developers the least (in a sense) yet can cause the user much trouble. Missing libraries, outdated toolchains...you name it. Uninstalling and updating the software can also prove to be difficult.
The developers offers the binary package and the user installs it via comands like apt install
Users can still counter dependency issues but it should be much milder than the troubles from building the source. This method also allows incremental updates. This time the headache is the developers', as different Linux distributions use different packages, for example .deb packages cannot be installed on RPM-based distros and vice versa. Adding to the confusion, even distros using the same package formats might not be able to use the same package. RHEL and SUSE are both RPM-based but their RPMs are different, for instance. This method requires the developer to maintain the packages themselves -- they'll have to choose between either diverge significant effort to maintain packages for each Linux distro, or focus on a small range of distros and leave users of other platforms to build the software from source.
Describe the solution you'd like
Enter the concept of Universal Apps, where the developers bundle their code and dependencies in an sandboxed package and the user can safely run/installed these ready-to-run software without worrying if their OS might conflict with the software. I recently had a taste of Universal Apps as a user and I think these 2 solutions feel pretty nice: Flatpak and AppImage. A user can easily install a Flatpak software by first installing flatpak (like sudo apt install flatpak) then running flatpak install <software_source_repository> <software_name>, whereas AppImage software is simply one execuatble file that can be launched by chmod +x <software_name>.Appimage (if the file doesn't have the execute permission) then ./<software_name>.Appimage. In both cases, the developer needs to maintain only 1 single binary package, period. Flatpak allows for incremental updates, and I think Appimage is starting to do so too.
Describe alternatives you've considered Docker can definitely do the job -- OpenFPGA is already offering Docker images. But Docker might be overkill and still a bit complicated.
Snap is practically Canonical's counterpart of Flatpak, except Canonical completly controls the Snap platform much like how Apple controls App Store (we cannot distribute snap packages without uploading them to Snapcraft and have Canonical review our requests). In contrast, flatpaks can be hosted on our own repos.
Additional context
There are a few potential setbacks of Universal Apps.
Performance and size. Compared to conventional methods, Universal Apps tend to take more disk space, as they rely on bundled dependencies, instead of reusing what the OS already has. Universal Apps also seem to suffer from performance penalties, though I don't think either of these issues are of big concern for our GUI.
Worth the effort? Building an Universal App isn't exactly a cakewalk, especially when all of us lack the experience and have other priorities. If FOEDAG ends up mostly being used by FPGA companies to be the foundation of their own software suite, then offering it as an end-user-oriented Universal App might not make much sense. Besides that, a sandboxed FOEDAG might have trouble interfacing with EDA backends, but my grasp of Universal Apps is too thin to be sure right now.
The text was updated successfully, but these errors were encountered:
Interesting technology. We definitely have to worry about both the GUI and the actual compiler (OpenFPGA, etc...) deployment on Linux systems, Windows, and MAC.
For most FPGA providers using FOEDAG as their baseline GUI Framework, the final GUI shipped to customer cannot be open-source, it has to be pre-built since it will also contain some code that is proprietary (Extra features/widgets beyond the open-source FOEDAG version).
The Compiler stack needs also to be pre-built and shipped, not just the GUI, it contains Intellectual Property related to the FPGA fabric by the given vendor, plus potentially "secret-sauce" in the Compiler beyond the open-source version.
For that reason, thinking of a deployment mechanism that facilitates binary distributions on all major platforms is of high interest.
This isn't an urgent matter at all, I'm just posting for future discussion.
Is your feature request related to a problem? Please describe.
Problem: Distributing software for Linux platforms has always been painful compared to Windows and Mac. There are 2 conventional methods:
This approach burdens the developers the least (in a sense) yet can cause the user much trouble. Missing libraries, outdated toolchains...you name it. Uninstalling and updating the software can also prove to be difficult.
apt install
Users can still counter dependency issues but it should be much milder than the troubles from building the source. This method also allows incremental updates. This time the headache is the developers', as different Linux distributions use different packages, for example .deb packages cannot be installed on RPM-based distros and vice versa. Adding to the confusion, even distros using the same package formats might not be able to use the same package. RHEL and SUSE are both RPM-based but their RPMs are different, for instance. This method requires the developer to maintain the packages themselves -- they'll have to choose between either diverge significant effort to maintain packages for each Linux distro, or focus on a small range of distros and leave users of other platforms to build the software from source.
Describe the solution you'd like
Enter the concept of Universal Apps, where the developers bundle their code and dependencies in an sandboxed package and the user can safely run/installed these ready-to-run software without worrying if their OS might conflict with the software. I recently had a taste of Universal Apps as a user and I think these 2 solutions feel pretty nice: Flatpak and AppImage. A user can easily install a Flatpak software by first installing flatpak (like
sudo apt install flatpak
) then runningflatpak install <software_source_repository> <software_name>
, whereas AppImage software is simply one execuatble file that can be launched bychmod +x <software_name>.Appimage
(if the file doesn't have the execute permission) then./<software_name>.Appimage
. In both cases, the developer needs to maintain only 1 single binary package, period. Flatpak allows for incremental updates, and I think Appimage is starting to do so too.Describe alternatives you've considered
Docker can definitely do the job -- OpenFPGA is already offering Docker images. But Docker might be overkill and still a bit complicated.
Snap is practically Canonical's counterpart of Flatpak, except Canonical completly controls the Snap platform much like how Apple controls App Store (we cannot distribute snap packages without uploading them to Snapcraft and have Canonical review our requests). In contrast, flatpaks can be hosted on our own repos.
Additional context
There are a few potential setbacks of Universal Apps.
The text was updated successfully, but these errors were encountered: