5 ms·

Looks like a replacement for ye-olde PlayOnLinux, which if I ever move to Linux Desktop[0] was going to be something I would write my own tooling to replace[1].

Looks like a replacement for ye-olde PlayOnLinux, which if I ever move to Linux Desktop[0] was going to be something I would write my own tooling to replace[1]. It is not clear from looking over the website, but since bottles appear closely related to Flatpak I am wondering if they support being installed to a different path than the default. Flatpak doesn't allow you to do this in a piecemeal way[2], but it does allow you to set up more than one entire Flatpak environment to different paths[3]. I'm hoping bottles can at least manage that? [0] There are dozens of tools on my list for this, mostly around application and container management. [1] I am a very vocal critic of the way Linux Desktop does things, but Windows is becoming worse at an alarming rate so it will probably be the least-worst option in a few years. [2] A regression from features we had in desktop OSs since the 80s. [3] Not that any GUI frontend for it pays attention to that. sigh

bogwog 5y ago
Idk anything about bottles, but just curious why you would want that feature? Like, what is a compelling use case for it? You probably know this already, but the point of Flatpak is to offer sandboxing and packaging of all dependencies in an isolated way. Being able to install and run flatpaks from any directory seems like it’d be difficult to implement for little benefit. It’s a bad fit for the tech IMO, and unnecessary since AppImage already offers exactly that functionality, but without the sandboxing (and other) features.
- AnIdiotOnTheNet 5y ago
  > Idk anything about bottles, but just curious why you would want that feature? Like, what is a compelling use case for it? Being able to run some applications from super fast but small NVMe disk and less important ones from slow but huge spinning rust disk, being able to run applications from a network share, CD, USB stick, etc. Desktop OSs have been able to do these sorts of things since the 1980s without all the hoops Linux Desktop software makes you jump through to do them. > Being able to install and run flatpaks from any directory seems like it’d be difficult to implement for little benefit. If Flatpak had considered this ability from the beginning it wouldn't be. Hell it might not be that difficult now, I haven't looked at the source for Flatpak and how it does things behind the scenes is otherwise not documented as far as I can tell. As you mentioned, AppImage implements it without much difficulty, and AppImages can be securely isolated by firejail. Combining the two concepts in the same package shouldn't be that hard. Keep runtimes in "installations" and let applications exists as single-directory self-contained units wherever the user wants them. What is fundamentally difficult about this? > unnecessary since AppImage already offers exactly that functionality If AppImage were fast becoming the new standard in Linux Desktop application distribution we wouldn't be having this conversation.
  - bogwog 5y ago
    > Desktop OSs have been able to do these sorts of things since the 1980s without all the hoops Linux Desktop software makes you jump through to do them. Linux desktops can do this. Flatpak maybe can't (Idk, I don't use them that often, but I'd be surprised if they couldn't), but even before AppImage, Flatpak, Snap, etc you could always just run an application from wherever you want. You could do that 20 years ago, and you can do it today. Desktops in the 80s didn't have sandboxing, but modern Linux desktops do. You can either implement sandboxing yourself through syscalls, use something like Systemd, or use the significantly more user friendly Flatpaks. ...Or don't use sandboxing at all, and do whatever you want. Download a (hopefully statically-linked) ELF from the internet, chmod +x it, then execute. > standard in Linux Desktop application distribution There is no such thing. There never has been, and there never will be :P
    - AnIdiotOnTheNet 5y ago
      - bogwog 5y ago
        Oh sorry, I didn't realize that I was the asshole. Thanks for clearing that up.
        mechanical_bear 5y ago
        Right? After that rant…
      - opan 5y ago
        I would much rather see Guix or Nix become the standard than Flatpak/AppImage/Snaps.
        AnIdiotOnTheNet 5y ago
        Yeah, a lot of people would, but I honestly can't see why. Application management on Linux is already complicated enough without having to learn a new language to use it effectively. I get that many people find value in its declarative nature, but the reason I think that is so attractive is that the current paradigm is so utterly terrible it makes what should be a relatively niche requirement (declarative application management) look like a good general solution.
gjs278 5y ago
FengLengshun 5y ago
> if they support being installed to a different path than the default. There is an AppImage version if you want that. Also have snap, .deb, AUR, and dnf install options, from what I saw on their Installation page. It used to be AppImage that they push until after some discussion makes them push Flatpak version more.
pxeger1 5y ago
> [0] There are dozens of tools on my list for this, mostly around application and container management. Could you share that list? I've had precisely the opposite problem with container management - whenever I have to use Windows, I find container management so unwieldy. And what do you mean by "application management"?

bogwog 5y ago

Idk anything about bottles, but just curious why you would want that feature? Like, what is a compelling use case for it? You probably know this already, but the point of Flatpak is to offer sandboxing and packaging of all dependencies in an isolated way. Being able to install and run flatpaks from any directory seems like it’d be difficult to implement for little benefit. It’s a bad fit for the tech IMO, and unnecessary since AppImage already offers exactly that functionality, but without the sandboxing (and other) features.

AnIdiotOnTheNet 5y ago
> Idk anything about bottles, but just curious why you would want that feature? Like, what is a compelling use case for it? Being able to run some applications from super fast but small NVMe disk and less important ones from slow but huge spinning rust disk, being able to run applications from a network share, CD, USB stick, etc. Desktop OSs have been able to do these sorts of things since the 1980s without all the hoops Linux Desktop software makes you jump through to do them. > Being able to install and run flatpaks from any directory seems like it’d be difficult to implement for little benefit. If Flatpak had considered this ability from the beginning it wouldn't be. Hell it might not be that difficult now, I haven't looked at the source for Flatpak and how it does things behind the scenes is otherwise not documented as far as I can tell. As you mentioned, AppImage implements it without much difficulty, and AppImages can be securely isolated by firejail. Combining the two concepts in the same package shouldn't be that hard. Keep runtimes in "installations" and let applications exists as single-directory self-contained units wherever the user wants them. What is fundamentally difficult about this? > unnecessary since AppImage already offers exactly that functionality If AppImage were fast becoming the new standard in Linux Desktop application distribution we wouldn't be having this conversation.
- bogwog 5y ago
  > Desktop OSs have been able to do these sorts of things since the 1980s without all the hoops Linux Desktop software makes you jump through to do them. Linux desktops can do this. Flatpak maybe can't (Idk, I don't use them that often, but I'd be surprised if they couldn't), but even before AppImage, Flatpak, Snap, etc you could always just run an application from wherever you want. You could do that 20 years ago, and you can do it today. Desktops in the 80s didn't have sandboxing, but modern Linux desktops do. You can either implement sandboxing yourself through syscalls, use something like Systemd, or use the significantly more user friendly Flatpaks. ...Or don't use sandboxing at all, and do whatever you want. Download a (hopefully statically-linked) ELF from the internet, chmod +x it, then execute. > standard in Linux Desktop application distribution There is no such thing. There never has been, and there never will be :P
  - AnIdiotOnTheNet 5y ago
    - bogwog 5y ago
      Oh sorry, I didn't realize that I was the asshole. Thanks for clearing that up.
      - mechanical_bear 5y ago
        Right? After that rant…
    - opan 5y ago
      I would much rather see Guix or Nix become the standard than Flatpak/AppImage/Snaps.
      - AnIdiotOnTheNet 5y ago
        Yeah, a lot of people would, but I honestly can't see why. Application management on Linux is already complicated enough without having to learn a new language to use it effectively. I get that many people find value in its declarative nature, but the reason I think that is so attractive is that the current paradigm is so utterly terrible it makes what should be a relatively niche requirement (declarative application management) look like a good general solution.

gjs278 5y ago

FengLengshun 5y ago

> if they support being installed to a different path than the default. There is an AppImage version if you want that. Also have snap, .deb, AUR, and dnf install options, from what I saw on their Installation page. It used to be AppImage that they push until after some discussion makes them push Flatpak version more.

pxeger1 5y ago

> [0] There are dozens of tools on my list for this, mostly around application and container management. Could you share that list? I've had precisely the opposite problem with container management - whenever I have to use Windows, I find container management so unwieldy. And what do you mean by "application management"?