As you might have heard by now, Canonical has made the decision to drop 32bit support from Ubuntu 19.10 onwards.
Writing on the mailing list, as well as this post on Ubuntu's Community Hub, Canonical gave a reminder that the decision isn't coming without warning. It was proposed last year and it was followed up with another post detailing a final decision to be made in the middle of 2019. So here we are, the decision seems to have been made.
The problem isn't hardware, as likely around 99% of people nowadays have a 64bit capable computer. Going by our own statistics, from what 2,254 users told us only 4 are using a 32bit Linux distribution. The issue then, is mainly software and libraries needed to actually run 32bit applications. This is where it sounds like there's going to be plenty of teething issues, with a number of people not too happy about the decision.
Steam, for example, is one such application along with plenty of 32bit games that will likely never get updated, although Canonical did say they're "in discussions" with Valve about it. There's also GOG, Humble Store and itch.io which all provide a number of direct-download 32bit games, which do not supply the required 32bit libraries to run. It doesn't sound like they have been given any thought (at least they haven't been mentioned).
Another of the major problems being Wine, with a discussion now happening on their mailing list. The discussion doesn't seem to be too positive, with developer Henri Verbeet even saying "I think not building packages for Ubuntu 19.10 would be the only practical option.", although Andrew Eikum's idea of using the Steam Runtime could be an interesting way around it.
What are your thoughts?
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
qptain Nemo Jun 22, 2019
Quoting: vectorI would not be surprised if Linux users not using SteamOS or Ubuntu LTS are subject to the potential caveat that Steam Support can refuse help requests if they so choose.Oh yes, they can. I got an "unsupported distro" response on an issue, even though it wasn't distro-related and even after I reproduced it in Ubuntu running in a VM.
1 Likes, Who?
I'm quite pessimistic concerning GOG's way of handling things based on what I've seen over the last seven years, so I assume that they will fade out Linux releases without any official news.
1 Likes, Who?
Quoting: darthbasselopeWell if Pop_OS! and LinuxMint also drop 32 bit support I will have to switch to Debian, Solus, Manjaro, or another distro when the next LTS comes out kinda a bummer I was enjoying Ubuntu and learning it well guess I will have to pick up on the nuances of some other distros. who knows maybe I will be saying btw I use Arch lol.
Pop!_OS has already stated that they won't be following suit even if it means maintaining 32bit support themselves. i would imagine LinuxMint has a similar position.
2 Likes, Who?
Steve Langasek has responded on the Ubuntu Community Hub.
quote=[vorlon]I’m sorry that we’ve given anyone the impression that we are “dropping support for i386 applications”. That’s simply not the case. What we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions. But there is every intention to ensure that there is a clear story for how i386 applications (including games) can be run on versions of Ubuntu later than 19.10.[/quote]It's basically a restatement of the last paragraph of the announcement. At the very least, I wish they would steer away from language like "support story" and "evolution of" (as used in the announcement); it reeks of marketing.
quote=[vorlon]I’m sorry that we’ve given anyone the impression that we are “dropping support for i386 applications”. That’s simply not the case. What we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions. But there is every intention to ensure that there is a clear story for how i386 applications (including games) can be run on versions of Ubuntu later than 19.10.[/quote]It's basically a restatement of the last paragraph of the announcement. At the very least, I wish they would steer away from language like "support story" and "evolution of" (as used in the announcement); it reeks of marketing.
1 Likes, Who?
QuoteWhat we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions.
That's not a good thing either. Given how fast mesa, dxvk and the rest are progressing. It totally should not be frozen.
2 Likes, Who?
Quoting: GuestQuoting: sergeEndeavourOS will be it's sucessor. Release date: 15th of JulyQuoting: vlademir1Switching from *Buntu to Antergos is a project I've had on the table for a few years anyway
i think you have to choose another distro Antergos is dead:
https://www.phoronix.com/scan.php?page=news_item&px=Antergos-EOL
https://forum.antergos.com/category/7/announcements
My first thought on seeing serge's post was "ok, maybe give Manjaro another test go" but if Endeavor will provide essentially the same base level install Antergos would have I may have to give it a shot. Hell, I'd be all over a straight Arch install, but for how long it took me to be fully functional the last time I tried (it's why I've been riding *Buntu for half a decade).
1 Likes, Who?
Quoting: ShmerlI mean will those things changing really break much of anything in how those libraries are functionning ?QuoteWhat we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions.
That's not a good thing either. Given how fast mesa, dxvk and the rest are progressing. It totally should not be frozen.
That's not a troll but a real honest question here . Them freezing up those libraires in their current state would really break shit ?
1 Likes, Who?
Quoting: TheSyldatI mean will those things changing really break much of anything in how those libraries are functionning ?
That's not a troll but a real honest question here . Them freezing up those libraires in their current state would really break shit ?
I had the impression that the x86 libs must match the amd64 ones, so freezing the former would freeze the later - and thus your graphics driver. But I'm not sure either.
0 Likes
Quoting: slaapliedjeQuoting: elmapul" The issue then, is mainly software and libraries needed to actually run 32bit applications. This is where it sounds like there's going to be plenty of teething issues, with a number of people not too happy about the decision.'Ha, that's a STRONG maybe for running older Windows stuff in Windows 10. I mean I've seen many older applications run better with Wine than in Windows 10.
in the mean time, you can run windows 1.0 applications on windows 10...
what is the point of the system being open source, if we cant even run the apps we want? where is the freedom on it?
yes i can use other distro, but what if all the major ones does the same (the ones which are base for the rest) i'm not planning to support my self.
windows never looked so good.
But the point here is, imagine if Windows 10 dropped 32bit support. I'd guess roughly 80% of things would stop working entirely. In the Windows world 64bit native applications were never that wide spread.
that is why microsoft would never do that, because they have something to lose by doing that, and that thing is $$ and marketshare.
companies like canonical who the main source of income comes from servers and support have nothing to lose in droping support for 32 bits applications, hell they may even gain money from doing it since their users WILL NEED support, paid support in some cases.
also you forgot to mention that linux break support with itself with an regular base, its a shame but if you want to install an old version of an software or an software made for an different distro, some times its easier to run the windows version on wine thant the linux version on linux.
and some times you absolutelly need the old version of such software because you need an plugin that only run in and old version and you dont have enough know how or time to port it to newer versions of the software (or its an proprietary plugin)
Last edited by elmapul on 23 June 2019 at 11:41 am UTC
1 Likes, Who?
Quoting: ShmerlQuoteWhat we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions.
That's not a good thing either. Given how fast mesa, dxvk and the rest are progressing. It totally should not be frozen.
That was partly/shortly adressed too: https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-with-eoan-ubuntu-19-10/11263/88
Quote32-bit mesa will be available in the Ubuntu 18.04 repository. Note that mesa already gets updates in 18.04 which track the versions from later Ubuntu releases, as part of hardware enablement. If incompatibilities are introduced beyond 20.04 (which is the cutoff for hardware enablement backports for 18.04), we will need to address them on a case-by-case basis.and later
QuoteWe 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.I see a problem with that the HWE always is some months behind of the regular releases they come from, so someone upgrading to 19.10 when its released with not have the kernel, mesa and xorg from 19.10 available in the 18.04 container right away, unless one uses the same PPA for both.
And why not doing the same with the AMD drivers they plan to do with nvidia, shipping the 32bit along with the 64bit drivers and libraries?
Last edited by Redface on 23 June 2019 at 1:35 pm UTC
1 Likes, Who?
Patreon
PayPal
See more from me