I like the separation between system packages and apps. A random system library being out of date doesn’t matter to me as long as it receives security patches. But I will not use out of date GUI apps when I don’t have to.

This is concerning. Hopefully they manage to keep it running as if the standard for packaging software on Linux disappears, companies would return to tarballs.

Android works much better, no doubt in that regard, but I think the chance of this script breaking your system is very low. The vast majority of the apps are flatpaks, then snaps, tarballs, AppImages, and only then a few .debs. I try to avoid them because even if you are on Debian/Ubuntu after a few years your version will stop being supported, whereas snaps will continue to work for 10 years.

Well guess what, I don’t use or want to use Arch. Pretty sure there’s a nix recipe too, possibly a Void or FreeBSD one too. They aren’t maintaind by KDE itself.

What do you mean by stagnated? I don’t keep up with its development but it seems pretty feature-complete.

If developers move on to something else I will modify the database accordingly. But as long as snap and flatpak are the official methods they will stay.

https://snapcraft.io/k3b

That’s understandable. Truth be told I probably wouldn’t trust this either if I didn’t make it. Anything can be hiding in the custom field.

Well then that has nothing to do with Canonical forcing developers to use snap if they want to appear in the software centre.

I like to get software directly from the developers, and this just makes it easier. I don’t want to compile anything, and I don’t mind any of the package formats. I just don’t like that every app uses a different one so it’s a pain in the ass to install them.

Whether you trust the list not to execute malicious commands is up to you.

If you want to build from source, this brings nothing of value. Nix has pretty much everything.

It’s meant for people who prefer their apps from the official sources rather than repackaged. All this script dies is make it easy so you don’t have to google the app’s name and search for an install method on its website.

That’s a good point. I will also probably need a better update method than rm -rf-ing the files and replacing them with each update.

Could you elaborate? I’m not the best programmer so I’m open to suggestions.

But why choose snap only? Flatpak works on Ubuntu just fine, and on other distros obviously, so they could just choose that. Blender only officially support snap too. Vivaldi for example made a blog post about how snap has better sandboxing of chromium. https://social.vivaldi.net/@ruario/113164179328218870

Yep. I did automate it the best I could (I’m not creating entries for thousands of apps manually) but it will indeed require manual maintenance as the apps will change their installation methods over time.

Those are all official sources tho, but you have to trust me not to put in malicious commands of course.

I understand that people treat snap as if it was a contagious virus but the developers chose the method purposely. A lot of KDE apps are only distributed as snaps for example, k3b comes to mind. VLC as well.

There are flatpak versions but they aren’t official, which defeats the point a bit.

I do however plan to somehow add the ability to prefer flatpak, since a few of the entries have both a flatpak and snap field.

Thank you, and fair enough.

Will there be a linux version?