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

51–60 of 410 posts

Re: Flatpak Is Not the Future

#51

Post by yyyk »

>They should... Build a fine-grained user-interactive runtime permission system that requires the app to make Flatpak-specific API calls to activate permission dialogs

What the article wants is useless without fixing Linux's security modules. Very few people know how to use SELinux or AppArmor, there's no standardization between distros and apparently even RedHat has given up.

Flatpak and Snap do containerization because they have no good alternative.

P.S.

>If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app.

Note that Microsoft has been moving away from that with .NET Core/.NET. The new runtime does not come with the OS. It's still possible to create a package and have .NET installed separately, but as far as I can tell, most people prefer to package with the runtime.

Re: Flatpak Is Not the Future

#52

Post by nextaccountic »

0x0nyandesu wrote: post #17
capableweb wrote: post #16

Earlier quoted context omitted.

Not sure if you misunderstand what Flatpak is or if you are really suggesting to ship a entire distribution for your users to install if they want to use the application you're delivering to them.

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.

Re: Flatpak Is Not the Future

#53

Post by smallerfish »

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 moved them elsewhere?) in 2017 (https://github.com/flathub/flathub/wiki). They have a buildbot for automated updates from developers, but they accept binaries anyway (e.g. https://github.com/flathub/us.zoom.Zoom/blob/master/us.zoom....), so what's the point? It appears to be a fairly amateur effort, and yet is at the center of the infrastructure Red Hat and Gnome are pushing. I'd love to see some white hat activity targeted at compromising it, to demonstrate the shaky foundations.

But on the other hand, it's nice that I can run Zoom sandboxed (apparently - it's not obvious what the granted permissions are: https://www.flathub.org/apps/details/us.zoom.Zoom). It's nice that Jetbrains and Zoom have a way to publish apps that can run on all distros. It's nice that I could rollback a version of IntelliJ that was buggy with a single snap command that took 5 seconds. The goals are good.

I wish Linus took more of a BDFL approach to the desktop occasionally. Ubuntu & Red Hat need to sit down in a room and have a constructive conversation to converge Snap and Flatpak into something new, deprecating the infrastructure built to date, and fixing some of the glaring problems. There's room for both to make money without further diverging the ecosystem.

Re: Flatpak Is Not the Future

#54

Post by kiryin »

I dunno. I had my doubts for the longest time but recently I've started, little by little, placing my bets on Flatpak. Snap can go to hell, for reasons exhaustively discussed here and elsewhere, but Flatpak is reasonably solid, open and performant technology that fits the problem it's trying to solve. I wouldn't mind if it takes over the distribution of big, GUI desktop apps on linux.

Re: Flatpak Is Not the Future

#55

Post by argsnd »

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.

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.

Re: Flatpak Is Not the Future

#56

Post by Const-me »

trollied wrote: post #41

My experience with these is terrible. I install a JetBrains IDE via a package. I spent a very long time trying to debug a CMake problem that I assumed was my inexperience with CMake. After attacking various processes with strace, it dawned on me that the problems were caused by the IDE not being able to see files in /usr/local. A sandboxed dev environment! Lost for words... A relatively inexperienced dev would have a…

Very similar experience with .NET runtime on Linux. Microsoft ships .NET runtime as a Snap package https://docs.microsoft.com/en-us/dotnet/core/install/linux

One time I didn’t paid attention, installed Snap package instead of the native binaries, and then I spent several hours debugging “access denied” status returned by mq_open https://man7.org/linux/man-pages/man3/mq_open.3.html kernel API in my program which only happened when called from a C# program, but not C++ program running under the same user account.

Re: Flatpak Is Not the Future

#57

Post by smallerfish »

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 package up debs and rpms (granted that on smaller distro teams, this may be less thorough). 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.

Re: Flatpak Is Not the Future

#58

Post by Gigachad »

0x0nyandesu wrote: post #17
capableweb wrote: post #16

Earlier quoted context omitted.

Not sure if you misunderstand what Flatpak is or if you are really suggesting to ship a entire distribution for your users to install if they want to use the application you're delivering to them.

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.

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 install millions of libraries in the space of a single AAA game.

Re: Flatpak Is Not the Future

#59

Post by bennyp101 »

trollied wrote: post #41

My experience with these is terrible. I install a JetBrains IDE via a package. I spent a very long time trying to debug a CMake problem that I assumed was my inexperience with CMake. After attacking various processes with strace, it dawned on me that the problems were caused by the IDE not being able to see files in /usr/local. A sandboxed dev environment! Lost for words... A relatively inexperienced dev would have a…

Yea, a while back I tried out a flatpak for filezilla, but because it was sandboxed I couldn't set the default editor to anything on my actual machine, so uninstalled that and went with a deb which worked just fine

Re: Flatpak Is Not the Future

#60

Post by marcodiego »

Don't know if it is the future, but has been making my present much better.

I can finally have a stable distro with released yesterday packages. As a test I tried installing GIMP on raspberry pi, a x86 bits ubuntu 18.04 machine a x64 bits ubuntu 16.04 machine and x86 bits ubuntu 20.04. Three architectures, 4 distros, 4 machines: 1 command, the same software. It took a bit long to install on the raspi but it worked.

Flatpaks, snaps and appimages finally blurs the lines between distros. If there are problems, they should be improved, not abandoned.

Post reply on HN