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

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.

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.

GearLever](https://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.

(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.

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

Ate em up

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! ☺️

Totally understand that. Development docs are so needed.

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

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

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

Great, now tell me why your appimage is complaining about not having some .so file on my system

But then again some people use things like Homebrew and pacstall unironically so …

Thank you for mentioning this! Unfortunately a quick search on the internet didn’t yield any pointers. Would you mind elaborating upon the security problems of Homebrew(/Linuxbrew)? Thanks in advance 😊!

I learned quite some things from this talk

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

Appimages are damn broken

I agree with much of this. However, regardless of which platform you’re on. it’s best to follow the design patterns of that platform.

Putting binaries on your desktop is not in keeping with Linux design patterns, nor are self-updating apps. I think those are fair points.

Having dozens of apps all using their own update mechanism introduces unnecessary complexity, which can be exploited. This has been a problem on Mac and Windows over the years. On Mac, for example, a common solution to this is the Sparkle framework, which devs can use in their app to manage self-updating; but Sparkle itself has been exploited, so then you have apps out there running god-knows-what-version of Sparkle in their bundles, leaving users vulnerable with no good way to identify or remediate it. This is why I typically disable any self-updating feature in any apps I use.

Dont know where user installed tar archives (with statically linked binaries or including deps) would have dep conflicts, maybe if they are not statically linked.

The self updating stuff and desktop icons is personal opinion and not the common way on Desktop Linux, so I skip that.

you could do something like obtanium for android which could easily automate the process.

That is called a package manager, with a repo, with gpg signing etc. On Android (which I mentioned) updates are secure. Let alone the point that appimages are not updated in a regular way, they are just replaced.

I’d argue it makes little difference. But yes, Downloading things from the internet is more unsafe

No the difference is huge. If you are used to downloading software from websites, a faked website can easily lead to downloaded malware. Flathub can be added with a click and flatpak is included in distros, which means no hunting on the internet and no accidental clicks.

And as I said, until nobody downloads .flatpak packages online, and there may be an occasion where this is normal behavior, people will believe malware links are legit.

the risks seem blown out of proportion here. As long as you are downloading from the same place, the risks are significantly smaller in reality, not gone, but smaller.

Appimages are distributed everywhere, just as .exe files for Windows. This means they are favored by developers used to Windows and Mac, and those will not add them to a repo instead.

So a faked website of whatever etcher or something is easy.

The fact that Linux malware is not a thing, while Appimages clearly give the headstart for that, is a miracle.

I find this to be a benefit myself, I have had countless headaches with flatpak applications and their sandboxing. everything

Flatpaks are not secure because their sandboxes are weakened to not have such issues. This is due to apps not following secure standards, and until that is fixed they are insecure or broken or both. (Apps need to write configs in the container, they should use portals etc.)

I maintain a list of flatpak apps following modern standards, which is a small portion but getting better.

Linux is only somewhat secure because everything is FOSS and comes from repos.

This is broken by appimages, that can easily distribute malware and thus fix the “my malware is not running on that distro” issue.

Every software that can write to your .bashrc can easily catch your sudo password.

Another moot issue. $HOME/.local/bin is an XDG standard, so unless we pretend that XDG standards aren’t “one of the major standards” this is just wrong.

Yes linux experts would put them there. As mentioned in that text malware would also install itself there, so on secure systems this should be only writable by root/ some elevated group privilege.

But apart from that users put them on the desktop, or in some random folder, I mean that dir is hidden for a reason.

Or put it in that PATH and then link to the desktop, resulting in a broken link when you remove the app.

When you need only a couple appimage files, space I find is smaller then flatpak, it only becomes when you need a lot of applications.

If something is not scaleable its not a good concept. The fact that you will only install a couple of appimage apps is enough proof.

On modern atomic distros users can rely purely on flatpak.

Btw see the linked dedup checker. You may download more dependencies but they are linked between each other and not actually take up so much space.

I don’t need to worry about installing and uninstalling application when I just want to try it

We need to overthink those habits. You dont just “try an app”, you run unsandboxed code from an unverified origin. As mentioned above, this could be totally fine, and also add a function to your bashrc that catches your sudo password (the next time you use it) and sends it to a server.

The secure way to do that is completely unpractical.

1. Get a GPG app or use the cli, create a personal key. Secure the access permissions, as gpg always complains on Fedora for example.
2. Hunt the internet for the gpg key of the dev
3. Look for at least another source of that key like GrapheneOS does it
4. Compare those keys hashes using cli or some app
5. When correct, load the key into gpg/kleopatra/kgpg
6. Verify the key with your internal key (yeah gpg is overcomplicated)
7. Download the appimage, and a signed hash (most of the time its done like that)
8. Verify the signed hash
9. Sandbox the appimage using bubblejail (doesnt work) or firejail (no idea if it works, and its insecure)
10. Repeat on every damn update (if it doesnt have a builtin updater)

This is unusable. And repositories do this automatically without anything you need to do. For sure you could “extra check the website” and say "

Also app data will be everywhere, often in its traditional location, while there is no package manager at all to delete them. Flatpaks store all their stuff (when devs care and not just ignore that, cough Cryptomator) in their container and data can be easily removed during uninstallation, GUI stores show a popup to delete data and I also made a small script to do that.

And that “try it out” app will either have no desktop entry or that entry needs to be manually and will be still there after uninstalling.

I don’t need to muck about trying to get an app into flathub or starting my own repo, when a user has a problem, I can just tell them to run the new appimage instead of trying to get them to compile it.

This may be a reason, but this is only for testing then. But for sure, when its a small project, getting it on Flathub may be much efford.

I can imagine the developer experience is easiser. Flatpaks are simply very “defined” and need all that metadata and more to be complete. But needing to use available runtimes is a good thing mostly, its basically supporting a specific distro.

Flatpak through CLI is fine (I would like to have a standalone small store just for flatpak), Discover is nice too. The Linux Mint store also seemed fine but not much experience. (Linux Mint has some Wayland support now, so there is a secureblue Cinnamon spin, have to try that). The Cosmic store is just a stub currently, lets see!

Cheers!

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.”

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

Okay fair point. Piracy, illegal content etc. will all get removed from Flathub.

Similar to another comment about archiving software that may get removed

As far as I know flatpak applications can be distributed as a file without the need for a repository, just like .deb or .rpm files

I want to find a way to do this with flatpaks too.

A small GUI tool (a statically linked binary lol) that can be placed on that stick

• copy the flatpak app and runtime stuff to a folder
• copy the desktop entry over
• copy app data when chosen

And the same thing to copy it from the stick to a live system. Should work, probably not haha

Thanks, yes fully agree. There are a ton if shitty distribution ways.

When I publish stuff on Github (its never big, always small tools) I never let people git clone, just download the needed parts.

Releases are meant for that, but still, putting software on repos may be annoying but its the correct way to do.

Nextcloud, Balena Etcher, Lunar Launcher and more are exclusively supporting Appimage, thats the big problem.

I get that multiple package managers can be suboptimal (though I don’t have a problem with it as long as the integration is good).

But it still seems like a much, much better solution than just not having these applications managed by a package manager, as is the case with AppImages.

So you prefer to not have any updates or secure verification, because you dont want a second package manager?

Dude you are the second package manager, and if you dont follow the whole gpg verification process I described in another comment, that is less secure.

You should definitely be checking the signatures before double clicking tho

Most shortsighted answer of the day. Great now you have this outdated executable on your system and you mabye are not even sure this was installed through appimage, because how should you know when your launcher is not telling you anything? golfclap

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

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.

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.

Because the FHS is a more sensible organization of files. Not every user needs to have their own executable for each program, that’s a mess.

opt

You shouldnt need Flatseal as Flatpaks should have as little restrictions as need to make them work properly.

This is an app problem, on Android all apps start with 0 permissions and many work completely without.

I maintain a list of flatpak apps following modern standards. Those dont just work because their sandbox is full of holes, but because they are adapted to use portals etc.

So Flatseal is used to harden flatpaks, not weaken them, normally.

that it would make my backups and restores take 900% longer and would rinse my data when they need updating.

You mean their storage space? Yes, biggest problem. Not very well solved tbh compared to android where all apps are also sandboxed but they have sizes of 30MB or something.

Flatpaks should be preferred over many other formats though, as they just work, dont touch the system and are more secure, unlike Appimages.

I highly recommend to watch this talk that some commenter mentioned

https://www.youtube.com/watch?v=b4_TXZJw3rU

because they require more access to the system

afaik, you can allow more system access to flatpaks

Ubuntu runs a virtual filesystem in order to allow its Snap Firefox to access the Dictionary that lives “outside” its sandboxing

i believe flatpak also does that, you can specify some paths from the host to be available to the flatpak

Are these access problems not solvable with XDG portals?

Have a look at GPU screen recorder, I think thats as much privileges as you need.

XDG-desktop portals are not yet complete. But for filesystem access and GPU de/encoding that should already work.

If the Davinci Resolve devs actually cared about Linux…

Have a look at GPU screen recorder, I think thats as much privileges as you need.

XDG-desktop portals are not yet complete. But for filesystem access and GPU de/encoding that should already work.

If the Davinci Resolve devs actually cared about Linux… I think the best way to run it is using uBlues image on Podman.