Don't use Appimages (a writeup about all the reasons they are a pain for users)

Appimages totally suck, because many developers think they were a real packaging format and support them exclusively.

Their use case is tiny, and in 99% of cases Flatpak is just better.

I could not find a single post or article about all the problems they have, so I wrote this.

This is not about shaming open source contributors. But Appimages are obviously broken, pretty badly maintained, while organizations/companies like Balena, Nextcloud etc. don’t seem to get that.

penquin,

I don’t use app images of flatpaks. I don’t like either.

spacebanana,
@spacebanana@lemmy.world avatar

Static binaries, or dynamic binaries whose project has documentation on what dependencies they need, are better than appimages. This is because appimages are a container with the actual files inside, creating a layer of abstraction, and appimages require libfuse to work.

Imagine the case in NixOS, where dynamically-linked binaries don’t work out of the box. You can patch or package these binaries, or just quickly use something like steam-run to emulate traditional Linux bin and lib paths, it works. With appimages, it won’t work unless you already have libfuse in your system, so you have to extract the appimage first.

Still, flatpaks as the only official alternative isn’t great for many reasons, and CLI/TUI programs are out of the equation. What is better is the devs distributing unpackaged binaries, jars, etc, and optionally flatpaks. Either way, Nix’s repository is huge so I don’t usually feel the need to run anything that isn’t a nix package.

tigerjerusalem,

Appimages are awesome for the regular user. Single file, just double click to run anywhere. Snap and Flatpak should die a quick death and all the work should be used to improve Appimages. There’s no other concept for the end user as simple and clear as this.

Yubishi,

They mimic the apple application format to some degree and it is a great way to distribute. The real detriment is sandboxing but with more support this could be included.

iopq,

I double clicked, the program didn’t run because it’s missing some dependencies

Pantherina,

No it is not. Appimages are bad.

youtube.com/watch?v=4WuYGcs0t6I&t=456

Watch that talk. And also read the text I guess. Also comments under other comments.

Appimages are seriously broken

Kusimulkku,

AppImages as a universal packaging format seem fun in that I’ve had loads of issues getting them to run properly on different systems. I’m sure they’re handy for some stuff but haven’t personally enjoyed them.

thingsiplay,

AppImages are great and easy to use and they can be very easily archived. Today I tried to archive a Flatpak package (yuzu) and it was a pain, complicated and gave up in the end. I end up archiving multiple versions of the AppImages and continue using the Appimage for this emulator. Also sometimes Flatpaks do not work correctly, and I (and any other user) have to figure out what settings and configuration, rights and other stuff is needed to setup with Flatseal. Recently I solved the open links issue with Flatpaks, and found out a certain portal was required to be installed. Also sometimes the theming is not correct too.

All in all, I use Flatpak still and AppImages too, each for their own reasons. The lack of repositories and not needing an installation for being functional is not a problem with AppImages, because that’s the entire point of it. They can be automatically generated and ready for download, regardless of any repository, directly on Github from the developers. There is even a program, RPCS3 (a ps3 emulator), which can check and update itself and list all changes since last update.

If you download AppImages from shady places, then off course its shady and insecure. Just like installing any software without knowing what you are doing is insecure. So that’s not a point against the format itself. The argument “Duplicated libraries” is hilarious, if we speak about AppImages vs Flatpak, because Flatpak has duplicated drivers (especially with Nvidia, I know how bad it is because I had Nvidia cards before) and desktop environment versions, just because certain versions of the application needs it.

I don’t understand these evangelism for packaging formats. Flatpak, AppImage, native system packages and other formats have their own uses and are all useful and not bad.

Pantherina,

What do you want to achive with archiving, because of a potential takedown by Nintendo?

Just for your purpose you could just keep it installed and probably block it from getting updated. I am sure you could also backup the .flatpak file somehow, and all the dependencies would still be accessible.

flatpak runtimes are pretty bloated, when you use different versions etc. And its bad that you cant only use Flatpak, currently. But locally they use deduplication, so GNOME, KDE and Freedesktop.org will share at least some libraries.

But for sure, it may not be the best library management there is.

Its not evangelism, there are developers that thinl Appimage is an acceptable format and only support that. I dont know but guess some licenses prohibit user repackaging as Flatpak, so you have to stick with that pain.

thingsiplay,

The deduplication is only for one specific version, even if its installed on my operating system already. AppImages do not include the entire KDE system. And Flatpak will install multiple versions of drivers (Mesa in example) and other dependencies. While this is exactly what Flatpak was designed for and there are good reasons for, it is important to understand that was counter arguing your argument against AppImages for being bloated. Both approaches are good in their own way, depending on what you want or need.

The backup of Yuzu Flatpak was just a current example why someone would want do that. There can be any reason to backup specific software versions, which is not the topic of today. The topic is, that with Flatpak its a mess to backup and restore. Yes, you can copy the configuration and installed binary files, but that does not work on any other computer. You can backup the key and other important files as well, but then its complicated to restore them as well, that I just gave up. It’s probably not impossible, but not straight forward; a bad user experience.

Meanwhile I can just download an AppImage and copy the file and its archived. Done. In multiple versions. No extra software, knowledge or complicated dance to do this very simple and important task.

Pantherina,

Good points.

Montagge,

Flatpak is bloated monster that has no idea how much it has to download to update. I’ll take AppImage over flatpak if I can.

Kusimulkku,

I’m confused. You call flatpaks bloated but AppImages have to bundle everything with them and there’s no dedupping or sharing libraries between them, unlike with flatpak. Unless the devs assume you have certain libraries and certain versions of them, which kinda ruins the point of AppImages. How come you think flatpak would be more bloated than AppImages as a packaging format?

has no idea how much it has to download to update

That’s actually the dedupping stuff in action. It knows you might need this much at maximum, but realized you only needed to download a lot less since you already had most of it downloaded beforehand. It’s funny but I can’t see it as a big issue tbh.

spacebanana,
@spacebanana@lemmy.world avatar

Appimages come with the library dependencies, flatpaks come with that + multiple versions of the runtimes and drivers. Flatpaks make the most sense if all you use it’s that, otherwise you will have 5 different versions of mesa, gnome runtime, video codec libraries and other runtimes for little reason.

Kusimulkku,

When you’re talking about bloat you meant when using just one or at best a few apps and otherwise using repo packages? I was more thinking as a replacement for repo stuff, with 5+ apps. The more you have flatpaks the better the advantage of them over AppImage would be with dedupping and shared runtimes.

The dedupping works between different runtimes and whatnot too btw. So two versions of gnome runtime don’t actually use all that space they claim they do, just what has changed between them.

Not to mention the savings when it comes to download size over time. Unless they’ve made some delta download system for AppImages, which would be pretty cool.

Montagge,

laughs in download 113.4MB/<9.4MB

Kusimulkku,

Can’t say I’ve bumped into that one. I wonder what could cause it. Downloading less makes sense, it might not know right away what parts you already have but downloading more, dunno

Pantherina,

Flatpak has a good package manager?

Read the other comments etc. No motivation to repeat everything

rotopenguin,
@rotopenguin@infosec.pub avatar

It would be nice if there was a way to bundle up a flatpak that was at risk of disappearing

Pantherina,

I think this is possible, just install it for now. There are .flatpak files

d3Xt3r, (edited )

I’m a Flatpak user myself, but a lot of those arguments against AppImage are outdated or invalid. Here are my counterpoints:

Usability issues

GearLever solves all the problems mentioned.

Updates

There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don’t want to use GearLever, there are other updaters like AppImageUpdate.

The lack of repositories
Appimages don’t even have a central place where you can find them, not to mention download them.

This is blatantly wrong - AppImageHub exists for this very reason. There are also GUI frontends like AppImagePool which makes it easy to discover/download/install them.

Lack of Sandboxing

That is a fair point, however, AppImage never claimed to be a sandboxing solution, and for some use-cases this can even be seen as an advantage (any Flatpak user would’ve at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes). But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you’re actually running an untrusted app.

Random location
[…] A necessary step would be mounting the entire /home non-executable. This is no problem for system apps, or Flatpaks, but where do you put Appimages now?

There would need to be a standard directory to put such files in, which is normally the PATH. But this is also the easiest attack goal for malware, so PATH would be non-executable as well.

I completely disagree with making the entirety of /home as non-executable, when $HOME/.local/bin is recommended by the XDG standard as a place to store executables. As long as $HOME/.local/bin is in the XDG spec, I’ll continue storing my executables there. If you disagree, go argue with the XDG guys.

Duplicated libraries

This is a fair point but “they include all the libraries they need” is the entire point of AppImage - so mentioning this is pointless.

If users would really install every Software as Appimages, they would waste insane amounts of storage space.

Then it’s a good thing that they don’t right? What’s the point of making hypothetical arguments? Also, this is 2024, storage is cheap and dedicating space for your applications isn’t really a big deal for most folks. And if storage space is really a that much of a concern, then you wouldn’t be using Flatpak either - so this argument is moot and only really valid for a hypothetical / rare use-cases where storage is a premium. And again, in such a use case, that user wouldn’t be using Flatpaks either.

Finally, some distros like Bazzite already have the above integrations built-in (GearLever/AppImagePool), so you don’t even need to do anything special to get AppImages integrated nicely in your system, and there’s nothing stopping other distros adding these packages as optional dependencies - but it’s kinda moot at this point I guess since Flatpak has already won the war.

Personally, I’m pro-choice. If AppImage doesn’t work for you, then don’t use it, as simple as that. Stop dictating user choice. If AppImage is really as bad as you claim, then it’ll die a natural death and you don’t have to worry about it. What you really need to worry about is Snap, which has the backing of Canonical, and some dev houses new to the Linux ecosystem seem to think packing stuff as Snap is an acceptable solution…

Pantherina,

GearLever](github.com/mijorus/gearlever) solves all the problems mentioned.

Sceptical but I will try it for sure.

It makes appimages less worse than Flatpaks though, so its only “badness reduction” for me.

There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don’t want to use GearLever, there are other updaters like AppImageUpdate.

The first is what I mentioned, such updates can be perfectly done by a central package manager. Did you ever try to seal off a Windows install using Portmaster, where every installed app needed network access for their individual update services? Just no…

Ans to the repos, yeah maybe, havent looked if they are as secure as a linux repo. But the concept of “it is acceptable to download software from random websites” allows for malware to fit in there. Only if you will never find a .flatpak file it is possible to be sure its malware.

But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you’re actually running an untrusted app.

All worse than bubblewrap. Containers are either manual af (like with bubblejail) or if you refer to Distrobox/Toolbox, unconfined by default. They have no portal integration and no GUI configuration apps. So it may work somehow but probably worse, more resource heavy and there simply already is something better.

Same for VMs. Keep an eye on Kata containers, but this is about least privilege, not some QubesOS system that will not run in a tablet, for example. Android uses containers, is damn secure, and runs on phones.

[non executable stuff]

This is about protecting against malware. Linux Desktops are built on a different logic. Any unconfined software can download a binary to localbin, copy a random desktop entry from usrshareapps to your local folder, edit the exec line and add that binary to it.

Or just manipulate your .bashrc, change the sudo command to read input, save to file, pipe input to sudo. Tadaa, sudo password stolen.

That concept of “users can change their home but not the system” is poorly pretty flawed. So any directory that is writable without any priveges is insecure, if you dont trust every single piece of software you run.

Agree that Snaps are a problem. Its only really problematic when repackaging is illegal though, of course annoying but the Spotify flatpak is a repackaged snap. Same as with appimages.

I should write the same about snaps, but I feel they are covered WAY better.

thiccckk,

This tool also good

github.com/ivan-hc/AM

Pantherina,

Dont spam please

avidamoeba,
@avidamoeba@lemmy.ca avatar

Oooh yes, let’s throw some mud in the gaping holes of this packaging solution, spit and tape the rest to make it do something it was not designed to do. Brilliant idea! ☺️

jjlinux,

This is how you bring your thoughts to the table. Awesome information that I certainly did not have. Thanks man.

vhstape,
@vhstape@lemmy.sdf.org avatar

Ate em up

aksdb, (edited )

I agree with you on all but one point: I detest the argument that “storage is cheap”.

While true, it’s of no value to have 10 times the storage when all your apps grow 10 times in size. You can still only do as much as before but had to upgrade in between. This also means, it leaves behind people who simply can’t afford an upgrade and who have an otherwise running system.

On top of that, we live in a time where we should not waste resources, since the world already suffers enough.

I am therefore still a fan of optimizing software to be as efficient as possible.

That being said: carefully used AppImages solve one such issue for me. Not every application I use needs constant updates. I want to stay at a specific version. That’s easy with AppImages.

Kusimulkku,

GearLever

Download from Flathub

Hehe.

Duplicated libraries

This is a fair point but “they include all the libraries they need” is the entire point of AppImage - so mentioning this is pointless.

“Bloat” is one big topic around these newer packaging formats so definitely not a pointless thing to bring up imo. I don’t think it should be as big of a topic as it is (the actual issue here is fairly minor imo) but it is definitely talked about.

And flatpak (and snap I think) have much better tools to mitigate the space use issues.

Takios,

(any Flatpak user would’ve at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes)

While I overall do prefer Flatpak over AppImage these days, the sandboxing has indeed been giving me more trouble than I think it is worth so far.

someacnt_,

Yeah, it is also interesting how people do not see in eyes of developers.

h3ndrik,

We’re also regularly debating Flatpak here. That password managers don’t tie into the browser and the desktop themes don’t apply. It’s also not the best solution and regularly confuses newer users.

Pantherina,

That native messaging portal is probably developed somewhere. But for sure, also apps installing themselves “partly” as an extension of another, like Zotero and Libreoffice. This could be done though, okay.

Themes generally just work on KDE at least. At least light/dark themes, which may not really be the fanciest of choices

h3ndrik,

I’d be happy if people just cut down on advertising Chrome/Firefox and LibreOffice via Flatpak to new users. They should use the packaged version. That’s why we have distributions, to make the whole system a smooth experience and everything tie together.

Flatpak is slowly getting there and I think at least some distros have it preconfigured so the default GTK themes are in place.

Ultimately, I’d like sandboxing to be available natively in Linux, at least for desktop applications. And we can talk about a packaging format that is available to the user, allows pulling software directly from the upstream project, includes libraries and runtimes.

Pantherina,

Yes SELinux confined users or apparmor could allow sandboxing apps the same way as flatpaks.

On 2GB of RAM systems that would make a lot of sense.

Chromium cant use its native sandbox, Firefox supposedly can.

But Librewolf and more should be used as Flatpak, unless you need multiple apps to chat between (native messaging) which doesnt work yet, its way more stable.

h3ndrik, (edited )

Yeah, I think we should extend on the sandboxing features like AppArmor, SELinux and Flatpak for desktop use. Look at MacOS and Android and what they’re doing for desktop users. That is currently not the Linux experience. Ultimately I’d like my system to have an easy and fine grained system to limit permissions. Force third-party apps to ask permission before accessing my documents or microphone. have sane defaults. make it easy to revoke for example internet access with a couple of clicks. make it so I can open an app multiple times. and have different profiles for work, private stuff and testing. This should be the default and active in 100% of the desktop applications. And apps should all use a dedicated individual place to store their data and config files.

Librewolf and more […] used as Flatpak, […] its way more stable.

That’s just not true. I’ve been using Linux for quite a while now. And I can’t remember my browser crashing in years, seriously. Firefox slowed down a bit when I had 3000 tabs open, but that’s it. How stable is your Flatpak browser? Does it crash minus 5 times each year? How would that even work? And what about the theming and addons like password managers I talked about in the other comment? Use the distro’s packaged version. It is way more stable. And as a bonus all the edge-cases will now work, too.

Pantherina,

Most things already work. You know, desktops need to start with that, they need to implement popups for these permissions. And I guess apps also dont ask for permissions yet (like they do with Pipewire access), they just take it or fail.

So its again a problem of adapted apps.

Storage is all stored in ~/.var/app/ and could be duplicated etc if you really want to. That would require some hacking, but you could have multiple profiles for apps. Tbh this is not hard to do at all, just rename the app folder to “appname-profile” and rename the active folder back to the apps name.

A GUI for that would be interesting.

Browsers are a big example of good native packaging, as they get most attention. But for example on Debian, or Ubuntu, or many other platforms, I would prefer to use Flatpak Firefox (if firefox didnt have their deb repo now).

Chromium is hacky as Flatpak as the Sandbox is imcompatible and needed to be replaced.

For firefox there is no statement about this, hopefully soon. I use native browsers for the same reason as you.

GravitySpoiled, (edited )

Flatpak is the best solution.

Password manager is usualy an add on.

Themes not applying is wrong packaging, not flatpaks fault.

Flatpaks limitations are real but you should install as flatpak first and if not working, then use the native package or nix. And limitations in flatpaks should be advertised.

h3ndrik, (edited )

Hehe, No. It’s the sandboxing.

But with this approach you take over the answering questions to newbies… Why doesn’t the webcam show up in the videoconferencing? Why doesn’t my GTK / QT themes apply to some software and it’s a 2 page tutorial with lots of command line commands to fix that? Why can’t I install Firefox add-ons and on Windows and MacOS everything just works? Why is Linux so complicated and regularly stuff doesn’t work?

I had this argument multiple times now. There is an easy solution: Do it the other way around until you know what you’re doing and about the consequences. Distributions are there for a reason. They put everything into one package and do testing to make sure everything works together. They provide you with security patches if you choose the right distro. LibreOffice and a Browser even come preinstalled most of the times. If you do away with all of that, it’s now your job to tie the software into your desktop, your job to handle the sandboxing if there is addons that need to pierce the sandbox. Your job to make sure the Flatpak publishers do quick updates and keep the runtimes up-to-date if a security vulnerability arise within an used library…

I’m not directly opposed to using Flatpak. I’m just saying there are some consequences that aren’t that obvious. There are valid use-cases and I also use Flatpak. But in my experience hyping some of the available technologies without simultaneously explaining the consequences is regularly doing a disservice to new users.

GravitySpoiled,

Do you mean fedora not installing codecs by default and the flatpak version of firefox has it bundled, i.e. just works?

I don’t want to argument with you about that. If something doesn’t work as expected or intended, you’ve done a bad job. Stuff not working on linux isn’t exclusive to flatpak. It’s the fault of maintainers if people complain about a flatpak version compared to distro package.

More people have to use flatpak and report the bugs they experience. The more people focus on flstpak the less infancy bugs will appear.

I’ve got only recent runtimes installed. There’s no old runtime. I understand your concern though, but it’s less of a problem for maintained software. Moreover, you’ve got the same problrm for other package manager. Flatpakcan even improve upon this because it’s bundled.

There’s also a distinction to be made if it’s an official distribution channel or if someone else packaged it.

h3ndrik, (edited )

I mean it’s not even my own problem. I just have Spotify, Microsoft Teams and Zoom installed that way, and a few pieces of software that I’m testing. I use a rolling distro so I have the most recent versions of every software I need anyways. And I have the skills to configure stuff. So I myself don’t have an use-case for a spyware-riddled Chrome browser from Flathub or something. I have a nice LibreWolf from the unstable channel of my distro. Steam and all the other stuff is there, too. And it works almost flawlessly. Why would I trade that in for a 4GB version of the same software that has downsides?

It’s the newer users I’m concerned with. Their sub-par experience of Linux.

This is what I mean:

  • github.com/keepassxreboot/keepassxc/issues/7352 (Maybe Keepass works as of now(?) I don’t think so but I haven’t tried. At least some addons do. But other’s don’t. It requires the permissions to be configured by the prople preparing both flatpaks that want to talk to each other.)
  • itsfoss.com/flatpak-app-apply-theme/ / docs.flatpak.org/en/…/desktop-integration.html
  • All the issues people had with Steam, the graphics drivers, attaching gamepads/controllers or headsets, getting Discord and extras working. (Some of that seems to have been resolved in the meantime. They put quite some work into it.)
  • Some distros don’t update Flatpak packages as part of their standard update mechanism. You need to learn to regularly run “flatpak update” or learn how to activate that.
  • I have some packages still rely on old runtimes that are missing security patches. I suppose it’s the same for a lot of other people. And there isn’t a mechanism to warn you. You also need to learn how to figure that out.
  • I don’t remember which of the video conferencing solutions this was, but I remember fighting with the webcam permissions and advice on the internet was to disable sandboxing entirely. I set the permissions a bit better but then also screen sharing wouldn’t work.

As I said, it’s okay for someone like me - and probably you - to use, and I don’t complain. I’m glad I have Flatpak available as a tool. But look at the issues I’ve linked above and the steep learning curve for the beginner. They need to learn what GTK is, what QT is, what desktop they use, learn what Flatseal is, use the CLI. They have no clue why it is even required to do that much work to get their Keepass set up. And that it’s not Linux’ fault but their decision from 2 weeks ago to install the browser that way. And their experience is just worse than it needs to be. And this isn’t unsubstianced, I’m speaking from experience. I’ve answered these questions over and over again. It’s already annoying to get the NVidia stuff set up reliably, find new software and adapt your workflow. And the switch from X11 to Wayland broke things like screen sharing/recording, anyways. And we’re now piling 20 other things on top, to learn and do manually if you happen to be one of the users who don’t use the default standard setup.

And nothing of that is “bad” or can’t be fixed… We’re making progress with all of that. And we’ll get there. All I can say with my experience helping people with their Linux woes and the current state of Flatpak: The “use Flatpak for everything” mentality is causing issues for some newer users. And experience shows: They rarely understand the consequences but heard the hype about Flatpak. And few of them can explain why they used Flatpak over the proper packages in their distro.

So my opinion in short:

  • Flatpak is nice : yes
  • try a Flatpak first, then the distro package if it doesn’t work: hard no
  • you can get recent software on older distros with flatpak: yes
  • you can recommend Flatpak: Yes, if you also explain the consequences of the sandboxing and pulling things from potentially unreliable third-party sources. You’re doing people a disservice if you don’t.
  • some of this will change in the future: yes
  • we should have more sandboxing: yes
hperrin, (edited )

I agree with this, but as an app developer, can I just say, Flathub’s documentation is an absolute abomination. It is so bad, that I’ve tried 3 times to publish an app and have given up each time. I can build a local Flatpak just fine, but getting it on Flathub is just so convoluted and bad.

AppImages are ridiculously easy to build and distribute, just a pain to actually use. And even then, they’re not that much of a pain.

db2,

Try getting Creality Print to run without manually updating components of the appimage. I’ll wait.

hperrin,

This has nothing to do with my comment.

db2,

Uhh ok pal, sure thing.

jjlinux,

Bro, a developer (which I am not) voiced his opinion. What’s the need for the toxicity? Isn’t it better for everyone if we all ask questions or provide our opinions respecting others? This is the reason why ANY difference of opinion ends up turning into a heated and useless argument. If you have something to counter what he said, by all means, bring it to the table. @hperin didn’t say anything out of place.

db2,

I think you’re both on something either really good or really bad. I added to the sentiment about appimages and you’re both too busy sniffng your own farts too actually read the very short thing I wrote. You’d rather create a narrative in your own head about what a big meanie I am. So be in it then.

In conclusion, screw both of you, you’re blocked. I have only marginally more patience for stupid than Linus does and you’re both well past that. Have a nice day.

jjlinux,

You too bud. A great week actually.

FuglyDuck,
@FuglyDuck@lemmy.world avatar

One specific implementation by a terrible company that can barely manage to check quality control on their actual products isn’t a very good example of appimage’s problems.

Not saying they don’t have problems. But having seen creality’s version of Marlin, I gotta say, I’d be willing to bet they rebranded something, but using vastly out of date versions.

Probably should switch to simplify3d, prusa or cura.

db2,

While you’re not wrong, the problem I was referencing is an outdated library embedded in the image. It makes the whole app crash and it could happen to any app.

FuglyDuck,
@FuglyDuck@lemmy.world avatar

That’s a creality problem. Not an appimage problem.

They’d have a just as shitty flatpak or whatever else they used; because that’s how the company is.

db2,

Are you trying to tell me creality is the only one who would ever embed a library in an appimage? Isn’t that supposed to be half the point, that it comes with what it needs?

FuglyDuck, (edited )
@FuglyDuck@lemmy.world avatar

No. I’m telling you that they won’t maintain it properly.

Not when it’s a reskinned cura fork. There marlin (printer firmware- nominally more important) versions are old too… last I checked, by years.

Pantherina,

Totally understand that. Development docs are so needed.

SubArcticTundra,
@SubArcticTundra@lemmy.ml avatar

If worst comes to worst you can just distribute your .flatpak file directly, as you would with your app image

Pantherina,

This would tick a lot of issues but please dont do that. People will get used to it and suddenly malware is possible again.

gnumdk,
@gnumdk@lemmy.ml avatar

what are flathub issues? IMO it’s easier than putting your app in Debian…

Luci,
@Luci@lemmy.ca avatar

Odd, this random github rant didn’t seem to sway my opinion.

To hell with user choice, only flatpak

OmnipotentEntity,
@OmnipotentEntity@beehaw.org avatar

I’m not going to weigh in on the specifics of Flatpak vs AppImage, because I don’t know enough about the particulars.

However, I think the “user choice” argument is often deployed in situations where it probably shouldn’t be.

For instance, in this case, it’s not the user’s choice at all, but a developer’s choice, as a normal user would not be packaging their own software. They would be merely downloading one of a number of options of precompiled packages. And this is the thrust of the argument. If we take the GitHub rant at face value, some developers seem to be distributing software using AppImage, to the exclusion of other options. And then listing ways in which this is problematic.

I, for one, would be rather annoyed if my only option were either AppImage or Flatpak, as I typically prefer use software packaged for my package manager. That is user choice, give me the option to package it myself; hopefully it’s already been done for me.

There are some good things to be said about trust and verification, and I’m generally receptive to those arguments way more than “user choice.”

Pantherina,

Thanks. Also, afaik lots of software is not legal to redistribute as Flatpak.

spacebanana,
@spacebanana@lemmy.world avatar

It’s thanks to user choice that we aren’t all stuck on proprietary operating systems, so saying that isn’t great.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • linux@lemmy.ml
  • fightinggames
  • All magazines
    •