| ▲ | enriquto 13 hours ago |
| 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.) |
|
| ▲ | nolist_policy 11 hours ago | parent | 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 8 hours 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 5 hours 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 hours 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 5 hours ago | parent | prev [-] | | this is horrifying, and contrary to the very notion of what a "driver" should be | | |
| ▲ | fc417fc802 an hour 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 13 hours 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 13 hours ago | parent | prev | next [-] |
| Any complex software is going to be a collection of files, not a single static binary. |
|
| ▲ | brnt 13 hours ago | parent | prev [-] |
| 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 13 hours 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 12 hours ago | parent [-] | | Have you actually tried to make a fully statically linked GUI app on Linux? | | |
| ▲ | enriquto 9 hours 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. | | |
|
|
|
