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

Flatpak Is Not the Future

ludocode.com

Post reply on HN
Print view View original

341–350 of 410 posts

Re: Flatpak Is Not the Future

#341

Post by Gigachad »

josefx wrote: post #164
Gigachad wrote: post #58

Earlier quoted context omitted.

it’s been tested and almost all library packages are only used by one other package on the system. And almost all of the sharing comes down to a very limited set of libraries. Flatpak solves this with platforms. You can base a package on the gnome platform for example and get a whole bunch of the most used libraries. But even without platforms, disk space is one of the most abundant resources right now. You could ins…

> it’s been tested and almost all library packages are only used by one other package on the system. I have a KDE desktop, are you trying to imply that only one of the dozens of applications provided by it actually use Qt? That only one of the dozens of image related programs use libpng, libtiff,libjpeg, etc. ? Or are you just citing a highly misleading statistic?

GTK, QT and the core C stuff make up almost all of the shared library usage. Some obscure png cropping library will basically never end up shared even with dynamic linking. Flatpak does a great job of sharing the 1% that make up the 99% of usages while allowing version locking and bundling of that 1mb binary used by only one program.

Re: Flatpak Is Not the Future

#342

Post by Gigachad »

josefx wrote: post #287
lucian1900 wrote: post #176

Earlier quoted context omitted.

Qt in your case is one of the exceptions, just like GTK for Gnome users.

Any application that depends on either of those indirectly depends on libpng and dozens of others. Its a dependency tree, just cutting it of after the first dependency does not make sense in any context and even less so in a context that claims to measure package reuse.

The KDE and GNOME platforms contain all of those indirect packages. They contain basically everything generic that you need to build a GUI app. Then when you go off in to the specific little tools you need, you bundle those in.

Re: Flatpak Is Not the Future

#343

Post by Scramblejams »

tapoxi wrote: post #293
Scramblejams wrote: post #276

Earlier quoted context omitted.

I often avoid Flatpaks because the permissions are so frequently wrong or not what I need. For example, you mentioned Signal. I stopped using the Flatpak because of this: https://github.com/flathub/org.signal.Signal/issues/181

It looks like that problem is fixed with Flatpak override and not installing the Flatpak with root? This is also probably because the Signal Flatpak is community developed on Flathub from Signal's .deb, they're not building Signal with Flatpak in mind. Mozilla provides an official Flatpak release of Firefox.

I'm sure official Flatpaks do better on average, but that narrows the selection a lot. And most third-party packagers raise my suspicions in a way that, say, the Debian packaging team does not. You should see my eyebrows go up when I cruise dockerhub!

I don't know what the right answer here is, but for me it's not Flatpaks or Snaps. Trusting the packager (and the org behind the package system) is a huge part of it. I breathe a sigh of relief every time I see the software I need is in Debian's repos, even if that means they may not be optimally sandboxed.

Re: Flatpak Is Not the Future

#344

Post by jcelerier »

CRConrad wrote: post #333
jcelerier wrote: post #297

Earlier quoted context omitted.

> On the contrary it provably works very well for distributions. if it worked very well there wouldn't be a need for flatpak / snap / appimage / etc. How do I install an older or newer inkscape / ardour / krita in the latest debian stable / ubuntu / fedora / whatever without recompiling stuff ?

> if it worked very well there wouldn't be a need for flatpak / snap / appimage / etc. Exactly: There isn't. > How do I install an older or newer inkscape / ardour / krita in the latest debian stable / ubuntu / fedora / whatever without recompiling stuff ? You don't. Or if you have to, do it on Gobo (or perhaps Guix or NixOS?).

That's a ridiculous answer. "You don't" means people go back to windows or Mac OS where they can do that easily because it's an actual need people have. That's the worst outcome by far as it leads to less support on Linux.

Re: Flatpak Is Not the Future

#345

Post by pabs3 »

necovek wrote: post #278
pabs3 wrote: post #137

Earlier quoted context omitted.

The tool that flatpak uses for sandboxing is bubblewrap, that can be used to sandbox distro packages fairly easily. None of the desktops do that though.

Thanks: bubblewrap seems to have been extracted from flatpak. The documentation seems to focus on filesystem access sandboxing. Is there something with practical suggestions on how to sandbox things like webcam access, clipboard, screen (for screen sharing/recording apps), networking... with bubblewrap? (I know some of that is visible in the filesystem, but not all of it is)

Look into Flatpak portals. I'm not sure how they work wrt bubblewrap, but they pass limited interfaces to various things into the container. Things on the host side then prompt the user for which webcam/etc the app should get access to. I think they are similar to Android intents in that the app can't ask for access to a specific thing, just for access to certain kind of things and then it is up to the user to choose which one.

Re: Flatpak Is Not the Future

#346

Post by cromka »

oleg_antonyan wrote: post #111
zohch wrote: post #100

Earlier quoted context omitted.

Because installing an rpm allows you to run arbitrary code as root. Installing a flatpak does not. I mean there are many more reasons but that should be en.

It's explained in the article, security section: b/c installing flatpak can also run arbitrary code as a user. And I won't argue that running malicious code as a user is always harmless. Regardless of root access if you're installing flatpak and its author want to pwn you - they can do it even without root access

Yeah, so why even have user accounts and not just root everything? I mean if there's no difference...

Re: Flatpak Is Not the Future

#347

Post by tomberek »

kaba0 wrote: post #77
gens wrote: post #47

Earlier quoted context omitted.

I recommend just shipping everything you need with your app, either manually or using AppImage. Flatpack is, more or less, just a bad package management.. technology.

Nah, AppImage still won’t run on all distros. The only thing I think actually solves packaging is nix.

Nix seems to be the only approach that has a chance, but having good fundamentals isn’t enough. The effort to improve the UX and usability is underway. I’m working on it; are there use-cases or “blow your socks off” demos that would be compelling to help convince developers and application writers?

Re: Flatpak Is Not the Future

#348

Post by jhaygood86 »

brnt wrote: post #317
curt15 wrote: post #202

Earlier quoted context omitted.

>As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that. The filesystem permissions are a bit more fine-grained than "all of home or nothing". Your two examples are already possible to achieve by granting filesystem access to xdg-documents or xdg-downloads.

So many flatpaks do this incorrectly though. For Browser by default saves in the flatpaks home/Downloads directory (which is 15 layers deep from ~). You just gotta know to navigate up. Signal let's you save attachments anywhere on disk, but only if you manually navigate to ~/Downloads, does it actually save (in a way visible and accessible outside of the app). You just gotta know. I forgot what exactly the problem wa…

The apps that are "broken" are apps that are not "Flatpak native", so assume they have full write access to ~

Flatpak aware apps (like the ones I develop, or any on elementary OS since flatpak is the native packaging format there) tend to just work.

Re: Flatpak Is Not the Future

#349

Post by jhaygood86 »

simiones wrote: post #173
zimbatm wrote: post #40

There is a deep trend happening in software development. As the number of dependencies for building an application grows, it becomes exponentially harder to shake the tree. This used to be the role of Linux distributions, they were acting as a push-back force, asking projects to support multiple versions of C libraries. This was acceptable because there is not C package manager. Now that each language has their own p…

> On Windows and macOS, there are some SDKs the application can lean on. On Linux, the only stable "SDK" is the Linux kernel API. This is a very good observation I think. Basically, what Linux distributions have failed to do is to create a higher level SDK for their platforms - instead, they rely on a soup of libraries and on the package maintainer model to know which of these is which. Basically, they are failing to…

I'd like to point out elemenatary OS as a counter-example:

They have consistently provided a high level SDK for their OS. With elementary OS 6, they moved their high level SDK to using flatpak (not flathub) as a distribution mechanism.

Re: Flatpak Is Not the Future

#350

Post by SteveBash »

southerntofu wrote: post #156
pfranz wrote: post #88

Earlier quoted context omitted.

You should point the finger at package managers. They never really addressed needs outside of system administration (to be fair, that's the problem they were trying to solve). Scripting languages came up with their own package system because package managers didn't fit their needs, I often found myself building from source and installing into my homedir because package managers wouldn't accommodate, industries (like…

> Nix/Guix seems like the only one that's trying something different enough to address some of those other use-cases, but the cat's out of the bag for most people. Maybe that's because nix and guix don't interop despite having rather similar principles, and because we mostly don't have GUI for it (like GNOME Software has integration for flatpak) nor desktop integration (like AppImageLauncher). Are you aware of work b…

There's nix-gui: https://github.com/nix-gui/nix-gui
Post reply on HN