Mac is very similar to Linux in that it comes with bash (these days zsh) and a lot of the command line tools you’d expect on Linux, including gcc

No it doesn’t.

The gcc command is a wrapper for clang, and the clang command is a stub that runs an executable used to install the “Xcode Command-Line Tools”

It also uses the BSD coreutils, rather than the GNU coreutils present on most Linux distros. The two are only compatible up to functionality defined by the POSIX standard, and anything beyond that is an inconsistent mess.

Windows is more difficult. The command line is very different (it inherits from DOS instead of Unix like both Mac and Linux). It doesn’t come with Python pre-installed

If you limit yourself to not using WSL, sure. WSL 2 runs an actual Linux kernel with the same Linux executables you would find on any other distro.

It’s still Windows and full of telemetry and AI garbage nobody wants, but it somehow manages to have better Linux compatibility than macOS.

Unsurprising. Drivers are better than they used to be, but some of them (Nvidia) have a long way to go in terms of optimization.

More importantly, however, is the complete lack of info the article provides about their testing methodology.

• They said they tested on SteamOS—ok, but it’s not officially available on non-handheld devices. How did they install it? Did they use HoloISO? Did they install the version meant for handhelds on a desktop PC?

• How did they run the games? Directly through an embedded gamescope session like the Steam Deck, or through KDE Plasma, which has a compositor that can’t be disabled on Wayland. Or, did they take the double hit and run gamescope as a window within Plasma?

• Speaking of Wayland, did they use Wayland or X? They have different performance characteristics, and it’s not negligible.

• How many runs did they do? One-and-done, then record what the game said the average FPS was? Average of 5 runs? Were runs with outliers excluded and retested?

• Did they pre-run the scenes to ensure the assets were cached from the disk and the shader caches were available? Did they restart the system between games? Did they restart the system between runs?

And the way they present the results are also bad:

• They graph the FPS achieved by each platform, but they have absolutely no detail about the 1% or 0.1% lows—and at a sufficiently-high average FPS, these are what make the games feel slow and stuttery.

• What about frametime graphs and frame pacing information? If Linux can achieve more consistent pacing at 85% of the average FPS, it would still be a better experience than having the same frame being presented repeatedly because the game missed the vblank window.

• They didn’t try multiple resolutions to identify where the bottlenecks are occuring in each game. If a game is CPU bottlenecked by their hardware choices, it’s not a good comparison of GPU performance. Likewise, if it’s GPU bottlenecked, it’s not a good comparison for CPU performance.

The only way that username would check out is either if it was owned by a pushy and holier-than-thou social progressive with zero self-awareness, a conservative with a small world view that feels “owning the libs” is a personality trait, or a troll.

Now, considering your account was created on this platform two days ago, just called the resident population of Lemmy stupid, and drink whatever kool-aid Musk is selling, it’s a toss-up between the last two.

Much like Musk himself, it seems.

OP frequently posts pro-Russia articles. I suspect they don’t want to see the difference.

clips shared by Students for Justice in Palestine (SJP) Toronto show one of the IDF soldiers grabbing and shoving protesters.

Oh look, a live demonstration of what they were trained to do—assault foreign citizens on their own soil.

Agreed. The call trace shows it occurred as part of a drm_ function, which is related to the DRM (Direct Rendering Manager) subsystem.

There’s a chance it might not be the root cause, but the more obvious answer is that the Nvidia driver managed to corrupt a kernel data structure.

Respectfully, I’m going to have to disagree about stock Windows working fine. There are multiple places where it necessitates having a keyboard and/or mouse connected.

• Interacting with UAC prompts and other elevated-permission windows that block synthetic input events.
• When a popup hijacks focus away from the game window.
• When Steam (or other controller to mouse software) is not open, such as during the logoff screen where you sometimes have to click “Close Anyways”.
• After a BIOS update, when the TPM refuses to unlock and you need to enter the BitLocker recovery key within the pre-boot environment.

am still running Windows on it, but only for one reason: no first party support from SteamOS.

For the most part, it SteamOS isn’t really necessary to get a serviceable desktop gaming experience. Pick a well-supported rolling release distro or a derivative, install Steam and Proton, and games mostly just work.

It’s not perfect, but it’s usable. The only real pain point around gaming is getting HDR working properly.

Closed-source software is a different story, however. Discord’s Wayland support is basically nonexistent and the AFK detection thinks you’re always in front of the computer, suppressing mobile notifications.

If other hardware vendors are going to follow, they have to be using SteamOS or something similar out of the box. Handhelds can somewhat get away with using Windows because of the touch screen, but a “console” experience that occasionally requires plugging in a keyboard and mouse to get past some controller-unfriendly menu or pop-up is just going to annoy users.

A thief doesn’t loudly announce that they just stole something.

The attack was coming from ::1

Or if that’s too unbelievable, fe80:: has some scary implications while also not likely to ever be a real device.

these games only accept the secure boot setup where the root key is that of microsoft’s.

I have a PC where I could actually test this. Custom MOK but with all the MS signatures in the database. I can boot into Windows through the BIOS using only the MS-signed bootloader instead of GRUB or any chain loader, and Windows itself considers Secure Boot to be enabled successfully.

Do you know if it would immediately reject the game from launching, or would I be flagged and banned later as some kind of ban wave?

The latter is something I would prefer to avoid.

secure boot enabled with machine owner keys wouldn’t be enough either for these games

They should be able to check which signing keys were used for every part of the boot process. Unless they want to be colossal assholes and check the MOK as well, they could still verify what they need without flagging Linux Secure Boot dual-booters as cheaters.

You quoted the end of my comment, so you must have read this part:

Together, they make it possible for anticheat to tell if something (like cheating software) tried to rootkit Windows as a way to evade detection.

For the threat model of anticheat software, verifying system integrity is not an unusual requirement.

Amazing. Crowdstrike did end up providing some benefit to users after all.

Once you delve into the technical specifics of Secure Boot and the TPM, it’s actually not that unusual. I wrote more detail in another comment on this post, but the TLDR of it is that Secure Boot is meant to enforce the integrity of the boot procedure to ensure that only approved code runs before the Windows kernel gets control, and the TPM 2.0 is meant to attest to that. Together, they make it possible for anticheat to tell if something (like cheating software) tried to rootkit Windows as a way to evade detection.

I don’t agree with the requirement, but it’s not a pointless requirement or some grand conspiracy to make people buy new hardware.

Sorry to see the downvotes buddy, people are cult-ish. You aren’t wrong.

The entire idea of Secure Boot is to verify the boot chain using signature checks to ensure that nothing “unauthorized” runs in the boot process before control is handed off to the kernel. It’s meant to stop lower bootloader stages from silently modifying or hooking later stages.

In theory, it’s supposed to stop rootkits from being able to exist above the OS, hiding themselves while stealing information or influencing programs. In practice, there’s a shit load of badly implemented EFI programs and bootloaders that are signed and later turned out to be vectors for arbitrary code execution (this is why you need the DBX list to be updated frequently).

Cynically, Microsoft probably came up with Secure Boot because that whole rootkit-and-fuck-with-the-kernel thing used to be one of the ways people cracked Windows 7.

As for TPM 2.0, the whole point of it being used for anticheat is because it stores an immutable log of the Secure Boot process and attests to the integrity of the system. If I installed my own Secure Boot certificates and rootkitted Windows for the sole purpose of cheating, the TPM would see that a self-signed executable was used during boot and refuse to say the system was unmodified.

“Keeping users safe on Android is our top priority,” Android president Sameer Samat wrote on X. “Scammers rely on anonymity to scale their attacks. Right now, if we block a bad app, they can often just create a new app and try again. Verification stops this “whack-a-mole” cycle by requiring a real identity – making it much harder and costlier to repeatedly distribute harmful apps.

So, you’re actually going to put an effort in stopping people from publishing malware through the Play Store, right?

Right?

Contrary to popular belief, it is possible to write software in assembly that is very readable. It takes thought but assembly has the edge with its miniscule footprint and zero-dependency runtime.