Part of what’s making learning Linux so difficult for me, is the idea of how fragmented it is. You can install programs with sudo apt get (program). You can get programs with snaps. You can get programs with flatpaks. You can install with tar.gz files. You can install with .deb files. You can get programs with .sh files. There’s probably more I don’t know about.

I don’t even know where all these programs are being installed. I haven’t learned how to uninstall them yet. And I’m sure that each way has a different way to uninstall too.

So that brings me to my main question. Why not consolidate all this? Sure, files CAN be installed anywhere if you want, but why not make a folder like /home/programs/ where it’s assumed that programs would be installed?

On windows the programs can be installed anywhere, but the default is C:/windows/Program Files x86/ or something like that. Now, you can change it all you want when you install the programs. I could install it to C:/Fuckfuckfuck/ if I wanted to. I don’t want to, so I leave it alone because C:/Windows/Program Files x86/ is where it’s assumed all the files are.

Furthermore, I see no benefit to installing 15 different programs in 7 different folders. I begrudgingly understand why there’s so many different installation methods, but I do NOT understand why as a collective community we can’t have something like a standardized setting in each distro that you can set 1 place for all your installation files.

Because of the fragmentation of distros, I can understand why we can’t have a standardized location across all distros like Windows has. However I DON’T see why we can’t have a setting that gets set upon each first boot after installation that tells each future installation which folder to install to.

I would personally pick /Home/Programs/, but maybe you want /root/Jamies Files/ because you’re Jamie, and those are your files.

In either case, as we boot up during the install, it would ask us where we want our program files installed. And from then on, no matter what method of install you chose, it would default to whatever your chosen folder was.

Now, you could still install other places too, but you would need to direct that on a per install basis.

So what’s the benefit of having programs each installed in seperate locations that are wildly different?

  • Jumuta@sh.itjust.worksEnglish
    31·
    5 days ago

    there’s different ways to install things because they each have their use cases in which they’re better than others (or used to have use cases)

    • binary package managers (e.g. apt): fast and lightweight because it only downloads/installs the necessary binaries

    • flatpak: can be installed on any distro, but takes up more storage space because they’re installed in a sandbox and all the dependencies are also installed with it, for every application

    • snap: same thing as flatpak but a bit worse, but some applications are only packaged for snap because canonical paid a lot of big companies to package for snap (rhey didn’t incentivise against flatpak, they just didn’t fund flatpak)

    • appimage: the ‘windows exe’ kinda thing and has all the dependencies bundled so distro agnostic, but you have to manage the appimage files yourself unless you get a manager for it and you can’t update them centrally like you can do with other stuff

    • source code repos (e.g. aur): have to compile every new version yourself on your machine, so is slow to update, but often offers things not in the binary package manager

    • .sh files for installation: idk why these are used, they’re just annoying. a lot of proprietary software from corpos use them (probably so they can verify dependencies themselves and not trust the system)

    • binariy files (e.g. .deb): same thing as with appimage except they’re not distro agnostic

    • tar.gz: is just a compressed file format like zip

    • Daemon Silverstein@thelemmy.clubEnglish
      3·
      4 days ago

      .sh files for installation: idk why these are used, they’re just annoying. a lot of proprietary software from corpos use them (probably so they can verify dependencies themselves and not trust the system)

      GOG (Good Old Games) distributes the games using a .sh file containing all the binaries and assets needed for the game. It’s strange to think of, but the binary data coexists with textual shellscript instructions, thanks to the exit instruction (which ensures that the shell won’t try to interpret the binary data) alongside some awk/grep/tail wizardry to extract the binary data from the current shellscript.

      It’s probably because .sh can run in any distro, because every distro has a shell interpreter. Also, they don’t need to be compiled (differently from .appimage, for example), it’s just a merge of a .sh and a binary archive (possibly .tar.gz).

    • DarkThoughts@fedia.io
      1·
      4 days ago

      .sh files are shell scripts, they’re comparable to Windows batch files or newer powershell scripts. They can be useful for tools with lots of dependencies which they then download on their own, so you often see them when you want to install something like LLM tools from Github or whatever. They’re easy to put together and easy to edit, even for the user itself, unlike a precompiled installer.