Op ma 7 jun. 2021 om 10:01 schreef 'Kay F. Jahnke' via hugin and other free panoramic software <[email protected]>:
> Am 07.06.21 um 09:28 schrieb David W. Jones: > > > Sorry, I don't do flatpack or appimage. I've tried both with a couple of > > different apps, with complete lack of success, and no interest in > > figuring out why they didn't work. > > Harry's comment about using flatpack or appimage was not directed at > you, but simply stating the fact that these two methods of installation > avoid issues with incompatible or inaccessible libraries, because they > provide an environment where the necessary shared library infrastructure > is provided bundled with the installation medium. > > Indeed. I already had a look at an AppImage as I had made two before. In this case there is something with libc6 that need to be patched, where you normally use the lib6c from the system. aferrero2707 used that same patch for the Hugin app image, but I did not dive into it yet. As Kay mentions: using cmake to compile lux makes it now much easier. > > Doesn't compiling something to use static libs also include everything > > inside the app? > > It, does, but it produces enormous bloat. And if anything relevant in > one of the libraries changes, you have to recompile, redistribute, and > make all users reinstall. Linux has decided against this, and for good > reasons. > > Yeah, well. With a statically compiled binary you have everything in there that end users do not have on their system. So that's more space effective. For developers it is of course not, but they are less than 0,01% once a package really gets used by an end community. An AppImage or Flatpack is squash compressed. It delivers a 13~15MB release. Upon starting it is uncompressed to a tmp folder and is then ~40MB (and actually that should even be slightly larger with the extra patching). This tmp folder is of course removed when you close the app. When I compile lux on Debian, it is 18MB (!) and that is with uncompressed libraries even more. So actually a static binary or an AppImage or Flatpack (never did that one) is actually more space effective "all the time" for end users. And only when running the AppImage it temporarily takes slightly more space. Especially for those users who do not have the development installed, a static binary or AppImage is more space effective. On the other hand: Who cares nowadays with bigger SDs? My camera makes 14MB images and if I bulk shoot I have even up to 200MB of images for one sequence. A day of "bird shooting" gives me often 3~5 GB of images/videos (and afterwards mostly less than 1~2% remains). 4K movies from my camera are 250MB to >1GB (and I'm not even talking about persons who download movies or series up to 30GB) So who cares whether an app is 18MB (uncompressed lux), 13MB (compressed app image) or 35MB? I do think that AppImages (and Flatpacks) are indeed the way forward now that Linux more and more gets an "end user" platform. Next to that: I do have a Chromebook with Linux Beta on it. Every user can install that. I use it all the time (I hate fans in my laptops) and do all my development on that Chromebook in Linux Beta. The java app images I make and lux debs I make can simply be installed in that Linux beta (by default Debian but you can install any major distro). If Chomebook users (considering them even more as end users) start to use AppImages in Linux beta, makes it even more attractive to use these. But that's my personal view. Harry -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAGARPpsCbeTTbrgDHZ%2Bf_UQaFxMiXOUjT%2Buw70QjWz9Ot_%3DhTw%40mail.gmail.com.
