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.)

▲

brnt 2 months ago | parent | next [-]

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?

▲

enriquto 2 months ago | parent [-]

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

▲

sirwhinesalot 2 months ago | parent [-]

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

▲

enriquto 2 months ago | parent [-]

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.

▲

sirwhinesalot a month ago | parent | next [-]

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

▲

enriquto a month ago | parent [-]

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.

	▲	sirwhinesalot a month ago \| parent [-]
		I agree, but hopefully it's clear that there's a major problem all these crazy solutions are trying to work around.

▲

brnt 2 months ago | parent | prev [-]

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

▲

nolist_policy 2 months ago | parent | prev | next [-]

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

▲

fc417fc802 2 months ago | parent [-]

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?

▲

akvadrako 2 months ago | parent [-]

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

▲

fc417fc802 2 months ago | parent | next [-]

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.

▲

enriquto 2 months ago | parent | prev [-]

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

	▲	fc417fc802 2 months ago \| parent [-]
		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.

▲

dale_glass 2 months ago | parent | prev | next [-]

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

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

▲

arbll 2 months ago | parent | prev [-]

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