Why Canonical Views the Snap Ecosystem as a Compelling Distribution-Agnostic Solution (techrepublic.com) 93
Canonical's Martin Wimpress addresses Snaps, Flatpak, and other competing standards, and community unease around Canonical's control of the Snap store. intensivevocoder writes: With these advances in hardware support, the last significant challenge users face when switching from Windows or Mac to a Linux distribution is app distribution and installation. While distribution-provided repositories are useful for most open source software, the release model of distributions such as Ubuntu or Fedora lock in users to a major version for programs for the duration of a particular release. Because of differences in how they interact with the underlying system, certain configuration tasks are different between Snaps or Flatpaks than for directly-installed applications. Likewise, initial commits for the Snap and Flatpak formats were days apart -- while the formats were developed essentially in parallel, the existence of two 'universal' package formats has led to disagreement about competing standards. TechRepublic interviewed Martin Wimpress, engineering manager for Snapcraft at Canonical, about Ubuntu's long term plans for Snaps, its adoption and support in other Linux distributions, Canonical's position as the operator of the Snap Store, and the benefits Snaps provide over Flatpak. An excerpt from the interview: TechRepublic: Practically speaking, there are two competing standards for cross-platform application packaging -- three, if you count AppImage. What's the practical benefit that Canonical's Snap format offers over Flatpak or AppImage?
Martin Wimpress: If you look at the initial commits of both of those projects, Snaps have a lineage back to Click packages, which were developed for [Ubuntu Phone] originally. The Snap project developed out of what had been learned from doing the phones, with a view to solving problems in IoT. So, although technically snapd and xdg-apps -- and consequently Flatpak -- look like they emerged around the same time, Snaps can trace their lineage back to the Click project from several years previous. If we're looking at Flatpak specifically, we can probably include AppImage in most of these comparisons as well. Some of the similarities are that Snaps are self-contained software packages, which is something that Flatpak and AppImage strive to be as well. I think that Flatpak achieves that better than AppImage. I think AppImage still makes some assumptions on what's installed on the host operating system. It doesn't bundle everything inside the AppImage. Similarly, Snaps, Flatpak, and AppImage work across all the major Linux distributions without modification. We haven't all arrived at this solution by accident. We've clearly, independently, all realized that this is a problem that we need to solve in order to encourage software vendors to publish their applications on Linux, because Linux is a very broad platform to target. If you can lower the hurdles... to getting your software in front of users on Linux, then that's a good thing. And we're all aiming to do the same thing there.
Martin Wimpress: If you look at the initial commits of both of those projects, Snaps have a lineage back to Click packages, which were developed for [Ubuntu Phone] originally. The Snap project developed out of what had been learned from doing the phones, with a view to solving problems in IoT. So, although technically snapd and xdg-apps -- and consequently Flatpak -- look like they emerged around the same time, Snaps can trace their lineage back to the Click project from several years previous. If we're looking at Flatpak specifically, we can probably include AppImage in most of these comparisons as well. Some of the similarities are that Snaps are self-contained software packages, which is something that Flatpak and AppImage strive to be as well. I think that Flatpak achieves that better than AppImage. I think AppImage still makes some assumptions on what's installed on the host operating system. It doesn't bundle everything inside the AppImage. Similarly, Snaps, Flatpak, and AppImage work across all the major Linux distributions without modification. We haven't all arrived at this solution by accident. We've clearly, independently, all realized that this is a problem that we need to solve in order to encourage software vendors to publish their applications on Linux, because Linux is a very broad platform to target. If you can lower the hurdles... to getting your software in front of users on Linux, then that's a good thing. And we're all aiming to do the same thing there.
Buying a paid snap requires photo ID (Score:2)
Running your own instance of Mastodon costs money, as does buying a paid snap. For the AC who posted this screed, any attempt to pay electronically with a debit card ends up with a demand for a scanned photo ID.
Re: (Score:2)
It will have the added benefit of having absolutely nobody else on his social media platform.
Re: (Score:2)
In Germany, we have a law that requires providers to give minimum guarandeed speeds when offering services.
And none of the VPNs advertise speeds that come anywhere near saturating your connection to your ISP.
You need to move somewhere with a social climate that is nicer and more on YOUR side.
What qualifications does Germany place on immigrants from outside the European Union other than having completed most of Duolingo's German course?
Hotmail? Seriously? You're a geek! Getna fixed IP and run your own mail gateway/server at home!
Many people live in areas where the local ISP or ISPs refuse to offer fixed IPs to residential subscribers. See Bert64's comment [slashdot.org].
Don't use freakin web services! Use real software. With real clients. And their own port number! [...] Most services have a better solution in real software anyway.
Do most major banks offer such a desktop application, either for Linux or compatible with Wine? Last I checked, most banks' native appli
Snap annoyances (Score:4, Insightful)
I wouldn't mind snap packages so much if every package didn't appear as a separate file system on my df output. If I just want to see what utilization I have on one of my 3 disks, I have to sift through 20 other /dev/loop snap filesystems.
Re: (Score:1)
100% agreed. An extra file system per app is stupid.
Re: (Score:2)
It's called grep -v
You don't invent separate parameters for every program if a generic tool can do it.
Re: (Score:2)
--What, you never heard of piping DF output to ' grep -v ' ?
Re: (Score:2)
So use one of the most basic elements of Unix functionality, shell scripting, and write a wrapper that strips them out.
I find that kind of stuff irritating too, because it's not what I'm used to either, but it's not hard to fix.
He who doesn't understand static linkage... (Score:2, Interesting)
is doomed to reinvent it, poorly.
Re: (Score:2)
The problem is not the binary, but rather the additions to desktop menus, icons, etc.
The linux filesystem is not laid out in a way that is modular, so their fix was ro overlay sevzral parallel filesystems on top of each other.
So provide a source package (Score:2)
If you can lower the hurdles... to getting your software in front of users on Linux, then that's a good thing. And we're all aiming to do the same thing there.
Okay, so provide us with a source package for at least Debian and Redhat, and we'll take it from there. There's no need for all of this other nonsense. If you also want to provide a containerized distribution that's fine, but I'm not interested in it.
Re: (Score:2)
Okay, so provide us with a source package for at least Debian and Redhat, and we'll take it from there.
Would it be acceptable to provide this source code under a non-disclosure agreement to each paying licensee of the software, or does it have to be specifically under a free software license? There are a few categories of application that aren't likely to become free software any time soon, such as major video games, clients for paid video on demand services, and annual individual income tax return preparation software.
Re: (Score:2)
Would it be acceptable to provide this source code under a non-disclosure agreement to each paying licensee of the software, or does it have to be specifically under a free software license?
As long as they permit redistribution of the binaries, someone will likely take on binary package maintenance. The specifics of the license don't really matter for these purposes, although using a Free Software license might be more likely to attract lasting maintainer interest.
Re: (Score:2)
Re: (Score:2)
Sarcastic response: are any of these applications ever going to appear for GNU/Linux anyway?
Games linked to Steam Runtime are among them. That's why I've recommended Steam Runtime as a fourth solution alongside Snap, Flatpak, and AppImage.
Re: (Score:2)
Why is tax return software confidential? Shouldn't the rules for taxes be open to all?
Proprietary translation of free tax code (Score:2)
Why is tax return software confidential? Shouldn't the rules for taxes be open to all?
Though the tax code itself written in English legalese is public sector, public, and viewable without charge, the machine-executable interpretation thereof is private sector, a trade secret, and paywalled and/or provided as "service as a software substitute." This is how the United States happened to choose to organize its income tax assessment procedure.
Snap/flatpak security issues (Score:5, Insightful)
Snap's, flatpaks and these other app store like distributions of software often result in software packages with hundreds of additional applications and dependencies included with the snap and I personally question the security of doing it this way. Is the packager of the snap tracking and updating the snap for all the vulnerabilities in these other packages? (haha)
Distributions don't always do a good job tracking vulnerabilities and making sure included software is always up to date and inline with upstream but it's 10,000% better than what these flatpak and snap packages present. Some of these snaps (like LXD as an example) include half a distributions worth of a binary dependencies and I doubt Canonical and other packagers are tracking all these dependencies security issues and updating the snaps for them.
IMO these snap like packages are the same security nightmare that docker containers present. You've got a cluster of software built and packaged by god knows who with absolutely no tracking of security and updates. No doubt this stuff is convenient for a one time use or testing but unless you package it yourself you've got no idea what security nightmare is included and you'd have to be crazy to use it a production environment unless you build them yourself.
Snaps could be really cool, but without some sort of security guarantees and updating they will IMO turn out to be massive exploit channels if they see wide deployment.
Re: (Score:3)
Well said. containerized applications work for development and work on the server side but should never be used as desktop applications. Not only are they security liabilities like you pointed out but they are also inefficient. You are essentially running a VM on your desktop just for that one application.
What ever happened to caring about bloat? Are developers that lazy now?
You want something portable then use a portable language like Java. You want to fix dependency issues then stop using dynamic linking
Re: (Score:2)
I actually am of the view that snaps, flatpaks, etc. are a good thing. It ensures that the app has a known, tested environment. Otherwise, who knows what might be on a machine? Is it a recent version of python, or a backport? Are other libraries up to date? This is especially true when you want software to run consistently well across distros that have different file structures and patch managers.
What really sucks is that one image is done by one OS provider, one image is done by another, and they are
Re: (Score:2)
You can run a flatpak on Ubuntu and a snap on Fedora.
Stop spreading misinformation.
Re: (Score:2)
What ever happened to caring about bloat? Are developers that lazy now?
My own experience suggests they ARE that lazy, but that laziness was well-entrenched long before Flatpaks and the like started to really take off. I'm not a programmer so I could be totally wrong here, but IMHO Snap and Flatpak were at least partly a response to the growth of the Linux equivalent of DLL hell. When I try to install a program from the repos and it wants to bring in almost the entirety of some other DE, I suspect developer and/or maintainer laziness. When I try to install something and it brin
Re: (Score:2)
Java is not more portable than C or C++.
Re: (Score:2)
The standard library of Java SE includes Swing. The standard libraries of C and C++ contain no graphical user interface components. Instead, developers of graphical applications in C or C++ are expected to rely on implementation-defined behavior of mutually incompatible GUI frameworks provided by each operating system. Therefore, a graphical application in Java SE is more portable than a graphical application in C or C++.
Re: (Score:2)
Qt works on more platforms than Swing.
Comparing the standard library of an ISO standard to that of a language controlled by a single corporation is also a bit ridiculous.
Finally, only a tiny segment of developers care about GUI toolkits, it's a niche domain. Evaluating portability solely based on this is simply heavily biased.
Source vs. binary compatibility (Score:2)
Qt works on more platforms than Swing.
Only at the source code level, not at the binary level. A jar using Swing can run on any platform with Java SE. A native executable using Qt will work on only one platform. If the program is proprietary, only its developer can make it available on other platforms, and developers have been known to upcharge for this or even refuse outright.
Finally, only a tiny segment of developers care about GUI toolkits, it's a niche domain.
If graphical applications (those that use a GUI toolkit) form "a niche domain" that is so small as to be worthwhile to ignore, then I must have some sort of fundamental mi
Re: (Score:2)
Both Java and C++ can target a variety of architectures, some of which are native, some of which are native to some other architectures but easy to emulate, some of which are native to no architecture and need to be emulated everywhere (e.g. bytecode).
Relevant projects for C++ include for example WebAssembly, and plenty of other things you can find by googling, mostly LLVM-based.
That Java specifies
Re: (Score:2)
Not only are they security liabilities like you pointed out but they are also inefficient. You are essentially running a VM on your desktop just for that one application.
No! It's worse than that! A VM would give some meaningful separation. None of these popular OSS container formats use hypervisors (although there are hypervisor-based containers) and so none of them use VT. So there's hardware sitting there which could improve security (not like it's impossible to break out of a hypervisor, but still) and it's just going unused.
So everyone throws up their hands and says fuck it, we will just bake it into a VM with everything we need.
VMs are smarter than containers without hypervisors. I say fuck it, too.
Re: (Score:2)
So everyone throws up their hands and says fuck it
Hi, I've had to package an application in flatpak. Completely volunteered to do it too. Here's the deal. The software uses libgoocanvas pretty heavily. Now most major distributions have completely dropped libgoocanvas and moved on to better pastures and I don't blame them. However, this one piece of software I don't maintain is still heavily reliant on it. Now, the thing is the team that does support the software is literally a team of three. So they've been rewriting the software since 2017. They'r
Re: (Score:2)
And that makes sense given we are talking about Linux. But I still think conceptually snaps and the like are the wrong solution to this problem. In Windows if you have dependencies that aren't included in the OS then you ship them with the application and they get installed at the same time. I saw someone mention issues with having multiple concurrent installs of glibc. I can't tell you how many concurrent installs of the M$ C++ equivalent I have on my Windows system. But its a lot and the OS manages to let
Re: (Score:2)
1. How does your system determine that a new version of the "statically linked binary which has all its dependencies" is available?
2. How does your "statically linked binary which has all its dependencies," including libc, interact with the system's X11 and OpenGL libraries, which are linked to the system libc? Last I checked, mixing libc implementations was dangerous, in part because malloc with one libc and free with another has undefined behavior. Or are you assuming use of the system libc, where memcpy
My only complaint (Score:2)
My only complaint is that Snaps, Flatpaks, and AppImages aren't kept updated to stay current with the most recent release of the non-containerized software. Often they're multiple revisions behind.
Other than that, they seem very handy and simple to use. Disk pace is cheap and I don't mind keeping a few of the previous revs on hand in case I need to revert to a previous version for some reason (which I haven't had to do yet).
Re: (Score:2)
Do you find storing boolean values in a 64-bit integer field OK too? Or how about as a string representation "False". Preferabl with XML tags around them. ;)
And every process, thread an function gets its own copy of the entire data structure tree on the heap. :P
1) Yes, I always store boolean values in a 64-bit integer field, just in case the "1" or "0" turns out to be a really big "1" or "0".
2) Yes, I always store the text string "False" as a completely sensible way to represent "0"; it's so much more readable that way, don't you think? Sometimes I pad it with lots of zeroes (on both sides) just to make sure the server "gets it".
3) Yes, of course everything gets its own copy of the entire data structure tree, what the fuck else am I supposed to do with all that un
Re: (Score:2)
The small number of programs that I run from AppImages tend to be kept up-to-date by the software developers.
The bigger issue is that AFAICT Snaps (never heard of Flatpaks) appear to depend on systemd. This makes them unusable on systemd-free systems (such as Gentoo), which means it's hardly a universal Linux binary distribution format. AppImages don'
Re: (Score:2)
My only complaint is that Snaps, Flatpaks, and AppImages aren't kept updated to stay current with the most recent release of the non-containerized software. Often they're multiple revisions behind.
Other than that, they seem very handy and simple to use. Disk pace is cheap and I don't mind keeping a few of the previous revs on hand in case I need to revert to a previous version for some reason (which I haven't had to do yet).
Funny, my main complaint is the opposite - I don't want (certain) packages being updated automatically.
I have Eclipse installed, with several plugins. The plugins may work on later versions, but they may not. Since I'm developing code for an ARM microcontroller, and I'm working with other developers, I have to use the same version of the tools during my entire development process (unless we all evaluate and choose to change to a newer version).
I was surprised to find that suddenly I wasn't able to compile
Re: (Score:1)
Re: (Score:2)
The closest utility that frees us from dependency hell and distro hell is AppImage. Snap is great... if you are on Ubuntu. Flatpak is great, for RedHat and derivative operating systems. However, neither works outside their own arenas.
It would be nice to have a cross distro standard, perhaps using some lightweight containerization to limit what a rogue app can do to a filesystem, and to make it easy to back up and restore user data stored in the app's "worlds", be it a VM, container, jail, or whatnot.
Re: (Score:2)
Reading this transphobic screed makes me want to stop recommending APK Hosts File Engine, write a replacement under a free software license, and distribute it as a snap for use in a gateway that runs Ubuntu IoT.
Why Canonical Views Snap Ecosystem as Compelling? (Score:2, Insightful)
Because they developed it.
Terrible idea (Score:1)
We will need to update snaps every time a component or library is updated, and have to rely on the package maintainer to make sure the entire food chain is up to date. That sounds like a lot of work and a lot of downloading.
Snap daemon (Score:1)
Can we not have snapd as a long lived process, listening all the time?