Clear Linux Developers Weigh Supporting Snaps

[NotMine999]

Why is flatpak much better than snap? The only "advantage" that i hear often, is that flatpak has "runtimes" to build an app on. The intention is to save space, when multiple apps build on the same runtime and so share their dependencies. But that's stupid. When an app builds on a runtime, it won't need all of the stuff this runtime provides, which means I'm getting stuff that I don't need. Additionally, devs will just lazily build their apps on a runtime that provides much more than the app really needs instead of carefully picking the real dependencies. In the end, it results in a higher storage usage.

Windows has had this type of feature for years. It led to a famously named Windows-specific problem called "DLL he11".

Instead, they should do deduplication of files of applications and require apps to bring every single dependency by themselves. If two applications contain files with the same contents, they could be linked to just one file. Apps would also be more stable, because they're using the libs they're tested against, rather than the ones from the runtime, wich could change at any given time.

Windows tried this approach and it resulted in "DLL he11" due to DLL versioning issues between applications. One application wanted 1 specific DLL version and another application wanted a different DLL version. Initial solution from Microsoft: there wasn't one and the result was "DLL he11". Eventually Microsoft figured out a way to support that sort of environment but it took them until Windows 7 (or Vista?) to get something that mostly works.

I think snap does exactly that, which makes it way better in that regard.

What I don't like about snap, though, is the centralized hosting of applications. While it's easier for the end user, it makes us dependent of Canonical, which is a bad thing. Self-hosting an application should definitely be supported, and auto-updating should still work.

Ahh... the issue that users and developers are currently seeing in the mobile device app store design. Of course there is "side loading" on some mobile devices (if you can "root" the device in some cases), but users are pretty much confined to a specific OS appstore, either Apple or Google.

Ask any mobile app developer about the "monetary touch" that Apple and Google make off of the developer's efforts to generate revenue. Also consider the lack of security that both Apple and Google have demonstrated in managing and curating their respective app stores. For anyone that monitors technology news they know that Apple and Google are regularly and routinely removing applications that have "bad intentions", like "adware" or virtual currency mining features buried in a seemingly harmless app. Yes, that's what I fear in these centralized app stores, compromised applications that are not found out until they have been "active" for some time.

What I miss in both systems, is that I cannot install any version of an app that ever existed or that I cannot install multiple versions at the same time, or that I cannot define the name of an application at setup time, like for example give the node.js executable the name "mynode" and then run node programs with "mynode ./app.js. Whoever implements these features first will be the winner for me.

[ms178]

Sounds like you want "package management" features that already exist today and might only require some "extending" of the existing code.

Will any distributions implement packages to "the Nth degree" of CPU architectures? I doubt it.

Why? While package creation and testing are commonly automated now, there is still the manual process of merging patches, resolving code conflicts, and managing package dependencies & versioning. The alternative is to load up the package creation and testing system with endless lists of "ifdef" rules so the compiling platform(s) can build the packages as desired by humans, but those endless lists are easy avenues to introduce errors.

Given the current state of technology the problem is not impossible to solve. It's simply a very steep series of mountains to climb that will cost a lot in time and person-power to accomplish. Who has the skilled resources needed to devote to a project like that where the ROI ("return on investment") is negligible at best?

Thanks for the insight! I actually played around with Solbuild on Solus which automated dependency solving and applying custom patches to a good degree already - I only needed to change my compiler flags in the package yaml file for certain packages plus a pkbuild.conf file as a default. But Solbuild had some drawbacks, once I altered their yaml file for a package, the update process refused to update that particular package. Even worse, the package update process was consuming several hours just checking a handful of files for each package. I wonder if these are things which could be tweaked even further. This came close to what I want to achieve without needing to go with Gentoo all the way (which is way to unfriendly to setup for beginners like me).

Concerning the ROI argument, I understand that this would need the ressources of a big corporation behind to be feasible, but at least I hope Intel will try to further push the boundaries in the future as I see some value for users in having such an "optimized to the max" distro (just like some Gentoo guys do on Github already). The benchmarks on Phoronix for Clear Linux show that there are instances where this matters more than many thought before. My own custom kernel with a custom config for my machine plus very aggressive compiler flags already made a huge difference in day-to-day usage like web browsing, especially on lower speced machines, RAM usage dropped significantly and the snapiness improved a lot.

[stargazer]

Users may want to install some "flavor" of Linux on a device that is "storage space challenged" and not physically upgradable. In that case a user might want to benefit from something like Flatpaks or Snaps as a way of simplifying the package/application management of their device.

Said another way, not all devices can be upgraded, especially those with soldered in eMMC memory like tablets. And why run Linux on a tablet? You like to use Linux. You can find/write the drivers that you need. And because you can.

First, thank you for responding. While it is a fair argument that there are other use cases such as this, I would put forth that when you are choosing to use a device constrained by its form factor the way tablets are, you're accepting some trade-offs to begin with. This would just be another and flatpack may not be the best option for these scenarios. On the flip side, in 10 years it's likely the baseline storage even in these devices will be large enough to render the point moot. Hopefully flatpack, or whatever technology ultimately solves the problem they're going after, will last longer than that.

[mv.gavrilov]

Why is flatpak much better than snap?

The advantages flatpack over snap in dynamic linking with runtime. It's give gain in size of packages and security updates, because security vulnerability of runtime possible fix without application update. This is a very important advantage because manufacturers of proprietary software are very lazy and not update their runtime as soon as possible.

[cynical]

The advantages flatpack over snap in dynamic linking with runtime.

They’re called content snaps in the snappy system.

https://docs.snapcraft.io/the-content-interface/1074

[wizard69]

OK first off I know little about Snaps or Flatpaks, but for me any ways it is absolutely asinine to try to turn Clear Linux into something it isn't. If somebody wants Snaps would it not be logical to use a distro focused on that system? Frankly Clear Linux needs tell these guys to get off the lawn and play some place else. In a nut shell is is simply childish to try to pollute somebody else's distro for an ill defined reason.

[starshipeleven]

It is not possible, since Flatpak can only support desktop apps, whereas Snaps are used for things like kernels, display servers, services, etc.

Flatpak can deploy any userspace application, not just "desktop apps".

Snap supports kernels and display servers or core OS components only in specific distros you write code to deal with, as distros ship the kernel and bootloader and libraries and stuff in different places, with different names and standards.

[Weasel]

Why is flatpak much better than snap? The only "advantage" that i hear often, is that flatpak has "runtimes" to build an app on. The intention is to save space, when multiple apps build on the same runtime and so share their dependencies. But that's stupid. When an app builds on a runtime, it won't need all of the stuff this runtime provides, which means I'm getting stuff that I don't need. Additionally, devs will just lazily build their apps on a runtime that provides much more than the app really needs instead of carefully picking the real dependencies. In the end, it results in a higher storage usage.

Instead, they should do deduplication of files of applications and require apps to bring every single dependency by themselves. If two applications contain files with the same contents, they could be linked to just one file. Apps would also be more stable, because they're using the libs they're tested against, rather than the ones from the runtime, wich could change at any given time.

I think snap does exactly that, which makes it way better in that regard.

What I don't like about snap, though, is the centralized hosting of applications. While it's easier for the end user, it makes us dependent of Canonical, which is a bad thing. Self-hosting an application should definitely be supported, and auto-updating should still work.

Amen brother, everything you said is just truth.

[Weasel]

Windows has had this type of feature for years. It led to a famously named Windows-specific problem called "DLL he11".

You should keep spelling it like that since clearly you have no idea what you are talking about.

[jo-erlend]

Flatpak can deploy any userspace application, not just "desktop apps".

Snap supports kernels and display servers or core OS components only in specific distros you write code to deal with, as distros ship the kernel and bootloader and libraries and stuff in different places, with different names and standards.

What I meant is that Flatpak requires a desktop session, hence making it mostly useful for desktop apps. I guess you _could_ use it for non-desktop stuff like a web server, adding desktop as a requirement to that web server, but it wouldn't make much sense.

Snap can install files to any location, as long as you permit it. In short, any software you're allowed to manually build and install on system, can be installed using Snap. The point I was responding to, was that people should use Flatpak for everything and get rid of Snap. That's not going to be possible, as Snap is used for more things than Flatpak is capable of. Now that we have package systems that can easily coexist for most things, I think wide support is a good thing. Not everything has to be a war.

By the way; this discussion is about a specific distro.