Support us on Patreon
PayPalAs an update to the situation around Canonical planning to drop 32bit support (and Valve saying bye-bye to Ubuntu 19.10+ support), apparently they're not. Instead, the 32bit libraries will be frozen. Are you confused yet? I sure am.
Canonical's Steve Langasek has attempted to clarify the situation. Here's what they said:
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.
That's at least a little better, isn't it? They also said a little further:
[…] since the vast majority of i386-only software is also legacy (closed-source, will never be rebuilt), it also does not generally benefit from newer libraries […]
There's a pretty big difference from not being "included as an architecture", to having them available but frozen and still possible to use, isn't there? It's confusing, since that's not how it was originally explained. This is something that should have been said very clearly from the start.
Perhaps this might not be the epic disaster many people (myself included) thought it might turn out to be. We still have to wait and see how exactly they implement all this, and how it will affect gaming.
There's still going to be confusion and issues though, like upgrading drivers. Touching on that, Langasek said:
32-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.
So it sounds like you're still going to be stuck in some ways. Seems like the proposal is still no good for Wine either (and so Steam Play too).
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
abelthorne Jun 23, 2019
Valve, you'r options are: Manjaro/Pure Arch, Clear Linux, Solus, FreeBSD!They said don't want Arch nor Debian. And I doubt they'd even consider FreeBSD as it's not Linux. I guess their most likely choice would be either openSUSE or Fedora.
0 Likes
They DID talk about it before and my wild guess is at least Valve took notice of it. Hence their quick declaration afterwards with no much visible bargaining.
Possible Valve was aware and could not change their mind. There is this mailing list post from a year ago that outline this plan, someone on reddit just mentioned it: https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040348.html?_ga=2.61098156.1624633425.1561246225-23245439.1561246225
This should have been made a lot more public, it reminds me of Hitchhikers Guide to the Galaxy where the announcement of the plan to bulldozer the main characters house was buried in the cellar of the townhall. He could just have objected to it in time.
That's the same (short) email chain discussion where this was said:
quote=[https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040316.html]> So with the scope of this email chain, I would like to request a clarification before we go forward much
> more with this email chain: Are we discussing dropping 32-bit for *installer images* this cycle, or are we
> talking about the complete global death of i386 as a supported architecture?
Let's make it simple and reserve this thread for discussion about dropping 32-bit installer images now.
Someone else is welcome to start a separate thread to discuss the more controversial and complex topic of dropping i386 completely.
And maybe dropping armhf completely should be a third thread since that hopefully will be easier than i386.[/quote]
And this:
quote=[https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040331.html]
> I've been following this thread for a while, and have some questions. Are we talking about dropping
> Ubuntu x86 images or i386 packages from the repo? If the former, I don't see an issue here, as the
> subs (Lubuntu, core, etc) can still build release images.
The primary Ubuntu flavor already stopped creating 32-bit ISOs before 18.04 LTS. At a minimum, I think this discussion is about whether *any* official Ubuntu flavor should offer official 32-bit ISOs starting now with 18.10.
I believe one proposal is to go a step further and block users from using the normal upgrade tools to upgrade 32-bit installs past 18.04 LTS. The error should explain the situation. This is a bit annoying because we don't support cross-grading from 32-bit to 64-bit.
I was hoping that the question about 32-bit packages would be split off into a separate thread.[/quote]
Not exactly conclusive with regard to where things are now.
I've seen more lengthy discussion written on a toilet stall than what occurred on the ubuntu-devel mailing list. /hyperbole
Last edited by vector on 23 June 2019 at 10:36 pm UTC
1 Likes, Who?
They said don't want Arch nor Debian.Source?
They did say they're fed up with Debian tooling but they've not stated they don't want Debian itself.
In my opinion:
- OpenSuse: tumbleweed is a rolling distro and you don't want that for mainstream. Leap is only supported for 18 months that's way too short
- Arch based distro: come on, be serious, we're talking mainstream here
- Clear Linux: nope, rolling and controlled by a company that could shut it down without warning
- Centos or derived distro: with'ppas', why not. Still controlled by Redhat but Redhat has a good track record unlike Canonical. I still doubt Valve would want to be at the mercy of a company though
- Debian: most logical choice. Stable and with a really good track record, not vendor-controlled. Main problem is indeed some tooling is really showing its age. Apt was awesome back in the days but it's lackluster nowadays. Maybe Valve can contribute improvements?
- Ubuntu: Canonical has showed once again they can't be trusted. Going with a derived distro (like PopOs) would still be vulnerable to Canonical nonsense
Last edited by gurv on 23 June 2019 at 10:18 pm UTC
4 Likes, Who?
I'm saddened by this mess as the LTS release cadence of Ubuntu has always worked for me. However, it may be time to look at an alternative. I've always been wary of rolling release distros on production machines. But I think Manjaro might work well and I'm tempted to try XFCE on modern hardware. Also, it is definitely worth keeping an eye on Clear Linux - There are hints of a push towards the desktop market:
https://www.google.com/www.forbes.com/sites/jasonevangelho/2019/06/21/intel-drops-2-exciting-clues-about-the-future-of-clear-linux-os-desktop-users/
The real battle is for control of the developer desktop, since this is one factor driving adoption of specific distros in the cloud and datacenter. If developers start abandoning Ubuntu for other distros due to the fact that they can't run stuff they want away from work, you can bet it will hurt Canonical' s market share in the medium term..At the moment, many developers run Ubuntu at work and at home. But this may change, especially if a major industry player such as Intel offers a compelling alternative.
https://www.google.com/www.forbes.com/sites/jasonevangelho/2019/06/21/intel-drops-2-exciting-clues-about-the-future-of-clear-linux-os-desktop-users/
The real battle is for control of the developer desktop, since this is one factor driving adoption of specific distros in the cloud and datacenter. If developers start abandoning Ubuntu for other distros due to the fact that they can't run stuff they want away from work, you can bet it will hurt Canonical' s market share in the medium term..At the moment, many developers run Ubuntu at work and at home. But this may change, especially if a major industry player such as Intel offers a compelling alternative.
1 Likes, Who?
The problem with MX-Linux is the UI. Windows XP has similar looks and it's from 2001.Come, come, you're not serious, this is Linux, you can make any Distro look like whatever.
0 Likes
EagleDelta Jun 23, 2019
They said don't want Arch nor Debian.Source?
They did say they're fed up with Debian tooling but they've not stated they don't want Debian itself.
In my opinion:
- OpenSuse: tumbleweed is a rolling distro and you don't want that for mainstream. Leap is only supported for 18 months that's way too short
- Arch based distro: come on, be serious, we're talking mainstream here
- Clear Linux: nope, rolling and controlled by a company that could shut it down without warning
- Centos or derived distro: with'ppas', why not. Still controlled by Redhat but Redhat has a good track record unlike Canonical. I still doubt Valve would want to be at the mercy of a company though
- Debian: most logical choice. Stable and with a really good track record, not vendor-controlled. Main problem is indeed some tooling is really showing its age. Apt was awesome back in the days but it's lackluster nowadays. Maybe Valve can contribute improvements?
- Ubuntu: Canonical has showed once again they can't be trusted. Going with a derived distro (like PopOs) would still be vulnerable to Canonical nonsense
How would Pop!_OS be vulnerable to Canonical nonsense? They maintain their own repos and have already said they will maintain 32-bit support on their own if they have to. They have a vested financial interest (Being a Desktop/Laptop OEM) in making sure their distro is still stable and usable for their users. I would imagine that similar stances will arise from Elementary and Mint as well due to their desktop focus.
2 Likes, Who?
Well, that could've been handled better. Wonder how much marketshare they lost over past day alone over this.
do you think people really panicked and switched their distrobution because of a news within one day?
even if they have 19.04, they have support until 2020. I would not have done anything until december
and now it seems like i dont have to do anything at all
1 Likes, Who?
2. Come up with solution to run 32-bit programs, using 64-bit libraries with good performance, no 32-bit libs involved at all.
That's not a solution for graphic intensive applications, and probably every library in your system because in order to map a 32 bit library into the 64 bit version you will have to start a new process that handles the library calls through an IPC with a big impact in the performance. Also, keeping that code running will require more resources than just keeping the 32 bit builds maintained... no point at all in the end.
I would really like to see that they measure the necessary work/time required for keeping i386 builds available for the most used library (i.e. probably all the base stack that Wine requires). The bases shouldn't be big trouble for them and as it is a critical feature for many end users, the will definitely worth it.
Last edited by x_wing on 24 June 2019 at 12:14 am UTC
0 Likes
Nevertheless Jun 24, 2019
They said don't want Arch nor Debian.Source?
They did say they're fed up with Debian tooling but they've not stated they don't want Debian itself.
In my opinion:
- OpenSuse: tumbleweed is a rolling distro and you don't want that for mainstream. Leap is only supported for 18 months that's way too short
- Arch based distro: come on, be serious, we're talking mainstream here
- Clear Linux: nope, rolling and controlled by a company that could shut it down without warning
- Centos or derived distro: with'ppas', why not. Still controlled by Redhat but Redhat has a good track record unlike Canonical. I still doubt Valve would want to be at the mercy of a company though
- Debian: most logical choice. Stable and with a really good track record, not vendor-controlled. Main problem is indeed some tooling is really showing its age. Apt was awesome back in the days but it's lackluster nowadays. Maybe Valve can contribute improvements?
- Ubuntu: Canonical has showed once again they can't be trusted. Going with a derived distro (like PopOs) would still be vulnerable to Canonical nonsense
I repeat myself.. I think they should aim to officially support the Flathub Steam flatpak on at least a set of distros, or provide one themselves. It runs 32bit games on pure 64bit distros without problems.
Last edited by Nevertheless on 24 June 2019 at 12:52 am UTC
0 Likes
come on Debian?? haven't tried it recently but does it still use a ncurses installer?? sorry but it's not user friendly
Debian has graphical installer for years already.
3 Likes, Who?
2. Come up with solution to run 32-bit programs, using 64-bit libraries with good performance, no 32-bit libs involved at all.
That's not a solution for graphic intensive applications, and probably every library in your system because in order to map a 32 bit library into the 64 bit version you will have to start a new process that handles the library calls through an IPC with a big impact in the performance.
Using processor emulation like with Qemu would be indeed too much of performance hit. But hardware gets better, solutions get better and etc. Eventually this might work with acceptable performance. 32-bit games will remain old, so their level of performance requirements will be easier and easier to crunch. But not today, and besides no one implemented that yet.
Last edited by Shmerl on 24 June 2019 at 12:49 am UTC
1 Likes, Who?
Luke_Nukem Jun 24, 2019
I just purged all *386 libs from my install, including Steam. Then installed Steam via flatpak...
No. Issues. At. All.
But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?
No. Issues. At. All.
But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?
1 Likes, Who?
2. Come up with solution to run 32-bit programs, using 64-bit libraries with good performance, no 32-bit libs involved at all.
That's not a solution for graphic intensive applications, and probably every library in your system because in order to map a 32 bit library into the 64 bit version you will have to start a new process that handles the library calls through an IPC with a big impact in the performance.
Using processor emulation like with Qemu would be indeed too much of performance hit. But hardware gets better, solutions get better and etc. Eventually this might work with acceptable performance. 32-bit games will remain old, so their level of performance requirements will be easier and easier to crunch. But not today, and besides no one implemented that yet.
And will never be an option having the retro compability at hardware level. Also, creating such emulation layer stills requires to have the 32 bit libraries to run, so not a solution for the current problem.
Last edited by x_wing on 24 June 2019 at 12:57 am UTC
0 Likes
Nevertheless Jun 24, 2019
I just purged all *386 libs from my install, including Steam. Then installed Steam via flatpak...
No. Issues. At. All.
But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?
True! Though it is possible to install and play GOG games via "Install non Steam game" function in flatpak Steam - even Windows GOG games via Proton. Not the perfect solution, but works!
2 Likes, Who?
I just purged all *386 libs from my install, including Steam. Then installed Steam via flatpak...
No. Issues. At. All.
But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?
And what about proton games? Do they work without problems?
1 Likes, Who?
Nevertheless Jun 24, 2019
I just purged all *386 libs from my install, including Steam. Then installed Steam via flatpak...
No. Issues. At. All.
But this doesn't solve HumbleBumble or GOG. Though I do seem to recall and automated GOG->flatpak creator?
And what about proton games? Do they work without problems?
I have no problems at all.
2 Likes, Who?
And will never be an option having the retro compability at hardware level. Also, creating such emulation layer stills requires to have the 32 bit libraries to run, so not a solution for the current problem.
32-bit libraries can be completely bypassed, by modifying 32-bit code on the fly in some way, into 64-bit one. Something like thunking idea: https://en.wikipedia.org/wiki/Thunk
Not sure how well that would work, but hard to say until someone tries.
Last edited by Shmerl on 24 June 2019 at 1:13 am UTC
1 Likes, Who?
And will never be an option having the retro compability at hardware level. Also, creating such emulation layer stills requires to have the 32 bit libraries to run, so not a solution for the current problem.
32-bit libraries can be completely bypassed, by modifying 32-bit code on the fly in some way, into 64-bit one. Something like thunking idea: https://en.wikipedia.org/wiki/Thunk
Not sure how well that would work, but hard to say until someone tries.
But what if you have a code that plays around with pointer size values? Is a call for disaster that. Also, you have to support all the code required to translate your 32 bit app to 64 bit just to avoid building the required deps in 32 bits. Having the support at hardware level and libraries that can be compiled for 32 bit is a no brainer decision.
In short, all the suggested workarounds are by far more expensive than simply compiling the base deps for x86.
1 Likes, Who?
In short, all the suggested workarounds are by far more expensive than simply compiling the base deps for x86.
They might be more expensive to develop, but it can be better than having nothing when upstream libraries simply decide to drop 32-bit support to begin with. They can do it at some point. Then what?
Last edited by Shmerl on 24 June 2019 at 2:03 am UTC
1 Likes, Who?
They might be more expensive to develop, but it can be better than having nothing when upstream libraries simply decide to drop 32-bit support to begin with. They can do it at some point. Then what?
In the moment that any library drops 32-bit support (which is kinda debatable as x86 and AMD64 are a very related instruction set) you just freeze to the last version of the library that is supported. Basically, what Ubuntu says are going to do now but with the problem that they are doing this before any common library got into such "milestone".
Last edited by x_wing on 24 June 2019 at 2:12 am UTC
0 Likes
See more from me