To be clear, they're dropping all support for 32-bit x86, including e.g., i686 and multilib. The former is understandable, but the latter seems like a recipe for disaster, especially since it will...
To be clear, they're dropping all support for 32-bit x86, including e.g., i686 and multilib. The former is understandable, but the latter seems like a recipe for disaster, especially since it will be the release closest to Windows 7's EOL; 32-bit WINE is one of the most common uses of multilib. Their FAQ answer is not very encouraging (emphasis mine):
Q. How can I run 32-bit Windows applications if 32-bit WINE isn’t available in the archive?
Try 64-bit WINE first. Many applications will “just work”. If not use similar strategies as for 32 bit games. That is use an 18.04 LTS based Virtual Machine or LXD container that has full access to multiarch 32-bit WINE and related libraries.
Yeah that isn't encouraging in the slightest. I really expected something a little bit more professional from Canonical regarding Wine, especially as Ubuntu is the go-to gamer's distro, since it's...
Yeah that isn't encouraging in the slightest. I really expected something a little bit more professional from Canonical regarding Wine, especially as Ubuntu is the go-to gamer's distro, since it's officially supported by Steam and everything.
Well, Steam only officially supports the LTS version mentioned in the FAQ, so it's fine for now if that's what you're going with. But multilib is also commonly used with it, so it's not going to...
Well, Steam only officially supports the LTS version mentioned in the FAQ, so it's fine for now if that's what you're going with. But multilib is also commonly used with it, so it's not going to go well for the next release, either.
Q. Doesn’t Steam use 32 bit libraries? How can I play my games?
Steam itself bundles a runtime containing necessary 32-bit libraries required to run the Steam client. In addition each game installed via Steam may ship 32-bit libraries they require. We’re in discussions with Valve about the best way to provide support from 19.10 onwards.
It may be possible to run 32 bit only games inside a lxd container running a 32 bit version of 18.04 LTS. You can pass through the graphics card to the container and run your games from that 32bit environment.
Personally, my go-to distro for gaming would be Solus, even before this announcement; they have special integration with Steam. I'm not much of a gamer, though, so I don't know if Ubuntu has advantages over it.
18.04 is still supported until 2023 so this isn't as bad as you'd think. If 2019 is a bit too early for this change then by 2023 i386 will definitely have overstayed its welcome. Dropping support...
18.04 is still supported until 2023 so this isn't as bad as you'd think. If 2019 is a bit too early for this change then by 2023 i386 will definitely have overstayed its welcome. Dropping support for i386 is how you get people to start targeting amd64 exclusively.
All of the old games that run on Linux already aren't native games. I'm sure they'll figure something out. Granted, it will pull resources away from something else - but you can't avoid this work...
All of the old games that run on Linux already aren't native games. I'm sure they'll figure something out. Granted, it will pull resources away from something else - but you can't avoid this work forever.
For anyone curious as to why that is not encouraging: The solution requires an additional, dedicated GPU to have good performance. It's simply an unacceptable solution and shows they do not care...
For anyone curious as to why that is not encouraging: The solution requires an additional, dedicated GPU to have good performance.
It's simply an unacceptable solution and shows they do not care in the slightest for gaming on Linux, which is very shirtsighted, IMO.
A Valve employee posted a comment on reddit about how this will affect Steam: I'm personally very concerned that Canonical's stance on "how do we deal with 32-bit applications" is "just use LXD" –...
A Valve employee posted a comment on reddit about how this will affect Steam:
Steam and thousands of its games rely on a 32-bit glibc from the host system, as well as OpenGL and Vulkan userland graphics driver libraries for Mesa and the NVIDIA driver. Steam as it currently exists will be broken on 19.10 unless more work is done on our end. That work seems tractable, but fairly involved; what's unfortunate is that it will take away resources that would otherwise be spent on improving performance and functionality.
I'm personally very concerned that Canonical's stance on "how do we deal with 32-bit applications" is "just use LXD" – even just setting up a 32-bit LXD container by hand is not trivial, and I can't imagine configuring GPU passthrough to work properly with such a container would be easy either. I can't fault Canonical for not wanting to bear the development burden of supporting 32-bit applications forever, but this seems like a bad way to go about shedding that burden.
Ubuntu of all distributions making such a huge move with that as their workaround suggestion is just mindblowing to me. I would never think I'd have to jump through hoops like this to keep doing...
Ubuntu of all distributions making such a huge move with that as their workaround suggestion is just mindblowing to me. I would never think I'd have to jump through hoops like this to keep doing the normal basic user-y things that I use my computer for like playing some old games. Not while I'm using the go-to noob distro.
I've tried setting up GPU passthrough before and I'm not dealing with that shit. If this continues I'll probably have to hop back to Debian and try out Sid or something. [EDIT: did just that] I wouldn't be all that worried and assume it'd be just a lot of work for people who aren't me to fix, but given how even the announcement post's positive "it'll probably work" suggestion is a massive pain in the ass, I'm not optimistic.
Maybe the Debian edition of Mint will get some serious focus and I can go there. This situation seems to me like it's the exact kind of thing LMDE exists for.
They're a business trying to accommodate the community and their customers, so I'm guessing the hit of the few users who rely on this is worth the $$ for them. They can't please everyone but they...
Ubuntu of all distributions making such a huge move with that as their workaround suggestion is just mindblowing to me
They're a business trying to accommodate the community and their customers, so I'm guessing the hit of the few users who rely on this is worth the $$ for them. They can't please everyone but they likely won't lose any support contracts over this.
I mean, it's a shitty workaround and I'm actually happy not having a GPU just so I don't have to deal with these weird issues.
It's still strange to shoot themselves in the foot so directly like this. It's like they actively want to avoid being part of the optimism around Linux on desktop that Valve has earned with...
It's still strange to shoot themselves in the foot so directly like this. It's like they actively want to avoid being part of the optimism around Linux on desktop that Valve has earned with Proton. I get that's not their main business, but...well, no reason for me to stick around then :P
Well, it's going to be painful, but let's face it - sooner or later it has to be done. Multilib is a mess, and I'm glad Ubuntu is taking on the task first. The LXD solution is not ideal, but it's...
Well, it's going to be painful, but let's face it - sooner or later it has to be done. Multilib is a mess, and I'm glad Ubuntu is taking on the task first. The LXD solution is not ideal, but it's also not fatal, I doubt there are any 32 bit applications that would really suffer from running in a vm on a modern system. Also 64 bit Wine is not bad at all, lately it's improved, and the only time I had to specifically use 32 bit prefix was with a 1995 game Recoil.
Exactly. When I first read the news and this post I had my knee-jerk reaction of "but muh system works and I like it!". Thinking [and reading] more about it though, I do think they just need to...
Exactly.
When I first read the news and this post I had my knee-jerk reaction of "but muh system works and I like it!". Thinking [and reading] more about it though, I do think they just need to rip the bandaid off.
"It's not very compelling to say that Canonical should continue bearing these costs out of pocket on the grounds that some other companies are unwilling to update their software to an ISA from this millennium :)"
The 32bit -> 64bit transition has been dragging on for over 16 years now. We need to just get it done. We'll figure out ways to keep our old software running.
Absolutely agree with that. That's from the bottom of the Q/A section of the OP. Based on that and the fact that the last 32bit only desktop hardware is ~10-15 years old already, I can totally get...
I do think they just need to rip the bandaid off.
Absolutely agree with that.
i386 makes up around 1% of the Ubuntu install base.
That's from the bottom of the Q/A section of the OP. Based on that and the fact that the last 32bit only desktop hardware is ~10-15 years old already, I can totally get behind Canonical's decision here. I can't imagine anyone not being able to get off of their, at that point, 15-20 year old hardware by 2023 when 18.04 support ends.
The removal of 32-bit systems isn't very surprising and likely won't have too much friction; it's the removal of multilib support that is controversial.
i386 makes up around 1% of the Ubuntu install base.
That's from the bottom of the Q/A section of the OP. Based on that and the fact that the last 32bit only desktop hardware is ~10-15 years old already, I can totally get behind Canonical's decision here. I can't imagine anyone not being able to get off of their, at that point, 15-20 year old hardware by 2023 when 18.04 support ends.
The removal of 32-bit systems isn't very surprising and likely won't have too much friction; it's the removal of multilib support that is controversial.
Sure, but the sentiment still holds. I'd be interested in seeing the percentages of software requiring multilib. It will be much higher than 1%, but I'd wager it's still low and on the decline.
Sure, but the sentiment still holds. I'd be interested in seeing the percentages of software requiring multilib. It will be much higher than 1%, but I'd wager it's still low and on the decline.
While the number of applications that require it is probably decreasing, the actual usage of it probably isn't; applications such as Steam and 32-bit WINE use multilib, and are likely only getting...
While the number of applications that require it is probably decreasing, the actual usage of it probably isn't; applications such as Steam and 32-bit WINE use multilib, and are likely only getting more popular with Proton. Windows 7's EOL is also coming up, which probably would have boosted the usage of those two by quite a bit.
In spite of that [or rather probably more so because of that] I think it's in everyone's best interests to come up with another solution which is independent of the operating system providing...
In spite of that [or rather probably more so because of that] I think it's in everyone's best interests to come up with another solution which is independent of the operating system providing expensive support. And if more people are coming soon, the problem is only going to get worse. If an application needs to provide support for 32bit code, then an OS agnostic solution would be best, as then the onus is on the provider of said software who can better guarantee support.
Could switch to Debian, I haven't heard any plans for them to eliminate 32bit support. Depends what you're doing with the server but Debian Stable is rock solid.
Could switch to Debian, I haven't heard any plans for them to eliminate 32bit support. Depends what you're doing with the server but Debian Stable is rock solid.
To be clear, they're dropping all support for 32-bit x86, including e.g., i686 and multilib. The former is understandable, but the latter seems like a recipe for disaster, especially since it will be the release closest to Windows 7's EOL; 32-bit WINE is one of the most common uses of multilib. Their FAQ answer is not very encouraging (emphasis mine):
Yeah that isn't encouraging in the slightest. I really expected something a little bit more professional from Canonical regarding Wine, especially as Ubuntu is the go-to gamer's distro, since it's officially supported by Steam and everything.
Well, Steam only officially supports the LTS version mentioned in the FAQ, so it's fine for now if that's what you're going with. But multilib is also commonly used with it, so it's not going to go well for the next release, either.
Personally, my go-to distro for gaming would be Solus, even before this announcement; they have special integration with Steam. I'm not much of a gamer, though, so I don't know if Ubuntu has advantages over it.
18.04 is still supported until 2023 so this isn't as bad as you'd think. If 2019 is a bit too early for this change then by 2023 i386 will definitely have overstayed its welcome. Dropping support for i386 is how you get people to start targeting amd64 exclusively.
I don't think that'll be as hard, I think they already ship a whole bunch of like support libraries so games can target a common... thing.
All of the old games that run on Linux already aren't native games. I'm sure they'll figure something out. Granted, it will pull resources away from something else - but you can't avoid this work forever.
From the FAQ section I quoted above:
For anyone curious as to why that is not encouraging: The solution requires an additional, dedicated GPU to have good performance.
It's simply an unacceptable solution and shows they do not care in the slightest for gaming on Linux, which is very shirtsighted, IMO.
A Valve employee posted a comment on reddit about how this will affect Steam:
I'm personally very concerned that Canonical's stance on "how do we deal with 32-bit applications" is "just use LXD" – even just setting up a 32-bit LXD container by hand is not trivial, and I can't imagine configuring GPU passthrough to work properly with such a container would be easy either. I can't fault Canonical for not wanting to bear the development burden of supporting 32-bit applications forever, but this seems like a bad way to go about shedding that burden.
Ubuntu of all distributions making such a huge move with that as their workaround suggestion is just mindblowing to me. I would never think I'd have to jump through hoops like this to keep doing the normal basic user-y things that I use my computer for like playing some old games. Not while I'm using the go-to noob distro.
I've tried setting up GPU passthrough before and I'm not dealing with that shit. If this continues I'll probably have to hop back to Debian and try out Sid or something. [EDIT: did just that] I wouldn't be all that worried and assume it'd be just a lot of work for people who aren't me to fix, but given how even the announcement post's positive "it'll probably work" suggestion is a massive pain in the ass, I'm not optimistic.
Maybe the Debian edition of Mint will get some serious focus and I can go there. This situation seems to me like it's the exact kind of thing LMDE exists for.
They're a business trying to accommodate the community and their customers, so I'm guessing the hit of the few users who rely on this is worth the $$ for them. They can't please everyone but they likely won't lose any support contracts over this.
I mean, it's a shitty workaround and I'm actually happy not having a GPU just so I don't have to deal with these weird issues.
It's still strange to shoot themselves in the foot so directly like this. It's like they actively want to avoid being part of the optimism around Linux on desktop that Valve has earned with Proton. I get that's not their main business, but...well, no reason for me to stick around then :P
Well, it's going to be painful, but let's face it - sooner or later it has to be done. Multilib is a mess, and I'm glad Ubuntu is taking on the task first. The LXD solution is not ideal, but it's also not fatal, I doubt there are any 32 bit applications that would really suffer from running in a vm on a modern system. Also 64 bit Wine is not bad at all, lately it's improved, and the only time I had to specifically use 32 bit prefix was with a 1995 game Recoil.
Exactly.
When I first read the news and this post I had my knee-jerk reaction of "but muh system works and I like it!". Thinking [and reading] more about it though, I do think they just need to rip the bandaid off.
"It's not very compelling to say that Canonical should continue bearing these costs out of pocket on the grounds that some other companies are unwilling to update their software to an ISA from this millennium :)"
The 32bit -> 64bit transition has been dragging on for over 16 years now. We need to just get it done. We'll figure out ways to keep our old software running.
Absolutely agree with that.
That's from the bottom of the Q/A section of the OP. Based on that and the fact that the last 32bit only desktop hardware is ~10-15 years old already, I can totally get behind Canonical's decision here. I can't imagine anyone not being able to get off of their, at that point, 15-20 year old hardware by 2023 when 18.04 support ends.
The removal of 32-bit systems isn't very surprising and likely won't have too much friction; it's the removal of multilib support that is controversial.
Sure, but the sentiment still holds. I'd be interested in seeing the percentages of software requiring multilib. It will be much higher than 1%, but I'd wager it's still low and on the decline.
While the number of applications that require it is probably decreasing, the actual usage of it probably isn't; applications such as Steam and 32-bit WINE use multilib, and are likely only getting more popular with Proton. Windows 7's EOL is also coming up, which probably would have boosted the usage of those two by quite a bit.
In spite of that [or rather probably more so because of that] I think it's in everyone's best interests to come up with another solution which is independent of the operating system providing expensive support. And if more people are coming soon, the problem is only going to get worse. If an application needs to provide support for 32bit code, then an OS agnostic solution would be best, as then the onus is on the provider of said software who can better guarantee support.
I wouldn't be surprised if the 1% using ubuntu 32 bit actually have 64 bit systems but didn't know which version to pick.
Nope. My server is 32bit for real!
Well big oof for the 11 year old laptop I use as a server. Better switch it to LTS then. Or just replace the damn thing.
Could switch to Debian, I haven't heard any plans for them to eliminate 32bit support. Depends what you're doing with the server but Debian Stable is rock solid.
Will consider...