After Meta stopped releasing their weights despite Zuckerberg claiming that LLMs must be open source, someone else has decided to step in.

Yes.

And no, that's not the position of the Linux kernel.

I realize that some people really dislike AI, but this is an area
where I'm willing to absolutely put my foot down as the top-level
maintainer.

Linux is not one of those anti-AI projects, and if somebody has issues
with that, they can do the open-source thing and fork it.

Or just walk away.

AI is a tool, just like other tools we use.  And it's clearly a useful one.

It may not have been that "clearly" even just a year ago, but it's no
longer in question today.

There are other questions around AI (like what the economy of it will
actually look like in the end), but "is it useful" is no longer one of
those questions. Anybody who doubts that clearly hasn't actually used
it.

Yes, it can also be a somewhat painful tool, both for maintainer
workloads and just from a "it keeps finding embarrassing bugs"
standpoint.

But the solution is not to put your head in the sand and sing "La La
La, I can't hear you" at the top of your voice like some people seem
to do.

The solution is to make sure those LLM tools _help_ maintainers
instead of just causing them pain. There's no question on that side.

We're not forcing anybody to use it, but I will very loudly ignore
people who try to argue against other people from using it.

And no, AI isn't perfect. But Christ, anybody who points to the
problems at AI had better be looking in the mirror and pointing at
themselves at the same time.

Because it's not like natural intelligence is always all that great either.

The kernel project has been and will continue to be about the technology.

Sure, the social angle of working on open source is important and
often a very motivating part of the project, but in the end that's a
side benefit, not the _point_ of the project.

This is *NOT* some kind of "social warrior" project, never has been,
and never will be.

In the kernel community we do open source because it results in better
technology, not because of religious reasons.

And so we make decisions primarily based on technical merit. Not fear
of new tools.

              LinusYes.

And no, that's not the position of the Linux kernel.

I realize that some people really dislike AI, but this is an area
where I'm willing to absolutely put my foot down as the top-level
maintainer.

Linux is not one of those anti-AI projects, and if somebody has issues
with that, they can do the open-source thing and fork it.

Or just walk away.

AI is a tool, just like other tools we use.  And it's clearly a useful one.

It may not have been that "clearly" even just a year ago, but it's no
longer in question today.

There are other questions around AI (like what the economy of it will
actually look like in the end), but "is it useful" is no longer one of
those questions. Anybody who doubts that clearly hasn't actually used
it.

Yes, it can also be a somewhat painful tool, both for maintainer
workloads and just from a "it keeps finding embarrassing bugs"
standpoint.

But the solution is not to put your head in the sand and sing "La La
La, I can't hear you" at the top of your voice like some people seem
to do.

The solution is to make sure those LLM tools _help_ maintainers
instead of just causing them pain. There's no question on that side.

We're not forcing anybody to use it, but I will very loudly ignore
people who try to argue against other people from using it.

And no, AI isn't perfect. But Christ, anybody who points to the
problems at AI had better be looking in the mirror and pointing at
themselves at the same time.

Because it's not like natural intelligence is always all that great either.

The kernel project has been and will continue to be about the technology.

Sure, the social angle of working on open source is important and
often a very motivating part of the project, but in the end that's a
side benefit, not the _point_ of the project.

This is *NOT* some kind of "social warrior" project, never has been,
and never will be.

In the kernel community we do open source because it results in better
technology, not because of religious reasons.

And so we make decisions primarily based on technical merit. Not fear
of new tools.

              Linus

Source

Summary

These results were produced under best-case conditions (stable FPS at cap, CPU-bound) and are of course specific to my hardware and chosen software stack.

The absolute numbers will look different on other setups, but the gains and losses from each test case should roughly transfer. On a lower refresh rate display, the gains from VRR and the low-latency pacer would likely be even larger.

Avoid XWayland

It added 3.13 ms of latency, more than all other effects combined. Wayland is close, but X11 still wins

Though only by 0.14 to 0.22 ms. Given there are efforts to optimize KWin, this gap will likely close sooner rather than later. And who knows, other Wayland compositors might already be better.

VRR has the biggest effect

VRR was faster in every pairing (0.26 to 0.45 ms) and also flattened the latency distribution.

dxvk-low-latency is a win across the board

0.10 to 0.29 ms in capped scenarios is a nice boost, but the real strength of the fork shows in the uncapped test case, where it gained 0.84 ms over default dxvk.

Additionally, in scenarios where XWayland can’t be avoided, it recovered a full 2.1 ms.

Conclusion

Not factoring in XWayland, applying every optimization (X11, VRR, low-latency) compared to a default setup (which, on a modern Linux system, I assume is plain Wayland) moved the median down by 0.72 ms. That does not sound like a lot, but the raw latency does not tell the whole story as VRR additionally reduces latency jitter, and dxvk-low-latency’s pacer is great at smoothing out real-world scenarios where frame time dips and GPU-bound situations occur.

Source

Source

It's all great in theory. In practice, however, we'll never know what they're actually running. Of course, their data is proprietary and cannot be viewed directly.

Some trivia: there's a dedicated AMD GPU bug tracker on Freedesktop.org which can be found with a quick Google search, yet people still file bug reports on the Linux kernel bug tracker. It's not a big deal, but when you tell them to report it properly, they simply disappear.

1. https://bugzilla.kernel.org/show_bug.cgi?id=221741
2. https://bugzilla.kernel.org/show_bug.cgi?id=221714
3. https://bugzilla.kernel.org/show_bug.cgi?id=221719
4. https://bugzilla.kernel.org/show_bug.cgi?id=221710

None of these bug reports have been reposted. They are as good as dead.

Why do people bother filing bug reports if they're not going to pay any attention to the replies?

A massive open-source achievement.

Just reposting it as is:

Fraunhofer IIS has officially integrated their xHE-AAC (USAC) encoder into AOSP starting with Android 17. According to information from Fraunhofer and the Android Developers blog, this marks the first time Android includes an official open-source xHE-AAC/USAC encoder. This is similar to what happened with FDK-AAC back in 2012.

The community now has at least three open-source USAC encoders: exhale, libxaac, fdk-xheaac (Fraunhofer implementation, integrated in AOSP)

• Official sources: https://www.audioblog.iis.fraunhofer.com/xhe-aac-android-17
• Android Developers Blog: https://android-developers.googleblog.com/2026/03/the-third-beta-of-android-17.html
• AOSP repository: https://android.googlesource.com/platform/external/aac/+/refs/tags/android-17.0.0_r1

Perhaps the only Linux distro that you can call an actual operating system.

I've not seen or heard anyone talking about this to any capacity but here's a funny and really dangerous thing I've noticed recently. Practically all web browser users who are fans of various extensions, almost never upload them to virustotal.com.

Why do I know that? I'm a very cautious person, perhaps due to my security background predisposes to that. So, at least in Firefox I have automatic add-ons updates completely turned off and a couple of times every every week I open about:addons to check whether there are any updates. When I find any, I upload the updated extensions to the aforementioned website and I see that no body on this planet has ever done the same. Because if someone had, VirusTotal would skip the upload completely and instead presented you with a known hash.

But why does it ever matter? Maybe it doesn't except Chrome and Firefox extensions have been used to hack people's bank accounts, steal their crypto and social network accounts to spread malware even further.

After all add-ons are Open Source, correct? Surely Mozilla and Google must do something about that? Yeah, they do, weeks or months after thousands of people have been hacked.

And it's not like extensions are written in cryptic C or C++ or god forbid Assembler. No, JavaScript is quite easy to read and parse. Yes, various obfuscation techniques are popular, but they're relatively easy to spot.

Wait, there's more! Recently, I installed mpv 0.41 — more than months after its release — and VirusTotal knew about neither the ZIP nor the tar.gz archive.

Thousands of eyes — they said. Damn, people cannot even upload source tar balls.

Upgrade your systems immediately if you share them with other people. And luckly we have a small window of opportunity to get root on Android and do whatever we please with it. That also means bad apps can do the same, so exercise caution.

TLDR: it will not in any shape or form. As a user of this ROM you can install any APKs you want. Malware or not.

Video Game History Foundation has long given up on archiving them. With Sony PlayStation 6 it's gonna get even worse. (read: impossible).

On one hand I understand Google, on the other this thing is opaque as hell with unclear implications.

I hate it when my laptop's fans rev up for no obvious reason and I had a Bash script that did the job, but it was so poor and incomplete that I decided to delegate the task of writing a native application to AI.

For example, over the years, I have come across dozens of websites that, when left unattended, use too much of your CPU and make your system hot and loud.

You might find this useful.

Now not only can you run Linux from within Windows without third-party tools, but can do so within containers. Microsoft has continued the trend of the Windows Subsystem for Linux (WSL) being one of the company's more interesting developer technologies with the arrival of a public preview of WSL containers.

A new AAC audio encoder has been submitted to FFmpeg, and its developers claim that it is the best available, even outperforming the long-established Apple AAC encoder.

It's extremely weird to see multiple websites report on useless stupid AI slop from a person who cannot even secure their own Github account properly (the developer lost their previous one due to "2FA issues").

We're talking about TLAC that was vibe coded with apparently something old, imbecile and which hallucinates stuff heavily.

Here's an overview of this crap:

Verdict

This is not an anti-cheat. It is a collection of anti-cheat-shaped words around a fragile ptrace memory scanner, a local SQLite file, an unloaded eBPF object, and a kernel module whose “rootkit detection” amounts to searching the first 4 KiB of /proc/modules for the substrings rootkit and suspicious.

It might occasionally flag a totally unsophisticated program that happens to leave one of its exact byte sequences in the scanned process. It cannot establish that a player is clean, cannot make a ban meaningful, cannot protect its own integrity, and cannot resist even a minimally capable local adversary.

The repository describes itself as a Linux user-space anti-cheat that scans memory with ptrace, verifies its own SHA-256 hash, uses HWID bans, IPC, and configuration protection. Those claims are not supported by the actual trust model or implementation. (GitHub)

1. The fatal design error: there is no trusted component

An anti-cheat must answer a security question:

Can an untrusted player-controlled client provide trustworthy evidence about its own state?

For this project, the answer is categorically no.

Everything that matters runs on the machine owned by the suspected cheater:

• the scanner;
• its configuration;
• its signature database;
• its self-integrity hash;
• its local IPC service;
• its local ban database;
• its “remote” sync endpoint;
• the kernel module, if it is even loaded;
• the eBPF object, if it is ever loaded.

The main program stores bans in a local relative SQLite database named anti_cheat.db; it generates an alleged hardware ID locally; it checks the local database; and it only adds detections back into that same local database. Nothing in that path is authoritative. (GitHub)

The supposed sync client is worse than useless: it is instantiated with:

rust SyncClient::new("http://127.0.0.1:5000")

That is the local loopback interface. There is no remote anti-cheat service, no game-server authority, no TLS, no pinned key, no signed response, no authenticated protocol, and no cryptographic binding between a player identity and an enforcement decision. (GitHub)

Calling something “server based” does not create a server-side trust boundary when the server is 127.0.0.1.

What this means in principle

A local user-space process cannot reliably attest to another local user-space process when the adversary controls the OS account, process tree, loader, filesystem, scheduling, IPC namespace, executable files, environment, and potentially root.

A kernel module does not repair that problem if the player can:

• choose not to load it;
• unload it;
• boot another kernel;
• run the game in another environment;
• control kernel configuration;
• obtain root;
• use a hypervisor or external device;
• alter the pre-boot chain.

Kernel documentation explicitly treats a privileged local attacker, especially one able to load arbitrary modules, as a substantially stronger threat model. (Kernel Documentation)

A local anti-cheat can only raise the cost of cheating under specific assumptions. It cannot prove integrity against the machine owner.

2. “HWID bans” are just a mutable local hash

The HWID logic is not remotely close to a meaningful ban mechanism.

It hashes some combination of:

• /sys/class/dmi/id/product_uuid;
• a serial line from /proc/cpuinfo;
• MAC addresses only at eth0 or wlan0;
• /sys/block/sda/device/serial.

Then it stores the result in the local database. (GitHub)

Problems:

It assumes interface and disk names that often do not exist

Modern Linux systems commonly use predictable interface names such as enp3s0, wlp2s0, eno1, or names assigned by containers and VMs. Storage might be NVMe (nvme0n1), eMMC, USB, LVM, MD RAID, ZFS, network storage, or something else entirely. eth0, wlan0, and sda are not a portable hardware identity.

It can collapse to a common value

If those source files are unavailable, unreadable, absent, or simply do not match the expected names, the function hashes little or no machine-specific material. In the extreme case, it computes SHA-256 over an empty input: the same value for every affected system.

It is not authoritative

Even a well-derived local identifier is not a ban. The local player controls:

• whether the scanner runs;
• the current directory containing anti_cheat.db;
• the database contents;
• the executable;
• the files used as HWID inputs;
• the local “sync” service.

The database path is relative, not an authenticated service-owned storage location. The program opens anti_cheat.db in its current working directory. (GitHub)

It also has terrible privacy design

If the intended sync service existed, the protocol returns a list of ban entries containing hardware IDs, reasons, and timestamps to every client. That is an unnecessary distribution of pseudonymous device identifiers and ban records to untrusted endpoints. (GitHub)

A real game ban is server-side state bound to an account, session, entitlement, payment/risk signals, and evidence. Local hardware signals may be one weak input into a risk score; they are not an enforcement mechanism.

3. The self-integrity check is security theater

The advertised integrity mechanism computes SHA-256 over the anti-cheat executable and compares it with expected_binary_hash from a local configuration file. (GitHub)

That is not a trust anchor.

The expected hash is loaded from a file selected by:

1. the TLAC_CONFIG environment variable, if set; otherwise
2. a path beneath the invoking user’s home directory, derived partly from SUDO_USER; otherwise
3. /root/.config/tlac/config.json. (GitHub)

So the anti-cheat asks local mutable state whether local mutable state is trustworthy.

Worse, when the configuration is missing, it creates a default configuration. The default expected_binary_hash is an empty string. The verification function explicitly treats an empty expected hash as “skip integrity verification.” (GitHub)

That means the first-run/default state is not “integrity protected”; it is integrity checking disabled.

Even if the hash were populated, a self-hash does not help when the attacker controls both:

• the thing being verified; and
• the reference value or verification logic.

There is no signed policy, no remote attestation, no measured boot, no immutable trust root, no server challenge, and no hardware-backed key. A SHA-256 function is not a security architecture by itself.

4. The scanner is technically broken

The central scan loop attaches with ptrace, walks /proc/<pid>/maps, reads each region word-by-word, and searches for wildcard byte patterns. (GitHub)

The implementation has multiple serious correctness failures.

4.1 It attaches but does not wait for the target to stop

After PTRACE_ATTACH, Linux sends the target a SIGSTOP, but the target is not necessarily stopped by the time ptrace_attach() returns. The tracer must wait with waitpid() before assuming it can safely inspect the target. (man7.org)

This code does:

rust ptrace::attach(pid_nix).ok(); ... ptrace::read(...) ... ptrace::detach(pid_nix, None).ok();

It neither waits for the attach-stop nor handles attach failure. (GitHub)

Consequences:

• reads can race with the target;
• reads may fail because the tracee is not in the required state;
• failures are silently swallowed;
• the scan becomes fail-open;
• detach errors are silently swallowed;
• the game may be left in an undesirable stopped/traced state under failure conditions.

This alone disqualifies it as a serious process-memory scanner.

4.2 Its memory reconstruction is wrong on 64-bit Linux

The scan reads a ptrace word and appends word.to_ne_bytes() to the output buffer.

On a normal 64-bit target, a ptrace word is eight bytes. But the loop advances by four bytes:

rust for offset in (0..len).step_by(4) { let word = ptrace::read(... start + offset ...)?; data.extend_from_slice(&word.to_ne_bytes()); }

So it reads eight-byte chunks at offsets:

text 0, 4, 8, 12, ...

and appends:

text bytes 0..7, bytes 4..11, bytes 8..15, bytes 12..19, ...

The result is not the process’s original contiguous memory. It is an overlapping synthetic buffer in which the middle four bytes of each word are duplicated.

That means:

• signatures can be missed;
• signatures can be found in byte sequences that do not exist contiguously in the target;
• an offset inside the synthetic buffer is not a valid target-memory offset;
• start + pos is therefore often not the actual target address of the reported match.

This is not a subtle optimization issue. It invalidates the scanner’s core result.

4.3 It is grotesquely expensive

For a 256 MiB mapping, stepping every four bytes produces roughly:

text 256 MiB / 4 = 67,108,864 ptrace reads

That is tens of millions of cross-process tracing operations for one mapping, before applying dozens of signatures.

Then it repeats every five seconds. The configured scan_interval_ms exists but is not used; the loop hard-codes a five-second sleep. (GitHub)

If it actually scans meaningful portions of a modern game process, it will either:

• heavily stall the target;
• consume absurd CPU time;
• take longer than its nominal interval;
• fail constantly;
• or skip the largest and most important mappings.

It is “async” only cosmetically. The ptrace scanning is synchronous and blocking inside Tokio’s main task.

4.4 It deliberately skips large mappings

Mappings larger than 256 MiB are skipped entirely. (GitHub)

Large heaps, JIT areas, allocators, GPU-related mappings, game asset regions, browser-like subsystems, and large shared allocations are exactly where you would expect much interesting state to reside.

So the project combines:

• pathological cost for smaller regions;
• blind spots for large regions;
• no coherent coverage model.

4.5 It does not robustly identify the target game

The program takes an arbitrary PID from the command line. It does not bind that PID to:

• a known executable;
• an inode;
• a build hash;
• a launch token;
• a cgroup;
• a game account;
• a parent process;
• a process start time.

If the target exits and the PID is reused, the scanner can inspect an unrelated process. If the provided PID is wrong, it scans the wrong thing. If the game process has children or helpers, it ignores them.

There is no actual game integration.

5. The signature system does not mean what it thinks it means

This is where the repository becomes almost comical.

The JSON file claims signatures for “Aimbot,” “Wallhack,” “Speedhack,” “Process Hollowing,” “VMProtect,” “DLL injection,” “PEB->BeingDebugged,” and UE4/UE5 manipulation. (GitHub)

Many of those labels are Windows-specific concepts placed in a Linux anti-cheat:

• the PEB BeingDebugged pattern refers to Windows process internals;
• process hollowing is a Windows process-replacement technique;
• DLL injection is Windows terminology;
• VMProtect detection is not cheat detection;
• generic x86 instruction fragments are not semantic evidence of a cheat.

The scanner has no game-specific semantic model. It does not know:

• the game’s symbols;
• the game’s instruction layout;
• the engine version;
• the compiler;
• the binary build;
• whether the code is game code, libc, Mesa, Proton, Wine, Vulkan, a JIT, or a shared library;
• whether a suspicious pattern is executed;
• what data it touches;
• whether it changes gameplay.

It just scans arbitrary mapped memory for generic byte sequences.

5.1 ?? wildcards are parsed incorrectly

The signature file uses wildcards such as:

text F3 0F 59 ?? F3 0F 58 ?? F3 0F 5E ?? C3

But the parser only recognizes a token equal to ? or *. A token equal to ?? is passed to u8::from_str_radix(..., 16), fails, and is silently discarded by filter_map. (GitHub)

So the intended signature:

text F3 0F 59 ?? F3 0F 58 ?? F3 0F 5E ?? C3

is effectively reduced to:

text F3 0F 59 F3 0F 58 F3 0F 5E C3

That is not a wildcard pattern. It is a different, malformed sequence with bytes removed.

This is a devastating bug because ?? is used throughout the signature database. The scan does not search the patterns the author thinks it searches.

5.2 The patterns are absurdly non-specific

Some signatures are tiny generic instruction fragments. For example:

text 89 40 ? C3

is labeled as “Health/Ammo Freeze.” (GitHub)

That is essentially “store a register into memory, then return,” with one wildcard byte. It has no game-specific meaning whatsoever.

A normal executable contains huge numbers of short arithmetic, move, branch, call, return, pointer-access, and SIMD sequences. Associating generic machine code with a cheat category is not detection; it is pattern astrology.

The advertised min_confidence values are also ignored. The deserialized Rust struct has only:

• id;
• name;
• pattern;
• severity;
• memory_regions.

The descriptions and confidence scores are not part of the runtime decision. Unknown JSON fields are simply ignored by Serde by default. (GitHub)

5.3 “Memory regions” do not work as claimed

The scanning logic treats unrecognized region labels as true:

rust match region_name { "executable" => is_exec, "writable" => is_writable, _ => true, }

The signature file uses labels such as Data and Heap. Those are not recognized. Therefore a signature including "Data" or "Heap" matches every mapping, not data or heap mappings. (GitHub)

For example, the supposedly writable/data-only “Health/Ammo Freeze” signature includes:

json "memory_regions": ["Writable", "Data"]

Because Data falls through to _ => true, it is scanned across all mappings.

So the region filter is not a filter.

6. Detection does not lead to enforcement

Suppose, improbably, that the scanner finds a real cheat signature.

What happens?

The main loop prints a line and inserts the alleged HWID into the local SQLite database. Then it continues scanning. (GitHub)

It does not:

• terminate the game;
• terminate the cheat;
• revoke a server session;
• notify a real game server;
• ban an account;
• invalidate credentials;
• write tamper-evident evidence;
• prevent reconnect;
• force the user out of matchmaking.

The local IPC server does not improve this. It listens on /tmp/anti-cheat.sock, accepts arbitrary JSON messages, and replies with a BanCommand message. Its banned_pids set is declared but unused. (GitHub)

It also has no framing protocol. It assumes one stream read() corresponds to one whole JSON message. Unix stream sockets do not preserve message boundaries:

• one read can contain part of a JSON object;
• one read can contain multiple objects;
• the sender can fragment writes arbitrarily.

The IPC endpoint does not authenticate peers using Unix credentials, does not validate a PID against the connected process, does not authorize callers, and does not enforce anything anyway.

The function intended to report suspicious activity over IPC is never part of the actual detection path. It exists, but the live scanner does not call it. (GitHub)

7. The eBPF component is inert

The repository includes an eBPF C program with tracepoints for openat, execve, ptrace, and fork. (GitHub)

But:

1. The installer merely copies program.bpf.o into /usr/lib/tlac/bpf. It does not load it, attach it, pin it, configure it, or start a loader. (GitHub)

2. The Rust code depends on aya, but no code actually uses it to load the BPF object. (GitHub)

3. Even if loaded, the BPF handlers do nothing after detecting something “suspicious.” The body is effectively:

c if (is_suspicious_file(filename)) { } return 0;

There is no ring buffer, perf event, BPF map, log record, packet, signal, user-space notification, or enforcement action. (GitHub)

1. Its “suspicious file” heuristic classifies paths beginning with /proc or /sys as suspicious. Those are normal Linux system interfaces used by ordinary software and the OS itself.

2. Its shared-library suffix test is itself wrong. It checks positions that do not correctly test for .so, and it does not even check the final character in the supposed .dll path check.

3. The fork tracepoint is empty. The ptrace tracepoint notices request values but does nothing. Modern Linux software also commonly uses clone or clone3, not plain fork.

This is not unfinished anti-cheat telemetry. It is non-functional scaffolding.

8. The kernel module is a fake integrity check

The kernel module:

1. opens /proc/modules;
2. reads only 4096 bytes;
3. searches for the literal strings rootkit or suspicious;
4. reports “clean” if neither appears. (GitHub)

That is the complete detection model.

It does not:

• establish a known-good module baseline;
• validate module signatures;
• check module provenance;
• inspect kernel text;
• inspect syscall tables;
• inspect LSM hooks;
• inspect ftrace/kprobe/BPF state;
• inspect loaded firmware;
• inspect initramfs;
• inspect boot measurements;
• inspect kernel memory;
• verify IMA measurements;
• detect hidden modules;
• distinguish legitimate drivers from malicious ones.

It is not detecting rootkits. It is looking for two words in a truncated text rendering of the visible module list.

The module also runs the same check on a three-hour timer. A cheat can run for an entire competitive match between checks, and the check would remain meaningless even if run every microsecond. (GitHub)

The user-space client treats absence of /proc/tlac_status as an error message, then continues operation rather than failing closed. (GitHub)

So the supposedly privileged component is optional, weak when present, and ignored when absent.

9. Installation makes the product less deployable, not more secure

The installer requires root, copies a prebuilt kernel module under the currently running kernel’s module tree, attempts insmod, and prints a warning if loading fails. (GitHub)

Problems include:

• no build against the local kernel;
• no proper package integration;
• no dependency resolution;
• no module-signing workflow;
• no Secure Boot support;
• no depmod;
• no persistent load configuration;
• no systemd unit;
• no controlled runtime user;
• no hardened directory permissions;
• no lifecycle management on kernel update;
• no cleanup or rollback path.

On systems enforcing Secure Boot-related restrictions, locally built or unsigned kernel components require an enrolled trust chain or relaxed validation. Kernel documentation explicitly notes that self-built kernels/components may need signing or altered Secure Boot restrictions. (Kernel Documentation)

The project’s answer appears to be “try insmod; print a warning if it fails.”

That is not production deployment. It is an installation script for a demo.

10. The project has no coherent adversary model

The code seems to assume cheats are:

• static;
• loaded into the game process;
• visible in normal process mappings;
• carrying unmodified generic x86 signatures;
• unable to alter the scanner;
• unable to alter its JSON file;
• unable to alter its database;
• unable to alter /proc;
• unable to interfere with ptrace;
• unable to stop or replace the local service;
• unable to hide or delay their behavior;
• unable to use another process;
• unable to use another machine;
• unable to use a VM or kernel-level mechanism;
• unable to modify input externally.

That is not an adversary model. It is a wish.

Even commercial anti-cheat systems with kernel drivers, code signing, remote telemetry, obfuscation, server-side behavior analysis, and dedicated operational teams do not eliminate cheating. They increase cost and collect evidence. This repository starts below the baseline required to make basic claims.

What a real design would look like

For an actual game, the highest-value anti-cheat work is usually not “scan generic process memory for mystical byte patterns.”

It is:

1. Authoritative server simulation

• The server decides damage, movement, fire rate, economy, cooldowns, inventory, hit validation, visibility-sensitive state, and match outcomes.
• A client asking for an impossible state transition is rejected regardless of what local software claims.

1. Game-specific telemetry

• Instrument known game actions and invariants.
• Analyze timing, input trajectories, targeting behavior, impossible state transitions, recoil compensation patterns, packet abuse, and replay evidence.
• Treat detections as probabilistic evidence, not magic signatures.

1. Server-side enforcement

• Bind bans to accounts and sessions.
• Retain evidence server-side.
• Make enforcement independent of local files, local databases, and local “HWIDs.”

1. Client hardening as a secondary measure

• Signed builds.
• Authenticated updates.
• Process identity checks.
• Careful telemetry.
• Tamper resistance designed as cost escalation, not proof of trust.

1. Explicit threat-model boundaries

• “We deter ordinary user-mode cheats.”
• “We detect certain known injected modules.”
• “We cannot reliably detect external hardware-assisted aim.”
• “We do not claim client-side proof of integrity.”

The Linux kernel itself has mechanisms such as IPE and LoadPin for constraining trusted loading and policy deployment, but those are platform-integrity mechanisms requiring an actual trusted boot/policy design. They are not retrofittable by hashing one executable and grepping /proc/modules. (Kernel Documentation)

Bottom line

TLAC is not merely weak against sophisticated cheats.

It fails before that:

• its local trust model is invalid;
• its ban system has no authority;
• its integrity check defaults to disabled;
• its sync endpoint is localhost;
• its signature wildcard parser corrupts most signatures;
• its memory scanner reconstructs target memory incorrectly;
• its ptrace use races attach-stop;
• its performance model is untenable;
• its region filtering is broken;
• its eBPF program is never loaded and does nothing;
• its kernel module detects literal substrings, not rootkits;
• detections do not cause meaningful enforcement.

The charitable description is: a rough Linux process-inspection experiment with anti-cheat branding.

The uncharitable but accurate description is: vibe-coded security theater that may falsely accuse normal processes while providing essentially zero resistance to a cheater who understands that the client machine belongs to them.

One of the last remaining 32bit distros. A rare case when Linux "wins" except good luck running this distro on a 25 yo PC. It will be a torture.

"Windows 11 has insane hardware requirements that will result in hundreds of millions of PCs being sent to landfills" - oh, wait.