Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flatpak is not the future (2021)

ludocode.com

Post reply on HN
Print view View original

111–120 of 166 posts

Re: Flatpak is not the future (2021)

#111

Post by JohnFen »

ceronman wrote: post #87

Flatpak seems to follow a similar path as many other Linux technologies like Wayland or Systemd, in the sense that they seem to arouse the anger of a small but very vocal crowd who really can't stand any challenge to the status quo. So this is the template of the story: There is a new tool or workflow trying to replace or complement an old one. This new tool tries to solve many different complex problems that the old…

> without understanding that there is no holly grail solution and some sort of compromise is always required.

Why do you assume that such people don't understand this? Sometimes those compromises mean that the tool can no longer accomplish something important to some users.

I don't think that being upset that software has become less useful is terribly unreasonable or hard to understand.

> Additionally, as it's natural with any new technology, the very first incarnations of the new technology are not very mature and there is a lot to polish, a lot of tooling missing

And while the software is in that state, it shouldn't be forced on anyone. It's not unreasonable for people to want to use software that actually works well in the present.

Re: Flatpak is not the future (2021)

#112

Post by arrakeen »

gumballindie wrote: post #33

Neither 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…

i completely agree. for me, the only issues i've had with appimages are "housekeeping" UX:

* i know they can technically be updated but i really have no idea how. would be cool to see a de-facto solution similar to sparkle[0] on mac

* i use appimagelauncher[1] to integrate with my menus etc but sometimes it works and sometimes it doesn't? i haven't really figured out the rhyme or reason

[0] https://sparkle-project.org/

[1] https://github.com/TheAssassin/AppImageLauncher

Re: Flatpak is not the future (2021)

#113

Post by kvdveer »

gumballindie wrote: post #33

Neither 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…

I feel appImage is missing metadata. I'd be great when the user downloads an appImage, it is automatically linked to the mime types is can handle, shows up in relevant menus, and can properly register itself to any services it needs (e.g. Cron).

It could also do with an update mechanism.

Re: Flatpak is not the future (2021)

#114

Post by pmarreck »

sanderjd wrote: post #37
pmarreck wrote: post #11

It is strange to watch everyone fight about snaps, flatpaks, silverblue ad nauseam when Nix (or its full-OS version, NixOS, or the GNU alternative, Guix) has already definitively solved this problem but is still considered too arcane for most people to use. It only uses the disk space it must, AND every app only accesses the dependencies it needs. It's the best of all worlds (except for the learning curve, which is o…

I really like Nix, but I think "is still considered too arcane for most people to use" is a contradiction of "has already definitively solved this problem". Being usable for most people is an important part of solving this problem, which I unfortunately don't think Nix has accomplished. Maybe there is some way to improve its UX while keeping the fundamental model intact, in order to solve this problem.

The core idea of Nix that has basically "solved this problem" is simply trying to control for all possible inputs to a build-time and run-time environment, and lock them all down with hashes, which is in essence basically treating a build like a pure function. (In theory, this should result in deterministic builds and deterministic runs. And in practice, nearly 100% of the time, it does.) The point of a "derivation" is to provide that for code that does not. Nix, and derivations in general, are thus sort of a "scaffolding" over all the existing build tool and dependency managers out there that bring them "over the line" regarding this. If these build tools and dependency managers all embraced the Nix way of specifying dependencies, and they all agreed to store it in a Nix store (i.e. a Merkle tree), then hypothetically, Nix would not even be necessary (except perhaps as a group of small tools to manage the store).

1) This is probably too much to ask of people. 2) This still leaves behind decades of software that would still need to be built in the future and would thus still need something like the "scaffolding".

But again, the fundamental idea is really just this: Treat builds and runs as pure functions. Every other advantage derives directly from that principle. If someone else can figure out how to do this as simple as possible, I'm all for it! In the meantime, I think every developer should read Eelco's thesis paper on this idea: https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf

Of course, the OTHER way to solve this problem is just to statically-compile everything, leading to an explosion of disk-space usage. And even then, you wouldn't get guaranteed rebuilds.

Re: Flatpak is not the future (2021)

#115

Post by c-hendricks »

smashed wrote: post #42
5- wrote: post #15

Earlier quoted context omitted.

> Firefox should be able to just use the mozilla's official build which comes with an auto-updater (and it implements the sandbox itself, so no need for another one on top). > Zotero > Joplin both electron shells. also come with their sandbox already. most rolling release distributions would just package these with a system-provided electron build.

> both electron shells. also come with their sandbox already. Not sure about the 2 specific apps posted, but web applications packaged as electron apps often do so in order to easily escape the normal browser sandbox without having to prompt for permissions? Or even call into native code which would be impossible from a web app. I would not think that because an app is electron based, it is sandboxed from your system…

You're correct. In fact, they can even let webpages break out of the sandbox. So, some random JS loaded from the web can now compromise your system.

The person you're replying to is quite mistaken.

Re: Flatpak is not the future (2021)

#116

Post by david2ndaccount »

gumballindie wrote: post #33

Neither 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…

This works for MacOS because there are system frameworks you can rely on being installed (like AppKit) and that actually have backwards-compatibility (at least for a while). Linux distros don’t have this (not even for glibc), so you’d have to literally everything in your app image folder. Every GUI app bundling QT or other gui framework would be a ridiculous waste of space.

Re: Flatpak is not the future (2021)

#117

Post by prmoustache »

Timber-6539 wrote: post #108
prmoustache wrote: post #58

Earlier quoted context omitted.

The point is the proponent raise the security flag like it is a huge advantage and you could trust anything coming from flathub while it is mostly pixie dusk. Untrustable apps aren't more trustable because they are delivered as flatpaks.

You missed my point. > The point is the proponent raise the security flag like it is a huge advantage and you could trust anything coming from flathub while it is mostly pixie dusk. Okay then, as you criticize Flatpaks give us your alternative to a trusted application. > Untrustable apps aren't more trustable because they are delivered as flatpaks. Nobody made this claim.

> Okay then, as you criticize Flatpaks give us your alternative to a trusted application.

I am not criticizing, I am saying it is mostly a moot point. The sandboxing allow a bit of isolation but this it ranks quite poorly in term of actual security benefits for the typical end users use cases.

> Nobody made this claim.

Well, not the authors of flatpak, but yes some did. On medias that many people watch such as youtube videos.

Re: Flatpak is not the future (2021)

#118

Post by prmoustache »

danShumway wrote: post #92
prmoustache wrote: post #72

Earlier quoted context omitted.

But on the other hand, app crashes aren't something that common on linux. I mean at least on my distro. Whenever I have an app available as rpm, I choose the rpm over the flatpak version, for space saving purpose mostly. None of my apps crashes except one. And that is a piece of shit of a proprietary app that is not packaged by the distro maintainers: Microsoft Edge.

> But on the other hand, app crashes aren't something that common on linux. I mean at least on my distro Strong disagree, my experience is that app crashes are extremely common on Linux if you step outside of official repositories; I say this as someone who literally only runs Linux and nothing else. I'm not necessarily saying Windows is better but... it's not like nothing ever breaks. It's impressive how well develo…

The major distros and BSD have shown, that yes, that scales fairly well in fact given the number of apps provided through distros official repos.

Most apps that I have been getting from third party repo were not included because most majors distros are us projects that can't ship patent encumbered libs/apps, not because distros mainteners couldn't package them.

> This is why people run games through Wine instead of using the Linux versions

No, the main reason is that the linux versions do not exist for the most part because devs don't want to bother supporting a non uniform software platform that represent a tiny fraction of their market.

Re: Flatpak is not the future (2021)

#119

Post by jeroenhd »

mcpackieh wrote: post #56
jeroenhd wrote: post #45

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

Optimizing for disk space in 2023 seems misguided at best, all computers come with hundreds of GB at least, often one TB or more. Most people never fill these unless they download media, and people who download media have additional hard drives anyway. Ease of use, RAM usage, startup time and security should all rank higher than disk space.

I'm not going through the effort to upgrade my 250GB system SSD because a random podcast app can't figure out how to distribute a binary without shipping half an OS. Most people aren't going to upgrade their storage at all.

We're talking about Linux users here, not your run-of-the-mill generic end user. If you download an AppImage, you're most likely an advanced computer user. Maybe you don't download media yourself, but you'll probably have huge node_modules/cargo/venv/maven directories slowly clogging up your drive.

AppImages aren't easy to use (you can't double click them like on Windows and they all have to provide a mechanisms of their own to register a shortcut in the system menu), their startup time is affected by the compression tying all the files together, the security is no better than any other application (worse, in fact, because when I update my system's openssl client I'll still need to wait for every AppImage program to publish a security update with the patches included, which usually takes months or longer). I don't know about RAM usage, but the duplicate libraries being loaded by the executables will cause at least a few megabytes of unnecessary RAM usage.

AppImage is mostly there to help the developer spread the software. The benefit for the user is "at least there's something I can run, I guess".

Re: Flatpak is not the future (2021)

#120

Post by Timber-6539 »

prmoustache wrote: post #117
Timber-6539 wrote: post #108

Earlier quoted context omitted.

You missed my point. > The point is the proponent raise the security flag like it is a huge advantage and you could trust anything coming from flathub while it is mostly pixie dusk. Okay then, as you criticize Flatpaks give us your alternative to a trusted application. > Untrustable apps aren't more trustable because they are delivered as flatpaks. Nobody made this claim.

> Okay then, as you criticize Flatpaks give us your alternative to a trusted application. I am not criticizing, I am saying it is mostly a moot point. The sandboxing allow a bit of isolation but this it ranks quite poorly in term of actual security benefits for the typical end users use cases. > Nobody made this claim. Well, not the authors of flatpak, but yes some did. On medias that many people watch such as youtub…

> The sandboxing allow a bit of isolation but this it ranks quite poorly in term of actual security benefits for the typical end users use cases.

Ranked poorly in what checklist?

> Well, not the authors of flatpak, but yes some did. On medias that many people watch such as youtube videos.

Let's try to stay on topic. The point I made was that, the author's example about Flatpak GIMP doing something unauthorized on your system applies to any package format. The differentiating factor here is that Flatpak/Flatseal allows you to sandbox the application easily and quite effectively if I may add.

Post reply on HN