Linux

We’ve Been Installing Apps on Linux WRONG!



Did you know that developers have an intended way to install your programs? Turns out most distributions (and people) willfully ignore them. What can we do to install our programs the “right” way? Do I really need to use Vim as an AppImage??

Website:

Donate:
✨ Patreon:
▶️ YouTube Membership:

Links:
▶️ YouTube:
📒 Odysee:
🦑 Peertube:
🐘 Mastodon:
𝕏 (Formerly Twitter):
📁 Gitlab:

🪙 Crypto:
XMR: 84ZpcYxjfkT7uFGXgmi2jH2wyhUBMx8hGBJ3sAp478rKSShMAJHR3DhVVPSwCAskReRBPifzpA5Vu7HPpzAxHUux3SFS4bh

👇 Sauce:

Chapters:
0:00 The GUI Lies…
3:26 The “””Intended””” Way
6:29 Peeling Back the Layer
10:11 Not Everyone Is an Admin
13:04 Outro

[ad_2]

source

Related Articles

49 Comments

  1. As arch linux user I still hate how to uninstalling app and I already did face "you can't uninstall this app because this dependency is needed with another package" twice and it suck

  2. I trust the repos more only because maintainers, I would like to believe, have better insight to how the application of some developer will interact with the distro. My first choice is the distro not the application. Alternatives exist and if the confusion or concern is too much, change the workflow.

    This is why i stay away from flatpaks, snaps and appimages as much as possible. Never ran into an issue for application availability.

  3. Then people make fun of people who don't use linux because they don't want to do this. Look there are ways to have distros that want to use terminals for updating and etc..
    A great example is of Rhino LInux. It was so easy to install my Nvidia drivers, that I thought it was genius. Needed to put a simple line in and choose your driver. I am sure Arch Linux has a good way of doing it too.

    Or for distros that prefer guis is too looking at how Manjero does it for some of the drivers. The way they do drivers for my gpu is awesome and the way you can swap the kernel version is great too. I got my issues with that os however, it's a good way of dealing with it

    I wanted to try Fedora but it's annoying to get my drivers I need, so I don't want to touch that with a ten foot pole.

  4. I use almost all arch packages, some AUR and a bit of flatpak or compile manually.

    The best packages are the on from your distro if it is availablez this does not mean officially. In the case of arch are well maintained.

    The maintainer in most case do with things, the KeePassxc debian and others are an exception.

  5. Opensnitch is available in arch, Debian and Ubuntu repos as well as nix-pkg and gentoo. Besides that, sometimes there is a good reason software doesn’t manage to get picked up by distributions or flathub, for example if it doesn’t pass the quality control or malware screening.

  6. Some kind of FlatpakImage that can run without installing with an option to install as a regular flatpak that integrates into updates as well, could be the perfect in-between for putting up on the website.
    Given AppImage isn't 100% bundled, I think we could pretend flatpak being installed as a requirement could become universal (neither works on Ubuntu OOTB anyway) though bundling or not bundling runtimes could be… controversial.

  7. Okay, so the correct thing in most cases is to just use package manager version, the updates are integrated, the distro's security team are patching those…

    Ubuntu is weird due to their extreme push for snaps, not a good example generally on a few things due to that. Ultimately though, the developer is never going to be testing your exact setup. Your CPU is different, the amount and speed of your memory is different, your GPU is different, your partitioning is different… No developer can test all configurations, this is where distros are actually sometimes the best at testing a wide range of configurations. Things one should note though, the biggest reason developers do not like this is because distribution packages are often a bit behind the developer, this is good, they are more mature and well tested usually, less likely a very recent change causes a crash, but and this is a big but, they often get flooded with bug reports that either are a. already fixed in latest version or b. are due to something the distribution packagers are doing, the answer here is to report your bug fixes to the distribution first.

  8. As an Arch Linux user, this isn't much of an issue for me. Packages I need are almost always in the Arch repositories or the AUR, so I'm covered. Plus, I'm not really a fan of Flatpaks and Snaps.

  9. But the issue also is that the devs test their packages only on their preferred system. Which then makes problems across different distros, like for example davinci, is officially tested and supported only on Rocky Linux and CentOS. Would that mean that we all need to install different distro just for that software? No it's bs. Another example would be Heroic flatpak just being broken, even if that's the official preferred way. I still just prefer using copr repos for that on fedora, because it's better experience. Distro repos with repackaged software may annoy devs, but in reality it helps a ton. No dev will test their app on 30 different distros to make sure their appimage or flatpak work everywhere the same.

    Do I also think situations like the keepassXC on debian is ridiculous? Yes. But that should be the distro maintainers dealing with the situation, and setting some guidelines on repackaging so that this situation doesn't happen, and not the devs needing to fight people on debian.

  10. Valve also had to solve this problem with Proton, they couldn't rely on the system supporting everything it needed, so they basically built their own distrobox called Pressure Vessel. i'm not convinced its the best way to go though, for apps that expect different systems, its another layer of management, and i already can't manage the inconsistent ways applications use ~/config, ~/local/share, and then on top of that managing flatpak and snap configs, and then all my wine prefixes because Lutris and Steam think its necessary to make a new prefix for each game, and Steam doesn't even label them!!!

    so yeah, i'm using the AUR. i'm sorry devs, if you don't like it, i'll try to report bugs to the maintainer first, but no promises.

  11. yeah no, I've already had enough of doing it the windows way. I'm sticking to the package manager, much better experience even if I have to go to the manjaro forums instead of the dev forums

  12. this is not amazing advice, your distrobutions package repository has patches and optimizations for your specific distro, and in many cases should have the best experience. i know some developers don't love that, but its good for storage use, memory usage, system integration, and often security patches, when you use distro packages . also, if you're on nixos you should use nixpkgs whenever you can, as software often needs patches to work correctly on that system, and installing via other means can cause issues .

  13. The correct way o install something, is whatever way works for you.
    I usually check if it's on the default repository, if it's not, I check if there is a ppa, if no I look for an AppImage, if not I either install from source or use a flatpak.

  14. Once again I have never been more excited to see your video on such a beautiful night but now I’m grateful that I have pre compiled my apps and programs on Linux Android Mac Windows iOS etc I am very confident on my abilities to improve myself and my whole being and all that thanks for your efforts Mr Matt

  15. There has always been tensions between package maintainers and upstream projects. Upstream projects' main goals is not to maintain software, but rather to develop it. Testing all combinations of various distros/package managers is not a feasible task for most developers, especially so if they're open source. And so the task of maintaining compatibility of the packages and your distro is up to the package maintainers.

    As an example, there are some packages that haven't had a single line of code added to by the upstream developers that is constantly receiving bugfixes and security updates from Debian maintainers.

    However, problems arise when there is a disagreement as to the vision of what the software should do between the upstream developer and the downstream maintainer. Developers may only cater to a specific subset of the total use cases of their software, or they may be adding a lot of unecessary cruft in the software that can mess with the end user, or the software hasn't been maintained by upstream since forever. Maintainers can and have patched upstream software to the point that it is arguably a very different software at that point. This is a big problem also for end users that have a mismatch of their expectation with their software they were advertised and what they got. Both have valid reasons to have grievances with each other.

    In the end, it is a matter of use case and preference. If upstream has been broken for so long, chances are that your package manager has a patch for that in their repos already. If downstream maintainers are being anachronistic, then install from source.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button