4 ms·

> 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

> 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.
      - opan 5y ago
        I can point out that Guix uses Guile, a scheme, something someone may already know before using Guix, but I think a more interesting perspective is that of the simple user. What Guix and Nix give you are a package manager that can be used with a signature distro or installed upon another distro, and that package manager makes an effort to be the last package manager you'll need. Both of them are packaging the normal types of programs you'd expect, but also emacs packages, vim plugins, python packages, rust packages, go packages, and so on. Nearly every guix upgrade I do shows me that a bunch of new r-foo packages (R-lang stuff) got packaged. The way I see it, with enough time and manpower, these package managers will have just about everything you'd ever need (exceptions for things like proprietary software, mainly in the case of guix, although these can and do still exist in unofficial channels). Even in their current state they are good enough at doing this that I'm able to get all my emacs packages from the package manager and not use elpa/melpa at all. This also gives you rollbacks for free. If an emacs plugin breaks, you can roll back to a previous generation, and optionally do a partial upgrade to then re-upgrade everything except that broken package. This process is basically instant as it's just moving some symlinks around in the store. You can also have multiple versions of programs installed without issues, and until you do garbage collection, you likely do by default. Declarative package manager is also cool even as a regular user. If you choose to use a guix manifest to manage your user's packages, you have a good visual of everything you've intentionally installed on your system (not cluttered up with the deps they pulled in), and you can easily add/remove them with a text editor + re-running a command afterward to reapply the manifest. I don't consider myself a programmer, and I have not built packages for most distros (I have made a guix package or two locally with some help, but never submitted them upstream), so I thought my perspective as someone using these tools may be valuable. I wouldn't say I ever learned the nix lang or guile to any sort of level of fluency. I basically treat a configuration.nix or config.scm the same way I treat my sway config, neovim config, and so on. The syntax is a little complicated, but the community is there to help, and there's also the documentation. I just know enough to get by as a regular user and I still greatly appreciate guix.
michaelmrose 5y ago
> Being able to run some applications from super fast but small NVMe disk and less important ones from slow but huge spinning rust disk 1TB NVME drives aren't very expensive on the order of $80-$100 US. This is already big enough for your entire OS even with several very large games installed. The natural split if you have multiple drives would be between OS and backups/multimedia. I see this immediately being used for pirated software and games. It could also be used to implement a cross platform app store like interface to install legitimate software. It could even be integrated with the same store interface as one uses to install traditional packages and flatpaks for a true one stop shop.
- AnIdiotOnTheNet 5y ago
  > 1TB NVME drives aren't very expensive on the order of $80-$100 US. That isn't the point. I have in my possession several small form factor computers that have 16GB disks in them. "just spend $80-100 each on them" is not a good excuse for having such an inflexible system that it demands everything be on one disk. The original Mac did this on floppies in 1984. It is 2021, our software should be able to do better.
  - michaelmrose 5y ago
    You have several toys. The purpose of software isn't to optimize for an interesting use case you have devised for your toys it's for actual machines to provide useful work and engaging play. Faster file access for limited files is accomplished by - caching in ram - on disk cache - an explicit read cache device All of these are broadly applicable and effective to the other 99.9% of actual devices.
    - deleted 5y ago
      [deleted]
  - OOPMan 5y ago
    Right...I get where you're coming from but I think where you're coming from is indicative of the why things changed. It's neat old Mac's from the 80s could to do that...but they had to be able to do that in order to be useful. In other words, it wasn't a "cool feature", it was something they had to be able to do. I imagine that when storage became more plentiful OS developers became less interested in implementing solutions to problems of this nature and who can blame them really. Supporting a use-case that almost no one cares about anymore is rather unrewarding. As others have mentioned, there are plenty of ways to achieve this on Linux today, they just seem to involve more fiddling than you'd like. That, unfortunately, is the nature of the beast. Linux is a tinkerers OS (that just happened to become popular for servers) and expecting it to change its stripes is asking a lot :-)

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.
    - opan 5y ago
      I can point out that Guix uses Guile, a scheme, something someone may already know before using Guix, but I think a more interesting perspective is that of the simple user. What Guix and Nix give you are a package manager that can be used with a signature distro or installed upon another distro, and that package manager makes an effort to be the last package manager you'll need. Both of them are packaging the normal types of programs you'd expect, but also emacs packages, vim plugins, python packages, rust packages, go packages, and so on. Nearly every guix upgrade I do shows me that a bunch of new r-foo packages (R-lang stuff) got packaged. The way I see it, with enough time and manpower, these package managers will have just about everything you'd ever need (exceptions for things like proprietary software, mainly in the case of guix, although these can and do still exist in unofficial channels). Even in their current state they are good enough at doing this that I'm able to get all my emacs packages from the package manager and not use elpa/melpa at all. This also gives you rollbacks for free. If an emacs plugin breaks, you can roll back to a previous generation, and optionally do a partial upgrade to then re-upgrade everything except that broken package. This process is basically instant as it's just moving some symlinks around in the store. You can also have multiple versions of programs installed without issues, and until you do garbage collection, you likely do by default. Declarative package manager is also cool even as a regular user. If you choose to use a guix manifest to manage your user's packages, you have a good visual of everything you've intentionally installed on your system (not cluttered up with the deps they pulled in), and you can easily add/remove them with a text editor + re-running a command afterward to reapply the manifest. I don't consider myself a programmer, and I have not built packages for most distros (I have made a guix package or two locally with some help, but never submitted them upstream), so I thought my perspective as someone using these tools may be valuable. I wouldn't say I ever learned the nix lang or guile to any sort of level of fluency. I basically treat a configuration.nix or config.scm the same way I treat my sway config, neovim config, and so on. The syntax is a little complicated, but the community is there to help, and there's also the documentation. I just know enough to get by as a regular user and I still greatly appreciate guix.

michaelmrose 5y ago

> Being able to run some applications from super fast but small NVMe disk and less important ones from slow but huge spinning rust disk 1TB NVME drives aren't very expensive on the order of $80-$100 US. This is already big enough for your entire OS even with several very large games installed. The natural split if you have multiple drives would be between OS and backups/multimedia. I see this immediately being used for pirated software and games. It could also be used to implement a cross platform app store like interface to install legitimate software. It could even be integrated with the same store interface as one uses to install traditional packages and flatpaks for a true one stop shop.

AnIdiotOnTheNet 5y ago
> 1TB NVME drives aren't very expensive on the order of $80-$100 US. That isn't the point. I have in my possession several small form factor computers that have 16GB disks in them. "just spend $80-100 each on them" is not a good excuse for having such an inflexible system that it demands everything be on one disk. The original Mac did this on floppies in 1984. It is 2021, our software should be able to do better.
- michaelmrose 5y ago
  You have several toys. The purpose of software isn't to optimize for an interesting use case you have devised for your toys it's for actual machines to provide useful work and engaging play. Faster file access for limited files is accomplished by - caching in ram - on disk cache - an explicit read cache device All of these are broadly applicable and effective to the other 99.9% of actual devices.
  - deleted 5y ago
    [deleted]
- OOPMan 5y ago
  Right...I get where you're coming from but I think where you're coming from is indicative of the why things changed. It's neat old Mac's from the 80s could to do that...but they had to be able to do that in order to be useful. In other words, it wasn't a "cool feature", it was something they had to be able to do. I imagine that when storage became more plentiful OS developers became less interested in implementing solutions to problems of this nature and who can blame them really. Supporting a use-case that almost no one cares about anymore is rather unrewarding. As others have mentioned, there are plenty of ways to achieve this on Linux today, they just seem to involve more fiddling than you'd like. That, unfortunately, is the nature of the beast. Linux is a tinkerers OS (that just happened to become popular for servers) and expecting it to change its stripes is asking a lot :-)