I'm using the smaller vision models (Qwen3.5-4B currently) with Frigate, a FOSS self-hosted "AI" NVR. It's good enough at analyzing images to figure out mostly what's happening, and doesn't require the big knowledge base that bigger models have.

Also use a bigger model for summarizing or translating text, which I don't consume in realtime, so doesn't need to be fast. Would be a thing I could use OpenAI's batch APIs for if I did need something higher quality.

> v4 was built around the idea of multiple free standing networks linked by gateways.

I don't think this is what v4 was built around, but rather what v4 turned into.

CIDR wasn't introduced until 1993. NAT in 1994. Both to handle depleting IP addresses.

I've got this bookmarked for tracking: https://gitlab.collabora.com/hardware-enablement/rockchip-35...

Not on this list is the current GPU Vulkan drivers Collabora are working on too. Don't think that's really blame Rockchip since they're ARM Mali-G610 GPUs, but yeah those didn't get stable in Mesa until last year.

Current vetsion of vulkan panfrost notably doesn't run zed. Not just some games, a text editor doesn not get some surface extensions

Similarly sad for their PC38X headset. Though I know they shut down their Epos brand it was under a while ago.

Bcachefs also fulfills the requirement of checksums (and multi device support).

Also out of tree.

Isn't bcachefs even younger and less polished than btrfs? It does show more promise as btrfs seems to have fundamental design issues... but still I wouldn't use that for my important data.

I don't disagree. Gotta backups for important data either way too!

Just talking about filesystems with checksumming (and multidevice). Any new filesystem to support these features is going to be newer.

I've had both btrfs and bcachefs multidevice filesystems lock up read-only on me. So no real data loss, just a pain to get the data into a new file system, the time it was an 8 drive array on btrfs.

Does it not also eat data though?

Another method for gyro aim is flick stick, using the right stick to control the direction of your aim (on the left/right axis) and gyro for fine tuning and also up/down axis.

https://youtu.be/CiSS5OsNCNU from the creator explains it (and older gyro controls).

At least part of it is probably Microsoft's 40 TOPS NPU requirement for their Copilot+ badge. Intel also have NPUs in their modern CPUs. Phones CPU manufacturers have been doing it even longer, though Google calls theirs TPU.

I use an older Google Coral TPU running in my home lab being used by Frigate NVR for object detection for security cameras. It's more efficient, but less flexible than running it on the GPU.

Don't know if I need an NPU for my daily driver computer, but I would want one for my next home server.

It's not the same as EasyAntiCheat and doesn't support the same features. It's like saying Excel works on iPad, but you can't even use VBA on that.

Or a game example: I have Minecraft (Bedrock) on my phone so therefore I should be able to do the same things as Minecraft (Java) on Windows. The problem is they're the same names for different software with similar, but not the same, functionality.

So you're saying that easy anti cheat on linux is different from on windows? I am aware it is not as effective as detecting cheating on linux, but does this affect gameplay itself? Or do game developers not want reduced efficacy of detecting cheaters, and so they don't support linux at all?

I don't play those games myself but the word is that the EAC on linux lacks the same kernel hooks that are available on Windows. I personally consider that a plus but if you're a developer obsessed with strong anti-cheat you probably do not.

Linux kernel provides ways to observe from user space. The problem is that there’s nothing to stop someone running a kernel which neuters anticheat tools ability to observe using that functionality. As far as I’m aware the only way to mitigate that is via measured boot attestation and having signed kernel etc.

Ah, I was under the mistaken impression EAC operated in userspace.

It does on Linux. That's the problem for developers. Unless you're talking about Windows.

I believe most of those work with controller drivers in the application (Dolphin Emulator or Steam/SDL) rather than the OS level. That's why the Windows solution requires Zadig to replace the HID driver.

On Linux instead of replacing the driver, you have to add an udev rule that allows applications to communicate with the USB device directly: https://github.com/ValveSoftware/steam-devices/blob/master/6... And you can see in this list, it's not the only controller with that requirement.

SteamOS includes this by default.

I did add that rule, which if I remember correctly was needed for it to work at all. But then the problem is input lag. Many recommend https://github.com/hannesmann/gcadapter-oc-kmod which the author only tested in Arch, and for whatever reason it didn't work on Ubuntu. Was printing that "Failed to acquire lock for USB device" line and then I think "Could not reset device", don't remember. Anyway seems like a hack.

This was for Slippi Melee, so even though I'm not super good at the game, the lag was too annoying.

The explanation I've heard is simply: Chinese New Years happened, which means a lot more Chinese gamers are online in February during the week long national holiday.

It happened in last year's March stats too: https://web.archive.org/web/20250404061527/https://store.ste... -25%

The number being discussed is not March alone, but the percent change. So March's number relative to February's number.

A holiday that warps numbers in February will no longer be warping things in March.