4 ms·

what do you mean you wanted to install applications to an external disk? if you have a separate OS on the external drive, you could chroot in and install it.

what do you mean you wanted to install applications to an external disk? if you have a separate OS on the external drive, you could chroot in and install it. If you just want that one application to be on the other disk, you could mount it to wherever on the filesystem the program would be installed. However you probably don't wanna do that on an application by application basis. you could mount /usr/bin/ on the external drive for example. or use LVM to share disk space between the disks Flatpak, Snap, Appimage and other portable format aren't really preferable. they lead to a software ecosystem that amounts to just downloading and running executable binaries off the internet, each with their own overhead.

AnIdiotOnTheNet 6y ago
> what do you mean you wanted to install applications to an external disk? Kinda illustrates my point about this being a foreign concept to Linux Desktop people. It's pretty simple: I want to put an application on an external disk and run it from there. > if you have a separate OS on the external drive, you could chroot in and install it. No thanks. I'd just like to have the application stored on an external disk, and execute it on the OS I have installed. > If you just want that one application to be on the other disk, you could mount it to wherever on the filesystem the program would be installed. Not really, because Linux likes to have an application spread its files all over the hierarchy, so in reality I need to either use some form of union-mounting, and/or simlinks. Of course that is only sufficient if there are no library conflicts between what the application wants and what the system uses, in that case I need to use LD_LIBRARY_PATH and other tricks. In some cases I'll need to use a launch script that calls a different ld.so. That's a lot of hoops compared to how sane operating systems do it. > LVM to share disk space between the disks System breaks when disk is removed. No good. > Flatpak, Snap, Appimage and other portable format aren't really preferable. they lead to a software ecosystem that amounts to just downloading and running executable binaries off the internet, each with their own overhead. Which is pretty much what I want, because the alternative is dealing with the bullshit I mentioned above whenever you step outside the package manager's sandbox.
- monocasa 6y ago
  NixOS gets you there I think. They deviate from the standard hierarchy to keep each application in its own directory that could be installed on it's own drive if need be, then with symlinks back to the main tree for legacy purposes. Like /bin/sh would be a symlink to /nix/store/s/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/bash but only because there's enough legacy out there that expects /bin/sh to be runnable verbatim.
  - AnIdiotOnTheNet 6y ago
    Now if only I didn't need to learn a new language in addition to all the OS tooling to use NixOS. This is what AppImage gets that the rest of Linux doesn't seem to: if an application is a single file/folder, you don't need anything more complicated than a file manager to manage it. P.S.: after a quick glance at some documentation, I don't see any mechanism that would allow me to install nix packages to arbitrary locations anyway.
- drran 6y ago
  You mean you want an actual installer, like in DOS or Windows? IMHO, it's crazy. I had similar problem. I joined two physical disks into one logical using LVM and forgot about problem. :-/
  - AnIdiotOnTheNet 6y ago
    > You mean you want an actual installer, like in DOS or Windows? IMHO, it's crazy. Well that's still better, in my opinion, than package managers and all their various restrictions. But ideally I want something like AppImage, where an application is a singular entity that can just be moved at will and run from wherever [0]. Most DOS programs and many Windows programs (if you extract them from the installer) will still work like that. > I had similar problem. I joined two physical disks into one logical using LVM and forgot about problem. :-/ If you unplug the external disk, your system stops working. This is not what I want, as I mentioned already in the post you're replying to. [0] classic MacOS, RiscOS, and NeXT all had programs that worked like this too. Linux has yet to achieve the flexibility in application management afforded by the OSs of the 1980s.

AnIdiotOnTheNet 6y ago

> what do you mean you wanted to install applications to an external disk? Kinda illustrates my point about this being a foreign concept to Linux Desktop people. It's pretty simple: I want to put an application on an external disk and run it from there. > if you have a separate OS on the external drive, you could chroot in and install it. No thanks. I'd just like to have the application stored on an external disk, and execute it on the OS I have installed. > If you just want that one application to be on the other disk, you could mount it to wherever on the filesystem the program would be installed. Not really, because Linux likes to have an application spread its files all over the hierarchy, so in reality I need to either use some form of union-mounting, and/or simlinks. Of course that is only sufficient if there are no library conflicts between what the application wants and what the system uses, in that case I need to use LD_LIBRARY_PATH and other tricks. In some cases I'll need to use a launch script that calls a different ld.so. That's a lot of hoops compared to how sane operating systems do it. > LVM to share disk space between the disks System breaks when disk is removed. No good. > Flatpak, Snap, Appimage and other portable format aren't really preferable. they lead to a software ecosystem that amounts to just downloading and running executable binaries off the internet, each with their own overhead. Which is pretty much what I want, because the alternative is dealing with the bullshit I mentioned above whenever you step outside the package manager's sandbox.

monocasa 6y ago
NixOS gets you there I think. They deviate from the standard hierarchy to keep each application in its own directory that could be installed on it's own drive if need be, then with symlinks back to the main tree for legacy purposes. Like /bin/sh would be a symlink to /nix/store/s/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/bash but only because there's enough legacy out there that expects /bin/sh to be runnable verbatim.
- AnIdiotOnTheNet 6y ago
  Now if only I didn't need to learn a new language in addition to all the OS tooling to use NixOS. This is what AppImage gets that the rest of Linux doesn't seem to: if an application is a single file/folder, you don't need anything more complicated than a file manager to manage it. P.S.: after a quick glance at some documentation, I don't see any mechanism that would allow me to install nix packages to arbitrary locations anyway.
drran 6y ago
You mean you want an actual installer, like in DOS or Windows? IMHO, it's crazy. I had similar problem. I joined two physical disks into one logical using LVM and forgot about problem. :-/
- AnIdiotOnTheNet 6y ago
  > You mean you want an actual installer, like in DOS or Windows? IMHO, it's crazy. Well that's still better, in my opinion, than package managers and all their various restrictions. But ideally I want something like AppImage, where an application is a singular entity that can just be moved at will and run from wherever [0]. Most DOS programs and many Windows programs (if you extract them from the installer) will still work like that. > I had similar problem. I joined two physical disks into one logical using LVM and forgot about problem. :-/ If you unplug the external disk, your system stops working. This is not what I want, as I mentioned already in the post you're replying to. [0] classic MacOS, RiscOS, and NeXT all had programs that worked like this too. Linux has yet to achieve the flexibility in application management afforded by the OSs of the 1980s.