Hacker News new | past | comments | ask | show | jobs | submit login

I actually like AppImage, even if it is slightly over-engineered compared to simple appdirs. It's a shame more developers don't actually publish them, and that not a single file manager that exists supports displaying their icons.

Still, AppImage is an attempt to bring sanity to the garbage fire of the Linux Desktop. I'd rather have a system that wasn't a garbage fire to begin with.




How does an AppImage handle shared library dependencies? Do multiple independent AppImages share the same mmap'ed library or do they each occupy their own in RAM? If there's no way to dedup the same dependency code between apps then memory usage can grow out of control pretty easily. Package-based distributions concern themselves with this a lot...


> If there's no way to dedup the same dependency code between apps then memory usage can grow out of control pretty easily.

You seriously say this in an era when Electron exists? You'd be hard pressed to waste more resources by simply not having deduped libraries.

> Package-based distributions concern themselves with this a lot

Yes, and they end up causing a lot more headache than they ever save because of it.


I don't disagree with you at all on principle here. What I'm genuinely curious about is if this approach is akin to "compile everything statically?" I'm assuming that, if so, the issue of memory use has obviously been raised and the response is akin to "memory is cheap now" so it's a bygone concern. That may all be true and totally worth it. I just feel compelled to ask having been accustomed to the shared memory mapping model for decades...


I still have no idea what the issue you have is.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: