Yes. It has basically the same issue that any compatibility layer is going to have. It will either faithfully reproduce X11 so well it will bring all of the nonsense Wayland was meant to do a way with (everything not directly related to displaying graphics, like font and geometry rendering from the '80s, network transparency, insecure event handling) OR it will attempt to get a reasonable subset working for modern X apps and it won’t be compatible with dusty old binaries and X forwarding etc.

Right now it looks like a shim for Xwayland so it’s the first one, but as it matures we’ll see.

I couldn’t find the specific reasoning for this change, but I feel like QEMU is probably just too holistic to be appropriate for this kind of project.

QEMU needs to be able to emulate all the ARM hardware with enough fidelity to boot a naive operating system. For the purposes of running userspace applications almost all of that is not required, you really just need to convert one ABI to the other and translate the instructions. No need to handle firmware, the MMU, interrupts, disks etc.

Yes! It used to be so hit or miss with Wine, but I played WoW in it around the same time and it was crazy that it worked (at least most of the time).

There’s just no reason to do this work. Even if you ignore the fork’s controversial maintainer, and just favor the fact that it’s maintained at all (which is what the proposal’s author is suggesting) just… Why?

X11 is basically over at this point, why throw a last minute wrench into the existing, working Xorg infrastructure?

When we dropped XFree86 back in the day there were license issues, packaging issues and a real alternative didn’t exist - all justifying the effort to switch. None of these are a problem today.

That’s hilarious, but not really the same thing.

Proton is amazing, but it’s entirely overhead translating library/system calls to Linux. It’s accurate to say they run better on SteamOS, not to say Proton is making it run better.

Now maybe Proton makes them run better than a janky but native Linux port, but that’s a separate statement about games being better optimized on Windows.

It’s more of an issue with torrent seeding. You need to be able to accept incoming connections to seed, so you need a VPN/router to allow incoming traffic to a certain port to reach your torrent client.

So, not a problem for leeching, but if you are trying to meet ratio requirements, could be a big problem.

Oh, I see what you mean, fair enough.

Duke Nukem Forever did ship… Years late and it was a total mess of a decade’s worth of gimmick mechanics that killed the franchise, but it did make it out the door.

Still fits as a cautionary tale about switching engines, I just had to double check I didn’t hallucinate that game.

They really did you a favor by breaking your existing, paid for software and then designing a chip to emulate another processor to fix the problem they made.

Anyway, enjoy your low power draw. I’ll be over here running my whole Steam library on a handheld device that costs less than your RAM upgrade.

I mean, yeah, that’s what happens when you still want to be 32 bit compatible. It’s also why I said they were ELF64 when needed. My only point was that it’s not like Valve just shipped a bunch of 32 bit binaries and called it a day or x64 support was some kind of after thought that needs future support.

Oh, you were still talking about emulating an x86 binary? That’s kind of a weird comparison because if you’re running Linux and want to run x86 software you can just do it on x86. No corporation is forcing you off of the game’s native architecture.

Right, I’m not talking about Steam, I don’t think misk was either, the context is Apple transitioning to ARM silicon.

Also Steam definitely runs native 64 bit on x64 systems. It’s intended to run in either environment, and so will have 32 bit deps, but if you start Steam, the actual executables you’re running (e.g. ~/.local/share/Steam/ubuntu12_64/steamwebhelper) are 64 bit ELFs when needed. And, of course, games run in 64 bits and link to a 64 bit steam client library.

Linux on ARM is stuck in the mud? Huh? Everything works fine on ARM, including the desktop. There are like a billion ARM devices running Linux right now.

Or did you mean Linux on Apple hardware? Because that’s by design.

Unless you can launch offensive weapons at other racers or eat shrooms to speed up or literally launch your car off of a vertical ramp into the sky and it turns into a glider in Forza, I’m pretty sure these games aren’t even in the same genre.

Announcing Star Trek: Sisko… A limited run series about Jake running his grandfather’s restaurant after achieving a small amount of literary fame.

Aww, now I’m sad Tony Todd is dead.

I had to give up on Soulslike games. It’s not that I can’t do it, it’s that every boss makes me feel frustrated for 30 mins to an hour and I’m cursing a blue streak, pissed off when I’m supposed to be having fun. Not worth it to me or my blood pressure.

Not sure it’s really relevant to OP, but I’ll vouch for Moonlight. I use it to stream from my beefy desktop to my laptop/Linux tablet that both have weak little integrated GPUs. It’s not perfect, need a strong internet connection, but it’s 100x better than Steam’s integrated version and for remote desktop access too.

A handy tip is that you can fake second monitors without any extra hardware so you don’t have to give up a connected screen either.

It only looks that way if you’re dumb. There are only two types of society in this world: racist, and racist but trying to deal with it.

It’s why I have a lot of schadenfreude for Sweden/Scandinavia as well. Enlightened multicultural social democracy for everyone… Until migrants show up with the wrong race/religion then suddenly a fascist contingent of your population materializes and there’s a “security crisis”

This sounds like a great beta canon novel plot.