Canonical Developer Tries Running GOG Games On 64-Bit-Only Ubuntu 19.10 Setup

[jacob]

Like Solus, Manjaro, hell, Fedora even these days. Debian is honestly not bad with like, SID, etc. Pop_OS! will almost certainly continue to be amazing for such. Fine with any of these becoming a flag carrier for Linux mindshare. Which like it or not Ubuntu has been, but forsee not being for much longer.

Hardly that. Debian is a cornerstone of the Linux community but it's not an end-user OS in the sense of Ubuntu. Fedora is ideal if you are a Linux developer, otherwise not that much. Manjaro and Solus are obscure stuff. The bottom line is that if someone can force the community to dump 32bit for good, it's Ubuntu and the real question is whether they shouldn't have done it at the start of a 2 years cycle (i.e. in 20.10) and announced it well in advance. But ultimately if it goes well the entire community will be better off for it, and if it doesn't, there will surely soon be some 32buntu derivative.

[jacob]

BTW what does this mean for downstream distros like Xubuntu or Mint? Do they actually have their own independent repos, where they could presumably keep i386 around, or do they rely on Ubuntu's archives?

[horizonbrave]

what about just switching game?
or going for a walk?
by the way:

https://wccftech.com/gog-financial-trouble/

[audir8]

If the hardware will run 32-bit code, and won't stop doing so anytime soon, I'm not sure it makes much sense to stop supporting it in software for a distro. We can just install dosbox and run 16 bit code, so doing something along those lines for 32 bit is a better option than just choosing to not do multilib. You could do no-multilib in Gentoo pretty much the day the first Opteron launched, and I bet if you asked people today, they either have a dual-boot with multilib or just a multilib system for desktop use (servers, which is what ubuntu is focusing on, can do without multilib). It's never been easier to run a 64-bit only system, but the need to run 32 bit software hasn't completely gone away, and never will. Flatpak and containers have their own issues, so I would much prefer any 32 bit libs to be ported or merged into a few packages or something.

[DanielG]

Assuming Canonical doesn't revert course or scale back their decision to offer at least the most popular 32-bit packages to remain, it could be pain in the short term particularly for gamers.

I think the pain will be on Ubuntus side when they realize their users just switch to other distros.

Also, I can imagine Linux Mint focussing more on their Debian-based flavours in the future..

[angrypie]

Did he drop 32-bit libraries and expected 32-bit software to work? I checked the link twice because I thought I hit The Onion by mistake.

[DanielG]

HAHA, Steam is dropping Ubuntu support: https://twitter.com/Plagman2/status/1142262103106973698

[Kano]

Basically I can understand to drop 32 bit ISO images as long as a 32 bit EFI loader is included in the 64 bit one. But dropping 32 bit packages completely is ridiculous. Ubuntu lib packages are Debian based and tested there already. Also even if you could use a 32 bit user land via 3rd party lib package (like from Steam) usually you want to use mesa or even Nvidia binary drivers in the same version (little differences might work with mesa but not for Nvidia). If they remove most 32 bit apps but keep at least the commonly used 32 bit libs I would say this is okay, but otherwise Ubuntu 19.10 will be the end of the hype.

[the_scx]

A solution is to install Flatpak.

How many times I have to tell that Flatpak is not a solution here? It is just not suitable for everything.

https://github.com/flathub/flathub/pull/486#issuecomment-405826821

To expand on what TingPing said, Steam at least provides some common runtime that publishers/developers can base on, and even if that in mind, it doesn't really work. Just go through issues reported on Flathub's Steam repository – many games are broken because of dependence on external libraries or applications that are not correctly shipped. GameHub doesn't provide even that and it's impractical to add every missing dependency to Flatpak application itself.

GOG clearly states on their website that only Ubuntu is supported and even the release differs between particular games. Humble Bundle is even more trigger happy and I had even less luck with few games I bought there. Not to mention that some are 32-bit only, making it even harder to make everything work. All this results in bad user experience, especially for players with no technical Linux background and I can't see Gamehub being any different.

(On a side note, we are also considering removing Steam.)

Flatpak isn't a replacement for standard packages and never will be. There are too many cases where it just doesn't work well. And believe me, I know what I am talking about. I've created dozens of flatpak packages. Some of them are published on Flathub.

It should be possible to create a flatpak package for a game manager that supports GOG, and include Steam Runtime in it. I believe that it would help running most Unity-based games and maybe even some others, but definitely not all of them.
For example, the Epic Games documentation states that UE4 compiled for Ubuntu may be incompatible with UE4 compiled for CentOS (and vice versa). That's why game developers love Steam when it comes to publishing games on Linux. All they have to do is just to build game against Steam Runtime, and then it will work on (almost) every Linux distribution. It isn't the case when it comes to GOG. They state that Ubuntu is the only supported distro, so many developers cares only about this one. There is no enforcement to use Steam Runtime here, nor developers try to do this on their own. That's why running GOG games under Steam Runtime will not always be successful.
BTW: There is a reason why this list is so huge: https://web.archive.org/web/20180607...portselsewhere
Anyway, it will be a half-working solution. Probably much better than running an another Linux distribution in VM or using hangover, but still a partially-working workaround, rather than a complete solution.
And when it comes to Humble Bundle DRM-Free games, the situation would be even worse. Honestly, it will be a disaster.

[the_scx]

The consequences will be: even more market share for Ubuntu. Because they're not scared to lead, and indeed, as you might not have realised, with this move they're getting more press coverage than any other distribution could possibly hope for.

Just like people loved Windows RT, which got rid of Win32 applications and offered Modern Apps!

I guarantee you the vast majority of people are looking at this and going "a) I been 64 bit for at least 5 years if not 10, b) you mean to tell me there's still 32 bit shite around? Get rid of it already. Well done Ubuntu!"

I think that we should just abandon Linux support on bare metal. It is an ancient system, with kernel written in C (Rust FTW!) and based on UNIX from 1969 (not by source code, but by philosophy). If you have to run some legacy POSIX applications, you can do this on WSL under Windows 10. In long term, everyone should switch to Windows Lite based on WCOS (Windows Core OS). Modern UWP and PWA apps are all you need! We should get rid of this POSIX crap, and the sooner the better!
Insane? Of course! But no more insane than what you are suggesting here.
Microsoft tried to sell Windows RT without Win32 support and they failed. That's why they put a lot of effort into providing support for transparent x86 emulation in Windows 10 on ARM. They know that without it they have absolutely no chance in this market.

Oh, and one more thing. If you think that 32-bit support is just about some legacy software, you are wrong.

When Windows began targeting 64-bit architectures, Microsoft decided to include a compatibility layer to support their massive universe of 32-bit applications. This kind of subcomponent, nicknamed WoW64 (for Windows on Windows 64-bit), is also implemented in Wine to solve the exact same problem.
64-bit Wine built without 32-bit support will not be able to run ANY 32-bit applications, which most Windows binaries are. Even many 64-bit programs still include 32-bit components!

Many 64-bit applications still use either a 32-bit installer or some 32-bit components. In comparison 64-bit Windows will support 32-bit (probably) forever.

Make that almost all applications. It's very unusual for a program to have a 64-bit installer, because it won't be able to control what happens when a user runs the installer on 32-bit Windows.

In practice, the only cases where 64-bit only wine will be useful are when 64-bit applications are packaged some other way (such as a .zip, Steam Play, or packaging specifically for Wine) or for running Wine builtins like msidb.

Nor do I see much point in packaging a 64-bit-only Wine on our end. It's such a niche case for 64-bit-only Wine to be useful at all.