Canonical Formulates The 32-Bit Support Strategy For Ubuntu 20.04 LTS

[starshipeleven]

Canonical doesn't need to support anything.

Canonical isn't supporting shit either way, they are simply repacking Debian just like Devuan does.

It is a matter of control and user lock-in. Canonical is not going to use a generic system you can replicate everywhere with ease (the Flatpak route).

[Britoid]

Ubuntu supports Flatpak perfectly well. People always seem to believe that flatpak and snap are competing like deb/rpm. They're not, both work happily across many distros and you can install both flatpaks and snaps at the same time with no problem whatsoever. On my Ubuntu 19.10 I have a number of snaps installed, I also have Steam and other things from flathub and it all Just Works.

My point is that Canonical will never ship with Flatpak because it's not theirs.

Afaik Flatpak isn't even in their main repositories, it's in universe.

[royce]

Canonical have no incentive to support flatpak in Ubuntu because they have snap. In the same way fedora don't do the likewise as they already have flatpak. All distros can easily run both. Both solutions are equally open source. At this point, the differences between them are purely technical.

[Britoid]

Canonical have no incentive to support flatpak in Ubuntu because they have snap. In the same way fedora don't do the likewise as they already have flatpak. All distros can easily run both. Both solutions are equally open source. At this point, the differences between them are purely technical.

Sorry, that's rubbish.

The Snap server is closed-source and Canonical has said this is never going to change (or at least it's not the plan). Additionally, the protocol in which it connects to the Snap server is always changing, making building an alternative Snap server extremely hard. This is in addition to the Snapstore API endpoint being hardcoded in the Snap code, meaning changing to an alternative open-source remote requires rebuilding the thing, Canonical have also said this is done on purpose because they only want one Snap store (similar to how with Launchpad they were agaisnt alternative instances, despite being open source).

Flatpak is not controlled by any one distro and is truly owned by the FOSS community (no CLA). Yes Fedora uses it and some Fedora-developers are also Flatpak-developers, but there's also developers from Endless, Debian, GNOME, Arch, Apache etc. The Flatpak binary itself also has the ability to generate remotes (repos). Flatpak also doesn't require a daemon with root prievlidges running that connects by its own authentication system rather than using Polkit.

All distros do not run Snap easily for example Snap does not run at all on Gentoo, Alpine, Void, Fedora Silverblue, ChromeOS, NixOS, Clear Linux and Endless OS.

[CochainComplex]

Steam not having a 64-bit Linux client is ridiculous. If you use something like CUDA on Ubuntu, it provides (and depends on) the required NV driver in the CUDA repo, but not the 32 bit libs to support 32-bit apps like Steam. And then you can try to install the 32-bit libs on your own, but oh no, they depend on the Ubuntu NV driver, which in turn conflicts with the CUDA NV driver, so it removes the CUDA NV driver, but since CUDA itself depends on the CUDA NV driver, this action removes CUDA as well.

What a bunch of fools. How hard can it be to have a 64-bit client with a warning that it'll only run 64-bit games? Or if they aren't cocky enough to do this, how about compile and bundle the 32-bit packages on their own? Why on Earth is it Ubuntu's responsibility to cover Valve's lazy and/or incompetent arse? All this cr@p should've gone into a self-contained steam snap long ago.

Suffering from the same issues ...it simply sucks

[CochainComplex]

Sorry, that's rubbish.

The Snap server is closed-source and Canonical has said this is never going to change (or at least it's not the plan). Additionally, the protocol in which it connects to the Snap server is always changing, making building an alternative Snap server extremely hard. This is in addition to the Snapstore API endpoint being hardcoded in the Snap code, meaning changing to an alternative open-source remote requires rebuilding the thing, Canonical have also said this is done on purpose because they only want one Snap store (similar to how with Launchpad they were agaisnt alternative instances, despite being open source).

Flatpak is not controlled by any one distro and is truly owned by the FOSS community (no CLA). Yes Fedora uses it and some Fedora-developers are also Flatpak-developers, but there's also developers from Endless, Debian, GNOME, Arch, Apache etc. The Flatpak binary itself also has the ability to generate remotes (repos). Flatpak also doesn't require a daemon with root prievlidges running that connects by its own authentication system rather than using Polkit.

All distros do not run Snap easily for example Snap does not run at all on Gentoo, Alpine, Void, Fedora Silverblue, ChromeOS, NixOS, Clear Linux and Endless OS.

I always prefer Flatpak over Snap....it seems Canoncial tries once again to pull their own thing....like unity...like mir ....well lets see maybe flatpak will be default 24.04 ?

[anarki2]

Steam on Linux is mostly 64-bit. It only requires 32-bit dependencies so that users have to install them while installing Steam instead of finding out that game X won't run and wondering why.

Regardless, Valve are moving towards a 64-bit only world, with a recent beta having added a Flatpak style containerization option to run the 32-bit games in... or even all of them, for sandboxing purposes. https://steamcommunity.com/app/22141...5549018366706/

It doesn't matter if it's "mostly" 64 bit if, to this day, it breaks without 32 bit libs. Something either works or doesn't work, and Steam is in the latter group so far.

[Charlie68]

I always prefer Flatpak over Snap....it seems Canoncial tries once again to pull their own thing....like unity...like mir ....well lets see maybe flatpak will be default 24.04 ?

I also prefer Flatpak for various reasons ... on openSUSE which is my distribution Flatpak can be used easily, enabling support in Discover (Plasma) or Software (Gnome), while for Snap it is necessary to add a repository and not have sandboxes. Snap lengthens startup time, my girlfriend uses Ubuntu and with the latest versions she noticed that Snap slows down a lot of booting, it's not a case that she's thinking about switching to openSUSE too.

[jo-erlend]

Wine has a Windows Version dropdown that can be set on a per-EXE basis.

Per prefix, not per exe.

[jo-erlend]

not what I mean, that is still a generic API.

I mean Wine being designed with a core functionality that expects to be customized and hacked to best support each application in a quick and simpler (and dirty) way than "the proper way" that will never happen as you pointed out.

That's how Wine works. You create one Wine prefix per application you want to run and then you customize each prefix. Others can build on thiş to support specific applications. Crossover and PlayonLinux are two examples of this, but there are more. In other words, the core functionality is the uncustomized wine prefix that expects to be customized on a per-application basis.