Intel 32bit packages on Ubuntu from 19.10 onwards

[chanath]

Wine is to run Windows apps in Linux. If ppl wants/needs to run Windows apps, shouldn’t they run them in Windows?

I never used Wine, for one reason. I run Linux apps in Linux, and if I need to run a Windows app, such as Autocad, which cannot be run natively in Linux, I use Windows. Usually the laptops I bought always came with Windows, and I never throw away something I paid for. Wine, I think gives prominence to Windows apps and in a way advertises it.

Regarding all those 32bit Windows apps (games etc) that would still run on Windows would depend on Windows itself, not Linux, or even Wine. I don’t play games, so can’t say much about them, but I have a Windows 10 device that runs a 32 bit Windows 10. It, of course has a 64 bit processor. Now, this device has only System32, and as it is running the 32bit OS, that System32 has only 32bit software. In another device, which has the 64 bit Windows 10 has the system folder System32, which actually ha only 64 bit software, and there’s another system folder called SysWow64, which has only 32 bit software. The 32 bit OS device doesn’t have SysWow64 folder.

Now, one day, MS would say, end of support for 32bit software and even the 32bit Windows 10, just like it did with Windows RT. No one is going to create apps for Windows RT, would they? Like that, one day, all these 32bit app/games developers would have to start creating 64bit apps/games or lose business. That OS dictates the terms, doesn’t it.

I am keeping that 32bit Windows 10 device, just to see how long it would have support. No one is going to keep on supporting 32 bit devices and software.

[superian]

@chanath

If ppl wants/needs to run Windows apps, shouldn’t they run them in Windows?

Let them eat cake, you mean?

Even if you were offering to pay for the licences, telling people that they can no longer run (looks) about 4,800 programs with no problems and another 4,000 with some tweaking via WINE is unlikely to go well.

Especially as you can’t run some of them on Windows any more, because Microsoft removed stuff from it.

[warutel]

@vorlon

Because i386 would be treated as “legacy”, it would not get newer library versions. But since the vast majority of i386-only software is also legacy (closed-source, will never be rebuilt), it also does not generally benefit from newer libraries. Do you have something specific in mind?

Why? Updating the dependencies of proprietary software that will never be released again is very useful. It allows to remove security bugs, add hardware support, etc.

It is why SDL added that fancy “dynamic-dispatch-even-if-statically-linked” layer recently and why they ask developers not to static link to it or disable that layer, so that games can be kept working for a long time.

[fontman]

I’ve always (since 14.04) used the libraries mentioned in this link for a variety of Xerox printers, or 32-bit drivers: http://douglask.fog.org/home/xerox-phaser-6010n
They seem to work, so how does this discussion of specific printers impact these libraries?

[superian]

Looking at the mailing list where this was decided, I see that it was known over a year ago that “On the list of known blockers for removing the i386 port are Steam and Wine (sic).” (https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html)

So what actually happened in the past year?

Why is this apparently news to Steam and WINE?

[Mr_Swiv]

I read that thread about three months ago, and while removing i386 support was clearly mooted there, nothing appears to have been decided in that particular discussion. In fact, the thread ends in a question.

Some of the posters in that thread are also confused about what exactly it is that is proposed. Much of the talk is about hardware (supporting 32-bit CPUs), and at one point a poster asks what exactly it is that is being proposed.

[diogoconstantino]

Wine is to run Windows apps in Linux. If ppl wants/needs to run Windows apps, shouldn’t they run them in Windows?

I would rather not. All my personal computers run only Ubuntu. And if I needed to run one or a couple of windows applications I would rather run them on Ubuntu.

Windows licenses cost money, there’s something called the Ubuntu promise, which is that Ubuntu is and will always be for free. The reason behind it is that Ubuntu objective is to help people and not all have money for a windows license, and some more people may have the money but more important things to spend it on like medicine, education, etc…

Ubuntu is a liberation platform, its stated mission is to bring the best of Free Software to the people, however, that doesn’t mean that this is enough for everybody, sometimes, people still have to use some applications that are not Free Software and that sometimes are not even Linux applications. It may happen (it really does) that somewhere in the world States demand their citizens to use a windows application in order to take for of some mandatory bureaucracy. Going back again to human values behind Ubuntu, we can also read on the Code of Conduct, that we should be mindful of others, so we should also take the best of Free Software even to those that sometimes are forced to used windows applications, but that want for the most of the time just use Ubuntu and Free Software.

All this should also be seen within the realms of what is indeed practical or not. Some times they were practical for some time, and stop being after a while due to external changes and evolution.

[Wimpress]

@codemonkey

Note that this solution requires installing the proprietary NVidia libraries in the container. Will that still work when the next Ubuntu LTS ships with updated NVidia drivers, but you can still only install the old NVidia libraries in the 18.04 container?

In order to run Steam in LXD and maintain nvidia compatibility between the host and guest container, the container would need to bind mount the nvidia userspace drivers from the host.

[simosx]

Indeed, LXD has a nvidia.runtime key that does this for you.

I just wrote a blog post on running Steam and Wine on Ubuntu 19.10 (no 32-bit on the host), with an NVidia GPU.
I did not use nvidia.runtime in my case, just to make it a bit more explicit what is going on.

https://blog.simos.info/i-am-running-steam-wine-on-ubuntu-19-10-no-32-bit-on-the-host/

I should have shortly a fresh CS:GO screenshot from Steam running in a LXD container :-).

[RussianNeuroMancer]

@vorlon

If you’re aware of drivers other than Brother that are in this situation, please let us know what they are so we can assess those as well.

xalt7x and mikhailnov provided few examples.

@vorlon

We can and should make the 32-bit nvidia drivers available as part of the amd64 packages. These would then be exposed into the 32-bit containers, ensuring that the 32-bit userspace libraries matched the version of the kernel driver, regardless of what other library versions were available as packages within the container.

Good to know this is also covered.

@Syretia

First off, there is a pretty decent chunk of Ubuntu’s user base that will never use a snap ever. I know of quite a few users who instantly run sudo apt remove --autoremove --purge snapd and then sudo apt-mark hold snapd so that it is removed and never installed again on their installs.

By the way I do the same due to bunch of unresolved snap issues, such as application startup time and snap folder in home directory that looks like odd one, because other folders in home directory is localized, while this one is not and should not be there in first place (at least in my opinion).

[Syretia]

@simosx

Indeed, LXD has a nvidia.runtime key that does this for you.

I just wrote a blog post on running Steam and Wine on Ubuntu 19.10 (no 32-bit on the host), with an NVidia GPU.

I did not use nvidia.runtime in my case, just to make it a bit more explicit what is going on.

https://blog.simos.info/i-am-running-steam-wine-on-ubuntu-19-10-no-32-bit-on-the-host/

I should have shortly a fresh CS:GO screenshot from Steam running in a LXD container :-).

You’re using 18.04’s libraries there, though… what are you going to do when 18.04 is EOL? The repos you are getting those libraries from will no longer exist. The solution being offered here is a very temporary, band-aid solution at best.

[YamiYukiSenpai]

@Syretia

The solution being offered here is a very temporary, band-aid solution at best.

I agree with this, especially since even most Windows 64-bit software requires a 32-bit installer.

@jre-phoenix

Wine heavily relies on i386. Not only for legacy 32-bit software, but also “almost all” 64-bit software uses a 32-bit installer.[1] “It’s practically impossible to implement 32-bit on top of 64-bit”, so that you wouldn’t need i386 at all.[2]. So although Wine will still be available in the Ubuntu archive on amd64, it’ll be basically useless.

… and I don’t that method will stop (and not for a very long time). In addition, Windows on ARM only emulates 32-bit x86 software (don’t think it can emulate 64-bit right now), so 32-bit applications won’t be going away in a very long time.

[simosx]

@Syretia

You’re using 18.04’s libraries there, though… what are you going to do when 18.04 is EOL? The repos you are getting those libraries from will no longer exist. The solution being offered here is a very temporary, band-aid solution at best.

The desktop 18.04 will be EOL in 2023. The container image for 18.04 will be EOL after five extra years (in 2028).
Isn’t that enough?

[Syretia]

No. I still play games from 20 years ago. Some of my games will never stop being 32bit. There is no reason to stop me from playing them as long as we are using processors which can run them.

[hikaricore]

So in five years no one is going to want to run old applications which are literally never going to be recompiled for reasons too numerous to count? Doesn’t seem likely.

[Syretia]

Also, that would mean that, at best, in less than 9 years Steam is no longer usable on Ubuntu. Steam will most likely not stop selling 32bit games as long as we are using processors that support them which means they will continue to require 32bit libraries.

[simosx]

With LXD, you can run other operating systems as well, including Debian, Centos, Fedora, OpenSUSE, Devuan and more. 2028 is really a long time, but still you can run other distributions as well.

I suppose the computing power in 2028 will be more than enough to run easily proper virtual machines on anything for any i386 ISO image.

Are we really discussing concerns about the year 2028?

[Syretia]

That is not that far away, really. Rather than emulating distributions that have not chosen to take this route, I think I’d rather just switch to one of those and make my life more simple all around. All of these containers are much more of a headache to deal with than just switching to a distro that has no signs of dropping multilib support.

[simosx]

@Syretia

All of these containers are much more of a headache to deal with than just switching to a distro that has no signs of dropping multilib support.

I understand that there is need for some handholding to get to know about containers. I am writing posts about this.
Mixed 32-bit and 64-bit systems are messy. If you find such a distro, good for you. Note that it is increasingly too much work to maintain 32-bit Intel packages, even so watching for security updates.