As 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).
They didn't miss it
They dont care
Gamers are not their customers.
I get that (though I'm not sure it's clever to p**s off too many people). But what about WINE users...?
Again same thing. Gamers aren't their customers. Therefore Wine users aren't either. People 'in the cloud' don't use Wine. So they don't care what happens to Wine.
Again same thing. Gamers aren't their customers. Therefore Wine users aren't either. People 'in the cloud' don't use Wine. So they don't care what happens to Wine.
WINE is useful for way more than games. TBH, I can hardly imagine their customers don't need it. Having a Linux infrastructure but being able to run that one Windows program the company needs, but the Fortran ;-) code is gone, does sound valuable to me.
exactly that's the point, windows didn't drop 32bits, but once they said that from now on all apps should be UWP (universal windows platform) they had a major backslash and they decided to not implement it. If MS had this problem, it is clear that ubuntu has to backpedal,.
Maybe but I'm pretty sure I know why MS had ot back off on their plan. And it can be summed up with 3 letters
SAP
Why do I think this? History lesson. Back when IE was 'the thing' they were sued by a patent troll Eolas for some nonsense with ActiveX controls and whatever.
https://en.wikipedia.org/wiki/Eolas#Patents
MS lost and had to roll out an IE patch that forced users to click on an ActiveX control to activate it. That's it. Ok not a big deal right? I mean sorta annoying but most websites can patch that out or something. Note MS FORCED this on companies. It was not optional. This also came out on the heels of the IloveU virus wiping out companies, meaning companies were also highly sensitive to keeping IE up to date than they would have been previously.
The problem? Most companies run SAP. And if you use SAP, EVERY SINGLE THING on the page is an individual ActiveX control. That means to use anything in SAP, you have to click DOZENS of fields and accept ActiveX. You have to do this on EVERY SINGLE PAGE YOU LOAD. Imagine opening an Excel spreadsheet and every time you clicked a cell you were given a prompt to "do you want to actually use this cell". Every, single, time. Imagine a Word document that gave a pop up "do you want to use punctuation" every time you pressed "." You can imagine this was not good for SAP customers.
The only solution? UPgrade to the latest SAP version. Now let me tell you how companies upgrade SAP. If you wanted to add a comma to a page, you'd probably spend 6 months in development, testing, approval for production, and the rollout to every server and computer. A major SAP revision upgrade could easily be 1-2 YEARS before a desktop would see that. This MS patch was rolling out in a few months and was mandatory and there was no solution.
Well there was no solution if you were a plebeian company.
If you were a Fortune 10. Yes Fortune 10 MS customer, then you were on a secret DAILY conference call about this. Where engineers/IT/etc were SCREAMING at Microsoft. Again a major SAP revision, if you threw every single resource in a company at this into a sweatshop and worked them 80 hours a week, you 'might' get it done in a year. There was no way any of these giant companies could possibly roll this out in the timeframe MS said they needed to. Also remember the back drop of IloveU was also there, so you couldn't just 'leave IE unpatched for 1-2 years' like most organizations did before.
So the solution was, you mega giant Fortune 10 companies, that give MS more money than god every day in licensing, get a 'secret' patch that updates IE from a security standpoint but DOES NOT prompt for ActiveX controls.
SO when MS tried to make UWP 'the future', the problem was that SAP didn't work with UWP and because most SAP implementations were ultra complex rats nests of inter-dependencies, there was a zero percent chance you could get SAP to work with UWP. So much stuff, literally everything, fed into SAP. 3rd party software had to integrate into it, feed it information. Custom hardware had to work with it and feed it data. etc. None of that stuff was ever going to work with the way UWP was designed. UWP was a non starter because SAP HAS TO WORK.
Again same thing. Gamers aren't their customers. Therefore Wine users aren't either. People 'in the cloud' don't use Wine. So they don't care what happens to Wine.
WINE is useful for way more than games. TBH, I can hardly imagine their customers don't need it. Having a Linux infrastructure but being able to run that one Windows program the company needs, but the Fortran ;-) code is gone, does sound valuable to me.
While Wine can be used for stuff other than games, i'd say the majority of users who use it, generally are doing so for gaming. Working for gaming, has a 'side effect' so to speak of it working for other stuff. But I link Wine's primary focus for the group itself is basically gaming
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.Speaking of bolded issue here. I remember few years ago reading on "How-to-geek" article about Mint below..
Ubuntu Developers Say Linux Mint is Insecure. Are They Right?
So giving the scenario if all Ubuntu-derived fork are separating off from Canonical; will they able to maintain as same as or better than Canonical in term of security, reliability, etc.?
Let me be honest, I'm still using Ubuntu because it was/is supposely among the easiest Linux distros. But, when even some their own repos are broken/outdated and need same troublesome solutions as other distros, it's encourage me want to leaving Ubuntu. However, it's very hard for me to leave Ubuntu ecosystem "easiness" (well 10.04 - 18.04 era easiness).
Yours or anyone GoL users opinions?
But as i said earlier in replay- you can't compare it to "native" solution. These are like 5 clicks or so, not mounting disks manually or changing flatpak permissions.So, how you can install games to non-system drive? As i recall, flatpak Steam is isolated from the rest of OS. You cannot go out of flatpak's file system.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.
EDIT: Without changing location of Steam, of course. For example leave Steam (and some games) on SSD and keep rest of them on two separate HDD drives.
You can do it with a flatpak override like described here:
https://askubuntu.com/questions/1086529/how-to-give-a-flatpak-app-access-to-a-directory
or you can mount partitions into the [edit: Steam flatpak] packages folder.
I also don't like the general idea of an ecosystem of libraries that is outside of the control of the official package repo. It's creepy.
Now they actually change their plans: https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
Wow does this mean they have already reverted their decision? Sounds a bit like this to me. If so, it would be a tremendous success for the community. They obviously got a very huge feedback from many users!
I wonder what Valve will be doing now, still supporting Ubuntu 20.04 LTS then or switching to a different distro nevertheless.
However if this really means that they will continue to support 32bit libraries, it shows that they listened this time. Great news!
Now they actually change their plans: https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
"We'll stop shooting ourselves in the foot!" (Too bad there's a hole already.)
I don’t think they need hiding. If they can say “this way is beter for our CPU”, then its ok. Benchmark is actual state. Now clear linux isnt officialy suported by steam, if that change...
The scenario that you describe is actually a reality right now. Clear Linux is already highly tuned for Intel platforms. And it's still the best option for AMD hardware.
Can you mention something specific that will change the current situation?
I said that i can be paranoid. I only think it is not great idea. I haven't any proof, only hunch.
I don’t think they need hiding. If they can say “this way is beter for our CPU”, then its ok. Benchmark is actual state. Now clear linux isnt officialy suported by steam, if that change...I did some additional research and I found this information:
Clear Linux OS is composed of many different open source software projects and welcomes all contributors to improve the project.
You know, what owner can? Chose which contribution they accept. If they refuse, cotributor can fork, but he can't force intel accept his work.
But as i said earlier in replay- you can't compare it to "native" solution. These are like 5 clicks or so, not mounting disks manually or changing flatpak permissions.So, how you can install games to non-system drive? As i recall, flatpak Steam is isolated from the rest of OS. You cannot go out of flatpak's file system.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.
EDIT: Without changing location of Steam, of course. For example leave Steam (and some games) on SSD and keep rest of them on two separate HDD drives.
You can do it with a flatpak override like described here:
https://askubuntu.com/questions/1086529/how-to-give-a-flatpak-app-access-to-a-directory
or you can mount partitions into the [edit: Steam flatpak] packages folder.
Yes, it is a container/sandbox solution. Therefore it is more complex by nature. On the other hand, in the simplest case, if your system is installed on a single big partition, there is no configuration necessary at all. In Linux Mint you install flatpak Steam via gui, and then just use it. Only adding a second Steam library on a second partition is one step more than it already is.
Last edited by Nevertheless on 24 June 2019 at 7:58 pm UTC
You know, what owner can? Chose which contribution they accept. If they refuse, cotributor can fork, but he can't force intel accept his work.
Of course but if you don't want to accept AMD hardware contributions then you don't write exactly this:
"welcomes all contributors to improve the project"
You know, what owner can? Chose which contribution they accept. If they refuse, cotributor can fork, but he can't force intel accept his work.
Of course but if you don't want to accept AMD hardware contributions then you don't write exactly this:
"welcomes all contributors to improve the project"
Contrary, i write exactly that. AMD can bring some optimisation from which can benefit Intel HW, but for everythink from which intel HW haven’t profit but AMD does i try find a PR reason to not acept it. But that only if i have strong position, like if my distro is only one officialy suported by Steam.
That is probably too hard for average user switching from Windows to Linux. And who today has one big partition? I don't see many people buying multi terabytes SSD-es. And HDD are falling out of favor, especially as system disks.But as i said earlier in replay- you can't compare it to "native" solution. These are like 5 clicks or so, not mounting disks manually or changing flatpak permissions.So, how you can install games to non-system drive? As i recall, flatpak Steam is isolated from the rest of OS. You cannot go out of flatpak's file system.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.
EDIT: Without changing location of Steam, of course. For example leave Steam (and some games) on SSD and keep rest of them on two separate HDD drives.
You can do it with a flatpak override like described here:
https://askubuntu.com/questions/1086529/how-to-give-a-flatpak-app-access-to-a-directory
or you can mount partitions into the [edit: Steam flatpak] packages folder.
Yes, it is a container/sandbox solution. Therefore it is more complex by nature. On the other hand, in the simplest case, if your system is installed on a single big partition, there is no configuration necessary at all. In Linux Mint you install flatpak Steam via gui, and then just use it. Only adding a second Steam library on a second partition is one step more than it already is.
That is probably too hard for average user switching from Windows to Linux. And who today has one big partition? I don't see many people buying multi terabytes SSD-es. And HDD are falling out of favor, especially as system disks.But as i said earlier in replay- you can't compare it to "native" solution. These are like 5 clicks or so, not mounting disks manually or changing flatpak permissions.So, how you can install games to non-system drive? As i recall, flatpak Steam is isolated from the rest of OS. You cannot go out of flatpak's file system.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.
EDIT: Without changing location of Steam, of course. For example leave Steam (and some games) on SSD and keep rest of them on two separate HDD drives.
You can do it with a flatpak override like described here:
https://askubuntu.com/questions/1086529/how-to-give-a-flatpak-app-access-to-a-directory
or you can mount partitions into the [edit: Steam flatpak] packages folder.
Yes, it is a container/sandbox solution. Therefore it is more complex by nature. On the other hand, in the simplest case, if your system is installed on a single big partition, there is no configuration necessary at all. In Linux Mint you install flatpak Steam via gui, and then just use it. Only adding a second Steam library on a second partition is one step more than it already is.
Probably true. I guess there's still room for optimization or for configuration UIs. But not only with flatpaks, partitioning itself is not easy for beginners. And when I think about Nvidia driver installation and update mangement on some distros...
Last edited by Nevertheless on 25 June 2019 at 6:03 am UTC
And that's the point.That is probably too hard for average user switching from Windows to Linux. And who today has one big partition? I don't see many people buying multi terabytes SSD-es. And HDD are falling out of favor, especially as system disks.But as i said earlier in replay- you can't compare it to "native" solution. These are like 5 clicks or so, not mounting disks manually or changing flatpak permissions.So, how you can install games to non-system drive? As i recall, flatpak Steam is isolated from the rest of OS. You cannot go out of flatpak's file system.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.
EDIT: Without changing location of Steam, of course. For example leave Steam (and some games) on SSD and keep rest of them on two separate HDD drives.
You can do it with a flatpak override like described here:
https://askubuntu.com/questions/1086529/how-to-give-a-flatpak-app-access-to-a-directory
or you can mount partitions into the [edit: Steam flatpak] packages folder.
Yes, it is a container/sandbox solution. Therefore it is more complex by nature. On the other hand, in the simplest case, if your system is installed on a single big partition, there is no configuration necessary at all. In Linux Mint you install flatpak Steam via gui, and then just use it. Only adding a second Steam library on a second partition is one step more than it already is.
Probably true. I guess theres still room for optimization or configuration UIs, but not only with flatpaks. When I think about Nvidia driver installation and update mangement on some distros...
And that's the point.That is probably too hard for average user switching from Windows to Linux. And who today has one big partition? I don't see many people buying multi terabytes SSD-es. And HDD are falling out of favor, especially as system disks.But as i said earlier in replay- you can't compare it to "native" solution. These are like 5 clicks or so, not mounting disks manually or changing flatpak permissions.So, how you can install games to non-system drive? As i recall, flatpak Steam is isolated from the rest of OS. You cannot go out of flatpak's file system.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.
EDIT: Without changing location of Steam, of course. For example leave Steam (and some games) on SSD and keep rest of them on two separate HDD drives.
You can do it with a flatpak override like described here:
https://askubuntu.com/questions/1086529/how-to-give-a-flatpak-app-access-to-a-directory
or you can mount partitions into the [edit: Steam flatpak] packages folder.
Yes, it is a container/sandbox solution. Therefore it is more complex by nature. On the other hand, in the simplest case, if your system is installed on a single big partition, there is no configuration necessary at all. In Linux Mint you install flatpak Steam via gui, and then just use it. Only adding a second Steam library on a second partition is one step more than it already is.
Probably true. I guess theres still room for optimization or configuration UIs, but not only with flatpaks. When I think about Nvidia driver installation and update mangement on some distros...
Sorry, I edited while you were already answering! I had forgot a point to make my post clearer. But I think we generally agree that some things should be made easier to configure and understand in the future.
Still I think flatpaks are the right way in principle.
I think so. Flatpaks are great when it comes to proprietary software. But at this point Steam takes care of so many things related to gaming that isolating it hurts more then it helps. On the other hand, games as flatpaks or appimages on Steam would be totally awesome.And that's the point.That is probably too hard for average user switching from Windows to Linux. And who today has one big partition? I don't see many people buying multi terabytes SSD-es. And HDD are falling out of favor, especially as system disks.But as i said earlier in replay- you can't compare it to "native" solution. These are like 5 clicks or so, not mounting disks manually or changing flatpak permissions.So, how you can install games to non-system drive? As i recall, flatpak Steam is isolated from the rest of OS. You cannot go out of flatpak's file system.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.
EDIT: Without changing location of Steam, of course. For example leave Steam (and some games) on SSD and keep rest of them on two separate HDD drives.
You can do it with a flatpak override like described here:
https://askubuntu.com/questions/1086529/how-to-give-a-flatpak-app-access-to-a-directory
or you can mount partitions into the [edit: Steam flatpak] packages folder.
Yes, it is a container/sandbox solution. Therefore it is more complex by nature. On the other hand, in the simplest case, if your system is installed on a single big partition, there is no configuration necessary at all. In Linux Mint you install flatpak Steam via gui, and then just use it. Only adding a second Steam library on a second partition is one step more than it already is.
Probably true. I guess theres still room for optimization or configuration UIs, but not only with flatpaks. When I think about Nvidia driver installation and update mangement on some distros...
Sorry, I edited while you were already answering! I had forgot a point to make my post clearer. But I think we generally agree that some things should be made easier to configure and understand in the future.
Still I think flatpaks are the right way in principle.
I think so. Flatpaks are great when it comes to proprietary software. But at this point Steam takes care of so many things related to gaming that isolating it hurts more then it helps. On the other hand, games as flatpaks or appimages on Steam would be totally awesome.And that's the point.That is probably too hard for average user switching from Windows to Linux. And who today has one big partition? I don't see many people buying multi terabytes SSD-es. And HDD are falling out of favor, especially as system disks.But as i said earlier in replay- you can't compare it to "native" solution. These are like 5 clicks or so, not mounting disks manually or changing flatpak permissions.So, how you can install games to non-system drive? As i recall, flatpak Steam is isolated from the rest of OS. You cannot go out of flatpak's file system.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.
EDIT: Without changing location of Steam, of course. For example leave Steam (and some games) on SSD and keep rest of them on two separate HDD drives.
You can do it with a flatpak override like described here:
https://askubuntu.com/questions/1086529/how-to-give-a-flatpak-app-access-to-a-directory
or you can mount partitions into the [edit: Steam flatpak] packages folder.
Yes, it is a container/sandbox solution. Therefore it is more complex by nature. On the other hand, in the simplest case, if your system is installed on a single big partition, there is no configuration necessary at all. In Linux Mint you install flatpak Steam via gui, and then just use it. Only adding a second Steam library on a second partition is one step more than it already is.
Probably true. I guess theres still room for optimization or configuration UIs, but not only with flatpaks. When I think about Nvidia driver installation and update mangement on some distros...
Sorry, I edited while you were already answering! I had forgot a point to make my post clearer. But I think we generally agree that some things should be made easier to configure and understand in the future.
Still I think flatpaks are the right way in principle.
I really like it for its sandboxing functionality. I use Flatpak or Firejail for everything proprietary and / or connected to the internet.
See more from me