Yeah, that’s the fun part. Hooking into some auto-update mechanism would be useful to me.
But my stuff is mostly in the scratching-my-own-itch stage, so setting up a FlatHub account, Flatpak metadata, sandbox rules, probably an icon and screenshots and whatnot, and automating the build+releases, just to get auto-updates, yeah… no.
I could code a whole nother project in the time that would take.
Well, if you have any form of build script, makefile, or CI, then you can easily shove that into a flatpak-builder manifest and push the build repo anywhere you want. The default OSTree repository format can be served from any old webserver or S3 bucket after all.
I’ve done this for personal projects many times, since it’s a ridiculously easy way to get scalable distribution and automatic updates in place.
Hmm, okay, that doesn’t sound too bad.
Does the sandboxing get into the way much? Can a user tell it to poke a hole into the sandbox, to use some specific folder, for example?
I think, my real problem is that I don’t actually use Flatpak for any software I have installed. 😅
I’m not opposed to using Flatpak, but I disabled Flathub pretty quickly on my distro’s software store thingamabob, when I accidentally installed some proprietary software from it. Fuck that shit, no matter how much sandboxing I get.
In regards to sandboxing, it only gets as far in the way as you ask it to. For applications that you’re not planning on putting on FlatHub anyway you can be just as open as you want to be, i.e. just adding / - or host as it’s called - as read-write to the app. (OpenMW still does that as we had some issues with the data extraction for original Morrowind install media)
If you do want to sandbox though, users are able to poke just as many holes as they want - or add their own restrictions atop whatever sandboxing you set up for the application. Flatpak itself has the flatpak override tool for this, or there’s graphical UIs like flatseal and the KDE control center module…
So, like, dumb question. People here assumed that I mean AppImages, whereas I actually meant just a statically linked binary. Is that really the only reason why AppImage exists? So, that dynamically linked applications can be distributed like statically linked ones?
Ah, interesting. So, it’s different from just statically linking against the latest driver lib every 6-12 months, because the Flatpak runtime gives you a bit of a guarantee that there won’t be breaking changes in the meantime.
Bingo, and if the latest mesa breaks your app for example, you can target an older one until it’s fixed instead of end users having to fuck around downgrading system packages
This is the problem those tools try to solve. They package everything else upon which software might depend that can’t simply be linked into a single binary.
Yeah, alright, packaging assets makes sense. I’ve always been fine with just a .tar.gz, but having it be a singular file without compression is cool.
I guess, since AppImage emulates a filesystem, you can also have your application logic load the assets from the same path as if the assets were installed on the OS, so that’s also cool.
I just distribute it as a self-contained executable/archive. ¯\_(ツ)_/¯
Valid solution, but I miss unified updates with appimages and such
Yeah, that’s the fun part. Hooking into some auto-update mechanism would be useful to me.
But my stuff is mostly in the scratching-my-own-itch stage, so setting up a FlatHub account, Flatpak metadata, sandbox rules, probably an icon and screenshots and whatnot, and automating the build+releases, just to get auto-updates, yeah… no.
I could code a whole nother project in the time that would take.
Well, if you have any form of build script, makefile, or CI, then you can easily shove that into a flatpak-builder manifest and push the build repo anywhere you want. The default OSTree repository format can be served from any old webserver or S3 bucket after all.
I’ve done this for personal projects many times, since it’s a ridiculously easy way to get scalable distribution and automatic updates in place.
Hmm, okay, that doesn’t sound too bad.
Does the sandboxing get into the way much? Can a user tell it to poke a hole into the sandbox, to use some specific folder, for example?
I think, my real problem is that I don’t actually use Flatpak for any software I have installed. 😅
I’m not opposed to using Flatpak, but I disabled Flathub pretty quickly on my distro’s software store thingamabob, when I accidentally installed some proprietary software from it. Fuck that shit, no matter how much sandboxing I get.
In regards to sandboxing, it only gets as far in the way as you ask it to. For applications that you’re not planning on putting on FlatHub anyway you can be just as open as you want to be, i.e. just adding
/- orhostas it’s called - as read-write to the app. (OpenMW still does that as we had some issues with the data extraction for original Morrowind install media)If you do want to sandbox though, users are able to poke just as many holes as they want - or add their own restrictions atop whatever sandboxing you set up for the application. Flatpak itself has the
flatpak overridetool for this, or there’s graphical UIs like flatseal and the KDE control center module…As long as your application is statically linked, I don’t see any issue with that.
So, like, dumb question. People here assumed that I mean AppImages, whereas I actually meant just a statically linked binary. Is that really the only reason why AppImage exists? So, that dynamically linked applications can be distributed like statically linked ones?
You cannot statically link everything. Take graphics libraries and APIs for example, do you statically link against nvidia’s or mesa’s opengl?
Sure, but presumably AppImage/Flatpak/Docker cannot help with that either…?
Flatpak solves the problem with targetable platform versions, you just update the manifest for your app every like 6-12 months to target the new one
Ah, interesting. So, it’s different from just statically linking against the latest driver lib every 6-12 months, because the Flatpak runtime gives you a bit of a guarantee that there won’t be breaking changes in the meantime.
Bingo, and if the latest mesa breaks your app for example, you can target an older one until it’s fixed instead of end users having to fuck around downgrading system packages
This is the problem those tools try to solve. They package everything else upon which software might depend that can’t simply be linked into a single binary.
The majority of AppImages I’ve seen have been dynamically linked, yes. But it’s also used for packaging assets.
Yeah, alright, packaging assets makes sense. I’ve always been fine with just a .tar.gz, but having it be a singular file without compression is cool.
I guess, since AppImage emulates a filesystem, you can also have your application logic load the assets from the same path as if the assets were installed on the OS, so that’s also cool.
You cannot statically link everything. Take graphics libraries and APIs for example, do you statically link against nvidia’s or mesa’s opengl?
AppImage for the win!