Nightly Subsurface AppImage for most Linux distributions

Lubomir I. Ivanov neolit123 at gmail.com
Mon Nov 16 03:56:35 PST 2015


On 16 November 2015 at 01:20, probono <probono at puredarwin.org> wrote:
> 2015-10-18 14:14 GMT+02:00 Lubomir I. Ivanov <neolit123 at gmail.com>:
>>
>> let's say i have developed a rather big peace of CAD software (e.g.
>> 4GB) which is a small 10MB executable and next to it are many large
>> files (e.g. 200MB) which have a horrible AppImage compression ratio as
>> they are already compressed. the main executable loads these files as
>> libraries (let's say 3D meshes, textures, or schematics). i often make
>> updates to some of the 200MB files and wish to implement a
>> download-updates mechanic, which only touches some large library files
>> and possible the main executable.
>>
>> if an installation process to a RW location is not implemented in
>> AppImage i need to either re-package the whole bundle (4GB) for each
>> iteration or maintain some sort of a separation scheme for the main
>> executable and the libraries. again, on Windows this won't be a
>> problem because the download-updates mechanic will just work due the
>> the RW access of the installation folder.
>>
>> how would you approach this silly big CAD software example in a
>> portable OS manner?
>
> Sorry for having this found only now, but the PortableLinuxGames
> project has an interesting solution for this problem:
> https://github.com/RazZziel/PortableLinuxGames/wiki/Apps-that-require-writing-inside-the-AppImage
>
> (Some) "applications will insist on writing inside the application
> directory, which is impossible inside an AppImage, because they're
> just a read-only ISO image. (...) We can use a unionfs to let the
> application write as much as it likes inside the data directory, and
> redirect all the writes to another directory using a COW
> (Copy-on-Write) strategy."
>
> By bundling the unionfs-fuse binary inside the AppImage this just
> requires FUSE on the host system.

probono, thank you for the interesting article.

i'm not familiar with unionfs, but it did much better understand their
second method with symlinks which seems a bit volatile.

the unionfs-fuse method seems biased performance wise; i found this by
googling "unionfs-fuse performance":
http://www.linuxquestions.org/questions/linux-general-1/is-there-a-fuse-less-unionfs-4175521239/

"Now I got wind that there is only unionfs-fuse available for arch,
which as it's name says is based on FUSE as in user level unionfs,
which in turn means severe performance loss".

the only sane solution for me is to allow the user (Admin?) to install
the AppImage, if see fit. this ensure a properly working update
process and the most flexible package distribution. the two proposed
solutions are just "workarounds" like the author implies.

writing in the application directory is a bad model in general - the
user should only write in an user directory. but it has to be possible
for the administrator - when a software package is updated.

lubomir
--


More information about the subsurface mailing list