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.
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.
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.
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.
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.
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.
In the spirit of free speech, I think all transphobic people should get the Stonetoss Superman treatment.
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.
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.
It's going to re-launch soon
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.