u/anestling

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.

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

> 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:

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:

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:

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:

0, 4, 8, 12, ...

and appends:

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:

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:

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:

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

is effectively reduced to:

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:

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:

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:

"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:

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)

4. 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.

5. 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.

6. 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.

2. 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.

3. Server-side enforcement

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

4. 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.

5. 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.

If we're talking about what open source guarantees, the list is surprisingly short:

• Access to the source code.
• The legal right to study it.
• The legal right to modify it.
• The legal right to redistribute it (subject to the license).

That's basically it.

It does not guarantee:

• Maintenance.
• Reviews.
• Responsiveness.
• Merged patches.
• Governance rights.
• Democratic decision-making.
• Continuity of development.
• Fork viability.
• User influence.
• Bug fixes.
• Features.
• Course reversal.
• Freedom to use/run: e.g. multiple older Linux applications can no longer run in your fresh Ubuntu 26.04 or Fedora 44 because 1) missing/deprecated dependencies 2) source code that modern compilers think is "bad" 3) incompatible APIs (yeah, including and not limited to X11, GTK1/2, Qt 1/2/3/4, ESD, artsd, OSS, libc5, etc.). 4) Autotools incompatibility. Lastly, good luck using older unmaintained third-party kernel modules in Linux 7.1.

Too bad the second part of the list has been making circles for decades now with nothing to show for it. Extremely important projects that have tens/hundreds of thousands of users simply die off with no one picking them up, including my all time favourite RSS reader, QuiteRSS.

Then tens or even hundreds of thousands of users expressed their dislike of KDE4 and later versions incorporating Plasma, which continues to crash to this day. Been a joke for over 15 years now. KDE before version 4.0 was far more modular and crashed far less.

Remember the drama surrounding Gnome 3.0? Absolutely the same stuff. Open-source developers often don’t seem to develop software for their actual users.

And how Wayland has been developed and pushed is the worst condemnation of the entire Open Source movement. In 2026 we have basically two complete polished implementations where everything works out of the box: KWin/KDE and Mutter/Gnome. Every other implementation is a state of flux with multiple basic desktop features either missing or not implemented completely.

"Forking" that's being invoked all the time is just a huge stinking oversell:

• You must be sufficiently qualified to fork something.
• The project to fork must be sufficiently "simple" to be forkable. Larger projects like Wine, the Linux kernel, GCC, etc. are essentially unforkable because no human being on this planet can realistically maintain them. Even maintaining individual patches for them is a herculean task given how much they change over time.

So have the Linux fans been overselling inherent Linux and Open Source virtues for decades now?

In reality:

• “Open” means user power. No — it means legal rights and visibility.
• “Anyone can contribute.” Technically yes; socially and practically, no.
• “If you don’t like it, fork it.” Often a fantasy unless the project is small.
• “Linux respects users more.” Sometimes. But it also routinely breaks userspace apps, drops APIs, redesigns desktops, and shifts maintenance costs onto users.
• “Community-driven” means users decide. No — maintainers, employers, distros, corporate sponsors, and architectural cliques often decide.

Well, finally, AI giants will at least spend a couple of bucks securing the very software they use to serve AI requests.

Perhaps the most pertinent bits:

>Will consumers jump? Ask whether any AV2 announcement would make Joe Sixpack want a new TV. AV2 delivers nothing he doesn’t already get from the HEVC or AV1 set in his living room. 4K is done, HDR is done; so there is no compelling reason for him to buy, and no consumer pull to compress the schedule the way 4K did for HEVC. YouTube and Netflix may (again) attempt to create that pull, but with YouTube 4K covered, it’s clearly less powerful. > >Will publishers outside the AOM hyper-scalar club rush to AV2? The H.264 test was reach while reducing encoding costs, and AV2 fails it. Every viewer an AV2 stream can reach is already reachable with a codec they already produce, so adopting AV2 doesn’t consolidate their encodes. Instead, it adds an encode, a storage tier, and a fallback path in exchange for some efficiency on the sliver of devices that can decode it. > >Will Meta, Netflix, and YouTube rush to adopt? Without question, but if it’s anything like AV1, they won’t pull other publishers with them.

Brave just announced Brave Origin, a stripped-down version of Brave aimed at users who want the browser's core privacy and ad-blocking features without the growing pile of extras. According to Brave, Origin removes or disables things like Leo AI, Rewards, Wallet, VPN, News, Talk, Web3 integrations, telemetry-related features, and more, leaving essentially Brave Shields + Chromium security updates. It's a one-time purchase on most platforms, but notably free for Linux users.

What's interesting isn't the product itself so much as the admission. For years, a common criticism from privacy-minded users was that Brave kept accumulating features that many people never asked for. Now Brave is effectively saying: fine, here's the minimalist build you've been requesting. ([Brave][1])

As a Linux user, I'm on the fence. On one hand, getting a cleaner Brave build for free is nice. On the other, it's funny watching software gradually bloat and then sell "de-bloating" as a premium feature.

Still, if it means a browser that ships with strong native content blocking and privacy protections while leaving AI, crypto, VPNs, and assorted platform features on the cutting-room floor, I can see the appeal.

Curious what people here think: sensible response to user feedback, or a solution to a problem Brave created itself?

A timestamped summary of the fireside chat between Linus Torvalds and Dirk Hohndel at the 2026 Linux Foundation Keynote:

• [00:13] Milestone Anniversary: This session marks the 30th fireside chat/Q&A event that Linus and Dirk have done together, serving as Linus's preferred alternative to traditional public speaking.
• [01:25] 3D Printing & Code-Based Modeling: Linus discusses his hobbyist love for 3D printing. Coming from a programming background, he prefers code-based descriptive modeling tools (like OpenSCAD) over traditional visual UIs, allowing him to treat physical manufacturing like hardware programming.
• [04:10] The Maturity of Open Source: They note that open source has moved far past the era of being viewed as clunky or "just for engineers," finding mainstream success and high design quality in consumer spaces like 3D printing and Linux-based gaming.
• [05:55] A New Toy Project (Guitar Pedal): Linus reveals his latest open-source personal project: a custom guitar effects pedal. He released both the code and the physical PCB manufacturing/3D-printed housing design files publicly on GitHub.
• [07:25] A Sudden Spike in Linux Kernel Commits: Linus notes that after 20 years of a stable release cadence, the last six months saw a sudden 20% spike in total commits. While he initially assumed it was hype for a major version release, the real driver was a massive influx of code generated by AI tools lowering the barrier to entry.
• [12:03] AI & The Security Mailing List Crisis: Linus addresses a major pain point where developers flooding the kernel's private security mailing list with duplicate, automated AI-generated bug reports. This overwhelmed the small group of maintainers with triage work.
• [13:24] The New AI Bug Policy: To counter the flood, the Linux kernel team enacted a policy: if a bug or security vulnerability is discovered via an AI tool, it must be reported publicly rather than privately. Linus argues that if one person found it using a commercial AI tool, dozens of others have likely uncovered the exact same bug.
• [17:40] "Attention-Seeking" Security Disclosures: Dirk and Linus criticize security companies that immediately publish splashy blog posts or monetize brand logos for vulnerabilities without providing actionable patches or working alongside project maintainers first.
• [19:57] The Long-Term Value of AI: Despite the social and logistical friction, Linus remains highly optimistic about AI in software development. He notes that short-term triage pain is worth the long-term benefit of finding and fixing bugs that otherwise would have remained hidden.
• [22:02] Developer Burnout Beyond Linux: While the Linux kernel has a robust, well-compensated group of maintainers, Linus warns that automated "drive-by" AI bug reports are causing massive burnout for small, understaffed, or solo open-source projects.
• [23:34] AI Tools for Review: Linus highlights that while he doesn't use AI for managing human relationships, the community is embracing automated review tools (such as Google’s patch review tool, Syzbot/Sashiko) and encourages developers to run localized AI models to avoid vendor lock-in.
• [25:57] Advice to New Engineers (AI as a Modern Compiler): Responding to industry doom-and-gloom about AI replacing programmers, Linus compares LLMs to compilers or assemblers. Just as moving from raw machine code to a compiler increased productivity by a thousandfold without killing programming, AI is simply the next abstraction layer.
• [28:45] The Limitations of "Vibe Coding": Linus emphasizes that while AI is brilliant for throwaway scripts, long-term system maintenance (like keeping a project alive for 35 years) requires engineers who deeply understand the underlying system architecture, generated assembly, and outputted code—not just the prompts used to generate it.

1. Elite nerd status.
2. Being proudly different for the sake of being different.
3. The ability to say "I use Linux, by the way."
4. Fighting for "software freedom" while launching a proprietary DRM platform called Steam.
5. Windows "bad".
6. An urgent need to fill your evenings with debugging regressions and filing bug reports nobody will ever read.
7. Enjoying decade-long Linux vs. Windows flame wars that never produce a winner.
8. Acquiring obscure skills such as Bash, shell scripting, and memorizing command-line flags from 1987.
9. Realizing that competitive online gaming isn't that important to you after all, because kernel anti-cheat support on Linux is never, ever coming.

Hope I haven't forgotten any of the major selling points.

Dav2d (fast software AV2 decoder) is being ported to memory safe Rust.

>The entire C decode path has been ported to Rust and is bit-exact with dav2d: every coding-order frame of every shipped conformance clip matches byte-for-byte, with in-loop filters off and on, for both 8-bit and 10-bit streams. 818 library + 16 conformance tests pass.

Not sure if the timing is right. Dav2d has just started, so this Rust port will have to port its changes for years to come.