Canonical created snap; of course they’re going to push it.

It’d be like if Sony created BluRay and then didn’t do any market/sponsorship/etc.

Now I'm wondering, if it were bundled with an OCI sandboxing system, that would address my issues with Flatpack and Snap. Technology has moved on and Flatpack has stagnated, and Snap's just an attempt to centralize control and distribution. It's time for a redesign, specifically focusing on supply chain attacks, with sandboxing all the way down.

a lot of KDE packages are only distributed as snaps

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.

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.

Obtainium works in Android, because all the apks have their own Libraries already included, and bc android itself is Immutable

Take that into a mutable system like Linux, and you get break my Gentoo if you didnt even have the great anti dep hell functionality of portage

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.

Ironically, it's been in the news lately because of a talk given at LAS. Here's a breakdown of the video, for people like myself who hate watching talking heads.

Basically, development on Flatpak core has mostly stalled. And there's a lot of work yet to be done; efforts to rebase it on OSI, for instance.

Nobody's claiming it's dead; it's popular and widely used by a lot of people - it's just that nobody is actively maintaining the Flatpak project anymore.

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.

Some apps are packages as tarballs, some as .debs, some as install scripts that download a binary, some are flatpaks and snaps.

1. tarballs - heckle the devs to make a proper package
2. debs - this is a package, but its format makes it weak
3. flatpaks - discard this unvalidatable crap
4. snaps - discard this unvalidatable crap

just

sus.

typing the names of what they want, and the script will just get it.

apt-get install <some app> (thank you, Conectiva)

This is how it should be. This is how it was. The sooner we leave this swamp of quicksand packaging, the better.

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.

Someone will probably step up. It sound like the big blocker is governance - there are people willing to contribute, but whomever has control is not doing a good job of administering the project. At least, that's what I read between the lines.

Someone will probably fork it, get popular, then suddenly the original maintainers will find motivation, try to scramble to regain directional control, and be discarded because everyone lost faith in them.

Or, we're really about due for a new generation. Snap's a hot pile of steaming shit, Nix is simply awful for package managers to work with, Flatpak is directionless, Guix is like every other big GNU failed attempt to be an also-ran, and a lot of lessons have been learned from all of these. I expect someone will come out with something cleaner, leaner, and without all of the baggage; maybe with some backwards compatability with Snap, Flatpak, and AppImage packages.

Maybe not, but the situation is ripe for something like that. Just don't let it be based on god damned Lisp. I respect the hell out of Lisp and Lisp machines, but I absolutely hate having to work with it.

Same here. I switched to Debian, pop and fedora on my machines to escape the snap control.

Its cool to see this xkcd in action.

That being said theres a couple options out here attempting the same thing, but due to the required level of trust youre fighting a bit of an uphill battle for widespread adoption.

Not that this changes how cool of a tool it is and valuable for you use case!

Could you link some of those other options? I tried searching for something similar and found nothing. I know about LURE which got abandoned and didn't have the same goal.

Heres the biggest and most active I could quickly find, but I believe the XKCD in that repo inspired a handful of similar projects

I did check it out and it's really cool, but here's the big difference

I want to install audacity and it ran all of the commands for search via the package managers. My script will do this:

Check the database and finds an entry I made, because as it turns out, the only official audacity package is an AppImage built for Ubuntu 22.04. So it launches a command that retrieves the latest AppImage even if I don't update the database as it tries to fetch the latest version number and download the appimage based on that.

Ignore the .1, this is from a VM I test the app on and it's a mess

TLDR: mpm runs search commands for all package manager, my script's database was created manually. This means a lot of apps will be missing but when I come across something that's not there, I add it. Whether this approach is a good idea in the long run, I don't know. I just felt like creating a proof of concept of the idea.

Try https://github.com/Fmstrat/gam?

Same idea as this but specific to source releases

I also like the idea of installing software "as intended by their developers" and I don't like Linux distros that make a lot of changes and customizations. That's why I like Slackware for example, a distro that remains "pure" and intervenes as little as possible.

Good idea!