Wine Developers Appear Quite Apprehensive About Ubuntu's Plans To Drop 32-Bit Support

[Nocifer]

It never ceases to amaze me how Ubuntu still manages not only to survive but also to still stay relevant enough to be able to keep busting the community's balls, despite it having lost most of its credibility and almost gone bankrupt after the fiasco with Mir. This should be a great opportunity for it to finally go the way of the proverbial dodo, at least as far as the real Linux community and users are concerned (MS keeping the company financially afloat in order to use them in their WSL agenda is an entirely different matter).

On topic; I guess Wine and gaming on Linux in general are irrelevant as far as WSL is concerned, hence the decision :P

Time to give wine a taste of their own medicine. Why should Ubuntu cater to a small edgecase?

So you're actually trying to say that gaming on Linux is a "small edge case"..? If you're trying to sound like a clueless oaf, I must say that you're doing an absolutely terrific job so far.

[Xaero_Vincent]

The software is shooting itself in the foot. It's like people complaining about Flash. You've had such a ridiculous amount of time to move content over but sat on your butt. The only one to blame is the authors of the software / content.

Except for the no longer supported games people might still want to play. I currently play some 32-bit games like GhostBusters : The Game. I don't use Ubuntu but feel it's shooting itself in the foot here. If Canonical needs some extra developer resources to maintain multilib, they should just drop their Mir project that nobody outside of Ubuntu cares about.

[cb88]

the people who refuse to drop 32bit support and move forward deserve to be left in the past with other dead projects

wine is a mistake, it makes people rely on buggy solutions rather than unite and offer sane environment for apps/games to prosper

macOS dropped 32bit LONG time ago, and it is doing MUCH MUCH MUCH better than what you are trying to achieve with linux OS's aka stay in the 80's with your anti UX/UI preferences

People that write bloatware that requires a 64bit 8 issue processor with 8 threads running at several GHz and it still be laggy... should be taken out back and forced to write assembler for about 4 years.

Seriously 99% of software an end user uses... on a daily basis could be done with a 16bit instruction set. Notable exceptions being Video but pretty much everything else is bloated beyond recognition. Someone did a study awhile back finding that office productivity had barely increased since the 80s when Macintosh's and Office were released.

[starshipeleven]

So you're actually trying to say that gaming on Linux is a "small edge case"..?

Are you saying it isn't?

[zanny]

Intel tried to abandon 32-bit x86 by introducing IA-64 - the attempt failed. History shows that backward compatibility is a decisive factor for both hardware and for software. Another example is PS5 that is going to be backward compatible with PS4.

Anyone who needs backwards compatibility is probably not running bleeding edge Ubuntu releases. 18.04 will be supported until 2023 at which point if you are still running x32 for some bizarre reason Debian will probably still be there to pivot to.

[Azrael5]

it would be useful to generate an algorithm able to recompile games in 64 bit.

[gurv]

Never thought I'd say this but... Debian XFCE, here I come!

[brad0]

Are you saying it isn't?

Kinda hard to say it isn't when Steam only measures the user base at roughly 1%. That's not exactly not s small edge case. To me it's the very definition of.

[shmerl]

Wine developers shouldn't waste effort on Ubuntu. Just drop support for it to begin with and recommend users to move to other distros.

And please, don't use Steam runtime! Work with upstream packages in distros which care to provide 32-bit multiarch.

Besides, Steam runtine won't help with lower level stuff like Mesa and such.

[BwackNinja]

Apparently, the apt tool is configured in such a way that versions of x86-32 libs and x86-64 libs have to match. But to solve that problem, shouldn't it be easier to just modify the apt? But, I'm not really sure about this point, perhaps someone who knows more about it would be able to clarify.

x86-32 and x86-64 libraries share architecture-independent data files, which may change incompatibly between versions.

The questions we should be asking are:

Who should be maintaining this infrastructure?
What is the best way to maintain this infrastructure?

In addition, people should be thinking about where the boundary lies between the operating system and the application. Snap, FlatPak and AppImage all make this distinction a bit clearer, but both sides here need to re-examine that. Ubuntu should provide 32-bit glibc and graphics drivers (and perhaps libstdc++), while the wine devs should think of wine as the sum of the rest of its dependencies and be comfortable packaging it as such.