The news that Ubuntu will drop support for the 32-bit x86 architecture was discussed recently by the Wine developers, on the Wine-devel mailing list. The Wine developers are concerned with this news because many 64-bit Windows applications still use a 32-bit installer, or some 32-bit components.
That’s an interesting side-effect of going 64 bit-only that I hadn’t even considered. This can be a serious blow to Ubuntu users who use Wine, but I do wonder just how popular Wine really is.
Thom Holwerda,
I hadn’t even thought of that either. When ubuntu said it would drop 32bit, I understood that to mean it would drop it’s 32bit libraries and app repos, but it’s not immediately clear that Ubuntu would go so far as to disable 32bit support from the kernel itself? If 32bit processes and interfaces are still supported by the kernel, then wine could link statically and build it’s own dependencies, it’s just more work for them that they didn’t previously have to do.
If at some point 32bit processes were to be completely disabled in ubuntu’s linux kernel, then 32bit wine technology on linux becomes nonviable. Wine, who’s official moto is “Wine Is Not an Emulator”, would have to incorporate emulatation in order to continue existing going forward. Something akin to DOSBox and DOSEmu, or better yet run windows apps inside of virtualization/QEMU. Seems feasible, but requires new engineering.
I think the kernel will still have 32bit support, pretty sure you can’t rip that out, but it sounds like they want to disable 32bit library support, which will kill Wine, PCSX2, some NES and Genesis emulators, not to mention a WHOLE lot of binary only games on Steam. Well, and Steam. Pretty much anything in their repo that is packaged as package:i386.
If you wonder how popular wine is, it’s REALLY popular. Tons of things use it, and for a lot of people it bridges that layer they need between getting away from Windows, and allowing them to still enjoy their software library.
leech,
You are right that a lot of apps depend on it, but it comes down to who is willing to pay the costs of maintaining it if Canonical will not?
https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040348.html
A post on wine’s mailing list suggests that they might be able to piggyback off of steam’s work.
https://www.winehq.org/pipermail/wine-devel/2019-June/147898.html
Linux kernel includes a flag to build without 32 bit syscalls. So it possible to build 64 bit only at this stage Ubuntu does not sound like they are going todo that.
https://github.com/AndreRH/hangover
Wine project does have the option of the hangover route. This route you only need 64 bit host librarys and syscalls. But hangover still needs a lot more work.
When you have flatpak, snap, steam as run-time providing options if distributions need to provide 32 bit run-time directly any more is a good question.
Remember steam is not a problem as long as they don’t kill the 32 bit syscall in kernel and Nvidia keeps on providing 32 library support. Only change is with 19.10 ubuntu you know install steam by flathub.
https://flathub.org/apps/details/com.valvesoftware.Steam
Yes the flathub 32bit runtime provides enough to turn the Steam over and it games. Yes proton works inside flatpak package.
PCSX2 is also in flathub. You will find quite a lot that will be broken by 32 support being dropped 19.10 will be support by the flatpak runtimes and be able to be got from flathub. As long as Ubuntu does not kill the 32bit syscall support this will still be ok.
This is part of the reason I haven’t dropped support for i386 in MidnightBSD yet. 32bit wine is needed to run 32bit windows apps and needs to be build on a 32bit OS.
This may also impact other apps such as multimedia streaming, plugins for things, etc.
https://github.com/AndreRH/hangover
I bet your position would be different if hangover was more complete and more functional. So there is path forwards for 32 bit windows support from a vm/container using hangover thunking with the host not providing any 32 bit libraries. Of course this requires resources to complete.
Of course this leaves the true native Linux 32 bit programs problem. Over all those are not that large of a problem.
At lot of examples here to use as evidence that desktop Linux is terrible for 3rd party software support. The most popular distro just abandoning the support needed for one of the most popular pieces of Linux software, a privately funded effort being used to bridge the gap, etc. This is a very big reason people try Linux for a few weeks and then go back. There is no guarantee anything will work, or that it won’t be intentionally broken by the higher ups.
Linux is a changing place. With value steam runtime and flatpak and snap and containers and vm…. There is big questions if Ubuntu mainline distribution really does need to support 32 bit runtime.
Wine also has hangover in prototype. Without shove this is not going to develop either.
Genuinely not sure here, docs seem a bit ambiguous – does Wine Hangover provide just the Win64 implementation or is it Win64 + WoW32?
>Wine Hangover provide just the Win64 implementation or is it Win64 + WoW32?
It is a little bit brain bending.
You have a win64 native wine. Then inside the native Win64 wine you are running qemu based hangover at this stage and inside there you can run Win32/Win64 applications. It kind of a complex mess as expected from a prototype testing out what can and cannot be done. https://github.com/AndreRH/hangover the details are all here is with work win16 could be supported as well.
Using qemu TCG engine does not equal fast and this is because hangover as designed targeting android problem where running x86 binaries directly was impossible so no KVM option. Hangover lays down a possible path. Exploring completing and optimizing it is a whole stack of work.
Steam still needs 32-bit multilib support though to run most games on Linux that don’t have native ports.
Also, Valve has said they will officially not support Ubuntu 19.10 or any other newer version that does not have 32-bit multilib support going forwards (search ‘steam not supporting ubuntu 19.10’ on Google if you want exact details)).
So how is this different than what Apple is doing? I had messages yesterday about Inkscape and Scribus not being optimised for my Mac and won’t be supported after September. I know Inskcape 1.0 beta should fix this. But still, I have a few apps that I just abandoned in favour of others that worked because the third party stopped maintaining them and didn’t make them 64bit, even after I’d paid for them.
This isn’t just a Linux is terrible thing. It’s a real issue for computer users period.
earlycj5,
I agree with this, it’s far from just a linux problem. And IMHO it’s kind of unfair to criticize linux desktops for not being compatible with non-linux software, we really ought to blame the vendors for not supporting linux in the first place!
For their part, commercial vendors aren’t interested in linux desktops because that’s not where they find profitable users. And regarding their 32bit windows software, a lot of times there just isn’t much benefit in switching to 64bit whether it’s a commercial product or not. It’s an added cost that sometimes brings no benefits, so why do it? Supporting legacy ISAs might be a hassle on microsoft’s part, but considering the vendor locking potential they’d be throwing away if microsoft dropped support for these legacy apps, then it’s probably worthwhile to keep it around. Just think of all the customers microsoft stands to loose if users and developers were motivated to look at more portable options.
“we really ought to blame the vendors for not supporting linux in the first place!”
This is definitely a chicken and egg argument you’ve got going. Linux randomly drops support for all 32 bit apps, has terrible support for 3rd parties, and breaks things at will like this all the time; but we should push back on the vendors for not providing software for such an OS. This is why Windows will remain king for the foreseeable future; Microsoft continues to do great work making sure most ancient software, even 32 bit, still works fine over 10 years after it was published. How can you expect vendors to support something that has little to no support for 3rd party software? Linux software support is constantly in a state of “It’s our way or the highway” and the vendors have a great highway to work with.
dark2,
Vendors who support linux would have switched to 64bit back in 2005-2010. Any software that you’ve compiled on linux in the last decade will build as 64bit by default. Seriously, as a developer you’d be going out of your way to explicitly build 32bit linux software.
This dependency on 32bit does not stem from linux native software, but software built for other platforms running on linux (through wine & steam). You can criticize ubuntu for dropping 32bit, but it’s stretching quite a bit to insist this is such a problem for native linux software in the first place. The problem is that commercial software vendors are not writing native linux apps, only windows ones (and increasingly mobile ones). While I’m grateful for wine’s capabilities, it doesn’t always work that well and IMHO it’s not good to rely on it over having native linux software.
On linux I’d say the userspace ABI is very stable. The real source of software incompatibilities comes down to dynamically linked shared programming libraries. The most common libraries like stdc will generally be stable, but admittedly many libraries (ie things like like ffmpeg) can/do change and break out-of-repo software. This is frustrating, but it’s not dissimilar to DLL hell, which is something I still deal with on windows (ie your software was built with a different version of this or that, you get some damned frustrating DLL errors, and you have to go hunt down the correct one from some shady website).
The library dependency issue is a tough nut to crack because there’s a tradeoff between stability versus evolutionary enhancements. Some software on windows (ie the gimp) solves this by installing it’s own shared library dependencies, which means you’ll always have compatible library versions, but it rather defeats the advantages of using “shared libraries” if all applications use their own individual copies. Still, it does technically solve the problem on both windows and linux.
From the developer’s perspective, we actually do see new issues with new windows releases. Ideally we’ll fix the bugs on a windows pre-release before the public mainstream rollout. One of the reasons you don’t see more issues is because you’re using an officially supported combination rather than anything intrinsic about the platform. If you ever come across old neglected windows software (like off sourceforge), there can be new problems & bugs that didn’t happen on earlier versions of windows. The chances are best with software that uses few exotic dependencies.
I think your complaints are legit, though a bit misdirected and you’re trying very hard to blame linux for the lack of support which isn’t entirely it’s fault. I agree with you that “our way or the highway” attitudes are a put off and I can see how some leaders of the linux community are guilty of this. However I think the criticism is ironic coming from the windows side of the fence where microsoft often forces users to do things it’s way even amid much criticism such as when they forced the metro GUI, force updates, forced user telemetry, etc. If you want to criticize linux for it, then it would make sense to also critisize windows for it as well.
I guess, the solution is pretty simple: Use pure Debian instead of Ubuntu. It was Debian who introduced multiarch support years ago, and Debian is unlikely to drop it any time soon.
Without 32 bit support, WINE is pretty much useless, because so many legacy Windows applications are 32bit only.
Or just use the Debian 32-bit libraries with Ubuntu. Using Debian packages with Ubuntu has worked fine since the beginning. If it isn’t in the Ubuntu repos, you use the debian repo instead. So unless they disable 32-bit syscalls in the kernel, pulling the 32-bit libs from debian should work.
Preventing Wine from installing on Ubuntu would, also, I assume, prevent Ubuntu users from running Crossover Office as well. Heck, what would this mean for Linux Mint — time to hit the LMDE escape pod??? What in the heck is the point of this? For me, this would kill ever considering Ubuntu for my regular distro as one of the first things I do is install Wine and several Windows apps.
another side effect is steam – and valve is dropping ubuntu support entirely rather than deal with this mess
As much as I’m not a gamer, I glad to see that Steam is willing to demostrate to the losers who insist on killing off 32 bit support in distros that there are going to be real-world results they’re not going to like to this stupidity.
.
It won’t just stop Wine, old games released for Linux in 32bit also will no longer be able to launch. I have a number of those.
If you think Wine is the only 32bit application in Linux, you’re gravely mistaken.
>> If you think Wine is the only 32bit application in Linux, you’re gravely mistaken.
True but there is problem the Linux kernel 32 bit syscalls have the 2038 bug. So every one of those 32 bit Linux applications have known year of I am busted.
x32 ABI was made for applications that there was advantages to 32 bit pointers yet to have 64 bit time value so no 2038 problem. Intel worked on gcc and llvm to the point that there is no real performance advantage using x32 ABI or 32 bit old school linux binaries.
Is there any way around that 32 bit Linux syscall time issue yes. Here is the big but. It will require all 32 bit applications in containers so that a time domain that is not real time can be set-up. Now this gets worse that not real time domain cannot be used by anything communicating over the internet that using encryption. So steam client by 2038 has to be ported to 64 bit.
Yes protective proxys will need to be done around applications still using 32 bit by 2038.
“Is there any way around that 32 bit Linux syscall time issue yes. Here is the big but. It will require all 32 bit applications in containers so that a time domain that is not real time can be set-up. Now this gets worse that not real time domain cannot be used by anything communicating over the internet that using encryption. So steam client by 2038 has to be ported to 64 bit.
Yes protective proxys will need to be done around applications still using 32 bit by 2038.”
Oh,dear God, it’s Y2K all over again………….
If linux wants to be competitive on the desktop it needs to be brave enough to drop support.
Most of these 32bit apps only run on Windows 10 through an emulation layer, and the manufacturer Never supported running through WINE (despite all the claims, a fiddly and buggy experience) Yet, linux distros seem to be expected to continue to support them regardless. If linux on the desktop is ever going to take off, it needs it’s own apps. To my mind snap/flatpack are the future direction, they just need to become quicker…
> If linux wants to be competitive on the desktop it needs to be brave enough to drop support.
An OS without backward compatibility is worth nothing and Linux on the desktop is exactly where it should be: nowhere.
>An OS without backward compatibility is worth nothing and Linux on the desktop is exactly where it should be: nowhere.
Has Ubuntu 19.10 in fact removed backwards compatibility the answer is no. Altered how you have todo it. Ubuntu people would most likely be recommending making a snap package out the application using 18.04 as base and installing it that way. So you can still run the old applications.
Really you need to understand Linux backwards compatibility starts with chroots, then moves to virtual machines then moves to containers.
So its dropped support for 32 bit applications in the host distribution. I have looked at the 19.10 kernel it still has the 32 bit syscalls so it still supports 32 bit in container based guests this covers docker, flatpak, snap and so on. So steam will still run on 19.10 without valve support. Wine in a flatpak or snap is quite messy but as those making winepak stuff show it possible.
Of course there’s going to be outrage over this, people are scared of change and short-term growing pains. And once it’s all over with and everything is updated/back to normal, they’ll show little appreciation for it.
Apparently Ubuntu devs hadn’t thought well enough ahead on this thing before announcing dropping 32-bit support:
“Canonical Developer Tries Running GOG Games On 64-Bit-Only Ubuntu 19.10 Setup”
https://phoronix.com/scan.php?page=news_item&px=Trying-GOG-Games-64-bit-Ubuntu
making stupid decisions without giving much thought to the consequences is a longtime tradition for ubuntu