Ubuntu 19.10 To Drop 32-bit x86 Packages

[dungeon]

I guess Debian will continue with 32bit as release arch even with 11. but would be dropped even there somewhere during development for 12...

It is planned for execution, only question is what time is considered optimal..so, maybe year 2022/2023.

Of course, that might sit in debian ports for decade more for these who like, etc... so, don't cry you won't lose it immediately

[Dedale]

Better just invest efforts in Debian, so it wouldn't drop multiarch 32-bit packages. And ditch Ubuntu since they already made their mind.

And if one does not want to use one of the mutliple debian based 32 bits distros there is Manjaro 32 bits XFCE which is based on arch but with more ease of use. And its own repos. And there is still a 32 bit build of vanilla Arch for those who can use it.

Last time i used Xubuntu on my netbook it was mighty slow and with Lubuntu i ran into problems. My nebooks are going to reach 10 years of age soon. Still useful ^^.

[F.Ultra]

Since no one reads the linked mail post:

Q. Doesn’t Steam use 32 bit libraries? How can I play my games?

Steam itself bundles a runtime containing necessary 32-bit libraries required to run the Steam client. In addition each game installed via Steam may ship 32-bit libraries they require. We’re in discussions with Valve about the best way to provide support from 19.10 onwards.

It may be possible to run 32 bit only games inside a lxd container running a 32 bit version of 18.04 LTS. You can pass through the graphics card to the container and run your games from that 32bit environment.

[Raka555]

And if one does not want to use one of the mutliple debian based 32 bits distros there is Manjaro 32 bits XFCE which is based on arch but with more ease of use. And its own repos. And there is still a 32 bit build of vanilla Arch for those who can use it.

Last time i used Xubuntu on my netbook it was mighty slow and with Lubuntu i ran into problems. My nebooks are going to reach 10 years of age soon. Still useful ^^.

You might want to look at this distro: https://www.elivecd.org

It is one I discovered a few years ago, but kind of forgot about it until the 32bit thing jolted my memory. It is 1 guy that has been doing this for years and he puts a lot of love into it. It is based on Debian.

• Min. Requirements: 192 Mb RAM, 500 Mhz CPU
• 32-bit, non-UEFI, sysinit, PAE (bigmem) kernel + 486 kernel
• Install & Live, with advanced persistence features and encryption

[shmerl]

Since no one reads the linked mail post:

That's a very poor proposal. GOG games don't bundle stuff. Wine games don't bundle it either. Why do we need containers for multiarch exactly? I didn't get that proposal at all.

We need to be be able to use recent dxvk, d9vk, Mesa and what not. In 32-bit. That already cuts off that whole stale container proposal approach.

[oiaohm]

Is Multiarch required to run 32 bit steam the answer is no. Steam has a flatpak package and flatpak does not use any of the distribution provide runtime. All that is required is they still build a kernel with 32 bit syscalls. and drivers remain able to be got in 32 bit version. Yes flatpak installs matching version of Nvidia closed source driver has host from own repository and ships it own mesa3d.

Debian is not dropping 32 bit native yet. Ubuntu developers behind snap package format could expand that to formally allow images made from debian?. Also 32 bit not as old as platform when you think about what is still in production there were still a few devices with new 32bit x86 inside in 2018, 486 instruction set in fact not even Pentuim.

[shmerl]

Is Multiarch required to run 32 bit steam the answer is no.

How are you going to build 32-bit stuff (like updated Mesa, dxvk, and so on) without packaged 32-bit libraries? By hand with a toothpick? It's going to be a nightmare.

[skeevy420]

That's a very poor proposal. GOG games don't bundle stuff. Wine games don't bundle it either. Why do we need containers for multiarch exactly? I didn't get that proposal at all.

We need to be be able to use recent dxvk, d9vk, Mesa and what not. In 32-bit. That already cuts off that whole stale container proposal approach.

So you've never had a game come with bundled with DirectX, random midi drivers, .NET, fonts, and more?

Like Raka555, I'd like a 64-bit kernel, an x32 user space, and 32bit\64bit containers for programs that either require or run better with a certain architecture.

[oiaohm]

That's a very poor proposal. GOG games don't bundle stuff. Wine games don't bundle it either,

Really GOG could be done like steam with flatpak. We have already seen people building wine in flatpak so not impossible.

Why do we need containers for multiarch exactly? I didn't get that proposal at all.

In some ways Multiarch really does work best in containers when building wine you can be better off with a 32 bit and 64 bit container building the 2 different parts.

We need to be be able to use recent dxvk, d9vk, Mesa and what not. In 32-bit.

https://github.com/AndreRH/hangover

If you are talking about this in the sense of wine. With hangover with wine don't need 32 bit libraries from host. Yes this is being used with qemu but it shows that the wine core could talk 64 bit and the applications inside wine be 32 bit. dxvk, d9vk need 32 bit and 64 bit vulkan interface provide by this is still a weakness.

Wine in hangover is redirecting 32 bit opengl application requests to host 64 bit opengl. Also wine in hangover is using 64 bit wined3d and vkd3d cores to process 32 bit application requests.

Long term wine should not need host provided multiarch at all heck will not need any of 32 bit Linux kernel syscalls either. Of course the Linux kernel will still have to allow wine to create 32 bit and 16 bit protected memory zones for good performance.

Point at wine is not a very solid arguement once you wake up for Android support wine developers have to work in environments where 64 bit libraries is all there is from the host. Yes Ubuntu change over plan is ahead of wine project being absolutely ready for it.

Support for multi interfaces in PE format was added recently to wine for 16 bit to 32 bit library and future 16bit and 32bit to 64bit library. So dxvk and d9vk could add the interfaces to their 64 bit binaries to process 32 bit application requests. Removing multiarch stuff just means this work by the wine project will have to be speed up and requires dxvk and d9vk to deal with some of the hell wined3d developers have been dealing with of only have 64 bit host libraries.

32 bit closed native Linux programs has to be your arguement for why multiarch has to remain long term. Anything running in wine long term does not need the 32 bit host libraries. Short term there are going to be issues with wine using a container could be a good enough stop gap for wine.

[oiaohm]

How are you going to build 32-bit stuff (like updated Mesa, dxvk, and so on) without packaged 32-bit libraries? By hand with a toothpick? It's going to be a nightmare.

See above hangover for arm64 from codeweavers does not need 32bit Mesa. Its able to use 64 bit Mesa for 32 bit applications. Heck wined3d core is able to run 64 bit processing request from 32 bit applications for dx 1-11. Yes dxvk and d9vk have a problem but these could be fixed with work to be a 64 bit library providing interfaces for 32 bit applications..