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

61–70 of 410 posts

Re: Flatpak Is Not the Future

#61

Post by Gigachad »

argsnd wrote: post #55
hules wrote: post #34

Earlier quoted context omitted.

Firefox is larger on macOS because it contains 2 archs (x86_64 and arm64), not because it bundles of full runtime -- also the compression algo of dmg files is typically quite bad (zlib or bzip2), which is not helping.

I didn’t think that binaries would take up so much space, but Firefox 83 (the last x86-only release) is 73MB vs Firefox 84 (the first universal release) which is 126MB. Wow, I guess that makes sense then.

Firefox would be a bigger codebase than the whole Linux kernel so it makes sense.

Re: Flatpak Is Not the Future

#62

Post by Gigachad »

enriquto wrote: post #25
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…

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

There is a tool called flatseal which gives you a bunch of toggles so you can turn on or off any permission for a flatpak app.

Re: Flatpak Is Not the Future

#64

Post by johnchristopher »

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!

Where does that put the Deb files ?

edit: should have written "where does dpkg put the files of the package ?" or "where does that put the Deb's files ?", sorry.

Re: Flatpak Is Not the Future

#65

Post by curt15 »

enriquto wrote: post #25
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…

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

Flatseal gives users a GUI to manage the permissions of each app. Would that address your concern?

Re: Flatpak Is Not the Future

#66

Post by sho_hn »

nextaccountic wrote: post #52
0x0nyandesu wrote: post #17

Earlier quoted context omitted.

A typical system will end up with 10 versions of some .so library on disk. Sometimes more. Disk usage waste everywhere. You're better off having a package manager that can link multiple versions at the same time to the programs that need it instead of bundling.

Just use a deduplicating filesystem. Both btrfs and xfs can deduplicate identical files.

This is misleading. While btrfs and xfs have some dedup functionality, it must be invoked explicitly (e.g. by using `cp` with the `--reflink` argument). For application installation to benefit from this, business logic would have to pre-identify identical files and make such references.

There have been some experiments in btrfs to enable inband dedup on arbitrary writes, but nothing that made it in there as yet.

Note however that the discussion misses on the fact that Flatpak itself does perform dedup by using ostree for on-disk storage. ostree implements data structures and ideas very similar to git sans the version control.

Re: Flatpak Is Not the Future

#67

Post by esarbe »

smallerfish wrote: post #57
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…

> Currently, Linux desktop software offers no security against malicious code. The only protection the 'traditional' Linux desktop offers against malicious code is user separation, which is no protection at all. Before full security can be offered, applications need to be migrated to safer practices. To be fair, he appears to be arguing for the current model, where armies of distro volunteers review and manually pack…

> There is an actual third party involved in this explicit review step. With flatpak the developer has a direct route to the user without any intermediary or checks.

I think your reading of the author's argument is correct. To that I would counter that you can have just the same with Flatpak, it just depends on the Repository you are pulling your packages from.

It would be awesome if Flathub were to offer some kind of process to validate the packaged applications.

Re: Flatpak Is Not the Future

#68

Post by capableweb »

johnchristopher wrote: post #64
capableweb wrote: post #24

Earlier quoted context omitted.

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

Where does that put the Deb files ? edit: should have written "where does dpkg put the files of the package ?" or "where does that put the Deb's files ?", sorry.

The .deb file should remain where it was when you downloaded it, dpkg just installs the contents of the .deb file.

Re: Flatpak Is Not the Future

#69

Post by oleg_antonyan »

As Linux user and app developer (shameless plug https://github.com/olegantonyan/mpz/) I deliberately avoid snap/flatpak/appimage/etc.

Instead, I suffer with Open Build Service https://build.opensuse.org/. It's kind of cool, free and can build for multiple distros, but making it actually do so is a pain. But I still prefer this over flatpak&co both as user and as developer.

It just doesn't look like "the future of application distribution", https://nixos.org/ does.

Re: Flatpak Is Not the Future

#70

Post by pfranz »

hules wrote: post #34
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…

Firefox is larger on macOS because it contains 2 archs (x86_64 and arm64), not because it bundles of full runtime -- also the compression algo of dmg files is typically quite bad (zlib or bzip2), which is not helping.

Thanks for that! I quickly poked around at my Firefox install on MacOS. Firefox.app is 353M. The largest single file in there is Firefox.app/Contents/MacOS/XUL (binary) and that's 258M. Of that, lipo says 136165680 is x86_64 and 134106096 is arm64. My Firefox folder in Windows is 208M.
Post reply on HN