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

101–110 of 410 posts

Re: Flatpak Is Not the Future

#101

Post by drran »

alkonaut wrote: post #38
enriquto wrote: post #25

Earlier quoted context omitted.

> it works No. It doesn't. You still need to trust the people who package the thing. A working packaging system would give the user ultimate power to manage access to resources by each app. Overriding or mocking, if the user so decides, whatever access does the app believe to need. Flatpack does not give you such power, it removes this power from you and assigns it to the packagers. Thus, not only it doesn't work: it…

Is there any difference in trust between package maintainers and flatpack packagers? If anything, isn't the flatpack situation better in that regard because the end user is more likely to have a sandbox?

Maintainers are not developers, they are users, so the developer cannot push unwelcome changes, such as ads, trackers, trojans, backdoors, keyloggers, etc. directly to users because the maintainer will refuse to accept that.

Re: Flatpak Is Not the Future

#102

Post by kirbyfan64sos »

capableweb wrote: post #24
edent wrote: post #21

I agree with all of this and... I just don't care. I download a Flatpak from the Pop OS store and it works. It installs only in my profile, so another user on the same machine doesn't have access. You can't do that with a .deb! I've never got into dependency hell where I need to apt-get a specific version of a library from a dodgy PPA. If I uninstall it, Flatpak doesn't leave acres of cruft strewn around my disk. I d…

> You can't do that with a .deb! Pretty sure you can by doing "dpkg --root=$HOME -i mypackage.deb" or something like that, long time ago I used dpkg, but it should be possible with some flag. Otherwise I agree, Flatpak is a breath of fresh air!

This often doesn't really work in practice on its own at least, since packages tend to hardcode their in installation directories. (You could try using an overlayfs, but at that point it's becoming pretty cumbersome.)

Re: Flatpak Is Not the Future

#103

Post by drran »

gizdan wrote: post #84
enriquto wrote: post #43

Earlier quoted context omitted.

> Is there any difference in trust between package maintainers and flatpack packagers? You shouldn't need to trust either. Just the sandboxing system of your OS.

This is an inherent limitation of the way OSs are built. Linux, Windows, macOS are all like this. macOS is currently the furthest ahead in this since they're sharing code with iOS, but it's still not where it should be. The Linux kernel is not at a point of allowing this kind of fine grained sandboxing or mocking of APIs. I'm guessing because it's a significant undertaking. I'm sure as more features become available…

Yeah, proper use of Flatpack requires antivirus, reverse firewall, hardware isolation (separate CPU core per application), user education, etc.

Re: Flatpak Is Not the Future

#104

Post by wink »

sandGorgon wrote: post #20

The short (but polite) rebuttal to this is - OSX. DMG files are similar sized and proven to be very successful. For e.g. - firefox ( https://www.mozilla.org/en-US/firefox/all/#product-desktop-r... ). Win64 installer is 50mb. MacOS installer is 130mb. Linux 64-bit is 70mb. Same is the case with Chrome - https://chromeenterprise.google/intl/en_US/browser/download/... . Windows MSI is 79mb. OSX PKG for the same is 195mb…

osx can do this because "osx" is about as specific as "Ubuntu 20.04 LTS", so 90% of the problems that were described in the article wouldn't happen because there aren't many osxes.

I personally don't use it, so I can't tell how good the story is with 2 different versions. I've heard lots of upgrade troubles from mac users when a new OS release comes out, but maybe the authors are usually better in keeping a version for current-1 around, or the latest version compatible with current-1? Then it's still only 2 versions and not 10 distros.

Re: Flatpak Is Not the Future

#105

Post by odc »

esarbe wrote: post #28

Don't know what to think about this blog post; it's not a very coherent critique, since it throws together various issues of user-packaging-formats that mostly specific to only one of the formats. And these don't seem to be 'inherent' in their design. Well, one is. Let's go through some of the issues: > Size My /var/lib/flatpak is 13 GB in size. That's a lot of space. On the other hand; that's about one game with con…

> Neither Flatpak nor Snap have increased memory usage because of containerization.

Yes it does, because you end up loading multiple versions of the shared libraries.

There is also the memory used by the flatpack/snap daemons. Snapd is quite big since it is written in Go.

Re: Flatpak Is Not the Future

#106

Post by odc »

tonetheman wrote: post #98

End users do not care about this. If the download works then they are happy. A non-flatpak example is Electron. No one cares how big it is. It works. I download huge games from Steam all the time and have never looked at the size of a game even a single time... in years. Disk space is still cheap on end users machines. As long as the calculator works I do not care how much disk space it takes up.

> No one cares how big it is.

A lot of people care, especially Linux users.

> Disk space is still cheap on end users machines.

Not cheap for everyone.

Re: Flatpak Is Not the Future

#107

Post by jasode »

capableweb wrote: post #24
edent wrote: post #21

I agree with all of this and... I just don't care. I download a Flatpak from the Pop OS store and it works. It installs only in my profile, so another user on the same machine doesn't have access. You can't do that with a .deb! I've never got into dependency hell where I need to apt-get a specific version of a library from a dodgy PPA. If I uninstall it, Flatpak doesn't leave acres of cruft strewn around my disk. I d…

> You can't do that with a .deb! Pretty sure you can by doing "dpkg --root=$HOME -i mypackage.deb" or something like that, long time ago I used dpkg, but it should be possible with some flag. Otherwise I agree, Flatpak is a breath of fresh air!

>Pretty sure you can by doing "dpkg --root=$HOME -i mypackage.deb" or something like that,

As a sibling comment already noted, using "--root" doesn't always work and a q&a mentions the problems:

https://askubuntu.com/questions/28619/how-do-i-install-an-ap...

https://serverfault.com/questions/23734/is-there-any-way-to-...

Re: Flatpak Is Not the Future

#108

Post by tored »

esarbe wrote: post #28

Don't know what to think about this blog post; it's not a very coherent critique, since it throws together various issues of user-packaging-formats that mostly specific to only one of the formats. And these don't seem to be 'inherent' in their design. Well, one is. Let's go through some of the issues: > Size My /var/lib/flatpak is 13 GB in size. That's a lot of space. On the other hand; that's about one game with con…

In my opinion the article was well written and well researched (many sources), and to separate different topics but relatable it used different sections.

> Size

As the author mentions, many users uses budget computers or something like a raspberry pi and not a big gaming rig, but you also have to consider the network usage, all that data needs to be downloaded, that in it self is a cost for the network for every computer running that distro.

I work from my laptop when I'm traveling, I use my phone as wifi hotspot, download gigabytes of data for installing some small app is not feasible.

And you also have to consider poor countries, in poor countries you don't have infinite downloads nor the largest drives.

I remember the old days of the critique against Windows from the Linux community, Windows forces you to constantly upgrade hardware even though that old machine still works fine. I guess this is now true for Linux too.

Re: Flatpak Is Not the Future

#109

Post by IiydAbITMvJkqKf »

smallerfish wrote: post #53

I agree that the implementation is lacking. Snap has the abysmally named "--classic" parameter to allow installs to "run without confinement". Flatpak can request permission changes at install time (albeit declaring them), where users are likely to just click OK/OK/OK. The sandboxing needs to be tightened up. Flathub is a strange beast. There's no mention of security on their wiki. They stopped publishing minutes (or…

the flatpak sandbox UX is bleak. right now, you have to check the JSON file you linked to check how much access a flatpak program gets. i disagree with the --own-name and --talk-name flags (i think this is for screensharing; zoom should use the screensharing portal instead. letting zoom talk to gnome shell directly could be bad.).

--socket=x11 is a massive hole in the sandbox, since x11 does not have a security model - any client can observe and manipulate any other client. for x11, a viable solution would be running flatpak apps in xephyr, but flatpak doesn't do that. long-term, wayland is a better solution.

Re: Flatpak Is Not the Future

#110

Post by johnchristopher »

adwn wrote: post #87
johnchristopher wrote: post #75

Earlier quoted context omitted.

Where is the contents of the .deb files put?

Is there a point you're trying to make, or are you asking for technical information which would be better answered by man dpkg or a quick Internet search?

I am not trying to make any point, I am genuinely curious where dpkg is going to put those files since its the first time I read you can dot `dpkg --root=$HOME -i mypackage.deb`.

For instance I always do `python3 -m pip install --user wormhole` or `pip install --user wormhole` instead of sudoing my way to permissions hell. Python apps get installed in $HOME/.local/bin, so no cruft for other users.

But stuff installed with deb packages often have hard coded pathways and assumptions of where and how their files are run.

So I think it's fair to ask in reply to someone implying that `dpkg --root=$HOME -i mypackage.deb` is as clean/same as a flatpack behaviour "It installs only in my profile, so another user on the same machine doesn't have access. You can't do that with a .deb!"... It's fair to ask "where do those files in the deb package go ?" because if it works as implied (no pollution of the OS) I am certainly going to start testing installing things that way.

Post reply on HN