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 is going to sound ridiculous at first, but this is my rationale:
Max portability. Using shell scripting and an internal squashfuse binary (or a custom build with fuseless-extraction as a fallback?) allows not only for use on any Linux system of the same architecture, but any Linux system of any supported architecture. For small AppImages and those that use an interpreter or JIT runtime, supporting multiple architectures in one file may not significantly increase the size of the application. I did a little test building Pypy into SquashFS bundles, combining the x86_64 and AARCH64 installations increased the total size of the runtime by 60% in both ZSTD (30MB to 48MB) and LZ4 (42MB to 68MB). This change is not insignificant, but depending on the size of the project itself, it may change the total size very little.
Rapid development. Obviously once it gets to a mature stage, the language doesn't really matter as long as it works, but during early development, this would allow for much faster bug fixes.
Smaller codebase. I've created a PoC implementation of this that I'm calling shImg (shappimage), and the current runtime (comments included) is under 400 lines. After further optimizations and cleaning up have been done, I really can't see it getting much above 600 LoC.
Easy resource access. It's incredibly easy to embed a desktop files, SVGs and binary resources in a shell script using cat<<EOF and other tricks. These could also be safely extracted using a couple lines of code for desktop integration software.
The runtime has a speed penalty, my current solution is caching the extracted squashfuse in $XDG_RUNTIME_DIR. Using faster compression algorithms like LZ4_HC and ZSTD also significantly improve performance of the app, which easily make up for the slower runtime. These obviously have nothing to do with the runtime, but are both huge improvements over ZLIB. A build of another project of mine, aisap, which is just over 2MB uncompressed actually runs faster using shImg than the current standard AppImage with DEFLATE, and this difference very quickly scales with larger applications.
Once I clean up the code a bit, I'll further work on optimizing it, probably by adding a Perl section to do the parsing. Thanks in advance and let me know what you think
The text was updated successfully, but these errors were encountered:
This is going to sound ridiculous at first, but this is my rationale:
Max portability. Using shell scripting and an internal squashfuse binary (or a custom build with fuseless-extraction as a fallback?) allows not only for use on any Linux system of the same architecture, but any Linux system of any supported architecture. For small AppImages and those that use an interpreter or JIT runtime, supporting multiple architectures in one file may not significantly increase the size of the application. I did a little test building Pypy into SquashFS bundles, combining the x86_64 and AARCH64 installations increased the total size of the runtime by 60% in both ZSTD (30MB to 48MB) and LZ4 (42MB to 68MB). This change is not insignificant, but depending on the size of the project itself, it may change the total size very little.
Rapid development. Obviously once it gets to a mature stage, the language doesn't really matter as long as it works, but during early development, this would allow for much faster bug fixes.
Smaller codebase. I've created a PoC implementation of this that I'm calling shImg (shappimage), and the current runtime (comments included) is under 400 lines. After further optimizations and cleaning up have been done, I really can't see it getting much above 600 LoC.
Easy resource access. It's incredibly easy to embed a desktop files, SVGs and binary resources in a shell script using
cat<<EOF
and other tricks. These could also be safely extracted using a couple lines of code for desktop integration software.The runtime has a speed penalty, my current solution is caching the extracted squashfuse in
$XDG_RUNTIME_DIR
. Using faster compression algorithms like LZ4_HC and ZSTD also significantly improve performance of the app, which easily make up for the slower runtime. These obviously have nothing to do with the runtime, but are both huge improvements over ZLIB. A build of another project of mine, aisap, which is just over 2MB uncompressed actually runs faster using shImg than the current standard AppImage with DEFLATE, and this difference very quickly scales with larger applications.Once I clean up the code a bit, I'll further work on optimizing it, probably by adding a Perl section to do the parsing. Thanks in advance and let me know what you think
The text was updated successfully, but these errors were encountered: