Ain’t that the truth. I don’t know why KDE Discover is so sluggish when it comes to Flatpak, it takes me like 10+ seconds to load the landing page and see the popular apps.
First time I’ve heard someone call Gnome Software fast. In my experience that app feels like it’s on it’s last legs; the Flatpak CLI is far better than any desktop GUI.
Gnome Software has received numerous updates over the last few years which make it considerable faster. Searching and viewing apps is now fast enough to be usable, compared to it taking many seconds to minutes for basic tasks.
I’ve stopped removing Software on every system, altough I’m not usually using it. I’ve not tested it, but I feel like Discover is now slower than Software.
My main issue with Gnome Software is if I queue something to install, and go back to browse for more apps, once something is done installing it “refreshed” and I lose the spot I was at. Makes me feel I can only install one thing at a time.
It’s definitely faster than it used to be. But yeah, searching for app updates is still more sluggish than through the terminal, at least on Fedora Workstation.
This is a good step but I still feel like it’s pretty obscure where a package is actually coming from. “by Google” or for the Steam package “by Valve” is really confusing and makes it sounds like it’s coming directly from the company. Unverified tells the user to pay attention but there is no hover over to say what it actually means.
Wait… so the author displayed in “by <author>” is the supposed author of the software, not the one that put it on the store? That’s insane! Also sounds like you’d be open to massive liability since the reputation of the software author will be damaged if somebody publishes malware under their name.
Also maaany packages direct to issuetrackers of projects not supporting that flatpak.
If someone knows where that flathub metadata is stored I would love to know, as the manifest is not it. I would like to fix those to link to their own bugtrackers
My problem with that story is that’s the one time Jesus chose violence, vs the bajillion times he said to love your neighbor and turn the other cheek. But I’ve seen tons of posts by right wingers like “we should kill people we disagree with! Jesus was all about violence, did you hear about the time with the whip!?!?” using it as justification for their hate and totally ignoring all of Jesus’s messages.
I still don’t understand why a central repository for AppImages exist. The moment you are using a repository (and possibly version management), the format looses its reason to exist.
I don’t see how that’s true. The main point of AppImage is it ‘just works’ on any distro. If you have one primary place to distribute them to any distro - it’s still meeting AppImage’s vision.
No. Appimages are selfcontained and thus useful for archiving software or carrying it around in random ways. Flatpak could do this too but not as easy.
I personally use a few AppImages, but want replace them with Flatpaks. Flatpaks have their own issues, and because I did not want to troubleshoot in case I encounter another issue, just carry on using AppImages for these selected applications. Also I was not able to archive Flatpak easily, its very complicated with keys and not. Compared to it, I just have the AppImages included in my regular backup process with regular files.
My point was not if AppImages are useful (they clearly are and I use them), but was talking bout repositories. However after some other replies I thought about it and indeed such a repository makes sense even for AppImages. I personally just don’t have to use them.
Not really. AppImages are as much secure as any other executable you run on your system. If you download it from a trusted source, like you download trusted Flatpaks or your systems repository, then they are not worse. If you say AppImages are highly insecure, because you run executable code, then you have to take that logic to any other executable format. The problem is not the format itself that makes it insecure, it’s the source.
I read that page and there is nonsense included too. Just because I read that page does not make it correct. If you think that AppImages insecure, then you did not understand my point that its not the format thats insecure, but the source where you get the files. Every packaging system is insecure if you get it from bad source.
That’s not even a question. AppImages are fine and not insecure if you download it from a secure place you trust (like your system packages, you trust your distro maintainer fully). Would you trust every distribution maintainer on every distribution? Let’s say a Chinese Linux distribution, that maintains Flatpaks and native packages. Let’s say they are flaky. See? It’s the source you don’t trust, not the file format or packaging system.
Read my replies (just like you said I should read the linked post). And understand the issues.
Appimage is not a neutral packaging format. Of course “an app packaged as .zip is as secure as packages as .tar.gz”. But the format causes all the things mentioned in the post.
libraries are often the oldest non-EOL possible to support old kernels
no transparency about used libraries and possible vulnerabilities
no upgrades of libraries, always just the wanted app and then passively also the libraries
no sandboxing without firejail (which is a root binary and thus can lead to privilege escalation of rootless processes if it has a vulnerability which it had in the past)
no GUI sandboxing
even with a repo no cryptographic signature verification like on Android (not sure about Flatpak which uses OSTree)
requires users to execute code in random locations
I partly agree. But your tone changed a lot from “highly insecure” to “less secure”, which is a complete different statement. An application does not need to be in a sandbox to be secure, so I don’t accept that as an argument against trusted applications. I only accept your arguments if we talk about random downloads from random places.
Also the argumentation that AppImages are usually run from random locations doesn’t make them unsecure, it’s a feature. BTW I have a dedicated folder where I put them, but that’s my personal organization. Did you know that you can unpack an AppImage back to its original folder (like an archive)? You need appimagetool for that.
The only thing I fully agree with you and is a weak spot about the AppImage format is, that it can or will include outdated and not updated libraries (or executables). Which is the point of the format on the one hand, but a curse on the other hand. Normally it is recommended to build on the oldest supported LTS Ubuntu, because of older libc. libc is the root of many problems in Linux (for compatibility).
Tbh I was browsing a few nsfw subs/users earlier today and it was annoying as fuck, with errors every other page, images not loading, galleries half-loading, sooooo
lemmy.ml
Oldest