Hacker News Reader

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.

> 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.

> 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

> 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.

> 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.

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.

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 :-)

> 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.

You say this like making an application this way is some difficult problem. The whole point of me pointing out that it was the way applications worked on a Mac in 1984 (or indeed any of a dozen other desktop OSs) is that it isn't actually difficult at all. The difficulty it appears to have on Linux is all artificially induced by the culture of Linux software development.

> Linux is a tinkerers OS (that just happened to become popular for servers) and expecting it to change its stripes is asking a lot :-)

I don't expect it to change. I've been hoping Linux people would see the light for 20 years and it hasn't changed. That doesn't mean I have to like it or pretend that it's a good idea.

> [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"?

> 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.