The Future of Flatpak

Never understood the point of flatpak, snap and the like. Can't you just distribute static binaries? They are not that hard to compile.

(I mean, from the distributing point of view. The sandboxing and resource management is a OS-thing that should be an orthogonal issue. Users must be able to sandbox programs that they don't trust, regardless to how they are packaged and distributed.)

They're not at all trivial on anything big and complex.

And the code I work on has loadable plugins, too.

I did not find packaging up an AppImage that is actually compatible across distro's and version all that straightforward, and we were not even using Qt or GTK/libadwaita. How is this easy, in your experience?

Any complex software is going to be a collection of files, not a single static binary.

> How is this easy, in your experience?

add -static to your link flags? Sometimes you need to fiddle a bit with the order of the libraries, but that's it.

In the ideal case, for maximum portability, i'd like to use the αpε format!

Have you actually tried to make a fully statically linked GUI app on Linux?

> Can't you just distribute static binaries? They are not that hard to compile.

You absolutely can't, since you need to link to the system libGL.so and friends for gpu acceleration, libva.so for video acceleration, and so on.

Just did it!

I had to add "-static" to LDFLAGS and "-lxcb -lXau -lXdmcp" to LDLIBS, for an increase in binary size from 1MB to 3MB. It's a plain X program, i guess if you use fancy toolkits it may be harder.

To be fair isn't flatpak encapsulating the user space portion of mesa, similar to any other chroot? In which case the apples-to-apples comparison would be shipping your own mesa alongside your app.

Which now has me wondering, is the common wisdom wrong? Could I actually statically link opengl if I went to enough trouble?

If anything more than plain X is fancy to you...

You need the exact right version that matches your actual graphics driver. So flatpak takes care of installing the matching drivers inside the sandbox.

this is horrifying, and contrary to the very notion of what a "driver" should be

Do you? I've often seen this repeated but at some point I tried a cutting edge chroot on an extremely (ie multiple years) out of date device and opengl seemed to work. It surprised me but then I don't know much about how mesa works under the hood.

To be fair the graphics APIs are provided as libraries with as much as possible done in userspace. Sandboxing that without any coupling at all would likely require either new kernel APIs or highly questionable virtual memory shenanigans.

Try getting 3D rendering now. Your statically linked libc will fail to load the GPU driver and your app won't work :)

True. And that's why linus showing the finger to nvidia was an exhilarating relief to so many people. The gpu driver shenanigans are horrific to contour, but they are completely unnecessary on technical grounds. All the difficulties are purposefully introduced by the graphics card hardware companies. I'd say "fuck it" and do the rendering in the cpu only, which is almost always possible.

I agree, but hopefully it's clear that there's a major problem all these crazy solutions are trying to work around.