What’s new? Oh, just your usual dose of 1,000+ micro-patches, mysterious scheduler “optimizations,” and a whole bunch of drivers you didn’t know your toaster needed.

The changelog reads like a novel written by a caffeinated robot: fixes for AMD, tweaks for Intel, a gentle pat on the back for ARM, and a completely normal update to BPF that definitely won’t break your debug setup (again).

Should you upgrade? Of course.

Let me be crystal clear: I hate kernel-level anti-cheat.

I’m not talking about a mild dislike, or a passing irritation. I mean deep, primal, disgust. The kind you feel when you realize the thing you paid for—your game, your entertainment, your free time—comes with a side of invasive rootkit-level surveillance masquerading as “protection.”

You call it BattlEye, Vanguard, Xigncode, whatever the hell you want. I call it corporate spyware with a EULA.

It’s MY Computer, Not Yours

Let’s get this straight: no anti-cheat—none—has any damn business installing itself at the kernel level, the most privileged layer of my operating system. You know who else runs code in the kernel?

Rootkits. Malware. Nation-state surveillance tools.

So, no, I don’t want your “proactive protection system” watching every process I launch, analyzing memory usage, intercepting system calls, and God-knows-what-else while I try to enjoy a couple hours of gaming. That’s not anti-cheat. That’s anti-user.

“But It’s Necessary to Stop Cheaters!”

Don’t feed me that line. You mean to tell me the only way to stop some 14-year-old aimbotting in Call of Duty: Disco Warfare 7 is to give you full access to the innermost sanctum of my machine? Are you serious?

There’s a difference between anti-cheat and carte blanche to run black-box software with system-level privileges. If your defense against wallhacks requires administrator rights on MY computer 24/7, your design is broken.

Cheaters are clever, sure. But so are malware authors. You know what they do? Exploit over-privileged software running in the kernel. You’ve just handed them one more juicy target.

I Didn’t Sign Up to Beta Test Your Surveillance System

Let’s talk about transparency. There isn’t any.

What does your anti-cheat actually do? What telemetry does it collect? What heuristics are used to flag me? Does it store that data? Share it? Sell it? Run in the background when I’m not even playing?

You won’t tell me. You’ve locked it up tighter than Fort Knox and buried it in an NDA-laced support email chain.

And don’t even get me started on false positives. I’ve seen legit players banned for running Discord overlays or having a debugger open from their job. Their appeals? Ignored. Labeled cheaters by automated judgment, with no accountability.

The Irony? You Still Don’t Stop Cheaters

And here’s the kicker. You’re still losing.

Despite all this Big Brother garbage, cheaters still infest games. ESPs, ragebots, HWID spoofers—they’re thriving. Know why?

Because you’re fighting a cat-and-mouse game with people who are smarter, faster, and more motivated than your overfunded security team. You’re just screwing over everyone else in the process.

Enough

I don’t want a rootkit with my copy of Rainbow Six. I don’t want a watchdog in the kernel just to enjoy Escape from Tarkov. I don’t want to sacrifice privacy, performance, or basic control over my system for the privilege of not being called a cheater.

You say your mission is to “keep the game clean.”

I say: start by getting out of my goddamn kernel.

I’ve been working on this for awhile. I want to start writing more about Pytorch. One topic that has been taking a lot of my reading time these days is catastrophic forgetting. Lets dive into it. Catastrophic forgetting is a well-documented failure mode in artificial neural networks where previously learned knowledge is rapidly overwritten when a model is trained on new tasks. This phenomenon presents a major obstacle for systems intended to perform continual or lifelong learning. While human learning appears to consolidate past experiences in ways that allow for incremental acquisition of new knowledge (a huge fucking maybe here btw, in fact, a lot of this is a deep maybe), deep learning systems—especially those trained using stochastic gradient descent—lack native mechanisms for preserving older knowledge. In this article, we explore how PyTorch can be used to simulate and mitigate this effect using a controlled experiment involving disjoint classification tasks and a technique called Elastic Weight Consolidation (EWC).

Why do you care? Recently at work, my boss had to explain in detail how my company makes sure that there is no data left if processing nodes are reused. That really got me thinking about this…

We construct a continual learning environment using MNIST by creating two disjoint tasks: one involving classification of digits 0 through 4 and another involving digits 5 through 9. The dataset is filtered using torchvision utilities to extract samples corresponding to each task. A shared multilayer perceptron model is defined in PyTorch using two fully connected hidden layers followed by a single classification head, allowing us to isolate the effects of sequential training on a common representation space. The model is first trained exclusively on Task A using standard cross-entropy loss and Adam optimization. Performance is evaluated on Task A using a held-out test set. Following this, the model is trained on Task B without revisiting Task A, and evaluation is repeated on both tasks.

import torch
import torch.nn as nn
import torch.nn.functional as F
class MLP(nn.Module):
def init(self):
super().init()
self.fc1 = nn.Linear(784, 256)
self.fc2 = nn.Linear(256, 256)def forward(self, x):
    x = x.view(x.size(0), -1)
    x = F.relu(self.fc1(x))
    x = F.relu(self.fc2(x))
    return self.out(x)

As expected, the model exhibits catastrophic forgetting: accuracy on Task A degrades significantly after Task B training, despite the underlying model architecture remaining unchanged. This result validates the conventional understanding that deep networks, when trained naively on non-overlapping tasks, tend to fully overwrite internal representations. To counteract this, we implement Elastic Weight Consolidation, which penalizes updates to parameters deemed important for previously learned tasks.

def compute_fisher(model, dataloader):
model.eval()
fisher = {n: torch.zeros_like(p) for n, p in model.named_parameters() if p.requires_grad}
for x, y in dataloader:
x, y = x.to(device), y.to(device)
model.zero_grad()
out = model(x)
loss = F.cross_entropy(out, y)
loss.backward()
for n, p in model.named_parameters():
if p.grad is not None:
fisher[n] += p.grad.data.pow(2)
for n in fisher:
fisher[n] /= len(dataloader)
return fis

To apply EWC, we compute the Fisher Information Matrix for the model parameters after Task A training. This is done by accumulating the squared gradients of the loss with respect to each parameter, averaged over samples from Task A. The Fisher matrix serves as a proxy for parameter importance—those parameters with large entries are assumed to play a critical role in preserving Task A performance. When training on Task B, an additional term is added to the loss function that penalizes the squared deviation of each parameter from its Task A value, weighted by the corresponding Fisher value. This constrains the optimizer to adjust the model in a way that minimally disrupts the structure needed for the first task.

Empirical evaluation demonstrates that with EWC, the model retains significantly more performance on Task A while still acquiring Task B effectively. Without EWC, Task A accuracy drops from 94 percent to under 50 percent. With EWC, Task A accuracy remains above 88 percent, while Task B accuracy only slightly decreases compared to the unconstrained case. The exact tradeoff can be tuned using the lambda regularization hyperparameter in the EWC loss.

This experiment highlights both the limitations and the flexibility of gradient-based learning in sequential settings. While deep neural networks do not inherently preserve older knowledge, PyTorch provides the low-level control necessary to implement constraint-aware training procedures like EWC. These mechanisms approximate the role of biological consolidation processes observed in the human brain and provide a path forward for building agents that learn continuously over time.

Future directions could include applying generative replay, using dynamic architectures that grow with tasks, or experimenting with online Fisher matrix approximations to scale to longer task sequences. While Elastic Weight Consolidation is only one tool in the broader field of continual learning, it serves as a useful reference implementation for those investigating ways to mitigate the brittleness of static deep learning pipelines.

Why the hell does this matter? beyond classification accuracy and standard benchmarks, the structure of learning itself remains an open frontier—one where tools like PyTorch allow morons and nerds like me to probe and control the dynamics of plasticity and stability in artificial systems.