So try it our for first time. Install a program and run it.
It goes and downloads python, ffmpeg, vulkan, pytorch blah blah
all stuff what I already installed.
I'll walk down to high street coffee shop while it is faffing around.
On 09/04/2026 12.31, Nomen Nescio wrote:
So try it our for first time. Install a program and run it.
It goes and downloads python, ffmpeg, vulkan, pytorch blah blah
all stuff what I already installed.
I'll walk down to high street coffee shop while it is faffing around.
Yeah, the flatpak will not use system installed binaries, it will be
pulling it's own dependencies from the flatpak repositories, but the
benefit is that any Linux distro will be able to run the same flatpak program, no matter if you have python 3.9 installed, I may have python
3.12 and some other maybe even python 3.13...
The alternative is that your distro compiles the application as a fully native binary, then most of the packages are already installed that it depends on. But see from the bright side, next flatpak you install may
not have to download a flatpak version of ffmpeg, vulkan, python,
pytorch (as long as it depends on the same version as the program you installed).
Flatpak, appimage, snap are just tries to remove the maintenance work program distributions, so that the developers don't have to compile one
for ubuntu x, ubuntu x+1, ubuntu x+2, mint y, mint y+1, mint y+3, fedora
z, fedora z+1, ... and so on
and this is why it is what it is...
On 2026-04-09 15:27, J.O. Aho wrote:
Flatpak, appimage, snap are just tries to remove the maintenance work
program distributions, so that the developers don't have to compile
one for ubuntu x, ubuntu x+1, ubuntu x+2, mint y, mint y+1, mint y+3,
fedora z, fedora z+1, ... and so on
and this is why it is what it is...
At the cost of more resources needed at the users machines. Bigger hard disks (stuff that is installed several times), more RAM needed (you may
need two or three versions of the same library loaded), and probably
more CPU.
At the cost of more resources needed at the users machines. Bigger hard
disks (stuff that is installed several times), more RAM needed (you may
need two or three versions of the same library loaded), and probably more CPU.
But see from the bright side, next flatpak you install may not have
to download a flatpak version of ffmpeg, vulkan, python, pytorch (as
long as it depends on the same version as the program you
installed).
On Thu, 9 Apr 2026 15:27:34 +0200, J.O. Aho wrote:
But see from the bright side, next flatpak you install may not have
to download a flatpak version of ffmpeg, vulkan, python, pytorch (as
long as it depends on the same version as the program you
installed).
It seems to me, it would have to do that regardless. Because it cannot
simply depend on version numbers to ensure the version has the patches
it needs.
Say the application needs a special patch applied to python which
the python developers don't include in their python flatpak, then
need to include your custom python within the applications flatpak,
then it will of course not depend on the official python flatpak,
but will itself be larger, so from download point of view it will
not make a change.
On Fri, 10 Apr 2026 08:29:03 +0200, J.O. Aho wrote:
Say the application needs a special patch applied to python which
the python developers don't include in their python flatpak, then
need to include your custom python within the applications flatpak,
then it will of course not depend on the official python flatpak,
but will itself be larger, so from download point of view it will
not make a change.
The point being, trying to share components between flatpaks would
defeat the purpose of their being self-contained.
On 2026-04-10 10:30, Lawrence D’Oliveiro wrote:
On Fri, 10 Apr 2026 08:29:03 +0200, J.O. Aho wrote:
Say the application needs a special patch applied to python which
the python developers don't include in their python flatpak, then
need to include your custom python within the applications flatpak,
then it will of course not depend on the official python flatpak,
but will itself be larger, so from download point of view it will
not make a change.
The point being, trying to share components between flatpaks would
defeat the purpose of their being self-contained.
A set of flatpacks from one distributor of flatpacks might. Assuming
that you update all the flatpacks at the same time.
Flatpack is an extreme version of static linking. Like static
linking, it makes development easier, but maintenance much harder.
On Fri, 10 Apr 2026 08:54:49 -0400, David W. Hodgins wrote:
Flatpack is an extreme version of static linking. Like static
linking, it makes development easier, but maintenance much harder.
I see it as a system designed to take the packaging role away from the
distro maintainers, and put it in the hands of the developers.
For open-source software, this seems counterproductive. Currently, open-source developers have no problem supporting 300 different
distros, because it is up to each group of distro maintainers to
package the software to fit in with the rest of their product. If they
had to do this themselves, it would just be impractical.
However, it’s clear the aim is to give developers of proprietary
software something resembling the control they already exert when
packaging their products for proprietary platforms.
On Fri, 10 Apr 2026 17:50:57 -0400, Lawrence D’Oliveiro
<ldo@nz.invalid> wrote:
On Fri, 10 Apr 2026 08:54:49 -0400, David W. Hodgins wrote:
Flatpack is an extreme version of static linking. Like static
linking, it makes development easier, but maintenance much
harder.
I see it as a system designed to take the packaging role away from
the distro maintainers, and put it in the hands of the developers.
For open-source software, this seems counterproductive. Currently,
open-source developers have no problem supporting 300 different
distros, because it is up to each group of distro maintainers to
package the software to fit in with the rest of their product. If
they had to do this themselves, it would just be impractical.
However, it’s clear the aim is to give developers of proprietary
software something resembling the control they already exert when
packaging their products for proprietary platforms.
It's a security nightmare.
Without flatpak, and using dynamic module loading, when a security
bug is found in a library module, the author fixes it in the latest
version of the module. Distros then either install the latest
version or backport the patch to fix the bug to the version they are
using, test it and send the updates to their users.
With flatpak, the end user has to hope who ever produced the
flatpacks they are using did that work. If the same module is used
by twenty applications, there are twenty flatpaks that each have to
be fixed and tested. If just one of the flatpak authors doesn't pay
attention and doesn't update the flatpak they produced, the end
user's are left with vulnerable systems.
It's the same progam with static linking, in that the fix has to be--
done multiple times. With static linking, if just one on the
applications isn't updated, again, the end user is left vulnerable.
Using flatpaks, just like using static linking, it makes it easier
for developers, in that they don't have to support multiople
versions of other packages, but it makes it much more work for end
users that want to have secure systems.
The dynamic library system was developed to improve security.
Reverting to static linking or switching to flatpaks reduces that
security.
Regards, Dave Hodgins
Maybe... maybe that developer has the source of the flatpack (whatever
that is) installed in his machine using some distribution. Assuming that system is updated from that distribution, he only need to package again
his flatpacks, no?
The main reason for a developer to use flatpak is because he doesn't
want to spend the time updating his program to work with multiple
versions of a package.
So with 300 different distros
W dniu 15.04.2026 o 00:00, Lawrence D’Oliveiro pisze:
That’s not usually the developer’s problem; that’s normally left up
to the distro maintainers. So with 300 different distros, you have
300 different lots of distro maintainers, which is entirely
scalable and creates no extra work for the developer.
But most of them are based only on the 2 main distros: RedHat and
Debian. Mean: they use rpm or apt. Only small fraction use other
package managers.
This probably simplify programmers life a lot.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,113 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 492335:46:32 |
| Calls: | 14,238 |
| Files: | 186,312 |
| D/L today: |
3,565 files (1,160M bytes) |
| Messages: | 2,514,867 |