4

Former Canonical Developer is Working on a Script that Replaces Snaps with Flatp...

 1 year ago
source link: https://linux.slashdot.org/story/23/07/01/0046224/former-canonical-developer-is-working-on-a-script-that-replaces-snaps-with-flatpaks
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Former Canonical Developer is Working on a Script that Replaces Snaps with Flatpaks

Become a fan of Slashdot on Facebook

binspamdupenotthebestofftopicslownewsdaystalestupid freshfunnyinsightfulinterestingmaybe offtopicflamebaittrollredundantoverrated insightfulinterestinginformativefunnyunderrated descriptive typodupeerror

Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 30 million monthly users. It takes less than a minute. Get new users downloading your project releases today!

Sign up for the Slashdot newsletter! or check out the new Slashdot job board to browse remote jobs or jobs in your area
×

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.

  • 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.

    • 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?

      • Snap and flatpak are similar to docker in that they use containers to isolate things. The big difference is that they integrate with the desktop part of the system.

        In docker it isn't easy to show a GUI, access the system's sound,...

        Docker is great for servers, snap and flatpak(and others) are competing for the Linux desktop

      • Re:

        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:

      No infrastructure for sandboxing, requires keeping the package up to date with the distro package versions.

        • Re:

          Closed source developers often can't be bothered, open source programs too can become unmaintained.

        • Re:

          it's work. you a communist?

    • Sandboxing and decoupling app dependencies from system packages, so an app compiled against e.g. the freedesktop.org SDK can work on any distro and any version of that distro. This way, app developers donâ(TM)t need to build/package for 20 different variants of (distro, version) pairs.
    • 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:

        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".

        That's why statically linked programs exist.

        • Re:

          But we don't want statically linked binaries in our system, because they don't receive security updates to the libraries they were liked against. And it goes on and on...
          • Re:

            If you can upgrade a flatpack, that is the binary with its dynamically linked libraries, then you could also upgrade a binary statically linked with its library.
      • 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).

      • 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:

          Better yet, use Mint Debian edition. [linuxmint.com] Hopefully, this edition exists as a transition to only supporting Debian.

          • Re:

            Better yet, just use Debian. If for whatever reason you feel you need to use cutting edge software, use testing or unstable.

            • Re:

              Or just install from source. It really is not that hard.

  • How about a script that replaces both with Debian packages?
    • Re:

      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:

      well look at that: it's not even news if you do know.

    • Re:

      Even I know what a Flatpak is and I'm probably the least geeky person here.

    • 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

  • 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:

      Although, sharing libraries should require less space.

    • Re:

      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:

      Sharing libraries can lead to the Linux version of DLL H3LL if library names are duplicated but implement functions in slightly different ways.

  • 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.

    • 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:

        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,

        • 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:

      >"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

  • Of course, we all need Flatpak because Red Hat says so, and we all need Snap because Canonical says so. In reality, we do not.

    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.sh file or supply an archive for the end-user to extract
  • >"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.

  • As a salesperson once told me, "Your computer is too small a market to provide an adequate return."


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK