Ubuntu stops shipping Flatpak by default
Canonical recently announced that it will no longer ship Flatpak as part of its default installation for the various official Ubuntu flavors, which is in keeping with the practices of the core Ubuntu distribution. The Flatpak package format has gained popularity among Linux users for its convenience and ease of use. Canonical will focus exclusively on its own package-management system, Snap. The decision has caused disgruntlement among some community members, who felt like the distribution was making this decision without regard for its users.
The announcement was made on the Ubuntu Discourse Forum, where Philipp Kewisch, a Community Engineering Manager at Canonical, said:
As part of our combined efforts, the Ubuntu flavors have made a joint decision to adjust some of the default packages on Ubuntu: Going forward, the Flatpak package as well as the packages to integrate Flatpak into the respective software center will no longer be installed by default in the next release due in April 2023, Lunar Lobster. Users who have used Flatpak will not be affected on upgrade, as flavors are including a special migration that takes this into account. Those who haven't interacted with Flatpak will be presented with software from the Ubuntu repositories and the Snap Store.
Why?
In the announcement, Kewisch said the decision came from a desire to,
"improve the out-of-the-box Ubuntu experience for new users while
respecting how existing users personalize their own experiences
."
Ubuntu
is prioritizing deb and Snap, its default packaging
technologies, while no longer providing a competitor by default. This is
described as an effort to provide consistency and
simplicity for
users.
By focusing on these technologies, Ubuntu claims it can provide better community support to resolve issues in the software packages. While Canonical does not have full control over every Snap package published in the Snap Store, it does have some control over the format itself. That makes it easier for Canonical to diagnose and fix problems that arise in the packaging or distribution. Furthermore, because Canonical curates the official Snap Store, it has a degree of control over the quality of the packages that are included. It can work with developers to ensure that packages meet certain standards and do not contain obvious bugs or security vulnerabilities.
In comparison, Flatpak is developed and maintained by a community of contributors, rather than being tied to any company or organization. This can make it more difficult to coordinate bug fixes or updates, Canonical claims, since there may not be a single entity responsible for the technology. In the announcement, Kewisch mentioned fragmentation issues as a problem area:
In an ideal world, users experience a single way to install software. When they do so, they can expect that this mechanism is supported by the community and receives the majority of attention when it comes to resolving issues in software packages. When a new packaging technology is provided by default, there is an expectation that the distribution provides community support and is invested in contributing to development to resolve issues. This creates fragmentation instead of focusing on improving the technologies chosen for the distribution.
There is a key difference between having the base Flatpak package installed by default and having a Flatpak repository, such as Flathub (or something Ubuntu-specific), configured, which Ubuntu and its flavors never did. Merely removing the base Flatpak installation from the default install won't prevent users from having problems with Flatpak applications if they go ahead and install them anyway. Nor will it make those problems any easier to solve.
This adds fuel to the fire that Canonical is doing this largely to further its own interests. Since it controls the Snap Store, the company will be in a position to share in the revenue from any proprietary Snaps available there, for example. But even if Canonical has some self-serving reasons for making this change, it's important to remember that it hasn't removed Flatpak entirely; users will still be able to install the package-management system manually.
Impact
The move generated mixed reactions in the Linux community, with some users and developers expressing disappointment in the decision. Others argued in favor of Canonical's choice, agreeing with its reasoning about the unnecessary burden Flatpak places on support staff. Forum user Aaron Rainbolt ("arraybolt3") said that Ubuntu tries to change its package versions rarely and only update them for important bug fixes, which is not at all the case with Flatpaks so users may experience instability when using them, for example. In a reply, "h0lly" saw things differently:
People who opt to using flatpaks do so precisely because they do want the most recent (stable) releases, which I suspect is a lot of users evidenced by the raise of flatpak popularity.furthermore, thanks to the sandboxing flatpak apps generally work great out of the box. the picture you paint of users having a bad experience with unstable flatpaks is mostly made up. and even then, flatpak not being selected as the default source in the app store is already plenty to "guard" inexperienced users. if it was really about that, it could just display a little notice warning the user when selecting a flatpak source for the first time.
imho there is no need for Canonical to control anything here. there is absolutely nothing technical stopping its support staff from being able to say, "sorry you'll have to seek support from that flatpak's maintainer, we can't help you" and having [it] as an integrated option at the same time. although I don't think this would happen anywhere as frequently as you make it out to.
Rainbolt further defended the change, noting,
that while Flatpak may be more convenient, Snap packages will provide
greater long-term compatibility and lessen the burden placed on technical
support staff. "An app doesn't have to have anything wrong with it for it
to cause problems for technical supporters. It just has to have something
different from what the supporters are used to.
"
Another potential concern may be that Canonical could be using this decision to force package upstreams to offer a Snap version or face not being easily available in the default Ubuntu installation.
Ubuntu clearly wanted to present this decision as a united front with its flavors, but some have called that into question. As recently as December 2022, Sean Davis, Technical Lead for the Xubuntu flavor, was seen promoting Flatpak. While a lot can change in a few months, it does seem strange that Davis commented on its benefits fairly recently:
With the addition of the flatpak and gnome-software-plugin-flatpak packages, Xubuntu now supports the popular Flatpak packaging format. You can now easily install applications from Flathub with just a couple of clicks. In fact, any .flatpakref or .flatpakrepo file is natively supported thanks to GNOME Software.
The motives behind Canonical's move remain somewhat murky, but Flatpak users can be comforted by the fact that enabling the package-management system is still possible, though it's now something of a chore to do so.
Using Flatpak
For starters, it means that users will first need to manually install Flatpak and a repository, like Flathub, before they can begin to install Flatpak applications using the Ubuntu Software Center. Flatpak is a part of the universe repository, which means it is included in the community-maintained repository of Ubuntu packages that are not officially supported by Canonical. Due to this, Flatpak can be installed via the Ubuntu Software Center or the GNOME Software GUI.
Once Flatpak is installed, it can be connected to a Flatpak repository, such as Flathub. To configure Flathub, the following command can be used:
$ flatpak remote-add --if-not-exists flathub \
https://flathub.org/repo/flathub.flatpakrepo
In the announcement, Kewisch addressed some common concerns that users may have regarding the decision. For example, users would not lose access to applications that depend on the Flatpak ecosystem:
We've added a special migration that checks if you have Flatpak packages installed or remotes configured. If so, flatpak and related software centre plugins won't be auto-removed on an upgrade to Lunar Lobster. Therefore, you don't need to be concerned about this change.
Furthermore, Flatpak users do not have to worry about the package-management system being removed on current and older versions of Ubuntu either:
No, flavors are not actively removing package managers from the current or older releases. This change is for the upgrade to Lunar Lobster and beyond, where it is available but will not be installed by default in new installations.
Conclusion
Ubuntu's decision to stop shipping Flatpak by default is significant, but it is not the end of the road for the package-management system on Ubuntu. As the Linux ecosystem continues to evolve, it's likely that we will see other new technologies and approaches emerge to meet the needs of users and developers. For now, Ubuntu users who want to use Flatpak will need to adjust to the new way of doing things, but they will still have access to a same wide range of Flatpak apps.
| Index entries for this article | |
|---|---|
| GuestArticles | Moodley, Bradley |
Posted Mar 28, 2023 20:13 UTC (Tue)
by Spack (subscriber, #77556)
[Link] (13 responses)
Posted Mar 29, 2023 0:25 UTC (Wed)
by ms-tg (subscriber, #89231)
[Link] (6 responses)
If so, is that still going or did Ubuntu move to Systemd with Debian?
Posted Mar 29, 2023 4:08 UTC (Wed)
by codehz (guest, #161400)
[Link] (4 responses)
Posted Mar 29, 2023 6:04 UTC (Wed)
by rsidd (subscriber, #2582)
[Link] (3 responses)
Posted Mar 29, 2023 9:05 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (2 responses)
But, in keeping with the pattern, the people who started systemd originally wanted to contribute to upstart instead, but when they attempted to do so, Canonical's CLA got in the way, because it required copyright assignment to Canonical, but made no promises in return other than that your contribution would be part of upstart.
This is what ends up killing each of Canonical's ideas; Mir was a non-starter for the same reason. By attempting to maintain an iron grip on the upstream implementation, Canonical put themselves in a position where people contribute to the competing project, and over time, the competing project gains enough momentum that nobody outside Canonical contributes to Canonical's project, because it's easier to contribute to the competing project, and the competing project is nearly as good as Canonical's project. Give it a bit of time, and the extra weight of contributors to the competing project means that Canonical's project is not as good as the competition, and Canonical end up unable to keep up.
The fundamental killer each time has been that the Linux ecosystem is not large enough to sustain a Canonical-owned project in competition with a more open project, and that Ubuntu and derivatives don't carry a majority of open source developers with them - so the contributor pool to the competing project is larger than to Canonical's project, and ends up winning by virtue of sheer weight of developers.
Posted Mar 29, 2023 11:31 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
Also, and this is Lennart in particular I understand, there were several design flaws in Upstart. Canonical showed absolutely no interest in fixing them, so systemd was started from scratch. While I'm not a prolific programmer I understand this completely - for me clean design is *very* important.
Design something properly, and technical debt stays low. If you plan out your state table to be complete, even if you only address one or two states, cruft doesn't build up. The biggest cause of cruft is accidentally closing off a solution path you suddenly realise you need "some time" down the line, when it's too late easily to revisit past decisions.
Cheers,
Posted Mar 30, 2023 8:35 UTC (Thu)
by rsidd (subscriber, #2582)
[Link]
Posted Mar 29, 2023 4:36 UTC (Wed)
by viiru (subscriber, #53129)
[Link]
There were also multiple Canonical employees voting in the Debian Technical Committee, and the conflict of interest sparked yet more controversy.
Posted Mar 29, 2023 3:06 UTC (Wed)
by dralley (subscriber, #143766)
[Link] (1 responses)
* latpak was an idea with a little bit of prototyping going on
Posted Mar 29, 2023 19:19 UTC (Wed)
by luya (subscriber, #50741)
[Link]
Posted Mar 29, 2023 13:06 UTC (Wed)
by ocztrion (guest, #164350)
[Link] (3 responses)
In a sense that is good. Once they realise their way is not the ideal (or popular) way they do revert to the common way.
Posted Mar 29, 2023 14:59 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
If Canonical make the mistakes, and then the alternative dodges them, that's a good thing (just not for Canonical, though :-)
Cheers,
Posted Mar 29, 2023 17:16 UTC (Wed)
by Spack (subscriber, #77556)
[Link] (1 responses)
Posted Mar 29, 2023 18:22 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
Except your solution doesn't suit me. Indeed it may not even work for me.
Your idea is called "the tyranny of the majority" and doesn't not allow for the fact that Mr Average does not, in fact, actually exist.
Cheers,
Posted Mar 28, 2023 20:21 UTC (Tue)
by atnot (subscriber, #124910)
[Link] (9 responses)
> Canonical Announces new Vision for Snap, Will be Based on Flatpak
Posted Mar 28, 2023 22:36 UTC (Tue)
by dowdle (subscriber, #659)
[Link] (5 responses)
snap and flatpak have some overlap in functionality, but snap is made for all package types whereas flatpak is only targeting graphical desktop applications.
Since the announcement, at least one person (the LearnLinuxTV YouTube guy) has put together an Ubuntu remix that includes flatpak pre-installed along with some pre-installed flatpaks from flathub... and as was pointed out in the fine article... manually adding it post install isn't that difficult if I understood correctly.
Posted Mar 29, 2023 1:18 UTC (Wed)
by champtar (subscriber, #128673)
[Link]
Posted Mar 29, 2023 14:33 UTC (Wed)
by jhoblitt (subscriber, #77733)
[Link] (3 responses)
Posted Mar 30, 2023 2:41 UTC (Thu)
by dowdle (subscriber, #659)
[Link] (2 responses)
Practically speaking, Flathub is the only flatpak respository I've heard of... although I think Fedora has some packages available as flatpaks. I'd like to find some documentation on how to setup my own flatpak repo. Do you know where I might find some? I don't really want to create new/custom flatpak packages, I'd just like to mirror an existing repo... or download the flatpaks I'm interested in... so I can host them on my LAN... so all of my hosts don't have to download the same things from off-LAN. Admittedly I haven't looked really, really hard for documentation... but if it exists, I haven't found it. Any pointers?
Posted Mar 30, 2023 5:43 UTC (Thu)
by zdzichu (subscriber, #17118)
[Link]
Posted Mar 30, 2023 14:54 UTC (Thu)
by nedrichards (subscriber, #23295)
[Link]
if you want to install the apps from the elementary OS AppCenter (for example). Back in the day when I was working at Endless we had our own repo for Endless OS specific stuff as well.
Posted Mar 28, 2023 22:39 UTC (Tue)
by Nikratio (subscriber, #71966)
[Link] (1 responses)
Posted Mar 28, 2023 23:41 UTC (Tue)
by atnot (subscriber, #124910)
[Link]
Posted Mar 29, 2023 1:24 UTC (Wed)
by Paf (subscriber, #91811)
[Link]
Posted Mar 28, 2023 20:38 UTC (Tue)
by flussence (guest, #85566)
[Link]
Canonical's constant swings at RedHat are transparent, out-of-touch and reek of desperation. They can't just settle for providing a good OS, and they're straying further from actually having one as a result. Good ideas don't have organic first-page search engine results on how to completely uninstall them.
Posted Mar 29, 2023 5:14 UTC (Wed)
by eru (subscriber, #2753)
[Link] (6 responses)
Posted Mar 29, 2023 11:59 UTC (Wed)
by atnot (subscriber, #124910)
[Link] (4 responses)
Snap has:
Flatpak has:
Posted Mar 29, 2023 13:57 UTC (Wed)
by Xiol (guest, #87394)
[Link] (3 responses)
Posted Mar 29, 2023 17:52 UTC (Wed)
by ms_43 (subscriber, #99293)
[Link] (2 responses)
And the AppArmor in Linux isn't good enough, it needs additional patches that are only in the downstream Ubuntu kernel.
https://forum.snapcraft.io/t/snapd-still-requires-out-of-...
Posted Mar 30, 2023 9:51 UTC (Thu)
by tajyrink (subscriber, #2750)
[Link] (1 responses)
Posted Mar 31, 2023 8:04 UTC (Fri)
by ms_43 (subscriber, #99293)
[Link]
Posted Apr 12, 2023 11:31 UTC (Wed)
by emmi3 (subscriber, #62443)
[Link]
- Snap can only be used as root (or at least I haven't found out how).
This makes Snap completely useless for our locked down devices, where we want to allow the user to add desktop applications as needed, but not change anything in the base system.
This took me by surprise, since I was under the assumption that both are functionally on par.
Posted Mar 29, 2023 5:32 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link]
Meh. This is sort of the whole point of Ubuntu as a distro, so I don't really begrudge them making that argument. If you want a community-supported distro, go run some flavor of Debian, or Mint, or something like that. There are a lot of options these days.
> This adds fuel to the fire that Canonical is doing this largely to further its own interests.
They're a profitable company, so that doesn't really surprise me either.
Posted Mar 29, 2023 7:44 UTC (Wed)
by jengelh (guest, #33263)
[Link]
Well, it's a company, not a charity (but even charities have an interest, or perhaps scope, set forth in bylaws), and here is a friendly reminder that _companies are not your friends_ (search for the term if unaware).
Posted Mar 29, 2023 8:04 UTC (Wed)
by cyperpunks (subscriber, #39406)
[Link] (8 responses)
Talking about competition and forks: one of the most horrible forks recent years was done by Red Hat and their Docker "replacement" podman. The compatibility between these are almost nil.
Posted Mar 29, 2023 13:22 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
Huh? Podman is not a fork of Docker and has pretty good compatibility with Docker including OCI images, the REST api and socket.
Posted Mar 29, 2023 14:24 UTC (Wed)
by dowdle (subscriber, #659)
[Link]
Posted Mar 29, 2023 15:18 UTC (Wed)
by jhoblitt (subscriber, #77733)
[Link]
Posted Mar 29, 2023 18:22 UTC (Wed)
by jeffgus (guest, #59146)
[Link] (3 responses)
I've found podman much better. The design is much better. Security design is better.
The k8s export feature is cool.
Also, "podman play kube". The ability to have a k8s subset is also nice. In theory, no need for 'docker compose' just simplified k8s yamls for podman. They aren't trying to copy k8s, just a useful subset.
Posted Mar 30, 2023 11:21 UTC (Thu)
by mbunkus (subscriber, #87248)
[Link] (2 responses)
Posted Mar 30, 2023 14:25 UTC (Thu)
by TomH (subscriber, #56149)
[Link] (1 responses)
It doesn't do IPv6 ping beyond the the host as slirp doesn't support it yet (https://gitlab.freedesktop.org/slirp/libslirp/-/blob/mast...) but TCP connections are fine.
The only slightly odd thing was that glibc's address resolution seemed to be preferring v4 addresses when it normally prefers v6 if you have it. Not sure if that's because of the ULA address or what though.
Posted Mar 30, 2023 14:42 UTC (Thu)
by mbunkus (subscriber, #87248)
[Link]
About preferences: yes, it's official RFC policy that ULAs have lower priority than IPv4 addresses on dual-stacked hosts. Or to put it differently, the only time a dual-stacked host with only ULA IPv6 will only ever use IPv6 for connections to IPv6-only hosts, never to dual-stacked ones. Yes, that makes ULAs unusable for most scenarios where you'd like to use them, unfortunately. And no, they aren't comparable to IPv4 private address space in functionality.
If you want to know more about this mess, there are several very good blog posts out there about it, e.g. this one: https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual...
Posted Mar 29, 2023 19:24 UTC (Wed)
by vadim (subscriber, #35271)
[Link]
This means that for instance it can run without root access (so much better for security), and there's no central system that can crash and take a hundred containers with it.
Posted Mar 29, 2023 19:19 UTC (Wed)
by passthejoe (guest, #156034)
[Link]
I'm not sure if RHEL ships Flatpak by default for its desktops.
Is that me or they keep repeating the cycle. They fork from a somewhat popular project to focus on one of their own to come back later to the concensus.
Gnome > Unity > Gnome,
Xorg/Wayland > Mir > Wayland,
Flatpak > Snap > ...
Ubuntu cycle
Ubuntu cycle
Ubuntu cycle
Ubuntu cycle
Ubuntu cycle
Ubuntu cycle
Wol
I found this ancient comment by Scott James Remnant, creator of upstart, archived from G+. He basically says the CLA prevented Lennart, Kay Sievers, as well as he himself (after he left Canonical) from contributing to upstart; and upstart has its flaws but wasn't perceived as "shitty" at that time (2010) so if it weren't for the CLA, Lennart/Kay would likely have contributed to it and not written systemd.
Ubuntu cycle
Ubuntu cycle
Ubuntu cycle
* Canonical announces snap, with a mostly-functional implementation and a lot of engineering and marketing resources behind it
* people started taking the idea more seriously and actively working on flatpak shortly after so as not to be left in the dust
Snap is based from the old glick2, the ancestor of flatpak.
Ubuntu cycle
Ubuntu cycle
Ubuntu cycle
Wol
It is indeed a good thing to look for other options and maybe come with something better. But I can't stop thinking that all forces could join this energy on a single solution.
Ubuntu cycle
Given the distributed nature of open source, there will always be diverging opinions or someone wanting to try something else. Nothing wrong about this.
Ubuntu cycle
Wol
Ubuntu stops shipping Flatpak by default
>
> Ubuntu owner Canonical announced today in a blog post their vision for "Snap 2.0", their new vision for the role of Snap on the desktop. The statement outli [...]
> In what may come as a surprise to some, they also announced they would cease development on wide swaths of the current snap code and [...] competing flatpak instead. Existing applications on the snap store will be converted to flatpak format automatically [...] developers will still be able to continue using the snap store and snap tooling into the future, according to the company statement.
> While the move was unexpected considering that Ubuntu had removed Flatpak from their default install [...] years ago, it is certainly not unprecedented. The fate of snap in many way resembles the fate of some of their previous projects such as Mir, Unity, Upstart, Launchpad, Ubuntu One, [...]
> Canonical announced they would instead be focussing on [...] and their container orchestration offerings for servers.
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
How to setup one's own flatpak repository?
How to setup one's own flatpak repository?
How to setup one's own flatpak repository?
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
Technical difference?
Technical difference?
- good support for cli programs and services
- more modularity, with base runtimes and applications that can be used and extended by multiple packages
- more capable sandboxing via bubblewrap that also works across all linux distributions without out-of-tree patches
- support for many repositories not just one hardcoded one
Technical difference?
Technical difference?
Technical difference?
Technical difference?
Technical difference?
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default
container technology & IPv6
Ubuntu stops shipping Flatpak by default
Ubuntu stops shipping Flatpak by default