Former Canonical Developer is Working on a Script that Replaces Snaps with Flatpaks (linux-magazine.com) 69
Linux magazine reports that "Former Snap co-developer Alan Pope, who left Canonical in 2021 after 10 years with the company, has developed unsnap, a script that replaces snaps with Flatpaks where available. The script, hosted on GitHub, has been tested by the developers for use on Ubuntu and all derivatives that offer snapd and packages in the Snap format."
Pope clarifies its status on GitHub: Let's say it's "Pre-alpha", as in "It kinda works on my computer". Unless you plan on contributing (see below) it's probably not ready for you, yet.
And Pope notes the existence of "related projects" like the custom-desktop project by Natan Junges "which provides a set of packages to revert an existing Ubuntu install back to something many users may appreciate more." And "deb-get enables Ubuntu users to install and update deb-based packages of popular applications"
But Linux magazine tested out unsnap: The flatpak list command can be used to determine which snaps were converted to Flatpak format. For snaps with a Flatpak equivalent, unsnap converted these snaps cleanly, and all of the programs remained functional. The script left the remaining snaps and the infrastructure untouched...
An equivalent Flatpak must be available, which is very often the case with graphical applications. With a little manual work, the Snap infrastructure can also be removed.
Pope clarifies its status on GitHub: Let's say it's "Pre-alpha", as in "It kinda works on my computer". Unless you plan on contributing (see below) it's probably not ready for you, yet.
And Pope notes the existence of "related projects" like the custom-desktop project by Natan Junges "which provides a set of packages to revert an existing Ubuntu install back to something many users may appreciate more." And "deb-get enables Ubuntu users to install and update deb-based packages of popular applications"
But Linux magazine tested out unsnap: The flatpak list command can be used to determine which snaps were converted to Flatpak format. For snaps with a Flatpak equivalent, unsnap converted these snaps cleanly, and all of the programs remained functional. The script left the remaining snaps and the infrastructure untouched...
An equivalent Flatpak must be available, which is very often the case with graphical applications. With a little manual work, the Snap infrastructure can also be removed.
I really do not get it (Score:5, Insightful)
What is wrong with .deb? This looks like some "developers" looking to optimize things that already work reasonably well. Never a good idea and contrary to sound engineering practices.
Re: I really do not get it (Score:2)
Yeah, I kind of don't understand either.
I get that you might want to be rid of snap, as it seems like an unneeded chunk of overhead on a system that already HAS a robust and mature installation system - the "right way to install" with apt/deb, but what does flatpack get you as an alternative? Why flatpack?
Besides, aren't flatpack and snap both similar to docker images, which seem more widespread? If you MUST make this move, what makes docker not a choice?
Re: I really do not get it (Score:5, Informative)
Re: I really do not get it (Score:2)
Thanks, I appreciate the clarity in your response.
Re: (Score:2)
I haven't used a snap in quite some time, so I may be behind the times, but the last time I did they were very poorly integrated into the system. Like, the Firefox snap on Ubuntu literally didn't even get decorated with the system theme, and the profile directory was in some wacky location.
Re: (Score:3)
I recently stopped using snaps.
I have not had awesome experience with snap packages, so I decided to give Mint ago which is basically the same but no snaps by default. It's not a fast laptop: 1.7GHz i7 Q820, and a decent flash drive on a SATA II bus, so feel the pain maybe more than most. I'd say it feels like a new machine. Firefox, for example is much, much faster to start.
Oh also, snaps for some reason have access to /home (so the really important stuff) but not other parts of the filesystem, so everythi
Re: (Score:3)
Docker is more meant to fool disastrously coded server stacks they can do anything they want so you can throw them in the docker, get it to somewhat work and then never look at it again. It's not a convenient application sandbox.
Re: (Score:2)
I don't get how library management is part of "disastrously coded server stacks" but there's always one loud idiot in a group of well reasoned individuals
Re: (Score:2)
No infrastructure for sandboxing, requires keeping the package up to date with the distro package versions.
Re: (Score:2)
Closed source developers often can't be bothered, open source programs too can become unmaintained.
Re: (Score:1)
it's work. you a communist?
Re: I really do not get it (Score:1)
Re:I really do not get it (Score:5, Informative)
It is simple, .deb files don't work on RPM-based distros -- or other distros that use different packaging systems like Pacman. Both Snap [ubuntu.com] and Flatpak [flatpak.org] address the age-old problem of packaging "Linux" applications for different distributions.
Both Snap (Ubuntu) and Flatpak (Red Hat) provide a distribution-independent package that also includes needed dependencies. They also allow for ease of multi-version installation on the same system. That is Software-1.2 and Software-2.1 can both be installed and run, without dependency hell, on the same system. Finally, this makes upgrading simple because it doesn't depend on upgrading all the shared-dependencies. (Windows has .dll hell, Linux has something similar in "oh, the app I want was upgraded but my distro hasn't upgraded this one new library dependency so everything just broke".)
Flatpak is fully open source, Snap's back-end is proprietary Canonical. There can be/are multiple Flatpak repositories, but for Snap there can be only one -- Canonical's Snap store.
This site [itsfoss.com] has a good comparison of the two.
Finally, there is also AppImage [appimage.org], which people who use Balena's Etcher should be familiar with. I believe it predates both Snap and Flatpak, but is less popular and not backed by one of the major Linux distros.
Re: (Score:3)
That's why statically linked programs exist.
Re: (Score:1)
That's why statically linked programs exist.
You still have to actually deliver them to the distribution, make them work with the specific paths that that distribution uses for keeping things in special places, update them if any rare, non backwards compatible changes happen to system calls configure all sorts of other weirdness such as interacting with SELinux or other security systems. By the time you have really really solved all of these problems you will find that you have something very similar to Docker and people are cursing you for not puttin
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
No you cannot re-link a staticly linked binary.
Remember what got us here is Linux commercial applications - flatpaks allow them to run on multiple Linux distributions instead of being limited to just one with a particular collection of libraries.
At least with a flatpak you can always replace the internal library with a fixed version. With a staticly
Re: (Score:3)
TL;DR: Dependency management is hard.
Re: (Score:3)
WTF neither do snaps, or flatpaks.
There IS NO MAGIC SOLUTION OT THE PROBLEM.
Snaps get updates, sure but they are completely independent from the system libraries by design. If your system libraries get an update, the snaps will not because they don't use the system libraries.
Re: (Score:2)
That's why statically linked programs exist.
fucking hell this.
Why have people been making such a fucking meal of packaging things for Linux for so long. You can statically link, or ship all your .so dependencies. It's just not hard.
I remember Matlab back in the 19-fucking-90s used to do this. It was a big-ass .tar.gz file with a bunch of .so s in. You could untar it on any Linux machine and it would work. You could also untar the next version and have both side by side, but through the dark magic of being i
What is available as .deb or .rpm which is not (Score:3)
available in the other format? I don't know if it still exists, but this a was a problem from 20+ years ago and there was a script called Alien that would convert one to the other. I thought we were WAY past that now - but I admit I haven't touched anything RedHat since CentOS 6.8 (RIP).
Re: (Score:2)
The script in question is probably just issuing package management commands to replace one app in one repo (Snap) with the same app in another repo (Flatpak). Pe
Re: (Score:2)
It's worse than just compatibility. It's fine on a single purpose server to install a deb / rpm and call it a day. But on a desktop where you may have hundreds of different applications depended on different and sometimes incompatible versions of libraries you very quickly get stuck in the Linux version of DLL Hell where the existence of one program holds back a library upgrade preventing you from updating another package.
Fucking around with dependencies that move faster than the distribution maintainer is
Re: (Score:2)
Someone link the XKCD about standards.
Re: (Score:2)
Re: (Score:1)
Re:I really do not get it (Score:5, Informative)
Nothing's wrong with deb. Nobody wanted snaps. They are the slowest, most horrendous thing. Let's remove them from Ubuntu altogether.
Install Mint. It has snap disabled by default. Linux Mint dumps Ubuntu Snap [zdnet.com]
Re: (Score:1)
Better yet, use Mint Debian edition. [linuxmint.com] Hopefully, this edition exists as a transition to only supporting Debian.
Re: (Score:3)
Better yet, use Mint Debian edition. [linuxmint.com] Hopefully, this edition exists as a transition to only supporting Debian.
Better yet, just use Debian. If for whatever reason you feel you need to use cutting edge software, use testing or unstable.
Re: (Score:2)
Better yet, use Mint Debian edition. [linuxmint.com] Hopefully, this edition exists as a transition to only supporting Debian.
Better yet, just use Debian. If for whatever reason you feel you need to use cutting edge software, use testing or unstable.
Or just install from source. It really is not that hard.
Re: (Score:2)
Installing from source oft goes awry, and I no longer find it charming when I have to do it.
I still do it obviously, there's lots of software that you can't really get the most out of any other way. But I generally try to avoid it — not enough to use snap, though.
Re: I really do not get it (Score:2)
nah, Debian had really rough edges for desktop. It's great for servers.
Re: I really do not get it (Score:2)
It's the first thing I do on new Ubuntu server installs.
Re:I really do not get it (Score:5, Insightful)
What is wrong with .deb?
From the standpoint of the user, nothing. From the standpoint of the responsible developer who keeps software up to date, also nothing. From the standpoint of the developer who does not want to update their software, and wants to keep using ancient libraries that probably have security vulnerabilities, it's obvious. snap, flatpak, appimage et al allow them to not maintain their code.
Re: (Score:2)
Urgh. So these are a way for lazy and incompetent developers to continue to pretend they are doing good work. A good reason to never use them.
That said, you can statically link stuff to outdated libraries if you really need it, bit it should not be easy to make it amply clear that a) it is a bad idea dn b) you need extra security.
Re: (Score:1)
Re: (Score:2)
Indeed. Container isolation is also a lot weaker than many people think, and successfully attacking what is in a container often gives the attacker already what they want. The whole approach makes things "simpler than possible" and that is never good.
Better idea... (Score:2)
Re: (Score:2, Interesting)
Flatpaks and .debs are not equivalent. As has been mentioned elsewhere there's sandboxing and also maintainability where sometimes the Flatpak is the official method of distribution so stays up to date better than the distro package. What's really wanted is a script that can replace with either and gives you some idea of which one is better maintained.
Posting anon 'cos I'm likely to follow up on this idea.
Re: (Score:2)
there's sandboxing
And there's also the ability to move /usr/bin/foo to /usr/bin/foo.real and have the original location be a shell script that creates a sandbox before launching it. There's no inherit magic of sandboxing that is only available via Flatpak.
maintainability where sometimes the Flatpak is the official method of distribution so stays up to date better than the distro package
An AppImage is better in that case. The developer can build it themselves and distribute it on their website / GitHub. Many do already, especially cross-platform apps that need an auto-updater for Windows, and even better it means the developer doesn't have to worry about
Re: (Score:2)
well look at that: it's not even news if you do know.
Re: (Score:2)
Even I know what a Flatpak is and I'm probably the least geeky person here.
you don't understand the incentives here (Score:2, Insightful)
At big tech companies you get rewarded for working on and better yet for spearheading successful projects. Re-inventing the wheel gets you promotions, salary increases. (This by the way is why Google never focused on one chat client and kept breaking what they had, in the process losing the almost total market share they had at one point.) Just checking a box in a makefile to make builds static to solve all the problems doesn't get you that kind of reward, and it exposes the company to complaints that now t
AppImage please! (Score:5, Interesting)
I know there's a central ecosystem for these two competing formats but it just seems AppImage doesn't get the love it should. Sure it uses more space because it does share libraries (as far as I'm aware), but give me that concrete wall. There are at least three apps on my machine that distribute that way and they're awesome! No crap to deal with.
Re: (Score:2)
Sure [AppImage] uses more space because it does share libraries (as far as I'm aware), ...
Although, sharing libraries should require less space.
Re:AppImage please! (Score:5, Insightful)
AppImage containers work on RedHat-, Debian-, Arch-, Gentoo-based distributions without fuss. Snap or flatpak needs to be installed first, before those containers even can be used. So I tend to agree with the sentiment: "AppImage isn't getting the love it deserves".
Re: (Score:2)
I know there's a central ecosystem for these two competing formats but it just seems AppImage doesn't get the love it should. Sure it uses more space because it does share libraries (as far as I'm aware), but give me that concrete wall. There are at least three apps on my machine that distribute that way and they're awesome! No crap to deal with.
Sharing libraries can lead to the Linux version of DLL H3LL if library names are duplicated but implement functions in slightly different ways.
A pox on both your houses (Score:4, Insightful)
These "universal package formats" exist to serve the software-as-a-product point of view. They are anti-user, and anti-FOSS. Canonical has been using snaps to abdicate the responsibility of maintaining a Linux distribution, with disastrous results. Running a web browser on *ubuntu is so painful! Flatpak at least avoids the vendor lock-in, but the technical issues are very similar.
These packages have fewer access rights than the user nominally running them, and that's by design. Running software this way turns your computer into a lesser computing device, more like a modern smartphone. It turns each app into its own separate thing, destroying the integration of multiple programs that makes general-purpose computing useful.
At the same time, the plan is to tempt developers to participate by building their own official packages and distributing them through "app stores". There is even talk of selling apps this way. I don't begrudge awesome developers the income, but I don't like the sound of creating an incentive to make it harder to exercise the Four Freedoms.
Re: A pox on both your houses (Score:2)
I'm down with real software freedom, but please describe for me your pain in running a browser on Ubuntu.
I'm not saying you haven't had a hard time, but I've never experienced this. In fact, this has been the easy part of Linux for me on any debian-lineage Linux, snap or no.
Re: A pox on both your houses (Score:4, Informative)
To be honest, I haven't been running a *ubuntu lately. Also, there are Ubuntu-based options that have stuck with the debs, like Mint and Tuxedo OS. But if you're unaware of the problems, you haven't been paying attention to desktop Linux. I found this laundry list [evertpot.com] of one user's troubles. I've read complaints on blogs and Reddit, and heard a steady stream on various podcasts.
But my wife, who has loved Kubuntu for 15 years, tells me nearly every day how much she hates this crap. She has a quite zippy laptop, but the first startup of Firefox takes a massively long time, and she keeps getting annoying pop-up messages about a countdown to a snap update. A couple of weeks ago she said, "Would you please make Chromium stop doing that snap stuff?" so I uninstalled the snap and installed from a PPA. That's good for the couple of things she uses Chromium for. Firefox is going to be the time-consuming migration, since it's her primary browser.
These changes are clearly not being made for the sake of satisfied desktop Linux users.
Re: A pox on both your houses (Score:2)
So of I'm reading into that right, halting everything about the browser while the snap updates sucks?
I agree, though it's been at a tolerable level for me.
Worse for me has been the snap UI telling me it has updates for me, but refusing to install same when I click install. It's constant. And reminding me on every boot that it's installed some important shit or other. But that's not the browser.
Thanks for the info.
Re: (Score:2)
I switched to mint recently when ubuntu 18.04 went out of support. Honestly it feels like a new laptop, firefox is so much faster now. Backup /home, install mint and copy /home back over, dotfiles and all.
I think I have installed my last ubuntu machine now.
I used LVM to split / and /home into separate partitions to make future upgrades or OS changes a bit more convenient.
Re: (Score:2)
>"These "universal package formats" exist to serve the software-as-a-product point of view. They are anti-user, and anti-FOSS. Canonical has been using snaps to abdicate the responsibility of maintaining a Linux distribution"
^^^ THIS
+100
I am just fine with having an OPEN container system (Snap isn't it) and providing containerized software, as long as the distro *ALSO* has native packages for that software as well and the native ones are installed by default. The moment major FOSS software is not availa
Re: (Score:2)
These "universal package formats" exist to serve the software-as-a-product point of view.
Sorry but that is horseshit. You may be isolated from it being a seasoned Linux user who can solve any problem with quick tap-tap-tap in the console, but Linux has a very real dependency problem when it comes to trying to run the most up to date versions of software (reads: more up to date than your package maintainer has blessed in the official repo). These container formats didn't exist to serve anything other than fix a problem, one that users were complaining about. This should be immediately obvious wh
Re: (Score:2)
Linux has a very real dependency problem when it comes to trying to run the most up to date versions of software (reads: more up to date than your package maintainer has blessed in the official repo).
Why would a user who wants leading-edge software run a Debian-based distro? Snaps are not the answer to that.
Running software doesn't make my computer "lesser".
Running Firefox in a sandbox that can't use most of your peripherals or filesystem is a very inferior experience. And that's the experience Canonical chose to make the default. That's the vision going forward for all of the universal packaging formats, to duplicate the inferior mobile experience on the desktop.
Both Snap and Flatpak are unnecessary (Score:1)
ISVs need only release one set of binaries for their proprietary software, deliberately pinning their dependencies to the version of GLIBC and Linux Standard Base which represents the oldest distros they wish to support, while bundling non-LSB libraries as part of the software. It's up to them if they use a self-extracting
Re: (Score:2)
Personally, I'd rather see the LSB, or something like it, actually be actively supported across all major distros. For now however, we're stuck with Snaps / Flatpaks / etc. because no agreements can be
Native (Score:2)
>"has developed unsnap, a script that replaces snaps with Flatpaks where available"
Wake me up when both are replaced back with actual native packages, those things that don't waste TONS of resources.
Ship It! (Score:2)
Let's say it's "Pre-alpha", as in "It kinda works on my computer".
As a salesperson once told me, "Your computer is too small a market to provide an adequate return."
Linux (Score:2)
Between snap, flatpak, PulseAudio and systemd, modern Linux is a damn mess that can go away and die.
All the reasons I loved Linux are gone, systemd is literally a root-level binary that takes over EVERYTHING and is basically unauditable for an amateur user. I used to understand and customise all my bootscripts, systemd I just give up and delete the machine if it stops working (which it does). And it's already had root-level security flaws. It really DOES NOT NEED to be touching DNS whatsoever by default,