Instead of having some minimal set of conventions of where things are supposed to be stored, instead of allowing static libraries to actually work it seems that the solution is to now include the whole system instead. After all storage is cheap right?.
Flatpak is not the future (2021)
61–70 of 166 posts
Re: Flatpak is not the future (2021)
#62Related: https://blog.brixit.nl/developers-are-lazy-thus-flatpak/
Re: Flatpak is not the future (2021)
#63Neither are snaps. The future, for regular daily use, are appimages. Much like MacOS dmgs, these are a "single" file (from an end user perspective) that you download, double click, and run. That's it. Ideally we'd see more work in this area. I am slowly trying to figure out how to automate builds for GUI apps and I am considering somehow settings up an inexpensive server to pull, package, and submit appimages to appi…
Re: Flatpak is not the future (2021)
#64But it's the present. And a godsend. I'm using it for current Firefox, Zotero, Joplin and two or three more programs, none of which are packaged in Debian (except Firefox, but only the LTS version that doesn't work with all my extensions). Unless you can offer something better, I'll keep using it.
Isn't that just because you aren't using a decent distro? I mean I am surprised that firefox or librewolf or whatever fork is not packaged by Debian in a current version.
Re: Flatpak is not the future (2021)
#65I'm curious how all of this compares to macOS's .app packages.
• Both use reverse DNS to globally identify themselves, neither actually verifies DNS ownership.
• Almost everything is a bundle, except for CLI apps. FlatPaks on the other hand are being auto-converted from previous packaging systems.
• Bundles don't have dependencies. In theory they can, but in practice they never do. You depend on macOS/iOS as a unitary platform and bundles expose what the min version they require is.
• There is no update mechanism except the app store. If you want that you need to use something like Sparkle. A tool like Hydraulic Conveyor [1] can create a bundle with integrated Sparkle for your cross platform application without needing a Mac. Likewise no attempt to deduplicate redundant files. Interestingly, if you use the latest MSIX tech on Windows then the OS will deduplicate shared files (including libs) that are bundled with apps, in a transparent manner.
• Sandboxing is optional on macOS. If you don't opt in, you are put inside a relatively weak sandbox that just blocks access to a few folders in your home directory and stops you tampering with other apps/the OS. If you do opt in, you get a PowerBox design that's like what FlatPak is trying with portals. There's no way in the UI to see if an app is sandboxed because it's intended as a vulnerability mitigation and not a way to run untrusted code.
• Both bundles and the binaries within those bundles advertise which version of macOS/iOS they're expecting, and the OS frameworks can change behaviors depending on that for backwards compatibility reasons. It's a bit easier to maintain compatibility with Objective-C APIs than with C++, but still, Apple does it for all their APIs including the C++ ones.
[1] https://hydraulic.dev/ (disclosure: my company)
Re: Flatpak is not the future (2021)
#66Earlier quoted context omitted.
AppImages waste even more disk space. At least with Flatpak I only need to install libraries once, with AppImages I'm getting a second copy of everything with every application I download. If AppImages were actually directories, like they are in macOS, I could at least run duperemove to fix the disk space issue on BTRFS, but with full images that become a lot harder.
Technically speaking appimages are compressed files so maybe someone clever can come up with an idea on how to dedupe them. With mass adoption this issue i think may be solved by someone concerned about disk space. Personally, and probably many casual users, are not as worried about space as they are about convenience. But I think your point is valid, and I think this would make an interesting side project for someon…
Re: Flatpak is not the future (2021)
#67"Ah, but that was during Covid when a disproportionate amount of people were working from home and a lot of the normal feedback loops weren't running normally. Those were lonely/different times. I'll consider this article accordingly."
It's not really rationale/logical/founded, but that's where my brain kind of initially goes. Do others experience this?
Re: Flatpak is not the future (2021)
#68I think it's an unfortunate necessity for some kinds of applications. Eg, we make this: https://overte.org/ We're currently using AppImage because that was the first thing that worked for us, but most of the reasons are the same either way: We want to spend time developing the software, and that means it's hard to justify packaging every release for a dozen distributions. And I'd say nobody particularly wants to do i…
While the problems you cited certainly need to be solved by the Linux ecosystem, I don't see why that solution should involve the heavy-handed sandboxing with a thousand overlayfs, containers and whatnot. I wish there was a more straightforward solution that didn't have so many complicated moving parts, more like the static binaries that I get from Go or Rust.
One reason is that big applications can have many dependencies, and once in a while I find something dlopens something from the host filesystem, finds something incompatible and crashes. So I really want my stuff to run in a sandbox where I know exactly what it's loading and there are no surprises.
The other is that we've got a complex system under development and there may well be security exploits. I like the idea of that if somebody breaks our code it's going to take some work to get to the user still.
Re: Flatpak is not the future (2021)
#69I think it's an unfortunate necessity for some kinds of applications. Eg, we make this: https://overte.org/ We're currently using AppImage because that was the first thing that worked for us, but most of the reasons are the same either way: We want to spend time developing the software, and that means it's hard to justify packaging every release for a dozen distributions. And I'd say nobody particularly wants to do i…
I make few exceptions, none for snaps and flatpacks so far.
I installed Firefox from the tar.bz2 on their site, as I did with Windows before my switch to Linux in 2009. It auto updates and so far it's OK. I'm on Debian 11, I'll upgrade to 12 to stay more current.
Other exceptions: docker containers for redis and the PostgreSQL versions I have to run for compatibility with the production servers of my customers. I use asdf for that sometimes and also for languages, of course. We can't rely on the versions coming with distros.
If I'd really have to use Overte I would do an exception for that too.