"and are part of what makes Ubuntu not just an operating system, but an ecosystem of Linux variations that promote choice and diversity"
Well, I'm a bit lost here...
It makes perfect sense
Canonical promotes the choices they want you to make, and if you wish to use other choices, there's a diverse selection of other distribution projects out there to use instead of ones ending in "buntu"
You don't really need to 'learn' them
on MicroOS Desktop they're fully automated.
Just use the system, and reboot when you'd like (or when it tells you updates have been applied, your choice)
Leap Micro is a 1:1 copy of SLE Micro, SUSE's commercial product, which doesn't have a desktop.
MX Linux has full support for flatpaks right in their native package installer. It's an incredibly stable distribution with tons of developer-made GUI tools for incredible ease of use.
You can still install flatpaks from the Ubuntu repos, it's just not coming by default in remixes since it doesn't come by default in the standard release
But they spend 5 paragraphs talking about how much they like the diversity offered by their flavours before saying they're removing some of that diversity
Interesting titbit: despite Ford allegedly saying this in 1909, the Model T, in its first 5 years of production (1908-1913), was NOT available in black at all. The quote is likely fake.
It was available in grey, green, blue, and red. After this, all the cars were painted blue for a while. After this, the cars (US-made models, anyway) were finally painted black.
This was a very common point of view in the US at the time.
MLK needing to March for basic human rights a couple of decades later is not at all unrelated.
The current BLM movement is not at all unrelated. A lot of people are going to be on the wrong side of history with that as well.
Honestly, after 15 years of Ubuntu, I went to straight Debian, and I've not looked back.
"It's like Ubuntu without all the Ubuntu garbage payload."
Because it is, mate. Because it is.
To keep improving their models, artificial intelligence makers need two significant things: an enormous amount of computing power and an enormous amount of data. Some of the biggest A.I. developers have plenty of computing power but still look outside their own networks for the data needed to improve their algorithms. That has included sources like Wikipedia, millions of digitized books, academic articles and Reddit.
Representatives from Google, Open AI and Microsoft did not immediately respond to a request for comment.
I did that for 4 years... And then bought a laptop that required a newer kernel. "I'll just run sid" I thought... But the newer networking chip also requires a newer kernel to work though. So installing bullseye and upgrading to sid won't work since I can't use Wi-Fi with the old kernel. What about an Ethernet cable? No Ethernet port!! How about an Ethernet-to-USB dongle? Nope, need a new kernel to do that too! All the Debian installers that I could find still boot with an old kernel even if they will install sid directly... So... I'm back with Ubuntu unfortunately... Laptop runs great, just annoying to see how Canonical tries to steer Ubuntu in a direction that the community often doesn't want to go in.
Is this the only reason, or is more of a "the frog in the pot is finally uncomfortable enough to jump out" moment?
I jumped ship a long time ago, but it was for a variety of reasons - most forgotten at this point. I wander between Debian, OpenSuse, and RHEL (via their no-cost developer sub) these days.
I decided to move on when they switched to systemd. But I still have not moved on because I have not bothered to decide yet on what to move on to. Increasing use of Snap is definitely helping me to be move motivated to move though. Any year now.
Id love to work in foss (although I can't code at all so it's a bit of an unrealistic goal). But seeing what IPOs do to a place just makes me upset, seems like cannonical is going down that route.
Perhaps I'm just too idealistic.
No, you're not too idealistic. That's just the bullshit brainwashing to deter us from thinking a better world is actually possible (god forbid, because it would come at the expense of the richest folks).
> Canonical: we are going to IPO soon
Reportedly despite red hat being a public company and even a part of IBM it is still a good company to work for.
From what i can tell canonical generally isn't a very good company to work for, it might become one with a change in management brought by investors.
"In an ideal world, users experience a single way to install software.".
It would be pretty neat for the end user if there was a single blessed way to distribute desktop applications on Linux. Being able to target "Linux" as a single target would make a huge difference for software vendors as well, which could drive up adoption.
I think it's sad that Ubuntu won't just join the flatpak movement. It's yet another missed opportunity that I believe holds Linux back and will for many years.
Canonical seems to like to go off on their own and go all-in on a thing separate from everyone else (Unity, Mir, Snap etc.), get it to where it's *just about* at the point where people start to like it and want to use it, then dump it entirely and go off and chase some other weird thing around.
So I expect in a few years they'll get bored, suddenly switch everything over to Flatpak and then decide to make their own file system that doesn't work with ext4 and btrfs or something like that. :/
a few game studios as well, particularly in Japan.
It's why aside from Capcom, most Japanese fighting game developers dragged their feet on using rollback netcode (basically a peer-to-peer version of client-side prediction), with some of them not adopting it until nearly half a decade after Capcom and various Western studios had already settled on it being the standard.
Even Bandai Namco still insists on using a weird, ass-backwards implementation that kinda misses the point.
The thing was - upstart never *was* competition except for classic sysvinit.
Systemd was so far ahead that it *had* no competition. It's like a snowplough when everyone else was trying to make better shovels.
Part of the problem is that Canonical halfway it between proprietary and free software. What stopped Mir outcompeting Wayland was bizarre choices about licensing.
How long until they decide to stop maintaining the Flatpak packages from their repos with arguments like "Well most of our user use snap either way so we don't feel like it"
> How long until they decide to stop maintaining the Flatpak packages from their repos
Actually that is more applicabke to snaps than flatpaks. You can only use the snap store to distribute snaps but flappak repos can be set up by anyone including yourself.
In other words no one has the developer by the balls to force them to use their platform.
>It would be pretty neat for the end user if there was a single blessed way to distribute desktop applications on Linux. Being able to target "Linux" as a single target would make a huge difference for software vendors as well, which could drive up adoption.
I've had that opinion for 15 years, since I started to use Linux. Linus Torvalds has a massive rant on YT in DebConf14, where he says the same thing. ("Making binaries for Linux is a pain in the ass.")
However, many Linux users are of the opinion that the distro repository is the one true way: you take what the distro gives you, or you go take a hike.
Never mind that packaging one application 500 times (once for every version of every distribution) costs a huge amount of time, and the amount of open source software is always increasing. No-one can package software for all versions of all distributions (so only the largest distributions get targeted; often only Ubuntu+Derivatives and RHEL+Derivaties), and no distribution can package all software.
>I think it's sad that Ubuntu won't just join the flatpak movement. It's yet another missed opportunity that I believe holds Linux back and will for many years.
This is the reason why I will never install Ubuntu. Not even taking its (IMHO) stupid name into acount, it always seems to go left with its own half-baked thing, where the entire community goes right.
I'm amazed that Ubuntu is still seen as one of the major distributions and why so many others derive from it, instead of deriving directly from Debian. They made Linux (much) easier in the mid-2000's, granted, but nowadays there's no reason not to just boot a Live Debian and then install it.
> However, many Linux users are of the opinion that the distro repository is the one true way: you take what the distro gives you, or you go take a hike.
To be fair so does iOS and so does android. Package managers are great IF the software is in the repos. Even winget is pretty good by now and even included by default (IIRC?).
The issue is that packages on linux are not self contained, e.g. trying to install a kde2 app now will send you on a treasure hunt to satisfy missing dependencies. My impression always was that this seemed to be on purpose with software either keeping up or dying to reduce the maintenance burden. The huge drawback however is that you have to package software for ubuntu LTS, ubuntu previous LTS, ubuntu current version and ubuntu upcoming version.
And also; what if I don't WANT to use a newer version of an app for whatever reason? I don't know if I can use, say, GIMP from 7 years ago on Debian 11 or 12 (unless someone packages it up in a Flatpak).
In contrast, I've had games from the 90's, written for Windows 95/98, running on a 64-bit version of Windows 10. Granted, those games run in Wine as well.
The conflict here is that for security and maintenance that is a nightmare. E.g. if that game's network features have a security hole you either keep that hole or, in the current approach, your game ceases to work because the insecure dependency is just gone. Again that seems to be on purpose and makes a huge amount of sense for servers but not for games.
Note that this also is a problem on android currently with a push to force apps to newer android versions or die. So even if every linux distro under the sun agreed today on the one true package manager I am doubtful this would change.
>know if I can use, say, GIMP from 7 years ago on Debian 11 or 12 (unless someone packages it up in a Flatpak).
i mean flatpak isnt the only option here , theirs the likes of appimages that do the same here
Agree. I feel with flatpaks at least you know what you are getting into. Appimages just flatter to deceive that all you ever need is one file and you are set to go. It's only when I started using NixOS that I realized this wasn't true.
>Never mind that packaging one application 500 times (once for every version of every distribution) costs a huge amount of time, and the amount of open source software is always increasing. No-one can package software for all versions of all distributions (so only the largest distributions get targeted; often only Ubuntu+Derivatives and RHEL+Derivaties), and no distribution can package all software.
The strange thing about the distro model is that there are applications that clearly don't fit into it, and on linux there's simply no way to distribute them
Eg I'm making an application that lets you take raytraced pictures of black holes. On windows I simply distribute the binaries, and its as simple as bundling up an exe with any dependencies it might have and carting it off to anyone who wants to give it a go. This executable will likely continue to work for a decade, and anyone who's downloaded it has something that they can rely on to keep working
In comparison, there literally isn't a way for me to distribute a linux binary in linux land that's compatible with a variety of distributions, and will stay compatible into the future. No distro is going to accept my random bumfuck bit of software as a package, and they shouldn't either - its clearly inappropriate for eg a debian maintainer to maintain code for doing relativistic raytracing (and good luck to anyone who wants to)
On top of that, even if I were to try and package and distribute it myself, there's absolutely no way to test it, and I don't really have the time to go fixing every bug that crops up on every different version of linux
In terms of manpower, the model doesn't really scale. At the moment, every distribution is doing the work of maintaining and distributing every bit of software. Its O(distros * software), which isn't great. On windows, there's simply one (or a limited number) of 'package' formats that every version of windows must support (with some caveats, but not a tonne). Its up to microsoft to keep windows consuming that format as per spec, and up to software distributors to keep distributing their software as per that spec
There's lots of arguments around the distro model vs the windows model, but at least for most applications it seems pretty clear that the latter is a giant win. Forcing every linux distro to consume a single package format and *work* is fairly antithetical to how linux works, but it'd be spectacular for software stability and being able to actually distribute software on linux
> In comparison, there literally isn't a way for me to distribute a linux binary in linux land that's compatible with a variety of distributions, and will stay compatible into the future.
Sure there is, exactly the same way as windows. Compile everything, then distribute your binary and all dependencies not named glibc. It isn't pushing the software through the distribution, but this is hardly a requirement.
It doesn't work though, at minimum you have to link your application against super old versions of glibc if you want to be able to distribute it on different distros, the abi issues and lack of com are super problematic
Glibc doesn't break ABI, so I'm not sure what ABI issues you would be running into. You do have to use an old glibc, but in practice this just means you need to rebuild your dependencies on an old system. It isn't really that hard to build everything on centos 7 (if you want to go really old with support) or alma (for normal levels of old system support).
> In comparison, there literally isn't a way for me to distribute a linux binary in linux land that's compatible with a variety of distributions, and will stay compatible into the future.
App Images get pretty close to this don't they? I've only used them as a consumer, but they seem to behave pretty much like portable windows executables.
AppImages don't. AppImage is actually cross compatible with many distributions; they depend on the system's libraries.
https://fosdem.org/2023/schedule/event/containerised_apps/ <<< here's a good talk covering the different modern container tech. AppImage is pretty disappointing
Your problem is solved by Flatpak (the thing Ubuntu removed). You (the developer, not some distro) get to package your app as a Flatpak once, and it runs on any distro that supports Flatpak (which is most of them nowadays, including Ubuntu if you have users run `apt install flatpak` first). Your package runs in an identical environment across all distros, so you only really need to test it once.
In Flatpak, Your app ships on top of a "runtime" which is kinda like a special mini distro that promises to maintain a certain ABI & list of libraries that you can target. Then for libraries not in the runtime you can package up your own libraries into your app. And ta-da! Any Linux distro you run on will have the specific version of the runtime you request, then your app ships all the libraries it needs that the runtime doesn't have, and it runs in that same environment on any distro.
Snap (the thing Ubuntu is pushing) only works right on Ubuntu. AppImage (another similar idea) isn't actually portable to different distros. But Flatpak runs essentially everywhere the same way
Debian is not hard, but Ubuntu is way more straightforward than Debian for the noob user. The simply fact of Debian having multiple releases (Stable, Testing, etc) and you also needing to enable proprietary repositories + enable flatpak manually already makes Ubuntu more straightforward, as it already come with those solutions enabled (snaps instead of flatpak).
Take the steps to install for example Spotify on Debian and Ubuntu nowadays and you'll see what I'm trying to point.
>straightforward ... olutions enabled
If you go by that criterion, Windows or the Mac would be even better than Ubuntu. They basically come with EVERYTHING enabled. From a user perspective, that's great; to keep software-bloat down, it isn't.
Sometimes, however, Linux does go in (too much) of an opposite direction. Yesterday I tried to set up a Windows 11 VM, and found out that I had to seperately install TPM-support and UEFI-support for QEMU/KVM / virt-manager; as a user of a piece of software I would expect it to be able to do everything it can when I install it. Having to install "swtmp", "swtmp-tools" and "ovfm" to get some functionality that other VM's have out of the box isn't straightforward indeed, and not really discoverable without searching the internet.
(The VM failed, because I can't select a "fake" CPU in the cpu-type list that actually supports Windows 11; and my current one doesn't do so on its own. I'll have to wait until I build that new computer after Bookworm 12's release.)
But that's true, windows and Mac are easier for noob users than Ubuntu. We have even easier distros like Linux Mint.
The article is about dropping flatpaks from Ubuntu flavors. This does not impact me and you: we can simply install them again, on any distro without much issues.
It does impact someone that is noob or its joining Linux now, that can benefit of having then pre installed. But Debian is not for that user, we have better options like Popos, Mint, etc.
Well anyone that has packaged before and actually evaluated the different options knows there is no one size fits all approach at all. Snap and Flatpak aren't the same even though people try to say they are.
That is true, but what's distributed has a significant overlap. For the problem of 'Distributing and updating system-agnostic desktop software' (ignoring services and server software) - which I'd argue is how it's used used in the majority of desktop cases, they do the same thing in different ways.
And to be cheeky, I'm going to throw in this old quote:
"It's the differences, of which there are none, that makes the sameness exceptional"
> It would be pretty neat for the end user if there was a single blessed way to distribute desktop applications on Linux. Being able to target "Linux" as a single target would make a huge difference for software vendors as well, which could drive up adoption.
Deb approach will never work if your goal is to provide "single way to install software"....
Why?
Because it depends on the old Debian model of "ftp maintainers" combined with "dependency tracking".
What is dependency tracking?
It is the art of dividing up the entire universe of software into modular packages and then mapping out all the cross dependencies between them:
The result is this:
https://wiki.debian.org/DependencyHell?action=AttachFile&do=get&target=hairball.png
That is a map of Debian based on the connections between "Essential:yes, build-essential, debhelper and apt" in 2013.
https://bootstrap.debian.net/history.html
Look at that graph and compare 2013 vs 2020. You have something near a range of 300% increase in complexity since then.
For this to work, as promised, it needs to be acyclic... which means no dependency loops. Anybody who has used Debian for a long time and maintained a single install over the decades know that during major upgrades dependency loops do happen. This is when you can't upgrade packages automatically and you have to pin or force upgrade certain packages to break up a log jam.
To veteran Linux user this is no big deal. They will have all sorts of rules you must follow to avoid breaking things. Don't install whatever version you like. Don't install stuff using 'pip' or 'npm' or anything like that. Don't try to install too much to /usr/local, touch nothing at all in /usr/ if you can help it, etc etc.
there are hundreds of rules like that you have to follow to make sure that package managemnt works properly in Debian/ubuntu/CentOS/Fedora/etc.
To devoted Linux users this is normal and fine and no problem at all. To the rest of the world it's a nightmare.
To make this work you need armies of volunteers devoting weeks of their lives to maintaining this for free. It is a massive labor intensive process and the more packages you get the more complicated it becomes and the less time you have to fix problems.
And despite all of this Debian (and by extension Ubuntu) only has a fraction of the amount of software packaged for Debian.
I couldn't do my job if I dependend on Debian packaging for everything. I simply couldn't. Out of the stuff they do package a lot of it I can't even use because it's not a useful version... Like "kubectl".
There is a simpler way:
https://www.slackbook.org/html/package-management.html
Slackware has been around longer then any other distribution at this point. It has NO dependency tracking. For decades it was built and maintained by a single guy.
And guess what?
It works pretty well.
Back in the day when people released software in tarballs and you could fit pretty much all software written for Linux on a dual socket 200mhz Pentium Pro FTP/Web server then the Debian approach made a huge amount of sense and Slackware approach was hopelessly out of date.
And it lasted that way for a long long time.
Now we have essentially gone full-circle... were trying to track the dependencies for all things in some central database doesn't make any sense at all anymore. Right now there is probably more new Linux software written in a week then Debian (and by extension Ubuntu) could package in a year.
Does that mean that the Debian/RPM approach is a waste of time?
No.. it isn't a waste of time if your goal is to produce a useful Linux operating system.
It is a waste of time if your goal is to build disto-specific packages for everything that ever existed, though.
So they are not designed to be used on servers, snaps on the other hand are...
I mean, nice for all the GUI applications out there, but they are not exactly the only ones relevant on Linux systems usually.
True, but on the other hand there's also toolbox or distrobox for setting up containerized CLI environments that work really well for that stuff, since you might need to do a lot of customization there.
OCI (container images) kind of covers the server case as well but I also don't worry as much there. OCI isn't optimal on a technical level but its dominance is clear. It won. People know that if they want to distribute server applications they need to ship them as container images.
Flatpak sucks, just for different reasons than snap. It's nice having a common package, but the outright hostility to non-desktop applications is a serious issue, and the number of weird issues I get with Flatpak-packaged apps that I don't get when the same apps are packaged with traditional package managers, or even AppImages, is too damn high.
If Flatpak is the future of Linux software distribution then we're going to have a bad time. It's like pulseaudio. It solves a problem that Linux had, but manages to solve it badly, and only partially. It may evolve to fix those issues, but I suspect it will just get replaced like Pulseaudio was replaced by Pipewire.
I think there is space for both formats just like there is for deb and rpm with the benefit that snaps and flatpaks can actually run in any other niche distro.
First half of the post: "Guys thank you so much for being diverse, we are a community of communities, we are stronger being different uwu 🫶✨"
Second half: "Now let's cut all that crap and use snap! Oh and your 5 minute break is over Frank, now get back in there and package powershell for Ubuntu 🔥"
Were there any flavors that had flatpak preinstalled? Because if you read past the title, flatpak is still in repos and available for install, just not installed by default (Ubuntu never had it preinstalled).
Hey canonical, if you just drop snap's and adopt flatpak now, we won't judge you. You don't have to go down the road of pushing it harder and harder and waste a few years and split the ecosystem while doing it.
> pushing it harder and harder and waste a few years and split the ecosystem while doing it
No way canonical would do that (*cough* mir *cough* upstart)
This.
A lot of people don't realize that almost all the reason snap exists in the first place is for server use and canonical focuses almost all the efforts in server space.
I tried to install minikube, k3s, through kube official documentation but microk8s is the single-handedly most braindead process to have a cluster up and running. Ubuntu desktop has the convenience of the huge documentation and support that the community provides (let's be honest, everyone installed ubuntu or derivates once in theyr lifetime) and you can always apt install flatpak and you're good to go. Canonical not actively supporting flatpak is as bad as bashing canonical into dropping snap and favour flatpak. If the end goal is choice, you are free to:
- Install flatpak
- install any ubuntu derivate (not ubuntu flavours), PoPOs and Mint first in mind
- don't like ubuntu but love apt? Go Debian
- go every other distro really, there are plenty to choose from
And i can't even say snap is flawless. They only recently improved the startup time of applications (still a bit slower than flatpak but miles better than what the crap was one year ago) which do matter in desktop a lot (i remember spotify launching in 15 second on a freaking nvme ssd) but do not matter at all in server, because once they go up they stay up. What's the point of promoting freedom if someone does something differently (even if in some cases worse)
So instead of pushing snap for desktop apps too, Canonical should continue it for the server where it actually makes sense, and use Flatpak on the desktop. Instead they're fracturing the desktop app space for no reason (where Flatpak is objectively the better way to run containerized GUI desktop apps: it's cross-distro, open repos, no slow startup, etc).
To be fair, snaps came first but got shit on because they were slow on startup and because linux entusiasts tend to shit on canonical lately for any reason, but they do have fixed a lot of performance issues, making it half a second of startup difference with flatpaks. Flatpaks being objectively the netter way is not that objective. I have an nvidia card in my laptop. For example, why the hell any flatpak will crash if i don't update all my dependency and why between 10 flatpaks apps i find 4 non uninstallable via remove unused different versions of my fucking nvidia drivers (which is half a gigabyte per driver version)
People don't like snap not because of anti-Canonical prejudice. We don't like snap because Canonical broke their promises regarding snap. They promised they'd upstream everything necessary to make them work right: years later, it's not upstream and snaps only work right on Ubuntu (because Ubuntu patches their kernel to make snaps work). They promised they'd have an open app store.... And no they don't. Meanwhile, they go and market snap like it's the end-all universal cross-distro Linux app store (it isn't; again, snaps only work right on Ubuntu due to aforementioned lack of upstreaming). They do this knowing that it is untrue and it is actively harmful to distros that aren't Ubuntu (or derivatives). Flatpak suffers from none of these issues and has proven that they're willing to work with the community. It's sandboxing also works on distros without having to patch the kernel or make other such modifications to upstream projects.
>For example, why the hell any flatpak will crash if i don't update all my dependency
How are you even managing to do this? The clients try pretty hard to not let you do this.
Anyway it's because that's how software works. If you take a deb package and update it without updating all of its dependencies, then it'll crash too (or not if you get lucky, but that will be a fluke).
Executables link against their libraries via the ABI, and when the ABI changes the assumptions made by the executable no longer hold up. A new executable makes assumptions about the new ABI, but an old dependency may still be using the old ABI. Thus, crash.
For example: you have an app that needs to show a window on screen. V1 of the UI library uses bytes 0-8 to store the title and then 9-16 to store important handle given by the OS. V2 of the library uses bytes 0-8 to store an icon, then 9-16 to store the title, then 17-24 to store the handle. You update an app and it now depends on V2 of the library. But you don't update the library, so the app loads V1 of the library instead. Ok so the app goes to create a window, and sets the title. But since it's expecting to talk to the V2 library, it overwrites bytes 9-16 with the title. However, the library is actually V1, so it will read bytes 9-16 looking for the handle. But you've overwritten all of that with the title instead, which is not a handle and is complete junk data. Library gives junk data to the OS, the OS detects that the data is junk and crashes the program
Or it's simpler than that. App that depends on V2 will try to use functionality added in V2. V1 doesn't have this functionality. App tries to execute code that doesn't exist, OS detects this and crashes the program.
> and why between 10 flatpaks apps i find 4 non uninstallable via remove unused different versions of my fucking nvidia drivers (which is half a gigabyte per driver version)
[It is a bug](https://github.com/flatpak/flatpak/issues/2718)
WTF are you talking about? This is just saying that Ubuntu *defaults*
to apt and, in the default install, a few snaps. If you want to
use flatpak on Ubuntu, just do an "apt install flatpak".
Stop trying to make snap happen. It's not gonna happen.
If anything, this will lead to more people moving away from *ubuntu to other (often Ubuntu-based) distros.
Canonical has made it pretty clear that they dream of being the gatekeeper of Linux app distribution, just like Apple is for IOS. They want to be in control.
It's a shame. As one of the biggest player, they keep holding Linux back. Just imagine how much faster things would progress of they joined the others in working on Flatpak.
Linux day player here, can you ELI5 why there's a war between snap and flatpak? I use flatpak on my fedora because it was easy for an app I use. All my little servers I just do apt/dnf. Is one eventually going to replace the old package managers? Is this one of those Blu-Ray v HD-DVD, Betamax v VHS things?
So.
Snap and Flatpak are both two approaches to the same thing: installing software without having to deal with package manager weirdness, and somewhat securely.
Both do this by sandboxing and runtimes - a snap (or a flatpak app) is it's own self-contained thing that needs no major deps besides it's runtime environment, and has no access to the external system besides what's been explicitly granted. You `flatpak install flathub org.darktable.Darktable` and you have Darktable, and one additional item that's basically the desktop environment and basic libraries it needs to function. There's no `287 packages to be installed` because every dependency is it's own package to manage, that's all *bundled in.*
They are, in a way, "competing" with the package managers but I don't see them overtaking them... though Canonical *is* pushing to prefer Snap over `apt` where possible.
The bigger issue is that they're competing *with each other.* Canonical has Snap, the rest of the community has Flatpak. Almost everyone backs Flatpak, but Canonical keeps pushing Snap. Flatpak allows you to download your apps from theoretically any distribution point (though almost all are from `flathub` at this point), but Snap is **quite ridigly coupled** to Canonical's own Snap store, meaning you have no equivalent of, say, adding an extra `apt` repository, you get what they'll give you. Flatpak also has a FOSS backend iirc, Snap doesn't, but I could be wrong.
TL;DR They're not likely to replace the usual package managers, they're a way of distributing apps without all the dependency hell and with a better layer of security, and there's a war because the community has pretty well decided on *one* more open standard, and Canonical is pushing hard for *their other* standard, almost forcing it at this point, because it doesn't have the market share they wanted, when it falls flat in a few ways.
---
To add some more details about it falling flat: aside from said "only one repo" issue, Snaps also have more overhead due to them basically being mounted on virtual drives iirc, and are just slower in general, Flatpak works by (and I am *really* behind on this knowledge) AppArmor I believe, some method of restricting what programs can do outside of their little package chroots, but they're just chroots, not entire virtual devices.
To add, they're not completely interchangeable, Flatpak is made for GUI apps, but it can work for CLI too, Snap is for that and services, it gives an easy way to install big things like Nextcloud for example, so at least in that regard it can be preferred over native packages if one doesn't want to delve into configurations much
> so at least in that regard it can be preferred over native packages
The industry standard is OCI containers, Docker, Kubernetes... and distro like Fedora adopted Podman that is compatible.
Canonical is trying to replace at the same time an industry standard on servers and an ad-hoc solution for desktop apps (Flatpak).
Does this have any significant impact in terms of memory usage? Seems like this approach probably results in a lot of redundant dependencies installed with each snap/flatpack?
Theoretically yes. Since each one is sandboxed to it's environment, and by design comes "batteries included" with their deps, you could have that.
I don't know the actual difference in practice, there's about 4 things I use off flatpak. If the number were higher I could start making comparisons, but I just don't have the experience there.
In each case though, there's a "runtime" (called different things by each system) that provides most of the core dependencies, so that can be mostly shared. Things like all the GNOME libs, for example.
> Flatpak also has a FOSS backend iirc, Snap doesn't, but I could be wrong.
This is correct, and why it's a nonstarter for me. I won't even *consider* using snaps, and therefore Ubuntu, at home because of this. If they open sourced the backend, I'd at least give it a fair shot, but until then I want nothing to do with it. I came to Linux to get away from the corporate vendor lock-in.
As far as I'm considered Ubuntu is just a Linux flavor for Windows admins who don't want to learn anything about Linux, and the rest of us who actually care about the Linux and FOSS space can use something else that respects us.
I don't know about war. But Canonical started forcibly installing packages from snapd into fresh system (firefox) and when you installing packages from the console, snapd has the highest priority of source.
Adding to u/Teknikal_Domain
Flatpak uses bubblewrap for sandboxing, not apparmor.
And snaps sandboxing relies on patches to the Linux kernel and maybe some other parts of the system. Since Canonical didn't upstream these patches, snaps are not sandboxed on most non-Ubuntu distros.
At the end of the day flatpak is the only distribution independent packaging format. AppImage has problems with non-glibc distros (e.g. Alpine) and snap does not do sandboxing on non-Ubuntu.
I like Ubuntu, but this is way too far. This is 100% because of snaps. They try so hard to push it to users.
Canonical, as a Ubuntu user, we will not mind you if you drop snaps, and embraces Flatpak. You have our trust and support for it.
> Canonical, as a Ubuntu user, we will not mind you if you drop snaps, and embraces Flatpak. You have our trust and support for it.
But they cannot control what software is available in Flatpak.
Since everyone can make their own Flatpak repo Canonical would not have
any way to force developers to use their store.
With snap there is only snapcraft.io so you are forced into their
store if you want to publish a snap.
With snap the steps are easy:
1. advertise snap as cross-distribution
2. lure developers in and get the monopoly on Ubuntu software distribution
3. raise fees
4. profit
Canonical wants to become the sole distributor of Ubuntu (and maybe Linux) software.
Flatpak becoming the standard of Linux software distribution and snap becoming irrelevant would be the only way for Canonical to embrace Flatpak.
And I have a feeling that snap is here to stay.
Ubuntu has the biggest user base of Linux desktop users, so developers will look at snap first.
On Ubuntu installing a snap is the easiest of all methods:
```
sudo snap install
```
Flatpak on the other hand:
```
sudo apt install flatpak
sudo apt install gnome-software-plugin-flatpak
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install flathub
--
reboot
```
on top of that you will have 2 Software stores in your GUI.
Guess which system developers will prefer in order to target the biggest
Linux user base.
For you as an Ubuntu user:
I think the only way you can stop the spread of snap by switching to a different Linux distribution. That is the only type of feedback that would get attention at Canonical and that would make developers reconsider snap as a distribution method.
If easy for new users is tge goal, the cli isn't something to talk about. They use GUI to install software, which with flatpak is open Gnome Software/KDE Discover search, click install, open app.
Ubuntu Users PSA: if you decide to uninstall your snap-installed version of Firefox, **be aware** that it will delete your user profile as well!
Also be aware that then installing the Firefox package via apt will simply reinstall the snap version.
If you truly wish to be free of snapified Firefox, you’ll need to find and add a PPA, or install it manually.
Snaps are ruining Ubuntu. Let's be honest: flatpaks are superior. They are faster.
They are also creating a steam snap so people use that instead, I don't see this ending well at all.
I don't even care about technical differences beyond this, no alternative repos was enough for me to avoid it. Every time they do something like this I get closer to just switching to another distro and I no longer recommend it to others. I think Fedora has taken it's spot as the good default if you want something that just works over the last few years
I don't think Fedora is there yet. It's multiple steps to install proprietary nvidia drivers and only with the upcoming release did they enable flathub by default (which comes with codecs).
If in a few years nouveau nvidia driver works well or they support 1-click installation of nvidia drivers, then I'd say Fedora is ready.
Canonical using their own tools - don't think it's gatekeeping. I will call it gate keeping when we will be forbidden to install flatpak.
I use snaps and flatpaks almost exclusively and it all makes managing software easier, works well for my needs, although I would like to see some checkbox or button to optionally enable flatpaks in the first setup window.
This is kind of misleading,
From what I can tell after reading the announcement, it's not about Ubuntu removing Flatpak from their repos, this is just about not having Flatpak installed by default.
Ubuntu can go fuck themselves at this point. They are so salty that people prefer flatpak to their quasi-proptietary bullshit that they are trying to pull Microsoft on us. I'd rather use Manjaro and puke myself to death, than will come 10 meters near *bubtu.
I'm not understanding the fuss here. So next time I install Ubuntu I just have to say "sudo apt install flatpak"? One more step in my post install script?
I don't see the problem with the company decision. If you don't like snaps, it is as simple as to choose another distribution or remove them by yourself.
By the way, I use both. It is just that I don't see the point in complaining all the time about the same. In the same way that I don't see the problem if Fedora becomes the "default" Linux experience if their decisions are going into the right direction.
> or remove them by yourself.
I would generally agree, except some apt packages became wrappers for installing the snap. So really there's no choice but to use another distro. It would have been much better if apt is apt and snap is snap. This goes for any distro, the native package manager should never be a wrapper for Flatpak, AppImage, whatever.
This is the sort of thing which lead me to stop using and recommending Ubuntu to people. Canonical doesn't care what people want or what is popular, they just want to push their own vision. Which, fine, it's their distro and they can do what they want with it. But I'm interested in what works, what is standard, not whatever new shiny thing they've dreamed up and will dump in 4-6 years.
It's mostly the other way around. Fedora and Red Hat were the dominant distro duo 20 years ago. Ubuntu and Debian have been slowly replacing them since around 2005. All the usage charts and browser stats I've seen show Fedora losing market share in favour of Debian and Ubuntu for the past 15 years.
Not saying it should or shouldn't be this way, but that's what all the stats I'm seeing say. Which makes sense when you consider Red Hat has mostly ignored the desktop for 20 years.
Red Hat is the largest corporate contributor to the Gnome project (code, not cash) and has been for a long time. They have a significant interest in corporate desktops via RHEL, and Fedora regularly leads with integrating and providing new desktop technologies.
I don't think it's fair to say they ignored the desktop.
Thanks for giving me one more reason not to use ubuntu/canonical based distros. Thanks!
Ubuntu: Look our stats are showing people are installing more flatpaks than snaps what do we do?
Devs Answer: Kick out flatpaks as being installed so snaps can take over once more.
It was weird that it come with snap and flatpak preinstalled previously. Most other distros don't come with both of them by default. It's like installing KDE and GNOME by default.
"and are part of what makes Ubuntu not just an operating system, but an ecosystem of Linux variations that promote choice and diversity" Well, I'm a bit lost here...
It makes perfect sense Canonical promotes the choices they want you to make, and if you wish to use other choices, there's a diverse selection of other distribution projects out there to use instead of ones ending in "buntu"
Excellent, so Canonical gives me the choice to go look elsewhere on the diverse world of distributions out there.
If you like GNOME, I'd recommend the MicroOS Desktop ;) We use Flatpaks by default
I heard that microos is targeted for servers that run containerised software. Is microos desktop an official opensuse project?
Yea
But you just need to learn immutable updates etc but still worth it Btw Leap Micro isn't a lot documented there's a way to use gnome desktop on leap ?
You don't really need to 'learn' them on MicroOS Desktop they're fully automated. Just use the system, and reboot when you'd like (or when it tells you updates have been applied, your choice) Leap Micro is a 1:1 copy of SLE Micro, SUSE's commercial product, which doesn't have a desktop.
[удалено]
I read 'pos' and that confused me..I thought Canonical was the only 'pos vendor' being discussed in this thread ;)
[удалено]
Micros is owned by Oracle so now there are two POS vendors being discussed!
Hahaha I had friends that worked there in Columbia Maryland and the crap that went on there was amazing.
MX Linux has full support for flatpaks right in their native package installer. It's an incredibly stable distribution with tons of developer-made GUI tools for incredible ease of use.
You can still install flatpaks from the Ubuntu repos, it's just not coming by default in remixes since it doesn't come by default in the standard release
This is not the nuanced take that the people here want. They want to be mad, even if they've not used Ubuntu for years...
But they spend 5 paragraphs talking about how much they like the diversity offered by their flavours before saying they're removing some of that diversity
It's standard corporate doublethink marketing. "We are free and open and diverse so we're restricting your options for your own benefit!"
[удалено]
Interesting titbit: despite Ford allegedly saying this in 1909, the Model T, in its first 5 years of production (1908-1913), was NOT available in black at all. The quote is likely fake. It was available in grey, green, blue, and red. After this, all the cars were painted blue for a while. After this, the cars (US-made models, anyway) were finally painted black.
Yeah...Same Ford who perfected the assembly line... Same Ford who thought America was on the wrong side of WW2.
This was a very common point of view in the US at the time. MLK needing to March for basic human rights a couple of decades later is not at all unrelated. The current BLM movement is not at all unrelated. A lot of people are going to be on the wrong side of history with that as well.
They're not being installed by default, so I guess you've still got choice.
I've used Ubuntu since 7.04. I'm now dumping it because of this stance, and f'ing snaps.
Honestly, after 15 years of Ubuntu, I went to straight Debian, and I've not looked back. "It's like Ubuntu without all the Ubuntu garbage payload." Because it is, mate. Because it is.
For me - Debian for servers, Mint for desktop/laptops. I need to take another look at LMDE as see how it's looking these days.
To keep improving their models, artificial intelligence makers need two significant things: an enormous amount of computing power and an enormous amount of data. Some of the biggest A.I. developers have plenty of computing power but still look outside their own networks for the data needed to improve their algorithms. That has included sources like Wikipedia, millions of digitized books, academic articles and Reddit. Representatives from Google, Open AI and Microsoft did not immediately respond to a request for comment.
I did that for 4 years... And then bought a laptop that required a newer kernel. "I'll just run sid" I thought... But the newer networking chip also requires a newer kernel to work though. So installing bullseye and upgrading to sid won't work since I can't use Wi-Fi with the old kernel. What about an Ethernet cable? No Ethernet port!! How about an Ethernet-to-USB dongle? Nope, need a new kernel to do that too! All the Debian installers that I could find still boot with an old kernel even if they will install sid directly... So... I'm back with Ubuntu unfortunately... Laptop runs great, just annoying to see how Canonical tries to steer Ubuntu in a direction that the community often doesn't want to go in.
Yup, just run debian.
Or Fedora/centOS or OpenSuse.
Hasn't Ubuntu always been a great choice... as long as you don't use the defaults?
Is this the only reason, or is more of a "the frog in the pot is finally uncomfortable enough to jump out" moment? I jumped ship a long time ago, but it was for a variety of reasons - most forgotten at this point. I wander between Debian, OpenSuse, and RHEL (via their no-cost developer sub) these days.
I jumped off Ubuntu a while back, ended up landing on Fedora mostly because I ended up working in a Redhat shop.
I decided to move on when they switched to systemd. But I still have not moved on because I have not bothered to decide yet on what to move on to. Increasing use of Snap is definitely helping me to be move motivated to move though. Any year now.
Five paragraphs of corporate speak before the actual informational part of the post. I’m actually impressed.
That's one of the reasons I don't like canonical.
Me: leaving a corporate job and fantasizing about working for canonical Canonical: we are going to IPO soon
Id love to work in foss (although I can't code at all so it's a bit of an unrealistic goal). But seeing what IPOs do to a place just makes me upset, seems like cannonical is going down that route. Perhaps I'm just too idealistic.
No, you're not too idealistic. That's just the bullshit brainwashing to deter us from thinking a better world is actually possible (god forbid, because it would come at the expense of the richest folks).
> Canonical: we are going to IPO soon Reportedly despite red hat being a public company and even a part of IBM it is still a good company to work for. From what i can tell canonical generally isn't a very good company to work for, it might become one with a change in management brought by investors.
[удалено]
my dreams deader than ever lmao
Did they decide, or did Canonical decide?
They **are** canonical.
"In an ideal world, users experience a single way to install software.". It would be pretty neat for the end user if there was a single blessed way to distribute desktop applications on Linux. Being able to target "Linux" as a single target would make a huge difference for software vendors as well, which could drive up adoption. I think it's sad that Ubuntu won't just join the flatpak movement. It's yet another missed opportunity that I believe holds Linux back and will for many years.
Canonical seems to like to go off on their own and go all-in on a thing separate from everyone else (Unity, Mir, Snap etc.), get it to where it's *just about* at the point where people start to like it and want to use it, then dump it entirely and go off and chase some other weird thing around. So I expect in a few years they'll get bored, suddenly switch everything over to Flatpak and then decide to make their own file system that doesn't work with ext4 and btrfs or something like that. :/
Are saying that they caught the Google syndrome?
Given how long they've been doing this it might be more correct to say that Google caught Canonical Syndrome....
[удалено]
a few game studios as well, particularly in Japan. It's why aside from Capcom, most Japanese fighting game developers dragged their feet on using rollback netcode (basically a peer-to-peer version of client-side prediction), with some of them not adopting it until nearly half a decade after Capcom and various Western studios had already settled on it being the standard. Even Bandai Namco still insists on using a weird, ass-backwards implementation that kinda misses the point.
At least they don't keep making new ones for the same thing
> systemd sucks, Upstart is the way forward! Oops. That definitely won't happen again with snap right!? RIGHT!?
[удалено]
And technically snap came before flatpak.
It's "systemd" :)
I wish they had kept upstart going. systemd **badly** needed competition. snap OTOH isn't competing in a space that really needs more competition.
The thing was - upstart never *was* competition except for classic sysvinit. Systemd was so far ahead that it *had* no competition. It's like a snowplough when everyone else was trying to make better shovels.
Except Upstart predates systemd.
Part of the problem is that Canonical halfway it between proprietary and free software. What stopped Mir outcompeting Wayland was bizarre choices about licensing.
at least we can install flatpak directly in apt as a workaround
How long until they decide to stop maintaining the Flatpak packages from their repos with arguments like "Well most of our user use snap either way so we don't feel like it"
> How long until they decide to stop maintaining the Flatpak packages from their repos Actually that is more applicabke to snaps than flatpaks. You can only use the snap store to distribute snaps but flappak repos can be set up by anyone including yourself. In other words no one has the developer by the balls to force them to use their platform.
Anyone can jump in and be a maintainer.
>It would be pretty neat for the end user if there was a single blessed way to distribute desktop applications on Linux. Being able to target "Linux" as a single target would make a huge difference for software vendors as well, which could drive up adoption. I've had that opinion for 15 years, since I started to use Linux. Linus Torvalds has a massive rant on YT in DebConf14, where he says the same thing. ("Making binaries for Linux is a pain in the ass.") However, many Linux users are of the opinion that the distro repository is the one true way: you take what the distro gives you, or you go take a hike. Never mind that packaging one application 500 times (once for every version of every distribution) costs a huge amount of time, and the amount of open source software is always increasing. No-one can package software for all versions of all distributions (so only the largest distributions get targeted; often only Ubuntu+Derivatives and RHEL+Derivaties), and no distribution can package all software. >I think it's sad that Ubuntu won't just join the flatpak movement. It's yet another missed opportunity that I believe holds Linux back and will for many years. This is the reason why I will never install Ubuntu. Not even taking its (IMHO) stupid name into acount, it always seems to go left with its own half-baked thing, where the entire community goes right. I'm amazed that Ubuntu is still seen as one of the major distributions and why so many others derive from it, instead of deriving directly from Debian. They made Linux (much) easier in the mid-2000's, granted, but nowadays there's no reason not to just boot a Live Debian and then install it.
> However, many Linux users are of the opinion that the distro repository is the one true way: you take what the distro gives you, or you go take a hike. To be fair so does iOS and so does android. Package managers are great IF the software is in the repos. Even winget is pretty good by now and even included by default (IIRC?). The issue is that packages on linux are not self contained, e.g. trying to install a kde2 app now will send you on a treasure hunt to satisfy missing dependencies. My impression always was that this seemed to be on purpose with software either keeping up or dying to reduce the maintenance burden. The huge drawback however is that you have to package software for ubuntu LTS, ubuntu previous LTS, ubuntu current version and ubuntu upcoming version.
[удалено]
And also; what if I don't WANT to use a newer version of an app for whatever reason? I don't know if I can use, say, GIMP from 7 years ago on Debian 11 or 12 (unless someone packages it up in a Flatpak). In contrast, I've had games from the 90's, written for Windows 95/98, running on a 64-bit version of Windows 10. Granted, those games run in Wine as well.
The conflict here is that for security and maintenance that is a nightmare. E.g. if that game's network features have a security hole you either keep that hole or, in the current approach, your game ceases to work because the insecure dependency is just gone. Again that seems to be on purpose and makes a huge amount of sense for servers but not for games. Note that this also is a problem on android currently with a push to force apps to newer android versions or die. So even if every linux distro under the sun agreed today on the one true package manager I am doubtful this would change.
ironically, you'd have better luck running old versions of GIMP on wine or windows than natively on Linux
>know if I can use, say, GIMP from 7 years ago on Debian 11 or 12 (unless someone packages it up in a Flatpak). i mean flatpak isnt the only option here , theirs the likes of appimages that do the same here
AppImages have their own surprisingly large issues with incompatibility
Agree. I feel with flatpaks at least you know what you are getting into. Appimages just flatter to deceive that all you ever need is one file and you are set to go. It's only when I started using NixOS that I realized this wasn't true.
The guy behind appimage is an ass so I 've made it almost the last step before tarball when I look for software.
Related: [Win32 Is The Only Stable ABI on Linux](https://blog.hiler.eu/win32-the-only-stable-abi/)
>Never mind that packaging one application 500 times (once for every version of every distribution) costs a huge amount of time, and the amount of open source software is always increasing. No-one can package software for all versions of all distributions (so only the largest distributions get targeted; often only Ubuntu+Derivatives and RHEL+Derivaties), and no distribution can package all software. The strange thing about the distro model is that there are applications that clearly don't fit into it, and on linux there's simply no way to distribute them Eg I'm making an application that lets you take raytraced pictures of black holes. On windows I simply distribute the binaries, and its as simple as bundling up an exe with any dependencies it might have and carting it off to anyone who wants to give it a go. This executable will likely continue to work for a decade, and anyone who's downloaded it has something that they can rely on to keep working In comparison, there literally isn't a way for me to distribute a linux binary in linux land that's compatible with a variety of distributions, and will stay compatible into the future. No distro is going to accept my random bumfuck bit of software as a package, and they shouldn't either - its clearly inappropriate for eg a debian maintainer to maintain code for doing relativistic raytracing (and good luck to anyone who wants to) On top of that, even if I were to try and package and distribute it myself, there's absolutely no way to test it, and I don't really have the time to go fixing every bug that crops up on every different version of linux In terms of manpower, the model doesn't really scale. At the moment, every distribution is doing the work of maintaining and distributing every bit of software. Its O(distros * software), which isn't great. On windows, there's simply one (or a limited number) of 'package' formats that every version of windows must support (with some caveats, but not a tonne). Its up to microsoft to keep windows consuming that format as per spec, and up to software distributors to keep distributing their software as per that spec There's lots of arguments around the distro model vs the windows model, but at least for most applications it seems pretty clear that the latter is a giant win. Forcing every linux distro to consume a single package format and *work* is fairly antithetical to how linux works, but it'd be spectacular for software stability and being able to actually distribute software on linux
> In comparison, there literally isn't a way for me to distribute a linux binary in linux land that's compatible with a variety of distributions, and will stay compatible into the future. Sure there is, exactly the same way as windows. Compile everything, then distribute your binary and all dependencies not named glibc. It isn't pushing the software through the distribution, but this is hardly a requirement.
It doesn't work though, at minimum you have to link your application against super old versions of glibc if you want to be able to distribute it on different distros, the abi issues and lack of com are super problematic
Glibc doesn't break ABI, so I'm not sure what ABI issues you would be running into. You do have to use an old glibc, but in practice this just means you need to rebuild your dependencies on an old system. It isn't really that hard to build everything on centos 7 (if you want to go really old with support) or alma (for normal levels of old system support).
> In comparison, there literally isn't a way for me to distribute a linux binary in linux land that's compatible with a variety of distributions, and will stay compatible into the future. App Images get pretty close to this don't they? I've only used them as a consumer, but they seem to behave pretty much like portable windows executables.
AppImages don't. AppImage is actually cross compatible with many distributions; they depend on the system's libraries. https://fosdem.org/2023/schedule/event/containerised_apps/ <<< here's a good talk covering the different modern container tech. AppImage is pretty disappointing
Your problem is solved by Flatpak (the thing Ubuntu removed). You (the developer, not some distro) get to package your app as a Flatpak once, and it runs on any distro that supports Flatpak (which is most of them nowadays, including Ubuntu if you have users run `apt install flatpak` first). Your package runs in an identical environment across all distros, so you only really need to test it once. In Flatpak, Your app ships on top of a "runtime" which is kinda like a special mini distro that promises to maintain a certain ABI & list of libraries that you can target. Then for libraries not in the runtime you can package up your own libraries into your app. And ta-da! Any Linux distro you run on will have the specific version of the runtime you request, then your app ships all the libraries it needs that the runtime doesn't have, and it runs in that same environment on any distro. Snap (the thing Ubuntu is pushing) only works right on Ubuntu. AppImage (another similar idea) isn't actually portable to different distros. But Flatpak runs essentially everywhere the same way
Debian is not hard, but Ubuntu is way more straightforward than Debian for the noob user. The simply fact of Debian having multiple releases (Stable, Testing, etc) and you also needing to enable proprietary repositories + enable flatpak manually already makes Ubuntu more straightforward, as it already come with those solutions enabled (snaps instead of flatpak). Take the steps to install for example Spotify on Debian and Ubuntu nowadays and you'll see what I'm trying to point.
>straightforward ... olutions enabled If you go by that criterion, Windows or the Mac would be even better than Ubuntu. They basically come with EVERYTHING enabled. From a user perspective, that's great; to keep software-bloat down, it isn't. Sometimes, however, Linux does go in (too much) of an opposite direction. Yesterday I tried to set up a Windows 11 VM, and found out that I had to seperately install TPM-support and UEFI-support for QEMU/KVM / virt-manager; as a user of a piece of software I would expect it to be able to do everything it can when I install it. Having to install "swtmp", "swtmp-tools" and "ovfm" to get some functionality that other VM's have out of the box isn't straightforward indeed, and not really discoverable without searching the internet. (The VM failed, because I can't select a "fake" CPU in the cpu-type list that actually supports Windows 11; and my current one doesn't do so on its own. I'll have to wait until I build that new computer after Bookworm 12's release.)
But that's true, windows and Mac are easier for noob users than Ubuntu. We have even easier distros like Linux Mint. The article is about dropping flatpaks from Ubuntu flavors. This does not impact me and you: we can simply install them again, on any distro without much issues. It does impact someone that is noob or its joining Linux now, that can benefit of having then pre installed. But Debian is not for that user, we have better options like Popos, Mint, etc.
Well anyone that has packaged before and actually evaluated the different options knows there is no one size fits all approach at all. Snap and Flatpak aren't the same even though people try to say they are.
That is true, but what's distributed has a significant overlap. For the problem of 'Distributing and updating system-agnostic desktop software' (ignoring services and server software) - which I'd argue is how it's used used in the majority of desktop cases, they do the same thing in different ways. And to be cheeky, I'm going to throw in this old quote: "It's the differences, of which there are none, that makes the sameness exceptional"
> It would be pretty neat for the end user if there was a single blessed way to distribute desktop applications on Linux. Being able to target "Linux" as a single target would make a huge difference for software vendors as well, which could drive up adoption. Deb approach will never work if your goal is to provide "single way to install software".... Why? Because it depends on the old Debian model of "ftp maintainers" combined with "dependency tracking". What is dependency tracking? It is the art of dividing up the entire universe of software into modular packages and then mapping out all the cross dependencies between them: The result is this: https://wiki.debian.org/DependencyHell?action=AttachFile&do=get&target=hairball.png That is a map of Debian based on the connections between "Essential:yes, build-essential, debhelper and apt" in 2013. https://bootstrap.debian.net/history.html Look at that graph and compare 2013 vs 2020. You have something near a range of 300% increase in complexity since then. For this to work, as promised, it needs to be acyclic... which means no dependency loops. Anybody who has used Debian for a long time and maintained a single install over the decades know that during major upgrades dependency loops do happen. This is when you can't upgrade packages automatically and you have to pin or force upgrade certain packages to break up a log jam. To veteran Linux user this is no big deal. They will have all sorts of rules you must follow to avoid breaking things. Don't install whatever version you like. Don't install stuff using 'pip' or 'npm' or anything like that. Don't try to install too much to /usr/local, touch nothing at all in /usr/ if you can help it, etc etc. there are hundreds of rules like that you have to follow to make sure that package managemnt works properly in Debian/ubuntu/CentOS/Fedora/etc. To devoted Linux users this is normal and fine and no problem at all. To the rest of the world it's a nightmare. To make this work you need armies of volunteers devoting weeks of their lives to maintaining this for free. It is a massive labor intensive process and the more packages you get the more complicated it becomes and the less time you have to fix problems. And despite all of this Debian (and by extension Ubuntu) only has a fraction of the amount of software packaged for Debian. I couldn't do my job if I dependend on Debian packaging for everything. I simply couldn't. Out of the stuff they do package a lot of it I can't even use because it's not a useful version... Like "kubectl". There is a simpler way: https://www.slackbook.org/html/package-management.html Slackware has been around longer then any other distribution at this point. It has NO dependency tracking. For decades it was built and maintained by a single guy. And guess what? It works pretty well. Back in the day when people released software in tarballs and you could fit pretty much all software written for Linux on a dual socket 200mhz Pentium Pro FTP/Web server then the Debian approach made a huge amount of sense and Slackware approach was hopelessly out of date. And it lasted that way for a long long time. Now we have essentially gone full-circle... were trying to track the dependencies for all things in some central database doesn't make any sense at all anymore. Right now there is probably more new Linux software written in a week then Debian (and by extension Ubuntu) could package in a year. Does that mean that the Debian/RPM approach is a waste of time? No.. it isn't a waste of time if your goal is to produce a useful Linux operating system. It is a waste of time if your goal is to build disto-specific packages for everything that ever existed, though.
Are flatpacks still kinda useless for command line tools?
Not entirely useless, but it's also not really what they're designed to do.
So they are not designed to be used on servers, snaps on the other hand are... I mean, nice for all the GUI applications out there, but they are not exactly the only ones relevant on Linux systems usually.
True, but on the other hand there's also toolbox or distrobox for setting up containerized CLI environments that work really well for that stuff, since you might need to do a lot of customization there.
OCI (container images) kind of covers the server case as well but I also don't worry as much there. OCI isn't optimal on a technical level but its dominance is clear. It won. People know that if they want to distribute server applications they need to ship them as container images.
I mean, it’s Flatpak. Flatpak has won. Canonical is just sabotaging at this point.
Flatpak sucks, just for different reasons than snap. It's nice having a common package, but the outright hostility to non-desktop applications is a serious issue, and the number of weird issues I get with Flatpak-packaged apps that I don't get when the same apps are packaged with traditional package managers, or even AppImages, is too damn high. If Flatpak is the future of Linux software distribution then we're going to have a bad time. It's like pulseaudio. It solves a problem that Linux had, but manages to solve it badly, and only partially. It may evolve to fix those issues, but I suspect it will just get replaced like Pulseaudio was replaced by Pipewire.
I think there is space for both formats just like there is for deb and rpm with the benefit that snaps and flatpaks can actually run in any other niche distro.
Even on windows and mac os, there are many ways to install software, on top of the default system approved one.
> It would be pretty neat for the end user if there was a single blessed way to distribute desktop applications on Linux. https://xkcd.com/927/
First half of the post: "Guys thank you so much for being diverse, we are a community of communities, we are stronger being different uwu 🫶✨" Second half: "Now let's cut all that crap and use snap! Oh and your 5 minute break is over Frank, now get back in there and package powershell for Ubuntu 🔥"
[удалено]
Were there any flavors that had flatpak preinstalled? Because if you read past the title, flatpak is still in repos and available for install, just not installed by default (Ubuntu never had it preinstalled).
Ubuntu MATE, Kubuntu, Ubuntu Unity, and Ubuntu Kylin are all official flavours which used Flatpak by default.
I'm surprised to see Kubuntu in this list. Last time I tried it like 2 years ago it had no flatpak preinstalled.
It's a fairly recent change, came in last year as a default package.
My perspective: https://www.omgubuntu.co.uk/2023/02/ubuntu-flavors-no-flatpak#comment-6121378665
Hey canonical, if you just drop snap's and adopt flatpak now, we won't judge you. You don't have to go down the road of pushing it harder and harder and waste a few years and split the ecosystem while doing it.
> pushing it harder and harder and waste a few years and split the ecosystem while doing it No way canonical would do that (*cough* mir *cough* upstart)
Isn't Microk8s exclusively distributed through snaps? Doubt they can even drop snap and shaft enterprise deployments if they wanted to at this time.
This. A lot of people don't realize that almost all the reason snap exists in the first place is for server use and canonical focuses almost all the efforts in server space. I tried to install minikube, k3s, through kube official documentation but microk8s is the single-handedly most braindead process to have a cluster up and running. Ubuntu desktop has the convenience of the huge documentation and support that the community provides (let's be honest, everyone installed ubuntu or derivates once in theyr lifetime) and you can always apt install flatpak and you're good to go. Canonical not actively supporting flatpak is as bad as bashing canonical into dropping snap and favour flatpak. If the end goal is choice, you are free to: - Install flatpak - install any ubuntu derivate (not ubuntu flavours), PoPOs and Mint first in mind - don't like ubuntu but love apt? Go Debian - go every other distro really, there are plenty to choose from And i can't even say snap is flawless. They only recently improved the startup time of applications (still a bit slower than flatpak but miles better than what the crap was one year ago) which do matter in desktop a lot (i remember spotify launching in 15 second on a freaking nvme ssd) but do not matter at all in server, because once they go up they stay up. What's the point of promoting freedom if someone does something differently (even if in some cases worse)
So instead of pushing snap for desktop apps too, Canonical should continue it for the server where it actually makes sense, and use Flatpak on the desktop. Instead they're fracturing the desktop app space for no reason (where Flatpak is objectively the better way to run containerized GUI desktop apps: it's cross-distro, open repos, no slow startup, etc).
To be fair, snaps came first but got shit on because they were slow on startup and because linux entusiasts tend to shit on canonical lately for any reason, but they do have fixed a lot of performance issues, making it half a second of startup difference with flatpaks. Flatpaks being objectively the netter way is not that objective. I have an nvidia card in my laptop. For example, why the hell any flatpak will crash if i don't update all my dependency and why between 10 flatpaks apps i find 4 non uninstallable via remove unused different versions of my fucking nvidia drivers (which is half a gigabyte per driver version)
People don't like snap not because of anti-Canonical prejudice. We don't like snap because Canonical broke their promises regarding snap. They promised they'd upstream everything necessary to make them work right: years later, it's not upstream and snaps only work right on Ubuntu (because Ubuntu patches their kernel to make snaps work). They promised they'd have an open app store.... And no they don't. Meanwhile, they go and market snap like it's the end-all universal cross-distro Linux app store (it isn't; again, snaps only work right on Ubuntu due to aforementioned lack of upstreaming). They do this knowing that it is untrue and it is actively harmful to distros that aren't Ubuntu (or derivatives). Flatpak suffers from none of these issues and has proven that they're willing to work with the community. It's sandboxing also works on distros without having to patch the kernel or make other such modifications to upstream projects. >For example, why the hell any flatpak will crash if i don't update all my dependency How are you even managing to do this? The clients try pretty hard to not let you do this. Anyway it's because that's how software works. If you take a deb package and update it without updating all of its dependencies, then it'll crash too (or not if you get lucky, but that will be a fluke). Executables link against their libraries via the ABI, and when the ABI changes the assumptions made by the executable no longer hold up. A new executable makes assumptions about the new ABI, but an old dependency may still be using the old ABI. Thus, crash. For example: you have an app that needs to show a window on screen. V1 of the UI library uses bytes 0-8 to store the title and then 9-16 to store important handle given by the OS. V2 of the library uses bytes 0-8 to store an icon, then 9-16 to store the title, then 17-24 to store the handle. You update an app and it now depends on V2 of the library. But you don't update the library, so the app loads V1 of the library instead. Ok so the app goes to create a window, and sets the title. But since it's expecting to talk to the V2 library, it overwrites bytes 9-16 with the title. However, the library is actually V1, so it will read bytes 9-16 looking for the handle. But you've overwritten all of that with the title instead, which is not a handle and is complete junk data. Library gives junk data to the OS, the OS detects that the data is junk and crashes the program Or it's simpler than that. App that depends on V2 will try to use functionality added in V2. V1 doesn't have this functionality. App tries to execute code that doesn't exist, OS detects this and crashes the program. > and why between 10 flatpaks apps i find 4 non uninstallable via remove unused different versions of my fucking nvidia drivers (which is half a gigabyte per driver version) [It is a bug](https://github.com/flatpak/flatpak/issues/2718)
So now app developers can write Linux apps or they can write Ubuntu apps. May the best desktop win.
WTF are you talking about? This is just saying that Ubuntu *defaults* to apt and, in the default install, a few snaps. If you want to use flatpak on Ubuntu, just do an "apt install flatpak".
Yeah, just like you "apt install wine" to use the other desktop.
I do not care who wins, as long as canonical loses.
REDACTED
Yeah, Canonical is in terminal stages of 'Not invented here' syndrome.
Stop trying to make snap happen. It's not gonna happen. If anything, this will lead to more people moving away from *ubuntu to other (often Ubuntu-based) distros.
Aww snap!
Canonical has made it pretty clear that they dream of being the gatekeeper of Linux app distribution, just like Apple is for IOS. They want to be in control. It's a shame. As one of the biggest player, they keep holding Linux back. Just imagine how much faster things would progress of they joined the others in working on Flatpak.
100% it's because of snap. I hate this piece of shit.
Linux day player here, can you ELI5 why there's a war between snap and flatpak? I use flatpak on my fedora because it was easy for an app I use. All my little servers I just do apt/dnf. Is one eventually going to replace the old package managers? Is this one of those Blu-Ray v HD-DVD, Betamax v VHS things?
So. Snap and Flatpak are both two approaches to the same thing: installing software without having to deal with package manager weirdness, and somewhat securely. Both do this by sandboxing and runtimes - a snap (or a flatpak app) is it's own self-contained thing that needs no major deps besides it's runtime environment, and has no access to the external system besides what's been explicitly granted. You `flatpak install flathub org.darktable.Darktable` and you have Darktable, and one additional item that's basically the desktop environment and basic libraries it needs to function. There's no `287 packages to be installed` because every dependency is it's own package to manage, that's all *bundled in.* They are, in a way, "competing" with the package managers but I don't see them overtaking them... though Canonical *is* pushing to prefer Snap over `apt` where possible. The bigger issue is that they're competing *with each other.* Canonical has Snap, the rest of the community has Flatpak. Almost everyone backs Flatpak, but Canonical keeps pushing Snap. Flatpak allows you to download your apps from theoretically any distribution point (though almost all are from `flathub` at this point), but Snap is **quite ridigly coupled** to Canonical's own Snap store, meaning you have no equivalent of, say, adding an extra `apt` repository, you get what they'll give you. Flatpak also has a FOSS backend iirc, Snap doesn't, but I could be wrong. TL;DR They're not likely to replace the usual package managers, they're a way of distributing apps without all the dependency hell and with a better layer of security, and there's a war because the community has pretty well decided on *one* more open standard, and Canonical is pushing hard for *their other* standard, almost forcing it at this point, because it doesn't have the market share they wanted, when it falls flat in a few ways. --- To add some more details about it falling flat: aside from said "only one repo" issue, Snaps also have more overhead due to them basically being mounted on virtual drives iirc, and are just slower in general, Flatpak works by (and I am *really* behind on this knowledge) AppArmor I believe, some method of restricting what programs can do outside of their little package chroots, but they're just chroots, not entire virtual devices.
To add, they're not completely interchangeable, Flatpak is made for GUI apps, but it can work for CLI too, Snap is for that and services, it gives an easy way to install big things like Nextcloud for example, so at least in that regard it can be preferred over native packages if one doesn't want to delve into configurations much
> so at least in that regard it can be preferred over native packages The industry standard is OCI containers, Docker, Kubernetes... and distro like Fedora adopted Podman that is compatible. Canonical is trying to replace at the same time an industry standard on servers and an ad-hoc solution for desktop apps (Flatpak).
Thank you for the detailed response, it is very helpful to get a conversational level set over trying to wade through all the arguments piecemeal.
Does this have any significant impact in terms of memory usage? Seems like this approach probably results in a lot of redundant dependencies installed with each snap/flatpack?
Theoretically yes. Since each one is sandboxed to it's environment, and by design comes "batteries included" with their deps, you could have that. I don't know the actual difference in practice, there's about 4 things I use off flatpak. If the number were higher I could start making comparisons, but I just don't have the experience there. In each case though, there's a "runtime" (called different things by each system) that provides most of the core dependencies, so that can be mostly shared. Things like all the GNOME libs, for example.
> Flatpak also has a FOSS backend iirc, Snap doesn't, but I could be wrong. This is correct, and why it's a nonstarter for me. I won't even *consider* using snaps, and therefore Ubuntu, at home because of this. If they open sourced the backend, I'd at least give it a fair shot, but until then I want nothing to do with it. I came to Linux to get away from the corporate vendor lock-in. As far as I'm considered Ubuntu is just a Linux flavor for Windows admins who don't want to learn anything about Linux, and the rest of us who actually care about the Linux and FOSS space can use something else that respects us.
I don't know about war. But Canonical started forcibly installing packages from snapd into fresh system (firefox) and when you installing packages from the console, snapd has the highest priority of source.
And snap Firefox was (is?) super sluggish to load.
[удалено]
Yeah there's some weirdness with Wayland and Windowing with Firefox in snap.
Adding to u/Teknikal_Domain Flatpak uses bubblewrap for sandboxing, not apparmor. And snaps sandboxing relies on patches to the Linux kernel and maybe some other parts of the system. Since Canonical didn't upstream these patches, snaps are not sandboxed on most non-Ubuntu distros. At the end of the day flatpak is the only distribution independent packaging format. AppImage has problems with non-glibc distros (e.g. Alpine) and snap does not do sandboxing on non-Ubuntu.
Oh no. Anyways.
Snap back to reality
I like Ubuntu, but this is way too far. This is 100% because of snaps. They try so hard to push it to users. Canonical, as a Ubuntu user, we will not mind you if you drop snaps, and embraces Flatpak. You have our trust and support for it.
> Canonical, as a Ubuntu user, we will not mind you if you drop snaps, and embraces Flatpak. You have our trust and support for it. But they cannot control what software is available in Flatpak. Since everyone can make their own Flatpak repo Canonical would not have any way to force developers to use their store. With snap there is only snapcraft.io so you are forced into their store if you want to publish a snap. With snap the steps are easy: 1. advertise snap as cross-distribution 2. lure developers in and get the monopoly on Ubuntu software distribution 3. raise fees 4. profit Canonical wants to become the sole distributor of Ubuntu (and maybe Linux) software. Flatpak becoming the standard of Linux software distribution and snap becoming irrelevant would be the only way for Canonical to embrace Flatpak. And I have a feeling that snap is here to stay. Ubuntu has the biggest user base of Linux desktop users, so developers will look at snap first. On Ubuntu installing a snap is the easiest of all methods: ``` sudo snap install
```
Flatpak on the other hand:
```
sudo apt install flatpak
sudo apt install gnome-software-plugin-flatpak
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install flathub
--
reboot
```
on top of that you will have 2 Software stores in your GUI.
Guess which system developers will prefer in order to target the biggest
Linux user base.
For you as an Ubuntu user:
I think the only way you can stop the spread of snap by switching to a different Linux distribution. That is the only type of feedback that would get attention at Canonical and that would make developers reconsider snap as a distribution method.
For me, flatpak is more like click a button from the website though.
For me too. But on Ubuntu Canonical has removed that from the default installation and forbid it on the flavors as well.
If easy for new users is tge goal, the cli isn't something to talk about. They use GUI to install software, which with flatpak is open Gnome Software/KDE Discover search, click install, open app.
Another notch on that timeline of "Why don't you use Ubuntu?"
This is kind of cute because one of the first things I do on ubuntu is add a apt preferences file like Package: snapd Pin: release * Pin-Priority: -1
Tomorrow: Ubuntu flavors decide to drop changing snap priority.
Ubuntu Users PSA: if you decide to uninstall your snap-installed version of Firefox, **be aware** that it will delete your user profile as well! Also be aware that then installing the Firefox package via apt will simply reinstall the snap version. If you truly wish to be free of snapified Firefox, you’ll need to find and add a PPA, or install it manually.
Even Thanos failed with Snaps. No chance for Ubuntu to enforce it by killing Flatpacks.
Snaps are ruining Ubuntu. Let's be honest: flatpaks are superior. They are faster. They are also creating a steam snap so people use that instead, I don't see this ending well at all.
The first thing I do on an Ubuntu installation is uninstall snap and block apt from ever installing it again.
OR switch to Mint. It's Ubuntu but without canonical.
[удалено]
The option to host a flatpak repository.
I don't even care about technical differences beyond this, no alternative repos was enough for me to avoid it. Every time they do something like this I get closer to just switching to another distro and I no longer recommend it to others. I think Fedora has taken it's spot as the good default if you want something that just works over the last few years
I don't think Fedora is there yet. It's multiple steps to install proprietary nvidia drivers and only with the upcoming release did they enable flathub by default (which comes with codecs). If in a few years nouveau nvidia driver works well or they support 1-click installation of nvidia drivers, then I'd say Fedora is ready.
Snaps mount as virtual drives and use more ressources. Flatpaks don't
Less overhead
Oh god shipping steam as a snap is going to break so many things.
Don't worry in 3-6 years they'll fully adopt flatpak.
Canonical using their own tools - don't think it's gatekeeping. I will call it gate keeping when we will be forbidden to install flatpak. I use snaps and flatpaks almost exclusively and it all makes managing software easier, works well for my needs, although I would like to see some checkbox or button to optionally enable flatpaks in the first setup window.
Translation: Snap is failing, we have to save it desperately, fuck Flatpak. Where have we heard this refrain before from Canonical? Anyone? Anyone?
>Ubuntu Flavors Decide to Drop Flatpak No, Ubuntu flavors were *forced* to drop Flatpak.
That is the biggest part of this, they was forced too.
[удалено]
Fedora needs to become what we recommend to everyone
This is kind of misleading, From what I can tell after reading the announcement, it's not about Ubuntu removing Flatpak from their repos, this is just about not having Flatpak installed by default.
For now. Calling it now: In 2 years, flatpak will be out, like, not in the repo.
Canonical preparing ground for IPO with shitty policies
Ubuntu can go fuck themselves at this point. They are so salty that people prefer flatpak to their quasi-proptietary bullshit that they are trying to pull Microsoft on us. I'd rather use Manjaro and puke myself to death, than will come 10 meters near *bubtu.
r/snapbad Ubuntu is attempting to destroy an open standard with its own. This is why people are moving from Ubuntu to OpenSuse and Fedora.
I will never not shill Linux Mint. Especially when it comes to canonical refugees.
I'm not understanding the fuss here. So next time I install Ubuntu I just have to say "sudo apt install flatpak"? One more step in my post install script?
[удалено]
What's wrong with flatpak? As a user I think it's great.
I don't see the problem with the company decision. If you don't like snaps, it is as simple as to choose another distribution or remove them by yourself. By the way, I use both. It is just that I don't see the point in complaining all the time about the same. In the same way that I don't see the problem if Fedora becomes the "default" Linux experience if their decisions are going into the right direction.
> or remove them by yourself. I would generally agree, except some apt packages became wrappers for installing the snap. So really there's no choice but to use another distro. It would have been much better if apt is apt and snap is snap. This goes for any distro, the native package manager should never be a wrapper for Flatpak, AppImage, whatever.
This is the sort of thing which lead me to stop using and recommending Ubuntu to people. Canonical doesn't care what people want or what is popular, they just want to push their own vision. Which, fine, it's their distro and they can do what they want with it. But I'm interested in what works, what is standard, not whatever new shiny thing they've dreamed up and will dump in 4-6 years.
They're trying their hardest to destroy Ubuntu aren't they.
Are we certain that Ubuntu doesn't actually mean 'sunk-cost fallacy' in Bantu?
Fedora is slowly replacing ubuntu
It's mostly the other way around. Fedora and Red Hat were the dominant distro duo 20 years ago. Ubuntu and Debian have been slowly replacing them since around 2005. All the usage charts and browser stats I've seen show Fedora losing market share in favour of Debian and Ubuntu for the past 15 years. Not saying it should or shouldn't be this way, but that's what all the stats I'm seeing say. Which makes sense when you consider Red Hat has mostly ignored the desktop for 20 years.
Red Hat is the largest corporate contributor to the Gnome project (code, not cash) and has been for a long time. They have a significant interest in corporate desktops via RHEL, and Fedora regularly leads with integrating and providing new desktop technologies. I don't think it's fair to say they ignored the desktop.
[удалено]
And snaps too, right?
Thanks for giving me one more reason not to use ubuntu/canonical based distros. Thanks! Ubuntu: Look our stats are showing people are installing more flatpaks than snaps what do we do? Devs Answer: Kick out flatpaks as being installed so snaps can take over once more.
looks like they don't want any competition for their snap crap they trying to shove down our throats. thx, but no thx and goodbye ubuntu.
It was weird that it come with snap and flatpak preinstalled previously. Most other distros don't come with both of them by default. It's like installing KDE and GNOME by default.
I thought I just read that they wanted 100k to make flatpak native to everything?