Flatpak makes more sense for how Valve will be using it for all their new devices. Simple as that.
They “shit” money into ALL kinds of development that pushed lots of projects forward a decade in maybe a years time, and are doing it again with FEX. Are you taking issue with allmof that, or just this because they have a business use-case?
B: The author’s point was that Flatpak solves a lot of pain points for developers on Linux with distribution that Appimage doesn’t, and package managers certainly don’t, and that if there’s going to be companies like Valve and Redhat that are going all-in on that method, it would benefit the Linux ecosystem that’s currently driving away developers in droves with fragmentation to consider that.
Personally I like Appimage for just being able to grab a file and run it, and I integrate Gear Lever updates by building my own repackaging infra to keep projects that use it updating via Gear Lever’s Update All button. But I can completely commiserate with the idea that it isn’t very useful for most users to have to come up with things like that themselves when Flatpak is easily integrated with Discover and other packagekit software updaters.
You would figure that most developers would just work on the platform that gives them the tools to do what they do most easily. Yet the amount that won’t use Linux and instead seemingly cripple themselves by developing on Mac or Windows frankly astounds me. But I’m also very used to Linux’ pain points, having used it since the 90s. If I only every got my software with an .exe or .dmg download, I’d probably shy away as well.
I couldn’t imagine working with Docker Desktop or WSL, or depending on Brew to have everything I need, but that’s the reality for many, because it’s familiar and simple. The underlying operating system is abstracted away so they don’t have to deal with it, and sticking their nose in Linux is scary and confusing, especially if you’re expected to deal with the panoply of installation methods available to your software. When I dealt with Windows in the long-long ago, you built a MSinstaller package and went on your merry way.
And if you look at new developers today, do you think they’d put up with RBBS for a minute if that’s how they got their software out?
I don’t really get the point of the blog, honestly, because in the first part they are railing against one angle, then reverse and argue FOR it in a sense by saying Flatpak just works. Of course it does. That’s it’s job.
AppImage also just works, but there is a fundamental difference in the delta of what you get as a payload. AppImage has EVERYTHING the image needs to run. Flatpaks only contain the running code and custom dependencies, then it’s manager solves for shared libraries and generics from commonly available layers to download and run to solve for those deps.
Both make sense depending on how you feel you need to tackle the problem.
Where the author kid of goes off the rails is complaining that somehow either camp is somehow responsible for their product being popular enough to survive and be taken up by Valve. In this specific case, Valve is intending to include simple packaging for games and libraries they intend to ship to millions of cross platform devices. Flatpak makes sense from a bandwidth and storage standpoint for end-users.
AppImage does not. No idea why this person is taking issue with that.
Flatpak makes sense from a bandwidth and storage standpoint for end-users.
While flatpaks “share” dependencies, different flatpaks depend on different flatpak runtimes and even different versions of the same runtime, so it is actually the least efficient way to ship software.
If you talking about the infrastructure cost, then yeah it flatpak would be ‘better’. since all your users would use the same runtime and you only have to ship the binary.
But this only makes sense for the first time the user downloads the application, because it turns out appimage can do delta updates just like flatpak lol
In practice not even the first point is true btw, a lot of flatpaks often ship bundled in dependencies (due to having compat issues with the flaptak runtime), so the donwload size of the .flatpak alone is similar or bigger than the one of the appimage.
I think their point, in the first part at least before going off on ideology, is that appimage makes things a lot harder for developers. At least I think that’s their point, the rantiness makes it hard to distinguish technical points from the idealogical…
the Linux ecosystem that’s currently driving away developers in droves with fragmentation to consider that.
I am very skeptical of this. Exactly which developers are being driven away “in droves” because of packaging system differences? If you want to make a case for that assertion, you’re going to have to identify them, so they can be counted.
If it turns out that there are many developers who think like this, someone ought to let them know that they don’t have to package open-source software for every distro out there in order to reach all the major distros. Just package it for one, or even none, and let package maintainers do their thing.
Or, are you talking about proprietary software? That would be a different discussion.
Flatpak makes more sense for how Valve will be using it for all their new devices. Simple as that.
They “shit” money into ALL kinds of development that pushed lots of projects forward a decade in maybe a years time, and are doing it again with FEX. Are you taking issue with allmof that, or just this because they have a business use-case?
A: It’s not my blog
B: The author’s point was that Flatpak solves a lot of pain points for developers on Linux with distribution that Appimage doesn’t, and package managers certainly don’t, and that if there’s going to be companies like Valve and Redhat that are going all-in on that method, it would benefit the Linux ecosystem that’s currently driving away developers in droves with fragmentation to consider that.
Personally I like Appimage for just being able to grab a file and run it, and I integrate Gear Lever updates by building my own repackaging infra to keep projects that use it updating via Gear Lever’s Update All button. But I can completely commiserate with the idea that it isn’t very useful for most users to have to come up with things like that themselves when Flatpak is easily integrated with Discover and other packagekit software updaters.
As an old GenX who grew up with BBSs, Fidonet and dialup shell accounts so I’m probably missing something…
Where are the Linux developers being driven in droves to exactly?
We’ve always had nix fragmentation, that’s the nature of FOSS.
Teach this old gramps what he doesn’t understand.
You would figure that most developers would just work on the platform that gives them the tools to do what they do most easily. Yet the amount that won’t use Linux and instead seemingly cripple themselves by developing on Mac or Windows frankly astounds me. But I’m also very used to Linux’ pain points, having used it since the 90s. If I only every got my software with an .exe or .dmg download, I’d probably shy away as well.
I couldn’t imagine working with Docker Desktop or WSL, or depending on Brew to have everything I need, but that’s the reality for many, because it’s familiar and simple. The underlying operating system is abstracted away so they don’t have to deal with it, and sticking their nose in Linux is scary and confusing, especially if you’re expected to deal with the panoply of installation methods available to your software. When I dealt with Windows in the long-long ago, you built a MSinstaller package and went on your merry way.
And if you look at new developers today, do you think they’d put up with RBBS for a minute if that’s how they got their software out?
In my experience fragmentation of Linux is not at all why people
I don’t really get the point of the blog, honestly, because in the first part they are railing against one angle, then reverse and argue FOR it in a sense by saying Flatpak just works. Of course it does. That’s it’s job.
AppImage also just works, but there is a fundamental difference in the delta of what you get as a payload. AppImage has EVERYTHING the image needs to run. Flatpaks only contain the running code and custom dependencies, then it’s manager solves for shared libraries and generics from commonly available layers to download and run to solve for those deps.
Both make sense depending on how you feel you need to tackle the problem.
Where the author kid of goes off the rails is complaining that somehow either camp is somehow responsible for their product being popular enough to survive and be taken up by Valve. In this specific case, Valve is intending to include simple packaging for games and libraries they intend to ship to millions of cross platform devices. Flatpak makes sense from a bandwidth and storage standpoint for end-users.
AppImage does not. No idea why this person is taking issue with that.
While flatpaks “share” dependencies, different flatpaks depend on different flatpak runtimes and even different versions of the same runtime, so it is actually the least efficient way to ship software.
https://pkgforge-dev.github.io/Anylinux-AppImages/disk-usage-vs-flatpak.html
An example:
Application Payload = 100MB AppImage all inclusive image with deps = 175MB Flatpak App Layer = 101MB Flatpak Deps = 75MB
Now say you’re shipping 1000’s of similar applications with the same general dependency chains in bulk operations to things like end-user devices.
Flatpak wins. That’s the point.
This isn’t a discussion about an average Desktop user saving some disk space.
If you talking about the infrastructure cost, then yeah it flatpak would be ‘better’. since all your users would use the same runtime and you only have to ship the binary.
But this only makes sense for the first time the user downloads the application, because it turns out appimage can do delta updates just like flatpak lol
In practice not even the first point is true btw, a lot of flatpaks often ship bundled in dependencies (due to having compat issues with the flaptak runtime), so the donwload size of the
.flatpakalone is similar or bigger than the one of the appimage.🤣
My gawd. The hoops you jump through. Just take the L and walk on, slugger.
Didn’t know that measuring and comparing means I’m jumping thru hoops.
I think their point, in the first part at least before going off on ideology, is that appimage makes things a lot harder for developers. At least I think that’s their point, the rantiness makes it hard to distinguish technical points from the idealogical…
I am very skeptical of this. Exactly which developers are being driven away “in droves” because of packaging system differences? If you want to make a case for that assertion, you’re going to have to identify them, so they can be counted.
If it turns out that there are many developers who think like this, someone ought to let them know that they don’t have to package open-source software for every distro out there in order to reach all the major distros. Just package it for one, or even none, and let package maintainers do their thing.
Or, are you talking about proprietary software? That would be a different discussion.
Even if maintainers wouldn’t just package stuff themselves. How many formats do you need to cover 95% of the eco system? More than 3?