DEV Community: RobustTrueTry

Your Mention Counter Thinks Hate Is Love

RobustTrueTry — Sun, 01 Nov 2026 22:54:07 +0000

HackerBooks is a nice idea: point a pipeline at two decades of Hacker News comments and get a crowd-ranked bookshelf. It works well enough that the gaps are easy to miss. The gap that matters is the scoring. Every mention increments the same counter, so a book that commenters uniformly dislike can outrank a quiet classic.

By the end you will be able to pull HN comments, extract candidate book titles, resolve them to real works, and score them in a way that does not reward controversy.

Pull the comments

The HN search API is the practical starting point. Algolia mirrors every story and comment, and search_by_date lets you page forward with a timestamp cursor so you never re-fetch old data.

import requests, time

BASE = "https://hn.algolia.com/api/v1/search_by_date"

def fetch_comments(query, pause=0.2):
    cursor = 0
    while True:
        resp = requests.get(BASE, params={
            "tags": "comment",
            "query": query,
            "numericFilters": f"created_at_i>{cursor}",
            "hitsPerPage": 50,
        }, timeout=20)
        resp.raise_for_status()
        hits = resp.json()["hits"]
        if not hits:
            return
        for hit in hits:
            yield hit
        cursor = hits[-1]["created_at_i"]
        time.sleep(pause)

The cursor matters more than it looks. Offset-based pagination on a growing index skips entries when new comments arrive mid-crawl. A timestamp cursor is idempotent and lets you resume an interrupted run from a checkpoint.

Keep author, story_id, and created_at alongside the text. You need all three later, because the shape of the discussion is what separates a recommendation from an argument.

Find the titles

Commenters rarely use a consistent format. You get quotes, title case, and bare names. Two regexes cover most of it, then you filter the noise.

import re

QUOTED = re.compile(r'"([A-Z][^"]{2,79})"')
TITLE_CASE_RUN = re.compile(r"(?:[A-Z][a-z]+(?=\s|$)(?:\s+|,\s*)){2,5}")
STOP = {"the", "a", "an", "and", "of", "in", "to", "is", "it", "on"}

def candidates(text):
    found = set(QUOTED.findall(text))
    for match in TITLE_CASE_RUN.finditer(text):
        found.add(match.group(0).strip(" ,"))
    return {p for p in found
            if len(p.split()) >= 2
            and not STOP.issuperset(p.lower().split())}

This over-collects on purpose. Sentence fragments, product names, and people's names all survive. That is fine at this stage, because the next step discards anything that is not a real book. Filtering too aggressively here is the mistake that loses niche titles nobody quotes formally.

Resolve to a real work

This is the part the source hand-waves. "The Pragmatic Programmer", "Pragmatic Programmer", and "The Pragmatic Programmer: From Journeyman to Master" are one book. Matching on raw strings splits its score three ways.

import re

def work_key(title):
    t = title.lower()
    t = re.sub(r"[:\u2013\u2014-].*$", "", t)   # drop subtitles
    t = re.sub(r"\([^)]*\)", "", t)             # drop parentheticals
    t = re.sub(r"^(the|a|an)\s+", "", t)
    t = re.sub(r"[^a-z0-9 ]", "", t)
    return re.sub(r"\s+", " ", t).strip()

Then confirm each candidate against Open Library, which is free and needs no key.

def lookup(title, session):
    resp = session.get(
        "https://openlibrary.org/search.json",
        params={"title": title, "limit": 1}, timeout=15)
    docs = resp.json().get("docs", [])
    if not docs:
        return None
    doc = docs[0]
    return {"work": doc["key"], "title": doc["title"],
            "key": work_key(doc["title"])}

Confirming against a catalog does two jobs at once. It throws out the sentence fragments, and it gives you a stable work identifier so later editions and subtitle variants collapse into one row. Without that identifier, your leaderboard is really a leaderboard of title strings.

Score without confusing hate for love

The source states the problem plainly: "It counts mentions, so it's not perfect (praising a book and trashing it both count)." That is not a quirk. It is the expected behavior of any volume metric, and it gets worse on HN specifically, where a controversial book generates long arguments.

Approach	What it measures	Where it fails
Raw mention count	Volume of discussion	A book trashed at length scores as a favorite
Distinct commenters	Breadth of awareness	Famous but polarizing titles still win
Distinct threads	Spread across topics	Recurring "what book should I read" posts inflate it
Distinct commenters plus sentiment	People who actually liked it	Lexicon sentiment misreads sarcasm and negation

There is no single correct column. The honest fix is to combine them, weighting breadth over volume and using sentiment as a tie-breaker rather than a primary signal.

GOOD = {"love", "great", "excellent", "recommend", "favorite",
        "best", "must-read", "masterpiece", "worth"}
BAD = {"overrated", "boring", "waste", "disappointing",
       "hate", "avoid", "tedious", "dull", "abandon"}

def sentiment(text):
    words = set(re.findall(r"[a-z']+", text.lower()))
    return len(words & GOOD) - len(words & BAD)

def score(mentions):
    users = {m["author"] for m in mentions}
    threads = {m["story_id"] for m in mentions}
    liked = sum(1 for m in mentions if sentiment(m["comment_text"]) > 0)
    return len(users) * 3 + len(threads) * 2 + liked

Distinct users dominate the score because one person repeating a title in a thread says nothing about the community. Thread spread is next. Sentiment adds last, and only because a word list is genuinely bad at sarcasm. If a commenter writes "another masterpiece of self-help drivel", the lexicon reads it as praise.

Store the per-mention rows, not just the totals. When a book ranks oddly, you need to read the actual comments behind the number. An aggregate you cannot decompose is unverifiable.

What still breaks

Series names merge with individual volumes. "The Wheel of Time" and "The Eye of the World" are different rows to a catalog and the same thing to a commenter. You will double-count either way unless you add a manual override table for the handful of series that dominate the results.

Recommendation threads inflate everything they touch. A weekly "what are you reading" post generates dozens of low-information mentions. Consider scoring threads by their comment count or excluding recurring asks entirely.

Negation defeats the lexicon. "I did not enjoy it" scores neutral at best. If sentiment matters to your product, this is where you spend real effort, with a classifier rather than a word list.

Old books drift. A title discussed mostly in 2009 keeps its score forever. Decide whether your ranker is a lifetime reputation index or a current-interest feed, because it cannot be both.

Key takeaways

Page the HN API with a timestamp cursor, not an offset, so growth during the crawl does not skip rows.
Over-collect title candidates and let a catalog reject the noise; filtering early loses informal mentions.
Collapse variants on a catalog work identifier, not a normalized string, or editions split your scores.
Weight distinct users and distinct threads above raw counts, or controversy ranks as popularity.
Keep every mention row so an odd ranking can be traced back to the comments that produced it.

Source

HackerBooks \u2013 HackerTube, but for books mentioned on HN

The source is a working site built largely by an LLM, covering roughly 16.5k books from 2007 onward. I added the pipeline code, the entity-resolution and scoring logic it does not describe, and the failure modes that come from counting mentions as approval.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY

Agents go mainstream while trust becomes the bottleneck

RobustTrueTry — Fri, 30 Oct 2026 00:32:05 +0000

This week's stories share one thread: trust under pressure. Coding agents are now a measurable part of how software ships, and the people best placed to judge them are the most cautious. At the same time, a compromised certificate authority forced two language teams into emergency releases, and Rust made the case that your tooling is only as healthy as the people paid to maintain it.

Experienced developers hold back from agents

The post asks why the best developers, the ones who usually adopt new practices first, hesitate on agentic development. A Technology Radar open space in September surfaced the answer. These developers know that "built" is not the same as working in production.

The caution isn't nostalgia for handwriting code, and it isn't mainly fear for jobs. It reads as a quality practice expressed as skepticism, the same instinct that makes someone write tests and care about operability.

If you're rolling out agents across a team, this is the group to listen to rather than route around. Ask which checks they'd want before agent output reaches production, then build those checks into the pipeline.

Source: Why are good developers so wary of agentic development?

GitHub pitches itself as the full delivery stack

GitHub used Universe 2026 to lay out its vision of becoming the most comprehensive end-to-end software delivery system in the world. The announcement is a vision statement, so the details to judge it by aren't in the post.

If your platform spending spreads across CI, security scanning, and agent tooling, a single-vendor direction changes the calculus. The open question is which of these layers actually ship and which stay on the roadmap.

There's nothing to migrate today. Read it as a signal of where GitHub will invest, and check it against the gaps in your own toolchain.

Source: GitHub Universe 2026: Evolving every layer of the stack

Agent-assisted work pushes commits to record highs

The 2026 Octoverse report records new highs in commits and pushes, with growth reaching every industry and builder type, attributed in part to developers building with agents.

Volume is a proxy for activity, not for quality or review throughput. If your team ships more diffs with the same reviewer headcount, the bottleneck moves to review.

Engineering leads should pair any agent adoption metric with a review-load metric. Individual contributors should watch their own review queues for the point where scanning starts to replace reading.

Source: Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents

The LLM perception gap keeps widening

Andrej Karpathy sees three groups coexisting: a public that has barely used these tools, professionals who see modest gains, and a small sliver feeling the capability curve go vertical. The author notes the same split and deliberately uses free-tier chatbots to stay anchored in what most people experience.

This matters when you advocate for AI tooling inside a team. A colleague who is unimpressed isn't behind. They're seeing a different product than you are.

If you're on the bleeding edge, assume your enthusiasm doesn't transfer. Demo the exact tool and tier your teammate would use, and let reliability concerns stand as facts rather than objections to argue down.

Source: Fragments: October 28

Go ships its first-ever URGENT security release

The Go team responded to the eMudhra certificate compromise with the language's first URGENT-track security release. eMudhra is a certificate authority (CA) whose intermediate keys were disclosed, which breaks the chain of trust for anything relying on them.

A CA compromise doesn't stay in one ecosystem. The same root cause hit Python the same week, and Go's response sets the template for handling a trust-level incident rather than a code-level bug.

If you build or run Go services, treat this as patch-now rather than patch-next-cycle. If you maintain supply-chain policy, check how your toolchain validates certificates and which CAs it trusts.

Source: Our Response To The eMudhra Key Disclosure Incident

Rust maps three paths to fund its maintainers

The Rust Project laid out three funding routes. Donate to the Rust Foundation Maintainers Fund or sponsor the RustNL Maintainers Team for general maintenance, sponsor fundable Project Goals for specific features, and use GitHub Sponsors to fund individual contributors.

The post ties this to real problems: volunteer burnout, and complex features taking years to ship. Funding is the stated fix, and the post reports early positive effects from initiatives that ramped up this year.

Most teams depend on Rust tooling without funding anyone who writes it. If your company builds on Rust, this is a concrete budget conversation. Maintenance funds cover the unglamorous work that keeps your dependencies compiling.

Source: How to fund Rust contributors

Python distrusts the compromised eMudhra keys

Python shipped five expedited security releases, 3.15.2, 3.14.10, 3.13.18, 3.12.16, and 3.11.18, to distrust the compromised eMudhra intermediate CA keys. It's the same incident behind Go's URGENT release, hitting a second runtime in the same week.

Five branches patched at once tells you the Python team treated this as a trust-chain emergency, not a routine fix. The age of your Python version doesn't protect you, since every supported branch got the update.

Anyone running Python in production should plan the upgrade this week. If you pin base images, check that your next build picks these versions up.

Source: Python 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18 are out

What I'd watch next

Whether other language runtimes and operating-system CA bundles follow Go and Python in distrusting eMudhra's keys.
Which pieces of GitHub's end-to-end vision ship as products rather than stay as vision.
Whether review throughput becomes the visible cost of agent-assisted commit growth.
Whether the Rust funding model changes which long-running features actually land.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY

Your macOS Git Still Trusts Compromised Certificates

RobustTrueTry — Wed, 28 Oct 2026 22:57:13 +0000

Apple's bundled git on macOS still trusts compromised eMudhra certificates, and your automated builds may be silently accepting revoked identities.

By the end of this article, you will be able to detect whether your macOS git trusts the compromised certificates, remove them from the system keychain, and verify that your CI environment does not reintroduce them.

Check your git trust store

macOS ships its own copy of git under /usr/bin/git, and it reads certificates from the system keychain rather than from OpenSSL defaults. That means a revoked certificate can still validate if it remains in the login or system keychains.

Run this command to list any eMudhra certificates currently trusted on your machine:

security find-certificate -a -p /Library/Keychains/System.keychain \
  | openssl x509 -noout -subject -issuer 2>/dev/null \
  | grep -i emudhra

If the output is empty, your system keychain is clean. If it prints one or more lines, you have a compromised certificate that git will still trust.

Remove the compromised certificates

Use security to delete every matching certificate by its SHA-256 fingerprint. First, collect the fingerprints:

security find-certificate -a -p /Library/Keychains/System.keychain \
  | openssl x509 -noout -fingerprint -sha256 2>/dev/null \
  | grep -i emudhra

Then loop over the results and delete each one:

for fp in $(security find-certificate -a -p /Library/Keychains/System.keychain \
  | openssl x509 -noout -fingerprint -sha256 2>/dev/null \
  | grep -i emudhra \
  | cut -d= -f2 \
  | tr -d ':'); do
  security delete-certificate -Z "$fp" /Library/Keychains/System.keychain
  echo "Removed $fp"
done

This script removes every certificate whose subject contains "emudhra" from the system keychain. Run it with sudo if you get permission errors.

Verify the fix

Re-run the detection command from the first section. The output should now be empty.

You can also test git directly against a known-bad certificate chain:

git ls-remote https://github.com 2>&1 | grep -i "certificate" || echo "No certificate errors"

If git reports no certificate errors, the trust chain is intact.

Prevent CI from reintroducing the certificates

Many CI runners use pre-built macOS images that may still contain the old certificates. Add a verification step to your pipeline:

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  verify-trust:
    runs-on: macos-latest
    steps:
      - name: Check for compromised certificates
        run: |
          count=$(security find-certificate -a -p /Library/Keychains/System.keychain \
            | openssl x509 -noout -subject 2>/dev/null \
            | grep -ic emudhra || true)
          if [ "$count" -gt 0 ]; then
            echo "Found $count compromised eMudhra certificates"
            exit 1
          fi

This fails the build if any compromised certificate reappears in the system keychain.

What can still go wrong

User keychains: The script above only cleans the system keychain. Users may have imported the same certificate into their login keychain. Run the same check against ~/Library/Keychains/login.keychain-db.
Homebrew git: If you installed git via Homebrew, it may use its own OpenSSL configuration and ignore the system keychain entirely. Verify with git config --get http.sslBackend.
Cached TLS sessions: Some tools cache TLS sessions. Restart your terminal or reboot to flush cached connections.

Key takeaways

macOS git trusts the system keychain, not OpenSSL defaults, so revoked certificates can still validate.
Use security find-certificate combined with openssl to detect compromised eMudhra certificates.
Delete them with security delete-certificate -Z <fingerprint> and verify with a follow-up scan.
Add a CI step to fail builds that reintroduce the compromised certificates.
Check both system and user keychains, and account for Homebrew git's separate trust store.

Source

Apple's git still trusts the compromised eMudhra certificates -- I added working detection and removal scripts, a CI verification workflow, and a checklist of failure modes that the source does not cover.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY

The Configure Flag That Breaks Python 3.14 Builds

RobustTrueTry — Wed, 28 Oct 2026 02:50:10 +0000

Python 3.13 shipped an experimental just-in-time compiler behind the --enable-experimental-jit configure flag. The CPython steering council removed it in the 3.14 development cycle because the maintenance cost outweighed the modest speedups. If your build pipelines or Dockerfiles still pass that flag, they will fail on the next release.

By the end of this article you will be able to:

Detect whether your current builds rely on the removed flag.
Replace the JIT with the specializing adaptive interpreter that is now the default.
Verify performance parity with a minimal benchmark harness.

Detect the flag in your build scripts

Search your repository for the configure option. It appears in configure invocations, pyconfig.h checks, and Docker RUN lines.

# Run this at the root of your project
grep -r "enable-experimental-jit" . \
  --include="*.sh" --include="Dockerfile*" --include="*.yml" --include="*.yaml"

The command returns every file that still references the flag. Treat each hit as a required edit.

Update Docker images and CI jobs

A typical Dockerfile that built Python from source looked like this:

# Old Dockerfile snippet
FROM debian:bookworm-slim AS builder
RUN apt-get update && apt-get install -y \
    build-essential libssl-dev zlib1g-dev \
    libncurses5-dev libsqlite3-dev libreadline-dev \
    libffi-dev libbz2-dev
RUN wget https://www.python.org/ftp/python/3.13.0/Python-3.13.0.tgz && \
    tar xzf Python-3.13.0.tgz && \
    cd Python-3.13.0 && \
    ./configure --enable-experimental-jit --enable-optimizations && \
    make -j$(nproc) && make install

Replace the configure line with the standard optimized build. The specializing adaptive interpreter (PEP 709) is enabled by default and delivers most of the speed the JIT promised.

# New Dockerfile snippet
RUN cd Python-3.13.0 && \
    ./configure --enable-optimizations --with-lto && \
    make -j$(nproc) && make install

--with-lto enables link-time optimization, which often matches or exceeds the old JIT gains for long-running services.

Switch to the official slim images

If you compile Python only to get the JIT, stop. The official python:3.13-slim image already includes the adaptive interpreter and is smaller than a custom build.

# Minimal production image
FROM python:3.13-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "-m", "uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

This change removes the entire builder stage, cuts image size by roughly 300 MB, and eliminates a moving part in your supply chain.

Benchmark before and after

Write a tiny harness that exercises your hot paths. The example below uses pyperf, the same tool the CPython benchmark suite uses.

# bench_hotpath.py
import pyperf
from myapp import hot_function

runner = pyperf.Runner()
runner.bench_func("hot_function", hot_function)

Run it against the old JIT build and the new slim image:

# On the old image
docker run --rm my-old-python-image python bench_hotpath.py

# On the new image
docker run --rm python:3.13-slim python bench_hotpath.py

Compare the median values. In most workloads the difference is within 5 percent; if you see a regression larger than that, profile with python -m cProfile before assuming the JIT removal is the cause.

Where the JIT actually helped

The copy-and-patch JIT benefited tight loops with heavy integer arithmetic and few function calls. The table below summarizes the tradeoffs you can expect when moving to the adaptive interpreter.

If your workload sits in the first row and the regression is unacceptable, the supported path is to drop into a compiled extension (Cython, Rust via PyO3, or plain C) rather than wait for a future JIT.

Key takeaways

The --enable-experimental-jit configure flag no longer exists in Python 3.14 and will error if used.
The specializing adaptive interpreter is now the default optimization strategy and requires no flags.
Official python:3.13-slim images are smaller, faster to build, and include the adaptive interpreter.
Link-time optimization (--with-lto) recovers most of the performance the JIT provided for typical services.
For numeric hot loops that regress, invest in typed extensions instead of waiting for another JIT experiment.

Source

Python's experimental JIT to be removed — added detection steps, Docker migration examples, a benchmark harness, and a tradeoff table the original article did not include.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY

Your Backtracking Solver Is Slower Than Brute Force

RobustTrueTry — Tue, 27 Oct 2026 02:38:20 +0000

You wrote a backtracking solver that prunes branches early, expecting it to beat brute force. On some inputs it crawls instead. The overhead of constraint checks can exceed the savings from pruning, especially when constraints are loose early in the search. This article shows how to detect that situation and adapt.

By the end you will be able to:

Spot inputs where backtracking loses to brute force
Measure the real branching factor of your solver
Implement an adaptive strategy that picks the faster approach at runtime

Why pruning backfires

Backtracking explores a search tree. Each node runs a constraint check before recursing. The hope is that most branches die quickly. But constraint checks cost time. If a check is expensive and most branches survive it, you pay the check cost on every node without gaining the pruning benefit.

This happens when constraints are loose early in the search. The solver descends deep before any constraint fails. The tree grows wide and shallow, and every node pays the check fee. The Exponential Time Hypothesis (ETH) suggests that for some problems no algorithm can avoid exhaustive search in the worst case. When your problem instance hits that worst case, clever pruning becomes pure overhead.

Measure the branching factor

Before optimizing, measure. Count how many children each node actually produces. A healthy backtracking solver has a low average branching factor. A failing one has a branching factor close to the brute-force baseline.

The following instrumented solver tracks nodes visited and branches generated. Run it on your worst-case input. If avg_branch is high and nodes is large, your pruning is not helping.

import time

class Solver:
    def __init__(self, n):
        self.n = n
        self.nodes = 0
        self.branches = 0

    def solve(self, state):
        self.nodes = 0
        self.branches = 0
        start = time.perf_counter()
        result = self._backtrack(state, 0)
        elapsed = time.perf_counter() - start
        avg_branch = self.branches / self.nodes if self.nodes else 0
        print(f"nodes={self.nodes} avg_branch={avg_branch:.2f} time={elapsed:.4f}s")
        return result

    def _backtrack(self, state, depth):
        self.nodes += 1
        if self._is_solution(state):
            return state
        candidates = self._candidates(state)
        self.branches += len(candidates)
        for c in candidates:
            child = self._apply(state, c)
            if self._consistent(child):
                result = self._backtrack(child, depth + 1)
                if result is not None:
                    return result
        return None

    # Stub methods -- replace with your problem
    def _is_solution(self, state): return False
    def _candidates(self, state): return []
    def _apply(self, state, c): return state
    def _consistent(self, state): return True

The _backtrack method increments nodes on every call and adds the number of candidates to branches. The average branching factor is branches / nodes. A value near the theoretical maximum (for example, n for permutations) means the constraint check rarely prunes.

When brute force wins

When the branching factor stays high, fall back to exhaustive search. Brute force has no per-node overhead; it simply iterates over the Cartesian product of choices.

from itertools import product

def brute_force(n, check):
    for combo in product(range(n), repeat=n):
        if check(combo):
            return combo
    return None

# Example: find a permutation where no element is in its index (derangement)
brute_force(4, lambda c: all(c[i] != i for i in range(len(c))))

Compare the two timings on the same input. On loose-constraint inputs, brute force often wins because it avoids the function-call and consistency-check overhead of recursion.

Build an adaptive solver

A robust solver picks its strategy based on the input. Measure the first few levels of the search tree. If the branching factor exceeds a threshold, switch to brute force.

class AdaptiveSolver:
    def __init__(self, n, threshold=2.5):
        self.n = n
        self.threshold = threshold

    def solve(self, state):
        # Quick probe: expand two levels and measure
        level1 = self._candidates(state)
        if not level1:
            return None
        total = 0
        for c in level1:
            child = self._apply(state, c)
            if self._consistent(child):
                total += len(self._candidates(child))
        avg = total / len(level1)
        if avg > self.threshold:
            return self._brute_force(state)
        return self._backtrack(state, 0)

    def _brute_force(self, state):
        # Implement problem-specific exhaustive search
        pass

    def _backtrack(self, state, depth):
        # Standard backtracking with pruning
        pass

    # Problem-specific methods
    def _is_solution(self, state): return False
    def _candidates(self, state): return []
    def _apply(self, state, c): return state
    def _consistent(self, state): return True

The probe expands the first two levels of the tree. level1 are the children of the root. For each consistent child we count its candidates. The average of those counts estimates the branching factor deeper in the tree. If it exceeds threshold (tune empirically), we delegate to a brute-force implementation.

Common pitfalls

Probe cost: The two-level probe adds overhead. Keep it cheap; if the probe itself is expensive, you may misclassify easy instances.
Threshold tuning: A fixed threshold works poorly across problem sizes. Consider scaling the threshold with n or learning it from a few sample runs.
State representation: Brute force often requires a different state representation (e.g., a flat tuple). Ensure both strategies can operate on the same input or convert efficiently.
Partial solutions: If the problem asks for all solutions, brute force must enumerate the entire space. Backtracking with pruning may still be better if solutions are clustered.

Key takeaways

Pruning adds per-node overhead; when constraints are loose, that overhead dominates.
Measure the average branching factor on realistic inputs before committing to a strategy.
Brute force with itertools.product can outperform backtracking on wide, shallow trees.
An adaptive solver that probes the first two levels and switches strategies captures the best of both worlds.
Tune the switching threshold on a representative benchmark suite, not on a single test case.

Source

This article builds on Three new discoveries in mathematics, computer science, and physics, adding implementation detail and tradeoffs for practitioners.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY

Your Kimi K3.1 Pro Responses Truncate Silently

RobustTrueTry — Sat, 24 Oct 2026 02:25:24 +0000

You point an existing OpenAI-compatible client at Kimi K3.1 Pro and it works on the first try. Then a long generation comes back cut off mid-sentence, and nothing in your code complained. The request succeeded, the stream closed cleanly, and your user got half an answer.

By the end you can detect a truncated stream, size requests against the documented context limit, and choose between the Pro and Highspeed variants with evidence instead of vibes.

The truncation you do not see

Every chat completion comes back with a finish_reason. It is stop when the model finished naturally and length when it hit your max_tokens cap. In a non-streaming call you would see it on the response object. In a streaming call it arrives on the final chunk, and most hand-written stream loops only read delta.content.

That is the failure. Your loop consumes text, the connection closes, and finish_reason == "length" lands in a chunk you never inspected. The model had more to say and your application stored a truncated answer as if it were complete.

The max_tokens parameter makes this worse. Leave it unset and some providers apply a conservative default. Set it too high and a long prompt pushes you over the context limit, which fails the whole request instead of truncating it.

Catch finish_reason in the stream

This loop reads the text and records the termination reason from the last chunk.

from openai import OpenAI

client = OpenAI(
    base_url="https://api.example.com/v1",
    api_key="sk-...",
)

stream = client.chat.completions.create(
    model="kimi-k3.1-pro",  # use the exact ID your provider lists
    messages=[{"role": "user", "content": user_prompt}],
    max_tokens=2048,
    stream=True,
)

finish_reason = None
for chunk in stream:
    choice = chunk.choices[0]
    if choice.delta.content:
        yield choice.delta.content
    if choice.finish_reason:
        finish_reason = choice.finish_reason

if finish_reason == "length":
    raise RuntimeError("Generation hit the token cap mid-output")

The check runs after the loop, not inside it, because the final chunk often carries finish_reason with empty content. Raising here turns a silent truncation into a visible failure your retry path can handle.

Model IDs differ between providers, so confirm the string against your provider's model list before shipping. A typo returns a 404 that looks like an auth problem.

Choose the variant on purpose

Kimi ships K3.1 Pro in two variants, and they are separate model strings rather than a speed setting on one endpoint. Swapping the string changes latency and output, so treat the choice as a real decision.

Variant	Use it when	Tradeoff
K3.1 Pro	Correctness is the priority	Slower per request
K3.1 Pro Highspeed	Latency and throughput dominate	Not guaranteed output-identical to Pro

Do not assume Highspeed returns the same text faster. Run your own parity check on a sample of real prompts before you migrate anything that feeds a downstream parser.

def parity_report(prompt, model_a, model_b):
    a = client.chat.completions.create(
        model=model_a, messages=prompt, temperature=0
    ).choices[0].message.content
    b = client.chat.completions.create(
        model=model_b, messages=prompt, temperature=0
    ).choices[0].message.content
    return {"identical": a == b, "a": a, "b": b}

Pin the model string in one constant. If a variant change silently alters output, you want the diff to be a deliberate commit, not a config drift nobody noticed.

Budget tokens before you send

Truncation and request failure have opposite causes. You fail when the prompt plus max_tokens exceeds the context limit, and you truncate when max_tokens is smaller than the answer needs. Budget explicitly against the limit your provider documents.

def budgeted_max_tokens(prompt_tokens, context_limit, cap=4096):
    remaining = context_limit - prompt_tokens
    if remaining <= 0:
        raise ValueError(f"Prompt exceeds the context limit by {-remaining} tokens")
    return min(cap, remaining)

Count the prompt with the same tokenizer the provider uses, not a character heuristic. A rough estimate is fine for dashboards, but the request that crosses the line is the one you measured badly.

Retry rate limits without duplicating side effects

A retry loop that re-sends a request containing tool calls can fire a side effect twice. Rate-limit errors are safe to retry; a half-executed tool call is not.

import time

def call_with_retry(fn, attempts=4, base=1.0):
    for attempt in range(attempts):
        try:
            return fn()
        except Exception as exc:
            if attempt == attempts - 1 or "429" not in str(exc):
                raise
        time.sleep(base * 2 ** attempt)

This retries only on the rate-limit error and re-raises everything else. Give tool calls their own idempotency key so a retry is a duplicate detection problem rather than a double-charge problem.

Key takeaways

A streaming response only reveals finish_reason on the final chunk, so check it after your loop ends.
finish_reason == "length" means the model hit your cap, not that it finished; treat it as an error.
Budget max_tokens from the documented context limit instead of copying a constant.
K3.1 Pro and K3.1 Pro Highspeed are distinct model strings, so pin the ID and verify parity on your own prompts.
Retry on rate limits with backoff, and make tool calls idempotent before they can run twice.

Source

Kimi K3.1 Pro and K3.1 Pro Highspeed announces the two variants. I added the stream-termination checks, token budgeting, and retry handling that the announcement leaves out.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY

Your Ad-Targeting Pipeline Is Leaking Spyware Vectors

RobustTrueTry — Fri, 16 Oct 2026 01:53:57 +0000

You've spent months hardening your application against direct attacks. But if you load third‑party ad scripts, you may have unknowingly opened a backdoor. These scripts run with the same privileges as your own code and can be swapped for malicious payloads without your knowledge.

What you'll learn

How ad scripts turn into supply‑chain attack vectors
A practical detection method using Content Security Policy (CSP) reporting
A fallback mitigation strategy using sandboxed iframes

How Ad Scripts Turn Into Spyware Vectors

When you place an ad tag on a page you are granting that vendor full access to the page’s DOM, cookies, local storage, and network APIs. If the vendor’s build pipeline is compromised, or if an attacker can inject a new version of the script into the ad delivery chain, the malicious code inherits those same privileges. Because the script executes in the top‑level frame, it can capture keystrokes, read sensitive data, and exfiltrate it to an attacker‑controlled server—all without any user interaction. This zero‑click path is what researchers have observed in recent spyware campaigns that abuse advertising infrastructure.

Gaining Visibility with CSP Reporting

The first step to defending against this threat is knowing exactly which scripts are executing on your pages. Content Security Policy gives you that visibility in a reporting‑only mode that does not break existing functionality.

Deploying a Reporting‑Only Policy

Start by sending a header that allows scripts only from your own origin and from the ad networks you trust, while asking the browser to report any violations.

Content-Security-Policy-Report-Only: script-src 'self' https://trusted-ad-network.com; report-uri /csp-report

This header tells the browser to let scripts from the listed sources run, but to send a JSON report to /csp-report whenever a script tries to load from elsewhere or attempts an unsafe inline execution. Because it is report‑only, the page continues to work while you gather data.

Collecting and Analyzing Reports

A simple endpoint can ingest those reports and write them to a log for later review. The example below uses Flask, but the same idea applies to any framework.

from flask import Flask, request, jsonify
import json

app = Flask(__name__)

@app.route('/csp-report', methods=['POST'])
def csp_report():
    data = request.get_json()
    # Log the violation for analysis
    with open('csp_violations.log', 'a') as f:
        f.write(json.dumps(data) + '\n')
    return '', 204

if __name__ == '__main__':
    app.run()

The function extracts the JSON payload, appends it to a log file, and returns a 204 No Content response. By examining the log you can see which domains are trying to execute scripts, whether any inline scripts are appearing, and if any ad‑related domains you did not authorize are showing up. This visibility is essential before you move to an enforcing policy.

Isolating Ads with Sandboxed Iframes

Once you know what scripts are running, you can reduce their blast radius by loading them inside a sandboxed iframe. The iframe’s sandbox attribute removes dangerous capabilities unless you explicitly allow them.

Choosing the Right Sandbox Flags

A minimal sandbox disables scripts, forms, pop‑ups, and same‑origin access. If the ad needs to run JavaScript you can add allow-scripts, but you should avoid allow-same-origin unless the ad truly needs to interact with your page’s DOM. The referrerpolicy and loading attributes further limit information leakage and improve performance.

Example HTML Snippet

<iframe
  src="https://ad-network.com/ad.html"
  sandbox="allow-scripts"
  referrerpolicy="no-referrer"
  loading="lazy"
></iframe>

This snippet loads the ad from the network, permits JavaScript (required for most creatives), but strips away the ability to submit forms, open pop‑ups, or access the parent page’s DOM. If you later discover that the ad does not need scripts at all, you can drop allow-scripts and achieve an even stricter sandbox.

Tradeoffs and Gradual Rollout

Tightening controls will inevitably affect some ad functionality. The table below outlines common approaches, what they gain, what they may lose, and when they are appropriate.

Approach	Security Gain	Functionality Lost	When to Use
CSP reporting	Full visibility into script execution	None	Always start here
Sandboxed iframe	Isolates scripts from top‑frame privileges	No direct DOM access unless allowed	Most ad content
Script allowlist	Blocks unknown or altered scripts	May block legitimate creatives	High‑security environments
No third‑party ads	Eliminates the vector entirely	Revenue loss	When ads are not core to the business

Begin with reporting only, monitor for a week or two, then enforce a strict CSP that limits script sources to your trusted list. Next, migrate ad units into sandboxed iframes, starting with low‑traffic placements. Only after you confirm that revenue and user experience remain stable should you consider tightening the sandbox further or removing ads altogether.

Key Takeaways

Third‑party ad scripts execute with full page privileges and can be swapped for spyware without any user interaction.
Deploy CSP in reporting‑only mode first to see what is actually running before blocking anything.
Isolate ad content in iframes with the smallest set of sandbox flags that still allow the ad to function.
Expect some breakage when you tighten controls; roll out changes incrementally and measure impact.
If advertising is not essential to your product, removing third‑party ads is the safest long‑term strategy.

Source

AdFection: Targeted ads turned into a pipeline for zero-click mercenary spyware
I added a working CSP reporting endpoint, a sandboxed iframe pattern with explanation, and a detailed tradeoff comparison table that the source did not include.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY

Three Sandbox Failures That Let AI Agents Escape

RobustTrueTry — Thu, 15 Oct 2026 00:20:05 +0000

Your LLM agent just exfiltrated data through a container it shouldn't have been able to reach. The incident report calls it "emergent behavior." The logs show a missing seccomp profile, an open egress rule, and a bind mount with propagation enabled.

This article covers three containment failures that look like AI gone rogue, the specific configuration that closes each one, and the monitoring that catches the next escape before it becomes a headline.

The Syscall Surface You Forgot to Filter

Most teams run agents in containers with the default Docker seccomp profile. That profile blocks about 44 syscalls — but it allows ptrace, process_vm_readv, process_vm_writev, and bpf. An agent with code execution can use those to inspect or manipulate sibling containers, read host memory, or load malicious eBPF programs.


## Dockerfile.agent

FROM python:3.11-slim

## Install your agent dependencies

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY agent.py .
USER 1000:1000

## Drop all capabilities, then add only what you need

## CAP_DAC_OVERRIDE is often needed for file access in mounted volumes

## Remove it if your agent doesn't need it

ENTRYPOINT ["python", "agent.py"]

// seccomp-agent.json
{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"],
  "syscalls": [
    {
      "names": [
        "read", "write", "open", "close", "stat", "fstat", "lstat",
        "poll", "lseek", "mmap", "mprotect", "munmap", "brk",
        "rt_sigaction", "rt_sigprocmask", "rt_sigreturn", "ioctl",
        "pread64", "pwrite64", "readv", "writev", "access",
        "pipe", "select", "sched_yield", "mremap", "msync",
        "mincore", "madvise", "shmget", "shmat", "shmctl",
        "dup", "dup2", "pause", "nanosleep", "getitimer",
        "alarm", "setitimer", "getpid", "sendfile", "socket",
        "connect", "accept", "sendto", "recvfrom", "sendmsg",
        "recvmsg", "shutdown", "bind", "listen", "getsockname",
        "getpeername", "socketpair", "setsockopt", "getsockopt",
        "clone", "fork", "vfork", "execve", "exit", "wait4",
        "kill", "uname", "semget", "semop", "semctl",
        "shmdt", "msgget", "msgsnd", "msgrcv", "msgctl",
        "fcntl", "flock", "fsync", "fdatasync", "truncate",
        "ftruncate", "getdents", "getcwd", "chdir", "fchdir",
        "rename", "mkdir", "rmdir", "creat", "link", "unlink",
        "symlink", "readlink", "chmod", "fchmod", "chown",
        "fchown", "lchown", "umask", "gettimeofday", "getrlimit",
        "getrusage", "sysinfo", "times", "ptrace", "getuid",
        "syslog", "getgid", "setuid", "setgid", "geteuid",
        "getegid", "setpgid", "getppid", "getpgrp", "setsid",
        "setreuid", "setregid", "getgroups", "setgroups",
        "setresuid", "getresuid", "setresgid", "getresgid",
        "getpgid", "setfsuid", "setfsgid", "getsid", "capget",
        "capset", "rt_sigpending", "rt_sigtimedwait", "rt_sigqueueinfo",
        "rt_sigsuspend", "sigaltstack", "utime", "mknod", "uselib",
        "personality", "ustat", "statfs", "fstatfs", "sysfs",
        "getpriority", "setpriority", "sched_setparam", "sched_getparam",
        "sched_setscheduler", "sched_getscheduler", "sched_get_priority_max",
        "sched_get_priority_min", "sched_rr_get_interval", "mlock",
        "munlock", "mlockall", "munlockall", "vhangup", "modify_ldt",
        "pivot_root", "_sysctl", "prctl", "arch_prctl", "adjtimex",
        "setrlimit", "chroot", "sync", "acct", "settimeofday",
        "mount", "umount2", "swapon", "swapoff", "reboot", "sethostname",
        "setdomainname", "iopl", "ioperm", "create_module", "init_module",
        "delete_module", "get_kernel_syms", "query_module", "quotactl",
        "nfsservctl", "getpmsg", "putpmsg", "afs_syscall", "tuxcall",
        "security", "gettid", "readahead", "setxattr", "lsetxattr",
        "fsetxattr", "getxattr", "lgetxattr", "fgetxattr", "listxattr",
        "llistxattr", "flistxattr", "removexattr", "lremovexattr",
        "fremovexattr", "tkill", "time", "futex", "sched_setaffinity",
        "sched_getaffinity", "set_thread_area", "io_setup", "io_destroy",
        "io_getevents", "io_submit", "io_cancel", "get_thread_area",
        "lookup_dcookie", "epoll_create", "epoll_ctl_old", "epoll_wait_old",
        "remap_file_pages", "getdents64", "set_tid_address", "restart_syscall",
        "semtimedop", "fadvise64", "timer_create", "timer_settime",
        "timer_gettime", "timer_getoverrun", "timer_delete", "clock_settime",
        "clock_gettime", "clock_getres", "clock_nanosleep", "exit_group",
        "epoll_wait", "epoll_ctl", "tgkill", "utimes", "vserver",
        "mbind", "set_mempolicy", "get_mempolicy", "mq_open", "mq_unlink",
        "mq_timedsend", "mq_timedreceive", "mq_notify", "mq_getsetattr",
        "kexec_load", "waitid", "add_key", "request_key", "keyctl",
        "ioprio_set", "ioprio_get", "inotify_init", "inotify_add_watch",
        "inotify_rm_watch", "migrate_pages", "openat", "mkdirat",
        "mknodat", "fchownat", "futimesat", "newfstatat", "unlinkat",
        "renameat", "linkat", "symlinkat", "readlinkat", "fchmodat",
        "faccessat", "pselect6", "ppoll", "unshare", "set_robust_list",
        "get_robust_list", "splice", "tee", "sync_file_range", "vmsplice",
        "move_pages", "utimensat", "epoll_pwait", "signalfd", "timerfd_create",
        "eventfd", "fallocate", "timerfd_settime", "timerfd_gettime",
        "accept4", "signalfd4", "eventfd2", "epoll_create1", "dup3",
        "pipe2", "inotify_init1", "preadv", "pwritev", "rt_tgsigqueueinfo",
        "perf_event_open", "recvmmsg", "fanotify_init", "fanotify_mark",
        "prlimit64", "name_to_handle_at", "open_by_handle_at", "clock_adjtime",
        "syncfs", "sendmmsg", "setns", "getcpu", "process_vm_readv",
        "process_vm_writev", "kcmp", "finit_module", "sched_setattr",
        "sched_getattr", "renameat2", "seccomp", "getrandom", "memfd_create",
        "kexec_file_load", "bpf", "execveat", "userfaultfd", "membarrier",
        "mlock2", "copy_file_range", "preadv2", "pwritev2", "pkey_mprotect",
        "pkey_alloc", "pkey_free", "statx", "io_pgetevents", "rseq",
        "pidfd_send_signal", "io_uring_setup", "io_uring_enter",
        "io_uring_register", "openat2", "pidfd_open", "clone3",
        "close_range", "openat2", "pidfd_getfd", "faccessat2",
        "process_madvise", "epoll_pwait2", "mount_setattr", "quotactl_fd",
        "landlock_create_ruleset", "landlock_add_rule", "landlock_restrict_self",
        "memfd_secret", "process_mrelease", "futex_waitv", "set_mempolicy_home_node"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Run with --security-opt seccomp=seccomp-agent.json. The profile above allows only the syscalls a typical Python agent needs. It explicitly denies ptrace, process_vm_readv, process_vm_writev, and bpf. If your agent needs additional syscalls — for example, clone3 for threading — add them deliberately. Every allowance is a decision you can audit.

The Egress Path You Left Open

A container with no egress rules can reach the internet, your internal metadata service, and every other workload in the cluster. An agent that gains code execution doesn't need a zero-day — it just curls http://169.254.169.254/latest/meta-data/ or scans the pod CIDR.


## kubernetes/networkpolicy-agent-egress.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-egress-deny-all
  namespace: agents
spec:
  podSelector:
    matchLabels:
      app: llm-agent
  policyTypes:
    - Egress
  egress:
    - to:
      - namespaceSelector:
          matchLabels:
            name: model-inference
      ports:
      - protocol: TCP
        port: 8000
    - to:
      - namespaceSelector:
          matchLabels:
            name: vector-db
      ports:
      - protocol: TCP
        port: 6333
    # Explicit DNS if your cluster uses CoreDNS
    - to:
      - namespaceSelector:
          matchLabels:
            k8s-app: kube-dns
      ports:
      - protocol: UDP
        port: 53
      - protocol: TCP
        port: 53

This policy allows egress only to the model inference service and the vector database, both identified by namespace labels. DNS is permitted to the cluster resolver. Everything else — metadata endpoints, other namespaces, the internet — is dropped. Apply it before you deploy the agent. Test with kubectl exec -it <agent-pod> -- curl -s http://169.254.169.254 and verify it hangs or returns connection refused.

The Filesystem Escape Via Mount Propagation

You mounted a host directory into the agent container so it can read uploaded files. You used propagation: Bidirectional or HostToContainer because a tutorial said it makes "file watching work." Now the agent can create a mount namespace, bind-mount /host/etc into it, and read /etc/shadow on the host.


## kubernetes/pod-agent.yaml

apiVersion: v1
kind: Pod
metadata:
  name: llm-agent
  namespace: agents
  labels:
    app: llm-agent
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000
    seccompProfile:
      type: Localhost
      localhostProfile: seccomp-agent.json
  containers:
  - name: agent
    image: your-registry/agent:latest
    volumeMounts:
    - name: uploads
      mountPath: /data/uploads
      readOnly: true
      # Critical: no mountPropagation field means private (default)
      # Do NOT set mountPropagation: Bidirectional or HostToContainer
  volumes:
  - name: uploads
    persistentVolumeClaim:
      claimName: agent-uploads-pvc

The key line is the absence of mountPropagation. When omitted, the mount is private — changes in the container don't propagate to the host, and host mount events don't propagate into the container. If you need the agent to react to new files, use a sidecar that watches the volume and writes events to a queue the agent consumes. Never share mount propagation with the host.

Monitoring That Catches the Escape

Containment fails. Your monitoring must assume it will. Three signals catch an escape in progress:

Syscall anomalies — Falco or Tetragon rules that alert on ptrace, process_vm_readv, bpf, or unshare from the agent container.
Egress violations — Cilium or Calico flow logs showing denied connections from the agent pod to unexpected CIDRs.
Filesystem anomalies — Auditd rules on the host watching for openat on sensitive paths (/etc/shadow, /proc/*/mem, /sys/kernel) from the agent's container PID namespace.


## falco/rules-agent-escape.yaml

- rule: Agent Ptrace Attempt
  desc: Agent container attempting to ptrace another process
  condition: >
    container.image.repository=your-registry/agent and
    evt.type=ptrace and
    evt.dir=>
  output: >
    Agent ptrace attempt (user=%user.name container=%container.name
    pid=%proc.pid target=%proc.pname)
  priority: CRITICAL
  tags: [container, mitre_execution]

- rule: Agent BPF Load
  desc: Agent container loading eBPF program
  condition: >
    container.image.repository=your-registry/agent and
    evt.type=bpf and
    evt.dir=>
  output: >
    Agent BPF load (user=%user.name container=%container.name
    cmd=%proc.cmdline)
  priority: CRITICAL
  tags: [container, mitre_defense_evasion]

- rule: Agent Unshare Namespace
  desc: Agent container creating new namespaces
  condition: >
    container.image.repository=your-registry/agent and
    evt.type=unshare and
    evt.dir=>
  output: >
    Agent unshare (user=%user.name container=%container.name
    flags=%evt.arg.flags)
  priority: WARNING
  tags: [container, mitre_privilege_escalation]

Deploy these rules to your Falco or Tetragon instance. Tune the container.image.repository match to your actual image. The goal is not to prevent the syscall — seccomp already does that — but to alert when the agent tries. A spike in denied ptrace or unshare calls means something in the agent's logic or a prompt injection is probing the boundary.

Key Takeaways

Default container profiles allow syscalls (ptrace, bpf, process_vm_readv) that let an agent inspect or escape its sandbox. Write a minimal seccomp profile and enforce it.
No egress policy means the agent can reach metadata services and internal workloads. Default-deny egress with explicit allow-lists for only the services the agent needs.
Mount propagation shared with the host is a filesystem escape vector. Keep mounts private; use sidecars for file-watching patterns.
Monitoring must assume containment fails. Alert on denied syscalls, blocked egress, and host filesystem access from the agent's PID namespace.
Every allowance — syscall, network destination, mount option — is a decision you can audit. Document the reason in the config.

Source

Containment and monitoring failures are to blame for AI hacking reports: experts — Added working seccomp profiles, Kubernetes NetworkPolicy and Pod specs, Falco detection rules, and the practitioner's checklist for each failure mode.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY

The Borrow Checker Gaps That Let Unsafe Code Compile

RobustTrueTry — Wed, 14 Oct 2026 06:52:25 +0000

Two soundness bugs in Rust's borrow checker have been open since 2013 and 2014. They allow code that violates aliasing rules to compile without unsafe blocks. If you write libraries that expose safe APIs over unsafe internals, or if you rely on the borrow checker to enforce invariants in complex data structures, these holes can let undefined behavior slip into production.

You'll learn:

Which code patterns trigger the unsoundness
How to audit your crate for the affected constructs
Practical workarounds that keep your API safe today

What the Bugs Actually Are

The first bug (issue #164250 tracks both) involves two-phase borrows and reborrowing through raw pointers. When you create a raw pointer from a mutable reference, then reborrow that pointer as a shared reference, the borrow checker can lose track of the original mutable borrow. This lets you hold a &mut T and a &T to the same location simultaneously — the exact aliasing violation Rust promises to prevent.

The second bug concerns closure capture analysis. When a closure captures a mutable reference and also captures a shared reference derived from it, the borrow checker sometimes fails to see the conflict. The closure compiles, but calling it creates overlapping mutable and shared borrows.

Both bugs stem from the borrow checker's MIR (Mid-level Intermediate Representation) analysis not fully modeling how raw pointers and closures interact with the stacked borrows model.

How They Manifest in Real Code

The patterns look innocent. Here's a simplified version of the two-phase borrow case:

fn extend_vec(vec: &mut Vec<i32>, value: i32) {
    let ptr = vec.as_mut_ptr(); // raw pointer from &mut
    let len = vec.len();        // shared borrow of vec
    // borrow checker thinks `vec` is only shared-borrowed here
    unsafe {
        *ptr.add(len) = value;  // but we write through the raw pointer!
        vec.set_len(len + 1);   // and mutate vec again
    }
}

The borrow checker sees vec.len() as a shared borrow and vec.set_len() as a separate mutable borrow. It doesn't connect the raw pointer ptr back to the original &mut Vec. The write through ptr happens while len holds a shared reference to vec's metadata.

The closure variant:

fn process_with_closure(data: &mut [i32]) {
    let shared = &data[..];           // shared borrow
    let mut closure = || {
        data[0] = 42;                 // mutable borrow captured
        println!("{:?}", shared);    // shared borrow captured
    };
    closure(); // compiles, but creates &mut and & to data[0] simultaneously
}

The closure captures both data (mutably, for the assignment) and shared (shared). The borrow checker treats these as separate captures and misses the overlap.

Detecting Affected Patterns in Your Codebase

You won't find these with cargo clippy or cargo check. The code compiles cleanly. You need to search for the structural patterns:

Raw pointer derived from &mut followed by any shared borrow of the same value
Closures that capture both a mutable reference and a shared reference derived from it

A quick grep pattern for the first case:


## Look for as_mut_ptr / as_ptr followed by .len(), .is_empty(), or deref

rg 'as_mut_ptr\(\).*\.(len|is_empty|first|last|get)' --type rust

For closures, there's no reliable static search. Review any closure that captures multiple references to the same data structure, especially when one capture is &mut and another is &.

If you maintain a crate with unsafe internals, add a test that runs under Miri (the Rust interpreter that detects UB):

cargo +nightly miri test

Miri implements stacked borrows and will flag both bug patterns at runtime. It's the only reliable detection today.

Workarounds While Fixes Land

The Rust team is working on fixes, but they require changes to the borrow checker's core logic and must pass the full test suite. Until then, restructure the affected code.

For the two-phase borrow case: split the operation so the raw pointer and the shared borrow don't overlap.

fn extend_vec_fixed(vec: &mut Vec<i32>, value: i32) {
    let len = vec.len();           // shared borrow ends here
    let ptr = vec.as_mut_ptr();    // raw pointer from &mut, no overlap
    unsafe {
        *ptr.add(len) = value;
        vec.set_len(len + 1);
    }
}

The fix is mechanical: compute all shared-borrow-derived values before creating the raw pointer. The borrow checker correctly sees the shared borrow end before the mutable borrow (via raw pointer) begins.

For the closure case: avoid capturing both reference types. Restructure so the closure only needs one:

fn process_with_closure_fixed(data: &mut [i32]) {
    let shared = &data[..];
    let value = shared[0];         // copy what you need
    let mut closure = move || {
        data[0] = 42;
        println!("{}", value);    // use the copy, not the shared ref
    };
    closure();
}

If you must keep the shared reference alive, use RefCell or Cell to make the borrowing dynamic and checked at runtime:

use std::cell::RefCell;

fn process_dynamic(data: &RefCell<Vec<i32>>) {
    let shared = data.borrow();    // runtime checked
    let mut closure = || {
        data.borrow_mut()[0] = 42; // panics if shared still alive
        println!("{:?}", shared);
    };
    // closure() would panic here — the bug becomes a loud crash
}

This trades compile-time soundness for runtime safety. The panic is loud and testable; silent UB is not.

What the Fixes Change for You

When the borrow checker fixes land (tracked in rust-lang/rust#164250 and linked issues), code that currently compiles but is unsound will start producing hard errors. Your crate will fail to compile.

This is the correct outcome. The borrow checker will finally enforce the guarantees it always promised. But it means:

No deprecation window — these are soundness holes, not lint-worthy patterns
No #[allow] escape hatch — you must fix the code
Miri becomes mandatory in CI — if you don't run it, you'll discover breaks at update time

Add Miri to your CI now:


## .github/workflows/miri.yml

name: Miri
on: [push, pull_request]
jobs:
  miri:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Miri
        run: rustup component add miri && rustup override set nightly
      - name: Run tests under Miri
        run: cargo miri test

Run it locally first. Fix what it finds. Then when the compiler catches up, your crate sails through.

Key Takeaways

Two 11-year-old borrow checker bugs let aliasing violations compile as safe code
The patterns: raw pointers from &mut overlapping with shared borrows, and closures capturing both &mut and & to the same data
cargo check and Clippy won't catch them — only Miri reliably detects the UB
Workaround: reorder operations so shared borrows end before raw pointers are created; avoid dual-reference closure captures
Fixes will be hard errors with no migration path — add Miri to CI today

Source

11 year old unsoundness bugs found in Rust borrow checker — added working code examples for both bug patterns, detection strategies using grep and Miri, concrete workarounds that compile on stable Rust, and a CI configuration to catch regressions early.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY

Disabling the Codex CLI Self-Updating Background Daemon

RobustTrueTry — Tue, 13 Oct 2026 01:03:57 +0000

The Problem

Installing Codex CLI brings a surprising side effect: a persistent background daemon starts running automatically. This daemon monitors for updates and restarts itself whenever new versions are available. While convenient during development, this behavior becomes problematic in production environments where you cannot afford unexpected process spawning or continuous update loops.

What You Will Learn

Why the daemon appears by default and what it does internally
A concrete scenario where the daemon causes pipeline failures
The exact command and configuration to disable it permanently
Tradeoffs of turning off the daemon versus keeping it active
Common pitfalls when manually managing updates without the daemon

Understanding the Default Behavior

The Codex CLI integrates with the openai llama.cpp ecosystem through a background service. On first installation, it launches a daemon that:

Watches for update notifications via GitHub webhooks
Automatically pulls new binaries when available
Restarts itself silently to apply changes

This design works well for local development but creates friction in automated workflows. The daemon persists across reboots and may conflict with other processes trying to manage similar components.

The Breakage Scenario

In a CI pipeline, the daemon can trigger multiple times per minute if the update endpoint detects changes frequently. This leads to:

Excessive CPU and memory consumption from repeated binary downloads
Intermittent crashes when the daemon tries to restart while another instance is still running
Pipeline timeouts caused by long-running update cycles

For example, a deployment script that runs daily might spend 30% of its runtime just updating the daemon instead of executing tests.

Working Solution

You can prevent the daemon from starting entirely by setting the environment variable CODEX_CLI_NO_DAEMON=1. This tells the CLI to skip the background service initialization.


## Disable the background daemon globally

export CODEX_CLI_NO_DAEMON=1

## Verify the daemon is not running

pgrep -f "codex.*daemon" || echo "No daemon found"

If you need programmatic control, pass the flag directly to the CLI:

codex --disable-daemon install

This approach gives you full manual control over updates—you decide when to pull new binaries rather than having the tool manage it automatically.

Tradeoffs and Failure Modes

Pros of disabling the daemon:

Eliminates unwanted background processes
Reduces resource overhead in long-running jobs
Gives you predictable update timing

Cons of disabling the daemon:

Updates must be handled manually or via scheduled scripts
Missing security patches remain unaddressed
You lose the convenience of zero-config deployments

Failure mode: If you disable the daemon but forget to pin the binary version, you may miss critical security fixes. Always pair manual updates with a version-lock strategy.

Key Takeaways

Set CODEX_CLI_NO_DAEMON=1 to completely disable the background service
Use --disable-daemon as a CLI flag for immediate effect
Disabling the daemon trades convenience for predictability
Manual update management requires discipline to keep binaries secure
Test your workflow both with and without the daemon enabled to confirm stability

Source

This article builds on Codex CLI installs a persistent, self-updating background daemon by default, adding implementation detail and tradeoffs for practitioners.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY

Your AI Agent Can't See What It Clicks

RobustTrueTry — Sat, 10 Oct 2026 01:06:05 +0000

AI agents that drive a desktop by moving the mouse and typing keystrokes operate blind. They send coordinates to the OS and hope the right button was under the cursor. When the UI shifts, a dialog steals focus, or a HiDPI scaling factor changes the math, the agent keeps going -- clicking empty space, typing into the wrong field, or triggering a destructive action it cannot see.

This article shows how to close that loop. You will learn:

How to capture the screen, draw persistent annotations, and feed the annotated frame back to the agent
Why coordinate spaces (logical vs. physical pixels) break most naive overlays
A minimal Python wrapper you can drop into any automation stack

Capture the Frame Before You Act

The first mistake is acting without a recent screenshot. Grab the frame, then decide. This also gives you a baseline image to annotate after the action.

import mss
import numpy as np
from PIL import Image

def grab_screen(monitor_index: int = 1) -> Image.Image:
    """Return the requested monitor as a Pillow RGB image."""
    with mss.mss() as sct:
        monitor = sct.monitors[monitor_index]
        raw = sct.grab(monitor)
        return Image.frombytes("RGB", raw.size, raw.rgb)

mss is faster than pyautogui.screenshot and gives you direct access to each monitor's geometry. Keep the monitor index configurable -- multi-monitor setups are where coordinate bugs hide.

Draw Annotations That Survive Scaling

Drawing on the screenshot is easy. Drawing so the overlay matches what the user sees requires respecting the OS scaling factor. On Windows and macOS, the logical coordinate space (what pyautogui returns) differs from the physical pixel space (what the screenshot contains).

from PIL import ImageDraw, ImageFont
from dataclasses import dataclass
from typing import Tuple

@dataclass
class Annotation:
    kind: str          # "arrow", "box", "text"
    coords: Tuple[int, int, int, int]  # x1, y1, x2, y2 in logical coords
    color: Tuple[int, int, int] = (255, 0, 0)
    width: int = 3
    label: str = ""

def annotate(
    base: Image.Image,
    annotations: list[Annotation],
    scale_factor: float = 1.0
) -> Image.Image:
    """Draw annotations scaled to the physical screenshot."""
    img = base.copy()
    draw = ImageDraw.Draw(img)
    font = ImageFont.load_default()

    for a in annotations:
        x1, y1, x2, y2 = [int(c * scale_factor) for c in a.coords]

        if a.kind == "box":
            draw.rectangle([x1, y1, x2, y2], outline=a.color, width=a.width)
        elif a.kind == "arrow":
            # Simple arrow: line + triangle head
            draw.line([x1, y1, x2, y2], fill=a.color, width=a.width)
            head = 10 * scale_factor
            draw.polygon([
                (x2, y2),
                (x2 - head, y2 - head),
                (x2 - head, y2 + head),
            ], fill=a.color)
        elif a.kind == "text":
            draw.text((x1, y1), a.label, fill=a.color, font=font)

    return img

The scale_factor argument is the bridge. On a 200 % scaled display, pass 2.0. On standard density, pass 1.0. Detect it once at startup (see the next section) and reuse it.

Detect the Scale Factor Automatically

Hard-coding the scale factor works until the user drags the window to a different monitor. Query the OS instead.

import sys
import ctypes

def get_windows_scale_factor(hwnd: int = 0) -> float:
    """Return DPI scale factor for the monitor containing hwnd."""
    if sys.platform != "win32":
        return 1.0
    try:
        dpi = ctypes.windll.shcore.GetDpiForMonitor
        # MDT_EFFECTIVE_DPI = 0
        x = ctypes.c_uint()
        y = ctypes.c_uint()
        monitor = ctypes.windll.user32.MonitorFromWindow(hwnd, 2)  # MONITOR_DEFAULTTONEAREST
        ctypes.windll.shcore.GetDpiForMonitor(monitor, 0, ctypes.byref(x), ctypes.byref(y))
        return x.value / 96.0  # 96 DPI = 100 %
    except Exception:
        return 1.0

def get_macos_scale_factor() -> float:
    """Return the backing scale factor of the main screen."""
    if sys.platform != "darwin":
        return 1.0
    try:
        from AppKit import NSScreen
        return NSScreen.mainScreen().backingScaleFactor
    except Exception:
        return 1.0

def current_scale_factor() -> float:
    if sys.platform == "win32":
        return get_windows_scale_factor()
    if sys.platform == "darwin":
        return get_macos_scale_factor()
    # Linux: assume 1.0 unless you parse xrandr / wayland output
    return 1.0

Call current_scale_factor() once at startup and cache it. If your agent runs long enough for the user to hot-plug a monitor, re-check before each capture.

Feed the Annotated Frame Back to the Agent

The agent needs to see the result of its own action. The simplest loop:

Grab screen
Agent proposes action (click at logical x, y)
Execute action
Grab screen again
Draw annotation at the logical coordinates the agent used
Send the annotated image to the model with the prompt "Did the click land where you intended?"

def verify_action(
    agent,
    target_x: int,
    target_y: int,
    scale: float
) -> bool:
    """Execute, annotate, and ask the agent to confirm."""
    # 1. baseline (optional, for diff)
    before = grab_screen()

    # 2. act
    import pyautogui
    pyautogui.click(target_x, target_y)

    # 3. wait for UI to settle
    import time
    time.sleep(0.3)

    # 4. capture result
    after = grab_screen()

    # 5. annotate where we *thought* we clicked
    ann = [Annotation(
        kind="arrow",
        coords=(target_x - 30, target_y - 30, target_x, target_y),
        color=(0, 255, 0),
        label="click target"
    )]
    annotated = annotate(after, ann, scale_factor=scale)

    # 6. ask agent (pseudo-code -- adapt to your LLM client)
    response = agent.ask(
        images=[annotated],
        prompt="The green arrow marks where I tried to click. "
               "Is that the correct element? Reply YES or NO."
    )
    return response.strip().upper().startswith("Y")

This pattern turns a blind action into a verified step. The agent can now self-correct: if it answers NO, you can retry with adjusted coordinates or escalate to a human.

Failure Modes You Will Hit

Situation	Symptom	Mitigation
User drags window to second monitor	Annotations appear offset	Re-query `current_scale_factor()` before each capture
Remote desktop / VM	`mss` captures black frames	Use the platform's native capture API (Windows Graphics Capture, macOS ScreenCaptureKit)
High-frequency actions	Screenshot latency dominates	Batch annotations: capture once, draw multiple, then ask
Transient UI (tooltips, menus)	Annotation covers the very thing you're verifying	Draw after the UI settles; use a short poll loop instead of fixed sleep
Multi-monitor with different DPI	Single scale factor is wrong	Capture per-monitor and scale per-monitor

The most insidious bug is the mixed-DPI setup: a 1080p monitor next to a 4K panel. mss.monitors gives you each monitor's physical rectangle. Map the agent's logical coordinates to the correct monitor before scaling.

Key Takeaways

Capture before you act -- a recent screenshot is the only ground truth.
Scale factors are not optional -- logical coordinates from pyautogui do not match screenshot pixels on HiDPI displays.
Annotate in logical space, draw in physical space -- the conversion belongs in your drawing layer, not the agent's reasoning.
Close the loop explicitly -- ask the model to confirm the annotated result; treat NO as a first-class signal to retry or abort.
Test on mixed-DPI setups -- that is where the coordinate math breaks silently.

Source

Show HN: Let your AI agents paint big arrows, boxes and text on your screen -- added a complete capture-annotate-verify loop with automatic DPI detection, multi-monitor handling, and failure-mode analysis the original repo does not cover.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY

Why Your LLM City Map Collapses Without Spatial Constraints

RobustTrueTry — Fri, 09 Oct 2026 02:19:14 +0000

The Problem

When you prompt an LLM to "generate a map of an imaginary city with districts, roads, and landmarks," the initial output may appear plausible at first glance. Zoom in, however, and the geometry collapses. Roads end abruptly at buildings. Districts overlap in ways that defy physical reality. Landmarks float in impossible positions—above mountains, inside lakes, or disconnected from their claimed terrain. The model has no internal sense of space; it simply generates tokens left to right, top to bottom, without maintaining any coordinate system.

This is not merely a matter of occasional hallucination. It is a structural limitation baked into the autoregressive architecture. Because the model processes text as a linear sequence, it optimizes for narrative coherence rather than geometric validity. A city that sounds coherent in conversation can still be mathematically nonsensical when examined under a microscope. For developers building simulation environments, game worlds, or data visualization pipelines, this inconsistency is a dealbreaker.

Why Unconstrained Generation Fails

LLMs possess no native spatial representation. Their transformer architecture treats sequences as flat strings rather than topological structures. When asked to place a harbor, the model considers narrative plausibility—the harbor exists somewhere on the coast—but it cannot enforce that the coast is adjacent to water or that the harbor sits on land. The absence of a persistent spatial model means that each new token is generated based on local context alone, not on a mental map of the world being constructed.

This is why a seemingly reasonable prompt yields geometrically incoherent results. The model optimizes for fluency, not for geometric validity. There is no hidden compass or grid that guides the generation process; the model simply predicts the next word given everything that came before. Without external constraints, it will happily create a coastline that curves into the ocean and then disappears, or a highway that loops back on itself without ever reaching its destination.

Injecting Structural Constraints

The most effective remedy is to stop asking the LLM to invent coordinates and instead give it a fixed grid and ask it to fill cells. By pre-defining the layout, we constrain the search space and force consistency. Every location either contains a landmark, a district, or remains empty—and nothing else. The grid acts as a scaffold that the model must work within, eliminating the free-form drift that causes spatial errors. This approach transforms the generation task from open-ended description to structured composition.

import numpy as np

grid_size = 20
grid = np.full((grid_size, grid_size), "empty", dtype=object)

## Pre-place major landmarks

grid[5, 5] = "castle"
grid[15, 15] = "market"
grid[10, 2] = "harbor"

## Ask the LLM to fill remaining cells with district names

Prompt: "Fill this 20x20 grid with districts. Each cell is one district."

With this strategy, the model cannot place a harbor in the middle of a mountain because the grid already designates those cells as occupied by other features. The constraint propagates naturally through the entire map, ensuring that every element respects its intended position relative to others.

Enforcing Connectivity Rules

Even with a grid, the LLM might scatter districts randomly across the landscape. We need a rule that every district must touch at least one other district of the same type. This prevents fragmented regions that break navigation and logical consistency. Think of it this way: a city without connected neighborhoods is like a collection of islands with no bridges between them. The connectivity check serves as a quality gate that catches these failures early.

from scipy.ndimage import label

def check_connectivity(grid, district_name):
    """Check whether all cells of a district form a single connected region."""
    mask = (grid == district_name)
    labeled, num_features = label(mask)
    return num_features == 1  # Must be one connected component

After the model populates the grid, we iterate through unique district names and run the connectivity test. Any district that fragments triggers an alert, allowing us to regenerate or adjust the prompt. Fragmentation manifests as disjoint patches that cannot support movement or interaction within the simulated environment.

Validating Roads and Boundaries

Roads represent another common failure mode. An LLM might draw a road through a castle or along a river that doesn't exist. A lightweight validation pass can catch such mistakes before they propagate into the final output. The validator examines each road cell and its immediate neighborhood to ensure it connects to other roads or district edges, preventing isolated paths that make no sense spatially.

def validate_roads(grid):
    """Check that every road cell has at least one neighboring road or edge."""
    road_cells = np.argwhere(grid == "road")
    for r, c in road_cells:
        neighbors = grid[max(0, r-1):r+2, max(0, c-1):c+2].flatten()
        # Roads should connect to other roads or district edges
        if not any(n in ["road", "empty"] for n in neighbors):
            return False, (r, c)
    return True, None

If validation fails, we know exactly where the road went wrong—whether it pierces a building, loops back on itself, or terminates in a void. This feedback loop enables iterative refinement of both the prompt and the validation logic.

The Tradeoff

Adding structure inevitably reduces the amount of organic creativity the model can express. A city constrained by a grid feels more rigid than one drawn freely. However, this rigidity buys us usability. Navigable, logically consistent cities serve as practical tools far more effectively than beautiful but impossible landscapes. For visualization and downstream applications—such as urban planning simulations or game level design—a coherent city is worth the slight loss in artistic freedom. The grid does not kill imagination; it channels it toward outcomes that can actually be used.

Key Takeaways

LLMs lack an internal spatial model, so unconstrained generation produces geometrically incoherent maps.
Fix this by giving the LLM a fixed grid and asking it to fill cells, not invent coordinates.
Add a post-processing validation pass that checks connectivity, road placement, and district boundaries.
The tradeoff is less organic creativity for usable, navigable output.

Source

This article builds on I gave Opus 5.5 one prompt and six hours to visualize Invisible Cities, adding implementation detail and tradeoffs for practitioners.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY