UPDATE: Ubuntu NOT Dropping 32-bit App Support After All

[Video Beagle]

9 hours ago, Humbug said:

Valve already has 64 bit steam client for Mac OSX. It's only a matter of time until it comes to windows and Linux. That was never the problem.

 

The problem is there are thousands of old 32 bit games on steam which nobody is going to recompile. Valve has to maintain compatibility.

 

Do they? My Mac Steam is still 32bit and just updated this week.

[IAmAndre]

11 hours ago, Doobeedoo said:

Hm yeah I wonder what Valve will do in future considering they want to stay away from Windows in general. 

Ubuntu doesn't mean Linux. There are other Linux distribution.

[leadeater]

3 hours ago, Jito463 said:

As someone who's been running various 64-bit OS's since 2005 (starting with XP x64 edition), 32-bit drivers haven't been a concern of mine for some time now, save for the occasional computer I work on that needs them.  Is it really so different on the Linux side?  I didn't think it was possible to run 32-bit drivers in a 64-bit OS.

32bit applications and drivers are, at least in Windows, totally different things. You don't need 32bit drivers for 32bit applications on 64bit OS, Windows does 32bit to 64bit translations in the Kernel and I see no reason Linux cannot and isn't doing the same.

 

The only time that sort of thing matters is when there is a misuse of the name 'driver' like for ODBC connections in Windows where there is a 32bit and a 64bit ODBC driver, which is not technically a driver.

 

You will in 19.10 be able to install any previous working libraries and packages that are 32bit and they will function exactly as they did before, you can as Canonical has stated use existing 18.10 built packages on 19.10 and they will function. This was one of the suggested options that was explained in one of the mail threads and I believe there is a chance that these will just work in 19.10 without manual configuration, i.e. If not in 19.10 look in 18.10.

 

Doesn't at all sound as bad as it's been made out to be, though the information release wasn't clear enough which is the cause of that.

[Trixanity]

4 hours ago, Video Beagle said:

 

Do they? My Mac Steam is still 32bit and just updated this week.

Yeah, it seems that the client doesn't update to 64 bit on its own. I got tired of the warning message so I removed it entirely and got the latest client from the website. The warnings stopped so it should be 64 bit. It might also be possible to install it over the existing client but I didn't test it.

[Chunchunmaru_]

4 hours ago, leadeater said:

32bit applications and drivers are, at least in Windows, totally different things. You don't need 32bit drivers for 32bit applications on 64bit OS, Windows does 32bit to 64bit translations in the Kernel and I see no reason Linux cannot and isn't doing the same.

I have no knowledge on Windows architecture, but when I mentioned drivers in Linux pretty much I was referring to userspace, which is required to interface with the kernel, the kernel drivers are always 64bit, I think Windows userspace driver libraries are shipped with the graphics installers already?? or use a different architecture

[leadeater]

18 minutes ago, Chunchunmaru_ said:

I have no knowledge on Windows architecture, but when I mentioned drivers in Linux pretty much I was referring to userspace, which is required to interface with the kernel, the kernel drivers are always 64bit, I think Windows userspace driver libraries are shipped with the graphics installers already?? or use a different architecture

Userspace doesn't change it, if you have to interface with hardware the Kernel is doing 32bit to 64bit translations and Linux should be able to do this as well. Windows also has the concept of userspace and kernel mode as well, has for ages. Things like graphics drivers are kernel mode in Windows.

 

So it should make next to no difference that 19.10 ships with no 32bit libraries on the hardware side of things. For the software stack you will need to satisfy any dependencies which you can easily do and at worst dev need to update their dependency targeting to specific architecture so the correct repo and package is queried.

 

sudo apt install libgl1-mesa-glx libgl1-mesa-glx:i386

This (in theory) will pull the 64bit package from 19.10 repo and the 32bit package from the 18.10 repo. At worst you'll have to add the 18.10 repo to your apt sources list.

 

Edit:

You can also add a repo source for only i386 architecture so you won't pull stuff from 18.10 that you shouldn't on 19.10. 

[Chunchunmaru_]

8 minutes ago, leadeater said:

Userspace doesn't change it, if you have to interface with hardware the Kernel is doing 32bit to 64bit translations and Linux should be able to do this as well. Windows also has the concept of userspace and kernel mode as well, has for ages. Things like graphics drivers are kernel mode in Windows.

 

So it should make next to no difference that 19.10 ships with no 32bit libraries on the hardware side of things. For the software stack you will need to satisfy any dependencies which you can easily do and at worst dev need to update their dependency targeting to specific architecture so the correct repo and package is queried.

 

sudo apt install libgl1-mesa-glx libgl1-mesa-glx:i386

This (in theory) will pull the 64bit package from 19.10 repo and the 32bit package from the 18.10 repo. At worst you'll have to add the 18.10 repo to your apt sources list.

Yes pretty much it, that's for OpenGL but only for Mesa drivers(AMD, intel and Nouveau) if you use the Nvidia proprietary drivers it's completely different, since now it's always been a system "responsibility" since it could easily switch between opengl implementations, with update-alternatives, now unless you add complexity in the game/program executable which isn't properly "right" you can pretty much archive the same thing, but as I previously mentioned it's not even 100% that it wouldn't break mixing such different libraries versions for 32bit and 64 especially for Nvidia, and needs a specific effort or support

[leadeater]

8 minutes ago, Chunchunmaru_ said:

Yes pretty much it, that's for OpenGL but only for Mesa drivers(AMD, intel and Nouveau) if you use the Nvidia proprietary drivers it's completely different, since now it's always been a system "responsibility" since it could easily switch between opengl implementations, with update-alternatives, now unless you add complexity in the game/program executable which isn't properly "right" you can pretty much archive the same thing, but as I previously mentioned it's not even 100% that it wouldn't break mixing such different libraries versions for 32bit and 64 especially for Nvidia 

If you have a repo source on your system set to look at 18.10 for i386 literally nothing will change, all dependencies will be found and install just as before. The only real difference is will 19.10 do this by default or do we have to add it.

 

Edit:

deb [i386] http://archive.ubuntu.com/ubuntu/ cosmic main

Add or check for that after your OS install then treat as normal, shouldn't be any difference beyond that other than having to initially install WAY more 32bit packages that aren't installed by default to satisfy what ever you are trying to install.

[Chunchunmaru_]

2 hours ago, leadeater said:

If you have a repo source on your system set to look at 18.10 for i386 literally nothing will change, all dependencies will be found and install just as before. The only real difference is will 19.10 do this by default or do we have to add it.

 

Edit:

deb [i386] http://archive.ubuntu.com/ubuntu/ cosmic main

Add or check for that after your OS install then treat as normal, shouldn't be any difference beyond that other than having to initially install WAY more 32bit packages that aren't installed by default to satisfy what ever you are trying to install.

Yeah I know how to do that, btw the LTS is bionic and not cosmic, they said they will froze to 18.04, and other than main there are other "subrepositories" like universe,multiverse which include more software (even though have most of the time their 64bit counterpart, except for system libraries and wine) 

Wine developers however disagree with doing this at all similar to what I said in those 3 threads, and I personally disagree leaving unupdated libraries which can be a security hole, but also for performance and future games support

Wine developers cit.
 

Quote

The suggestion from Ubuntu is to use the 32 bit libraries from 18.04, which will be supported until 2023. It's theoretically possible for me to build the 32 bit side on the OBS using the libraries from 18.04, but that would lead to a mismatch in library versions the 32 and 64 bit sides were built against.

Apt requires the i386 and amd64 versions of packages match or it will refuse to install them, so unless that changes, users of 19.10 and up will be unable to install the 32 bit libraries they need to run Wine, unless they downgrade a significant part of their system to the 18.04 versions.

Also I have seen rumors like System76 PopOS developers are going to maintain i386 by themselves, but I yet have to confirm it by myself

I will also set up a test environment, I'm just curious to see what will happen

Also TLG/TheLinuxGamer made an interesting video on all of this... I don't think I'm supposed to post it here?

[Ashleyyyy]

16 hours ago, DrMacintosh said:

How is it not ideal? Why should 32Bit libraries be updated? It would only encourage development of more 32Bit apps which is simply unacceptable in 2019.  

why? loads of things still run on 32-bit, mainly old machines that still work fine for some tasks. 

 

also low end hardware. there is no reason to run a 64-bit OS on a machine with 4gb ram or less. 

[Chunchunmaru_]

So... Some updates, I set up an Ubuntu Eoan build with i386 LTS repositories and...
Pretty much as I expected, apt doesn't let you mix different 32bit and 64 bit libraries at this current state, to fix this, that will require a rebuild and manually intervention for ALL ubuntu packages with i386 dependencies, because at this current state it will look for a minimum library version (the same as 64bit ones) as Wine developers said.

I don't even know if it is going to work at all honestly even if you put those libraries manually without APT complaining (I will try that definitely)

So far, it would be hard to canonical to address this rather then just leaving basic i386 support in my opinion...

The i386 Steam requirements for Linux that it complains about are:

C Library

C++ Library

X11 library

udev library

xinerama (another X library)
OpenGL Implementation (DRI, GLX)
libGPG, should be crypto library

But to be clear, I don't think those are required to run steam at all, but rather than basic dependencies of ALL games, so they are put in there.

[Chunchunmaru_]

Another update, looks like I was predicting future after all? 

 

System76 is going to offer their personal support for i386 libraries, updating them regularly https://github.com/pop-os/

 

Have they parterned with Valve? Who knows, that would be a great choice 

[The King of the Undead]

1 hour ago, Chunchunmaru_ said:

Another update, looks like I was predicting future after all? 

 

System76 is going to offer their personal support for i386 libraries, updating them regularly https://github.com/pop-os/

 

Have they parterned with Valve? Who knows, that would be a great choice 

yes! I will not have to switch!!!!!!!!

[Chunchunmaru_]

https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts

***Other news regarding the switch***,

due to the amount of community criticisms, valve pressure and wine etc... This is going to be all done in 20.04

 

@matrix07012 you can switch the title at this point

[leadeater]

9 hours ago, Chunchunmaru_ said:

Yeah I know how to do that, btw the LTS is bionic and not cosmic, they said they will froze to 18.04

Yea thought they were freezing to 18.10, not really a big difference overall.

[leadeater]

9 hours ago, Chunchunmaru_ said:

Wine developers however disagree with doing this at all similar to what I said in those 3 threads, and I personally disagree leaving unupdated libraries which can be a security hole, but also for performance and future games support

Well it's also a pretty big assumption that those 32bit libraries are actually getting updated. Though heavily used ones by Steam and Wine probably would.

 

Nothing is stopping Steam and Wine partnering to run their own mirror that gets added during install that has those updated libraries but I'm guessing they just don't want to have to deal with that.

 

On future game support.... 64bit.....

 

Also if Canonical are saying using an older repo source is a supported option I'm assuming they are going to do something to allow for that to work.

[YamiYukiSenpai]

I was happy & relieved that they changed their minds. 

Quote

We will also work with the WINE, Ubuntu Studio and gaming communities to use container technology to address the ultimate end of life of 32-bit libraries; it should stay possible to run old applications on newer versions of Ubuntu. Snaps and LXD enable us both to have complete 32-bit environments, and bundled libraries, to solve these issues in the long term.

Ubuntu is, after all, aimed for the general Linux user who doesn't like to tinker too much with the system.  Until there's a true be all & end all solution to that problem, those libraries need to exist in there.  The general user shouldn't have to jump so many hoops just to do their thing.

Quote

we will change our plan and build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS.

this is something that should've been done since 18.04 or whenever the last time an i386 Ubuntu flavor has been released.  There's no point in having an i386 version of Firefox, VLC, Plasma, etc.

[FezBoy]

This....  Pleases me.

[LAwLz]

21 hours ago, firelighter487 said:

why? loads of things still run on 32-bit, mainly old machines that still work fine for some tasks. 

 

also low end hardware. there is no reason to run a 64-bit OS on a machine with 4gb ram or less. 

64bit is faster than 32 bit even at lower RAM amounts.

64bit applications has access to far more general purpose registers as well as compilers being able to assume and optimize for SSE2.

 

For compute intense workloads it is not uncommon to see a 20-30% performance improvement just from compiling against 64bit rather than 32bit, because of the additional registers.

And on top of that in Windows there is a 2GB limit for each 32bit process. If you need to access more than 2GB of memory in Windows you will need to start swapping memory in and out, which obvious has a performance penalty.