Ubuntu 19.10 To Drop 32-bit x86 Packages

[leiptrstormr]

Also, also, I'm gonna seriously ROFL when/if Steam decides to switch to Suse due to this.

SteamOS and Ubuntu are both based on Debian. Why would they need to change anything?

[betam4x]

Mint is a fork of Ubuntu which is not 32bit anymore...you didn't think that one through. Shit, as is Mint considered closing up shop recently...they're not going to pick up the 32bit torch when Ubuntu drops it.

Both Cent and Suse both have official AMDGPU Pro drivers making them prime Steam candidates. RHEL is the only other choice and don't nobody wanting that for their gaming OS.

Security, compatibility, performance, and maintenance should not be an issue at all. It's all this reliance of existing compatibility that is causing the containerized approach. IMO this is the best approach for now.

Every distro out there is dated and has issues in some form or another. Someone needs to rethink how distributions are approached as a whole. Ubuntu tried to do a bit of that (and is failing) with snap. Packaging systems need to be improved, the concept of root and the root filesystem should go away (at least from user space), and kernel space should be off limits. That is the direction Windows is headed (future versions of Windows allow you to run apps in a sandbox VM). Security these days is paramount and we have the hardware to do it. Games can even be containerized if the the driver HAL is properly virtualized. I believe that Wayland will eventually cause a push in this direction. A containerized version of Wayland with it's own virtual hardware accelerated screen would not add much overhead, and as an added bonus, you'd get security to boot. No more invasive DRM or cheat detection (or cheats). It's all containerized with the game itself.

Unfortunately, all that I've mentioned takes a lot of work and a lot of change, and there aren't enough developers willing to commit to an effort, much less even having a consensus on what needs to be done. The UNIX mentality is dated, but Linux, the BSDs, etc. are so ingrained in it, things will likely never change.

[skeevy420]

There are thousands of 32bit windows titles wine + hangover does not need 32 bit host platform support to run them. Those are a short term problem.

With these advancements do we really need multilib any more. Or should we simple put old 32 bit Linux application in container and use virtgl/emugl to host particularly thinking they are most likely not getting security patched any more we might want to restrict file system access and other things. Wine with hangover means that 32 bit windows applications will not be needing 32 bit graphics driver libraries from Nvidia either.

I wonder how long it'll be until we end up using LIMES with Tequila Shots. You know, the LInux Multi-architectural Environment System.

[skeevy420]

SteamOS and Ubuntu are both based on Debian. Why would they need to change anything?

Well, Ubuntu felt the need to change something hence the topic at hand...and because I'm a little retarded and forgot SteamOS was Debian based...

[betam4x]

That 99% does not line up for Linux native games.



There are thousands of 32bit windows titles wine + hangover does not need 32 bit host platform support to run them. Those are a short term problem.



This is less required than you would think. emugl from android and virtgl work both don't care if you only have 64 bit opengl hardware support. Virtgl inside a VM to it rendering engine outside allows 32 bit inside VM and 64 bit in the host works. emugl by pipe allowed 32 bit in container and 64 bit as host. So for opengl programs we don't in fact need host provided 32bit opengl support once we have these solutions completed off.

With these advancements do we really need multilib any more. Or should we simple put old 32 bit Linux application in container and use virtgl/emugl to host particularly thinking they are most likely not getting security patched any more we might want to restrict file system access and other things. Wine with hangover means that 32 bit windows applications will not be needing 32 bit graphics driver libraries from Nvidia either.

99% of games are 32 bit only? News to me. The vast majority of games I play are 64 bit. Maybe the older stuff is 32 bit. Anything developed in Unity3d or UE4 likely is 64 bit. Also, don't confuse Ubuntu dropping 32 bit support with Wine dropping 32 bit support. Wine builds Ubuntu packages (https://wiki.winehq.org/Ubuntu), not Ubuntu. Finally, if you read the actual mailing lists posts, they are not dropping 32-bit without recourse. They are investigating how to best handle the removal of 32 bit packages. I assume, from reading the mailing list post, that no "new" 32 bit packages will be accepted. Then i386 is mentioned a lot, which leads me to believe there is some confusion of 32 bit support vs i386 support (vs i586 or i686). Time will tell and I'm willing to bet that the final solution will work out of the box with all existing software, but with a slight nudge for 32 bit applications.

Also, this myth about 32 bit applications running faster is just that, a myth. It was true early on that AMD64 could run 32 bit applications faster due to the way the architecture was implemented, but times, and architectures, have changed. These days, any decent hardware will run 64 bit applications just as fast, if not faster, than 32 bit equivalents.

[Raka555]

Also, this myth about 32 bit applications running faster is just that, a myth. It was true early on that AMD64 could run 32 bit applications faster due to the way the architecture was implemented, but times, and architectures, have changed. These days, any decent hardware will run 64 bit applications just as fast, if not faster, than 32 bit equivalents.

It is not a myth, but depends on what you are doing and how big the cache of your CPU is.
x86 has better cache hit ratio than x86_64, but x86_64 has more registers and instructions so it kind of evens out a lot of times.
x32 is the best of both worlds and can give anything from 0 to 40% increase in speed, depending on hardware and workload.

Edit:

You can play with x32 binaries yourself on Ubuntu and maybe other distro's.

It is as easy as: "gcc -mx32 my_fast_app.c -o my_fast_app" on Ubuntu 18.04.

You can then compile and run your own benchmarks and see if there are any notable differences using x32. (Please share)

[Jumbotron]

About time. If you haven't gotten the 64bit memo by now, your lazy and deserve to be unsupported.

[Mario Junior]

Nothing of value was lost.

[Vaporeon]

Good riddance.

Keeping i686 around has just made things way harder than they needed to be. Just look at this thread, this is what happens when you ship 32bit software way past its time.
Steam really screwed the pooch by shipping as 32bit. Now we are stuck with 32bit game binaries that well never be changed or updated. Who even at the time it released was using a 32bit OS? and if you were, I bet the CPU was still 64bit anyway. Before steam the only real holdback was Wine and printers, thanks Valve.

It is really unfair to expect everyone to test and release software that fully supports two architectures, even if they are extremely similar. It is still twice the testing and support and bugs can happen on one but not the other. In a way, 32bit being "good enough" has made it many times worse, unlike going from 16 to 32.
If you are still stuck in multilib hell as both a user or a developer then buckle up for the next few years, you all collectively asked for it by not going right to x86_64 as soon as technically possible.

[chithanh]

As one former Internet celebrity once said, in the long run, the utility of all non-free software approaches zero.
So now the time for 32-bit proprietary software has come.

I wonder though how Ubuntu is going to handle the whole bootloader situation. 32-bit toolchain is still needed for some parts, especially those for booting 64-bit systems that have only 32-bit UEFI.

Stupid decision. There are relatively recent Intel processors (in particular Silvermont cores) that run certain code faster on 32b. An example can be found here https://github.com/htot/crc32c.

That's Intel's fault for not pushing x32 more. I think it was hpa and some other Intel employees mostly working in their spare time. The original target of x32 was Intel smartphone SoCs, but with that business folding, Intel apparently saw no reason to pursue x32 further.

The perfect world would have been a 64bit kernel with 32bit user space (Still waiting for x32 ) ( I think https://www.elivecd.org/ was the only distro doing it. Not sure if that is still the case)

You can run x32 on Gentoo fine.

User space apps seldom need a lot of memory for a single app, except recent cross platform GUI run-times (chrome/firefox/etc) need huge amounts of memory.

64 bit is not only about memory, it is also about address space.

I really hope that 32bit arm will be with us for a long time to come as most SBC's do not have huge amounts of memory and therefore do not need the inefficiency of 64bit... (I am not holding my breath though)

Well there is aarch64-ilp32, which enjoys the same support as x32...

there are still cases and applications which run a lot faster in 32bit mode

run their VMs in i686 to save disk space and RAM.

Go x32 then.

It's an asinine decision and I expect Ubuntu to backtrack on it.

Keep dreaming.

Ubuntu -- Why are we now 87 and falling on Distrowatch?

Because Distrowatch ranks by whatever they measure in clicks, but by not installed base of a distro. Distrowatch ranking does not say anything about how well a distro does.

What a bunch of idiots. Or perhaps they are just mean and selfish? I don't know. What the f*** is happening?

They know very well, and came to the conclusion that their limited resources and developer time are better spent improving the distro elsewhere, rather than maintaining i386 support.

You can play with x32 binaries yourself on Ubuntu and maybe other distro's.

It is as easy as: "gcc -mx32 my_fast_app.c -o my_fast_app" on Ubuntu 18.04.

You can then compile and run your own benchmarks and see if there are any notable differences using x32. (Please share)

It is not that simple. If your software contains a JavaScript JIT or does other fancy things then recompiling is not enough. Instead, a major porting effort is required.

Steam really screwed the pooch by shipping as 32bit.

I agree. This should never have happened, instead Steam should have shipped a 64-bit client and insisted on all Linux games being 64-bit right from the start.