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?
Last edited by Schattenspiegel on 21 June 2019 at 12:36 am UTC
Dropping 32 bit altogether in one go is a bit dumb ...
They should work with Valve in maintaining the few libs that were used by our games in the past ...
Quoting: GuestFlatpak a 32-bit library runtime and redirect traditional apps to it? What do other distros do for 32-bit lib support for games, just build their own packages? Using something like flatpak instead so 32-bit libraries wouldn't be locked into any particular distro would be great if you could make it easy for apps to utilize it (symlinks to the flatpak libs provided by a native package or by the flatpak w/ expanded permissions perhaps?).
Distros commonly use multiarch approach: https://wiki.debian.org/Multiarch/HOWTO
Less flexible and more limited idea of the same sort is called multilib. For such distros, there is no reason to use flaptak for 32-bit packages. So unless everyone will start dropping x86_32 multiarch, it should fine.
Last edited by Shmerl on 21 June 2019 at 1:40 am UTC
QuoteWhile this means we will not provide 32-bit builds of new upstream versions
of libraries, there are a number of ways that 32-bit applications can
continue to be made available to users of later Ubuntu releases, as detailed
in [4]. We will be working to polish the 32-bit support story over the
course of the 19.10 development cycle. To follow the evolution of this
support, you can participate in the discourse thread at [5].
Don't panic.
Quoting: slapinDon't panic.
Be calm, pick a better distro ;) Seriously, their proposed solutions are far from optimal.
Quoting: ShmerlIsn't it already mostly in Debian proper? Besides maybe the plymouth theme / wallpapers.Quoting: MohandevirValve could up their game and offer a Steamos-Desktop Edition. It's already Debian based and includes a Gnome DE... Both hands on the steering wheel.
Or they can just open source their UI and add it to Debian proper ;)
I'm a huge supporter of Debian as a desktop / server, whatever.
It really goes like this, use stable with backports (namely kernel / nvidia driver, if you have such hardware, etc.) with the debian-multimedia repo, and you're pretty much set. Then you can wait about a year into stable, then switch to testing, since their release cycles seem to be about every 2 years. Just note that testing gets a bit unstable right after a release, and switch to stable at that point so the couple months of all the new crap coming from experimental and unstable don't break your system.
Coming from someone who has used it since the late 90s :)
Quoting: slaapliedjeJust note that testing gets a bit unstable right after a release, and switch to stable at that point so the couple months of all the new crap coming from experimental and unstable don't break your system.
Coming from someone who has used it since the late 90s :)
Debian tried to address this issue. Remember this proposal? https://lwn.net/Articles/550032/
It got better, but Debian testing can be sometimes rough and needs some understanding how to handle breakage if it happens. But that's in general not uncommon for any rolling distro, and rolling distro users learn how to deal with it and how to roll back breaking changes if they slip through.
Last edited by Shmerl on 21 June 2019 at 2:04 am UTC
Quoting: ShmerlHere's my thoughts on the actual change;Quoting: slapinDon't panic.
Be calm, pick a better distro ;) Seriously, their proposed solutions are far from optimal.
They are spending no extra development to get the 32bit packages on their 64bit system, since Debian does all the work, and they just fork / rebuild the packages.
They are doing this only to try to promote their own Snap package management, because no one really wants to use it, and more and more projects are moving to flatpak, or just releasing AppImages (I know Cura does this, I do wish the maintainer of the debian package would update it...)
Granted, it's my understanding that snap is friendlier to commercial packages, vs flatpak is more for running newer / sandboxed open source software. I personally stay away from snap, because it seems about as clean as random android app stores.
Quoting: slaapliedjeQuoting: ShmerlIsn't it already mostly in Debian proper? Besides maybe the plymouth theme / wallpapers.Quoting: MohandevirValve could up their game and offer a Steamos-Desktop Edition. It's already Debian based and includes a Gnome DE... Both hands on the steering wheel.
Or they can just open source their UI and add it to Debian proper ;)
I'm a huge supporter of Debian as a desktop / server, whatever.
It really goes like this, use stable with backports (namely kernel / nvidia driver, if you have such hardware, etc.) with the debian-multimedia repo, and you're pretty much set. Then you can wait about a year into stable, then switch to testing, since their release cycles seem to be about every 2 years. Just note that testing gets a bit unstable right after a release, and switch to stable at that point so the couple months of all the new crap coming from experimental and unstable don't break your system.
Coming from someone who has used it since the late 90s :)
Thing is the desktop sessionn is separate from the BPM session that automatically launches . (the BPM mode uses it's own compositor , and the X server is slightly differently configured ) .
So yeah it is mostly Debian based but thing is they customized it a looot .
As far as I am concerned I guess I'll stick with 18.04 for a while once I upgrade to it (and that already brings some problems Devil Daggers being one of them )
Quoting: slaapliedjeThey are doing this only to try to promote their own Snap package management, because no one really wants to use it, and more and more projects are moving to flatpak, or just releasing AppImages (I know Cura does this, I do wish the maintainer of the debian package would update it...)
Granted, it's my understanding that snap is friendlier to commercial packages, vs flatpak is more for running newer / sandboxed open source software. I personally stay away from snap, because it seems about as clean as random android app stores.
I think Flatpak overall has wider backing, and is viewed is a lightweight sandboxing solution. When it comes to such bundling, I usually see Flatpak discussed, almost never Snap. And I doubt their Snap push will help prevent massive migration of gamers from Ubuntu. Canonical really didn't handle this well.
Last edited by Shmerl on 21 June 2019 at 2:18 am UTC
See more from me