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.
Excellent move. Time to get rid of some legacy stuff.
Yes, there will be a few bumps along the way, but the longer people wait to move forward with this, the harder it will get.
Better sooner than later, then. It is inevitable, anyway.
Last edited by TheSHEEEP on 21 June 2019 at 4:04 pm UTC
Yes, there will be a few bumps along the way, but the longer people wait to move forward with this, the harder it will get.
Better sooner than later, then. It is inevitable, anyway.
Last edited by TheSHEEEP on 21 June 2019 at 4:04 pm UTC
1 Likes, Who?
I think killing 32-bit support is good. I think forcing game devs to 64-bit is good. My problem with it is old games that will never be updated. I think 100% of the reason 32-bit games exist is Windows and the fact that 32-bit arguably comes before 64-bit in the Windows world. 64-bit is definitely more of a priority on Windows than in the past(mainly because of the ram limit) but that system doesn't treat 32-bit like the old legacy thing that it should. MacOS killed 32-bit long ago which actually brings up another question. Devs have to make 64-bit games for macOS right? Why is Linux left out? Unless I'm missing something. I personally think it's a good thing although there will be some growing pains around it I don't think we can keep 32-bit support forever. I'll be especially happy if the steam client goes 64-bit. I'm on Debian where 32-bit is disabled by default but very easy to enable. If steam itself doesn't need 32-bit support I might disable it, most, if not all of the games I play are 64-bit only at this point anyway.
Last edited by Scoopta on 21 June 2019 at 4:37 pm UTC
Last edited by Scoopta on 21 June 2019 at 4:37 pm UTC
3 Likes, Who?
Linux is not left out. Practically no one today makes 32-bit games. It's all about old ones, both native and Wine. We should be able to run old games without extra added overhead.
Last edited by Shmerl on 21 June 2019 at 4:48 pm UTC
Last edited by Shmerl on 21 June 2019 at 4:48 pm UTC
6 Likes, Who?
Mohandevir Jun 21, 2019
Anyway, personnally, I'm not really worried over this one. Since I use my computer mainly for gaming, I'll wait for an official statement from Valve, regarding steam and act accordingly, if needs be. For the moment, I'm sticking to Ubuntu 18.04, it's still doing an awesome job.
The problem might get resolved in the background while we, the users, won't notice.
The problem might get resolved in the background while we, the users, won't notice.
5 Likes, Who?
Isn't it a bit of an inevitability, though?
Playing devil's advocate a bit here, but, since 32 bit is no longer being pushed, Isn't it just a matter of time before it would be dropped or that future versions of libraries would have incapabilities with our beloved older games and programs?
It seems to me at some point in the future there would have to be an extra overhead, akin to a WINE or dosbox or something, that preserves that working state for older titles.
I just don't think any of us thought that time would be now
Last edited by denyasis on 21 June 2019 at 5:24 pm UTC
Playing devil's advocate a bit here, but, since 32 bit is no longer being pushed, Isn't it just a matter of time before it would be dropped or that future versions of libraries would have incapabilities with our beloved older games and programs?
It seems to me at some point in the future there would have to be an extra overhead, akin to a WINE or dosbox or something, that preserves that working state for older titles.
I just don't think any of us thought that time would be now
Last edited by denyasis on 21 June 2019 at 5:24 pm UTC
1 Likes, Who?
Quoting: denyasisIsn't it a bit of an inevitability, though?
Playing devil's advocate a bit here, but, since 32 bit is no longer being pushed, Isn't it just a matter of time before it would be dropped or that future versions of libraries would have incapabilities with our beloved older games and programs?
It seems to me at some point in the future there would have to be an extra overhead, akin to a WINE or dosbox or something, that preserves that working state for older titles.
I just don't think any of us thought that time would be now
So far, it doesn't need to be now, and there will be too much overhead, to be acceptable. Too many games were made in 32-bit still in the not distant past.
In the further future - yes, likely there will be ways to run 32-bit in some kind of emulated mode or thunking? But that should come with acceptable performance to work out for gaming. And it should be tested before dropping support for what's working today.
Last edited by Shmerl on 21 June 2019 at 5:32 pm UTC
4 Likes, Who?
Quoting: denyasisIsn't it a bit of an inevitability, though?
Playing devil's advocate a bit here, but, since 32 bit is no longer being pushed, Isn't it just a matter of time before it would be dropped or that future versions of libraries would have incapabilities with our beloved older games and programs?
There are two things to note here. One, by the time something is given up completely, there usually something in place to still run you old things. Dosbox for instance (or dosemu before that). Right now the only thing available is to actually have the 32-bit libs (or a VM, but that's too problematic).
Second problem is Wine specifically. Microsoft was very late in moving over to 64 bit. Windows software even later. So while most things native Linux have moved on, the same cannot be said for Windows. Which is a problem for those using Wine.
I agree that it is inevitable, it's just way too early.
6 Likes, Who?
https://www.gamingonlinux.com/articles/canonical-planning-to-drop-32bit-support-with-ubuntu-1910-onward.14409/comment_id=157290
I must say I agree. Besides in the future, hardware improvement could mitigate the overhead to some degree.
Now if Ubuntu were to have started work on a compatibility layer / emulator (Not really sure what to call it) before killing off 32-bit support, that would be a very nice project and would have placed them well ahead of the curve.
Quoting: ShmerlSo far, it doesn't need to be now, and there will be too much overhead, to be acceptable. Too many games were made in 32-bit still in the not distant past.
In the further future - yes, likely there will be ways to run 32-bit in some kind of emulated mode or thunking? But that should come with acceptable performance to work out for gaming. And it should be tested before dropping support for what's working today.
I must say I agree. Besides in the future, hardware improvement could mitigate the overhead to some degree.
Now if Ubuntu were to have started work on a compatibility layer / emulator (Not really sure what to call it) before killing off 32-bit support, that would be a very nice project and would have placed them well ahead of the curve.
1 Likes, Who?
Quoting: denyasisNow if Ubuntu were to have started work on a compatibility layer / emulator (Not really sure what to call it) before killing off 32-bit support, that would be a very nice project and would have placed them well ahead of the curve.
They likely don't have resources for it. They said they don't even have them for supporting 32-bit packages as is. And above sounds like a major project. But now probably someone will start focusing on such solutions, to avoid the situation when all distros will eventually do the same thing, leaving gamers in the cold.
I.e. switching from Ubuntu to other distros will help in the interim. But eventually I think this will hit all distros, so working solutions are needed.
Last edited by Shmerl on 21 June 2019 at 5:46 pm UTC
3 Likes, Who?
Good point.
Honest question as my apt knowledge with Ubuntu ended a long time ago. IIRC there is a method to upgrade from one version to another (no need to re-install any more, right)?
So when someone upgrades, their i386 packages will remain, right? I seem to remember that apt generally avoids removing packages (out side of auto-remove) during an upgrade. Or would it remove them automatically because the packages are "orphaned"?
I'm honestly interested how that would work, but my apt skills are a little weak to figure it out from the apt man pages.
Honest question as my apt knowledge with Ubuntu ended a long time ago. IIRC there is a method to upgrade from one version to another (no need to re-install any more, right)?
So when someone upgrades, their i386 packages will remain, right? I seem to remember that apt generally avoids removing packages (out side of auto-remove) during an upgrade. Or would it remove them automatically because the packages are "orphaned"?
I'm honestly interested how that would work, but my apt skills are a little weak to figure it out from the apt man pages.
0 Likes
Quoting: slaapliedjeMaybe it's because I've been using it for so damned long, but Debian to me is VERY easy to set up...
I generally agree, Debian is pretty easy to set up. Not to derail the thread too much or start a distro war, I found that the Suse's YAST setup program was more polished and had more options for tinkering the system. For example, I could set up my NFS shares and even tell the installer to skip certain packages (gaming rig, skip the Office suite plz).
It also includes some "bells and whistles". For example, it sets up automatic root partiton snapshots, so if you get a bad upgrade (its like testing after all), you can just boot into the last snapshot via grub and restore it.
Its all fairly easy stuff to do on your own, but its nice that the installer handles it. It gives a very professional feel (and hopefully is less intimidating to a newer user)
The only thing I'm not still not a fan of, I can't figure out the equivalent of apt-get autoremove to remove orphaned or unneeded packages. I can do it in the package manager's gui, but haven't figure out how to do it on the command line.
When I wanted to try a rolling distro, I went Debian testing and kept it for 10 years (my home server is still Debian and I'm never changing that!). It's a darn good OS. If your thinking of trying an RPM based distro, I'd totally recommend OpenSuse Tumbleweed.
1 Likes, Who?
wvstolzing Jun 21, 2019
Quoting: denyasisThe only thing I'm not still not a fan of, I can't figure out the equivalent of apt-get autoremove to remove orphaned or unneeded packages. I can do it in the package manager's gui, but haven't figure out how to do it on the command line.
For a general table of equivalences, check this out: https://wiki.archlinux.org/index.php/Pacman/Rosetta
(
zypper rm -u is probably the command you're looking for.)
1 Likes, Who?
Quoting: wvstolzingQuoting: denyasisThe only thing I'm not still not a fan of, I can't figure out the equivalent of apt-get autoremove to remove orphaned or unneeded packages. I can do it in the package manager's gui, but haven't figure out how to do it on the command line.
For a general table of equivalences, check this out: https://wiki.archlinux.org/index.php/Pacman/Rosetta
(zypper rm -uis probably the command you're looking for.)
Holy crap! I didn't know that existed! Thanks!
I love you
0 Likes
apt-get autoremoveis not the right way to use it though. Many forget to add purge:
apt-get autoremove --purgeLast edited by Shmerl on 21 June 2019 at 7:03 pm UTC
1 Likes, Who?
Quoting: GuestAlan pope of Canonical tried a few GoG games on 64 bits only 19.10 and guess what ? It is not going well.
https://www.phoronix.com/scan.php?page=news_item&px=Trying-GOG-Games-64-bit-Ubuntu
Heh, what did they expect? A lot of older games on GOG are 32-bit. Both native and Wine.
2 Likes, Who?
Quoting: Shmerlapt-get autoremove
is not the right way to use it though. Many forget to add purge:
apt-get autoremove --purge
Thanks. Totally forgot about purge.
0 Likes
Quoting: GuestAlan pope of Canonical tried a few GoG games on 64 bits only 19.10 and guess what ? It is not going well.
I'm shocked! Shocked! ... Well, not that shocked.
1 Likes, Who?
Quoting: barottoI'm shocked! Shocked! ... Well, not that shocked.
I'm surprised about what kind of assumption he was making. That it would "just work"? How?
Last edited by Shmerl on 21 June 2019 at 8:08 pm UTC
3 Likes, Who?
Quoting: denyasisThanks. Totally forgot about purge.
Yeah, if you don't add --purge it will keep leaving clutter around and you'll eventually have a lot of garbage left in the system. I didn't figure it out right away myself, that option is a bit hidden away.
Last edited by Shmerl on 21 June 2019 at 8:12 pm UTC
0 Likes
Patreon
PayPal
See more from me