[AussieWog93]

There's a very strong reaction here from users, but overall if more software became snap-only (or FlatPak-only, or anything-only), it would solve one of Linux's biggest pain points as a software developer.

MSI on Windows is completely fucked, PKG on Mac has a few footguns, but at least they're universal, decades-old standards supported by mature tooling. You release an MSI/PKG, and you're done. Works on every Windows/Mac system, no issues.

On Linux, an OS with 3% market share, there are more competing standards to count: Deb, RPM, snap, FlatPak, AUR, AppImage and probably a dozen other semi-popular ones. Every individual user has their opinion (and they'll voice it!) as to which standard is the best. At best, this leads to God knows how many man-hours of duplicated work packaging and QAing. At worst, it leads to the dev abandoning the thought of Linux altogether.

Linux on Desktop simply can't move forward by continued bike-shedding over frankly irrelevant details. Even if the only rationale for a standard is "Because Mike Shuttleworth said so, and he got a phone call from Mandela in space", that's a massive improvement over the current status quo.

[cies]

> it would solve one of Linux's biggest pain points as a software developer.

Maybe true for proprietary software, but for FLOSS it is a non issue once your software has traction and gets picked up by distributions. I wrote a piece of open source in ~2002 and it is still found in pretty much all distros AND I never spend a minute in pain over packaging difficulties.

IMHO, the basic package managers work REALLY well for FLOSS. The gave me a peak into the AppStore/PlayStore(tm) experience (but then without all the spyware), waaaaay before they even existed.

[dataangel]

Having N distributions repeat almost identical packaging work on different schedules and sometimes falling many versions behind is not a "non issue". You're excusing something Linux is genuinely bad at. I say this as someone using it personally and professionally for 12+ years.

[aragilar]

Sure some distros have many derivatives, but it's not obvious to me that you can stop that (see Android for a different open-source ecosystem, and how fractured that is), nor that is always a bad thing, as it allows experimentation which can flow up to the parents.

I'm not sure though "almost identical packaging work" is accurate, maybe that applies to Debian and Fedora (and their derivatives), but Gentoo and Nix are examples of doing something quite different (not to mention the different embedded distros), and so the "duplicate work" is anything but that.

[cies]

Also I was replying to:

> it would solve one of Linux's biggest pain points as a software developer.

Not the pain of the distro-people. That may be mitigated with a universal standard of snap or flatpak.

[robert_foss]

Snap is not a standard, and never will be (RedHat will always ship flatpak for example). So Snap is no universal solution.

At the same time snap packages have serious downsides for end users.

[jckahn]

I think this comment demonstrates the parent’s point.

[sph]

Before every distro had their own package management system and repository.

Then 99% went with Flatpak, except one, Ubuntu with their own proprietary solution called snap.

It's not the same thing. We have a decent (yeah not perfect, I'll spare commenters the effort of posting that same old tired flatpak rebuttal) cross distro packaging solution, but Canonical always wants to play different and not collaborate with the other standards. So here we are.

[Spivak]

You can also just install Flatpak on Ubuntu and never think about Snap ever again if you so choose. Someone putting forth effort to maintain their own bespoke repository isn't really that big a deal.

In 10 years the "Ubuntu Store" will be a pretty frontend on top of Flatpak just like Gnome Software, and just like every NIH Canonical product made before it.

[Karunamon]

Unless you want Firefox or some other apps where the deb package is a thin frontend around a snap install command.

[Spivak]

Fair criticism, but wouldn't you be installing the Flatpak versions of those apps anyway? I get the loss of the distro-provided builds but in abstract I can't find some fundamental reason distros can't drop packages from their repos.

[forgotpwd16]

What 99%? Fedora, Mint, eOS, Pop use Flatpak. Ubuntu (and derivatives other than aforementioned ones) and Solus use Snap. In every other distro, including but not limited to popular ones like Debian, SUSE, Slackware, Arch, Void, Gentoo, both are optional. Neither Flatpak nor Snap is standard.

[robert_foss]

Well, no. The parent point was that Snap is a way out of this software packaging quagmire, but I am saying that Snap will never unify the linux distros.

[BearOso]

A snap has Ubuntu-specific package dependencies. That's totally not a cross-platform concept. The only thing snap solves is sandboxing, but there are better ways to do that.

[everybodyknows]

> Ubuntu-specific package dependencies

Could you briefly summarize those for us?

[nulbyte]

> On Linux, an OS with 3% market share, there are more competing standards to count: Deb, RPM, snap, FlatPak, AUR, AppImage and probably a dozen other semi-popular ones.

AUR is explicitly a community-driven effort. The others are packing standards, some of which (like DEB and RPM) are also used in community-driven efforts. Debian and RedHat derivatives have repositories that use DEB and RPM, respectively. There's not a lot of bike-shedding, here. Availability of functional software is a pretty big feature of Linux distributions.

And there is a big difference between those community efforts and the likes of Snap, AppImage, and FlatPack, which are developer-centric. User preferences on software distribution aren't always or even usually based on irrelvent arguments, but fundamental ones. The community efforts centralize dealing with compatibility and, to an extent, security with community standards, while the developer-centric model largely leaves this work to software developers alone. This is a meaningful distinction.

[jeroenhd]

DEB is working fine for most users, for the corporate/Fedora users RPM also is good enough. Flatpak works great for GUI applications as well, it integrates nicely with most "app store" interfaces on Linux.

DEB vs RPM is an ancient debate, each comes with its pros and cons. Flatpak and Snap try to solve a different problem (sandboxing + dependency hell vs stable system-wide dependencies).

MacOS has PKG, but most software I've seen actually comes through DMG images or ZIP files. Windows has MSI, which, if you use it correctly, actually elegantly solves most problems; the features that were added to allow developers to bypass the declarative installation process are what usually breaks MSI installers.

But then modern Windows now features has packages installed through .appx, .appxbundle, .msix, .msixbundle, and plain old .exe. Windows Mobile (based on Windows CE) had .cab; Windows Phone 8/8.1 (based on Windows 8) had .xap; Windows 10 Mobile had .appx. Now Windows 11 also supports .apk files from Android!

In the end, the package method doesn't matter. Users don't care where the package comes from, they just want to install the application and run it. Deb, Flatpak, RPM and Snap all work fine from tools like Discover or GNOME Software; it really doesn't matter to normal users what kind of packaging system they use.

[bayindirh]

Everybody I know strongly dislikes snap because of the machinery it brings and how untidy it is. Also it's forced upon the users.

AppImage and Flatpak are fine, and AppImage is the first choice amongst this "everything included" bundle formats.

However, Ubuntu is forcing snaps as a power move. Both the software, and the treatment from Canonical is off-putting a lot of enthusiasts right now.

[everybodyknows]

The devil on my shoulder wonders if Canonical's pushing of Snap, rather than adoption of FlatPak, is another instance of the Not-Invented-Here organizational dysfunction that led it to slog on with its own Bazaar SCM rather than switch to Git (or Mercurial).

[account42]

Bazaar, Upstart, Mir, Snap. Canonical really likes to do their own thing and usually it fails in the end. Competing implementations are great but competing standards only make more work for everyone else.

[sreevisakh]

The worst part is that they sabotage their good software by insisting on these bad solutions. LXD and MicroK8s for example, are distributed only as snaps - not even tarballs. LXD is actually a great software. But it's available as native package only on a few less popular distributions, and that has hurt its adoption. I wanted to try MicroK8s, but completely abandoned it due to the snap requirement.

[demetrius]

Snap server is closed-source (unless anything has changed?), so I believe this is more likely to be a nefarious intent to create a dependency on their service (which Canonical can monetize later) than a mere dysfunction

[kaba0]

The thing is, none of the mainstream package formats solve the underlying problem, they just push it to a different layer.

I know what I’m saying can be regarded as “+1 different standards”, but Nix is the only truly novel approach to package management that can reliably install a huge-ass behemoth package group like Gnome, install Plasma next to it and remove both without a single garbage file laying around afterwards.

I think we really should embrace this uniquely good solution.

[Spivak]

Nix fails the "don't make me think" test unfortunately. Flatpak is winning because you can head-empty dump a working application into it and it will work. Nix requires discipline on the part of the packager which will never scale.

[musingsnort]

Indeed - and they provide separation between a stable OS (which debs are fine for) and frequent desktop app updates. I've been using Snap, Flatpak and Appimage for desktop/productivity apps (Krita, DigiKam, Spotify, Signal, calibre etc) where possible. Its been amazing getting updates in a timely fashion, sometimes straight from the developer, instead of having to wait years for the DEBs to be updated.

[dTal]

This is really overcomplicating it. Most mainstream end user Linux programs - including Firefox [0] - are distributed through archives you just unpack and run the binary inside, same as most Windows freeware. AppImages are just self-extracting versions of this. Most of the other formats you mention are for distro package managers - these aren't distribution formats and it's not the responsibility of the program authors to package for every distro, nor is it required for a package to be in repositories for people to run it.

Just ship an ELF binary in an archive. Include any files and libraries you need. Compile against the oldest glibc found in any system you care about supporting. That's all you need.

[0] https://download-installer.cdn.mozilla.net/pub/firefox/relea...

[rkv]

Comparing Windows and macOS to Linux is moot and we should stop doing it. Linux has always been and will continue to be an ecosystem driven by various communities, and expecting everyone to agree on the same standards is silly.

The sooner we all begin treating Ubuntu and Red Hat Enterprise Linux as separate Operating Systems the sooner we can all move on from the "single standard" and "Linux on Desktop" debates. As an application vendor I always find it amusing when customers ask if we support Linux. My response is no, we don't support Linux but we do support Ubuntu 18+ and RHEL 8. Linux distros are so wildly different these days, not just in software but in ideologies, that this distinction is important, and there's nothing wrong with that.

[sph]

Not in 2022 they're considered different Operating Systems. People have been developing AppImage, Flatpak and snap for a reason. They're being used and it's a thing.

Yeah, the year of the Linux desktop isn't coming, but it's not 2001 either. We've standardised onto a few technologies pretty much everyone adopt except the ones that want to be different: systemd, Flatpak being the most used cross-distro system, pulseaudio (and pipewire offers a 100%-compatible shim for it), dbus, NetworkManager and now finally with GNOME 42/libadwaita we can have even standardised UI design.

And like many other things frontend, things move at a pretty rapid pace. Ubuntu 18 is ancient, might be good for a server, but it's not a good idea to use that as a metric for where the Linux desktop is.

[bubblethink]

I'm willing to bet that desktop linux's market share is not going to move one way or another with any packaging format changes. The best hope currently is steam deck, which may bring a new generation of users to linux, although in a pretty limited capacity.

[ale42]

I would be fine with Firefox packaged as snap. If snap would have the decency of working fine with the typical configuration used in managed systems (NFS home mounts, LDAP auth and similar stuff). But it doesn't. Until that day, snap is as bad as any other deployment technique.

[0xdeadb00f]

Okay but snap sucks. I don't want it. I never asked for it.

This is why my daily driver isn't Ubuntu (or Debain, because I also hate apt - it also sucks).

[0xbadc0de5]

There's an XKCD that captures that: https://xkcd.com/927/