3 ms·

The last app image I've installed took 800 MB. It was approximately 720 MB of libraries, and just 80 MB of core program. Using self-contained images is simply n

The last app image I've installed took 800 MB. It was approximately 720 MB of libraries, and just 80 MB of core program. Using self-contained images is simply not scalable. I have some experience with packaging, and if we talk about standalone applications, dependencies aren't a big deal; producing deb packages for different targets is not difficult. The last (only) breaking change across different targets I can remember was old graphic libraries (I think it was gtk2-based WxWidgets, removed in newer Ubuntu versions).

manuelabeledo 4y ago
> The last app image I've installed took 800 MB. It was approximately 720 MB of libraries, and just 80 MB of core program. Using self-contained images is simply not scalable. This is one of the points they are missing with snaps and flatpaks. These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates. Do I want to spend my time worrying about setting up a package cache, because a handful of updates are costing me a small fortune in transfers? Why would I need to think about what snap is doing in my small instance with a 16GB volume, when I use it to run a certainly small application? Snaps are an absolute nightmare in these scenarios.
- PlutoIsAPlanet 4y ago
  > These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates. Containers have already won the war on the Linux server, there's no point Flatpak etc trying to compete here. Additionally, desktop software is a complete design paradigm to server software. I wouldn't even say they make sense to be in the same package manager. Although they do share tech, ostree, namespacing etc.
  - manuelabeledo 4y ago
    > Containers have already won the war on the Linux server, there's no point Flatpak etc trying to compete here. There are things that you just cannot run inside a container. Also, in cloud environments, default provisioning is not done with containers, which makes sense, but directly causes the issues I mentioned, e.g. Amazon provisioning SSM on Ubuntu Server instances.
- m4rtink 4y ago
  Not sure about snap, but at least for Flatpak, it has runtimes and runtime extensions that Flatpaks can share, which already reduces the individual Flatpak size. But further more, all runtime, extensions and Flatpaks live in a single OSTree repository on the system, which does automatic de-duplication on the file level. While probably still less efficient than a properly maintained and integrated distro, where all software uses a single set of shared core libraries, its actually (in the Flatpak case) quite optimized & has additional benefits, such as installing a set of apps that don't share a common set of required library versions, which would normally be impossible.

manuelabeledo 4y ago

> The last app image I've installed took 800 MB. It was approximately 720 MB of libraries, and just 80 MB of core program. Using self-contained images is simply not scalable. This is one of the points they are missing with snaps and flatpaks. These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates. Do I want to spend my time worrying about setting up a package cache, because a handful of updates are costing me a small fortune in transfers? Why would I need to think about what snap is doing in my small instance with a 16GB volume, when I use it to run a certainly small application? Snaps are an absolute nightmare in these scenarios.

PlutoIsAPlanet 4y ago
> These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates. Containers have already won the war on the Linux server, there's no point Flatpak etc trying to compete here. Additionally, desktop software is a complete design paradigm to server software. I wouldn't even say they make sense to be in the same package manager. Although they do share tech, ostree, namespacing etc.
- manuelabeledo 4y ago
  > Containers have already won the war on the Linux server, there's no point Flatpak etc trying to compete here. There are things that you just cannot run inside a container. Also, in cloud environments, default provisioning is not done with containers, which makes sense, but directly causes the issues I mentioned, e.g. Amazon provisioning SSM on Ubuntu Server instances.
m4rtink 4y ago
Not sure about snap, but at least for Flatpak, it has runtimes and runtime extensions that Flatpaks can share, which already reduces the individual Flatpak size. But further more, all runtime, extensions and Flatpaks live in a single OSTree repository on the system, which does automatic de-duplication on the file level. While probably still less efficient than a properly maintained and integrated distro, where all software uses a single set of shared core libraries, its actually (in the Flatpak case) quite optimized & has additional benefits, such as installing a set of apps that don't share a common set of required library versions, which would normally be impossible.