this post was submitted on 24 Feb 2025
15 points (94.1% liked)

Linux

8409 readers
439 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago
MODERATORS
Ategon@programming.dev
anzo@programming.dev
dwraf_of_ignorance@programming.dev
15
appimage portablility across machines (lemmy.today)
submitted 4 months ago by neatobuilds@lemmy.today to c/linux@programming.dev
33 comments fedilink hide all child comments
 

Hi everyone, I have been getting back into photography lately and switched to using linux full time about a year ago.

I ended up deciding to use digikam as my photo library management tool and then edit in darktable. both applications I decided to use the appimage for easier use and to have the necessary dependencies to get things like opencl to work, (I had a hard time getting it to work with the .deb)

now I also use multiple machines and recently learned that you can create .home and .config folders for each appimage to have all their settings etc save there, and it seems that this would make it pretty portable.

would it be a bad idea to for example keep the appimages and their folders in a synchronized folder like with nextcloud to use the same* appimage across machines. I never have the same machine on at a time but it would be nice to have all the settings sync'd but im not sure it would then break something since two machines use nvidia gpus and the other uses an amd gpu

you are viewing a single comment's thread
view the rest of the comments
[–] neatobuilds@lemmy.today 1 points 4 months ago (1 children)

Thank you, it seems every way I go i make the wrong choice lol

[–] Samueru_sama@programming.dev 2 points 4 months ago (1 children)

Thank you, it seems every way I go i make the wrong choice lol

Welcome to linux.

What you were told about appimage depending on legacy stuff is also not true, it is the libfuse2 dependency, which hasn't been a dependency of AppImage for 3 years (though some projects haven't updated yet).

It also isn't a big deal if you run into an appimage that still depends on it, archlinux which is a rolling release distro, some of its packages like mtpfs and ntfs-3g still depend on libfuse2 as well. And you can still run the AppImage by setting the env variable APPIMAGE_EXTRACT_AND_RUN=1 to avoid having to install libfuse2 in those cases.

[–] neatobuilds@lemmy.today 1 points 4 months ago (1 children)

maybe you can help guide me, I borked my video drivers on my desktop trying to get opencl to run on darktable with my 7900xtx gpu on popOS

I guess popOS just has older drivers or something and following guides on how to update led me to getting videos to stutter all the time now so Im planning to do a fresh install, would you recommend another distro that might have its drivers more up to date? I am thinking of trying out fedora as I heard that updates much faster than popOS

[–] Samueru_sama@programming.dev 2 points 4 months ago

Unfortunately because PopOS is based on debian/ubuntu, they tend to split packages into a million pieces, so something that would have a simple pacman -Syu mesa vulkan-radeon on archlinux to get the video drivers is like 6 different packages on debian which I don't know the names of.

Fedora is the testing ground of red hat, they are known for pushing a lot of breaking changes constantly, even more than Archlinux or other rolling release distros. A while back they pulled this nonsense that we had to deal with that not even upstream approves of.

So my only distro recommendation is archlinux or some archlinux fork, every time I have had to help people with distro issues they all eventually ended up in arch because all other distros have some weird issue that's a deal breaker. Just don't rely too much on the Aur.

My other suggestion is that you get most of your software as appimage thru AM: https://github.com/ivan-hc/AM

We ship Steam as an AppImage with a lot of common fixes that affect the flatpak version or native versions of steam (you can check them in the readme), and you don't have to deal with the hassle of setting up the 32bit repo and installing Steam for example.