I created a script that always installs apps from their official source
https://github.com/Tsu-gu/appfetch/
It’s a proof of concept of an idea I had a while ago. I dislike having to hunt down apps for my Linux machine when I want them from an official source. Some apps are packages as tarballs, some as .debs, some as install scripts that download a binary, some are flatpaks and snaps.
I created a yaml file with only verified apps from flathub and snapcraft, and added a few apps outside of them that I could think of.
The ultimate goal is the user just typing the names of what they want, and the script will just get it. They shouldn’t waste time with picking the right source.
Some apps are packages as tarballs, some as .debs, some as install scripts that download a binary, some are flatpaks and snaps.
- tarballs - heckle the devs to make a proper package
- debs - this is a package, but its format makes it weak
- flatpaks - discard this unvalidatable crap
- 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.
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.
I like the idea ! And looked at the project on github. But … snap disgust me so much more than searching the right source, i’m not adapting to it. But still nice thinking!
Seriously? Very strong feelings XD
Thank you, and fair enough.
Maybe add something in the search results to indicate the app’s origin? Or even just a way to choose search sources?
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.
the developers chose the method purposely
They chose it because it’s often the only way they can distribute packages to Ubuntu users. Which was the whole point all along; Canonical taking control of app distribution.
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
But why choose snap only?
Because they don’t want to support flatpak.
Well then that has nothing to do with Canonical forcing developers to use snap if they want to appear in the software centre.
wild
a lot of KDE packages are only distributed as snaps
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.
I like this idea, but with the increase in supply chain attacks, I’m reluctant to use it. I’ve been much more reticent about installing from AUR, and my use of github projects has drastically slowed down since I now feel as if I have to read all the source code for everything I get.
I’ve sandboxed programs before, and I may just start making that standard practice, but still… it makes me angry. It’s, like: this is why we can’t have nice things. There are precious few OSS supply chain static code analysis tools, and there are a lot of languages I don’t know well enough to review, or which have such broad or deep dependency trees that it’s more work than it’s worth. The most frustrating is the dampening effect it’s having on OSS. It only pushes people to only use programs from big commercial companies.
Anyway, none of that is directly related to your program, which is really cool. Sadly, if there aren’t any positive developments in the OSS ecosystem for attacking the supply chain problem, cool projects like this are not going into my toolbox.
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.
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.
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.
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.
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.
Sounds like Obtainium on Android.
The thing that concerns me is that it downloads an unofficial source.
Those are all official sources tho, but you have to trust me not to put in malicious commands of course.
Oh so you are essentially personally maintaining the sources list?
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.
Genuine question: Why would I use this as opposed to Nix? Between nixpkgs and the NUR, there are an insane amount of packages available, and you can build everything from source if you wish.
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.
right, that’s what nix does if you build from source
If you want to build from source, this brings nothing of value. Nix has pretty much everything.
with that being the case, correct me if I’m wrong, but your pitch is that users should trust your manually compiled and maintained commands to install things because you’re guaranteeing that the binaries being installed by your commands are from official sources, and that is better (in at least some cases) than cached binaries from something like nixpkgs, where the trust we are asked to give is that the cache is built correctly from source.
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.
I think that using some “custom” package names for internal args is not the best choice.
Anyway, later I’ll take a better look at it and probably contribute to it. Ty
Could you elaborate? I’m not the best programmer so I’m open to suggestions.
I saw that “version” and “update” are inside apps.yaml instead inside the program itself like “search”. I see why version helps to be there which gets updated with the list, but the update link looks more like a quirk to be inside apps list. And it would make sense to distinguish program version and apps list version.
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.
