Canonical has announced a change in the packaging defaults for the various "flavours" like Kubuntu, Ubuntu MATE, Ubuntu Budgie and so on to exclude Flatpak and stick with Snap. Yes that's flavours, not flavors but also flavors in the announcement.
This is no doubt going to be a hot topic, because name me a more intense argument in the Linux world than packaging. While Flatpak has been gaining many fans lately, partly because it's included as the official way to install extra packages in Desktop Mode on the Steam Deck, Canonical are sticking to their own Snap.
So what's going on? In short: Ubuntu flavours will no longer have Flatpak enabled or setup by default. However, users can still do it themselves as they're not being removed from any repositories. It's all about the out of the box experience, with Canonical and the flavours now sticking to deb and snap to maintain their focus on what is actually properly supported by them and gets the most attention.
Users who have Flatpak installed won't see any changes, it's just the out of the box new-install experience as of April 2023, with the release of Ubuntu Lunar Lobster.
This is, after all, why we have different distributions isn't it? They're free to make whatever decisions they wish, and people who don't like it can go elsewhere, or just change the defaults to their liking — Linux is open and configurable unlike certain other systems. Do what you want.
So while it's going to be controversial, it's not exactly a big deal is it? Sort of. It's still making the desktop Linux experience quite messy, especially for newer users since there's no single way of installing things across different Linux distributions. You can't usually just point people to this thing and say get that, unless you first know the exact distribution they're on.
If you have thoughts you can comment on the announcement and let them know.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: sprocketNow before people lose their cool over this, lets look at it from Canonical's perspective:
Canonical need to support their LTS versions of Ubuntu and the different flavors. That *includes* everything offered in the Snap store, since Snaps and the Snap store are officially supported.
Flatpaks are *not* officially supported, because Canonical doesn't run Flathub.
Flatpaks are not going away, they just aren't going to be officially supported (Use at your own risk sort of thing). Which is fine.
Ubuntu forks/spinoffs like Mint and Pop_OS will currently continue to support Flatpaks out of the box.
The flip side of the argument is that, if you don't want to be wrapped up in the Snap ecosystem, then Ubuntu and its flavors probably isn't going to be your Linux distro of choice anymore. Fortunately the Linux (and Ubuntu-based) ecosystem is rather large, and Ubuntu forks/spinoffs like Pop_OS and Mint are still a thing.
When discussing about these kind of things it's always the same vision Canonical doesn't share: Linux should develop into a platform, so it's *possible* to create software that will install and run on any Linux distribution if you know how to. But once again, no, Canonical works in the opposing direction. Śo, they don't want to support flathub? Fine, then don't add the repo, but the flatpak base software stack should be included on every desktop linux distro by default, there is no good argument against it.
0 Likes
Quoting: M@GOidI personally have no horse in this race, since I prefer tradicional packaging over Snap/Flatpack.I do too. Still have a smidge of an opinion about Snaps/Flatpaks though.
Quoting: M@GOidAlso, since I'm not a Canonical hater, I also do not see any problem with this. Other distros don't promote Snap, so why Canonical had any obligation to support a competitor option?Is it really a "competitor option"? I don't think Flathub is maintained by some specific other distro company. My understanding of Flatpaks is that they are just an independent piece of software, like LibreOffice or something. If Canonical were to start considering the whole open source ecosystem to be "competition" they would have problems.
On the other hand, for every other distro, Snaps really are a "competitor option" since they're created and maintained by not just a particular distro, but by a for-profit corporation, and Snap as currently written works with just one repository, Canonical's. It probably would be do-able to change that, it's not like Snap stuff is closed source, but what's the motivation to bother? You'd have to fork it and maintain the fork because Canonical ain't gonna accept any patches to do that; it'd be a pain and a big controversy. So nobody else is ever going to seriously adopt Snaps, but any new distro has no problem including Flatpaks.
Basically, if Canonical's thinking about Snaps is just that they're a handy tool to be used by Canonical, then there's nothing wrong with their approach. If on the other hand they are imagining Snaps as a technology competing with Flatpaks and other packaging things in the broader Linux software ecosystem, they have kept them too closely attached to Canonical to be able to spread, and will fail.
Last edited by Purple Library Guy on 23 February 2023 at 4:21 pm UTC
7 Likes, Who?
Quoting: BoldosIf you're going to make that comment maybe it would have made more sense to be arguing with the person who actually mentioned Upstart . . .Quoting: ZlopezI'm not sure why Canonical doesn't want to have flatpak installed out of the box, but they sometimes do strange decisions, like Mir or Unity. Not bad projects but they were the only one using them and dropped them after some time.I'm not sure why people keep bashing Canonical of doing "bad" or "strange" decisions/projects all the time.
Upstart was there before anyone even heard about that second weird thing called systemd. But it is Canonical who is the bad guy yet again for choosing their own path?
Oh c'mon...
1 Likes, Who?
I love flatpak. I distro hopped for a year from ubuntu after they kept making it harder to use, and game on. Now I am on manjaro/arch/steamos. I use official packages when available, or install flatpak when it is not. Then it's AUR and SNAP as a last ditch effort.
1 Likes, Who?
Quoting: F.UltraQuoting: whizseI can't say I have a stake in this, but it's interesting to ponder that Ubuntu seems to have a habit of betting on the wrong horse, Mir and upstart, for example.
I wish that people would stop bringing up Upstart in discussions like these. Upstart predates systemd by 4 years and was at the time the best candidate to replace the ancient SysVinit which is why many, including Red Hat and Chromebooks, move over to Upstart.
The same is also true of snaps, Mir, and Unity. Snaps predate flatpaks and have features that flatpaks still lack. Wayland wasn't (and still isn't) a good choice for phones since it's for the desktop. There (still) isn't a convergent desktop environment that will work across phones, netbooks, tablets and the desktop, which was the aim of Unity.
Canonical's problem is that they want to push things forward but don't have Red Hat (IBM now) money.
4 Likes, Who?
BlackBloodRum Feb 23, 2023
Just Canonical being Canonical to be honest. It's usual game for them.
Lest we forget:
Wayland vs Mir
Unity vs Gnome
Upstart etc and so on
Really this is nothing new. Canonical has always made a product and project while excluding the other distributions in the design process just to avoid adding code upstream and then thrown their teddy out the cot when people don't use it.
Nothing to see here folks, move along
Give it a few years, they'll have flatpak again.
Last edited by BlackBloodRum on 23 February 2023 at 5:10 pm UTC
Lest we forget:
Wayland vs Mir
Unity vs Gnome
Upstart etc and so on
Really this is nothing new. Canonical has always made a product and project while excluding the other distributions in the design process just to avoid adding code upstream and then thrown their teddy out the cot when people don't use it.
Nothing to see here folks, move along
Give it a few years, they'll have flatpak again.
Last edited by BlackBloodRum on 23 February 2023 at 5:10 pm UTC
2 Likes, Who?
Quoting: BlackBloodRumJust Canonical being Canonical to be honest. It's usual game for them.
Lest we forget:
Wayland vs Mir
Unity vs Gnome
Upstart etc and so on
Really this is nothing new. Canonical has always made a product and project while excluding the other distributions in the design process just to avoid adding code upstream and then thrown their teddy out the cot when people don't use it.
Nothing to see here folks, move along
Give it a few years, they'll have flatpak again.
I'm not hostile to that complany at all. In fact I'm thankful to that company, Ubuntu made me stay with Linux in the early 2000s, after several failed attempts with other distros. The first Ubuntu releases really were a lot more usable then anything I had tried before. My fascination for Linux made me look into game development. That made me cancel my PhD in molecular genetics and go for an entirely new career in IT and I'm still very happy with that decision.
Yet when I see them make another decision that shows they don't feel like agreeing to standards or being a part of the community, I will criticize that. They are still among the biggest distros and if they don't adhere to standards, they better have a good reason.
I don't see that reason here. For as long as I can think, Linux needed a way for 3rd partys to provide (e.g. closed source) applications directly to their users. Not to replace repos, but to make desktop linux a platform. Now here we finally are. No company can still say they can't provide software because of .deb, .rpm..., flatpak has proven it's worth. And now Canonical comes in and goes no, not with us. It's damn frustrating.
2 Likes, Who?
Quoting: constWhen discussing about these kind of things it's always the same vision Canonical doesn't share: Linux should develop into a platform, so it's *possible* to create software that will install and run on any Linux distribution if you know how to. But once again, no, Canonical works in the opposing direction. Śo, they don't want to support flathub? Fine, then don't add the repo, but the flatpak base software stack should be included on every desktop linux distro by default, there is no good argument against it.The one argument I have for Snap over Flatpak is that Snap works for CLI software and system software. As of now, Flatpak is only Userland and GUI-based software.
That's as far as I'm going to defend Snap though. There's a LOT about it I do not like, and I actively avoid using Snaps whenever possible.
Canonical is drawing a line in the sand, and they have their reasons. That's their choice, and it's our choice whether we agree with it or not.
0 Likes
dziadulewicz Feb 23, 2023
Please read this response from a developer to understand this decision better. It makes perfect sense and no need to raise pitchforks yet again: https://discourse.ubuntu.com/t/ubuntu-flavor-packaging-defaults/34061/9
"As a developer, it might help to see a bit of the standpoint I have on this issue, as I actually agree with the decision to not include Flatpak by default. I may simply be reiterating what @kewisch has already said, but I don’t have to talk in “official language” so it might be a bit easier to swallow.
It may be easily overlooked, but one of the core features of Ubuntu is that package versions change very, very rarely. If at all possible, bug fixes are taken from the (openly viewable) source code of an application, carefully tweaked to make them compatible with an older version of the software, patched in, tested, and only then deployed. There are a few packages where this is impractical (Firefox for instance), and there are some closed-source packages in the Restricted repo that we can’t backport patches into since we don’t have the code. But for the most part, if you install an app into Ubuntu, that’s the app you get, and that will be the app you continue to use for the rest of that release’s lifespan.
This is a powerful feature since it makes Ubuntu unlikely to randomly break your important data as often as that other OS that you hear get a lot of grief from Linux geeks, but it also requires that Canonical and the Ubuntu community have near-total control over the software repository.
That’s only possible if Canonical actually has the necessary control.
Canonical does have total and complete control over the Ubuntu archive that apt uses. And Canonical has total and complete control over the Snap repository. If something goes wrong and Canonical must step it, they can.
But Canonical has zero control over the Flatpak repositories. They do not host a Flatpak repo of their own (Snap does the near-equivalent job), nor do they control Flathub or any of the other Flatpak repos (at least as far as I know). This means that if something goes awry with a Flatpak, the user is pretty much left to figure it out for themselves.
What’s worse, most of the Ubuntu flavors (and Ubuntu itself) provide free technical support via forums and IRC channels. Most of our users are using software from the Ubuntu repos or Snap Store and we are equipped to help them. We know what to expect from the software our users run and can give targeted and efficient advice on how to resolve issues. Some of us can even kick things into shape in the archives if there’s a legitimate problem with our packages, or we know who to talk to.
With Flatpaks, the situation is much more dismal from a technical support perspective. We have little-to-no clue what quirks the software vendor(s) will have introduced since we don’t work closely with them. We have no way to reach in and fix legitimate bugs aside from filing bug reports and hoping that they will be answered. We’re going to end up with frustrated support staff and even more frustrated users. And all because they didn’t know that if they clicked a particular button in their flavor’s app store, they would be downloading unsupported software.
Yuck. No thanks.
Ubuntu provides plenty enough software for most people in the apt archives and in the Snap Store. In the rare instances that someone needs a Flatpak, they have to go out of their way to enable Flatpak support, which gives them a clue that what they’re doing might not end well. If they enable Flatpak, install an app, it fails, and then they come ask for help, they’ll at least expect it when we say “sorry, we don’t support Flatpaks, that’s why they require extra steps to enable”. They’re exactly like PPAs from an Ubuntu support perspective. And I’m sure we can agree that providing official support for arbitrary PPAs is a bad idea.
That, in a nutshell, is why Canonical and the Ubuntu flavors have gone ahead and agreed to not include Flatpak on the default ISOs, at least as I understand it. As a regular supporter in the IRC channels and many of the Ubuntu-related forums, I heartily agree with this decision.
(For the record, I don’t hate Flatpaks, just like I don’t hate PPAs. In fact I have Flatpak enabled on my personal system and have nn app installed from Flathub that I use. I just don’t expect that the official Ubuntu support venues are going to help me if that app goes berzerk.)"
"As a developer, it might help to see a bit of the standpoint I have on this issue, as I actually agree with the decision to not include Flatpak by default. I may simply be reiterating what @kewisch has already said, but I don’t have to talk in “official language” so it might be a bit easier to swallow.
It may be easily overlooked, but one of the core features of Ubuntu is that package versions change very, very rarely. If at all possible, bug fixes are taken from the (openly viewable) source code of an application, carefully tweaked to make them compatible with an older version of the software, patched in, tested, and only then deployed. There are a few packages where this is impractical (Firefox for instance), and there are some closed-source packages in the Restricted repo that we can’t backport patches into since we don’t have the code. But for the most part, if you install an app into Ubuntu, that’s the app you get, and that will be the app you continue to use for the rest of that release’s lifespan.
This is a powerful feature since it makes Ubuntu unlikely to randomly break your important data as often as that other OS that you hear get a lot of grief from Linux geeks, but it also requires that Canonical and the Ubuntu community have near-total control over the software repository.
That’s only possible if Canonical actually has the necessary control.
Canonical does have total and complete control over the Ubuntu archive that apt uses. And Canonical has total and complete control over the Snap repository. If something goes wrong and Canonical must step it, they can.
But Canonical has zero control over the Flatpak repositories. They do not host a Flatpak repo of their own (Snap does the near-equivalent job), nor do they control Flathub or any of the other Flatpak repos (at least as far as I know). This means that if something goes awry with a Flatpak, the user is pretty much left to figure it out for themselves.
What’s worse, most of the Ubuntu flavors (and Ubuntu itself) provide free technical support via forums and IRC channels. Most of our users are using software from the Ubuntu repos or Snap Store and we are equipped to help them. We know what to expect from the software our users run and can give targeted and efficient advice on how to resolve issues. Some of us can even kick things into shape in the archives if there’s a legitimate problem with our packages, or we know who to talk to.
With Flatpaks, the situation is much more dismal from a technical support perspective. We have little-to-no clue what quirks the software vendor(s) will have introduced since we don’t work closely with them. We have no way to reach in and fix legitimate bugs aside from filing bug reports and hoping that they will be answered. We’re going to end up with frustrated support staff and even more frustrated users. And all because they didn’t know that if they clicked a particular button in their flavor’s app store, they would be downloading unsupported software.
Yuck. No thanks.
Ubuntu provides plenty enough software for most people in the apt archives and in the Snap Store. In the rare instances that someone needs a Flatpak, they have to go out of their way to enable Flatpak support, which gives them a clue that what they’re doing might not end well. If they enable Flatpak, install an app, it fails, and then they come ask for help, they’ll at least expect it when we say “sorry, we don’t support Flatpaks, that’s why they require extra steps to enable”. They’re exactly like PPAs from an Ubuntu support perspective. And I’m sure we can agree that providing official support for arbitrary PPAs is a bad idea.
That, in a nutshell, is why Canonical and the Ubuntu flavors have gone ahead and agreed to not include Flatpak on the default ISOs, at least as I understand it. As a regular supporter in the IRC channels and many of the Ubuntu-related forums, I heartily agree with this decision.
(For the record, I don’t hate Flatpaks, just like I don’t hate PPAs. In fact I have Flatpak enabled on my personal system and have nn app installed from Flathub that I use. I just don’t expect that the official Ubuntu support venues are going to help me if that app goes berzerk.)"
6 Likes, Who?
Quoting: sprocketThe one argument I have for Snap over Flatpak is that Snap works for CLI software and system software. As of now, Flatpak is only Userland and GUI-based software.Um . . . I can kind of see how Flatpak might only work for userland software. And I can see how Flatpak itself might have only GUI-based installation software, and no CLI-based tool for installing Flatpaks. But I don't see how, technically, it would be possible for Flatpak to even be able to tell if the software being packaged was CLI software. I suppose it would feel weird and backwards to use a GUI to install CLI software, but I don't get how they could make that not work.
Last edited by Purple Library Guy on 23 February 2023 at 7:05 pm UTC
1 Likes, Who?
Patreon
PayPal
See more from me