Flatpak Is Not the Future • Hacker News Board

Re: Flatpak Is Not the Future

#271

Post by TingPing » Tue, Nov 23, 2021, 4:42 PM UTC

goohle wrote: post #249

AnIdiotOnTheNet wrote: post #113

Earlier quoted context omitted.

On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software, and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained"), which reflects poorly on the developer in the mind of the user. I personally see no upside to shoving an unpaid third party between user and developer.

> On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software, Such maintainer will be kicked off from distribution. > and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained") Developer wishes are developer wishes. User wishes are more important. If package has a maintainer,…

> Such maintainer will be kicked off from distribution.

Debian did this, they said oops and moved on. Packagers suck as developers, they apply patches they don't fully understand to solve problems they don't understand on codebases they don't understand.

Re: Flatpak Is Not the Future

#272

Post by curioussavage » Tue, Nov 23, 2021, 4:46 PM UTC

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…

You discovered the one area that doesn't work well yet. Dev tools don't work great because they typically need access to just about everything. They either ask for very broad permissions or the app has to add support for portals - of which there may not be some that they need yet.

Re: Flatpak Is Not the Future

#273

Post by dylan-m » Tue, Nov 23, 2021, 4:47 PM UTC

cunidev wrote: post #7

To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution on Linux. While my experience on Snaps was mostly negative (due to bugs, virtual "loop disks" per every app affecting the system performance, etc.), I found that Flatpak finally lets me install essentially any app on any distro. For example, the Elementary OS…

> Memory and CPU-wise, Flatpaks are very light containers

Adding to that: it's really worth noting, on "Memory Usage, Startup Time," the author of this article went straight into Snap ("the slowest of all") and doesn't mention Flatpak once. Could it be … it isn't a big deal? Nah, let's move on, Flatpak bad.

They also conveniently use an old version of GNOME Software which predates the recent rework of how it displays permissions, age ratings, and other details. In Fedora 35, GIMP most definitely has a worrisome "Unsafe" message. It's very shiny and new so it would be excusable to miss that if you weren't pretending to be a well-researched hatchet job.

Re: Flatpak Is Not the Future

#274

Post by apexalpha » Tue, Nov 23, 2021, 4:50 PM UTC

As a linux user, but not a developer, I've always been surprised by the backlash against Flatpack and Snap.

For me they work wonderfully. On Ubuntu I usually go for the Snap since it just works. Solving multiple dependency issues before I can use a tool always cost me time before. Now, not so much. Even AppImage is nice.

The fact that most software is even available on Linux now is due to the fact that developers can create one app for Linux, in stead of multiple.

Maybe I'm not familiar enough with GNU/Linux to see the drawbacks, but if it's just disk space I'll happily make that trade.

Re: Flatpak Is Not the Future

#275

Post by bboozzoo » Tue, Nov 23, 2021, 4:53 PM UTC

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…

> Snap has the abysmally named "--classic" parameter to allow installs to "run without confinement".

Only if the snap was built with classic confinemnt in mind. Otherwise, just slapping --classic on a random snap does nothing, there's even a warning display about that. Classic is very much the same as a random 3rd party vendor app built and unpacked under /opt. Unfortunately some software, especially IDEs and languages are unsuitable for running under confinement and need to be distributed this way. By passing --classic you give your consent to use an app package in this sub-par way.

FWIW, perhaps you meant --devmode, which as the name implies is mostly for developing a snap? snap install --help describes that as:

    --devmode  Put snap in development mode and disable security confinement

Re: Flatpak Is Not the Future

#276

Post by Scramblejams » Tue, Nov 23, 2021, 4:55 PM UTC

tapoxi wrote: post #196

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.

My experience with AppImages is fine, but I prefer Flatpaks because they can be updated with a remote. My installs of Signal and Firefox are with Flatpaks and GNOME Software transparently handles updating both.

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

Re: Flatpak Is Not the Future

#277

Post by necovek » Tue, Nov 23, 2021, 4:57 PM UTC

AnIdiotOnTheNet wrote: post #266

necovek wrote: post #241

Earlier quoted context omitted.

You must have missed all the articles on the huge effort Microsoft went to to maintain backwards compatibility (like that famous SimCity story). I can't find the original article anymore, but you can find references to it on Joel Spolsky's blog: - https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii... - https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... Referenced posts probably live somewhere o…

Yes, in order to increase their backwards compatibility Microsoft has, historically at least, done things like that. However, mostly they achieve backwards compatibility by just not breaking ABIs all the goddamned time. Windows backcompat isn't perfect, true, but largely the stories of where it fails are exceptions to the rule. Where as you can't even have backward compatibility in a Linux Desktop with applications c…

You started off by disagreeing that backwards compatibility is hard, because other platforms (like Windows or MacOS) can do it.

When given evidence that it's at huge cost and investment that they manage to do that (basically an admission from them that it is hard — you may have a different definition of "hard" than I do), you seem to suggest that either they are not doing a lot of work towards compatibility or that they are wasting all that money because they could have simply maintained backwards ABI compatibility while developing new features "easy-peasy".

Why did they choose not to take the easy way out and made it hard for themselves?

From my software development experience, maintaining API backwards compatibility is "hard" (requires significant extra effort to achieve compared to just not doing it), not to mention ABI complexities on top.

Re: Flatpak Is Not the Future

#278

Post by necovek » Tue, Nov 23, 2021, 5:01 PM UTC

pabs3 wrote: post #137

necovek wrote: post #22

The most important takeaway from this is, to me, the need to separate sandboxing from dependency management. However, as can be seen with AppImage, which seems to be strictly focused on dependency management, that results in bloat. It would be great if we could have a sandboxing solution that ignores the dependency management altogether. The problem is not with Flatpak or Snaps (or Docker). The problem is that the fr…

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)

Re: Flatpak Is Not the Future

#279

Post by m4rtink » Tue, Nov 23, 2021, 5:06 PM UTC

Gigachad wrote: post #58

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.

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…

IIRC Flatpak actually deduplicates all platform runtime and apps on file level automatically due to the backing storage being an ostree. The same thing also gives flatpak efficient diff updates for apps and platform runtime.

Re: Flatpak Is Not the Future

#280

Post by derefr » Tue, Nov 23, 2021, 5:08 PM UTC

gopher_space wrote: post #242

WastingMyTime89 wrote: post #187

Earlier quoted context omitted.

You are replying to a comment explaining to you why Flatpak actually works with a dismissive sentence implying it's just a bad technology. Do you have anything substantive justifying your opinion? From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change. Despite being centered around technology, a very vocal part of the Linux community seems to be extr…

> Despite being centered around technology, a very vocal part of the Linux community seems to be extremely conservative. A working system calls for a conservative viewpoint. I'm only looking to introduce change if my needs aren't being met.

My understanding is that, by volume, most people using Linux "in anger" (whose needs mostly dictate the direction of Linux development) aren't the SREs maintaining living systems for years at a time; rather, they're the DevOps people with constant streams of greenfield projects, involving half-baked third-party components, that in turn need all sorts of random bleeding-edge dependencies.