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?
Quoting: EikeI 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.https://www.winehq.org/pipermail/wine-devel/2019-June/147869.html
"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."
https://www.winehq.org/pipermail/wine-devel/2019-June/147881.html
"Reading more carefully: their suggestion is to use a containerized 18.04 environment (snaps) to run Wine on a 19.10 system. This would use the 18.04 packages. But since there's no expectation of long term support for the environment containing 32-bit packages, I can't see any point in putting much effort into this temporary solution.
Nor do I see much point in packaging a 64-bit-only Wine on our end. It's such a niche case for 64-bit-only Wine to be useful at all. If those few people for whom it's useful need the latest development version, they can build it themselves."
https://www.winehq.org/pipermail/wine-devel/2019-June/147882.html
"As I understand it, it would still be possible to run 32-bit executables on the Ubuntu 19.10 kernel, but we'd have to build and ship all our dependencies ourselves. I don't think we want to go there just yet."
https://www.winehq.org/pipermail/wine-devel/2019-June/147985.html
"I can't use PPAs to satisfy build dependencies on the OBS. Packages have to either be in the Ubuntu standard, update, or universe repositories, or on the OBS itself. The latter is what we're doing for FAudio. That works fine, other than the whining from Ubuntu users about the tremendous difficulty of copying and pasting the command to add another repository. So if Ubuntu users do decide to go the PPA route, they should also plan on building their own Wine packages."
Last edited by vector on 23 June 2019 at 2:22 pm UTC
1 Likes, Who?
Quoting: legluondunetDon't panic, I'm sure there will be soon a solution like a "steam runtime" package containing all old needed 32 bits libraries or another solution like "VM". I just hope it will be a simpler solution as installing 32 bits software is hell for a newbie that just want to play his old 32 bits game on Linux.
wich reminds me that steam runtime is proprietary...
1 Likes, Who?
Quoting: elmapulQuoting: legluondunetDon't panic, I'm sure there will be soon a solution like a "steam runtime" package containing all old needed 32 bits libraries or another solution like "VM". I just hope it will be a simpler solution as installing 32 bits software is hell for a newbie that just want to play his old 32 bits game on Linux.
wich reminds me that steam runtime is proprietary...
Quoting: elmapulQuoting: legluondunetDon't panic, I'm sure there will be soon a solution like a "steam runtime" package containing all old needed 32 bits libraries or another solution like "VM". I just hope it will be a simpler solution as installing 32 bits software is hell for a newbie that just want to play his old 32 bits game on Linux.
wich reminds me that steam runtime is proprietary...
No, it consists of open source libraries, and the scripts for the runtime itself is also very permissive: https://github.com/ValveSoftware/steam-runtime/blob/master/COPYING
It is possible for GOG and others to bundle those as well.
2 Likes, Who?
Quoting: BeamboomIf y'alls problem with this is old 32bit games, why can't you just keep a partition with current Ubuntu installed, and run the games on that one? I mean, times change. One can't expect an old binary to run forever, that's just not how it works.
I mean, getting rid of old technology is always a pain for some. Look at Adobe Flash, the entire world worked hard for a decade to get rid of that nightmare. It will hurt some to rip it out but sometimes we need to clean out the closet.
yeah, i dont mind rebooting the system every time i want to play an different game.
want to play a little bit of an <brand new game> for a few minutes, then a little bit of <inser old game here> for a few minutes then <another brand new game> again? just reboot! you will waste more time rebooting that playing, but who cares!
1 Likes, Who?
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.
That doesn't sound reassuring. Why create a problem that needs to be "addressed on case by case basis"? It will horrendously complicate things for those who want to build things themselves.
I so far don't see Ubuntu remaining a good option for gamers.
Last edited by Shmerl on 23 June 2019 at 5:10 pm UTC
4 Likes, Who?
Quoting: ShmerlQuote32-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.
That doesn't sound reassuring. Why create a problem that needs to be "addressed on case by case basis"? It will horrendously complicate things for those who want to build things themselves.
I so far don't see Ubuntu remaining a good option for gamers.
Yeah, they should do the same for 32bit Mesa as for the proprietary Nvidia driver, make them available in the AMD64 repository (or keep the needed packages in i386 and just drop the rest, no one needs a 32bit vim in a 64bit system after all)
And if they go through with removing the i386 repositories then package the libraries needed by Steam and Wine in AMD64, this should cover a lot more programs like GOG games too then.
The LXD containers can then be used by Enterprises to deliver legacy programs to their users
1 Likes, Who?
Quoting: Schattenspiegelhttps://twitter.com/Plagman2/status/1142262103106973698I think people haven't noticed this comment or it would be seeing a bit more discussion.
Oh dear... this will get interesting
1 Likes, Who?
Quoting: Purple Library GuyDo you mean where he writes that Valve will nbot support Ubuntu 19.10 and newer anymore? There are over 200 comments at GOLs article about that: https://www.gamingonlinux.com/articles/valve-looking-to-drop-support-for-ubuntu-1910-and-up-due-to-canonicals-32bit-decision.14421Quoting: Schattenspiegelhttps://twitter.com/Plagman2/status/1142262103106973698I think people haven't noticed this comment or it would be seeing a bit more discussion.
Oh dear... this will get interesting
Or is there something new from Valve?
1 Likes, Who?
slaapliedje Jun 23, 2019
Quoting: elmapulThat's never been my experience with Linux. It may take some compatibility libraries for older stuff, but you can still get the old Loki games working on modern Linux systems.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)
2 Likes, Who?
Quoting: RedfaceWhoops! It's me that hadn't noticed that whole article yet.Quoting: Purple Library GuyDo you mean where he writes that Valve will nbot support Ubuntu 19.10 and newer anymore? There are over 200 comments at GOLs article about that: https://www.gamingonlinux.com/articles/valve-looking-to-drop-support-for-ubuntu-1910-and-up-due-to-canonicals-32bit-decision.14421Quoting: Schattenspiegelhttps://twitter.com/Plagman2/status/1142262103106973698I think people haven't noticed this comment or it would be seeing a bit more discussion.
Oh dear... this will get interesting
Or is there something new from Valve?
0 Likes
Patreon
PayPal
See more from me