Until any competing store releases a Linux client, I can't really argue against Steam. They are a gatekeeper and almost a monopoly, but they're also the most benevolent and pro-consumer gatekeeper that we have in the PC gaming distribution space. As long as all the competition continue to be Windows-only and, in some cases, actively work against Linux users, I don't want Valve's digital fiefdom to fall.
Agreed 100%. I reached voting age in 2008 and I was one of those "both sides suck" idealistic young voters who voted third party. I did again in 2012 and again in 2016 thinking "Hillary's already got this one, I can protest vote". Nope, we ended up with Trump. Ever since that I will only vote blue no matter who, at least as long as the Democrats are the only viable party with some sense of normalcy. Third parties are completely unviable in the US election system. We need ranked choice for a third party vote to not be a throwaway vote. Until that happens, we can't afford to pick "the best choice", we have to pick "the best choice that actually has a chance". Even if it's not really the best choice. Very happy to have gone out and voted early last week. We need the blue wave. Once the Republican party is thoroughly stomped into the ground and made completely unviable can we focus on a truly liberal third party, but honestly we probably have a better chance of slowly moving the Dems left than we do a third party taking over. It may not happen in my lifespan but I'd rather see progress than regression.
I've been experimenting with both of these and recently wrote up a guide for installing FEX on postmarketOS (as I am testing it on my phone and tablet) but the steps should work for Pi as well.
https://wiki.postmarketos.org/wiki/Steam
I also just made a video tutorial/demo on YouTube. I ran Half Life 2 and Tomb Raider (2013). I'm not sure how capable the Pi 4 GPU is in comparison to the Adreno GPUs I tested.
Box86/64 and FEX can both run Steam on ARM. Lighter games should be playable on RPi4 and 5.
APIs can be complex too. Look at how much stuff the Win32 API provides from all the kernel calls, defined data structures/types, libraries, etc. I would venture a guess that if you documented the Win32 API including all the needed system libraries to make something like Wine, it would also be 850 pages long. The fact remains that a documented prototype for a software implementation is free to reimplement but a documented prototype for a hardware implementation requires a license. This makes no sense from a fairness perspective. I'm fine with ARM not giving away their fully developed IP cores which are actual implementations of the ARM instruction set, but locking third parties from making their own compatible designs without a license is horribly anticompetitive. I wish standards organizations still had power. Letting corporations own de-facto "standards" is awful for everyone.
In the mobile Linux scene, Qualcomm chips are some of the best supported ones. I don't love everything Qualcomm does, but the Snapdragon 845 makes for a great Linux phone and has open source drivers for most of the stack (little thanks to Qualcomm themselves).
RISC V is just an open standard set of instructions and their encodings. It is not expected nor required for implementations of RISC V to be open sourced, but if they do make a RISC V chip they don't have to pay anyone to have that privilege and the chip will be compatible with other RISC V chips because it is an open and standardized instruction set. That's the point. Qualcomm pays ARM to make their own chip designs that implement the ARM instruction set, they aren't paying for off the shelf ARM designs like most ARM chip companies do.
Hopefully Qualcomm takes the hint and takes this opportunity to develop a high performance RISC V core. Don't just give the extortionists more money, break free and use an open standard. Instruction sets shouldn't even require licensing to begin with if APIs aren't copyrightable. Why is it OK to make your own implentation of any software API (see Oracle vs. Google on the Java API, Wine implementing the Windows API, etc) but not OK to do the same thing with an instruction set (which is just a hardware API). Why is writing an ARM or x86 emulator fine but not making your own chip? Why are FPGA emulator systems legal if instruction sets are protected? It makes no sense.
The other acceptable outcome here is a Qualcomm vs. ARM lawsuit that sets a precedence that instruction sets are not protected. If they want to copyright their own cores and sell the core design fine, but Qualcomm is making their own in house designs here.
It's just a matter of flashing the CorsairLightingProtocol firmware (instructions on the project's GitHub page) and then soldering the data pin of your LED strip to the appropriate Arduino pin. You can provide 5V power to the LEDs from a Molex or SATA power cable which allows as much power as your PSU can handle. You can draw 5V from the Arduino directly to run the LEDs but I would only run 30 LEDs or fewer with this power source. If you want more LEDs then connect them straight to your PSU.
Corsair Lighting Node is another good option. The real Corsair one works well but if you're willing to DIY you can use CorsairLightingProtocol on an Arduino Pro Micro and have 2 channels of ARGB with direct mode support for like $6, and you can use multiple. I have one in my case for case lighting as I used up my motherboard headers on fans and I used this as the controller for my OpenRGB desk fan project as well.
Except the one platform that actually matters, Linux. My girlfriend got me into this game and it's the only game I have to keep a Windows installation around for. It doesn't run on the Steam Deck, so it's the only multiplayer game I play where I would even contemplate having to play it on Switch. I hate Epic Games.
If Bungie is behind it I have zero interest without even knowing what it is. Destiny 2 was an OK game, but its god awful anticheat bans Linux users. That is a sure-fire way to make me pretend your game doesn't exist. Client side anticheat is a plague. Do it properly on the server side.