TOCTOU: time-of-check to time-of-use
It's a race condition that happens between "checking" and "using" something

this is a common and simple example of it:

  cacheData := cacheMap.Get(key)
  if cacheData == nil {
    cacheData = &BinanceDepthCachedData{
      Coin:       key,
      LastUsedAt: time.Now(),
    }
    cacheMap.Add(key, cacheData)
  }

where Get and Add are atomic (they have a lock in them to prevent concurrent operations); however the entire operation itself is not atomic:

Goroutine A: Get → nil
Goroutine B: Get → nil
Goroutine A: Add(objectA)
Goroutine B: Add(objectB)

since this is a purely logical race, race detectors tool usually can't detect it

The fix is to do the entire check + use with a single lock, e.g:

  mut := hlInfoReqMutexes.GetOrCreateDefault(mutKey)
  mut.Lock()
  defer mut.Unlock()

whereas the GetOrCreateDefault (or GetOrCreate(key, lambda)) use a single lock operation

How bad can this be?

It can range from harmless wasted work to critical security vulnerability
depending on what the created object(s) controls and whether an attacker can trigger concurrent calls:

1. Low severity: duplicate construction

v := cache.Get(key)
if v == nil {
    v = parseConfig(key)
    cache.Add(key, v)
}

Two goroutines parse the same immutable config. One value overwrites the other, but they’re equivalent. just CPU time is wasted

2. Moderate severity: inconsistent or split state

uppose the object contains mutable state. Both callers create different objects, and one gets stored:

A creates objectA and continues using it
B creates objectB and stores it
A stores objectA—or B remains the winner

Now some code may use objectA while future lookups use objectB.

- Lost updates
- Inconsistent counters
- Orphaned resources / Incorrect cleanup (memory leaks)
- Hard-to-reproduce application failures

3. High severity: ineffective per-key locking

A common dangerous example is lazily creating a mutex:

lock := locks.Get(accountID)
if lock == nil {
    lock = &sync.Mutex{}
    locks.Add(accountID, lock)
}

lock.Lock()
defer lock.Unlock()
processWithdrawal(accountID)

Two requests can create and lock two different mutexes. Both enter the supposedly protected operation simultaneously; can result in:

- Double withdrawal
- Duplicate payment
- Oversold inventory
- Duplicate coupon redemption
- Corrupted files or database state

I literally just refactored this bug, it's much much more common than you can ever think of
and it goes unnoticed for a very long time until shit happens

OpenAI just open-sourced Codex Security
Article, Comments

Blake3

is a cryptographic hash function that is:
- Much faster than MD5, SHA-1, SHA-2, SHA-3, and BLAKE2.
- Secure, unlike MD5 and SHA-1. And secure against length extension, unlike SHA-2.
- Highly parallelizable across any number of threads and SIMD lanes, because it's a Merkle tree on the inside.
- Capable of verified streaming and incremental updates, again because it's a Merkle tree.
- A PRF, MAC, KDF, and XOF, as well as a regular hash.
- One algorithm with no variants, which is fast on x86-64 and also on smaller architectures.

the official Rust and C implementations:
https://github.com/BLAKE3-team/BLAKE3

Pure Go implementation of BLAKE3 with AVX2 and SSE4.1 acceleration:
https://github.com/zeebo/blake3

(the chart is a particular optimized benchmark, not a universal speed guarantee)

How to speed up the Rust compiler in July 2026

TL;DR:

Since December 2025, Rust compiler workloads improved by ~5.6% overall ( ~2.9% excluding rustdoc).

Improvements:
- rustdoc: ~38% mean speedup
- Clippy: 10–30% faster by skipping useless lint calls
- New trait solver benchmark: 27s → under 1s
- Smaller AST nodes and fewer memory copies improved cache use
- Incremental compilation received many smaller optimizations

RipGrep musl binaries occasionally segfault during very-large searches
Article, Comments

https://github.com/dfoxfranke/ripgrep-3494-analysis

TL;DR: the Linux kernel briefly forgot a memory write. Not really a ripgrep bug, and probably not a musl bug.

During a massive, highly parallel directory search, one thread allocated a page and wrote musl allocator metadata to it. At the same moment another thread was unmapping memory. A Linux 7.0 kernel race between a fresh page fault and the munmap TLB shootdown replaced that page’s backing. Roughly ten CPU instructions later, the first thread reread its own value and got zero instead. Musl correctly noticed impossible/corrupt allocator metadata and crashed. [1]

The investigator reproduced it with about 1.8 million files / 20 GiB, instrumented musl, matched the disappearing write to the core dump, and found it tracks kernel 7.0.12, not the CPU or ripgrep itself. A Linux 7.0 page-table-reclaim change is the prime suspect, though the precise offending commit isn’t proven yet—and the race was reportedly still present in mainline during the analysis. [1]

So, in technical terms: absolutely cursed kernel VM race, exposed by ripgrep doing allocator violence at scale.

Citations
[1] GitHub - dfoxfranke/ripgrep-3494-analysis: Analysis of one crazy segfault in ripgrep · GitHub

Go 1.27 Interactive Tour

🔸Go 1.27 introduces several new features, including generic methods, improved struct literals, and broader type inference, as well as performance improvements like size-specialized allocation and an experimental SIMD package. Other notable additions include a standard UUID package, a json/v2 package, and various testing and quality-of-life improvements.

02 Aug 2026

💬 comments

New simd package
Go 1.27 introduces a new experimental simd package that provides portable and vector-size-agnostic SIMD support. It will make use of the hardware instructions if they are available. This package is enabled by setting the environment variable GOEXPERIMENT=simd at build time.
The simd package is available on all architectures, and provides vector types of unspecified size such as Int8s and Float32s. It supports a “scalable” subset of the operations present in the simd/archsimd package that are hardware-supported or easily emulated across architectures and vector widths.
See the proposal issue for more details.

New crypto/mldsa package
The new crypto/mldsa package implements the post-quantum ML-DSA signature scheme specified in FIPS 204.
crypto/x509 now supports ML-DSA private keys, public keys, and signatures.
crypto/tls now supports ML-DSA signatures in TLS 1.3, with the new MLDSA44, MLDSA65, and MLDSA87 SignatureScheme values.

According to @glxyresearch, the total losses from the #Coldcard hack may have reached 2,055 $BTC($130M).

More than 7,700 victim addresses have been affected.

A 3D mesh stores:

- Vertex data: the points making up the mesh
- Index-buffer data: instructions describing which points form each triangle

When a mesh is mirrored using a negative scale, such as Scale X = -1, its triangles effectively face the opposite direction.

If bBuildReversedIndexBuffer is enabled, Unreal stores a second copy of the triangle instructions in reverse order. This can make mirrored rendering slightly easier, but it roughly doubles the mesh’s index-buffer memory usage.

Unreal can already render mirrored meshes correctly using "reverse culling"it simply changes which triangle direction counts as the front. Therefore, the second index buffer usually isn’t necessarily required. Unreal’s own HLOD and proxy-mesh generators disable it for this reason.
it exists as a memory-for-performance tradeoff.

So:

ProxySourceModel.BuildSettings.bBuildReversedIndexBuffer = false;

means:

“Don’t create the extra reversed copy. Save memory, because Unreal can render negatively scaled/mirrored instances correctly without it.”

This shouldn’t change how the mesh looks; it only avoids unnecessary storage.