171–180 of 410 posts
Snap startup speeds have increased considerably since https://ubuntu.com/blog/why-lzo-was-chosen-as-the-new-compre... Spotify and telegram open up pretty much instantly for me. Ubuntu 20.04
People have tried to provide a packaging format that would allow apps to declare their depencies in a distribution neutral manner[1]. It was, uh, not a huge success. Let's take an extreme example. If I build an app on Ubuntu and then try to run it against the system libraries on Alpine, it'll fail, because Alpine is built against a different libc. We can simply declare Alpine out of scope and only support glibc based…
Same problem that flatpak is solving (shiping binaries that would work across many distros) already have at least two solutions - static binaries (where possible, golang is great here), or shell wrappers that point dynamic linker to appropriate private /lib directory.
Among the 3 solutions here flatpak is the most complex, and least compatible with what advanced user might do - run stuff in private containers, with different init, etc.
There is a deep trend happening in software development. As the number of dependencies for building an application grows, it becomes exponentially harder to shake the tree. This used to be the role of Linux distributions, they were acting as a push-back force, asking projects to support multiple versions of C libraries. This was acceptable because there is not C package manager. Now that each language has their own p…
This is a very good observation I think. Basically, what Linux distributions have failed to do is to create a higher level SDK for their platforms - instead, they rely on a soup of libraries and on the package maintainer model to know which of these is which.
Basically, they are failing to provide a true OS: there is only a Kernel + various user space apps, from systemd to KDevelop, with no explicit line in the sand between what is the system SDK and what is a simple app bundled with the OS.
The short (but polite) rebuttal to this is - OSX. DMG files are similar sized and proven to be very successful. For e.g. - firefox ( https://www.mozilla.org/en-US/firefox/all/#product-desktop-r... ). Win64 installer is 50mb. MacOS installer is 130mb. Linux 64-bit is 70mb. Same is the case with Chrome - https://chromeenterprise.google/intl/en_US/browser/download/... . Windows MSI is 79mb. OSX PKG for the same is 195mb…
Firefox is larger on macOS because it contains 2 archs (x86_64 and arm64), not because it bundles of full runtime -- also the compression algo of dmg files is typically quite bad (zlib or bzip2), which is not helping.
Having said that, I never bothered installing it on my current laptop which sort of reinforces the point others are making about being less concerned with application size.
I think this article is not providing adequate alternatives. Most programs link against quite a bit more than libstdc++ and you clearly can't expect users to install a bunch of packages to get their program running. Those extra libraries usually take up most of the space in a package. If you include all the shared libraries you need, apart from the system libraries in your distribution, you pretty much have an AppIma…
That's not wrong, but AppImage is focused on the UX of the application as single file, which you can move/copy around and can be integrated with the desktop launcher, which i personally don't know of standard solutions for with a classic tarball. For example, Tor Browser is a classic tarball and works great, but the .desktop generation relies on some hacks rather than a properly-defined mechanism.
> the author was complaining about the complexity introduced by Proton
That's not what i understood from the article. I mean wine/proton makes sense on its own to run Windows apps, i think the author was criticizing that their specific approach relies on steam-specific runtimes instead of using system libraries.
Earlier quoted context omitted.
it’s been tested and almost all library packages are only used by one other package on the system. And almost all of the sharing comes down to a very limited set of libraries. Flatpak solves this with platforms. You can base a package on the gnome platform for example and get a whole bunch of the most used libraries. But even without platforms, disk space is one of the most abundant resources right now. You could ins…
> it’s been tested and almost all library packages are only used by one other package on the system. I have a KDE desktop, are you trying to imply that only one of the dozens of applications provided by it actually use Qt? That only one of the dozens of image related programs use libpng, libtiff,libjpeg, etc. ? Or are you just citing a highly misleading statistic?
People have tried to provide a packaging format that would allow apps to declare their depencies in a distribution neutral manner[1]. It was, uh, not a huge success. Let's take an extreme example. If I build an app on Ubuntu and then try to run it against the system libraries on Alpine, it'll fail, because Alpine is built against a different libc. We can simply declare Alpine out of scope and only support glibc based…
> People have tried to provide a packaging format that would allow apps to declare their depencies in a distribution neutral manner[1]. It was, uh, not a huge success. Have you looked into Nix?
Though, here is e.g. https://github.com/matthewbauer/nix-bundle, which is supported as an experimental command in nix 2.4.
From my subjective (user) point of view, flatpak is pretty fine. Yes, I do get annoyed whenever I run flatpak update and see 5-10 updates to drivers or runtimes in the range of ~100MB each. But I also want applications to be "just working". What kinda annoys me though is that file dialogs open in the background. Now I am used to check for it, but when the main window is still in front, yet blocked, because focus is i…
I'm also familiar with this approach, but that's unfortunately something i can't easily teach my friends. AppImageLauncher is arguably more user-friendly, and i wish it were more commonly distributed as a distro default.
Don't know what to think about this blog post; it's not a very coherent critique, since it throws together various issues of user-packaging-formats that mostly specific to only one of the formats. And these don't seem to be 'inherent' in their design. Well, one is. Let's go through some of the issues: > Size My /var/lib/flatpak is 13 GB in size. That's a lot of space. On the other hand; that's about one game with con…
> Neither Flatpak nor Snap have increased memory usage because of containerization. Yes it does, because you end up loading multiple versions of the shared libraries. There is also the memory used by the flatpack/snap daemons. Snapd is quite big since it is written in Go.
Given that not all applications necessarily use the same libraries and versions, that's an issue you cannot avoid even with shared libraries.
So, yes are right; it could be an issue. But it doesn't strictly have to do with the containerization.
To be thorough, let me qualify my statement:
Neither Flatpak nor Snap do necessarily result in an increased memory usage because of containerization.
> Snapd is quite big since it is written in Go.
Yes, that's true. Go probably wasn't the best idea for a system daemon.
Feel like we’ve really missed an intermediate solution based around tree-shaken statically compiled code. A lot of the goals achieved by docker et al could be met with some kind of multi-elf file format that is basically a collection of statically linked executables combined with a way to read built-in configuration files. Maybe this already exists / works.