Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider shell scripting as language #15

Open
mgord9518 opened this issue Feb 5, 2022 · 0 comments
Open

Consider shell scripting as language #15

mgord9518 opened this issue Feb 5, 2022 · 0 comments

Comments

@mgord9518
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant