I'd classify it as too little, too late. Trust is pretty much gone. And I doubt anyone would recommend Ubuntu for gaming after this.

View this comment - View article - View full comments

QuoteLet's take Feral Interactive as an example of this, I've seen a lot of comments from people saying they buy directly through the Feral store, so Feral gets the full cut and that's just one of many such examples. However, the difference of course is the majority of the time the games are available across multiple stores, you still have the choice.

Feral are the counter example, no? Even games bought in their own store require Steam. So they essentially are equal to Steam exclusives? Feral staunchly refuse to release their games on GOG and other Linux stores.

QuoteI'm personally torn on it all. I don't particularly like exclusives, as I don't like any kind of lock-in but I don't blame developers for doing it. Good games take a lot of time and money to produce and support after release. Offering developers the chance to earn more money from a smaller store cut, plus limited-time exclusive funds to help them finish their game and improve it, developers are obviously going to take it.

Exclusivity is the wrong way to do it. Not only it's anti-competitive which is bad, it's anti-user, since it limits users' choice. So to answer Tim - no, exclusives can not be justified with agenda of lowering "Steam tax".

View this comment - View article - View full comments

Quoting: x_wingIn 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?

View this comment - View article - View full comments

Quoting: x_wingAnd 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.

View this comment - View article - View full comments

Quoting: x_wing

Quoting: Shmerl2. 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.

View this comment - View article - View full comments

Quoting: chancho_zombiecome 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.

View this comment - View article - View full comments

Quoting: finaldestCorrect me if I am wrong but surly freezing the library would make it impossible to use newer GFX drivers.

I plan to upgrade my ryzen desktop CPU soon and may consider Navi GPU further down the line. How am I supposed to get the latest drivers if the packages are frozen?

Canonical said something about case by case handling, but given it's not their priority, I wouldn't expect them to do it in timely fashion. For same reason Mesa users tend to prefer rolling distros, Ubuntu with some kind of special Mesa exception is not going to be a good choice. New hardware just amplifies the issue.

View this comment - View article - View full comments

Quoting: subWhich is VERY unfortunate because I actually like companies trying new stuff and being courageous - so I feel a bit bad when bashing such efforts - but it was just a stupid idea and not helpful at all. :/

Sure, I'm all for progress and innovation. But one that doesn't break user experience or creates a huge rift in the Linux desktop (like Mir almost did).

View this comment - View article - View full comments

Quoting: MohandevirBad project managment.

Canonical are known for that. It's not the first time. :) Remember the whole Mir vs Wayland debacle? It's not far off from that.

View this comment - View article - View full comments

Quoting: liamdaweSounds like Wine still won't work: https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-with-eoan-ubuntu-19-10/11263/121?u=liamdawe

It's good that he is highlighting the problem with their proposed plan:

QuoteSo the solutions proposed in [4] like containers and snaps based on 18.04 will not fully work.

That was quite obvious.

View this comment - View article - View full comments