4 ms·

> They're also ludicrously inflexible in that they don't allow multiple versions of the same application to be installed They actually do allow multiple versio

> They're also ludicrously inflexible in that they don't allow multiple versions of the same application to be installed They actually do allow multiple versions of the same application to be installed. It's just difficult to get it to work. The package itself will install to (for example) /usr/bin. A new version of the package will have the same file names, so they get overwritten. Most well-built packages will allow you to override the installation path though. This is perfect in case you want to install to your home directory (instead of globally) or some versioned directory. For example you can relocate RPM installations given an example.rpm file: rpm -i --relocate=/=/home/myuser example.rpm

AnIdiotOnTheNet 8y ago
Correct me if I'm wrong, but won't all of the dependencies also need to be installed to the same prefix? So I could end up with half the OS on there for one application?
- inetknght 8y ago
  When you stray from the beaten PATH (and LD_LIBRARY_PATH) then yes you can start encountering trouble. Most good tools provide the options for you to do that. If you want to start building from scratch then `configure` and `make` often have PREFIX (and flavors such as BINPREFIX, LIBPREFIX, etc). `cmake` has similar variables to control where it looks for dependencies. Other languages' tools undoubtedly do too. I highly recommend you to read the documentation of the tools you use. And when all else fails, there's docker.
  - AnIdiotOnTheNet 8y ago
    In other words, I can get what I want, which is very simple on Windows and Mac, in Linux by compiling things from source or otherwise jumping through a bunch of containerization hoops. No thanks.
    - inetknght 8y ago
      Unfortunately for now :) One of the awesome things about Linux and it being open source is that if you don't like it then you can work to improve it.
      - AnIdiotOnTheNet 8y ago
        Theoretically, yes, realistically, not really. For all its talk of openness and freedom for the user, the Linux community has a remarkable amount of disdain for anyone who isn't a C greybeard. AppImage has already pretty much solved everything I want as far as application distribution. It is at least the third such implementation that has. However, the community refuses to embrace it and so very little software is distributed that way, just like the last two times.
        inetknght 8y ago
        > the Linux community has a remarkable amount of disdain for anyone who isn't a C greybeard I feel like you're the one providing disdain simply by saying "greybeard". Please don't disrespect people who have lots of C experience. I've found plenty of non-C applications in Ubuntu's and Fedora's repositories though. I've found Python, Ruby, and Perl applications and developer tools (in addition to the obvious C and C++ ones). That's just off the top of my head. Erlang, Ocaml, R, and (maybe?) D also exist. Of course there's also the package-building tools. Mailing lists and bug reports are usually open to the public too. And there's usually policies around offensive behavior. If you see a problem that hasn't been addressed satisfactorily then I highly encourage you to bring it forward to the maintainers. > AppImage has already pretty much solved everything I want as far as application distribution. It is at least the third such implementation that has. Search engine brought me here: https://appimage.org/ https://appimage.org/ It looks like it supports every major Linux distribution I've come across. Then what's stopping you from using it? > the community refuses to embrace it and so very little software is distributed that way, just like the last two times. This sounds like you need to get application developers on board. Get software developers to provide an AppImage of their application. Make sure to include source code for distributions to build their own version of the AppImage -- including any patches which might be necessary to tweak and support the distributions' different and unique environments.

AnIdiotOnTheNet 8y ago

Correct me if I'm wrong, but won't all of the dependencies also need to be installed to the same prefix? So I could end up with half the OS on there for one application?

inetknght 8y ago
When you stray from the beaten PATH (and LD_LIBRARY_PATH) then yes you can start encountering trouble. Most good tools provide the options for you to do that. If you want to start building from scratch then `configure` and `make` often have PREFIX (and flavors such as BINPREFIX, LIBPREFIX, etc). `cmake` has similar variables to control where it looks for dependencies. Other languages' tools undoubtedly do too. I highly recommend you to read the documentation of the tools you use. And when all else fails, there's docker.
- AnIdiotOnTheNet 8y ago
  In other words, I can get what I want, which is very simple on Windows and Mac, in Linux by compiling things from source or otherwise jumping through a bunch of containerization hoops. No thanks.
  - inetknght 8y ago
    Unfortunately for now :) One of the awesome things about Linux and it being open source is that if you don't like it then you can work to improve it.
    - AnIdiotOnTheNet 8y ago
      Theoretically, yes, realistically, not really. For all its talk of openness and freedom for the user, the Linux community has a remarkable amount of disdain for anyone who isn't a C greybeard. AppImage has already pretty much solved everything I want as far as application distribution. It is at least the third such implementation that has. However, the community refuses to embrace it and so very little software is distributed that way, just like the last two times.
      - inetknght 8y ago
        > the Linux community has a remarkable amount of disdain for anyone who isn't a C greybeard I feel like you're the one providing disdain simply by saying "greybeard". Please don't disrespect people who have lots of C experience. I've found plenty of non-C applications in Ubuntu's and Fedora's repositories though. I've found Python, Ruby, and Perl applications and developer tools (in addition to the obvious C and C++ ones). That's just off the top of my head. Erlang, Ocaml, R, and (maybe?) D also exist. Of course there's also the package-building tools. Mailing lists and bug reports are usually open to the public too. And there's usually policies around offensive behavior. If you see a problem that hasn't been addressed satisfactorily then I highly encourage you to bring it forward to the maintainers. > AppImage has already pretty much solved everything I want as far as application distribution. It is at least the third such implementation that has. Search engine brought me here: https://appimage.org/ https://appimage.org/ It looks like it supports every major Linux distribution I've come across. Then what's stopping you from using it? > the community refuses to embrace it and so very little software is distributed that way, just like the last two times. This sounds like you need to get application developers on board. Get software developers to provide an AppImage of their application. Make sure to include source code for distributions to build their own version of the AppImage -- including any patches which might be necessary to tweak and support the distributions' different and unique environments.