Honestly, not even mad. Sucks for the victims, but we need hackers poking holes in kernel anticheats. Show the game companies that kernel anticheat is a waste of effort and maybe this horrific plague of gaming will die off.

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.

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.

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.

https://youtube.com/watch?v=EuOX2L_yNqI

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.

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.

Too bad they added shitty anticheat that broke GTA Online. I can’t trust Rockstar anymore and I won’t be buying these. RDR on PC was something I really wanted, but not after Rockstar betrayed us by basically revoking our access to GTA Online after almost a decade.

Mozilla sold out a long time ago, they are nothing like they used to be. Everyone should be ditching Firefox for forks if possible. Yes, Firefox is still miles ahead of anything Chromium-based but we can’t trust Mozilla to not screw over their users anymore (and it’s been apparent for YEARS…Pocket, “Sponsored” shortcuts and links, Mozilla VPN popup ads, this behavior is hardly new). What can we trust? Firefox forks with the bullshit stripped out, mostly. I’ve been using LibreWolf for several years on my Linux, Windows, and MacOS systems now. I originally switched because of the Mozilla VPN popups but at the time, complaining about those popups was met with a bunch of Mozilla apologists going “it’s not that bad” “they’re a big company and they need their precious monies”…no. That was ADVERTISING front and center, and it was in Firefox years ago. So was Pocket. So was having Amazon links auto-filled on the new tab shortcuts. Go to something that isn’t run by money. Go to a community-maintained and sanitized fork.

I’ve been pretty happy overall with my Arc A770. For the price, it performs well, and driver issues are mostly a thing of the past. My only complaint is that the anv Mesa driver doesn’t implement VK_NV_device_generated_commands which appears to be a requirement for some D3D12 games on Linux (Starfield being the one I had issues with). Luckily, it looks like there is a new non-NVIDIA specific extension to solve that and an open MR in the Mesa GitLab to add it to anv.

Change for the sake of change is so dumb. I’m tired of pointless UI changes every so many years because some middle manager and their designers need to wow some dumb exec to get a promotion and they do so just by rearranging all the existing functionality because the product itself is already a complete solution that doesn’t actually need a new version. Sadly, this mentality even creeps into FOSS spaces. Canonical and Ubuntu wanting to reinvent the wheel with Unity, Mir, Snap, etc. GNOME radically changing their UI all the time.

This was my early high school days. My friend and I would play Mario 64 DS wirelessly across the hall because we were in different classes but close enough for a WiFi connection. Great times. Also, the Metroid demo included with the console was a fun multiplayer experience.

I got ab RG35XX Plus when it came out. Very nice little Game Boy style handheld. I played a bunch of GBA, GB, and Genesis games on it but it’s capable of a lot more.

You can view WiFi passwords for saved networks on pretty much every OS. There’s no reason to be secretive about entering WiFi passwords, at least to the people whose devices you’re entering the password on.

LibreWolf on everything that supports it (Windows/Mac/Linux) and Fennec F Droid on Android.

I wish these implementations of secure boot were designed more to protect the SOFTWARE against “theft” than the HARDWARE against “tampering”. Let us wipe the secure boot keys, but in the process erase the firmware (or have the firmware encrypted so that erasing the keys renders it unbootable) and then allow new code to run. Blocking third party firmware on consumer devices is a shit move. It just creates more e-waste when the OEM stops updating it and the community can’t make their own replacement firmware.

True, but if you buy a finished product that uses the new chip that has secure boot enabled, you can’t flash your own firmware. From what I gather, the boot keys are burned into OTP memory so they can’t be erased or changed. The chip is permanently locked to that firmware.