fuse-3? #1120
Comments
|
Please install libfuse2 for now; systems like CentOS 6 and 7 still need it. As far as I know, no one has started working on (optional) support for libfuse3 so far. |
|
You could just |
The entire libfuse3 dynamic library weighs in at less than 250K on my machine (I would expect an even smaller size for libfuse2). The increase in size for each AppImage (assuming you only linked in the relevant function calls) seems absolutely trivial relative to the gains in user experience. Plus it solves your problem of having to switch later. Some distributions have started to get very strict about removing apps that link to unmaintained software (Python 2.7.x or Gtk+ 2.24.x, to name two), and I expect that those distributions won't even package libfuse2 by the end of the year. |
Then those distributions don't have a very backward/LTS compatible mindset. In my opinion, when a new major version of a library comes along, the last major version should be carried alongside at least until even the oldest still-supported LTS releases come with the new major version, plus some extra grace period. |
|
I don't mean to sound too argumenative here, but doesn't most LTS last about two years (people usually don't get that on many phones)? Libfuse2 has (already) died more than two years ago. Dead software doesn't have the number of eyes looking at it for potential security vulnerabilities, and distribution maintainers almost always have limited resources (and do always have demands that far exceed those resources). I can tell you that distribution packagers hate few things more that having to expend the effort required to maintain applications that demand deprecated versions of tools (and the tools often need patching themselves because other things have changed in the meantime). Some upstream developers will simply never upgrade if they can get away with it (I know software that still requires a version from the last millennium of a common tool). Why doesn't the project upgrade? I have no idea, but can only guess some combination of arrogance, ignorance, and laziness. |
Phones are clearly not our reference point. In fact, most phones become un-usable after just a few years due to them being abandoned shortly after they have been produced. I know people who are still running 10-year old desktop operating systems, ad I am typing this on a workstation that is over 10 years old and still working perfectly fine.
And that is exactly why we need something like AppImage that embraces backward compatibility to older systems. Many distributions simply don't care and that is a problem.
Caring about users who do not want, or cannot, upgrade their operating system every couple of years. In my personal optinion, distributions should continue to ship the |
So would not requiring libfuse at all, and placing the function calls needed directly in each AppImage.
That seems specious to me. Distributions often have limited resources (and requests from users to add additional packages). Attempting to include deprecated libraries (especially those where the discovery of security flaws makes that more difficult) places a tremendous load on those resources. When the developer of a library moves to a new (and incompatible) version, application developers who continue to use to old library force every distribution that includes that application to do extra work. Eventually that becomes quite selfish (although libfuse2 remains recent enough that I don't mean to include applications that link to it in that description). |
True, unless we still need to invoke commands like
Maybe the sweet spot would be to carry (and co-install by default) the current-1 major version, and deprecate it thereafter. Something like that. So that there is an overlap in available major library versions in all distributions (from Enterprise/LTS to bleeding edge) at any point in time. But I suspect that this kind of thinking may be alien to many distributions. Well, in pragmatic terms, I think we should try what @TheAssassin has suggested: If this doesn't work, we can always think about not requiring libfuse (and |
|
@probonopd what do you mean with using I'm kinda interested in a static version of |
|
squashfuse is used, not fusermount it seems |
|
Doesn't |
|
I think |
|
Yeah, one way to figure this out is by running |
|
I quickly looked into this, but the latest tagged version of squashfuse doesn't play well with libfuse 3 (apparently @TheAssassin's patches were upstreamed to Debian for the libsquashfuse0 package -- stuck on the same version then); meaning that most people likely use libfuse 2 anyways. I've created an issue in that repo to ask them to release a new version: vasi/squashfuse#50. |
|
Actually there is a licensing issue when you statically link libfuse, because it is licensed LGPL. |
|
Static linking sure isn't the way to go. I wonder why this licensing issue was found just now, not a couple days ago. I think this is the perfect opportunity for some polymorphy. The strategy pattern comes into my mind, but since this is pure C, well... I guess a struct containing function pointers is going to have to do. We just need 2-3 functions in such an API, wrapping libfuse2 and libfuse3 respectively. A factory can initialize a struct accordingly, preferring libfuse3, but falling back to libfuse2 if needed: #include <stdio.h>
#include <assert.h>
typedef struct {
int (*mount)(char*, ...);
int (*unmount)(char*, ...);
} fuse_handler_t;
fuse_handler_t* make_fuse_handler() {
return NULL;
}
int main() {
fuse_handler_t* fuse_handler = make_fuse_handler();
assert(fuse_handler != NULL);
fuse_handler->mount(...);
/* wait until app in AppImage terminates */
fuse_handler->unmount(...);
}Such a FUSE handler could even hold some state, if needed. |
|
Pardon my ignorance, but do you really need to call directly into libfuse in AppImageKit at all? Isn't everything handled through SquashFUSE? SquashFUSE 0.1.104 supports both libfuse2 and libfuse3, and the master branch (which is hopefully tagged soon) adds Maybe squashfuse can be improved a bit to add support for using dlopen to load either libfuse2 or libfuse3 instead of fixing that at compile time. |
|
squashfuse is compiled in. |
|
We use a specific version of squashfuse, patched to load libfuse with |
|
There's currently some active development in squashfuse, I don't think it's a lot of fun to maintain those patches or stick to a fixed vendored version (also for me, cause I want to build an optimized runtime.c in spack without vendored deps (e.g. i want to use the latest zstd for compression)). Wouldn't it make more sense to just open an issue in the squashfuse repo about this use case? The facebook |
|
They are unfortunately not interested in supporting fuse and fuse3 at the same time |
|
Another tool from the AppImage ecosystem, https://github.com/vinifmor/bauh/, is also offering to be used with fuse (2) and fuse3. Unfortunately it's written in Python, and therefore uses an abstraction that could not be reused here. What is blocking us here from offering both, the dependency on squashfuse and having to use dlopen? Two comments from the linked thread stand out:
seconding the argumentation from @2011 .
providing a suggestion which could maybe work here, too? Please note that the error message displayed in the OP will also be sent as a notification to GNOME, and with the `journalctl --user -u appimaged.service | grep 'restart counter' | tail -n 50` |
|
I have a suggestion, introduce a vulnerability in fuse2 to make everyone migrate to fuse3. |
|
Steam on Ubuntu 22.04 requires fuse3 for xdg-desktop-portal. This seems to make it not really possible to have both Steam installed and use AppImages on the same system unless I am missing something. It's not this projects job to support all environments, but worth noting that an incompatibility with one of the most popular apps in Linux will make using AppImages a non starter for many. |
|
Are you saying fuse2 and fuse3 cannot be installed at the same time @pkkid? What happens if you do? AppImages require fuse2 to be installed and configured. |
|
In Ubuntu 22.04 it doesn't seem to let me install both. I have 22:03:42 pkkid-ubuntu ~: sudo apt-get install fuse
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
libfuse2
The following packages will be REMOVED:
fuse3 xdg-desktop-portal xdg-desktop-portal-gtk
The following NEW packages will be installed:
fuse libfuse2
0 upgraded, 2 newly installed, 3 to remove and 11 not upgraded.
Need to get 0 B/117 kB of archives.
After this operation, 1,120 kB disk space will be freed.
Do you want to continue? [Y/n] |
|
I think it would be easiest to just statically link libfuse; it should be OK with MIT being a compatible license, and it just affects the runtime. At the end of the day libfuse is a fancy way to execute |
|
https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041530.html:
Argh. Trouble is to be expected. This means that all existing AppImages will not run on Ubuntu unless the user manually installs libfuse2 from a non-default official repository. Something that is too difficult for "normal end users" to do.
Distributions often blindly assume that users are updating everything to the latest versions of everything all the time. Which is not how I see things. Once I have a version of an application that works well for me the last thing I want is to be forced to update it. (At most, I download the new version in addition to the known good one to check out the new features and check for new showstoppers.) If I understand it right, it Looks like https://github.com/eth-cscs/spack-batteries-included is providing a solution for this. Should we backport these changes into the AppImage runtime? |
This sounds supremely sensible :) |
|
Ubuntu 16.04 is long EOL, even 18.04 is hitting EOL in ~1 week. Meanwhile, AppImages don't run on Ubuntu 23.04 out of the box: https://www.omgubuntu.co.uk/2023/04/appimages-libfuse2-ubuntu-23-04 It sounds like static runtimes are the long-term solution, but right now AppImages are failing to launch in recent distros (silently if not ran from a terminal!) |
|
Yes. On archlinux it needs to manually install |
Or, in most of the cases, you can just remove libstdc++.so.6 and libgmodule-2.0.so.0 from the AppImage file |
|
@probonopd Here's the situation My OS: Debian unstable
What can i do in this scenario? |
|
|
|
@probonopd thanks a lot! it helped |
|
so, if as of today I want to provide an appimage that will work from, say, ubuntu 18.10 to 23.10, and does not require the user to run apt install manually, what are my options? |
|
That should be doable by using a statically linked AppImage runtime, e.g., https://github.com/AppImage/type2-runtime. |
|
But people have to be aware that older (existing) AppImage will still require libfuse2 unless they are altered to use this statically linked runtime. |
|
sorry, I should have been more clear, it's not too clear for me how to instruct AppImageKit to use this new runtime ? or do I have to do it manually |
|
If you are using Once @TheAssassin gives green light, we will change the default behavior to use the static runtime automatically. |
|
I see. I'm not using linuxdeployqt - I do this : https://github.com/ossia/score/blob/master/ci/appimage.build.sh#L25 is the runtime the AppRun file ? The steps would be
Or are more things invlved |
|
No, the runtime is not the AppRun file. And I meant So instead of this you need to download the new one from https://github.com/AppImage/appimagetool/releases/download/continuous/appimagetool-x86_64.AppImage, and you also need to download https://github.com/AppImage/type2-runtime/releases/download/continuous/runtime-x86_64. Then, instead of you need to use (If you think we should make this easier - I think so too. Once @TheAssassin is ready for it, we will make that runtime the default in the new appimagetool, and recommend the new appimagetool instead of the one in AppImageKit.) Hope this clears it up! |
|
thanks a lot! this is great and exactly the explanation i needed |
|
super, just in case there is a typo in the command, I think it should be instead of |
|
Of course. Correcting above. Thanks! |
This change allows the AppImage to run on systems that don't have FUSE 2. AppImage/AppImageKit#1120
I found nothing in the documentation mentioning version 3 of fuse, but do note that fuse-3.0.0 arrived in 2016, and the (dead) version 2 has seen no releases in more than two years. I don't understand why you still use version 2.
In searching through issues before making this post, I noticed somebody suggesting that you include (the relevant parts of) fuse in the AppImages. I heartily endorse that idea.
The text was updated successfully, but these errors were encountered: