Ubuntu stops shipping Flatpak by default

March 28, 2023

This article was contributed by Bradley Moodley

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

to post comments

Ubuntu cycle

Posted Mar 28, 2023 20:13 UTC (Tue) by Spack (subscriber, #77556) [Link] (13 responses)

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

Posted Mar 29, 2023 0:25 UTC (Wed) by ms-tg (subscriber, #89231) [Link] (6 responses)

Q: Did the same thing happen with a Ubuntu init system?

If so, is that still going or did Ubuntu move to Systemd with Debian?

Ubuntu cycle

Posted Mar 29, 2023 4:08 UTC (Wed) by codehz (guest, #161400) [Link] (4 responses)

Yes, (traditional) init -> Upstart (2006-2014) -> Systemd

Ubuntu cycle

Posted Mar 29, 2023 6:04 UTC (Wed) by rsidd (subscriber, #2582) [Link] (3 responses)

In fairness, upstart came before systemd and was initially adopted by Fedora, RHEL and others; it wasn't Ubuntu's "going their own way", they were filling a need.

Ubuntu cycle

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.

Ubuntu cycle

Posted Mar 29, 2023 11:31 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 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

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,
Wol

Ubuntu cycle

Posted Mar 30, 2023 8:35 UTC (Thu) by rsidd (subscriber, #2582) [Link]

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

Posted Mar 29, 2023 4:36 UTC (Wed) by viiru (subscriber, #53129) [Link]

It did. Canonical was waiting for the result of the Debian init debate, and after systemd was chosen announced that Ubuntu would move to systemd and killed the upstart project.

There were also multiple Canonical employees voting in the Debian Technical Committee, and the conflict of interest sparked yet more controversy.

Ubuntu cycle

Posted Mar 29, 2023 3:06 UTC (Wed) by dralley (subscriber, #143766) [Link] (1 responses)

Snap arguably came first, although it was something more like this:

* latpak was an idea with a little bit of prototyping going on
* 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

Ubuntu cycle

Posted Mar 29, 2023 19:19 UTC (Wed) by luya (subscriber, #50741) [Link]

Snap is based from the old glick2, the ancestor of flatpak.

Ubuntu cycle

Posted Mar 29, 2023 13:06 UTC (Wed) by ocztrion (guest, #164350) [Link] (3 responses)

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

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.

Ubuntu cycle

Posted Mar 29, 2023 14:59 UTC (Wed) by Wol (subscriber, #4433) [Link]

Always plan to throw version 1 away ...

If Canonical make the mistakes, and then the alternative dodges them, that's a good thing (just not for Canonical, though :-)

Cheers,
Wol

Ubuntu cycle

Posted Mar 29, 2023 17:16 UTC (Wed) by Spack (subscriber, #77556) [Link] (1 responses)

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.

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

Posted Mar 29, 2023 18:22 UTC (Wed) by Wol (subscriber, #4433) [Link]

> But I can't stop thinking that all forces could join this energy on a single solution.

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,
Wol

Ubuntu stops shipping Flatpak by default

Posted Mar 28, 2023 20:21 UTC (Tue) by atnot (guest, #124910) [Link] (9 responses)

For anyone curious how this turns out, I have received snippets of an article from a time traveller, supposedly from the year 2025. Some of the data was lost in transit it seems, but I think the information is still useful:

> Canonical Announces new Vision for Snap, Will be Based on Flatpak
>
> 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

Posted Mar 28, 2023 22:36 UTC (Tue) by dowdle (subscriber, #659) [Link] (5 responses)

As I wrote in a comment here when the announcement was first made, and I'm not Canonical fanboi... Red Hat nor Fedora ship with snap preinstalled so why should Ubuntu ship with Flatpak pre-installed? I'm not sure why they added it in the first place.

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.

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 1:18 UTC (Wed) by champtar (subscriber, #128673) [Link]

On Ubuntu you can end up with curl but the snap version, which has extra sandboxing. I don't remember the error, but trying to POST a file that was in a forbidden path was giving a cryptic message, and without strace I would have never found what was happening. Would be nice to have a message when the sandbox blocked some file access.

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 14:33 UTC (Wed) by jhoblitt (subscriber, #77733) [Link] (3 responses)

Fedora/RedHat will never embrace snap because it is tied to a closed source server controlled by a single vendor. That is neither in the interests of the community nor RedHat.

How to setup one's own flatpak repository?

Posted Mar 30, 2023 2:41 UTC (Thu) by dowdle (subscriber, #659) [Link] (2 responses)

I believe I read somewhere that Canonical did release the source to the snap server-side but that it wasn't current with the version they were running. I don't now if that disparity would hinder someone setting up their own snap repo or not.

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?

How to setup one's own flatpak repository?

Posted Mar 30, 2023 5:43 UTC (Thu) by zdzichu (subscriber, #17118) [Link]

https://docs.flatpak.org/en/latest/hosting-a-repository.html

How to setup one's own flatpak repository?

Posted Mar 30, 2023 14:54 UTC (Thu) by nedrichards (subscriber, #23295) [Link]

flatpak remote-add --if-not-exists elementary https://flatpak.elementary.io/repo.flatpakrepo

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.

Ubuntu stops shipping Flatpak by default

Posted Mar 28, 2023 22:39 UTC (Tue) by Nikratio (subscriber, #71966) [Link] (1 responses)

Hu? Isn't Launchpad still going strong?

Ubuntu stops shipping Flatpak by default

Posted Mar 28, 2023 23:41 UTC (Tue) by atnot (guest, #124910) [Link]

Launchpad may still exist, but the envisioned future where we would all be developing software using canonical's bazaar on canonical's hosted launchpad forge using all of their cloud development tooling solutions certainly doesn't. Even they themselved just host their important repositories on git(la|hu)b like everyone else.

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 1:24 UTC (Wed) by Paf (subscriber, #91811) [Link]

This is magnificent, thank you. I’m very glad Canonical is still around and making Ubuntu, I’m more than a little confused by why they think it will work this time.

Ubuntu stops shipping Flatpak by default

Posted Mar 28, 2023 20:38 UTC (Tue) by flussence (guest, #85566) [Link]

The whole existence of snap reminds me of the infamous incident of a Gnome developer going to an application's bug tracker and declaring they have to “choose between being a GNOME app, an Xfce app or a KDE app”.

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.

Technical difference?

Posted Mar 29, 2023 5:14 UTC (Wed) by eru (subscriber, #2753) [Link] (6 responses)

Apart from "political" considerations, what is the difference between Snap and Flatpak? My impression has been they do essentially the same thing, but are they really equivalent in capabilities and resource usage?

Technical difference?

Posted Mar 29, 2023 11:59 UTC (Wed) by atnot (guest, #124910) [Link] (4 responses)

In terms of user-facing features they are pretty comparable overall. But off of the top of my head:

Snap has:
- good support for cli programs and services

Flatpak has:
- 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?

Posted Mar 29, 2023 13:57 UTC (Wed) by Xiol (guest, #87394) [Link] (3 responses)

I'm not sure how true it is these days, but in the past snap didn't play nicely with SELinux either, whereas Flatpak does.

Technical difference?

Posted Mar 29, 2023 17:52 UTC (Wed) by ms_43 (subscriber, #99293) [Link] (2 responses)

Snap requires AppArmor to sandbox applications, which is incompatible with other LSMs such as SELinux; Linux supports only one LSM at a time.

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

Technical difference?

Posted Mar 30, 2023 9:51 UTC (Thu) by tajyrink (subscriber, #2750) [Link] (1 responses)

All snap packages I'm using on opens use Tumbleweed are working just fine, though. Including Chromium/Firefox.

Technical difference?

Posted Mar 31, 2023 8:04 UTC (Fri) by ms_43 (subscriber, #99293) [Link]

Well if the sandboxing doesn't work, you would only notice in case of a security vulnerability being exploited.

Technical difference?

Posted Apr 12, 2023 11:31 UTC (Wed) by emmi3 (subscriber, #62443) [Link]

- Flatpak can be used as an unprivileged user (or as root to install packages system wide).

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

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 5:32 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

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

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.

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 7:44 UTC (Wed) by jengelh (subscriber, #33263) [Link]

>Canonical is doing this largely to further its own interests

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

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 8:04 UTC (Wed) by cyperpunks (subscriber, #39406) [Link] (8 responses)

To me both snap and flatpak are useless, flatpak being removed just means less entropy and absent of useless stuff.

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.

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 13:22 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

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

Huh? Podman is not a fork of Docker and has pretty good compatibility with Docker including OCI images, the REST api and socket.

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 14:24 UTC (Wed) by dowdle (subscriber, #659) [Link]

You might find flatpak/snap/whatever useless, but for EL users... when the release is long in the tooth (it's supported for 10 years usually with the initial versions of things that the .0 release shipped with, except for backporting of security/bug and some features)... being able to get the latest and greatest desktop software is amazing. Sometimes you can get newer stuff via flatpak than the cutting edge distros are shipping... on an ancient EL release in deep in it's lifecycle... without endangering your environment/ecosystem... and without trying to compile everything yourself. That's value for goodness sakes.

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 15:18 UTC (Wed) by jhoblitt (subscriber, #77733) [Link]

Podman is not a fork of Docker. The architecture of the two applications is vastly different. RedHat did attempt to work upstream to resolve the security issues with dockerd before starting the Podman project. However, it is fair to say that Podman does make some use of Docker code: https://github.com/containers/podman/blob/main/go.mod

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 18:22 UTC (Wed) by jeffgus (guest, #59146) [Link] (3 responses)

When have you last run podman? You might want to try a more recent version. According to Dan Walsh, any incompatibility with Docker one finds in podman is considered a bug. He mentions this during his 2022 SCaLE presentation.

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.

Ubuntu stops shipping Flatpak by default

Posted Mar 30, 2023 11:21 UTC (Thu) by mbunkus (subscriber, #87248) [Link] (2 responses)

Last time I tried podman, which was probably a year ago, I ran into serious issues with two things others will likely consider niche topics: running foreign-architecture containers (e.g. i386 & arm64 on an amd64 host) & automatic assignment of IPv6 addresses. I'm not saying Docker's IPv6 support is great, but even in its not-so-great state it was still better than podman's, unfortunately. Don't remember if it was still in the 3.5 days of podman or 4.0 already.

Ubuntu stops shipping Flatpak by default

Posted Mar 30, 2023 14:25 UTC (Thu) by TomH (subscriber, #56149) [Link] (1 responses)

I just span up "podman run --rm -it fedora:rawhide" on a Fedora 37 host with no other special configuration and it got an fd00::/64 address that worked fine.

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.

container technology & IPv6

Posted Mar 30, 2023 14:42 UTC (Thu) by mbunkus (subscriber, #87248) [Link]

Thanks. Unfortunately I don't remember the exact problems I had. I _think_ it was related to exposing ports instead of a routing setup, as that works for both IPv4 & IPv6 in Docker (caveat: with experimental features turned on), and it only worked for IPv4 in podman as it didn't to NAT for IPv6. Sure, one can debate if this is actually a good use-case; fact is, this is the one case where I really like NAT for IPv6 as it unifies IPv4 & IPv6 handling & makes things very, very easy — no need for pushing routes to other hosts/routers, no need to worry about whether the app in the container listens on IPv6 (a lot don't, unfortunately, even if the container has an IPv6 address).

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

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 19:24 UTC (Wed) by vadim (guest, #35271) [Link]

Podman is a reimplementation, and does some very cool things like not requiring a daemon.

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.

Ubuntu stops shipping Flatpak by default

Posted Mar 29, 2023 19:19 UTC (Wed) by passthejoe (guest, #156034) [Link]

To provide context, Debian does not ship Flatpak by default. You are free to add Flatpak or Snap if you wish, but the default is regular DEB packages.

I'm not sure if RHEL ships Flatpak by default for its desktops.