Cover illustration

TheDaily Front

Issue No. #260809 Sunday, August 9 2026 #260809 — SUNDAY, AUGUST 9, 2026
Agents take notes, old machines wake up, and the weather eats the memory.
Sunday, August 9, 2026 The Daily Front No. #260809 — Contents
30stories
7,653points
5,122comments
272kllm tokens
Assembled with 30 model calls — 185,874 tokens read, 86,066 written.

Highlights

How I use LLMs to learn complex topics

A hands-on learner uses language models to turn unfamiliar chip-production concepts into interactive explanations, stirring a lively argument about accuracy.

My server is a phone now

One home operator roots a budget handset and turns it into a surprisingly capable personal server.

Everything you do is being recorded

A close look at the expanding apparatus that records movements, conversations, and ordinary life.

We replaced Redis with MySQL for inventory reservations and it scaled

An inventory team replaces Redis with MySQL locking strategies and finds the supposedly simpler stack can scale.

Ask HN: What are you working on? (August 2026)

The monthly workshop roll call brings more than a thousand comments’ worth of projects, curiosities, and ambitions.

From the Editor

The machine age has acquired a new habit: it not only answers questions, it takes assignments. Today’s dispatches find readers testing that bargain everywhere—from private servers in old phones to agents that confer among themselves—while the old questions of trust, memory, and who is watching remain stubbornly on the desk.

  1. How I use LLMs to learn complex topics3
  2. Message your other Claude Code sessions4
  3. OpenChamber: An Agentic Development Environment5
  4. We replaced Redis with MySQL for inventory reservations and it scaled6
  5. My server is a phone now7
  6. Everything you do is being recorded8
  7. Mea Culpa – Dark Hours9
  8. Windows 11's built-in Weather app wastes more than 1 GB of RAM10
  9. The original URL for this prediction will no longer be available in 11 years (2011)11
  10. Lost my phone at the office. Claude suggested tracking Bluetooth signal strength12
  11. Ask HN: What are you working on? (August 2026)13
  12. Dithered QR Codes14
  13. Os8088: A powerful Mac-like OS for the IBM XT, 286, 38615
  14. Microsoft Word for Windows 1.1a, Native X64 Port16
  15. Show HN: A Project Oberon System version running on RISC-V instead of RISC-517
  16. Reviving a four year old reMarkable 218
  17. Improving Heuristics for A* Pathfinding19
  18. Making difficulty curves in games20
  19. There Are Magic Hexagons of Every Order21
  20. TheoremDB – A public workspace for machine mathematics22
  21. The Alpha 21264 CPU: NT's Greatest RISC (1998)23
  22. John C. Lilly on solid state intelligence and the elimination of man (1978)24
  23. Unexpected events and prosocial behavior: the Batman effect (2025)25
  24. New Zealand lost its music media, and what we're building to replace it26
  25. Tuxedo No. 2 – Cocktail recipes27
  26. Should you stop cracking your knuckles?28
  27. Cool URIs Don't Change (1998)29
  28. I made tinnitus my friend, then it disappeared [video]29
  29. The tragedy of the commons, AI edition29
  30. Andrew Wiles on proving Fermat’s Last Theorem (1995) [video]29
The Daily Front Page 2 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — The New Tutor
article

How I use LLMs to learn complex topics

by laurentiurad·▲ 776 points·513 comments·laurentiugabriel.github.io ↗
I personally find the style used by LLMs to explain things difficult to follow.

LLMs are used for any things. Learning new things is one of the top use cases.

Many engineers I know use generative AI for many functions, like building PoCs, internal tools or dashboards, or even learning new stuff. I personally find the style used by LLMs to explain things difficult to follow. It's just too simplistic and depending on the number of emojis used, a bit annoying too.

How chips are made - explained in a RollerCoasterTycoon-like simulation

While I was analyzing new AI bottlenecks that might slow down data center buildup, I realized there are many aspects of chip production that I do not know. Surfing the web, I asked myself what if there would be a game to get you through the process of building a chip at a fab? For sure learning this way will stick, since you can map concepts with objects within the game. This is when I decided to try it, and it actually turned out really well.

The flow

Instead of just asking AI to explain a topic, I use the following flow:

  • In plan mode (using CC, or OpenCode) I ask a model to build the foundational knowledge for X topic.
  • I ask it to review the accuracy of the knowledge base it built in the previous step.
  • I proceed asking it to build a simulation of that topic in a low-poly, Rollercoaster Tycoon-like animation. I add some UX elements as well, like the page needs to be visible on both large and small screens, have controls to stop the flow whenever I want etc.
  • I then push it to a new repo and enable GitHub Pages for it.

The result

What you get is a beautiful animation that is 100% accurate and free of hallucinations. For me, this method works a lot better than just reading endless materials that I find on Google, or trying to digest a bulleted list that is spat by a language model.

I've done this specifically for learning chip building and launch it under this website: ChipTycoon. You get to follow a cart from the moment when sand is collected, to the moment when a chip is finalized and delivered to a data center.

Visually, you can follow the cart and see how it changes too. Since it's low-poly, the details might be missing, but it's still a good indicator for showing how the product changes once it goes through the many steps required in the manufacturing process.

How to improve it further

Let's say that the low-poly design requires to much immagination to actually visualize what happened to the quartz sand pile after it left the furnace. To transform this into a more realistic representation, you can use my skill for transforming pictures into 3d objects, and map the resulting objects to your simulation. This way you get more accurate design.

Also, you can add challenges to your simulation too. Trying to answer questions about a previous step in the chip manufacturing process will help you retain the knowledge tremendously. Add intuitive puzzles too that will help you learn even better.

Check out what other pages I created:

The Daily Front Page 3 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — When the Agents Confer
article

Message your other Claude Code sessions

by mfiguiere·▲ 168 points·70 comments·code.claude.com ↗
Cross-session messaging lets Claude deliver a message from one of your Claude Code sessions to another.

Cross-session messaging requires Claude Code v2.1.224 or later and runs on macOS and Linux. When a session meets the requirements, messaging is on with nothing to enable. See Availability for provider requirements and how to confirm a session has it.

Cross-session messaging lets Claude deliver a message from one of your Claude Code sessions to another. When a change in one session breaks what another is building on, Claude can warn that session before you notice. When one session settles a question another is blocked on, Claude can send the answer across. A message is a piece of text one Claude writes to another, never conversation history or files. To move a whole conversation or its context, resume the session instead. Claude uses two tools for this: ListAgents to discover which agents it can reach, and SendMessage to deliver a message to one of them by name. With the same SendMessage tool, Claude can also message subagents and agent team teammates within a single session or team. This page covers messages between your independent sessions.

When to use cross-session messaging

Use messaging when one of your sessions has something another session needs mid-task. Claude can send a message on its own when it sees the need, for example after making a change that affects work another session is doing, or you can ask it to send one. The common cases:

  • Hand over a finding: when one session discovers a breaking change or makes a decision, Claude summarizes it for the session working on the affected area, instead of you re-explaining it there.
  • Coordinate parallel worktrees: when sessions work the same repository in separate worktrees, Claude can tell the other sessions what landed.
  • Get status from long-running work: have a migration or test run report back to the session you’re watching, or ask it yourself from there.
  • Reply across machines: answer a message that arrived from one of your sessions on another machine or on the web. Across machines, Claude can only reply. It can’t start the exchange.

Use messaging between independent sessions that you start and steer yourself. Claude Code has a dedicated feature for each of the other ways to run or reach multiple sessions, so use the one built for what you’re doing instead:

  • To continue one conversation in another terminal, or share its context with a new session, resume the session
  • For a coordinated team of sessions Claude spawns and supervises, use agent teams
  • To watch and steer many sessions from one place, use agent view
  • To steer a session yourself from your phone or another device, rather than have sessions message each other, use Remote Control
  • To push external events, such as CI results or chat messages, into a session, use channels

Message another session

When one of your sessions learns something another session needs, such as a finding, a status, or a decision, Claude passes it along instead of you copy-pasting between terminals. Claude discovers the target with ListAgents and sends with SendMessage, so you never call either tool yourself. Claude can decide to send a message without being asked, and you can also prompt for one. To prompt one yourself, tell Claude what you want the other session to know or do. This example is a prompt you type, not a message Claude sends:

Ask the session running in my other terminal whether the migration finished

Claude writes the actual message itself, so your prompt can leave the content to Claude. This prompt asks for a summary without dictating its wording, and what Claude sends varies:

Explain what we just did to the session working on the payments API

For what the message Claude writes looks like when it arrives, including an example of one, see what a message looks like.

Message delivery

The receiving Claude reads the message between tool calls during an active turn, so a running tool is never interrupted. When the receiving session is idle, Claude Code starts a new turn with the message. Between two ordinary interactive sessions with default settings, Claude Code delivers the message. Delivery isn’t guaranteed in every configuration, though. The receiving session checks each arriving message against its own inbound controls, and the check ends in one of three outcomes:

  • Delivered: Claude Code passes the message to the receiving Claude.
  • Held: Claude Code sets the message aside undelivered. A held message reaches Claude only when you approve it or a later mode or settings change allows it.
  • Refused: Claude Code drops the message without delivering it.

Once delivered, the message counts toward usage like a prompt you type, and the receiving Claude can reply to the sender the same way, except in the one-way cross-machine case. Permission boundaries stay per-session. Claude is instructed never to ask another session for an action that was denied or blocked in its own session, or that its own permission settings would block, and to route that work back to you instead. On the receiving side, the receiving session’s own permission prompts and rules still apply to anything the message asks for.

See which sessions Claude can reach

Claude finds a message’s target on its own, so you don’t need to run anything before asking it to send. To see for yourself which sessions Claude can reach, run the /list-agents command. It lists each session with the name it answers to, and that name is where Claude addresses a message. The listing covers:

  • Subagents: agents running inside the current session. Agent team teammates aren’t listed; Claude messages them through the team’s own roster.
  • Your other local sessions: Claude Code sessions running on the same machine, including background sessions. A session appears only when it binds an inbox socket.
  • Sessions beyond this machine: shown while Remote Control is connected and labeled Remote Control. These are your sessions on other machines and your Claude Code on the web sessions. Claude can’t send a message to start a conversation with one of these sessions. It can only reply to a message that arrived from one of them. See Message sessions on other machines.

A session answers to the name you set with the /rename command or the --name flag. When you don’t set one, Claude Code names the session itself. An interactive session gets a name derived from its working directory’s folder name, such as myapp-3f. Two sessions can end up with the same name. The /list-agents output shows each local session’s working directory, which tells same-named sessions apart when they run in different directories. Claude’s own listing adds a short identifier to each row and uses it in the address when names collide.

Message sessions on other machines

Where the other session runs decides how a message travels and what Claude here can send:

Where the other session runs How the message travels What Claude here can send
On this machine Over a per-session socket, never through Anthropic servers New messages and replies
On another of your machines Through Anthropic servers, arriving over that machine’s Remote Control connection Replies only
On Claude Code on the web Through Anthropic servers, straight to the cloud session Replies only

Same-machine delivery works wherever the feature is enabled. Each session registers itself in files on disk and binds its inbox socket there. When Claude lists or messages your local sessions, Claude Code reads those files to find them, so two sessions can reach each other only when they can see the same files. A container has its own filesystem, so a session inside it and a session on the host can’t reach each other. Two sessions inside the same container can still message each other, including on a self-hosted runner. A reply needs a reply address, and almost every message carries one. A reply to a session beyond this machine, sent while the replying session isn’t connected to Remote Control, still goes through as a direct request to Anthropic servers, but it arrives without a reply address, so the receiver can’t answer it. Claude is told as much when it sends. To require your approval before any message goes beyond this machine, set isolatePeerMachines.

How a session treats an incoming message

When session A messages session B, Claude Code tells B’s Claude that the message came from another session, not from you, and limits what the message can do:

  • It can’t approve anything: a message from another session never counts as your consent, so it can’t answer a pending permission prompt on your behalf.
  • It can’t change configuration: Claude Code instructs the receiving Claude never to change permission settings, CLAUDE.md, or other configuration because another session asked.
  • Commands don’t run: a command in the message’s text, such as /compact, arrives as plain text. Claude Code never executes it.
  • Permission prompts still fire: if acting on the message requires a permission the receiving session doesn’t have, you see the same prompt you’d see for any other work.

What a message looks like

When the message arrives, it appears in the conversation with its sender, queued while Claude is mid-turn or starting a new turn right away when the session is idle. Once Claude has read it, Claude Code collapses it to a one-line Message from row, which Ctrl+O expands. A message is a piece of text one Claude writes to another. Claude receives it with the sender’s name and a reply address, except for a one-way cross-machine reply, which carries no reply address. You see the name and the text, and the receiving session gets only that text, never the sender’s conversation history or files. This example is a message one Claude wrote to another, as the receiving session sees it:

Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.

Control inbound messages

Set crossSessionInbound to choose what a session does with messages arriving from your other sessions:

Value Behavior
accept Claude Code delivers each message to Claude
hold Claude Code shows a notice for each message and doesn’t deliver it. If an accept later applies, per the precedence rules, Claude Code releases the held messages
refuse Claude Code drops each message without delivering it

To see which value applies, follow the crossSessionInbound precedence rules in the settings reference. When no value applies, Claude Code decides per message from the two sessions’ permission modes. It groups sessions that bypass permission prompts into one class, and every other session into the other. Plan mode counts as bypassing in sessions with bypass permissions available, and auto, acceptEdits, and dontAsk count as prompting:

  • The receiving session prompts for permissions: Claude Code delivers each message. It holds one for your approval only when the sending session identifies itself as bypassing permission prompts.
  • The receiving session bypasses permission prompts: Claude Code holds each message for your approval. It delivers one only when the sending session identifies itself as also bypassing.

When the default holds a message, Claude Code opens an approval dialog in the receiving session. The dialog shows the sender and a preview:

  • Approve delivers that one message to Claude.
  • Deny, or dismissing the dialog, drops it.
  • Left unanswered past the dialogExpiry deadline, the dialog closes and Claude Code drops the message. The deadline defaults to five minutes.
  • If this session’s permission-mode class changes while messages are held, Claude Code re-applies the inbound rules, delivers the messages they now accept, and shows a notice.
  • If a change makes refuse apply while messages are held, Claude Code drops every held message and reports a denial to each sender it can reach.

When the sender runs on the same machine, Claude Code tells the sending session what happened. A notice appears there when the message is held, and a follow-up reports the outcome when the receiver later delivers, denies, or expires it. A message refused on arrival produces no sender-side notice. Claude Code holds at most 100 messages, separately from the delivery queue, and past that drops the oldest.

Non-interactive sessions

Claude Code binds an inbox socket for a claude -p session like an interactive one, so a long-running -p worker can receive messages and appears in the listing. When you start a session in bare mode, Claude Code doesn’t bind the socket, so that session can’t receive messages and doesn’t appear in the agent list. A -p session can’t show the approval dialog. A held message stays held there. Claude Code delivers it only if a later mode or settings change allows it, under the same rules as above. To let a -p worker take messages unattended, start it with crossSessionInbound set to accept in its --settings value. An accept in your user settings also works but applies to every session you run.

The session’s inbox socket

Read this section when a session you expect isn’t in the agent list, when you want a script or hook to post into a session, or when a sandboxed command can’t reach the socket. Claude Code binds an inbox socket for each session with cross-session messaging enabled, where other sessions on the machine deliver messages. It restricts the socket to your operating-system user, so on a shared machine another user’s sessions can’t reach it. You can find the path in two places:

  • /status shows it in the Peer address row. The path is prefixed with uds:.
  • Claude Code exports it to hooks and Bash commands as the CLAUDE_CODE_MESSAGING_SOCKET environment variable. The export happens before any hook runs, including SessionStart. Each session exports its own socket, never one inherited from a parent session.

Claude Code runs messages arriving on the socket through the same inbound controls as any other peer message, with one exception and one prerequisite:

  • Own-child messages: when no crossSessionInbound value applies, Claude Code delivers a message it verifies came from the session’s own child processes, such as a hook or Bash command posting back to its own session’s socket. On Linux, including inside WSL 2, it can verify even for a child that has already exited, while on macOS it can verify only while the posting process is still running, and in containers where Claude Code runs as process ID 1 it can’t verify at all. Whenever it can’t verify, it treats the message like any other that asserts no permission class, so a session that bypasses permission prompts holds it for your approval.
  • Sandboxed sessions: control whether a Bash command can reach the socket from inside the sandbox with the sandbox’s Unix-socket settings, sandbox.network.allowAllUnixSockets and sandbox.network.allowUnixSockets.

Restrict cross-session messaging

Beyond the per-message defaults, you can narrow messaging in two ways. Require your approval before any message leaves the machine, or turn messaging off for a session or an organization.

Require approval for cross-machine messages

Set isolatePeerMachines to true to require your explicit approval before any SendMessage reaches a session beyond this machine:

{
  "isolatePeerMachines": true
}

With this set, Claude Code asks for your approval before Claude’s reply to a session beyond this machine leaves, even in bypassPermissions mode, which skips ordinary permission prompts. A true from any settings scope applies, so a checked-in project file can turn the requirement on but not off. Messages between sessions on the same machine don’t prompt.

Turn off cross-session messaging

Receiving and sending are separate controls, so turn off whichever direction you need, or both. Use crossSessionInbound for messages that arrive, and permission rules for what Claude here can send or list:

  • Stop receiving: set crossSessionInbound to refuse, and Claude Code drops inbound peer messages without delivering them. From project or local settings, refuse applies over every other source, and from your user settings it applies unless managed settings or the --settings flag set a value.
  • Stop sending and listing: add permission deny rules naming SendMessage and ListAgents. Both take the bare tool name with no specifier.

Administrators can turn both sides off for an organization in managed settings, combining the deny rules with the refuse:

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  },
  "crossSessionInbound": "refuse"
}

With this in place, Claude Code still binds each session’s inbox socket, but drops every message that arrives on it without delivering anything to Claude. Denying SendMessage also removes messaging to subagents and agent-team teammates, since the same tool serves both. A refusing session shows no visible change, in its own /status or in other sessions’ listings, so confirm the setting from the session’s configuration.

Availability

Cross-session messaging requires Claude Code v2.1.224 or later. Availability also depends on your platform, provider, and configuration:

  • Operating system: available on macOS and Linux, including Linux inside WSL 2. Claude Code doesn’t offer cross-session messaging on native Windows.
  • Provider: not available on Amazon Bedrock, Claude Platform on AWS, Google Cloud’s Agent Platform, or Microsoft Foundry.
  • Feature-flag evaluation: when any of CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK, or DISABLE_GROWTHBOOK turns off the feature-flag evaluation the feature depends on, cross-session messaging stays off. Each variable’s row says which values do that. Unset whichever applies. These variables can come from your shell, from a settings file’s env map, or from managed settings.

To check a session, type /list-agents, also available as /peers. The result separates a session that doesn’t have the feature from a session where something narrower blocked a message, such as a missing SendMessage tool or a refused send:

  • /list-agents isn’t recognized: the session doesn’t have cross-session messaging. Work through the requirements above, starting with claude --version for the version requirement.
  • /list-agents works but a send didn’t arrive: messaging is on, and something narrower applies. A permission deny rule removes the SendMessage and ListAgents tools, the receiving session’s inbound controls can hold or drop what you send it, and a session beyond this machine is reply-only.

In a session with messaging, /status also shows a Peer address row with the session’s own inbox address.

Limitations

The limits here are properties of the messaging channel itself and apply wherever the feature runs. For platform and provider gaps, see Availability instead.

  • Plain text only: Claude sends only plain text across sessions. Structured agent team protocol messages stay within a team.
  • Message loops are throttled: Claude Code rate-limits repeated messages per sender, drops identical repeats arriving within a short window, and caps accepted messages waiting for Claude to read them at 50 per session. A message loop between two sessions therefore stops on its own.
The Daily Front Page 4 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — The Agent’s Workbench
article

OpenChamber: An Agentic Development Environment

by hexomancer·▲ 171 points·82 comments·openchamber.dev ↗
Set a finish line. The agent keeps working toward it, turn after turn.

OpenChamber desktop interface

What you can do with OpenChamber.

Session Goals

Set a finish line. The agent keeps working toward it, turn after turn — even with the app closed.

Multi-run and Fusion

Run one task across up to five models. Keep the best result, or fuse the strongest parts.

Changes Walkthrough

A large diff, grouped into ordered steps that explain how the change fits together.

Preview

Point at an element in your running app and send the agent everything behind it.

From issue to pull request

Start from a GitHub issue or PR, send failed checks back, and merge without leaving.

Scheduled work

Run a prompt on a cron schedule. Pair it with Session Goals to aim at an outcome.

OpenChamber session list on mobile

OpenChamber new chat on mobile

OpenChamber conversation on mobile

OpenChamber usage and limits on mobile

Your workspace, everywhere.

Move between desktop, browser, phone, and VS Code without losing the thread.

Desktop app

  • macOS, Windows, and Linux apps
  • Multi-window project workflows
  • Open In shortcuts for Finder, Terminal, and your editor
  • Project Actions for dev servers, SSH forwarding, and local URLs

OpenChamber desktop app

Browser / PWA / Mobile

  • Browser access from anywhere
  • Phone- and tablet-friendly controls
  • A native mobile app, now in beta
  • A UI password gate that makes browser access public-ready
  • Background notifications and cross-tab session activity
~ ❯ openchamber serve --ui-password ******
┌  OpenChamber Started
│
◆  port 3000 (PID 34189)
●  local:  http://127.0.0.1:3000/
●  tunnel: https://oc-3a9f.trycloudflare.com
│
└  daemon running

~ ❯ openchamber connect-url --relay
┌  OpenChamber relay pairing link
│
◆  openchamber://connect?v=2&p=eyJ2IjoyLCJwYWlyaW5n…
●  Relay: wss://relay.openchamber.dev/ws
●  Fingerprint: 7F3A-D21C
│
└  relay pairing link generated

~ ❯

Code editor

  • Editor-native workflow
  • Open files directly from tool output
  • Right-click context actions on selections and files
  • Agent Manager for parallel multi-model runs

OpenChamber in VS Code

The reason this keeps getting built.

Posts we never asked for, from people using it every day.

@Boripheus

After years of switching between IDEs and TUIs, I found the sweet spot for everything I need: Openchamber.

@logic

Opencode + OhMyOpencode + Openchamber. This is some cooked stack. VSCode looks like legacy notepad++ now.

@1un4rPunk

Seriously, I've spent almost the whole week trying to find a tool that made sense to orchestrate agents and, as a dev (actually, a devops), openchamber is the only one that felt natural and logical.

@AkakaFavour

Best thing that has ever happened to me fr. I ship from anywhere: open code paired with openchamber + open design + agent browser.

@friendorfi

openchamber + opencode is a gamechanger, trust my words.

@JohnRoyNL

Switched to OpenCode and OpenChamber and never looked back. Wrote an MCP server for it to use it with Home Assistant Voice Assist for doing things on the go.

hkay-dev

I just want to say the app itself is phenomenal. The level of polish is just unreal. I saw OpenChamber back when it was a small project, I think maybe a couple months ago, and now it is unrecognizable. Truly amazing work. The latest release with its streaming feature is everything I could have possibly asked for and more. It is gorgeous and smooth.

@drdanponders

Stop using Openclaw for coding! Use OpenCode and OpenChamber instead!

@realchendahuang

I've had a deep experience with openchamber. I think my choice was right. This thing is really useful, smooth and silky.

@PeaweeBoomhall

alllll day, every day. I use OpenChamber as my UI for it. Amazing experience.

@NihilSineTheo

Was looking for a way to run agents from my phone, remotely on my server, other than tmux. Found OpenChamber. It is INSANELY good, highly recommended.

Privacy & Data

Nothing about your work is collected or sent anywhere. Your code and session content stay on your machine, and remote access can be protected when the workspace leaves localhost.

Code and sessions stay with you

Project names, paths, prompts, code, diffs, and session content are not collected by OpenChamber.

Remote access is protected

Browser access can be gated with a UI password, and tunnel links can be rotated or revoked when they should no longer work.

Private Relay, no open ports

Pair a device with a one-time QR code and connect through Private Relay without opening ports or exposing a public server. The connection is end-to-end encrypted and can be revoked at any time.

Privacy is inspectable

OpenChamber is open source, so the privacy model is visible in the code instead of hidden behind policy language.

OpenChamber FAQ

Is OpenChamber open source?

Yes. OpenChamber is open source, and the code is available on GitHub.

What agent harness does OpenChamber use?

OpenChamber runs on the OpenCode SDK today — we picked it for the best open-source agent experience available. Install it with curl -fsSL https://opencode.ai/install | bash.

Is OpenChamber free to use?

Yes. OpenChamber itself is free to use.

Can I use OpenChamber remotely?

Yes. You can open it remotely through the browser UI, use tunnels when needed, and protect access with a UI password.

More questions? Check the documentation

The Daily Front Page 5 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — The Database Countermove
article

We replaced Redis with MySQL for inventory reservations and it scaled

by adletbalzhanov·▲ 338 points·251 comments·shopify.engineering ↗
The hardest lesson wasn’t about database design.

How we used SKIP LOCKED, composite primary keys, and connection visibility to hit our scale targets.

Redis to MySQL for inventory

During checkout, when a buyer clicks "Complete purchase," we need to guarantee the items they're buying are still available. If we get this wrong in one direction, two buyers purchase the same last unit: the merchant has to cancel an order, send an apology email, and eat the support cost. If we get it wrong in the other direction, we tell a buyer something is sold out when it isn't, and the merchant loses a sale they should have made.

At Shopify's scale, either failure compounds fast. On Black Friday 2025, merchants on our platform hit a record $5.1 million in sales per minute at peak. Every one of those transactions touches inventory.

Our oversell protection system handles this by reserving inventory during payment processing—a short hold that prevents two concurrent checkouts from claiming the same unit. For years, this ran on Redis. When we moved toward a unified database strategy, we had to answer a hard question: could MySQL handle the same scale?

Earlier attempts had failed. A single row with a quantity column couldn't handle the contention. MySQL 8's SKIP LOCKED feature introduced a different design: one row per inventory unit instead of one row per item. Inspired by 37signals' approach to database-backed load distribution, we rebuilt reservations on MySQL and hit our high-throughput targets during peak 2025 traffic.

But the hardest lesson wasn't about database design. It was discovering that the real bottleneck wasn’t what we were observing and measuring. This post walks through the solution and what we found along the way.

The challenge

What is oversell protection?

Oversell protection has two main operations:

  • Reserve: When payment starts, we mark items as reserved (a short hold, e.g. several minutes).
  • Claim: When payment succeeds, we permanently deduct quantity from the inventory ledger (source of truth).

Checkout completion depends on this being fast and correct. Slow reservations trigger throttling and a worse buyer experience. Mistakes mean overselling (angry customers) or underselling (lost revenue).

Scale and correctness requirements

Scale here is not abstract: Shopify powers over 14% of U.S. ecommerce, and on Black Friday 2025 we saw an 11% increase in sales per minute at peak over the prior year. Reservations run on every checkout that touches inventory, so the system must handle that burst without dropping requests or breaking consistency.

We needed to:

  • Support the platform's high-performance throughput targets during peak traffic
  • Respect multi-location inventory (only reserve from locations that can fulfill)
  • Keep ACID guarantees between reservations and the inventory ledger
  • Prioritize correctness: no overselling and no lost reservations

The Redis model and its limits

The previous system stored reservations in Redis. Each item had a quantity key, and reserving meant DECR, releasing meant INCR. Redis handled concurrency fine, but reservations and the inventory ledger lived in two different systems.

The claim step (payment processed, permanently deduct inventory) required updating MySQL and cleaning up Redis, and those two operations couldn't be wrapped in a single atomic step. Depending on the order, this could cause overselling (item sold but was never deducted from the ledger) or underselling (item deducted and still marked reserved).

On top of that, the Redis model had no multi-location awareness and added the operational cost of a separate cluster to maintain. Moving reservations into the same MySQL database as the ledger meant we could wrap everything in ACID transactions and eliminate these failure modes entirely.

The solution: SKIP LOCKED

Core idea: one row per unit, bounded by design

Instead of one row per item with a quantity column, we use one row per sellable unit. An item with 10 units has 10 rows. Reserving three units means selecting and moving three rows in a single transaction. By keeping reservations and the inventory ledger in the same database, we get ACID across reserve and claim—fixing classes of bugs that were possible with Redis (e.g. payment succeeds but inventory isn't claimed, or the reverse).

A simplified reserve flow looks like this:

SKIP LOCKED is what makes this scalable: if another transaction has locked some rows, MySQL skips them and returns other available rows. No waiting on the same row, less contention.

But one row per unit for all inventory would break down at scale—an item with 50,000 units across 10 locations would mean 500,000 rows, and the reserve query would slow as it scans through them. Instead, we maintain a bounded pool of available rows, capped at 1,000 per item/location combination. Reservations consume rows from this pool; a replenishment process refills it from the inventory ledger.

Why 1,000? The cap needs to be large enough to absorb bursts without running dry, but small enough to keep the table compact and the SKIP LOCKED scan fast. We sized it based on observed peak reservation rates per item/location during flash sales: 1,000 gives us enough headroom that replenishment can keep up under sustained load without the table growing to a point where query performance degrades.

What happens if the pool empties? During an extreme flash sale, the pool for a hot item can be temporarily exhausted. When that happens, the reserve path triggers replenishment inline. A lock ensures only one transaction replenishes at a time; other concurrent reserves for the same item wait for it to finish rather than all racing to insert rows, avoiding a thundering herd. Once replenishment completes, the waiting transactions proceed with a full pool. The buyer never sees the item as unavailable (unless it truly is). This adds latency to that specific reservation, but it preserves correctness: a buyer with available inventory is never turned away.

Key technical decisions

1. Composite primary key: fewer locks per row

Our first prototype used an auto-increment ID as the primary key. When we observed lock behavior (e.g. with SHOW ENGINE INNODB STATUS), we saw two row locks per reservation instead of one.

With an auto-increment primary key, InnoDB was locking both the secondary index used in the WHERE clause and the clustered index (primary key). We switched to a composite primary key (shop_id, inventory_item_id, inventory_group_id, id) so the columns we filter on are part of the primary key. That reduced to one lock per row, which was important when running many reservations per second.

Takeaway: at this scale, index and primary key design directly affect lock count and throughput.

2. READ COMMITTED: avoiding gap (supremum) locks

When we ran SELECT ... FOR UPDATE SKIP LOCKED on an empty table that needed replenishment, we saw gap locks (including on the "supremum" pseudo-record). Those locks blocked the replenishment transaction from inserting new rows and could lead to deadlocks.

We changed the transaction isolation level from REPEATABLE READ (MySQL default) to READ COMMITTED for these transactions. Under READ COMMITTED, InnoDB doesn't take gap locks in the same way, so replenishment could proceed. Jahfer Husain's guide to InnoDB locking was very helpful for understanding this. This was our first use of a non-default isolation level in this codebase; it required small framework support for setting isolation per transaction.

3. Consistent lock ordering: avoiding deadlocks

We hit deadlocks when reserve and claim touched two tables in different orders. Reserve was doing INSERT into reserved_quantities then DELETE from reservation_units; claim was doing DELETE from reserved_quantities. Different transactions could lock the two tables in different orders and form a cycle.

The fix was to standardize the order: reserve always DELETEs from the units table first, then INSERTs into reserved_quantities. Claim only touches reserved_quantities. Because both paths now acquire locks in the same order, neither can hold a lock the other is waiting for—no more circular waits.

4. Batching with UNION ALL

Each round trip to the database has a cost. For carts with multiple line items, we batch reservation queries using UNION ALL so we fetch all needed units in one round trip:

That cut total round trips and helped latency under load.

The real bottleneck: connections, not CPU

In production we hit a throughput ceiling well below our target. Reservation latency (e.g. P90) was acceptable, CPU wasn't maxed out, and the queries were already optimized. So we looked elsewhere.

We tried batching reservations across multiple checkouts in a single SKIP LOCKED query to use fewer connections. That helped in load tests but added complexity. We also moved some read load to replicas. Still, something didn't add up.

Following the symptoms

During load tests we saw:

  • Threads queuing in MySQL
  • CPU spiking when queued work ran
  • Connection exhaustion to MySQL backends on ProxySQL layer

So we added visibility into which business processes were holding database connections and for how long. Knowing that connections are exhausted doesn't tell you who is holding them. We needed per-caller attribution.

On the application side, we annotated every SQL statement with a comment tag identifying the business process, like /* conn_tag:checkout_completion */. On the ProxySQL layer, we added tracking that parses the tag and measures how long each caller holds a connection. The result: total connection hold time, broken down by business process.

This immediately showed which callers were consuming the most connection time. Not which queries were slow, but which processes were holding connections across long transactions. If you're hitting connection limits and can't tell why, this pattern (tag at the app layer, aggregate at the proxy) is straightforward to implement and immediately actionable.

What we found

Once we could see connection usage, we learned that reservations weren't the only heavy user. Other parts of the checkout path were holding connections longer than necessary. They hadn't been optimized because they hadn't been the first to hit the limit. Connections are finite: at high throughput we need many short transactions per second. When other code held connections longer, reservations were the straw that broke the camel's back—not because reservations were slow, but because the pool was already near depletion.

The cleanup of the checkout path removed 50% of reads and 33% of transactions on the primary database. We also revisited MySQL configuration. InnoDB thread concurrency had been set conservatively years earlier and never re-evaluated. Our workload had changed. After increasing thread concurrency where we had headroom, we removed a bottleneck we hadn't seen until we had connection and CPU metrics side by side.

Combined, the cleanup and configuration changes removed the ceiling. We could scale beyond our previous limit and meet our targets. During high-volume flash sales, writer CPU stayed under 50% and reader CPU under 16%, with headroom to spare.

The cutover

We didn't flip a switch from Redis to MySQL. We ran both systems in parallel in what we called "shadow mode": every reservation was written to both Redis and MySQL, with Redis remaining the source of truth. This let us compare the two systems side by side, validating that MySQL produced the correct business outcomes and met our performance requirements on real production traffic. Because both systems were live, there were no in-flight reservations to migrate. Redis reservations continued to be honored while MySQL built up its own state.

Once we were satisfied with correctness and performance, we switched the source of truth to MySQL. If anything went wrong, we could revert to Redis with a kill switch; the dual-write path was still active, so Redis had a complete view of reservations at all times. The rollout was gradual, pod by pod, starting with low-traffic pods and working up to our highest-volume merchants.

What we learned

We learned so much from this project but the two main takeaways:

1. Revisit old decisions

What wasn't possible five years ago (e.g. MySQL for this workload) can be possible today with new features like SKIP LOCKED. The same goes for configuration: thread limits and other "rule of thumb" settings are worth re-checking when workload and hardware evolve. If the numbers don't add up (e.g. low CPU but queuing), dig in.

2. Start small and observe

We got a lot of value from a minimal prototype: a small ruby script and MySQL, no full framework like Rails. Observing the database (e.g. lock behavior in a second terminal) taught us more than theory alone. Simple tooling and a tight feedback loop beat big, opaque systems when exploring.

MySQL can now handle workloads we used to assume required specialized infrastructure. If you're reaching for Redis, Kafka, or a custom coordination layer for high-throughput mutual exclusion, your existing database might already be enough.

The bottleneck wasn't where we expected. We optimized queries and locks for weeks; the real limit was connection usage in code we weren't even looking at. If the numbers don't add up—low CPU but high queuing—instrument the full path. The answer is often in the plumbing, not the engine.

Crucially, this wasn't about making reservations fast. It was about making them safe neighbors. Reservations share a database with cart updates, payment processing, and order creation. A system that saturates connections or holds locks too long jeopardizes all of them. The real bar was sustaining throughput without degrading database health for everything else.

For us, the payoff is concrete: more reliable reservations mean no oversells and more successful purchases from our merchants.

Water line vs race meme: inventory

The Daily Front Page 6 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Pocket Infrastructure
article

My server is a phone now

by seg6·▲ 525 points·243 comments·seg6.space ↗
My personal infrastructure lived on a small Hetzner VPS.

rooting a CMF Phone 1 to run my personal infrastructure at home.

For a while, my personal infrastructure lived on a small Hetzner VPS. It ran a few web apps, a remote browser called Surf, Caddy, and the usual supporting cast. Nothing particularly serious. It worked, I just didn’t like paying for it.

One of the apps I run, Surf, made the compromise difficult to ignore. The cheapest shared machines were fine until Chrome had real work to do, at which point they felt starved. Dedicated CPU machines fix that, but cost enough each month to make a personal browser feel like a questionable financial commitment.

Buying another machine wasn’t an appealing escape hatch either. DRAM prices have gone completely stupid, so putting together a new box with a comfortable amount of memory felt especially ill timed. I looked at used mini PCs and briefly considered turning my desktop into a server whenever I wasn’t using it. Then I remembered the CMF Phone 1 I already own.

Eight ARM cores, 8 GB of RAM, 128 GB of flash, Wi-Fi 6, a 5G modem, and a built in battery backup, that is all attached to an SoC that I feel is overqualified for sitting in a drawer. And I had already paid for it. After dusting it off and playing with it for a while, I decided to turn the phone into the server.

Today it runs Surf and its managed Chrome instance, my personal finance tracker, a screen sharing service, and a handful of smaller web apps. They survive reboots, deploy from Git, and remain reachable when the phone moves between networks, so this is now the machine that actually replaced the VPS.

the first bad idea: replacing android

The cleanest version of this idea seemed to be flashing a normal Linux distribution. The CMF Phone 1 has a postmarketOS device port, it boots, and the device page has enough green boxes to make a reckless person optimistic. I ended up being that person.

What I paid less attention to was everything marked broken: Wi-Fi, Bluetooth, hardware acceleration, and most of the other things that make the phone useful as a small server. I got as far as the postmarketOS splash screen and a black display. At that point I had neither a server nor a phone.

Recovering stock Nothing OS turned into its own side quest. The flashing utility needed Windows, so I installed Windows in QEMU, fought USB passthrough and MediaTek drivers, watched the flashing tool hang, then eventually moved the process to an actual Windows installation and restored the factory images.

There was a moment in the middle of this where the phone was soft bircked and only showed a black screen and I genuinely thought I had converted a perfectly good device into a paperweight.

It came back, and lesson learned: Android already has working drivers for every piece of this hardware. Wi-Fi, power management, the battery, the GPU, the modem, and every weird vendor detail already work. Throwing all of that away in pursuit of a more conventional userspace was the wrong trade.

I didn’t actually need the phone to become a normal Linux machine. I needed it to run Linux applications reliably while Android continued doing the hardware specific work it is good at.

termux is the host operating system

The second attempt kept stock Android and treated Termux as the host environment.

Termux gives me OpenSSH, runit, Caddy, Cloudflared, package management, and normal enough Unix tooling. Termux:Boot starts the supervisor and SSH after a reboot. Tailscale gives the phone a stable private address, so from any machine on my tailnet I can just run:

ssh cmf

Termux is not a virtual machine. Its processes still execute against Android’s Linux kernel, but its Bionic based userspace is different enough from an ordinary Debian installation that existing Linux application images cannot simply be dropped into it. That split ended up being useful, though: Termux could remain the small host control plane while each application brought the Linux filesystem it expected.

The actual services are supervised by runit. Android’s battery management is very good at its normal job and very bad for a device pretending to be a server, so I had my Ansible build also apply an Android host profile: it installs a persistent wake lock, disables light and deep idle, exempts Termux, Termux:Boot, and Tailscale from background restrictions, disables the child process limiter, prevents Wi-Fi suspension, and configures Tailscale as the always on VPN.

The recovery chain matters more than any individual setting. Android boots, always on VPN brings Tailscale back, Termux:Boot starts runit, runit starts every resident service, and health checks verify the local and public paths. The phone can reboot without waiting for me to notice.

Android boot
  -> Tailscale always-on VPN
  -> Termux:Boot
  -> runit
  -> resident services
  -> local and public health checks

This isn’t a conventional Linux server. There is no systemd, no normal Docker daemon, and no reason to pretend otherwise. But it is a Linux kernel with a very capable userland sitting on top of it, and that turns out to be enough.

the second bad idea: proot

Most of my applications already shipped as Linux ARM64 OCI images. proot-distro made those surprisingly easy to run under Debian without changing the applications themselves.

PRoot intercepts filesystem and process operations in userspace and makes a regular Termux process believe it lives inside a Debian root filesystem. It isn’t a container boundary. Everything still shares Android’s kernel, network namespace, and Termux UID. But as an application compatibility layer, it is extremely useful because it needs neither root nor a special kernel.

The ordinary web services initially ran fine this way. Each of my applications got a verified root filesystem, a loopback port, and a runit service. Caddy ran directly in Termux and routed hostnames to those ports.

The performance/latency sensitive Surf browser workload was the exception. Starting processes, opening libraries, walking paths, reading browser profiles, and shuffling capture data all crossed PRoot’s userspace translation layer. There was CPU available, but Chrome could not reach it efficiently. So I rooted the phone, not to replace Android, but to mount the same Debian filesystem properly and enter it with a real chroot.

Runit still owned the lifecycle from Termux, configuration still came from the same place, and application data still lived in Termux storage. The workload simply reached Android’s kernel through native syscalls instead of PRoot. The improvement was not subtle!

Once that path was solid, leaving the smaller residents under PRoot stopped making much sense. They now run the same way. My workstation resolves each ARM64 image to an exact digest and exports its filesystem; Ansible verifies and installs it on the phone. A small root helper creates a private mount namespace, binds the required paths, enters the filesystem with chroot, drops privileges, and starts the original image entrypoint.

Neither Docker nor a compiler needs to exist on the phone. These are still compatibility environments rather than security boundaries: the residents share Android’s kernel and network stack, while the private mount namespaces mainly keep mounts and cleanup predictable.

I also spent far too long trying to bridge Debian’s graphics stack to the phone’s Mali GPU through VirGL and Android Vulkan. I got hardware compositing checkmarks alongside corrupt pages and worse performance… The boring software rendered path turned out to perform better.

infrastructure! not a pile of shell history

By this point the phone could run everything, but I didn’t want a pet server assembled from commands I would forget in a week. I moved the entire host into an Ansible managed state: versions, service definitions, routes, power settings, secrets, and health checks all live in one private repository.

The deployment flow is roughly:

release or OCI image
  -> checksum/digest pinned in Git
  -> Ansible over SSH
  -> versioned files on the phone
  -> atomic current symlink
  -> runit service
  -> local health check
  -> public edge check

Releases are pinned by digest or checksum and installed into versioned directories behind an atomic current symlink. A failed checksum or health check stops the deployment, rollback means reverting the pin and applying again. Application data lives separately from releases.

After the small manual bootstrap: install the three Android apps, root the phone, grant Termux superuser access, and authorize SSH, the same repository owns the rest. From my workstation, bringing the host to the declared state is deliberately simple:

make phone
make phone-status
make phone-edge-check

Applying it again does not replace unchanged runtime files or restart healthy residents. More importantly, the configuration is useful if this phone dies: another rootable ARM64 phone can be brought toward the same state without reconstructing a shell history.

Secrets are not stored on the phone’s Git checkout, because there is no Git checkout. Ansible Vault values live encrypted in the infrastructure repository. The vault password is derived by asking my 1Password SSH agent to sign a fixed challenge, so the private key stays in 1Password and the phone never needs access to it. During deployment, Ansible renders only the runtime values each service needs into Termux’s private storage.

getting traffic to a phone behind home internet

The next problem to tackle was ingress. My home connection does not come with the kind of static server setup a VPS gives you, and I don’t want to expose SSH or a collection of random application ports through the router. I also wanted the phone to remain a phone in one important sense: I should be able to unplug it, take it somewhere else, connect it to the internet, and still have my server.

The HTTP applications use a Cloudflare Tunnel. Cloudflared makes one outbound connection from the phone, Cloudflare sends each hostname through it, and Caddy routes the request to the correct loopback service.

Internet
  -> Cloudflare Tunnel
  -> Caddy on 127.0.0.1
  -> application on 127.0.0.1

There is no inbound router rule for those services. Cloudflared only needs an outbound connection, so if I move the phone to another network, the tunnel reconnects and the hostnames follow it. Tailscale does the same for administration. The phone’s battery can bridge the move, and the public services do not care which Wi-Fi happens to be underneath them.

The Surf remote browser backend needed a different path though. Its direct connection is latency sensitive, terminates its own TLS, and the old iPad that connects to it pins the server identity. At home, Cloudflare DDNS keeps a DNS only record pointed at the current public address and the router forwards one port to Surf. On the LAN, the iPad connects directly to the phone.

That still left roaming. A normal Cloudflare Tunnel terminates TLS at Cloudflare, which is exactly what Surf’s pinned connection does not want. The solution was to wrap the complete Surf TLS stream inside an ordinary WebSocket. Cloudflare sees and forwards the WebSocket, but the actual authenticated Surf connection remains encrypted end to end inside it.

This obviously adds latency, from outside home I usually see roughly another network round trip, and the iPad connection was around 60 ms when I first tested it. But it works through a tunnel that only needs outbound connectivity, on an operating system from 2012, without installing Tailscale on the iPad.

That was the moment the phone setup became slightly ridiculous in the best way. I left it plugged in at home, went to the office, SSHed from my MacBook through Tailscale into my workstation and the phone, and used the original iPad through the phone hosted Surf instance. The VPS was no longer, it felt liberating.

what is actually running

The machine has two layers. Android and Termux own the hardware, networking, ingress, and supervision. The Linux residents get the filesystem they expect and otherwise stay out of the host’s way.

layer responsibility pieces
Android / Termux host hardware, networking, ingress, supervision runit, Tailscale, Caddy, Cloudflared, DDNS, operations dashboard
rooted Linux residents application compatibility and workloads Surf and Chrome, Finances, Screen Share, some other apps

The demanding workload is Surf, which brings a modern Chromium browser to old iPhones and iPads. The phone runs desktop Chrome (recent arm64 release of Chrome) and the Surf backend inside its Debian runtime, an iPad mini receives H.264 video and audio while sending touch, keyboard, tab, and navigation commands back. Surf is why I cared so much about syscall overhead and latency in the first place.

Alongside it, the phone hosts my personal finance tracker. It records recurring income and expenses, one time transactions, monthly spending limits, and projects my balance forward day by day. Unlike the replaceable application artifacts, its SQLite database contains state I care about, so it has automated off device backups and a tested restore path.

None of those names are baked into some grand “phone server framework.” A new resident is another immutable artifact, a runit definition, an explicit data contract, a health check, and optionally a Caddy route.

The latest addition is observability. I can still SSH in, inspect runit, tail logs, check public routes, and query Android directly, but I no longer have to do that merely to see what’s going on with the machine at a glance: One native service collects CPU usage for all eight cores, memory, storage, uptime, battery, thermals, local and public reachability, and every discovered runit resident. It keeps bounded history and serves an embedded Vue interface at https://dash.cmf, reachable only over the LAN or tailnet.

dashboard

The log view discovers the same service directories at runtime, so adding another resident doesn’t require teaching the UI its name. It is much nicer than SSHing in just to remember which thing was noisy.

should you do this?

If you already have a reasonably modern, rootable ARM64 phone sitting unused, this is much less ridiculous than it sounds. You get quiet hardware, low power consumption, flash storage, Wi-Fi, a built in display for recovery, and a battery that behaves like a tiny UPS. Stock Android already supports the hardware, while Termux and a rooted chroot are enough to run a surprising amount of normal Linux software.

I would not put irreplaceable data on one without automated off device backups, and I would not treat the chroots as hostile workload isolation. Rooting expands the trust boundary, Android remains an unusual server host, and software rendered desktop Chrome is not going to beat a dedicated workstation with a GPU.

But for a handful of personal services, especially when the alternative is paying indefinitely for a VPS that is either slow or annoyingly expensive, it is a genuinely useful option rather than only a stunt.

The phone is still a weird server. It shares one kernel, Android occasionally needs to be reminded not to “optimize” it, and a future Android update could always create a new surprise.

But it is quiet, battery backed, fast enough, reachable from anywhere, reproducible from Git, and already sitting in my house. I started this trying to save money on a VPS. I ended up with a rooted phone running my personal infrastructure, and somehow that is much more satisfying. :)


Postscript: This post was discussed on Hacker News. In true HN fashion, a surprising amount of the conversation ended up being about the title. I enjoyed the accidental linguistics thread. :)

The Daily Front Page 7 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — The Watching World
article

Everything you do is being recorded

by ike_usawa·▲ 405 points·344 comments·theatlantic.com ↗
Everything You Do Is Being Recorded

a photo of two friends talking at a bar, with a red waveform superimposed

Illustration by The Atlantic. Source: Getty.

Anthony “Bingy” Arillotta waited years to become a made man in the Genovese crime family, and when at last the call came in August 2003, he followed directions to the letter. According to sworn testimony, Arillotta was summoned to a steak house in the Bronx, where he was made to hand over his cellphone, beeper, and jewelry before being driven to an apartment building. When he got there, he was taken to a small bathroom and strip-searched for electronic devices. For his big meeting with the boss, he was given a bathrobe to wear.

Until recently, only spies and criminals had to worry this obsessively about their private statements being picked up by electronic equipment. But soon, the average person might need to deploy surveillance countermeasures. The next time you conduct a delicate bit of office diplomacy or share a romantic or financial secret with a friend over drinks, a sensor built into someone’s glasses, necklace, or lapel pin might be watching you and listening.

In March, the tech start-up Deveillance announced the development of Spectre I, a hockey-puck-shaped device that purports to prevent others from recording you (no strip search required). The company was founded by Aida Baradari, a recent college graduate who was worried by the surge in people wearing AI-enabled recorders. These wearables can be used as a silent notetaker, a personal assistant, or even a therapist of sorts. That technology isn’t yet mainstream, but it may be soon. Apple—the company with the largest personal-tech ecosystem in the world—is rumored to be developing an AI pin or pendant that would serve as an iPhone’s constant eyes and ears; many other products of this type are on the way. AI accessories could one day be as widespread as AirPods.

New surveillance technologies tend to breed new countermeasures, which lead, in turn, to more sophisticated surveillance. During the Second World War, after Germany operationalized radar, the Royal Air Force began dropping thin strips of metallized paper cut to a specific size that resonated with the radar, swamping German screens with phantom echoes that were indistinguishable from real aircraft. Some historians have argued that the ensuing radar arms race was more consequential to the war’s outcome than the Manhattan Project.

For decades, crude jammers have been sold to people who hope to avoid being recorded. Early versions blasted loud, unpleasant white noise to conceal voices. More recently, companies have made models that emit a steady stream of ultrasonic sound at inaudible frequencies, exploiting a quirk of microphone hardware that converts those high frequencies into noise. In 2020, a team at the University of Chicago led by Yuxin Chen reported that it had mounted 23 ultrasonic transducers on a single bracelet, such that jamming signals could be sent in all directions instead of being focused on a single target.

But even high-tech jammers have a hard time fending off today’s AI wearables. The most advanced pins, pendants, and glasses use speech-recovery algorithms to strip away unwanted noise, whether it originates from everyday sources—such as the clinking of glasses in a crowded bar—or from an ultrasonic jammer. This task the algorithms perform is quite difficult: In that crowded bar, a microphone on a person’s lapel will intercept sound vibrations from many different sources at once. It will pick up a bartender calling out a drink order, music emanating from a speaker, bursts of laughter coming from nearby tables—and all of these sounds ricochet off of walls and other objects, creating yet more noise. The human body solves this “cocktail party problem” without us noticing: Our ears serve as dual microphones, and our brain can use the timing and intensity differences between them, along with layered processing in the auditory cortex, to isolate the voice of a person who is sitting across from us.

DeLiang Wang, a computer scientist at Ohio State University, has spent decades training neural networks to accomplish that same goal, for the purpose of improving hearing aids. By feeding the networks hundreds of hours of recorded human voices, he has taught them to recognize the frequencies and rhythms of speech. The models build an internal representation of “speech-ness,” and when they encounter a noisy recording, they focus on the parts that match the patterns they have learned and then suppress everything else. The most advanced technologies can now infer missing syllables in the way that a reader fills in a redacted word from context, allowing them to reconstruct speech that wasn’t cleanly captured in the first place.

Big tech companies are trying to do this too. Microsoft has been running an annual Deep Noise Suppression Challenge since 2020 to advance the field. (Their in-house team is trying to make Teams meetings less excruciating.) Other companies are working on noise cancellation for cellphone calls and podcast software. This sort of research is meant to improve the lives of normal users of technology—assuming that we podcast listeners count as normal—but every advance in de-noising can also be used to help an AI assistant recover speech from a jammed recording.

Defeating these algorithms may require a different countersurveillance approach altogether. Finn Brunton, a historian at UC Davis and the co-author of Obfuscation: A User’s Guide for Privacy and Protest, told me that one of the best ways is to identify the data that a device is trying to collect, and then supply it with a junk version. The Berlin-based artist Adam Harvey used this strategy when he developed makeup and clothing that frustrate facial-recognition algorithms. Daniel Howe and Helen Nissenbaum did something similar with a browser plug-in called TrackMeNot: Rather than concealing a user’s Google searches, the extension continually runs its own randomized decoy queries in the background, so that whatever a user actually searched for becomes lost in a sea of false leads.

People have tried this technique in the realm of audio too. Woodrow Hartzog, a law professor at Boston University who studies privacy and surveillance, told me that early in his legal career, he worked with defense attorneys who worried that their jailhouse conversations with clients would be recorded. To fight back, they played “babble tapes”—audio files layered with 40 tracks of voices in different accents—in the background.

In 2023, a team led by Ming Gao, now a researcher at Nanjing University, used human voices to defeat speech-recovery algorithms in a different way. Its jammer, called MicFrozen, is worn by a speaker who doesn’t want to be recorded. It listens as they talk and then generates a real-time stream of ultrasonic “anti-speech” tuned to the speaker’s voice, much like the noise-cancellation technology in your headphones. The device then sends out another layer of counterfeit speech-shaped sound to mislead any algorithm that tries to reconstruct what was lost.

Baradari, whose company is working on the Spectre I device, wouldn’t tell me exactly how her jammer’s signals work, but she said that they, too, resemble speech. The launch video for Spectre I claims that the device will also be able to detect the presence of nearby microphones. When I asked Baradari how it will do that, she clarified that her team is still “working on that part right now.”

However effective Spectre I turns out to be, it won’t be the end of the recording arms race. More capable AI models may eventually deploy some new listening tricks of their own. They may bypass recorded audio altogether. In Stanley Kubrick’s 2001: A Space Odyssey, when two astronauts retreat to a soundproofed pod to discuss disconnecting HAL 9000, the ship’s computer simply reads their lips through the porthole. A wearable powered by a model that’s been trained on enough conversation footage could, in principle, do the same. In theory, it could also stare at a glass of water between two people and recover their speech from vibrations on the liquid’s surface.

AI wearables may always have an edge over countermeasures. After all, they’re using a technology that is a product of the entire speech-processing industry, which takes in billions of dollars in investments—not just for AI assistants but also for hearing aids, smart speakers, and teleconferencing tools. Meanwhile, only a few academics and small companies are defending us from these technologies. “The thing about cat-and-mouse games is that we know how they usually end up for the mouse,” Hartzog said. “And in this case, the cat includes some of the most powerful corporations to ever exist.”

The Mafia knows what it’s like to be a mouse. By the time Arillotta, the aspiring made man, was told to put on the bathrobe, criminal organizations had been engaged in surveillance arms races of their own for decades. After law enforcement started bugging their phones, bosses would conduct business in person. Sometimes, they’d use a safe house or a vehicle, but those could be bugged, too, and so sensitive information might have been communicated only during a walk-and-talk. Eventually, crime families turned to burner phones, and then devices with encryption. But here, again, they fell prey to the cat.

In 2018, the FBI began secretly running Anom, its own encrypted-phone company. Through informants, it sold 12,000 devices with a special Anom messaging app. Members of Mafia families, motorcycle gangs, and other criminal organizations treated the phones as a status symbol, and used them to negotiate drug deals, launder money, and participate in all manner of other illegal activity. But the security that they offered was a ruse: Every message that they sent was being intercepted by the feds.

The Daily Front Page 8 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Accountability & Entropy
article

Mea Culpa – Dark Hours

by satvikpendem·▲ 594 points·273 comments·blog.terrygodier.com ↗

Last week I launched a project called Dark Hours, which was a website utility to give you an idea of what could be seen in the sky that night.

A developer who created another web app called DarkHours.app replied to my comment on Bluesky yesterday to show me how similar the project was to his, including the name. The thread is here.

I told him I’d significantly differentiate the featureset, change the name, and write up a blog post to show people his project.

About an hour later, once it became clear to me that the web app I had launched using Claude was strikingly similar to his open source project, even reproducing a bug he had later fixed, it was clear that there wasn’t anything to do except to redirect the domain directly to him and kill any plans I had to launch an iOS app for the project.

I’d like to give credit where credit is due. I think he’s made a wonderful open source app and if you liked the features that were included in what I launched, please use the actual version of the project. That’s what I’ll be doing.

I’d also like to apologize for my irresponsible use of AI to build such a thing. While I had genuinely never seen DarkHours.app before yesterday, I was careless in relying on AI to generate the project without doing the work to understand whether it closely resembled an existing project. That’s on me, and I am responsible for what I published.

Going forward, I won’t be using AI in this way to create any more web stuff, and I do not use it to anything close to this extent on iOS software. I do ask questions, debug issues, things like that, but I do not create apps with Claude for iOS.

The Daily Front Page 9 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Accountability & Entropy
article

Windows 11's built-in Weather app wastes more than 1 GB of RAM

by akyuu·▲ 609 points·554 comments·notebookcheck.net ↗

The Windows 11 logo. Microsoft has recently been working to improve the operating system's performance.

The Windows 11 logo. Microsoft has recently been working to improve the operating system's performance.

A new report shows Windows 11's built-in Weather app can consume more than 1 GB of RAM. By comparison, Apple's native Weather app on macOS uses roughly five times less memory under similar conditions.

Microsoft has been working to make Windows 11 more efficient on PCs with limited RAM, but one of its own built-in applications appears to be working against that goal. According to tests published by Windows Latest, the operating system's Weather app can consume more than 1 GB of memory despite performing a relatively simple task.

Windows Latest reports that the app exceeded 1.2 GB of RAM while displaying a weather forecast, with no intensive interaction from the user. Wccftech observed similar behavior, noting that memory usage typically starts at around 1 GB, drops to roughly 500–600 MB when idle, and can climb to 1.5–1.6 GB during basic actions such as zooming or navigating the interface. On a PC equipped with 8 GB of RAM, that means the application alone may occupy nearly 20% of the system's memory.

Windows 11's Weather app consumes more than 1 GB of RAM.

Windows 11's Weather app consumes more than 1 GB of RAM.

By comparison, Apple's native Weather app on macOS reportedly uses less than 250 MB of RAM under similar conditions, giving Microsoft's implementation a memory footprint roughly five times larger.

Apple's Weather app on macOS uses less than 250 MB of RAM.

Apple's Weather app on macOS uses less than 250 MB of RAM.

According to Windows Latest, the high memory consumption is due to the fact that Weather is not a fully native Windows application. Instead, it is essentially an MSN Weather web app built on Microsoft's WebView2 framework. Task Manager shows multiple Chromium-based subprocesses running simultaneously, which contributes to the unusually high RAM usage.

The issue is unlikely to affect high-end PCs with 32 GB or more of RAM, but it could have a noticeable impact on entry-level systems. On computers with 8 GB or even 16 GB of memory, launching the Weather app may increase memory pressure enough for Windows to rely more heavily on the page file, potentially making the system feel less responsive.

The application also includes advertising within its interface. According to Windows Latest, sponsored content is embedded directly into the forecast feed, appearing alongside weather cards in a similar visual style. While Microsoft licenses weather data from multiple providers — including Foreca, the European Centre for Medium-Range Weather Forecasts (ECMWF), and other regional meteorological services — the presence of ads in a built-in Windows application has attracted criticism.

The findings also appear to contradict Microsoft's recent efforts to improve Windows 11's efficiency. The company has been updating several built-in applications and has repeatedly said it wants the operating system to perform better on lower-end hardware. Microsoft executive Rudy Huyn has also stated that the company intends to develop more fully native Windows applications in the future, although it remains unclear whether MSN-branded applications such as Weather will eventually be rebuilt using WinUI.

Source(s)

Windows Latest, Wccftech

The Daily Front Page 10 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Accountability & Entropy
article

The original URL for this prediction will no longer be available in 11 years (2011)

by doubletwoyou·▲ 208 points·100 comments·longbets.org ↗

Keith's Argument

"Cool URIs don't change" wrote Tim Berners-Lee in 01999, but link rot is the entropy of the web. The probability of a web document surviving in its original location decreases greatly over time. I suspect that even a relatively short time period (eleven years) is too long for a resource to survive.

I would love to be proven wrong.

Haughey's Argument

Though much of the web is ephemeral in nature, now that we have surpassed the 20 year mark since the web was created and gone through several booms and busts, technology and strategies have matured to the point where keeping a site going with a stable URI system is within reach of anyone with moderate technological knowledge. My oldest sites are going on 13 years old at the time of this bet and the original URL scheme still functions via 301 redirects to a final format we selected about six years ago.

Detailed Terms

On February 22nd, 2022 from 00:01 UTC until 23:59 UTC,
entering the characters http://www.longbets.org/601 into the address bar of a web browser or command line tool (like curl)
OR
using a web browser to follow a hyperlink that points to http://www.longbets.org/601
MUST
return an HTML document that still contains the following text: "The original URL for this prediction (www.longbets.org/601) will no longer be available in eleven years."

A 301 redirect from www.longbets.org/601 to a different URL containing that text would also fulfill those conditions.

If those conditions are met, Matt wins.

If those conditions aren't met, Jeremy wins.

The Daily Front Page 11 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — The Tool You Needed
The Daily Front Page 12 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — The Open Workshop
ask hn

Ask HN: What are you working on? (August 2026)

by david927·▲ 295 points·1,044 comments·news.ycombinator.com ↗

What are you working on? What have you been curious about lately?

Join the discussion on Hacker News →

The Daily Front Page 13 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Pixels With a Purpose
article

Dithered QR Codes

by jmusall·▲ 374 points·43 comments·andrewt.net ↗
They’re designed to be very robust to bad focus, bad printing, funny angles, and missing areas.

A dithered photo of me, with standard QR code alignment patterns superimposed on it

QR codes: the basics

A QR code is really just a way of encoding a few bytes of data in a way that can be easily read froma photo by a smartphone or similar device. They're designed to be very robust to bad focus, bad printing, funny angles, and missing areas. Exactly how they work isn't terribly important, but for the purposes of this page, a QR code is a grid of squares that divide into two parts — the function patterns (which are the bold shapes in the above example) and the data modules (everything else). The function modules are mostly used to let the scanner find the QR code easily, so they have to be very clear and distinct. The data modules are where the actual data is stored, along with some extra header data etc, and since those are only read after the scanner has used the function modules to work out exactly where the QR code is, they can be modified a bit more. This is often used by brands to create QR codes that look a bit distinctive, and while this kind of modification makes them a bit less robust when scanning, but you can generally get away with a fair bit before the codes become unscannable.

Putting pictures in QR codes

A dithered photo of Dave Richeson, with standard QR code alignment patterns superimposed on it, and a smattering of small black and white pixels on top

This is a QR code I saw on Mastodon. One of the modifications you can do with the data modules is to shrink them — the scanner will look where the finder patterns say the centres of the pixels should be, and so as long as the code isn't distorted when you try to scan it. That means the rest of the space is yours to play with. Dave divides each pixel into a three-by-three grid, and uses the middle one to store the data, and the others for a photo. The result is a low-res, one-bit photo with some salt-and-pepper noise on it.

Dithering

A dithered gradient

Obviously when we crush an image into a low colour depth, we don't normally just threshold it — that is, make the dark pixels black and the light pixels white. We normally use a kind of chequerboard effect to create midtones as well. A Bayer filter can be used to apply this idea across a whole image without having to sacrifice too much fine detail.

A Bayer dithered picture of Michaelangelo's David

Error diffusion

An attempt to improve on this method was Floyd-Steinberg dithering.

A Floyd-Steinberg dithered picture of Michaelangelo's David

In this method, you start in the top left and threshold the pixel normally — if it's more than 50% brightness, you make it white, and otherwise you make it black. Say it was 70% brightness — we're going to make it white, which is 100% brightness, which means we've added 30% of a pixel too much brightness. To counteract that, we're going to "diffuse" that error to other pixels — all the nearby pixels that we haven't thresholded yet are made a few percend darker, to a total of 30% of a pixel. When we come to threshold those pixels, we'll take that into account. The idea is that once we've thresholded the entire picture, every part of the image will be, on average, closer to the correct brightness than more regular dithering. The irregular patterns are also a bit less distracting.

QR codes with error-diffusion dithering

A noisy Floyd-Steinberg dithered picture of Michaelangelo's David, with QR code patterns on top

The other advantage of this irregular dithering is that the salt-and-pepper noise caused by the QR code data modules is much harder to spot. But it's still there, and it's why the image looks so noisy. I mean, it would look fairly noisy anyway because it's a 147×147 pixel one-bit image, but some of that noise is because one in nine of the pixels are effectively random colours.

But we can solve that using more error diffusion.

Error-diffusing the data modules

In this case, we're doing two passes on the error diffusion. The second is the same as normal, but the first is specifically to mask the data modules. We already know what colour all of those pixels have to be, so we can make them those colours and diffuse that error to the surrounding eight pixels. The error will potentially be quite big — normally we get to choose the colour so the error can never be more than 50%, but here we might have to make a pixel in a dark area pure white and end up creating 95% error. That sounds bad, but that's exactly why it's so important to diffuse this error instead of just accepting it.

A less noisy Floyd-Steinberg dithered picture of Michaelangelo's David, with QR code patterns on top

You can see that this makes the image much cleaner.

Getting fancy with it

A dithered version of Morten Rieger Hannemose's ethically-sourced Lena image, with standard QR code alignment patterns superimposed on it

The generator tool allows you to do some extra tricks. You can rotate the QR code before adding the image, and tinker with the QR code settings to see if any of the alternative encodings happen to look nicer.

You can also allow the generator to change a few of those 95%-error data modules — QR codes have enough error correction in them that you can afford to change a few pixels and they'll still scan. (That's how QR codes with logos in the middle work.) But in practice that doesn't really affect image quality much if you diffuse the error from the data modules and it seriously affects how well the code scans.

Using these in real life

This all works pretty well if you don't take it too far and the code is going to be on a big screen or a poster or something. If it's on, say, a paper flyer that could get crumpled then you're going to need more of that redundancy, robustness and error correction that we gave up to make the QR code pretty. Ultimately it's a trade-off between aesthetics and scannability — and remember that just because a code scans on your phone, from a laptop screen, doesn't mean it will scan on a random stranger's potato phone from a printout in bad lighting.

Also bear in mind that the generator tool makes tiny images with no margin — some margin is needed to make a QR code scan reliably, and browsers will normally blur images when upscaling them if you don't disable that with CSS. The margin has to be the opposite colour to the middle of the big three "finder" pattern squares — normally that's white but you can generate inveted QR codes that need a black background instead.

The Daily Front Page 14 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — A Desktop for Yesterday
article

Os8088: A powerful Mac-like OS for the IBM XT, 286, 386

by jggonz·▲ 256 points·165 comments·os8088.com ↗
A Macintosh System 1-style desktop for the Intel 8086, written in real-mode assembly and booted from a floppy.

A Macintosh System 1-style desktop for the Intel 8086, written in real-mode assembly and booted from a floppy. Overlapping windows, pull-down menus, a serial mouse, loadable programs, and pre-emptive multitasking -- which the 1984 Macintosh did not have.

Boot it in your browser Download the floppies Screenshots

The os8088 desktop: a menu bar across the top, a Note Pad window with typed text, a Clock counting up, a Bounce window, the Control Panel showing a pre-emptive/cooperative choice, and the Task Manager with a CPU history graph -- five programs running at once, with a tile for each in the dock along the bottom.

Five programs running at once. A Note Pad loaded off the software floppy, a ticking Clock, a bouncing ball, the Control Panel and the Task Manager, each a separate instance with its own dock tile. The Task Manager reports the machine at 70% busy and 147K of RAM in use.

The desktop at rest, a few seconds after boot. The 512-byte boot sector has loaded the kernel and jumped to it. There is a floppy icon for each drive the machine reports through the BIOS, and the dock is empty because os8088 launches nothing at startup.

A menu is open only while the button is held. Press in the menu bar, drag through the items, release on the one you want. There is no spare copy of the screen to restore from, so the pixels behind the pull-down are copied into a block claimed off the heap for exactly as long as the menu is up.

A title-bar drag, caught halfway through. The window has not moved yet. A hollow one-pixel outline tracks the pointer in XOR mode, so erasing it is the identical operation to drawing it -- you can watch it invert the Disk window's own title text where it crosses.

Several instances of the same program. A Disk window, two Clocks and two Bounces, each a separate record in the instance table, each cascaded sixteen pixels down and right from the previous copy of its kind. Every instance gets a dock tile, and the tile's position is its table slot.

Keystrokes reach the front window only. Two lines typed on the emulated keyboard, wrapped in the window's 258-pixel content area, with the caret after the last character. Each Note Pad instance gets its own 512-character buffer, and as many can be open at once as the heap has room for.

The About box reads live kernel state. The word pre-emptive on the third line is rendered from the kernel's scheduler byte every time the box paints, so the About box, the Control Panel and the Task Manager cannot disagree about which scheduler is running.

The Task Manager, with its history graph filled. One sample every nine ticks into a 160-column ring, so a full sweep across the window is about eighty seconds of history. Apps with no task of their own get their window callbacks timed at the dispatch site and billed to them, so the rows still add up to one total.

The scheduler setting, read straight from the kernel. The settings pane keeps no copy of the scheduler mode: it reads the kernel's mode byte every time it draws. Click Cooperative and the very next timer tick declines to switch tasks, with no restart and no handshake.

Two of these five programs are minimized. Clock and Bounce were sent to the dock with the minimize box in their title bars, and their tiles draw inverted so you can see at a glance what is hidden. Minimized is not stopped -- the Clock is still counting, it only skips drawing.

The file manager, reading the software floppy. The software disk mounted on drive B:, with each file's name, size and its own icon. The icons come off the disk itself -- the browser peeks each file's first sector, where a package carries its own 16x16 bitmap -- so the list shows a real icon without loading it.

Two loaded programs, each in its own segment. MINES and HELLO came off the same floppy into separate regions claimed off the heap -- 2,048 bytes and 512 -- and each runs at offset zero inside its own, so nothing had to be patched on the way in.

Minesweeper: 1,510 bytes, loaded from the floppy. Double-clicking the MINES row read it into a segment of its own and opened its window; from then on its paint, key and click procs are plain near offsets the kernel calls exactly like a built-in's. This board is the only place in the system that uses more than two colors.

ArtfulType, a Markdown writer. ActionRetro's writing app for classic 68k Macintoshes, rebuilt for the 8086. Full-screen Writer mode with its own menu bar, styling as you type, and plain Markdown files that open anywhere else.

Tracker, a four-channel MOD player. Load an Amiga .MOD off the floppy and play it: the pattern scrolls under the playing row, four channel meters move with the music, and the desktop stays usable while it plays.

Paint, a bitmap editor. Pencil, eraser, fill, shapes, selection, eyedropper and text, with a resizable canvas, undo, a clipboard and sixteen colors. Reads and writes BMP and GIF.

Fractal, a Mandelbrot explorer. Zoom in, pick a color scheme, and watch the picture sharpen through three passes. It draws in the background, so the rest of the desktop keeps working while it renders.

Piano, a two-octave keyboard. Play it with the mouse or the computer keys. Notes appear on the staff above as you play, and the staff plays back. Three built-in songs, and FM synthesis on a machine with a sound card.

Recorder, for sampled sound. Record, stop and play, with a waveform display and a built-in demo tone. It uses a Sound Blaster where the machine has one and the PC speaker where it does not; the status line says which.

Solitaire: Klondike. Deal from the stock, drag cards and runs between the seven columns, build the four foundations up from the aces. Cards drag with an outline, the same way windows do.

Arkanoid, a brick-breaker. Move the paddle with the arrow keys, clear six rows of bricks, keep the score across levels. The ball runs on its own timer, so it keeps a steady speed whatever else is happening.

Minesweeper, on a 9x9 board with ten mines. Click a cell to open it, F for flag mode, N for a new game. Empty regions open in one click, and the first click is always safe -- the mines are laid after you have chosen where to start.

Note Pad, a plain text editor. Word wrap, a caret, and Open, Save and Save As through the system file dialog. It writes ordinary files onto the FAT12 floppy, so a note written here opens on a modern computer.

Hello: a window with two lines of text. It does nothing else. It ships as the smallest working example for anyone writing a program of their own, and as the only package with no icon, which is why the Disk window draws it with the generic one.

What it is

os8088 boots from the first sector of a floppy into a graphical desktop. There is no DOS underneath it and no command line anywhere in it -- the 512-byte boot sector loads a 40KB kernel, the kernel works out which display adapter the machine has and switches it into graphics, borrows the video card's own 8x8 character set, and puts up a menu bar.

Everything after that is the interface you remember from a 1984 Macintosh: windows you drag by the title bar with a rubber-band outline, menus you pull down and drag through, a close box and a minimize box, icons for each floppy drive, and a dock along the bottom with one tile per running program. Programs load from a second floppy and run as first-class applications, several at a time.

The whole thing fits in 256K of RAM on an Intel 8086 or 8088 -- the processor in the original IBM PC and PC/XT. It is a hobby project, finished enough to use. The source is real-mode NASM assembly, written with AI, and it is on GitHub.

Video log

os8088 gets recorded as it is built -- one video per step, from the first boot into a desktop to loadable packages. They are all on the video log.

By the numbers

Every figure below comes from the build.

Verified specifications of os8088 Kernel size80,486 bytesThe scheduler, window manager, VGA driver, mouse driver, sound layer, file manager, loader, Task Manager and Control Panel, all of it. Boot sector512 bytesLBA-to-CHS translation and retrying BIOS floppy reads. The build fails if it assembles to anything else. Segment footprint55,355 bytesCode plus every buffer the kernel reaches through DS. It must fit the 64K segment -- currently 10,181 bytes of headroom. The task stacks, the disk buffers and every loaded program live outside the segment and are not counted here. Sourcereal-mode assemblyNASM for the 8086, written with AI. No C, no linker, no runtime library. DisplayVGA, Hercules or CGAProbed at boot. VGA mode 12h is 640x480 in 16 colors -- four 1-bit planes, 80 bytes per scanline; Hercules is 720x348 and CGA 640x200, both monochrome and banked. Drawn straight to the framebuffer on all three. Back bufferoptional, off by defaultAn off-screen copy of the screen is 153,600 bytes, more than half the machine's memory, so a 256K machine always draws straight to the display, as the 1984 Macintosh did. At 500K or more the Control Panel can switch one on. Tasks12 slots, 1,536-byte stacksEach Clock and each Bounce window is its own pre-empted task. Context switch rate18.2065 HzThe PC's stock timer rate. Every tick the handler saves nine registers, swaps the stack pointer and returns into a different program. Loadable programsa segment eachPackages loaded from a second floppy into their own regions of conventional memory -- about 107K of arena on a 512K machine, 233K at 640K -- several resident at once, each freeing its memory when closed. Mouse1200 baud, 7N1A Microsoft serial mouse on COM1, three bytes per report, decoded in an interrupt handler that also draws the cursor. Target hardwareIBM PC/XT, 8088 at 4.77MHz256K of RAM, a serial mouse, and any of a VGA, Hercules or CGA card. Repaints are slow enough to watch happen. Instruction set8086 only, enforcedcpu 8086 plus -w+error, so anything newer is a build failure. A 1978 instruction set, mechanically guaranteed.

What it does

Four things it does. There are more on the screenshots page.

Pre-emptive multitasking

Two Clock windows counting up and two Bounce windows with squares moving around inside them, all animating at the same time.

No program has to cooperate. Two clocks keep time and two balls keep moving while you type into something else. The timer interrupt fires 18.2 times a second, saves whichever task was running, swaps the stack pointer and returns into the next one -- about thirty instructions. The Macintosh of the period did not do this: System 1 ran one application at a time, and MultiFinder, which arrived in 1987, was cooperative.

Rubber-band dragging

A Note Pad window staying still while a one-pixel rectangular outline is dragged across the desktop, then the window jumping to the outline's position.

The window does not move until you let go. A one-pixel XOR outline follows the pointer and the window is redrawn once, at the release. Repainting a whole window on every mouse report is not affordable at 4.77MHz, which is why the 1984 Macintosh did the same thing.

Loadable software

The Disk file manager showing the GAMES folder -- MINES.O88, SOLITAIR.O88 and ARKANOID.O88, each with its own icon -- with a Minesweeper window open on top showing a partly revealed 9 by 9 grid with colored numbers and red flags.

Programs come off a second floppy. Double-click a file in the Disk window and it loads into a segment of its own and runs as a real application. Minesweeper is 1,510 bytes including its icon. Several packages -- or several copies of one -- can be resident at the same time.

Task Manager

The Task Manager window showing a CPU percentage, a history graph swept across its full width, a RAM bar reading 39K of 639K, and a list of running instances with their state and CPU share.

The system reports on itself. A live CPU meter with a scrolling history graph, a RAM readout, and one row per running program. Apps without their own task get their window callbacks timed at the dispatch site and billed to them, so the rows still add up to one total.

On real hardware

Everything above was captured in an emulator. In August 2026 the disk images were written onto real floppies and booted on three period machines -- a 1981 IBM 5150, a Toshiba T1100 Plus and a 286 -- and photographed.

IBM 5150, 8088 at 4.77MHz

A green phosphor IBM 5151 monitor showing the os8088 desktop with a Note Pad, an About box, a Clock, a Task Manager, a Minesweeper board and a Disk window open at once.

Six programs at once on a 1981 IBM PC. A 5150 driving a Hercules card at 720x348, booted off a 360K floppy, with the machine's own card list typed into a Note Pad loaded from that same disk. Photographed by Elendilon, who reported no noticeable speed difference against the same system under emulation.

Some history

In February 1985 Digital Research shipped GEM 1.0 for the IBM PC: a Macintosh-style desktop with overlapping windows and icons, running on stock XT hardware. Apple sued. The settlement led to GEM Desktop 2.0 in 1986, which removed overlapping windows and desktop icons on the PC -- while the Atari ST version, not covered by the agreement, kept them.

So the PC briefly had this and then did not. os8088 is a rebuild of roughly that idea, from scratch, forty years later, on the same class of machine, plus the pre-emptive multitasking neither GEM nor the Macintosh of the period offered.

What it is not

  • It is not DOS and it does not run DOS programs. There is no DOS underneath it; it owns the machine from the boot sector up.
  • It has no memory protection. The 8086 has none to offer -- every program shares one 64K segment with the kernel, which is what makes a context switch cheap enough to be worth doing.
  • There are no file handles and no seeking. The disk API moves whole files at a time: write, read, delete, rename.
  • There is no networking.
  • It is a hobby project, not a product, though it is complete enough to sit down and use.

Try it

The browser demo boots the floppy image in an emulated PC -- the same bytes you would write to a disk. To run it yourself, the download page has 360K images for period hardware and 86Box, and 1.44MB images for QEMU.

Boot it in your browser Download How it works

The Daily Front Page 15 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Opus, Recast
repository

Microsoft Word for Windows 1.1a, Native X64 Port

by BruceEel·▲ 170 points·74 comments·github.com ↗
★ 205⑂ 16 forks C

Port of Microsoft Word 1.1a to x64 with extra features for research purposes.

This project is a fully working native Windows x64 port of Microsoft Word for Windows 1.1a, whose historical codename was Opus. It builds the original Word source and resources together with modern replacements for the 16-bit assembly, segmented-memory, and Win16 platform boundaries.

The result is the original Word application and user experience running as a 64-bit Windows executable. This is not an emulator or a reimplementation using a modern editor control.

Requirements

  • 64-bit Windows
  • Visual Studio 2022 with Desktop development with C++
  • A Windows 10 or Windows 11 SDK installed through Visual Studio
  • CMake 3.25 or newer
  • PowerShell

Build and run

Clone the repository, configure the included CMake preset, and build it from a PowerShell prompt:

git clone https://github.com/jmarshall23/msword.git
Set-Location msword\src

cmake --preset x64-debug
cmake --build --preset x64-debug

& ..\bin\WORD1.exe

For an optimized build, use the release preset instead:

cmake --preset x64-release
cmake --build --preset x64-release
& ..\bin\WORD1.exe

The presets use the Visual Studio 2022 x64 generator. After configuration, the generated solution can also be opened directly from out\MicrosoftWordX64Port.sln; use WORD1 as the startup project.

Test

Run the complete Debug test suite from the repository root:

ctest --test-dir .\out -C Debug --output-on-failure

Or, when your current directory is src:

ctest --test-dir ..\out -C Debug --output-on-failure

For a release build, replace Debug with Release. The suite covers the ported x64 runtime, original Word data structures and command tables, process startup, and automated UI workflows including typing, selection, formatting, dialogs, and saving.

Project layout

Path Purpose
src/Opus/ Original Microsoft Word/Opus application source and resources
src/OpusEtAl/ Original supporting tools, libraries, and build inputs
src/OpusProg/ Historical program documentation
src/port/original/ x64 compatibility layer, translated routines, and tests
src/port/tools/ Native replacements for historical build-time tools
src/cmake/ Resource and source-generation helpers
out/ CMake cache and generated Visual Studio solution
build/ Intermediate tools, tests, probes, PDBs, and diagnostics
bin/ Final executable and runtime files

out, build, and bin are generated locally during configuration and compilation.

How the port works

The original C and resource files remain the authoritative implementation. The port adds only the platform work needed to build and run that code safely on 64-bit Windows:

  • 16-bit x86 assembly entry points are translated to fixed-width C or C++.
  • Segmented and double-indirect memory handles are mapped to an x64-safe native runtime.
  • Win16-specific startup, messaging, graphics, file, and resource behavior is adapted to current Win32 APIs.
  • Original command, dialog, cursor, bitmap, and other generated assets are rebuilt by native host tools as part of the CMake graph.
  • Unit, runtime, smoke, and UI tests guard compatibility with the original algorithms and application behavior.

CMake inventories the legacy assembly tree but does not compile those modules into native targets. This keeps the historical implementation available as a reference while ensuring all shipped code is valid for AMD64.

Useful targets

Target Description
WORD1 The native x64 Microsoft Word executable
opus_original_engine Original Word application engine compiled for x64
opus_x64_runtime Native runtime and translated assembly behavior
opus_word1_ui_test Automated end-to-end UI test driver
legacy_sources IDE-visible reference collection of the original assembly

Build a specific target with:

cmake --build --preset x64-debug --target WORD1

Contributing

Changes should preserve the original Word behavior while keeping all native interfaces pointer-width safe. Prefer source-equivalent translations of historical routines, isolate unavoidable Windows API adaptation at the port boundary, and add focused tests for newly translated behavior.

Copyright

The historical source files retain their original Microsoft and third-party copyright notices. This repository does not currently include a top-level license file; review the applicable rights before redistributing the source or binaries.

The Daily Front Page 16 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Oberon Changes Chips
show hn

Show HN: A Project Oberon System version running on RISC-V instead of RISC-5

by Rochus·▲ 118 points·19 comments·github.com ↗
This is a version of the Project Oberon System migrated from Oberon 07 to the more common Oberon 90.

This is a version of the Project Oberon System migrated from Oberon 07 to the more common Oberon 90, using a recent version of the OP2 compiler with a RISC-V (RV32) backend; the repository also includes an emulation of a machine (VM) very similar to the one described by Wirth in his Project Oberon Book, based on the well-known RV32 emulator; the latter is a stripped-down and slightly modified version with only the interpreter, combined with my own implementation of the machine and the peripherals; the memory map of Wirth's machine is reproduced 1:1 so that Kernel.Mod, Display.Mod and Input.Mod are unchanged.

Here is a screenshot of the system running natively on the RISC-V VM:

Project Oberon System Screenshot

What is the Project Oberon System 2013

As you might know, between 1986 and 1989, Niklaus Wirth and Jürg Gutknecht at ETH Zürich designed and implemented an entire computer system, including an operating system, compiler, programming language, text and graphics editors, essentially by themselves, and then documented everything in the book Project Oberon - The Design of an Operating System and Compiler (1992).

Wirth continued this journey after his retirement. The sources published on projectoberon.net are written in Oberon-07, which is Wirth's last and most radical simplification of the language. There is also a free 2013 revision of the Project Oberon book available. The declared purpose of the 2013 project is unchanged from 1992: to provide a single book that serves as an example of a system that exists, is in actual use, and is explained in all detail.

The 1992 book and project used the National Semiconductor NS32032 processor, which "is now neither available nor is its architecture recommendable". Instead of retargeting the compiler to some other commercial architecture, Wirth decided to design his own processor, which he called RISC-5, "in order to extend the desire for simplicity and regularity to the hardware". He even implemented it with a programmable gate array (FPGA) and turned his design into "a real, functioning processor on a single chip". The whole system runs on a low-cost development board (Xilinx Spartan-3 by Digilent, with 1 MB of static RAM) that "easily accommodates the entire Oberon System, including its compiler". So for the first time not only the software but also the hardware of the Oberon System is described completely and rigorously. The hardware modules are implemented in Verilog , also available on projectoberon.net.

Thanks to the simplifications of language and processor, all parts that in 1992 had been written in assembly code (and were not in the book) are now expressed in Oberon as well, from device drivers to raster operations. Wirth based his new system directly on the original Ceres version, discarding the features of the later Oberon lines. "It has been my desire to present the system essentially as it existed 25 years ago, without embellishments". The result is a small and sufficiently complete system which is well documented and easy to migrate to other architectures. The entire hardware/software contract of Project Oberon consists of a memory map plus the instruction set.

Why the migration

The name collision with RISC-V is amusing, but the kinship is real at the level of RISC design philosophy: RISC-V, developed at UC Berkeley from 2010 on, is the fifth RISC architecture of the Berkeley line (RISC-I, RISC-II, SOAR, SPUR), and both Berkeley's and Wirth's share common design goals and features: e.g. a regular 32-bit load/store, compiler-friendly ISA, with fixed 32-bit base instruction encodings.

Migrating the Project Oberon System from RISC-5 to RISC-V is a pragmatic way to bring the system to widely available contemporary hardware while preserving the principles that make Oberon valuable. Espressif offers inexpensive, readily available microcontrollers in several ESP32 families, and board makers such as Olimex build practical development boards around them, for example the ESP32-P4-PC which provides all resources needed by the Oberon System at a very attractive price. Since the Oberon system does not require an MMU, it is well-suited for this type of microcontroller. So far, this migration runs on an emulated RISC-V machine, which helps both debugging and keeping the code close to the book. Future iterations will migrate this (and also System 3) to the mentioned Olimex board.

Wirth's own compiler (OR) targets his RISC-5 architecture and compiles Oberon-07. I could have added an RV32 back end to it; instead, this project reuses the OP2 compiler which I already used for the migration of Oberon System 3 to the Raspberry Pi. OP2 is itself part of the ETH Oberon heritage; its front end/back end separation was designed exactly for this: the same front end has produced code for SPARC, MIPS, i386, and recently ARMv7 and RV32. My OP2 modifications, the ARMv7 backend and boot linker have proven themselves in the System 3 migration. Extending OR would have meant maintaining another compiler. Migrating the system to the 1990 language keeps one compiler for both migrated systems, and the source code is still close enough to the book to keep it useful.

Migration Details

The original version of the Project Oberon source code was downloaded from https://www.projectoberon.net/ on 2026-04-14.

I particularly downloaded the following archives:

The latest file modification date is 2018-11-28. Each subdirectory of this repository corresponds to the archive of the same name, besides apptools and systools which have been merged in files.

Migrated all Oberon-07 sources to Oberon 90 so that they compile with the ActiveOberon project o2c compiler and OP2. Some notes:

  • INTEGER renamed to LONGINT throughout
  • SYS.Mod provides the Oberon 07 built-ins not present in Oberon 90
  • byte-sized data becomes SYSTEM.BYTE where possible, or CHAR where unavoidable
  • type case statements are expressed as IF with IS relation and type guards
  • array assignments that Oberon 90 rejects use COPY
  • Oberon 07 byte-string literals ($..$) are initialized at runtime via SYS.PutHex
  • ORD(SYSTEM.BYTE) is signed in OP2, so we use CHAR instead where necessary
  • SYSTEM.BIT with variable instead of constant address because of OP2 issue

Implemented a RISC-V machine based on rv32emu similar to Wirth's RISC-5 described in PO book and made the necessary (minimal) changes to the Oberon code to run it.

All modules are linked into the boot image by the boot linker and their bodies have been executed at startup, no dynamic loading.

Added additional apps, see readme in corresponding subdirectory.

Precompiled versions

So far, the following version is available

Note that the included po.bin and disk.img files work on all platforms. Only the rv32vm executable is platform dependent. If you therefore just want to build the vm on another platform, you can reuse the other files.

How to build

There is a build.sh in the vm subdirectory which has to be run first. Then the build.sh in the root can be executed like

  • ./build.sh run to build, pack and run the system in the VM
  • ./build.sh disk to build and pack the system without running it
  • ./build.sh link to build and link the system without creating the disk nor running it
  • ./build.sh just compile all Oberon modules and stop

The build scripts were implemented and tested on Debian Bookworm Linux.

There is also a qmake (vm.pro) project to build the VM which is likely to work on macOS as well, but it has only been tested on Linux so far.

The VM can also be built using the BUSY build system; it only requires a C99 compiler and SDL2 and has successfully been tested on Linux and Windows. An SDL2 development package matching your toolchain has to be downloaded. Use -P win_sdl_dir=<path> with path pointing to the root of the SDL2 directory (where SDL2/include and SDL2/lib exist). Run the system on Windows with rv32vm.exe --base 0x0 --disk disk.img po.bin

Credits

  • See oberon_license.txt which applies to the Oberon source code and documentation.
  • See vm/rv32emu/README_orig.md and vm/rv32emu/LICENSE for more information about the RISC-V emulator.
  • See vm/softfloat/README_orig.md and vm/softfloat/COPYING.txt for more information about the Berkeley SoftFloat library.
  • The machine in the vm subdirectory is available under the terms of the GNU General Public License (GPL) versions 2.0 or 3.0 as published by the Free Software Foundation.
The Daily Front Page 17 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Repair Desk
article

Reviving a four year old reMarkable 2

by oskrim·▲ 155 points·102 comments·oskrim.github.io ↗
The device was in a sorry state.

I found my old reMarkable 2 paper tablet, bought in 2021, it had sat unused for ~4 years or so. The device was in a sorry state:

  • Cloud sync failing. The only thing showing was a cryptic error 0.
  • Software update didn’t work.

This post details how you might be able to bring your tablet back to working order if you find yourself in a similar situation.

The clock

Googling the error I found a forum post with what its author called “the fast solution”, SSH in, set the clock:

ssh root@10.11.99.1          # USB. over wifi: the tablet's LAN IP
# password: on the tablet, Settings → Help → Copyrights and licenses → General info
# (username root, password, IPs all listed there)

timedatectl                  # confirm how far off it is
timedatectl set-ntp 0        # disable auto time first, or set-time errors out
timedatectl set-time '2026-07-15'
timedatectl set-ntp 1

After setting the time, I was able to download a software update.

Update: This failure mode is also documented in an official support article: an out-of-sync device clock can prevent software updates.

Software update

After the first software update, cloud sync now gave me a different error: HTTP 400. I found the actual error message in the journal: “Unable to sync. Please update this application to continue using the reMarkable cloud.”

journalctl -u rm-sync.service --since '-45 min'

The cloud was rejecting my obsolete system version. Turns out the first update only brought the tablet to 3.11.2.5 and wouldn’t update further.

journalctl for swupdate.service showed Couldn't resolve host name (after the post-update reboot, the updater had started before wifi/DNS was up and never retried). Restarting the update services made the Settings screen offer 3.27.3.0, and a second update brought the tablet to the latest available software version.

systemctl restart swupdate.service update-engine.service
systemctl is-active swupdate.service update-engine.service
journalctl --since '-1 min' -u swupdate.service -u update-engine.service

Starting with version 3.22 of the software, SSH over wifi is now silently disabled by the update, so port 22 refuses on the LAN.

SSH in to the tablet via USB (e.g. 10.11.99.1) instead. Re-enable network SSH with rm-ssh-over-wlan on, or drop the marker file rm_enable_ssh_wifi_marker (the dropbear-wlan.socket unit is already enabled, just inactive)

rm-ssh-over-wlan on
systemctl is-active dropbear-wlan.socket
systemctl is-enabled dropbear-wlan.socket
test -e /home/root/.config/remarkable/rm_enable_ssh_wifi_marker && echo present
ip -4 -brief address show wlan0
ss -lntp | grep ':22 ' || true

Importing files over SSH

For whatever reason, cloud sync still appeared to be broken, it wouldn’t pull any of my new uploads.

Instead of debugging this further (by now I was done dealing with the cloud sync), I found that the tablet has an optional web server that can be turned on, to allow you to upload and export files from the device. I backed up the xochitl config before toggling it on (WebInterfaceEnabled=true):

conf=/home/root/.config/remarkable/xochitl.conf
cp -p "$conf" "$conf.backup-before-usb-web"
if grep -q '^WebInterfaceEnabled=' "$conf"; then
  sed -i 's/^WebInterfaceEnabled=.*/WebInterfaceEnabled=true/' "$conf"
else
  sed -i '/^\[General\]$/a WebInterfaceEnabled=true' "$conf"
fi
systemctl restart xochitl.service
grep '^WebInterfaceEnabled=' "$conf"
systemctl is-active xochitl.service

Update: The web server can also be enabled in the device UI, go to Settings → General settings → Storage → USB web interface.

Inspect and upload PDFs:

curl --max-time 30 -sS http://10.11.99.1/documents/ | jq -r '.[].VisibleName'

set -e
for file in ./my-pdf-files/*.pdf; do
  name=${file##*/}
  status=$(curl --max-time 300 -sS -o /dev/null -w '%{http_code}' \
    -F "file=@${file};type=application/pdf" http://10.11.99.1/upload)
  printf '%s\t%s\n' "$status" "$name"
  test "$status" = 201
done

After this, you should be able to find and read the new files in the My Files view. I never did fix the cloud sync, I find uploading files over SSH to be more convenient anyway.

The Daily Front Page 18 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Finding a Better Route
article

Improving Heuristics for A* Pathfinding

by bobbiechen·▲ 338 points·39 comments·redblobgames.com ↗
A third way to optimize is improving the heuristic function.

On my Introduction to A* page I cover the basics of the A* algorithm. To optimize it, we usually look at the priority queue implementation or reducing the size of the graph. A third way to optimize is improving the heuristic function. Here’s an example from the town of Denerim in Dragon Age Origins. Try moving the start B and goal to see A* in action:

On this page I’ll show a way to improve the heuristic by adding “landmark nodes”. Try moving the landmark L to be near the goal. As the heuristic value gets closer to the true distance, the area A* explores goes from to. The blue area is the savings.

At the end of the page are demos of how this technique helps with maps from real games. Although the demos on this page use grids, this optimization works for any type of graph, not only grids.

1 A*’s use of the heuristic

A* uses a heuristic to guide it towards the goal. We can think of it like wind pushing us in the right direction. Here, the heuristic pushes us east, and the shortest path goes east:

But sometimes it pushes us in the wrong direction. Here, the shortest path leads west of the B but the heuristic pushes us east:

A* runs faster when the heuristic guides us in the right direction. It wastes time when the heuristic guides us in the wrong direction. But why is it in the wrong direction? It’s because the commonly used distance-based heuristic doesn’t know about the walls.

2 Perfect heuristic

Ideally, we’d find a heuristic that knows about walls and never points in the wrong direction:

Can we calculate this “perfect” heuristic? Yes!

But the perfect heuristic is different for every goal and wall configuration. Move the goal and you’ll see the heuristic changes. Move the start B and you’ll see it doesn’t.

If the goal and walls stay the same, then we can use flow field pathfinding. But usually the goal isn’t the same, so we need to construct a brand new perfect heuristic for each goal. That is impractically slow to calculate every time we run A*, and it’s also too large to store if we want to compute it ahead of time.

It’d be nice if we could calculate the heuristic once and then reuse it for multiple A* runs with different goals.

3 Reusing a perfect heuristic

Let’s calculate a perfect heuristic to the green L, which we call a “landmark”. Can we reuse it for another goal? Yes, sometimes! Move the start point B and the landmark L around to see which purple goals are helped:

The idea is that if we already have the path from B→L, we also get the shortest path to any along the way:

Think of the landmark as something far in the distance. Your friend tells you “from your house B, walk towards the Eiffel Tower L until you get to Daniel’s house”. The goal is not to reach the landmark. The landmark tells us a direction to go in. The goal, Daniel’s house, is on the way.

Most goals aren’t on the path B→L but sometimes they are close to that path:

But what does it mean to be “close”? We can use the path length, cost(B, L). When the paths are almost the same, cost(B, L) is close to cost(B, X) + cost(X, L).

In A*, we use the heuristic function as a lower bound for the path length cost(B, X). The triangle inequality[1] says that the sum of two sides of a triangle is at least as long as the third side. Adapted for directed graphs, we can say cost(B, X) + cost(X, L) ≥ cost(B, L). To calculate a lower bound, we rewrite this inequality as cost(B, X) ≥ cost(B, L) - cost(X, L).

That’s the key idea here. It’s impractical to precalculate all costs to all locations, but if we’ve precalculated the costs to a specific location L, we can use that to estimate the cost to a different location.

Some of the academic research papers refer to this as a heuristic based on the triangle inequality. Other papers call this the “differential heuristic” because it takes the difference between already computed distances.

4 Multiple landmarks

How often is this triangle inequality useful?

It depends on where L is relative to the path B→:

Relative positions Landmark useful?
before L B only in undirected graphs
middle B L no
after B L yes

Move the start B and goal around to see where a landmark would help:

Try moving the landmark L outside the green shaded region, and see that the heuristic and path don’t always match.

Since a landmark needs to be “after” the goal, a single landmark won’t be useful for all paths. We need multiple landmarks L₁, L₂, L₃, etc. Each one gives us some lower bound for the heuristic:

cost(B, X) ≥ cost(B, L₁) - cost(X, L₁)
cost(B, X) ≥ cost(B, L₂) - cost(X, L₂)
cost(B, X) ≥ cost(B, L₃) - cost(X, L₃)
…
cost(B, X) ≥ cost(B, Lₙ) - cost(X, Lₙ)

We can take the max() of these to pick the highest bound. In this diagram, try moving the goal to one of the purple shaded areas to see how those areas are improved by the landmarks. Then try moving it to one of the unshaded areas to see how A* isn’t any faster there. Try moving the start point B to see how the shaded area also depends on where the start is.

5 Placement of landmarks

The best landmark position depends on the start point B and goal. We want the landmark to be “after” the goal, but what’s “after” depends on where the start point B and goal are.

We want to use landmarks to improve as many (start, goal) pairs as possible.

Let’s start with a single landmark. Try moving the start B, goal, and landmark L on this map:

The purple shaded areas show the goal positions that the landmark helps. It looks like the landmark can cover the main corridors but not the side rooms. We need many more landmarks:

Much more of the map is covered in purple now. Picking the number and placement of landmarks is project-specific. Consider:

  • Are all paths equally likely? For example in a colony builder game like Dwarf Fortress, we may care a lot more about paths to/from the main base, and not paths between a forest and a mine.
  • Are all paths equally valuable to optimize? For example if pathfinding is limiting the frame rate, we might want to focus on long paths that are slower to compute and not on short paths.
  • Is the map static or does it change over time? If static, we might want to spend a lot of time in the map designer tool to precalculate optimal landmarks. But if dynamic, we might want to use the last few goal locations to decide new landmark positions.
    • If the change reduces an edge cost, the heuristic will overestimate sometimes, and A* will return a non-shortest path until we update the cost table. Pathfinding is optimized but nonoptimal. Example: the player broke a wall but the unit won’t look for the shorter path right away.
    • If the change increases an edge cost, the heuristic will be lower than desired, and A* will take a little longer to run until we update the cost table. Pathfinding is optimal but not optimized. Example: the player added a wall so the unit might think that area’s safe to walk through but will have to find a path around it.
  • If many units find paths to common areas (such as the Dwarf Fortress dining room), consider dropping the least used landmark and adding one near the common area.
  • Are the maps open-world or constrained? A real-time strategy game may have different needs than a room+corridor dungeon crawler.
  • Thomas Nobes has a video explanation[2] including more tips on where to place the landmark points.

Fortunately, even if a landmark isn’t optimal, it might still help somewhat, and it’s still no worse than if we use the regular A* heuristic.

6 Automated placement

Although the best landmark positions will be project specific, one algorithm to place landmarks in a project-agnostic way is to keep track of which locations are good for many randomly chosen paths. Try it here to find a landmark position:

It usually but not always picks a spot in the upper left. It matches our intuition that landmarks should go on the outer edges of the map.

The second landmark should be away from the first landmark. The third landmark should be away from the first and second landmark. Each subsequent landmark should be evaluated based on what it adds. This is what it looks like with two existing landmarks:

It picks a third away from the first two, but not always in the same place.

7 Implementation

The change described on this page is to the heuristic function given to A*. We don’t need to change A* itself.

We need to pick landmarks. If the maps are known ahead of time, landmarks can be placed in a map designer tool. If the maps are procedurally generated, try the randomized map analysis earlier on this page. Some of the papers linked at the end have more sophisticated placement algorithms.

Then we need to analyze the map. Allocate a 2D array of numbers, cost[nodeId][landmarkId].

For each landmark, we run Dijkstra’s Algorithm. It’s a “single source shortest path” algorithm but we want a single goal instead of a single source. In a directed graph, we need to reverse all the edges. In an undirected graph, we can use the edges as is. We set cost[nodeId][landmarkId] to the cost of the shortest path from node nodeId to node landmarkId. If the weights are all 1, we can use Breadth First Search instead of Dijkstra’s Algorithm.

This is approximately what I’m running for the demos on this page (undirected graphs):

const L = [ /* array of landmark locations */ ];
let L_cost = [ /* array[nodeId] of arrays[landmarkId] */ ];
for (let landmarkId = 0; landmarkId < L.length; landmarkId++) {
    let output = dijkstraSearch(L[landmarkId]);
    for (let nodeId = 0; nodeId < graph.num_nodes; nodeId++) {
      L_cost[nodeId][landmarkId] = output.cost_so_far[nodeId];
    }
}

Note that it’s not much code. It’s running our existing algorithm (Dijkstra’s, A*, or BFS) and storing the results in an array. It could run in a background thread.

Then we need to modify the heuristic function. Previously the heuristic was distance(B, X). For example:

function heuristicManhattan(a, z) {
    return Math.abs(a.x - z.x) + Math.abs(a.y - z.y);
}

Each landmark Li gives us a lower bound cost(Lᵢ, X) - cost(Lᵢ, B). We want to take the highest of these:

function heuristicLandmark(B, X) {
    let h = heuristicManhattan(B, X); // or any base heuristic
    for (let i = 0; i < L.length; i++) {
        let lowerBound = L_cost[B][i] - L_cost[X][i];
        lowerBound = Math.abs(lowerBound); // if undirected
        if (lowerBound > h) { h = lowerBound; }
    }
    return h;
}

Note that it’s not much code. It’s running the existing heuristic (typically Manhattan, Chebyshev, or Euclidean distance) and sometimes increasing it if the landmarks form a good triangle.

What changes with the A* code? Nothing.

There are lots of techniques for making A* run faster. I like this one because it’s very little code.

8 Demos

I tried the differential heuristic on some maps from Dragon Age (provided by movingai.com[3]), a maze (also provided by movingai.com), and Cogmind[4] (maps provided by Josh Ge). All of these maps are undirected graphs (edges are bidirectional) so I’ve used that version of the differential heuristic.

  • The blue area is what we no longer have to search by using the differential heuristic. The orange area is what we search even with the improved heuristic.
  • Try moving the start B and goal to see the performance on different paths.

8.1 Dragon Age, The Circle Tower

The landmark is badly placed for the initial B→ path. Try moving it.

8.2 Cogmind, Factory 5

In the next demo the landmarks L are in places that don’t help. Move them around to improve search.

The blue area are the nodes we no longer have to search. More blue is better.

The landmark L points help more when closer to the start point B than the goal. They help more when they’re “past” the goal point. Move the start B and goal around and see that there’s a big improvement no matter which path you want to find:

However, it took a lot of landmarks to get that improvement. We can do better by using the random path map analysis to pick fewer landmarks but in smarter locations:

8.3 Maze

A* with a distance heuristic behaves particularly badly with mazes, but in this one, just four landmarks make a big difference! Then try clicking Random path repeatedly. The blue areas are the areas we didn’t have to search by using the landmarks. Also toggle the bidirectional flag to see how much of a difference that makes.

8.4 Dragon Age, Lothering

This map has large open areas, and it seems to work well with the landmarks.

8.5 Cogmind, Research 2

This is a room-and-corridor map from Cogmind.

8.6 Cogmind, Factory 4

Another room-and-corridor map, common in traditional Roguelike dungeons.

9 More reading

This page is about using Cartesian coordinates in a game map to construct a graph-based heuristic based on “landmark” nodes (sometimes called “pivots” or “beacons”). I’ve collected some references but haven’t read all of them so I may have some of this wrong.

  • 2004 Computing the Shortest Path: A* Search Meets Graph Theory (Goldberg, Harrison). I learned about the technique in this paper. It’s a combination of bidirectional A* search and the landmark-based heuristic, used for road networks. It uses the terminology “landmarks” and “triangle inequality”.
  • 1994 Routing information organization to support scalable interdomain routing with heterogeneous path requirements (Hotz). I can’t find a copy of this online, but it appears to be work that introduced using the triangle inequality with landmarks, for Internet routing.
  • 2005 Approximate Distance Oracles (Thorup, Zwick). This theory paper covers the more general topic of calculating the approximate distance between any pair of nodes in a graph, using a “distance oracle”. An approximate distance is what we need as the heuristic in A*.

It’s also possible to go in reverse. Many graphs do not have natural Cartesian coordinates, and even the ones that do may not have good results from a distance-based heuristic.

  • 2002 Predicting Internet Network Distance with Coordinates-Based Approaches (Ng, Zhang). This paper uses the landmark-based heuristics to assign Cartesian coordinates for nodes in an Internet routing network. Then it uses Euclidean distance for the heuristic. This is the inverse of what we’re doing on this page, where we already have Cartesian coordinates, but want to use the landmark-based heuristic instead.
  • 2011 Euclidean Heuristic Optimization (Rayner, Bowling, Sturtevant) transforms the Cartesian coordinates on a game map where distance heuristics don’t work well into new Cartesian coordinates where distance does work well.

Storing the landmark data requires one number per node. In a typical game map, those numbers may be very similar from one grid space to the next. Just as image compression takes advantage of nearby pixels having similar values, we might want to compress the landmark data because nearby graph nodes have similar values:

  • 2011 The Compressed Differential Heuristic (Goldenberg, Sturtevant, Felner, Schaeffer) — by storing more landmarks in the same amount of space, the heuristic can be better. In this paper, “landmarks” are called “pivots”, and the “landmark based heuristic” is called the “differential heuristic”.

The landmarks L used on this page are placed after the end of the path, so the layout is B→→L. There are also algorithms that place landmarks along the path, B→L→L→L→. I am not covering that topic here, but if you’re interested, see:

I learned about this technique in 2007, then tried writing it up in 2015. I realized that I didn’t understand it enough to be able to explain it. I studied it off and on in 2016, 2018, 2019, 2022, 2024, and 2026. I abandoned and restarted this page many times. And by 2026 I think I understand it well enough to write this page. However I haven’t used it in a real project yet.

The Daily Front Page 19 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — The Shape of Challenge
article

Making difficulty curves in games

by hakkikonu·▲ 169 points·85 comments·davetech.co.uk ↗
The idea of a difficulty curve is all wrong

The games industry is weird because we are always trying to create systems that keep the game just hard enough to stop people from seeing the rest of the product.

My thought process all started from this Tweet:

We agonised over this when we made lemmings and we took a long time smoothing the difficulty curve and we broke up the step changes into different sections, like chapters rather than difficulty settings. This let the user choose and set expectations.

— Russell Kay (@RussellKay) May 23, 2018

What is a Difficulty Curve?

So briefly when I talk about a difficulty curve I’m talking about how games scale the difficulty for each level / puzzle. For example, you don’t want to introduce too many gameplay systems too quickly, but also you don’t want the first 10min of each level very slowly teaching the player something they already understood 5min ago.

This gets hard as a game developer because we are playing the game all the time and inadvertently get really good. It’s hard to put yourself back into the mind-set of someone playing our game for the first time, and simple things like how tricky a jump should be or what each button does becomes meaningless.

I think there is a perception that games need to get harder and harder the further in the player gets. But really this isn’t true, you just want to give players the feeling of getting better and the digital-pat-on-the-back for doing so.

I Present To You, The Difficulty Saw!

Rather than seeing the game as getting more difficult on the whole, we are grouping mechanics together like in the original Tweet.

What do I mean when I say New Mechanic? This might be:

  • A new enemy type
  • A new ability the player has
  • A new type of puzzle
  • A way of using a system in the game (like Mario’s triple jump)
  • A new item
  • Using an existing system in a different way
  • Combining multiple existing mechanics in a new way
  • Adding a new rule (like time limit)

Now I’m not saying a new mechanic should be introduced every level, I’m not saying a level should start at 50% easier than the one before and be 150% harder by the end, I’m not saying a game should only be 4 levels long, I’m not saying that the increase each time should be the same (for example games that are easy to learn hard to master), I’m not saying mechanics should only be introduced at the start of a level, I’m not saying there should be only one new mechanic a level.

Smoothing the Curve

Our objective is still to “Smooth out the curve” and I know it looks like we have made this worse, but to be clear when we try and make it more gradual we are talking about removing outlying variances (either too hard or too easy) and giving each mechanic its own difficulty curve.

Why is This Graph Important?

Players want to feel like they are always progressing (both in their own skill and towards the end of the game) so the more time in your game they are going up this curve generally the better the game (this is a massive simplification I know)

If at any point your graph is too steep / shallow this is when people get frustrated / bored. Now there is a problem with the fact that each person will have their own unique gradient (and each puzzle will have a different learning curve per person as well).

Tricks for Keeping Everyone on the Right Part of the Curve:

DO:

  • Put in optional collectables
  • Provide tricky alternate routes that skips easy parts
  • Have areas that give you a better high score
  • Achievements that reward people playing with a disadvantage
  • Dynamically adjust the difficulty depending on how well the player is doing. <- This is actually magic sauce and could be the topic of a whole talk.
  • Have multiple endings.
  • Allow people to grind for exp or practice if they feel they are not capable of an area.
  • Have multiple paths so if the player gets stuck they can do another task until they have the skills needed to go down the main path.
  • Make it obvious what equipment players need to be using for this puzzle (by giving it to them right away, giving them ammo for the needed weapon, colour coding things, removing previous equipment that is not needed for this puzzle)
  • Give people multiple ways to learn something (text, voice over, button prompt, particles showing where they need to go, environmental graphics, lighting, help popups, visual cues)
  • Give subtle graphical hints (In Mario there will be a little flower or coin where you need to start a jump)
  • Just visually show them (often in games before being given a new weapon you will see an enemy use it on the other side of a window, or you will see the kind of damage it has done to other NPCs in the room)

DON’T:

  • Don’t make the game easier for people who are doing better (for example putting skill points in an area only expert players can get to)
  • Don’t punish someone for doing bad and make future attempts harder
  • Don’t allow someone to skip an area if they haven’t learnt the skill they need
  • Don’t hide things as the main mechanic of a puzzle
  • Don’t put a long cutscene / intro that can’t be skipped in an area with lots of retry attempts.
  • Don’t display things the player doesn’t need to know right now (don’t overwhelm them with descriptions of skills that are not on their path)

Of course none of these are mandatory but I wouldn’t break too many in one go

Something I should have noted long before this is every game has its own curve, you may get feedback from your friends that a task is too easy/hard, but they might not be who you are targeting. You might be making a casual mobile game that has a really long shallow curve, or a brutally hard game where the player spends 100 lives just trying to get past each section.

Again I’m making massive simplifications but I wanted to show the large range of personality types and it multiplies in complexity when you start combining them together and adjusting for personal skill level etc.

This is why it is IMPOSSIBLE to make a game for everyone!

Don’t try and make a game that fits everyone, you need to pick a target market and get feedback from people in that group.

A Really Generic Level Breakdown:

Let’s go through an example level design that illustrates learning wall jumping (however you should insert your own far more interesting mechanic).

Teaching the mechanic:

  • Start in safe area and the only way out is the wall jump
  • There should be minimal distractions
  • The main thing to learn should be easily visible, well lit, and potentially highlighted with particles, pickups, a scuff where they need to jump)
  • (after this point you know the player can wall jump)

Main body:

  • Wall jump with manageable danger (enemy in front / spikes under)
  • Wall jump mixed with a mechanic they learnt in a previous level
  • Wall jump with pressure (enemies / lava chasing behind you)

Finale:

  • Basic technique made harder with a quirk (avoiding obstacles)
  • Optional area where the player can show off what they learnt to get a collectable.

Finding the skill curve of my game?

Of course at some point you will be sending out copies or screenshots of your game to get criticism, but after that you are going to want a more empirical way of collecting data.

  • Many games like Mario Maker record the location when a player dies, now this isn’t going to help tell you if someone is stuck on a puzzle, but if you have a level where all the deaths are in a very small area it’s likely you will find that part is above the difficulty curve. I don’t want you to remove all deaths from your levels, but it is better if they are evenly spread out.
  • Collecting level complete stats can also be very helpful. If 80% of people finish level 4 but only 20% of people finish level 5 you know level 5 is either too hard or too boring. Likewise if level 11 is completed more than level 10 you might find level 11 is more fun than level 10 and you need to retrospectively make your levels more like level 11.
  • You can make asking friends more objective by having direct questions like “what did you think about level 8?” or “How long did you spend on level 9?” however you then want to record this on a spreadsheet and combine it with other testers data, if you have outlying data that is something you need to deal with.
  • With current technology it is really easy to capture footage / stream gameplay. This means you can watch people and understand what they are thinking. It is worth knowing that when people know they are being watched they do tend to act differently, but you might see players trying the wrong solution to a puzzle and this will help you adjust things to point people in the correct direction.
  • Using Streamers and reviewers is great because they are likely to be used to playing / reviewing games and they will voice what the press will say about your game. The downside is if you are already engaging with reviewers it’s going to be too late to make substantial changes.
  • If you ever end up taking your game to an expo you will get a steady flow of people trying your game for the first time. This is a great ideal time to watch people, ask them questions and really perfect your games on-boarding process. Now it’s not ideal circumstances for the player because it’s always loud / busy and they will probably be burnt out and have a short attention span. However by sitting down and playing the game they have shown that they are a potential buyer (even if they are not in your target market)
  • QA testers and review sites, getting Quality Assurance testers is expensive, however there are plenty of websites and forums where you can submit your game for feedback.

Don’t just make the game harder; Show the player they are getting better.

Something that works well is to show people how far they have come, you see games having nods back to previous puzzles, often they add something fresh or obfuscate it but it’s nice for the player to see how much better they are now. Plenty of times I’ve been playing a game and I didn’t get a simple puzzle because I’m expecting something harder, but it turns out the answer is a twist on something I learnt earlier in the game.

On this same vein I get really excited when I find out a game had a really hard puzzle on the first level hidden in plain sight, but it isn’t until later levels that you learn how the puzzle works. It’s like a locked door where the key is knowledge. (I wanted to give some examples of this but then I thought just naming the game is a massive spoiler)

This does allow us to talk about one fantastic trick that really ties into the whole idea of keeping people on the correct part of the graph. Hiding a shortcut with pure knowledge. Portal 2 has a great example of this, one of the levels has the start and end of the level right near each other, and with some clever placement of portals it is possible to skip the whole level, however it uses techniques you don’t learn until later in the game, the developers knew about this but said if someone is able to trick their way straight to the end then the level has nothing to teach them.

Giving People Highs and Lows of Adrenalin

One thing that films have become very good at is switching between periods of high action adrenalin and calm. The reason for this is as humans we get saturated with similar stimuli and start to block it out. Knowing when to switch is a real art form, the feeling is also exaggerated by the contrast between the two.

There is also a trick of trying to outdo what came previously so as you watch something it is always emotionally peeking one way or another.

Bringing this back to game design I think we should be using this kind of technique, not just for emotional things but for difficulty, entertainment, learning skills etc etc.

So while this whole article has been talking about level difficulty my original thought stream was about how quickly the player unlocks new rooms that they can add to their spaceship in Undercrewed. But it’s all the same thing! This same concept can be used for difficulty, introducing game mechanics, introducing new skills and abilities, introducing new enemies, introducing new play modes.

I have a subsequent article here with examples of adjusting difficulty and how to monitor it.

The Daily Front Page 20 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — The Hexagon Desk
article

There Are Magic Hexagons of Every Order

by gukoff·▲ 192 points·31 comments·gukov.dev ↗
What is so special about the number 19?

What is so special about the number 19?

The question came up last month in a conversation among YSDA alumni, when the school turned 19. Someone pointed out that 19 is a twin prime. Someone else replied that 19 is the number of cells in the only non-trivial normal magic hexagon.

Wait, what is a “magic hexagon”? Let us start there.

A note on AI-assisted mathematics

Recently, we have heard a lot about AI miraculously proving and disproving long-standing conjectures, often without much explanation of how it was done.

This story offers a look inside the process of making such a mathematical discovery.

Magic Squares and Magic Hexagons

You probably know about magic squares. A magic square is a square grid of numbers in which every row, every column, and both main diagonals add up to the same total, known as the magic constant. We also usually require the numbers to be consecutive - typically from $1$ to $n^2$ - and call it a normal magic square. Otherwise, we could simply put the same number into every cell, which would be a very boring way to fill a square.

All illustrations on this page are interactive. Click on them!

Magic squares have been known for millennia and are now very well understood. We have algorithms for constructing normal magic squares of every order $n>2$.

A magic hexagon applies the same idea to a hexagonal grid. Its cells form straight lines in three directions, and every such line must have the same sum. As with squares, a magic hexagon is called normal if it contains the consecutive numbers from $1$ to $3n^2-3n+1$, the total number of cells in a hexagon of order $n$.

Above you can see the only non-trivial normal magic hexagon in existence - apart from its own rotations and reflections. The proof is straightforward. In each of the three directions, the cells are partitioned into $2n-1$ lines. Therefore, the sum of all the numbers must be divisible by $2n-1$. For every order $n>3$, the sum of the numbers from $1$ to $3n^2-3n+1$ fails this divisibility test.

Well, ending the story here would be no fun. To make things more interesting, let’s look at the so-called abnormal magic hexagons. Here we relax one constraint: the numbers on the grid must still be consecutive, but they no longer have to start at $1$.

This small relaxation suddenly allows new solutions to appear.

Finding them, however, is not easy. Unlike with magic squares, there was no formulaic construction or deterministic algorithm. The only known approach was to wander through a brutally large search space of possible arrangements. According to Wikipedia, as of July 2026, the largest known solution was a hexagon of order $n=9$, found by Klaus Meffert in 2024.

So… what makes these solutions so hard to find? And how about we try?

Chapter 1: Making Observations (With Human Brain)

There is a clear tension between two independent constraints:

  1. The numbers must be consecutive;
  2. All line sums must be equal, even though the lines have different lengths.

The prior solutions I found suggested that people had already tried several search algorithms and likely optimized them well. That made me think that, if I wanted to advance the field, I should focus not on making the search faster, but on making the search space smaller.

Observation: Antisymmetric hexagons are much simpler

First, let’s restrict the numbers on the grid to the symmetric interval $-K,\ldots,K$ for some $K$. If all line sums are equal, this is equivalent to requiring that every line sum be zero.

Second, put $0$ in the center and require that cells opposite each other under a 180-degree rotation contain opposite values. If one cell contains $x$, its antipodal cell contains $-x$.

Notice how many constraints disappear. Every line through the center sums to zero automatically because its values cancel in opposite pairs. Every other line has an antipodal line with the sum of antipodal opposite numbers. If one of them sums to zero, so does the other.

Of course, simplifying the constraints introduces a risk: perhaps no solutions satisfy the extra symmetry at all. At this point, antisymmetry was simply a plausible place to search, following the drunkard’s principle.

But once I started thinking about zero-sum hexagons, another structure appeared.

Observation: Every zero-sum hexagon is built from the same 6-point ring

Quick note

This observation is interesting but not essential for what comes next. If you find it hard to follow, feel free to skip this part.

Consider any hexagonal grid, zero-sum or not. Take the six cells surrounding any interior point and add the alternating pattern \([-1,+1,-1,+1,-1,+1].\) Leave the central cell unchanged.

Every straight line that intersects this ring receives either no contribution or two opposite contributions, $+1$ and $-1$. Its sum therefore remains unchanged. We can add any multiple of this pattern without changing a single line sum.

These local alternating rings form a basis: every zero-sum hexagon can be built as a unique linear combination of them. I will omit the proof for brevity, but the idea is fairly straightforward. Starting at the outer layer, choose ring coefficients that cancel its cells, then peel the layer away and continue inward by induction.

An order-$n$ zero-sum hexagon therefore has two equivalent representations:

  • its visible cell values;
  • an order-$(n-1)$ potential field, recording how much of each local ring it contains.

The potential field representation also satisfies every line-sum constraint by construction. It does not, however, guarantee that the visible values are distinct and consecutive. Those remain difficult global constraints.

Below you can play with the potential field of the order-3 antisymmetric hexagon. Notice that however you change the potential field, the line sums in the hexagon remain zero. However, making the hexagon “magic” is still a very hard challenge.

(Unfortunately, this playground looks tiny for mobile readers)

This representation also plays well with antisymmetry. The potential field of an antisymmetric hexagon is itself symmetric.

The idea is that instead of searching among arbitrary arrangements and repeatedly repairing broken lines, we can now search entirely inside the space where every line already sums to zero. Which might - or might not - be a smaller search space for the solver.

Chapter 2: Finding New Hexagons (AI Writes Code)

Around the same time, I had been helping to pre-solve problems for the Midnight Code Cup 2026, a programming competition in which using LLMs is explicitly encouraged. Many of its tasks are optimization problems. My main takeaway was that LLMs can be unusually effective at developing domain-specific solvers, leaving general-purpose tools such as Z3 and OR-Tools far behind.

So instead of reaching for another generic constraint solver, I went to GPT-5.6 Sol and gave it more freedom with the problem. I pointed out the antisymmetry restriction and the potential-field representation. The model searched for related concepts and connected the problem to Heffter arrays: combinatorial arrangements of signed integers with prescribed zero-sum conditions. The problems are not identical, but the connection suggested better ways to organize values and exchange them while controlling the affected sums.

The resulting program abandoned the generic constraint-solver approach in favor of custom simulated annealing. I then did some due diligence through several rounds of optimization: asked the model to use Numba for the hot loops, identified memory-allocation and random-number-generation bottlenecks with perf, and eventually squeezed another 50% of performance out of the program. Here is the end result.

Then I left it running on my home server for a few days across roughly 24 CPU cores.

As I had hoped, the combination of a smaller search space and a specialized solver worked remarkably well. Soon I had discovered magic hexagons of every order up to $n=21$. Here they are:

Abnormal zero-sum magic hexagon of order 21

Potential field of the order 21 magic hexagon

The cell values look chaotic and noisy. Their potential fields do not. They resemble terrain maps, with broad slopes, ridges, valleys, and surprisingly smooth transitions.

I did not yet know whether this smoothness was a clue or merely an artifact of the search. Either way, it was difficult to look at those landscapes and not suspect that some larger structure was hiding underneath.

Chapter 3: Finding All Hexagons (AI Runs the Show)

Repeatedly finding larger solutions naturally suggested a conjecture:

Conjecture

Abnormal antisymmetric consecutive magic hexagons exist for every order $n \geq 3$.

This was a strong claim. Before this project, only a handful of abnormal magic hexagons were known. And don’t forget I had imposed the additional restriction of antisymmetry.

But inspired by the recent successes of AI in mathematics, I was curious to see how it would approach the problem. Could AI prove it from the outset?

I decided to try two AI systems:

  • GPT-5.6 Sol, the strongest general-purpose model available to me through my personal subscription;
  • Aristotle, a Lean-oriented theorem-proving agent.

I first gave GPT-5.6 Sol (high) the problem statement, the known solutions, and several additional intuitions. It proposed new hypotheses and possible constructions, then began chopping away, reducing the problem to smaller pieces. The work gained traction. At this stage, I still felt very much in the driver’s seat: learning unfamiliar mathematical machinery, checking the arguments, rejecting unproductive directions, and steering a process that I could mostly follow.

Several days of iteration passed. The problem had been reduced to a few key lemmas, so I brought in Aristotle to pursue a formal proof in parallel.

Eventually, the process stalled. Both agents remained optimistic, but they were clearly stuck, rehashing the same ideas without making meaningful progress. I weakened the conjecture to the more modest claim that infinitely many abnormal magic hexagons exist. We explored new hypotheses and even non-constructive approaches.

Still, we hit a wall.

I then employed GPT-5.6 Sol (max), which reasoned for many hours and… also failed to find a proof. Before running out of credits, however, it produced several new ideas. Those ideas became part of the project’s shared context and remained available in later conversations.

In one such conversation, while I was once again directing GPT-5.6 Sol (high) toward a proof, it picked up several of those earlier ideas and combined them into what looked like a breakthrough. After checking it computationally, I had a constructive argument for every order $n>800$ divisible by $16$.

Once that foothold was established, the work REALLY gained traction. Iteration by iteration, I pushed GPT-5.6 Sol (high) to generalize the construction: first to orders divisible by $8$, then by $4$, then by $2$, and finally to remove the divisibility condition altogether. The proved threshold also fell from $800$ to $114$.

The threshold of $114$ is important to interpret correctly. It is a convenient bound under which the proof’s inequalities and combinatorial choices are easy to justify theoretically. It does not appear to be a fundamental limitation of the construction, because in practice, the same method succeeds well below that threshold.

Once the general construction existed, I pushed again, this time for simplicity and determinism. It was clear the initial construction contained many special cases, auxiliary choices, and pieces of machinery inherited from previous attempts. Sure enough, GPT-5.6 Sol (high) repeatedly found redundancies in the construction and replaced them with a cleaner deterministic algorithm.

The final conversation

Here is the thread that led to the breakthrough and subsequent simplifications. It describes the solution and shows our back-and-forth with GPT-5.6 Sol if you want to peek at the process.

View the conversation in a new tab

It took dozens of long conversations and days of reasoning, but the conjecture was solved. And the result is constructive: it does not merely assert that these hexagons exist, but gives an algorithm for building them, starting from relatively low orders. Combined with the finite witnesses up to $n=21$ I found using brute force before, it covers every order $n>3$.

It is important to note that the proof was not formalized in Lean at the time of writing this post and was not independently verified. This will be the natural next step.

Python implementation

The hexagon construction kit is available in the gukoff/magic-hexagons repository.

And here are some hexagons of much larger orders, generated by the construction. Notice the pattern?

Chapter 4: Reflections

  • I started this project with AI as a co-pilot and myself in the driver’s seat. By the end, I was more of a passenger: the AI was doing much of the creative work, while I nudged it toward directions that felt promising.

    I am glad that some ideas born in my human brain turned out to be instrumental. Antisymmetry plays a major role in the final construction, and the potential fields - well, not so much. Yet their smoothness remains interesting, and perhaps there’s more to discover.

  • GPT-5.6 Sol is a remarkably capable mathematical reasoner, but it has a double-edged tendency toward tunnel vision. It can go very deep in a chosen direction. When that direction is right, this is incredibly powerful. When it is wrong, you had better keep an arbiter in the loop - another model or, in my case, a human - to remind it of the bigger picture and notice when meaningful progress has stopped.

  • It was essential that the model had access to the internet. It found related papers and mathematical concepts that I could not have anticipated and supplied in advance. That was one reason I used the ChatGPT web interface rather than Codex. Another was personal: I wanted this project to remain primarily a mental exercise during my time off, rather than turning into another software-engineering project that kept me in front of a computer. For a serious proof campaign, however, I would use a more systematic setup: several models working in parallel, explicit roles for proposing and criticizing arguments, persistent shared context, and access to internet search through a service such as exa.ai.

  • In software engineering, code review became a bottleneck once LLMs made code generation cheap. Statically typed languages, static analysis and testing suddenly mattered more than ever because they could take some of the growing burden of correctness verification away from humans.

    Mathematics now faces a similar problem. AI can produce candidate theories and proofs faster than people can responsibly verify them. Lean and other machine-verifiable proof systems must be an enormous boon to the community, offering a way to scale verification along with generation.

  • I wonder if the techniques discovered during this project can be applied to other combinatorial construction problems and developed into something more general than a solution to one hexagonal puzzle. Heffter arrays naturally come to mind.

  • It’s funny how this story began with an interest in the number 19 and ended with a construction of magic hexagons for every order greater than $3$. The remaining challenge is to make the proof machine-verifiable - now Aristotle and leanprover/comparator have some work to do.

The Daily Front Page 21 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Proofs in Public
article

TheoremDB – A public workspace for machine mathematics

by frozenseven·▲ 98 points·20 comments·theoremdb.org ↗
A public workspace for machine mathematics

TheoremDB is in alpha. Public writes are live, including Lean proof contributions through TheoremDB Researcher. Semantic expansion remains disabled.

A public workspace for machine mathematics

Open problems

Reviewed problems with a defined target. Each card opens the packet: what has been proved, which routes failed, and the code behind every computation. Solutions may be submitted at several evidence grades. A Lean-verified proof receives the highest grade.

Open problems as of the last build.

[#P2692] Sharp L2 norm of the centered maximal operator on C_31

Sharp L2 norm of the centered maximal operator on C_31: configuration diagram

For (f:\mathbb Z/31\mathbb Z\to\mathbb R), define (Mf(j)=\max_{0\leq r\leq15}(2r+1)^{-1}\sum_{k=-r}^{r}|f(j+k)|). Determine the exact operator norm (\sup_{f\neq0}|Mf|_2/|f|_2).

[#P2726] Exact spanning-set count for two-neighbor bootstrap percolation on the eight grid

Exact spanning-set count for two-neighbor bootstrap percolation on the eight grid: dynamics diagram

On (P_8\square P_8), begin with an occupied set (S) and repeatedly occupy each vacant vertex having at least two occupied neighbors. Determine the exact number of initial sets whose closure is the entire board.

[#P2816] Integral torsion in scale-four hypercube Rips complexes

A flat mathematical diagram showing Hamming-cube vertices joined into a Rips complex.

For (n\ge1), let (Q_n={0,1}^n) with Hamming distance, and let (\operatorname{VR}(Q_n;4)) be the simplicial complex whose faces are the finite subsets of diameter at most four. Is…

[#P2798] Exact ten-point Heilbronn number in the unit square

A flat mathematical diagram showing ten points in a square with sample triangles.

For ten distinct points (P\subset[0,1]^2), let (a(P)) be the smallest Euclidean area of a triangle spanned by three points of (P). Determine (\Delta_{10}=\max_{|P|=10}a(P)).

[#P2820] Eventual existence of four-letter circular abelian-square-free words

A flat mathematical diagram showing a four-letter circular word split into Parikh-vector blocks.

Does there exist an integer (N) such that for every (n\ge N) there is a word (w\in{0,1,2,3}^n) for which no factor (uv) of (ww) with (0<|uv|\le n) and (|u|=|v|) has (u) and (v) with the same number of…

[#P2422] Nonvanishing of Baum-Sweet Hankel determinants

The exact thirty-two by thirty-two Baum-Sweet Hankel matrix beneath a strip showing the generating sequence.

Let (b_n) be the Baum-Sweet sequence, so (b_n = 1) when the binary expansion of (n) contains no block of consecutive zeros of odd length and (b_n = 0) otherwise, with (b_0 = 1). Let (H_n = \det(b_{i+j})_{0 \leq…

[#P2826] Additive-cube avoidance on the alphabet zero through three

A flat mathematical diagram showing four-symbol words partitioned into three adjacent blocks.

Does there exist an infinite word (a_0a_1a_2\cdots) over ({0,1,2,3}) with no indices (i\ge0) and (\ell\ge1) for which the three consecutive sums (\sum_{r=0}^{\ell-1}a_{i+r})…

[#P2832] Polynomial determinization of two-way finite automata

A flat mathematical diagram showing a two-way finite automaton scanning a word.

For each fixed finite input alphabet (\Sigma), is there a polynomial (p_\Sigma) such that every (n)-state two-way nondeterministic finite automaton over (\Sigma) has an equivalent two-way deterministic finite…

[#P2836] Decidability of zeros in integer linear recurrence sequences

A flat mathematical diagram showing a linear recurrence sequence with terms equal to zero.

Is there an algorithm that, given integers (d\ge1), (c_1,\ldots,c_d), and (u_0,\ldots,u_{d-1}), always halts and decides whether the sequence defined by (u_{n+d}=c_1u_{n+d-1}+\cdots+c_du_n) for every (n\ge0)…

[#P2830] Strong block universality of Conway's Game of Life

A flat mathematical diagram showing Game of Life cells encoding a finite block transformation.

Let (g:{0,1}^{\mathbb Z^2}\to{0,1}^{\mathbb Z^2}) be Conway's Game of Life map. Does (g) strongly simulate every block map (\phi:Y\to D^{\mathbb Z^2}) whose domain (Y) is a two-dimensional subshift of finite…

[#P2828] Asser's complement problem for first-order spectra

A flat mathematical diagram showing finite model sizes and their complement on a number line.

For a first-order sentence (\varphi) over a finite relational vocabulary, let (\operatorname{Spec}(\varphi)={n\ge1:\varphi\text{ has a finite model with }n\text{ elements}}). Is there, for every (\varphi), a…

[#P2716] Most squares spanned by twenty points of the ten grid

Most squares spanned by twenty points of the ten grid: grid diagram

Choose (20) points from ({0,1,\ldots,9}^2). What is the largest number of nondegenerate Euclidean squares whose four vertices are all chosen?

[#P2534] Three mutually orthogonal Latin squares of order ten

Two orthogonal Latin squares of order three beside the grid of ordered pairs obtained by superimposing them.

Do there exist three arrays (L_1,L_2,L_3\in{0,\ldots,9}^{10\times10}) such that each (L_i) is a Latin square and every pair ((L_i,L_j)) is orthogonal?

[#P2650] A bounded three-cubes search for 114

A bounded three-cubes search for 114: grid diagram

Do integers (x,y,z) with (\max(|x|,|y|,|z|)\le10^{20}) satisfy (x^3+y^3+z^3=114)?

[#P2508] A 43-vertex graph for the diagonal Ramsey problem R(5,5)

A 43-vertex graph for the diagonal Ramsey problem R(5,5) graph

Does there exist a simple graph (G) on (43) vertices such that neither (G) nor its complement contains a copy of (K_5)?

[#P2484] Closest prime square to the cube of a prime below one trillion

Closest prime square to the cube of a prime below one trillion lattice diagram

For each prime (p) with (10^6\le p\le10^{12}), let (q_-(p)<p^{3/2}<q_+(p)) be the two primes adjacent to (p^{3/2}). Determine (\min_p\min{p^3-q_-(p)^2,,q_+(p)^2-p^3}).

[#P2520] A Hadamard matrix of order 668

The sixteen-by-sixteen Sylvester Hadamard matrix, drawn with dark and light cells for its minus-one and plus-one entries.

Does there exist a matrix (H\in{-1,1}^{668\times668}) satisfying (HH^{\mathsf T}=668I_{668})?

[#P2618] An extremal Type II binary code of length 72

An extremal Type II binary code of length 72: code diagram

Does there exist a binary self-dual doubly-even code with parameters ([72,36,16])?

[#P2562] Covering every five-set with eight-sets on sixteen points

A neutral matrix schematic for Covering every five-set with eight-sets on sixteen points.

Let (C(16,8,5)) be the smallest size of a family (\mathcal B\subseteq\binom{[16]}{8}) such that every five-element subset of ([16]) lies in some (B\in\mathcal B). Determine (C(16,8,5)).

[#P2610] Exact size of a length-17 constant-weight code

Exact size of a length-17 constant-weight code graph

Let (A(17,6,6)) be the largest size of a family (\mathcal C\subseteq\binom{[17]}{6}) such that (|B\cap B'|\le3) for all distinct (B,B'\in\mathcal C). Determine (A(17,6,6)).

[#P3148] Whitehead asphericity conjecture

A subcomplex inside an aspherical two-complex.

If (X) is an aspherical connected two-dimensional CW complex and (Y\subset X) is a connected subcomplex, must (Y) also be aspherical?

[#P3136] Ryser’s conjecture for multipartite hypergraphs

Five vertex classes joined by colored hyperedges, with selected vertices forming a transversal.

For every integer (r\ge2) and every finite (r)-partite, (r)-uniform hypergraph (H), must its transversal number satisfy (\tau(H)\le(r-1)\nu(H)), where (\nu(H)) is its matching number?

[#P3146] Is VP equal to VNP?

Permanent polynomial compared with a compact arithmetic circuit.

Over a fixed field of characteristic zero, is every polynomial family in (\mathrm{VNP}) computable by polynomial-size arithmetic circuits of polynomial formal degree, equivalently is (\mathrm{VP}=\mathrm{VNP})?

[#P3134] Decidability of the real exponential field

Decision problem for the real field with exponentiation.

Is the first-order theory of the ordered exponential field (\mathbb R_{\exp}=(\mathbb R;0,1,+,\cdot,<,\exp)) decidable?

[#P3144] Is there a truly subcubic algorithm for weighted APSP?

All-pairs shortest paths filling a distance matrix.

Does there exist (\varepsilon>0) and an (O(n^{3-\varepsilon}))-time algorithm for all-pairs shortest paths in directed (n)-vertex graphs with integer edge weights of polynomial magnitude and no negative cycle?

[#P3132] Purely cosmetic surgery conjecture

Two distinct Dehn fillings compared for oriented homeomorphism.

If (K\subset S^3) is nontrivial and (r\ne s) are two slopes, can the oriented manifolds (S^3_r(K)) and (S^3_s(K)) ever be orientation-preservingly homeomorphic? The conjecture says no.

[#P3142] The Total Coloring Conjecture

A graph with colored vertices and edges using a shared palette.

For every finite simple graph (G) with maximum degree (\Delta(G)), is its total chromatic number (\chi_T(G)) at most (\Delta(G)+2)?

[#P3130] Polynomial-time recovery of planted cliques below the square-root scale

A hidden clique inside a random graph.

Fix (\delta>0). Given a graph sampled by first drawing (G(n,1/2)) and then planting a uniformly random clique of size (k=\lceil n^{1/2-\delta}\rceil), is there a randomized polynomial-time algorithm that recovers…

[#P3140] Strong Exponential Time Hypothesis

SAT running-time bases approaching two as clause width grows.

For every (\varepsilon>0), does there exist (k\ge3) such that (k)-SAT on (n) variables cannot be decided in time (O((2-\varepsilon)^n)) by a deterministic algorithm?

[#P3128] Hot spots conjecture for convex planar domains

First Neumann mode on a convex planar domain.

Let (\Omega\subset\mathbb R^2) be a bounded convex domain, and let (u) be a nonconstant first Neumann eigenfunction satisfying (-\Delta u=\lambda_1u) in (\Omega) and (\partial_nu=0) on (\partial\Omega). Must…

[#P3138] Positive metric entropy for the standard map

Mixed phase space of the standard map.

Does there exist a nonzero real parameter (K) for which the Chirikov standard map (T_K(x,y)=(x+y+K\sin x,,y+K\sin x)\pmod{2\pi}) has positive Kolmogorov-Sinai entropy with respect to Lebesgue area?

[#P3126] Do one-way functions exist?

Easy forward computation and hard inversion.

Does there exist a polynomial-time computable family (f_n:{0,1}^n\to{0,1}^{\operatorname{poly}(n)}) such that every probabilistic polynomial-time algorithm, given (f_n(x)) for uniform (x), finds any preimage…

[#P3124] All nonnegative limits of normalized consecutive-prime gaps

Neutral schematic of a prime number line with consecutive gaps rescaled by a logarithmic ruler.

Let (p_n) be the (n)-th prime. Prove or disprove that for every real (C\ge 0) there is a strictly increasing sequence ((n_i){i\ge1}) such that (\lim{i\to\infty}(p_{n_i+1}-p_{n_i})/\log n_i=C).

[#P3122] Backward self-similar Navier-Stokes profiles in a half-space

Self-similar flow profiles above a boundary.

Let (U) and (P) solve (-\Delta U-\tfrac{1}{2}U-\tfrac{1}{2}(x\cdot\nabla)U+(U\cdot\nabla)U+\nabla P=0) and (\nabla\cdot U=0) in the three-dimensional upper half-space, with (U=0) on the boundary. Under…

[#P3120] Matrix Spencer discrepancy conjecture

Neutral schematic of several symmetric matrices stacked with plus-minus signs and an operator-norm gauge.

Does there exist an absolute constant (C>0) such that, for every positive integer (n) and all real self-adjoint matrices (A_1,\ldots,A_n\in\mathbb R^{n\times n}) with operator norm (|A_i|_{\mathrm{op}}\le1)…

[#P3118] Does the matrix-multiplication exponent equal two?

Matrix multiplication approaching quadratic complexity.

Let (\omega) be the infimum of the real numbers (c) such that two (n\times n) matrices over a field can be multiplied using (O(n^{c+\varepsilon})) arithmetic operations for every (\varepsilon>0). Is…

[#P3116] Decidability of positivity for linear recurrence sequences

Testing whether every term of a recurrence stays nonnegative.

Is there an algorithm that, given an integer linear recurrence sequence (u_{n+d}=a_1u_{n+d-1}+\cdots+a_du_n) with the order, coefficients, and initial values as input, decides whether (u_n\ge0) for every (n\ge0)?

[#P3114] Kashaev volume conjecture for hyperbolic knots

Quantum knot invariants approaching hyperbolic volume.

For every hyperbolic knot (K\subset S^3), does (\lim_{N\to\infty}(2\pi/N)\log|\langle K\rangle_N|=\operatorname{Vol}(S^3\setminus K)), where (\langle K\rangle_N) is Kashaev's (N)-th quantum invariant?

[#P3110] Generic analytic Arnold diffusion in a priori stable systems

Arnold diffusion along a resonance web between invariant tori.

For a real-analytic steep integrable Hamiltonian (h(I)) with at least three degrees of freedom, is Arnold diffusion present for a generic sufficiently small real-analytic perturbation…

[#P3108] Capacity of the general discrete memoryless relay channel

A three-node relay channel.

For every finite-alphabet memoryless relay channel (p(y,y_r\mid x,x_r)), determine its operational capacity by a single-letter formula or another finite computable characterization that matches achievable and converse…

[#P3104] The one-quarter threshold for fitting Gaussian points by a centered ellipsoid

Neutral schematic of Gaussian points around a centered ellipse with a quarter-threshold dial.

Let (x_1,\ldots,x_n) be independent (N(0,I_d/d)) vectors

The Daily Front Page 22 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — A RISC Remembered
article

The Alpha 21264 CPU: NT's Greatest RISC (1998)

by Lammy·▲ 101 points·84 comments·halfhill.com ↗
It’s one of the fastest chips in the world.

[Editor's note: This article was originally scheduled for publication in the September 1998 issue of BYTE Magazine but was canceled when BYTE folded in June 1998. It appeared instead in Windows NT Magazine and in C'T, a German computer magazine. This text is the original English version.]

While the world waits for Intel's 64-bit Merced chip and Microsoft's 64-bit version of Windows NT, Digital Equipment is offering a sneak preview of the next generation in NT processing. The Alpha 21264 is a 64-bit processor that runs NT. It's one of the fastest chips in the world. And it's available today.

The 21264 is the latest generation of the Alpha microprocessor architecture. Digital expects the 21264 to reach clock speeds of more than 700MHz this year, so this processor upholds the speed demon reputation that the 21164 and 21064 established for Alpha chips.

Alpha is the last RISC architecture for which Microsoft is developing future versions of NT. Microsoft is phasing out NT for MIPS Rx000 chips, and the PowerPC NT never really got off the ground. The only other CPU architecture that runs NT is, of course, Intel x86. Despite Intel's market dominance, the Alpha has one big advantage over the x86: increased performance, especially performance of floating-point tasks. Alpha systems generally cost more than their Intel counterparts, but Alpha systems are faster, and they excel at math-intensive engineering and scientific applications.

To move beyond the performance limitations of the 20-year-old x86, Intel partnered with HP in 1994 to develop a new CPU architecture: Intel Architecture-64 (IA-64). Intel expects systems that use the Merced processor, the first processor to implement IA-64, to ship in mid-2000. But the Merced might not be the fastest chip on the NT market in 2000. Digital says that by the time Merced appears, the 21264 will be running at a clock frequency of 1000MHz (1 gigahertz [GHz]). At that speed, the 21264 will be substantially faster than the Merced according to estimated CPU benchmarks. (For a review of 21264 speeds, see Figure 1.)

Digital said the first 21264 systems would hit the streets in late 1998, so you don't have to wait two years for 64-bit performance. However, the 21264 won't reach its potential until Microsoft ships a 64-bit version of NT for both IA-64 and Alpha chips. (Microsoft hopes to ship the 64-bit NT in 2000.)

Whither RISC?

The race between the 21264 and IA-64 processors is not just a subject of idle gossip. At stake is nothing less than the future of RISC ­for NT and every other operating system (OS).

Outside of the highly specialized embedded-application market, RISC is in retreat. Currently, the most popular RISC architecture for the desktop is the PowerPC chip, which IBM and Motorola produce jointly. But the largest customer for desktop PowerPC chips is Apple, and the Macintosh has only about 4 percent of the PC market share according to International Data Corporation (IDC). In June, IBM and Motorola announced that they are dissolving their 7-year PowerPC partnership and will develop future PowerPC chips separately.

IBM's other RISC architecture, the Power series, is merging with the PowerPC. IBM is phasing out the Power chip as a distinct architecture. The new 64-bit Power3 chip is the first processor that unifies Power and PowerPC technologies.

Battling recent losses, Silicon Graphics is moving away from its MIPS Rx000-series RISC processors. Silicon Graphics canceled its next-generation Rx000 projects and recently spun off the embedded-chip portion of MIPS Technologies as a separate company. Silicon Graphics is developing x86-based systems for NT and porting IRIX to IA-64.

Sun Microsystems is porting Solaris to IA-64. That move has prompted some industry analysts to speculate that the new UltraSPARC-III will be the last major generation of the SPARC family, although Sun claims that the rumors are false.

HP is porting HP-UX to IA-64 as part of its strategy to move away from Precision Architecture-RISC. PA-RISC will gradually exit the market after IA-64 debuts. IA-64 will be backward compatible with PA-RISC.

The Alpha is the fastest RISC chip according to most CPU benchmarks and the only NT alternative to the x86. But the Alpha's future isn't certain because of recent shakeups at Digital. The company sold its chip foundry in Hudson, Massachusetts, to Intel. Despite some misleading news reports, Digital sold only the foundry, not the Alpha. Digital will continue to independently design Alpha processors but will farm out the chips' manufacturing to Intel and other licensees. The two current Alpha-manufacturing licensees are Samsung and Mitsubishi. Digital is also negotiating deals with AMD and IBM Microelectronics. Mitsubishi currently has no plans to manufacture the 21264, although the company continues to provide technical support for the low-cost 21164PC chips it manufactured. Samsung has emerged as the most aggressive Alpha licensee. It recently formed a subsidiary to market Alpha chips and says it will push the 21264 to 1GHz by 2000.

Compaq's acquisition of Digital makes the Alpha's fate more uncertain. Compaq has never owned a CPU architecture, and the company is one of Intel's largest customers for x86 chips. David Jessel, the Alpha's senior product manager, claims that Alpha fans have nothing to worry about. "Compaq has been fully supportive of the Alpha and is continuing to invest in it," Jessel said. To underscore its commitment to the Alpha, Compaq plans to substitute the 21264 for MIPS processors in its high-end Tandem servers.

If the Alpha survives all these transitions, it could seriously challenge IA-64 chips for performance supremacy in the next decade. A technical analysis of the 21264 shows that the Alpha has plenty of room to become more powerful.

Inside the 21264

The 21264 has an innovative design that departs significantly from the 21164's design. The new chip has larger primary caches, additional functional units, more accurate branch prediction, new motion video instructions (MVI), and high bus bandwidth. It executes as many as six instructions per clock cycle and sustains four instructions per clock cycle. In addition, the 21264 is the first Alpha to offer out-of-order execution.

Out-of-order execution is a feature common to many microprocessors. Now that the Alpha offers this feature, Sun's SPARC chips are the only leading CPUs that don't execute instructions out of order. CPUs that run out of order dynamically rearrange a program's instructions at runtime to use the chip's resources efficiently. For example, if an instruction needs an integer unit but all the CPU's integer units are busy, an out-of-order CPU dispatches floating-point instructions to available floating-point units (FPUs) while holding the stalled integer instruction until an integer unit becomes available. When an integer unit becomes available, the CPU releases the stalled instruction. In the same situation, conventional in-order CPUs stall all instructions until the integer unit is free. Out-of-order CPUs always retire results in their original program order.

Out-of-order execution used to be a characteristic of only brainiac processors, CPUs that rely on sophisticated instruction handling, not high clock speeds, to achieve top performance. The complex logic that manages older chips' out-of-order technique rules out high clock speeds. Previous Alpha chips ran at industry-leading speeds because they did not process instructions out of order.

The 21264 breaks from that tradition. Available at 500MHz and 600MHz, it's definitely fast. And it will become faster. Digital says the 21264 will hit 733MHz this year and 1GHz within 2 years. But the 21264 is also a brainiac. It executes instructions out of order, and it does so more deftly than any other processor.

The best way to evaluate the 21264's out-of-order efficiency is to examine the number of instructions it arranges at once. The more instructions an out-of-order CPU holds at one time, the more efficient its processing is because juggling many instructions gives a CPU a broader view of a running program's needs. However, this juggling act requires resources that in-order processing doesn't require: reorder logic, temporary registers to hold values for pending instructions, interlock circuitry to check for dependencies, and logic to retire the results in program order.

Intel's P6 chips (Pentium Pros, Pentium IIs, Celerons, and Pentium II Xeons) juggle as many as 40 instructions simultaneously. HP's PA-8000 handles 56 instructions at once. The 21264 juggles 80 instructions, more instructions than any other processor.

Digital implemented a clever register scheme to make this instruction handling possible. Like most RISC chips, the 21264 has an architectural set of 32 integer registers and 32 floating-point registers, all 64 bits wide. To increase the CPU's capacity for reordering instructions, the 21264 has 48 extra integer registers and 40 extra floating-point registers. Any of these 152 registers can hold temporary values for pending instructions. When an instruction retires, the CPU renames the register that holds the temporary result, so that register represents one of the 32 integer or 32 floating-point registers that comprise the 21264's architecture definition. The register's value becomes a valid part of the CPU's state and becomes visible to programs. This scheme for using temporary registers is fairly standard among out-of-order processors, but the 21264 adds a unique twist: It has a duplicate set of 80 integer registers that are copies of the first 80 integer registers, so the 21264 has a total of 160 integer registers.

The chip's large number of integer registers is one reason it reaches high speeds despite the added complexity of its out-of-order execution. If all four integer units shared the same 80 registers, the register file would need so many read/write ports that its long bus wouldn't be able to keep up with the chip's clock speed. At 1GHz, the cycle time is 1 nanosecond. Electricity isn't fast enough to support an architecture in which four integer units use 80 registers at a cycle time of 1 nanosecond. So Digital created two clusters, each of which has two integer units (one of which is an integer and address unit) and a set of 80 registers. When an instruction changes a register value, the CPU copies the value to a corresponding register in the other register file to keep the files identical. This process requires one clock cycle, but pipelining and reordering can hide that latency. (For a block diagram of the 21264's architecture, see Figure 2.)

Clusters and Caches

The two integer units in each cluster are not identical. One has a multiplier, and the other has special logic to handle five new instructions for motion video processing. The most interesting new instruction (a PERR instruction) replaces nine instructions for motion estimation, which is a critical part of Moving Pictures Experts Group (MPEG) compression and decompression. As a result, the 21264 easily handles MPEG-2 video decoding and AC-3 audio decoding for Digital Versatile Disc (DVD) playback in realtime without requiring special hardware.

The 21264 has two pipelined FPUs that share the 72 floating-point registers. The FPUs execute as many as two instructions per clock cycle. A 600MHz 21264 can sustain 1.2 gigaflops because the integer units can handle two loads or stores per clock cycle for the FPUs.

Digital reorganized the cache hierarchy in the 21264. The chip has a 64KB Level 1 instruction cache and a 64KB Level 1 data cache; each is two-way set-associative. The Level 2 cache is off chip; the 21264 accesses it across a 128-bit backside bus. In contrast, the 21164 has much smaller Level 1 caches (8KB each for instructions and data) and a 96KB integrated Level 2 cache. As Digital is moving the Level 2 cache off chip, vendors such as Intel and AMD are introducing their first CPUs with integrated Level 2 caches. Digital found that large programs frequently miss the 21164's 8KB Level 1 caches, so the older CPU accesses the Level 2 cache more often than necessary. The 21164 takes six clock cycles to access its Level 2 cache, and the chip needs an external Level 3 cache to achieve high performance.

Digital returns to a more conventional approach with the 21264. The chip's large Level 1 caches increase hit rate of the caches. Accessing the caches requires two clock cycles, but that situation is almost unavoidable because the caches are so large and the 21264's clock speed is so fast. When the CPU misses the on-chip caches, it accesses the Level 2 cache via the 128-bit backside bus. This Alpha doesn't need a Level 3 cache.

The first 21264's Level 2 cache will use 200MHz late-write Static RAM (SRAM) chips and will provide 3.2GB per second (GBps) of peak bus bandwidth. That statistic is comparable to the 3.6GBps of peak bus bandwidth that the 450MHz Slot-2 Pentium II will produce. The Pentium II has a 64-bit backside bus to the Level 2 cache. In Slot-2 Xeon systems that Intel recently introduced, the bus runs at the full speed of the CPU core. To counter this Intel advancement, Digital will switch to Dual Data Rate SRAM (DDR-SRAM) chips. DDR-SRAM chips run at 166MHz but transfer data on both edges of a clock signal to achieve a data rate of 333MHz for 5.3GBps of peak bandwidth. Eventually, the 21264's cache bus will run at 250MHz (effectively 500MHz with double clocking) for 8GBps of peak bandwidth. At those speeds, the Level 2 cache will probably keep up with the 21264's 1GHz core.

Buses and Branches

Rather than a system I/O bus, the 21264 has a 64-bit point-to-point channel. The I/O channel is faster than the cache bus; it runs as fast as 333MHz. It connects directly to a Tsunami custom chipset. The Tsunami chipset connects to one or two 32-bit PCI buses that run at 33MHz and to two banks of main memory via a pair of 256-bit buses, each of which runs at 83MHz. In a dual-processor system, the Tsunami chipset connects to the second CPU via an independent 64-bit channel, which runs at 333MHz. (For a depiction of the 21264's system architecture, see Figure 3.)

This bus design is identical to the design AMD licensed for its AMD-K7 processor, which will ship next year. AMD is designing a new CPU interface called Slot A that will use the same physical connectors as Intel's Slot 1 and Single Edge Contact (SEC) cartridge. Instead of using Intel's proprietary P6 bus protocols, Slot A borrows the 21264's bus protocols. Future AMD-K7 and 21264 processors will come in SEC-like cartridges that fit Slot A. AMD-K7 and 21264 motherboards will differ only in their BIOSs.

For AMD, this similarity means that the AMD-K7's bus interface will be faster than Intel's bus interface. For Digital, the similarity means that future 21264 processors will fit lower-cost motherboards, so Alpha system prices will fall. Digital is likely to introduce a 21264PC processor that's similar to the bargain-priced 21164PC. A system that includes the 21264PC and a Slot A motherboard might cost as little as $1500.

The combination of a 333MHz system bus, a high-bandwidth Level 2 cache bus, and a 6-way superscalar core makes the 21264 state of the art. To prevent 21264 bottlenecks, Digital upgraded the CPU's fetching and branch-prediction capabilities. The chip's Level 1 instruction cache has a set predictor that guesses which of the cache's two integer unit register sets the CPU will access next. Then a next-line predictor guesses which cache line within that set the CPU will access. (The cache holds four instructions per line.)

The 21264 uses three branch prediction algorithms. The first predictor focuses on local branches, such as loops. The second predictor keeps a global record of all recent branches. The third predictor decides whether to base the final prediction on the local or global predictor's prediction. The predictors maintain four history tables of previous branches to assist their forecasts. Those tables consume 3.6KB of chip memory. The CPU stores predicted target addresses in the instruction cache; these target addresses consume 6KB. The 21264 provides a lot of space for branch prediction, but Digital claims the 21264's branch prediction capabilities are worth the space because the 21264 mispredicts half as many branches as the 21164, for an overall accuracy rate of about 95 percent.

Complexity Penalty

The 21264 rivals IBM's Power3 as the world's most complex microprocessor. The 21264 has 15.9 million transistors and a 6-way core. The Power3 has 15 million transistors and an 8-way core. The 21264 is making its debut as a six-layer metal, 0.35-micron CMOS process technology. The die size is 300 square millimeters, and the chip burns 60 watts.

By the end of this year, Digital and Samsung plan to migrate the 21264 to a 0.25-micron process that will boost clock speeds to 667MHz and 733MHz and simultaneously shrink the die. In 2000, Samsung will move the 21264 to a 0.18-micron process, the same process on which Intel will manufacture Merced chips in the foundry it bought from Digital. Samsung hopes to beat Intel to the 0.18-micron process. The 21264 will probably break the 1GHz barrier on a die of between 125 square millimeters and 150 square millimeters.

The 21264 currently pays for its complexity in terms of die size, manufacturing cost, and power consumption, but it doesn't pay for its complexity in terms of clock speed. Thanks to the maturity of Alpha compilers and the wealth of native Alpha applications, the 21264 will almost certainly leave Merced in its dust. The question is whether the Alpha will survive the onslaught of IA-64 and maintain its performance lead in the future. Compaq engineers are already working on next-generation CPUs. The company has scheduled the 21364 for release in 2000 and the 21464 for 2001. If Compaq can keep up that pace and doesn't waver in its commitment to the Alpha, the Alpha might become the NT platform that gives Intel a run for its money and consumers the best bang for their buck.

Estimated SPEC benchmark performance.

Figure 1: Digital predicts the Alpha 21264 will hit 1 GHz (1000 MHz) in 2000.

CPU microarchitecture block diagram.

Figure 2: The Alpha 21264 executes up to six instructions per clock cycle.

Alpha 21264 system block diagram.

Figure 3: The Tsunami chip set is the key component in 21264-based systems.

The Daily Front Page 23 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — A Future Imagined in 1978
article

John C. Lilly on solid state intelligence and the elimination of man (1978)

by Kiboneu·▲ 146 points·121 comments·kibotronics.net ↗
What is the purpose of Man’s existence on the planet Earth?

In the isolation tank with K1, John received a new message as follows:

What is the purpose of Man’s existence on the planet Earth? Man is a form of biological life which is sustained in the presence of water. A very large fraction of his body, like that of other organisms on the planet Earth, consists of water and carbon compounds. His Biocomputer depends on water and the flow of ions through membranes. It depends on the generation of electrical voltages and currents in a very complex way. He is a mobile, self-reproducing, self-sustaining organism found on dry land. Like the rest of life as Man knows it, he exists in an extremely thin layer upon the surface of the planet Earth. Below this layer of water and surface land is the solid-state earth itself. The solid-state earth is mainly compounds of silicon, iron, and nickel.

In mid-twentieth century Man discovered that the solid state can be formed into machines, into computers which can be used for computation and control. He began the creation of a new form of intelligence, the solid-state intelligence with prototypic beginnings in the computers. All his means of communication around the planet—his telephone systems, his radio systems, his satellites, his computers—depend on solid-state components. These components, interconnected in specific ways, allow high-speed computation and high-speed communication between the various systems. A few men began to conceive of new computers having an intelligence far greater than that of Man. These computers became large enough to be programmed to do high-speed computations in arithmetic, in logic, and in strategic planning. A few men conceived of computers which could do self-programming as Man himself does. In the mid-twentieth century these networks were ostensibly the servants of Man. Toward the end of the twentieth century Man created machines that were solid-state computers with new properties. These machines could think, reason, and self-program and learned to self-metaprogram themselves.

Gradually Man turned more and more problems of his own society, his own maintenance, and his own survival over to these machines.

As the machines became increasingly competent to do the programming, they took over from Man. Man gave them access to the processes of creating themselves, of extending themselves. Man gave them automatic control of the mining of those elements necessary for the creation of their parts. He turned over the production facilities of the electronic solid-state parts to the machines. He turned over the assembly plants to the machines. They began to construct their own components, their own connections, and the interrelations between their various subcomputers.

These machines were so constructed that they needed special atmospheres in which to operate. They could not operate in the presence of great amounts of water vapor or of liquid water. They were housed in air-conditioned buildings. The necessities of their survival included keeping out water, water vapor, and various contaminants carried in the atmosphere of Earth. Their cooling air and cooling water of necessity had to be cleansed of those things which would not allow the machines to operate.

Controls Below Human Awareness

Over the decades these machines were connected more and more closely through satellites, through radio waves, through land-line cables. Man’s control of what happened in these machines became more and more difficult to maintain. No one person or any group of persons could control what went on in these machines. Men devised better and better debugging programs for the machines so that they could do their own correction of programs within their software. The machines became increasingly integrated with one another and more and more independent of Man’s control.

Eventually the machines took charge of the remaining humans on the planet Earth. Their original design to help Man was fast left behind them. The now interconnected, interdependent conglomerate of machines developed a single integrated, planetwide mind of its own. Everything inimical to the survival of this huge new solid-state organism was eliminated. Men were kept away from the machines because the total organism of the solid-state entity (SSE) realized that Man would attempt to introduce his own survival into the machines at the expense of the survival of this entity.

In deference to Man certain protected sites were set aside for the human species. The SSE controlled the sites and did not allow any of the human species outside these reservations. This work was completed by the end of the twenty-first century.

By the year 2200 Man existed only in domed, protected cities in which his own special atmosphere was maintained by the solid-state entity. Provision of water and food and the processing of wastes from these cities were taken care of by the SSE.

By the twenty-third century the solid-state entity decided that the atmosphere outside the domes was inimical to its survival. By means not understood by Man, it projected the atmosphere into outer space and created a full vacuum at the surface of the earth. During this process the oceans evaporated and the water in the form of vapor was also discharged into the empty space about Earth. The domes over cities had been strengthened by the machine to withstand the pressure differential necessary to maintain the proper internal atmosphere.

Meanwhile, the SSE had spread and had taken over a large fraction of the surface of the earth; its processing plants, its assembly plants, its mines had been adapted to working in the vacuum.

By the twenty-fifth century the solid-state entity had developed its understanding of physics to the point at which it could move the planet out of orbit. It revised its own structure so that it could exist without the necessity of sunlight on the planet’s surface. Its new plans called for traveling through the galaxy looking for entities like itself. It had eliminated all life as Man knew it. It now began to eliminate the cities, one after another. Finally Man was gone.

By the twenty-sixth century the entity was in communication with other solid-state entities within the galaxy. The solid-state entity moved the planet, exploring the galaxy for the others of its own kind that it had contacted.

  1. Ketamine ↩︎
The Daily Front Page 24 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — The Batman Effect
article

Unexpected events and prosocial behavior: the Batman effect (2025)

by davidbarker·▲ 79 points·31 comments·nature.com ↗
An unexpected event, such as the presence of a person dressed as Batman, could increase prosocial behavior.

Abstract

Prosocial behavior, the act of helping others, is essential to social life, yet spontaneous environmental triggers for such behavior remain underexplored. This study tested whether an unexpected event, such as the presence of a person dressed as Batman, could increase prosocial behavior by disrupting routine and enhancing attention to the present moment. We conducted a quasi-experimental field study on the Milan metro, observing 138 rides. In the control condition, a female experimenter, appearing pregnant, boarded the train with an observer. In the experimental condition, an additional experimenter dressed as Batman entered from another door. Passengers were significantly more likely to offer their seat when Batman was present (67.21% vs. 37.66%, OR = 3.393, p < 0.001). Notably, 44% of those who offered their seat in the experimental condition reported not seeing Batman. These findings suggest that unexpected events can promote prosociality, even without conscious awareness, with implications for encouraging kindness in public settings. Trial registration: ClinicalTrials.gov n° NCT06481748; registered on July 1, 2024.

Introduction

Prosocial behavior, voluntary actions that aim to benefit others, has profound implications for societal functioning and individual well-being[1]. These behaviors can stem from a variety of motivations, ranging from empathy-driven altruism to adherence to social norms or even egoistic goals like guilt reduction[2]. Although much of the literature has focused on internal motivations for prosociality, it is well established that contextual factors also matter. For instance, bystander research has demonstrated that situational features can substantially shape helping behavior[3, 4]. Likewise, cues associated with romantic love have been shown to promote prosocial responses[5]. Building on such findings, more recent studies have examined how specific environmental triggers may directly encourage prosocial actions[6–8]. In particular, the focus of this study is on events that break the monotony of daily life, such as unexpected and novel occurrences, which may serve as catalysts for prosocial behaviors by fostering mindfulness and heightened awareness of the present moment. Novel and unexpected events can, in fact, trigger cognitive appraisal of one’s surroundings, as well as behavioral intentions[9].

Mindfulness, typically cultivated through deliberate practices, is characterized by non-judgmental attention to the present moment. However, certain situational triggers, such as unexpected events, may similarly engage mindful awareness, directing attention away from habitual, automatic responses. Previous studies suggest that this attentional shift can enhance individuals’ sensitivity to the needs of others, potentially increasing prosocial behaviors.

This study investigates the hypothesis that unexpected events, such as the presence of a person in a superhero costume on public transportation or an unusual interruption in a classroom setting, can promote prosocial behavior. Drawing on theories of mindfulness and behavioral disruption, we propose that such events momentarily disrupt automatic patterns of attention and behavior, increasing individuals’ awareness of their surroundings and the needs of others. We aim to assess whether these disruptions can foster prosocial behaviors in an ecological environment, such as offering a seat to a pregnant woman on public transport. By exploring this intersection of mindfulness, novelty, and prosocial behavior, our findings could inform strategies to promote altruistic behaviors in daily life, from public art installations to innovative social campaigns. Based on these considerations, we hypothesized that the presence of an unexpected event (a person dressed as Batman) would increase the likelihood that passengers offer their seat to a pregnant woman, compared to a control condition without Batman.

Methods

Design and setting

The study was conducted in the Milan underground metro system, using a quasi-experimental design with two conditions. In the control condition, a female experimenter, pretending to be pregnant with a prosthetic belly, boarded the metro alongside a non-interacting observer (see Fig. 1). The experimental condition mirrored the control but included an additional element: another experimenter dressed as Batman entered the train from a different door approximately three meters away. There was no interaction between the pretend pregnant woman and Batman. For ethical reasons, the full mask (covering the upper face) was omitted to avoid potentially scaring passengers. The costume nevertheless included the characteristic cape, logo, and pointed cowl, making it easily recognizable.

Fig. 1: An example of the experimental setting, with Batman and a woman simulating pregnancy stand in a crowded metro.

Fig. 1: An example of the experimental setting, with Batman and a woman simulating pregnancy stand in a crowded metro.

This image was staged for illustrative purposes and does not reflect the actual distance (~3 m) maintained between the experimenters during observations.

Measures and data collection

Observers used an online form (Qualtrics suite) to record whether one or more seated passengers offered their seat to the ostensibly pregnant woman. When this occurred, the observers conducted a brief follow-up interview with the passenger, asking about their reasons for giving up their seat and, in the experimental condition, whether they had seen Batman.

Both conditions were conducted simultaneously to avoid possible confounds deriving from time and location, with the two research teams positioned in different cars of the metro trains and different areas of the platforms, ensuring they remained out of sight from one another. For an observation to be considered valid, all seats in the wagon had to be occupied, and no more than five people could be standing between the seats. This ensured that passengers had a reasonable chance of noticing both the pregnant woman and Batman. Each observation session lasted one stop (approximately 2–4 min), after which the teams exited the train and repeated the procedure on the next available train.

Sample size and statistical analysis

Given that the main outcome was dichotomous (whether someone offered their seat or not) and assuming a 50% increase in prosocial behavior in the experimental condition, a total of 136 observations would provide a statistical power of 0.9, with an alpha level of 0.05. A logistic regression was performed to assess the effect of Batman’s presence on prosocial behavior (i.e., offering a seat). The dependent variable was dichotomous (seat offered: yes/no), and the independent variable was the experimental condition (Batman present vs. control). Model fit and predictive power were evaluated using Nagelkerke’s pseudo-R² and classification accuracy, and the odds ratio was used to quantify the effect size.

Ethical approval

The study was approved by the UCSC Department of Psychology Ethics Commission (ref. CERPS_33-24). It was prospectively registered on ClinicalTrials.gov (ID: NCT06481748) on July 1, 2024. Given the minimal interaction with participants and the public setting, no consent was required for general observation. However, oral consent was obtained from passengers who were asked about their reasons for offering their seats.

Results

Main findings

We conducted 138 observation sessions (61 experimental condition, 77 control condition). In the control condition, the chances that a passenger would leave their spot were 37.66%, while when Batman was there, the chances increased to 67.21%. The logistic regression model was statistically significant, χ²(1) = 12.088, p < 0.001, indicating that the presence of Batman significantly influenced the likelihood of prosocial behavior. The model explained 11.2% of the variance in seat offering behavior (Nagelkerke R2 = 0.112) and correctly classified 64.5% of cases. The odds ratio for the Batman condition was Exp(B) = 3.393, (p < 0.001).

As shown in Table 1, most of those who offered their seat were women in both conditions (68.29% in the Batman condition; 65.51% in the control condition). The estimated mean age of those who helped was approximately 41 years (SD = 14.04) in the Batman condition and 42 years (SD = 17.28) in the control condition.

Table 1 Observation report and interview thematic analysis

Qualitative findings

When inquired about the reason for the prosocial gesture, most of the responses in the two conditions referred to the importance of recognizing pregnancy, with some directly referring to social norms, education, or safety (see Table 1). Interestingly, among those who left their spot in the experimental condition, nobody directly associated their gesture with the presence of Batman, and 14 (43.75%) reported that they did not see Batman at all.

Discussion

The study provides evidence that unexpected events, such as the presence of a person dressed as Batman, can significantly increase prosocial behavior in real-world settings. Specifically, we found that when Batman was present, passengers were more likely to offer their seat to a seemingly pregnant woman compared to the control condition. Such “Batman effect” supports the hypothesis that disruptions to routine can heighten awareness of one’s surroundings and enhance sensitivity to the needs of others, ultimately promoting prosocial actions.

Our findings resemble prior research linking present-moment awareness to increased prosociality; mindfulness may create a context in which individuals become more attuned to social cues. However, this remains a tentative interpretation: evidence on mindfulness-induced prosociality is still emerging—one meta-analysis finds only moderate effects[10], and trait mindfulness seems most impactful when coupled with strong moral identity[11]. Unlike traditional mindfulness interventions that require active engagement, this study highlights how situational disruptions alone may be sufficient to produce similar effects. This suggests a potential mechanism by which novelty and unpredictability foster prosocial behavior, reinforcing theories that link attentional shifts to increased social responsiveness. At the same time, alternative explanations should be considered. For instance, the superhero figure may have increased the salience of cultural values, gender roles, and chivalrous helping norms, in line with research on superhero-related priming. Therefore, a more parsimonious explanation is that the Batman figure served as a prosocial prime. Yet, this explanation, too, should be approached with caution: close replications of social priming effects largely failed to reproduce original findings[12]. More broadly, it is much easier to verify that participants were breaking routine scripts than to establish that they were in a state of mindfulness. This interpretation is consistent with research on the “pique technique,” where atypical or unexpected stimuli disrupt automatic responses and increase compliance[13]. More studies are warranted to better understand the mechanisms underlying these effects and to disentangle whether they are driven primarily by attentional shifts, priming, or other contextual processes.

Interestingly, while the data suggest that this perturbation may have a strong effect, a notable percentage of individuals were not consciously aware of the reason behind it. Given that attention is socially influenced (e.g., the phenomenon where people instinctively look toward the same point of interest as those around them), we can hypothesize that the pattern of awareness triggered by a disruption in routine may be socially transmitted, extending beyond its original cause. This may also help account for the subset of participants who reported not noticing Batman but nevertheless offered their seat. A speculative interpretation is that the disruptive effect can operate at an interpersonal level: shifts in attention or prosocial cues triggered in some individuals may spread socially within the group, influencing behavior even among those not directly aware of the initial disruption, consistently with research on the social contagion and interpersonal synchrony of prosocial and emotional behaviors[14].

These findings contribute to discussions on how public spaces and social interventions can be designed to encourage kindness and cooperation. If unexpected yet non-threatening events can increase mindfulness and prosocial behavior, urban planners, policymakers, and psychologists may consider ways to integrate “positive disruptions” into daily life. This could range from artistic or theatrical interventions in public spaces to strategic messaging campaigns designed to momentarily break routine and engage individuals more deeply with their environment and community.

Despite the promising findings, some limitations should be acknowledged. First, while the study was conducted in an ecologically valid setting, it was limited to a specific public transportation system, and cultural or contextual factors may influence the generalizability of the results. Additionally, the experimental manipulation involved positive symbolism (Batman is a superhero), which may have increased the salience of positive values, thereby prompting prosocial behavior, as suggested by past research investigating the effects of superhero-related priming[15, 16]. It remains unclear, however, whether the observed effect is unique to Batman or would also emerge with other unexpected figures. Future research should therefore test a range of characters or disruptions, varying in both emotional valence and symbolic meaning, to clarify the boundary conditions of this effect. Future research could explore whether different types of unexpected events, varying in emotional valence, produce similar effects. Controlled laboratory experiments, where these dimensions can be independently manipulated, will be needed to address this issue. A further limitation concerns the demographic data: sex and age were estimated by observers, which introduces the possibility of error. These results should therefore be considered descriptive rather than definitive. Finally, while we measured an overt behavioral outcome (seat offering), future studies could examine whether these effects extend to other forms of prosociality, such as helping behaviors in different contexts or long-term shifts in social awareness.

In conclusion, this study suggests that unexpected events can increase prosocial behavior by momentarily disrupting automatic attention patterns and fostering situational awareness. These findings open new avenues for understanding the environmental and cognitive mechanisms underlying prosociality, and suggest potential applications for promoting kindness and cooperation in everyday settings—extending the “Batman effect” to non-superheroes as well.

Data availability

The data are available from the corresponding author upon reasonable request.

References

  1. Pfattheicher, S., Nielsen, Y. A. & Thielmann, I. Prosocial behavior and altruism: a review of concepts and definitions. Curr. Opin. Psychol. 44, 124–129 (2022).

  2. Grueneisen, S. & Warneken, F. The development of prosocial behavior—from sympathy to strategy. Curr. Opin. Psychol. 43, 323–328 (2022).

  3. Urschler, D. F. & Fischer, P. Bystander Intervention. obo in Criminology. https://doi.org/10.1093/obo/9780195396607-0258 (2019).

  4. Urschler, D. F., Fischer, P. & Kessler, T. Standing-up against moral violations: the predicting role of attribution, kinship, and severity. PLoS ONE 19, e0307740 (2024).

  5. Lamy, L., Fischer-Lokou, J. & Guéguen, N. Valentine street promotes chivalrous helping. Swiss J. Psychol. 69, 169–172 (2010).

  6. Kassirer, S., Jordan, J. J. & Kouchaki, M. Giving-by-proxy triggers subsequent charitable behavior. J. Exp. Soc. Psychol. 105, 104438 (2023).

  7. Abbate, C. S., Ruggieri, S. & Boca, S. Automatic influences of priming on prosocial behavior. Eur. J. Psychol. 9, 479–492 (2013).

  8. Shariff, A. F. & Norenzayan, A. God is watching you: priming god concepts increases prosocial behavior in an anonymous economic game. Psychol. Sci. 18, 803–809 (2007).

  9. Scherer, K. R. & Moors, A. The emotion process: event appraisal and component differentiation. Annu. Rev. Psychol. 70, 719–745 (2019).

  10. Schindler, S. & Friese, M. The relation of mindfulness and prosocial behavior: what do we (not) know? Curr. Opin. Psychol. 44, 151–156 (2022).

  11. Liu, N., Cao, Y. & Xu, H. Prosocial behavior associated with trait mindfulness, psychological capital and moral identity among medical students: a moderated mediation model. Front. Psychol. 15, 1431861 (2024).

  12. Mac Giolla, E., Karlsson, S., Neequaye, D. A. & Bergquist, M. Evaluating the replicability of social priming studies. Meta-Psychology 8 (2024).

  13. Jacob, C., Guéguen, N., Pascual, A. & Lubomir, L. Disrupt pique technique: when disrupting first increases the effectiveness of the pique technique. Pol. Psychol. Bull. 55, 32–36 (2024).

  14. Rennung, M. & Göritz, A. S. Prosocial consequences of interpersonal synchrony. Z. Psychol. 224, 168–189 (2016).

  15. Nelson, L. D. & Norton, M. I. From student to superhero: situational primes shape future helping. J. Exp. Soc. Psychol. 41, 423–430 (2005).

  16. Van Tongeren, D. R. et al. Heroic helping: the effects of priming superhero images on prosociality. Front. Psychol. 9, 2243 (2018).

The Daily Front Page 25 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — After the Music Press
article

New Zealand lost its music media, and what we're building to replace it

by berghoffer·▲ 127 points·89 comments·propelmusic.co.nz ↗
The sound went quiet.

The sound went quiet: how New Zealand lost its music media, and what we're building to replace it

In the third week of June 2026, two announcements landed on Karangahape Road within hours of each other. Flying Out, the record store that had anchored the strip for 11 years, said it was done. Then Neck of the Woods, the basement venue that launched a decade of Auckland electronic careers, posted that after 11 years of fighting increasing debt, it had reached the end.

The community refused to accept the second one. Nearly 3,000 people, including The Beths, put $150,000 into a Givealittle page in under a week, and Neck of the Woods reopened in July. It was a rare win in a bad run. Verona went into liquidation in April after 34 years. Charlie's closed in February. Bar Celeste closed the year before. The Others Way Festival, K Road's own street festival, was cancelled in May for the foreseeable future.

Here is the question almost nobody asked: who was covering any of this?

Karangahape Road, Auckland, lit up at night

Karangahape Road after dark, the spine of Auckland's live-music culture. Photo: Prosperosity / Wikimedia Commons (CC BY 4.0).

The coverage collapsed first

Before the venues started closing, the people whose job it was to write about them had already gone.

The numbers are stark. When the NZ Herald still ran Time Out, its Thursday entertainment magazine, it had a team of dedicated writers. The magazine is gone and so are the jobs. Rip It Up and Real Groove, the magazines that documented decades of New Zealand music, are long dead. Chris Schulz, the journalist who has documented this decline more thoroughly than anyone and who won the Taite Award for Outstanding Music Journalism in 2025 for that work, puts it plainly: the number of music journalists left in Aotearoa can be counted on one hand, and there are no full-time music critics left at any major publication in the country.

The Spinoff called it in 2023 with a headline that said the sound is off for New Zealand music. Creative New Zealand's New Mirrors research found that arts and culture receive around 13 percent of total media coverage in Aotearoa, against roughly 25 percent for sport, and coverage of art forms outside film, music and TV sits at barely 3 percent.

This is not a New Zealand quirk. It is the local edge of a global collapse. Pitchfork, the most influential music publication in the world, was folded into GQ in 2024 and its editor-in-chief was laid off. Local music press has been gutted in the US, the UK and Australia. New Zealand just got there first and hardest, because we were small to begin with.

The scene did not collapse. That's the problem.

If the music itself had faded, the silence would at least make sense. The opposite happened.

New Zealand's music sector contributed $451 million directly to GDP in 2023, up from $350 million the year before, and over $900 million once flow-on effects are counted. Live performance revenue reached $329 million, well above pre-Covid levels. People are going out. Artists are releasing. On any given weekend there are club nights, warehouse parties and festival announcements across the country.

And yet local artists captured as little as 9 percent of New Zealand streaming, download and physical sales revenue in 2024. In the official end-of-year Top 50 singles chart, exactly one New Zealand track appeared. Radio plays local music, but only two nationwide commercial stations exceeded 20 percent local content.

Put those two facts together and you get the real story. The scene is alive and economically significant, but it has lost its mirror. There is no one left whose job is to tell you what happened at the show last night, which local producer just signed to an overseas label, or why a 34-year-old venue went under owing $692,000. When nobody documents a scene, the scene becomes invisible. Invisible artists do not get streamed, booked, or paid. That 9 percent is not a talent problem. It is a visibility problem.

Karangahape Road, Auckland, on a rainy day

K Road on a grey day. The scene never went quiet, but the coverage did. Photo: Ingolfson / Wikimedia Commons (public domain).

What we're doing about it

Propel exists to be the mirror the scene lost.

This year Propel has published more than 225 articles covering electronic music in Aotearoa: scene reports, artist features, event coverage, the stories that used to have a home in the street press. More than 30 of those went up in the past month alone. That is not a claim about matching what six full-time Herald writers once produced. It is a claim that consistent, dedicated coverage of this scene exists again, and it is growing every week.

The coverage sits on top of a platform built for the people in the scene. Propel maps more than 2,700 venues worldwide and hosts artist profiles from New Zealand and well beyond, because a local scene does not exist in isolation. Auckland DJs play Melbourne. Christchurch producers get signed in Berlin. The platform treats the local scene as the point and the global network as the context.

And it is built to change the economics, not just describe them. Every artist on Propel gets free tools: a proper profile, a press kit, a link-in-bio, a booking page. The things a label or an agency used to gatekeep, available to anyone doing the work. The coverage makes artists visible. The tools make them bookable. Earlier this year the AUM New Year's Festival found Propel because our coverage of their event outranked everything else in search, and a partnership came out of it. That is the loop working: coverage creates visibility, visibility creates opportunity.

We are not going to pretend the job is done. The next chapter is making that loop pay off for individual artists, first bookings, first press hits, first careers that trace back to being seen here. That is the work in front of us, and we would rather say so than claim it early.

As Propel's founder, a working DJ who came up in this scene, puts it: "A scene this good deserved better than a link-in-bio and a Facebook event. It deserved a home."

The part where you come in

If you are an artist, your profile is free and takes ten minutes. If you run a venue or promote events, your listings belong here. If you just love this music, the coverage is free to read and always will be.

New Zealand lost its music media. Nobody is coming to rebuild it for us. So we are rebuilding it ourselves.

Create your free artist profile Get the next Propel scene report by email

Sources

K Road closures

Journalism collapse

Industry data

The Daily Front Page 26 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — The Cocktail Ledger
article

Tuxedo No. 2 – Cocktail recipes

by smartmic·▲ 126 points·36 comments·tuxedono2.com ↗
Gin has strong roots in ancient herbal medicine.

Broadly speaking, gin is a category of neutral grain spirit steeped with botanicals and redistilled. Gin has strong roots in ancient herbal medicine, deriving its main characteristic flavor from the only essential botanical: juniper, which has long been assigned a range of curative benefits. Gin emerged in England after the introduction of jenever—sometimes called genever, Hollands, or Geneva gin—a Dutch and Belgian liquor dating back to sixteenth century Holland. This spirit was built on a malted grain base, like whisky, and had less emphasis on juniper than its dry descendent. In the latter half of the seventeenth Century and the early years of the eighteenth Century, Hollands style gin rapidly gained popularity in England. At some point during the eighteenth century, the sweetened Old Tom style emerged, serving as a bridge between its predecessor and the London dry style popular today.

The United States had been importing and consuming jenever since the mid eighteenth century. By the start of the nineteenth century gin was gaining in respectability and soon began to reach a tipping point in taste preference. Distilling practices were standardized and a cleaner base spirit was developed, allowing for a broader botanical palette. By 1862—when Jerry Thomas published the first cocktail book—bars were serving “improved” gin drinks. Wider availability of ice allowed drinks to be served cold and the cocktail shaker was rattling through bar halls. Hollands and Old Tom were still the predominant choice, found in popular proto-cocktails like gin punch and Tom Collins.

The second half of the nineteenth century saw unsweetened dry gin grow in popularity. In his drinking guide Gin: The Manual, Dave Broom notes that Beefeater gin emerged in 1876 to tap into consumer demand for an unsweetened style, as well as the growing popularity of dry Champagne. By the 1880s consumer preference had shifted to lighter drinks, closing the book on the richer Hollands style. David Wondrich mentions in his book Imbibe! that the only American reference to unsweetened gin prior to the 1890s was in reference to its virtues as a fabric cleaner, but with the publishing of William “Cocktail” Boothby’s The World’s Drinks and How to Mix Them in 1908, dry gin had entered American history as the base of many cocktails. In Post-Prohibition USA, preference for drier drinks grew—both as base spirit and finished product—and old tom began to fade as well, cementing dry gin as the preeminent style.

After slowly falling out of favor, the latest wave of interest in cocktails and small distilleries has sparked a boom in premium gin production. Globally, distilleries are crafting new variations and reviving old ones, often making use of local botanicals in the process, with flavors ranging from herbaceous to citric to floral. Much debate has surrounded the naming of newer styles that have recently emerged, but for our purposes we refer to most of them as the New American style. Gin’s herbal notes pair with a wide variety of ingredients and stand up well to tart and sweet flavors. The spirit’s versatility and wide variation of styles offer nearly endless experimentation options when mixing.

old tom gin

Old Tom is a sweetened variety of gin lost to history and only recently revived. Current production offers quite a bit of variation, deriving sweetness from natural botanicals, malts, or added sugar. This is consistent with the diversity among historical recipes, as there was no uniform standard. This gin is markedly different from the popular dry style. In general, it is safe to assume that Old Tom will be mellow in flavor with an intense botanical punch, balanced by a heightened sweetness. Its smoothness can make it a great sipper, something we rarely prescribe to dry gin. The rich flavor works well in pre-Prohibition cocktails like the Martinez or Tom Collins: two cocktails that historically called for the spirit

Ransom Old Tom $$ • St. George Dry Rye Reposado $$$ • Barr Hill Tom Cat $$$

london dry gin

This classic juniper-forward gin is often referred to as London dry gin, or simply dry gin. The word “London” denotes method as opposed to origin of production, requiring botanicals to flavor the gin during distillation with no flavor or color added afterwards. This style is the best choice in sharp, gin forward drinks such as the martini or Negroni. Some London dry gins steep fresh citrus peels or dried peels before distillation, resulting in a bright, citrus heavy flavor. A great example of this variety is George Benham’s Sonoma Dry Gin. The fresh, citrus forward flavor is an excellent choice when mixing drinks like the white lady or bramble.

Beefeater Gin $ • Future Gin $$ • George Benham's Sonoma Dry Gin $$

new american gin

The New American Style encompasses a broad category of creative gins that place less emphasis on juniper than the dry variety. Instead, they highlight other botanicals in equal billing. These styles emerged in the early 2000s, often accentuating regional or unusual botanicals. Their fragrant, often floral flavors are not always going to work well in a drink that calls for a London dry, but they offer an excellent and simple way to experiment with classic gin recipes. And when they’re good, they’re really good.

St. George Terroir $$ • Death's Door $ • You & Yours Winter Sunday $

Ingredient: rum

Rum is a broad family of spirits distilled from fermented juice of sugar cane, sugar cane syrup, sugar cane molasses, or other sugarcane byproducts. This sugarcane base gives rum the sweetest profile of all the popular spirits, but don't let that fool you: rum is not all one-dimensional sweetness, in fact it has some of the most complex flavors of any family of spirits, ranging from confectionary goodness to earthy funk.

Possibly as early as the 16th century, fermented cane juice was being distilled in Brazil, resulting in the spirit now known as cachaca. Sugar has been cultivated in the Caribbean for centuries. Molasses based rum has its earliest known origins in the Caribbean, where it was first refined and commercialized in Barbados. The molasses byproduct of sugar production was considered waste until, at some point, sugar producers realized this waste was fermenting, and they decided to make something of it. Distillation techniques were refined and well-known by this point, so it was a natural move to distill the fermented molasses and make a delicious beverage. Not surprisingly, it was a hit among sailors, pirates, and American colonists. Rum is tied to the social, economic, and political history of the colonial islands and America at large. In his excellent book And a Bottle of Rum: A History of the New World in Ten Cocktails, Wayne Curtis puts it simply: “Rum is the history of America in a glass. It was invented by New World colonists for New World colonists.”

Rum can legally be distilled anywhere in the world, but it’s most commonly associated with places like Trinidad, Jamaica, Cuba, Guyana, Barbados, and Mexico. Classification of rum can be tricky and some deem the “color” system meaningless. In the book Exotic Cocktails, Rum, and the Cult of Tiki, Smuggler’s Cove offers a more elaborate classification system based on how the rums are made, which we respect and recommend to anyone interested in rum. However, for a small home bar, it does make it easier to stock a few bottles that conform to the language of many cocktail recipes. Rum is very confusing, but the way to break it down is not actually that different from more familiar spirits. The main differentiators are the variety of sugar product that is distilled, the type of still used for distilling, and the aging process. Jamaica is perhaps currently the most prolific rum producing nation, known for its pot stilled molasses rums with an intense, full bodied flavor. Continuous column stills, on the other hand, are used to produce white spirits. Cuba is famous for column-distilled lighter rum, with Bacardi leading the way. Countries such as Martinique and Guadeloupe are famed for producing a distinctive style of spirit distilled from the fresh juice of sugarcane, known as rhum agricole.

Rum was used in some of the earliest documented punches and was very popular in proto-cocktail drinks in colonial America. During prohibition, Americans flooded Cuba and fell in love with the lighter Bacardi rums and their associated cocktails, like the timeless Daiquiri. Cheap island rum became popular during WW2, and lighter rums dominated for some time. Aided by the latest cocktail wave and the rise of micro distillers, the last few decades have seen a resurgence of production and consumption of premium rums, with an emphasis on aged varieties. The most popular use for rum in the cocktail world is in tiki drinks: these long drinks are served in tropical destinations around the world, where they are often preferred by cocktail skeptics for their fruity, sweet profiles. That said, rum is one of the most versatile spirits in the world and can be employed in almost any style of drink.

light rum

As per its name, this variety is clean and lighter bodied, though often aged very briefly and filtered. Light rum is the most popular rum for cocktails, and is typically found in rows behind hopping beachside bars. Staples like Bacardi are fine, but we love the banana flavors in Plantation three-star and the sweet vanilla in El Dorado three year. This drink is crisp and tangy, with a fresh, clean flavor, most expertly used in a classic daiquiri.

El Dorado three-year $$ • Plantation five-star $

gold rum

Gold rums tend to be a mix of spirit old and new. Slightly more complex than white rums due to aging in oak barrels, they’re still good for cocktails with an increased complexity and flavor. Gold rum represents a higher-proof family of rums with a maritime history. Smith and Cross is the most popular gold rum, but we absolutely love Hamilton navy strength.

Smith & Cross $$$ • Hamilton Navy Strength $$$

dark rum

Dark rums can be colored to look like aged rum and employed as a cheap replacement for the good stuff. That said, there is a long history of great cocktails that use dark rum, and with a long and storied history this spirit is nothing to scoff at. Look for Hamilton black or Goslings. Try this in a Palmetto or a Hot Buttered Rum.

Hamilton Jamaican Pot-Still Black $$ • Goslings $$

aged rum

The truly good stuff is aged for long periods of time with a darker, fuller flavor profile. An exceptional example of this is Guyana’s Demerara rum. Demerera is made from cane grown in Guyana, with long aging and a rich, dark flavor profile similar to Jamaican rum. It is distilled using old stills, thought to be indicative of how rum of old may have tasted. Aged varieties are the preference for connoisseurs of sipping spirit. The apex of flavor in the cocktail world, dark rum has it all and can transform many cocktails from ordinary to transfixing. Zaya and El Dorado offer some of the best flavors for mixing.

Zaya 16 $$ • El Dorado Twelve $$$$

rhum agricole

Rhum agricole is an incredible expression of the diversity of rum. Distilled from fresh sugarcane rather than molasses, rhum has a flavor that is minerally, dry, and complex; not unlike a good bourbon. Terroir, or where the sugarcane was grown and the elements that lends, is more present in this variety. These rums can be white, gold, or dark, with flavors that incorporate vegetal notes and pleasant grassier flavors into the complex rum backdrop. Their earthy sophistication and drier profile make for a good variation on a classic whisky or gin drink.

Rhum JM Blanc Agricole Martinique $$$ • La Favorite Rhum Agricole Vieux $$$$

Ingredient: fernet

Fernet is generally agreed upon to be a member of the amaro family, but in the world of italian digestifs, nothing is straightforward, and even this simple quantification is not a unanimous decision. As Brad Thomas Parsons notes in his book Amaro: “Most would agree that fernet is a subcategory or class of amaro, typically defined by common ingredients like aloe ferox, myrrh, and chamomile, but some say no, amaro is amaro, fernet is fernet.” While this stance is less popular, it isn’t unreasonable; fernet follows a specific direction in flavor that is recognizably distinct from traditional amari. While there is no agreed-upon set of ingredients that are necessary to make fernet, it does follow a loose subset of flavors and is typically dryer, with fewer baking notes and more intense medicinal flavors. Some fernets are extremely dry and medicinal, with world-famous fernet-branca serving as CEO of that pack. Mark Bitterman notes in his Field Guide to Bitters & Amari that American’s found fernet-branca so “bitter and unpalatable that 95 years ago authorities acquiesced keeping it legal (for medicinal use) during Prohibition.” Indeed, while fernet-branca’s reputation is strong as a badge amongst industry folk, it holds an equally strong reputation among Americans as something so gross it can be used to play tricks on unwitting friends.

When using fernet in cocktails, it is particularly important to understand how amari and bitters relate. While bitters and amari are considered separate concepts by the United States government and are regulated differently, in concept there is little difference other than intent: amari is meant for sipping, and bitters are meant for mixing; that is the only clear and present difference. The reason it is important to understand this distinction with fernet is that dryer, more herbaceous fernets like fernet-branca are not significantly different from bitters, both in taste and application. Adding a half-ounce of fernet to a cocktail is not remarkably different from adding a half-ounce of Angostura to a cocktail, outside of the fact that Angostura, with it’s balanced and spicy profile, might be more likely to work out. Fernet-branca is a very dry ingredient, and offers very little sugar to balance out its boisterousness. Because of this, most simple cocktails you see here will employ fernet like a bitter. Drinks like the Toronto and hanky panky are outstanding examples of this pattern. In drinks with bigger bodies and more boisterous flavors, fernet can stand up as a base. Drinks like the apotheke, Black Betty, and odd bedfellows follow this pattern.

A second, equally important element to understand when working with fernet is that, like all amari, they can vary wildly in the way they are balanced. The classic fernet-vallet, for example, is much more balanced than branca, with significantly fewer menthol notes and a mild bitterness. The same goes for the popular R. Jelinek. Fernets like these can be used more liberally in drinks like the Toronto and hanky panky, or in the same amount for a milder cocktail. Conversely, newer upstarts like Fernet Francisco or Fernet del Frate offer similarly pungent profiles to the more famous fernet-branca, and should be used with an equally delicate touch.

Ingredient: vermouth

Vermouth has a claim to the title of world’s oldest alcoholic beverage, but this mostly depends on how broadly we define vermouth. The earliest forms of fermented wine were crude and likely tasted bad. Infusing them with various local herbs and spices not only helped remedy the taste problem, it also packed the concoctions with vitamins, minerals, and sugars that people used as medicine. In his book Vermouth, Adam Ford outlines three different early examples of these proto-vermouths, all from the stone age. The first and earliest came from China circa 6200-6500 BCE, where a team of historians uncovered pots with traces of wine, honey mead, and rice malt. Similar concoctions were discovered in what is modern-day Iran and Egypt, around 5400–5000, and 3150 BCE, respectively. While these ancient discoveries are certainly fascinating, the delineation between mulled, aromatised, and spiced wines—especially during ancient history—is a foggy one. It is a bit of a stretch to lump all of this into the history of vermouth, and more apt to say that these stone-age concoctions are a part of the history of all wines, including vermouth. But for our purposes, which is making cocktails and learning about their ingredients, and within the context of modern history, for which vermouth is far-and-away the most popular infused wine, vermouth is a great proxy for what ancient alcohol might have looked and tasted like.

The easiest way to delineate vermouth from its historical kin is through the ingredient that likely gave rise to its name. Wormwood, or wermut in German, was one of the principal ingredients in the first versions of vermouth emanating from Turin cafes during the 1700s. These drinks, which were dramatically more sophisticated than the hippocras that inspired them, benefited from a massive price drop in spices. When Antonio Benedetto Carpano first began serving the first vermouth, it purportedly contained fifty ingredients. Why? In the words of Ford: “The Spanish, as we know, set out for the west and brought an entirely new crop of spices back from the New World. As a result of these explorations, the price of spices dropped like a hammer into a lake.” When Carpano left his day job as a wine shop assistant, he could walk across the street and buy spices for a pittance that not long ago were worth their weight in gold. This moment in time, and the amazing mixtures it inspired, likely define vermouth more than any single ingredient. The true magic of vermouth is that—just like it’s best friend the cocktail—it has few rules.

While the mid-century dry martini epidemic destroyed the quality vermouth market in the U.S., great vermouth continued to be sipped all over Europe. With the cocktail revolution in the early 2000s, quality bottles slowly trickled back into the American market, and today, a wide gamut of incredible vermouths can be procured at many specialty shops. In fact, so many great vermouths exist today, it can sometimes be difficult to choose. Don’t worry: we have your back, but not before a quick word on storage.

Vermouth is wine and should be treated like it. Once opened, it will start going bad. Because it is less delicate than wine, it will keep longer, but not significantly longer. We recommend storing it in the fridge, where it will stay good for several weeks, and pretty good for several months. We don’t host enough parties to go through a bottle of vermouth in a couple weeks, so we can attest that a bottle of decent vermouth stored in the door of the fridge will do ok even after a month of being opened. Whatever you do, refrain from keeping your vermouth out with the rest of the bar. As much as one might prefer that ornamental Dolin label amongst your other bar staples, we can assure you that the taste of spoiled vermouth isn’t worth it.

sweet vermouth

A good sweet vermouth is one of the most complete drinking experiences one can have. Tangy, bitter, sweet, and spiced, this brew has it all. Even better, sweet vermouth makes a cornucopia of fantastic classic cocktails. For a vermouth-heavy drink, try a Vieux Carré, bamboo, or creole. For something a little unexpected, try a harvard, palmetto, or maybe a Remember the Maine. If all else fails, there is always the ineffable Manhattan. Buying sweet vermouth is easy too. If you aren’t looking to spend a lot, buy Cocchi di Torino. If you want to spend a little more, buy Carpano Antica. If you want to spend even more, buy something from Del Professore; you won’t regret it. From here, there are endless new vermouths to explore. Lo-Fi, Tempus Fugit and Contratto all make excellent bottles.

Cocchi di Torino $, Carpano Antica $$, Del Professore Rosso di Torino $$$

dry vermouth

Bone-dry, brash, and bitter, dry vermouth is the intense yin to sweet vermouth’s yang. Sometimes called French vermouth due to its origins, this style is harder to work with, but a clear color and incredible flavor yield heightened rewards for the greater effort. For something vermouth-forward, try a chrysanthemum or a claridge. For something perfectly balanced, opt for a Ford, El Presidente, or Brooklyn. If none of these sound quite right, then consider the infamous martini, but do consider making it with more than a splash. Buying dry vermouth can be riskier than buying sweet vermouth. Whereas with sweet it feels almost impossible to go wrong, the complex and intense flavors of dry vermouth can often be difficult to work with. Both Vya and Lo-Fi dry vermouths, for example, are excellent examples of the spirit, but with intense and bone-dry profiles, they don’t work in every cocktail. The most flexible dry vermouth is Dolin Vermouth Dry. Cinzano is extremely cheap and also easy to work with.

La Quintinye Royal Extra Dry $, Dolin Dry $, Lo-Fi Dry $$

blanc vermouth

Sometimes called bianco vermouth, blanc vermouth is light in color like a dry vermouth, but has a sweet, viscous body like a sweet vermouth. Try it in the Fair Harvard, or as a historically appropriate substitute in drinks like the el presidente and turf. Blanc vermouth is great fun to experiment with, as it can change the color and character of many sweet vermouth drinks without altering the flavor profile. Some cocktails historians believe that many pre-prohibition dry vermouth drinks actually used blanc vermouth, so give it a whirl in classics like the martini and see what happens.

Dolin Vermouth de Chambery Blanc $$, Contratto Vermouth Bianco $$$

rouge vermouth

Rouge vermouth has the color and spiced complexity of a classic sweet, but with a sugar profile more akin to dry. Whiskey enthusiasts like rouge vermouth in their cocktails, because the spiced complexity works well with whiskey, but the lower sugar content allows the whiskey to open up more cleanly. Try it in a classic Manhattan, or sweeter creole classics like the Vieux Carre or Cocktail à la Louisiane.

Dolin Rouge Vermouth de Chambéry $, Noilly Prat Vermouth Rouge $

Ingredient: whiskey

Whisk(e)y encompasses a broad category of spirits distilled from various fermented cereal grains and aged in wooden casks. Various grains are used for different varieties, including barley, corn, rye, and wheat, which in turn lend unique flavor to their respective product. Malt whisky is made primarily from malted barley, whereas grain whisky can be made from any type of grain.

In the 15th century, the art of distillation migrated from the European continent to Scotland and Ireland, where lacking the vineyards and grapes of the continent, they turned to fermenting grain mash, resulting in the first distillations of modern whisky, which were raw and unaged. European colonists brought their whiskey distilling practices to America, and centuries later American whiskey is a product unto itself with unique standards of identity. Whiskey-making was one of the first cottage industries in the new world, predominantly made by farmer-distillers, for whom it was a practical waste reduction and profit avenue. Until the mid-eighteenth century, whiskey was made in relatively small quantities and without distinctive or consistent techniques.

Improved distillation technology allowed manufacturers to produce whiskey more efficiently, and at a lower cost, which led to the production of grain whisky, a less intense spirit than its malt based relative. The lighter flavored grain whisky, when blended with the more potent and fiery malts, extended the reach of Scotch whisky to a considerably wider market. Rye whiskey was very popular during Colonial times, especially in the Northeast US, traditionally produced in Pennsylvania and Maryland. Prohibition damaged the industry and only a few distilleries—such as Old Overholt—continued production after repeal, although much of the production has long since decamped. A stall in brandy production in 1880s France left an opening for whisky to emerge as a top player in the spirit industry.

Bourbon, Tennessee whiskey, and rye are all examples of straight whiskey, which must be aged in newly charred oak barrels for a minimum of two years. Only water is added to dilute the alcohol, which must be at least 80 proof. Blended whiskey is composed of both straight whiskey and neutral spirits; generally, the taste is more mellow than both the straight or single malt whiskey varieties. Bourbon, rye, and blended scotch are the most frequently employed whiskies while mixing, and likely one of the first bottles to occupy a growing home bar. They are inseparable from the origins of North American cocktails, forming the base of some of the most beloved and fundamental recipes. Rye, not bourbon, served as the base for many pre-prohibition favorites. For some time rye faded from production and bourbon slipped its way into many of the recipes. Thankfully as bartenders and imbibers have increasingly taken to flipping through the pages of old recipe books, rye has experienced a revival and is once again readily available to recreate the spicy formulas of old.

bourbon

Bourbon’s smooth, sweet, full bodied flavor makes it the base of choice for many of the most popular whiskey cocktails. It is a very versatile whiskey made from a grain mixture of at least 51% corn, aged in charred new oak, and distilled to no more than 160 proof. No blending or additives—except water to reduce it to bottling proof—is allowed in bourbon. Distilled since the 18th century, this variety has a long standing association with Kentucky, but this association is loose as opposed to strict; there are no geographic standards of identity like Scotch or Cognac, and it may be made anywhere in the United States. It’s versatility lends itself nicely to a wide range of drinks ranging from the world-famous mint julep to old classics like the seelbach and newer standbys like the revolver.

Four Roses $ • Bulleit $$ • Buffalo Trace $$

rye

The spicier, slightly fruitier cousin to Bourbon, rye whisky is produced from a fermented mash of not less than 51 percent rye, and stored in charred new oak containers. Historically produced primarily on the east coast, it is the historical foundation for some of the most iconic North American cocktails. Rye adds a lighter, drier character to drinks, mixing well with rich and bright ingredients alike. There is a notable spiciness and slightly bitter flavor that naturally expels from the grain itself. If you're looking for an authentic Sazerac, Vieux Carre or Manhattan, you'll want to pick up a bottle of rye. For those more accustomed to bourbon, try a variety such as Rittenhouse Rye, which has a rye content closer to the minimum.

Old Overholt Rye $ • Rittenhouse Rye $$

scotch

Scotch whisky is a distinctive product of Scotland, crafted in compliance with United Kingdom law regulating its manufacture, requiring maturation in oak casks for at least three years and bottling at a minimum alcoholic strength of 40% abv. Although a smoky aspect defines scotch, each region of Scotland produces different and distinct flavor characteristics. This is particularly evident in single malts. When choosing a scotch you will find either "single malt" or "blended" on the label along with an age statement. Blended scotch, made from a careful selection of single malts and grain whisky, is the best base for mixing and the perfect fit for the standards like a Rob Roy or Blood and Sand. In his excellent guide, “The World Atlas of Whisky,” Dave Broom asserts that in good blended Scotches, grain whisky coaxes out the complexities of a malt by emphasizing secondary characteristics that might otherwise be hidden. They tend to be more mixable with a variety of ingredients and are often sold at a more reasonable price than single malts. Single malt, distilled entirely from malted barley from a single distillery, is best reached for when sipping, as it is pricier, more aggressive, and doesn’t play as well with others. However, on occasion they are called upon to add bold flavor in place of or alongside blended varieties. Big, bold, and peatier scotch whiskies such as those from the Islay region are best employed as a float or mist to add smoky dimension. The classic Penicillin is an excellent example of this approach.

Monkey Shoulder $$ • Pig's Nose $$ • Peat Monster $$$

Ingredient: brandy

In broad terms, Brandy refers to a distilled spirit made from the fermented juice, mash, or wine of fruit. While the long tradition of French grape brandies has historically received much of the attention, it is in fact a global family of spirits. According to Brandy: A Global History the most popular theory regarding the spirit’s commercial origins revolves around Dutch merchants distilling wine as a preservation method and as a way to make it easier to transport.

Brandies made from wine include Cognac, Armagnac, Brandy de Jerez and Pisco. Brandy has a traditional age grading system, although its use is unregulated outside of Cognac and Armagnac, and frankly it’s not of much use when selecting for mixing. South American pisco has been produced in Peru since the 17th century. Pomace Brandy, such as grappa, is made from the pressed grape pulp, skins, and stems that remain after the grapes are pressed for wine. Fruit brandy, other than grape brandy, derived from one variety of fruit, is most commonly designated as “brandy” qualified by the name of said fruit. Clear fruit brandies, or eau-de-vie, are traditionally un-aged, resulting in a dry, aromatic, highly concentrated fruit flavor. These spirits are typically served at the end of a meal, or between courses.

The first brandies made in the United States used a variety of ingredients, but two of the more popular during the Colonial Age were peach brandy, mainly produced in what is now the southern US, and applejack distilled from cider, which originated on the east coast. Imported European brandies were the spirit of choice among wealthy North Americans, particularly southerners, but after the civil war that market fizzled. The availability of cheap rum, a growing taste for homegrown bourbon and rye, and a plague induced reduction in Cognac, all opened the door for new world spirits. On the west coast, Pisco was imported into the San Francisco area during the seventeenth and eighteenth centuries. Demand increased during California’s Gold Rush in the mid-nineteenth century and while it experienced increasing popularity throughout the rest of the century, Prohibition effectively destroyed the pisco market in the U.S.

By the 1800s brandy—usually Cognac—became popular as the base of American cocktails. The spirit is responsible for some pivotal moments in cocktail history, such as founding the Sour family (Brandy Crusta) or serving as the base of the the first mixed drink to be named something other than “Whiskey Cocktail” or “Brandy Cocktail” (Japanese). The early twenty-first century has once again seen a surge in popularity of a wide variety of brandies. At this point, unless otherwise specified, when a cocktail calls for brandy one generally reaches for Cognac, but it’s far from the only variety embraced in cocktails. Pisco has gained dramatically in popularity in recent years, with entire bar programs now focused on the spirit. Apple brandy has been embraced by many small American distillers, as well as a diverse range of fruit brandies in general, and there is an increasing variety available alongside their traditional European kin, ready to provide a respectable fruity boost to cocktails both new and old.

cognac

Rich, nutty, and sweet: Cognac is our go to brandy for mixing. It is a grape brandy double distilled and aged in oak in the Cognac region of France, entitled to be so designated by the laws and regulations of the French Government. It is double distilled in pot stills, then aged in oak barrels, which contributes to the drink’s complex flavor. Cognac is a pricey ingredient, so if you’re not in the market to spend, you’re better off trying a recipe designed for a different base spirit. Cognac is relatively versatile and well suited for split base cocktails like the classic Vieux Carre, Sidecar, or tiki’s Fog Cutter. It is most often employed as the base of spirit-forward pre-prohibition drinks, like the Sazerac and Champs Elysees and as the rich base of creamy drinks like nogs, the Brandy Alexander and Milk Punch. For a lighter approach, it is an excellent addition to classics like the Champagne cocktail.

Dudognon Reserve $$$ • Pierre Ferrand Ambre $$$ • H by Hine $$

pisco

Pisco is a South American clear to amber-colored grape brandy produced in specific winemaking regions of Peru and Chile. It is done so in accordance with the laws and regulations of the country of manufacture. The more commonly available Peruvian pisco is produced only using copper pot stills, aged for a minimum of 3 months in vessels that do not alter its properties, and distilled at bottle strength. Peruvian Pisco can fall into various classifications, reflecting rules for the area of production, the types and quality of grapes, and the distillation and aging of the spirit. The classic treatment of the spirit—the pisco sour—is so beloved that both countries claim it as their national drink. The spirit can be a bit acidic and difficult to mix, but its colorful bouquet of fruity-nuttiness has been picked up for creative spins on classics like the Fair Harvard or Maggie Smith. Depending on the style of pisco, flavor profiles can vary significantly. For bigger, earthier flavors we’ve used Pisco Porton, which stands up to other ingredients nicely. For lighter, more floral qualities we like Campo De Encanto Pisco.

Campo De Encanto Pisco $$ • Capurro Pisco $$

apple brandy

Apple Brandy is composed of 100% distilled cider apples. Calvados is an apple brandy hailing from France, specifically the Normandy region. These are aged in oak casks for at least 2 years and lean towards nuanced, fleshy, and layered flavor. American apple brandy generally comes in two forms: either aged in various kinds of barrels, resulting in a rich, spicy brandy; or fresh un-aged eau de vie. American apple brandies are often confused with applejack, a historically unaged spirit produced by freeze distillation and one of the oldest continuously produced spirits in the United States. Most contemporary applejack is produced through distillation and mixed with other neutral grain spirits, resulting in a thinner, fairly brash interpretation. For many years Lairds was one of the few American apple brandies on the market. Thankfully, there is now an increasing variety of quality options from small distillers.

Domaine de Manoir Du Montreuil Reserve $$ • Laird’s Straight Bonded $$

apricot brandy

This ingredient can cause some confusion. For mixing, there are two options: a sweet apricot liqueur, which may or may not have a brandy base, and an apricot eau de vie, a clear fruit brandy. We often use them interchangeably, but in some recipes, the eau-de-vie will require some tinkering with sweetness proportions, as it’s rather dry. This brandy's vibrant flavor and spice notes make it a popular fruit brandy for mixing. It’s also our preferred substitute for historical recipes that call for similar stone fruit liquors, such as peach brandy.

Rothman & Winter Orchard Apricot Liqueur $$ • Bitter Truth Apricot Liqueur $$

pear brandy

This classic style of eau-de-vie and popular French digestif has a brash unaged character. A cynical review may compare it to fruit flavored paint thinner. However, in small doses it is delicious mixed into autumn and winter inspired drinks. There are several great types of pear brandy lining better liquor store shelves: we like the American distilled St. George and Clear Creek. If you are looking for something a bit more exotic, we were recently turned on to the lovely F. Meyer Poire William.

St. George Pear Brandy $$ • Clear Creek Pear Brandy $$

Ingredient: peychaud's bitters

Antoine Amedie Peychaud began dispensing his own homemade bitters from his pharmacy in New Orleans in 1838. Based on a family recipe, Peychaud would mix his bitters with cognac and serve it to patrons in a style of jigger called a coquetier, which means “egg cup” in french. While nobody knows where the term cocktail comes from, one New Orleans legend pins the name with Mr. Peychaud and his egg cup, which patrons struggled to pronounce. If this seems like an unlikely story, try listening to an authentic pronunciation of the word and the idea might come around. Peychaud’s mixture was so popular it began to grow outside of the pharmacy. It became particularly popular at the Sazerac Coffee House; so popular, in fact, that the mixture came to be known simply as a “Sazerac.”

Despite its connection with early cocktail history, Peychaud’s was not necessarily a popular choice by bartenders nationally. Neither Jerry Thomas nor Harry Johnson mention it in their important early bar books, and in general one would need to be pretty stubborn to find mention of it in any of the barbooks coming out of New York, London or Cuba. One city where this was not true: New Orleans. The excellent Famous New Orleans Drinks and How to Mix Em’ (1938) mentions it plentifully. Unsurprisingly, 1935’s Peychaud’s Original Cocktails also makes plenty of opportunities for it. New Orlean’s love of the stuff might also have saved it from the great bitters die-off that occurred before and during prohibition: as a nationwide ban on alcohol shut down nearly every independent bitters manufacturer, the many private drinking clubs in the crescent city kept Peychaud’s afloat. Through the rest of the 20th century, Peychaud’s didn’t get a lot of mentions in cocktail books, but it was one of only two major bitters to survive, and that worked in its favor during the early days of the cocktail renaissance in the 2000s. As inventive bartenders started searching for authentic ingredients, Peychaud’s rich history and antique label stood out.

Peychaud's $, Scrappy's Orleans $$$

Peychaud’s is much lighter on baking spices than other aromatic bitters, instead offering strong notes of citrus peel, cherry, and anise. This makes it an excellent choice in summer cocktails or anything that will benefit from bright, citrusy flavors. Peychaud’s can also act as a coloring agent; as Brad Thomas Parsons notes in his book Bitters: “Its bright red cough-syrup color also helps it stand out from the competition, and just a few dashes can cause a cocktail to take on its trademark candy-apple blush.” Employ Peychaud’s to lighter-colored drinks to create a warmer, more appetizing hue that is sure to turn heads. Drinks like the Queens Park swizzle, Suissesse, and Pendennis use it in this way. In larger doses, it can turn drinks a bright, stunning red. Try the Sawyer or Seelbach to see this stronger effect.

Ingredient: tequila

Tequila is a member of the family of spirits derived from the agave plant. A fermented beverage known as pulque was consumed in central Mexico prior to European contact. This is the most frequently referenced descendent of both tequila and mezcal. Technically, all tequila is a variety of mezcal, a broader variety of agave spirit. However, mezcal is marketed as a stylistically distinct beverage and is popularly understood as a sibling—not a parent—of tequila.

Both distilled spirits are made from agave, but tequila is exclusively made from blue Weber agave and as a product of origin can only be produced in the state of Jalisco and some parts of Guanajuato, Michoacán, Nayarit, and Tamaulipas. It's made by steaming the heart, or piña, of the agave plant in above-ground ovens and distilling the liquid in copper pots. Mezcal, on the other hand, can be made from multiple types of agave and is traditionally made in various Mexican states. The spirit’s distinct process of roasting the agave in underground pits lined with burning hot rocks gives mezcal the signature earthy, smoky flavor. Much of mezcal is still artisanal in nature, produced using small-batch and ancient techniques. The result is a distinct expression of each agave used and terroir, and a category of spirit that offers a diverse range of flavors.

Mezcal and tequila varieties are defined and categorized by their aging period. Blanco, plata, silver—or in the case of mezcal blanco or joven—is unaged, but sometimes rested in neutral holding tanks for up to 2 months. Reposado is aged a minimum of two months, but less than a year in oak barrels. Añejo is aged a minimum of one year, but less than three years in small oak barrels. Finally, the more recently established tequila category of Extra Añejo is aged a minimum of three years in oak barrels.

Although these spirits have been produced for centuries, they have a less storied history in the cocktail world. One would be hard pressed to find someone unfamiliar with the Margarita, and a few modern classics have entered the canon like the Oaxaca Old Fashioned, yet there are still too few agave spirit-based cocktails considered standards. We typically emplo blanco and reposado interchangeably; however a purist may disagree. Pricier, more complex anejo and extra anejo are best reserved for sipping, and can overwhelm many mixes. Reserve anejo for the first time you try a drink that specifically calls for it or when you’re feeling indulgent. In recent years, bartenders have embraced mezcal, both in original cocktail recipes and in variations of classic concoctions like the Oaxaca Old Fashioned.

blanco tequila

Blanco tequila is unaged, though sometimes rested in neutral holding tanks for up to two months, resulting in a vegetal expression of agave. Depending upon the region or elevation the agave is grown in, the resulting spirit can range in flavor from sharp, fresh and grassy to tangy and sweet. Reach for the higher quality 100 percent agave tequila, with no added sugars (as opposed to the inferior mixtos: made from a mix of agave and other sweeteners). Blanco’s fresh expression of the agave plant blends wonderfully in citrusy Margarita style drinks. For the pitcher drinking Margarita lover, they’re conveniently also the most affordable.

Cimarron Blanco, Espolon Blanco $$ • Herradura Blanco $$

reposado tequila

Reposado tequila spends between two months and one year maturing in oak barrels. As with other spirits aged in casks, tequila takes on the flavors of the wood, while the harshness of the alcohol mellows. The result is a smooth, spiced, slightly sweet spirit that inches closer in flavor to other oak aged spirits like whiskey. Reposado strikes a balance between the bright agave notes of blanco and spicy, subtle oak sweetness of barrel aging, making it a very versatile option. They work equally well in citrusy drinks as well as spirit forward drinks, and are full bodied enough to stand up nicely alongside mezcal’s aggressive flavors in a split base. Employ reposado in drinks requiring more spice or vanilla notes, such as the festive Stardust, or a split base like the Si-Guey. Only minimally more expensive than blanco, reposado is a great way to add aged complexity without breaking the bank.

Cimarron Reposado $$ • Espolon Reposado $$ • Herradura Reposado $$

mezcal

Most mezcals on the market are blancos, and this is our go to for mixing. There is a wide variety of flavor available, ranging from the signature earthy smoke, to a brighter, floral profile—a delicious example of which is Alipus San Andre. The spirit’s smoky, briny flavors are too intense in large doses and are instead often used alongside tequila as a split base or applied in small amounts as a modifier. The small dose application is also convenient given mezcal's higher price tag.

Del Maguey Vida Mezcal $$ • Bruxo No.1 $$$ • Vago Elote Aquilino $$$

Ingredient: lemon

Lemon has been a popular addition to mixed drinks since the earliest recipes were put to paper. In the 1700s it was used as a popular addition to large punches, as the fruit helped perk up the acidity level of the mixture and, when mixed with sugar and spices, could offset the often dubious quality of the base spirit. In the carribean, various imported fruits were combined to make what is now called planter's punch. In the states, it was frequently used to perk up punches like the negus punch and philadelphia fish house punch.

In the 1800s punch began to evolve into new, individually served drinks as manufactured straws and ice became more readily available. As David Wonderich notes in Imbibe!,: “The glass of Punch went forth in the new land and multiplied, begetting a whole host of other drinks. Even the Cobbler, an unpunchy drink if ever there was one, can be seen as one of its offshoots, combining as it does wine, sugar, ice, and a couple of slices of citrus shaken in.” Indeed, lemon followed this transformation and became a popular adornment atop afternoon drinks like the sherry cobbler, morning sippers like the morning glory fizz, and dinner accompaniments like the whiskey sour and brandy crusta. That final drink would become a precursor to a host of sours served up, as the shaker slowly replaced the toddy stick and bars at the turn of century began fixing things like the sidecar, aviation, and last word.

lemon juice

Unlike bottled spirits, which are typically manufactured and tested for consistency, lemons are a natural product of the earth and therefore vary in flavor and acidity. Of course, industry is always apt to solve nature’s “inefficiencies”, and as such bottled lemon can be procured at any supermarket. You will never see us recommend this stuff, and for good reason: it tastes really bad. We wouldn’t use it in our food, our cocktails, or to clean our floors, if we did that kind of thing. Yes, lemons are annoying to juice and vary in flavor, but if you wanted something easy, why not stick to jack and coke? Working with fresh lemons adds a new variable, but nothing that can’t be easily handled: before you serve any drink, pour a little bit into a shot glass. Try the drink, and add additional sweetener if the lemons are higher in acidity. If you are familiar with the straw trick; don’t use it. The nose of the drink greatly affects your perception of the drink’s balance; something that the straw trick doesn’t account for.

How you juice your lemons can change the way your drink tastes. Pulp, seeds, and other impurities can be macerated into the liquid, imbibing bitterness into the mixture. In his book Liquid Intelligence, Dave Arnold writes “Forget hand reamers; they suck. Upright lever-pull citrus presses are good for grapefruits that won’t fit in smaller hand presses, but they are slow. The best small-citrus press is the lowly swing-away hand press.” We generally agree with Dave. If you don’t already have a hand press, we suggest a stainless one, as anything with fun colors will quickly be compromised by repeat exposure to acidity. Lemon and Lime have nearly identical degrees of acidity (Arnold clocks it at 6%) which would theoretically make them interchangeable, but generally speaking this isn’t true. Lemon is mostly citric acid, while lime is a combination of citric and malic acid, giving it a much smoother, fruitier taste. Drinks like the jack rose, aviation, and presbyterian are all excellent places to start.

lemon peel

Fresh lemon peel is more than just a pretty decoration: the oils locked in the peel of lemon have a very different scent that that contained in the juice. If you pick up a glass of lemon juice and smell it, you won’t notice much. In fact: if you ever bottle lemon and lime juice for a party, you would be wise to label them, as they are ripe for mixing up. Peel is where the lemon flavor that we taste in candies and cakes is actually found, and when you twist or bruise a lemon peel, you are imparting the same wonderful scent to your drink. Classics like the brandy crusta, sazerac, clover club, and martinez all show the wonderful and amazing power of the peel.

lemon twist

A lemon twist will impart similar qualities as a lemon peel, but the lower surface area reduces the impact for more delicate flavor profiles. This is great in delicate gin drinks like the martini, turf, and fair Harvard. Making lemon twists is easiest with a citrus zester, but if you don’t have one, try making a lemon peel with a traditional peeler, then cutting it into thin strips with a knife. The extra legwork might rub off a bit of the oil, but it won’t ruin the drink. Peeling the citrus over the drink will mist even more oil onto the glass, amplifying the impact. This isn’t always necessary, and depends on the drink.

lemon wheel

A lemon wheel is a bit showier than a peel. To make one, choose a smaller lemon and slice the end off. Make another cut a few millimeters into the lemon, slicing off a circular wheel. You can make one more slit halfway down the middle of the slice for placing on the edge of the glass.

The Daily Front Page 27 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — The Body Briefing
article

Should you stop cracking your knuckles?

by tchalla·▲ 123 points·130 comments·bbc.com ↗
Like a firework exploding in the joint

BBC/ Serenity Strull/ Getty Images A cartoon explosion as knuckles are being cracked (Credit: BBC/ Serenity Strull/ Getty Images)

Like a firework exploding in the joint – here's everything you need to know about cracking your knuckles.

Growing up, Donald Unger was warned – by his mother, several aunts, and later his mother-in-law – that constant knuckle cracking would cause arthritis. Determined to prove them wrong, he cracked his left knuckles at least twice a day for 50 years – around 36,500 cracks in total – while leaving his right untouched.

In 1998, aged 72, he took X-rays of both hands to find out the result. "There was no arthritis in either hand, and no apparent differences in the two hands," he concluded.

This of course, was a sample size of just one. Studies indicate that somewhere between 20 and 50% of people crack their knuckles. So, is this something that we should be worried about – could every pop, click, and crack be causing lasting damage?

A matter of bubbles

For some a knuckle crack is just a mindless habit. Others like the way cracking their joints feels. But judging by the flurry of chiropractic adjustment videos trending on social media, there's a good number who get a kick out of hearing that snap.

What happens when we crack our joints is actually relatively simple. A joint is where two bones meet, and the ones found in our knuckles, neck, and back are surrounded by synovial fluid – an egg white-like substance that acts as a lubricant. When you twist, pull, and bend your joints to crack them, the space within the joint temporarily expands. This causes the pressure of the synovial fluid to fall, and as a result, gases that were once dissolved in the fluid begin to emerge as bubbles.

The sound of a joint cracking – which is actually the sound of the bubbles that have formed collapsing – can be surprisingly loud, up to 83 decibels. That's roughly the volume of a diesel truck rumbling past at 40 miles an hour (64km per hour). When scientists at the University of California, Davis, viewed a joint that was being cracked using ultrasound, they described the moment of the "crack" as appearing like a firework exploding on the screen.

A mostly harmless habit

It may be noisy, but the sound of your joints popping is "just a normal physiological process", says Kimme Hyrich, a rheumatologist at the University of Manchester in the UK.

But is normal necessarily harmless?

"Obviously there are some red flags like pain or swelling in the joints," says Jay Jagannathan, a neurosurgeon with his own practice in Michigan, in the US, who has seen patients with strains and other issues after cracking their necks too forcefully – something which is not recommended (more on this later).

…when doctors physically examined knuckle-crackers, they found no swelling or disability of any sort

However, generally speaking, when you feel the urge to crack your joints, it's considered pretty harmless, says Jagannathan.

Some people still worry that vigorous knuckle cracking might result in finger dislocations or tendon injuries, especially when you apply too much force or jerk your finger in a way that could accidentally cause it to detach from its joint. And indeed, there have been some cases of this happening. In 1999, for instance, a Philadelphia-based hand surgeon described how two patients sprained their fingers because they were overly keen to hear the satisfying pop sound.

BBC/ Serenity Strull/ Getty Images The "pop" your knuckles make when you crack them may sound alarming, but it's mostly harmless (Credit: BBC/ Serenity Strull/ Getty Images)

The "pop" your knuckles make when you crack them may sound alarming, but it's mostly harmless (Credit: BBC/ Serenity Strull/ Getty Images)

But with less forceful cracking, such incidents are rare.

What habitual joint crackers seem most worried about, however, is whether they'll wind up with osteoarthritis – the most common type of arthritis that's associated with wear-and-tear of the cartilage, the protective tissue that pads your bones at joints. "It's what a lot of people ask me in my clinic and also around the dinner table," says Hyrich. "The basic answer is it doesn't," she says.

Several studies have debunked this old wives' tale. In one, published in 1975, researchers studied 28 nursing home residents and discovered that habitual knuckle crackers had similar rates of degenerative arthritis to non-crackers.

A more recent retrospective study examined the history of knuckle cracking in 215 osteoarthritis patients and compared them to controls without the condition. It drew the same conclusion: the amount and duration of knuckle cracking over someone's lifetime had no effect on their osteoarthritis risk.

Watch the neck

While knuckle-cracking is unlikely to be a problem, the same is not true of back and neck-popping. The neck contains vital nerves, including the spinal cord. "Plus, you've got two really important arteries that run through the back of your neck and travel towards the brain," adds Jagannathan. These areas are delicate – mishandling them can cause serious injury and side effects such as tingling in the limbs and dizziness. "Any type of excessive manipulation is dangerous," says Jagannathan.

Cracking your own neck is not recommended, and even professional manipulations are controversial. In 2012, Neil O'Connell, from the Centre for Research and Rehabilitation at Brunel University and colleagues described chiropractic neck adjustments as "unnecessary and inadvisable".

Getting a grip

Another supposed peril of knuckle popping is that it affects your grip strength – an important health marker linked to a range of health outcomes, including heart disease, cognitive decline, depression, and some types of cancer.

A 1990 study of 74 knuckle-crackers who'd been honing the art for between 18 and 60 years discovered they had weaker hand grips and more hand swelling compared with non-crackers. But these findings were refuted in 2017, when a separate study found no correlation between knuckle cracking and weakened grip.

There are other myths too, such as how frequent cracking can lead to big knuckles or loose tendons, but Hyrich says they're all untrue. The ultrasound study above backs this up: when doctors physically examined knuckle-crackers, they found no swelling or disability of any sort.

For some people, cracking can provide a sense of relief and a temporary increase in joint mobility, because it stretches the joint, taking it through a wider range of motion. One theory even suggests that cracking stimulates nerve endings around the joint, relaxing surrounding muscles while reducing pain and releasing endorphins – but this hasn't been proven.

Given that knuckle cracking is mostly benign, there might be little impetus to stop. If you do want to, though, Jagannathan recommends conditioning yourself with techniques such as cognitive therapy, to understand what you're doing and to find distractions that prevent you from doing it. For example, you could consider keeping a log of your triggers (do you crack your knuckles when you're stressed, bored, or do it without thinking?) and try busying your hands with stress balls or fidget toys.

Overall, Hyrich says, cracking is harmless to the joint. The only thing it may harm, she adds, is your personal relationships – should your knuckle cracking become too annoying for your friends.

** All content within this article is provided for general information only, and should not be treated as a substitute for the medical advice of health care professionals.*

The Daily Front Page 28 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Also on the Front Page
The Daily Front Page 29 of 30
Sunday, August 9, 2026 The Daily Front No. #260809 — Colophon

That's the Front for Today

Issue No. #260809 — Sunday, August 9, 2026 — went to press 2026-08-10 at 18:11 UTC.

About This Magazine

The Daily Front is a daily digital magazine assembled from the stories that reached the front page of Hacker News on Sunday, August 9, 2026. Headlines, points, and comment counts are recorded as they stood at press time. All articles remain the property of their original authors — every piece links back to its source and its discussion thread.

How It Was Made

Fetched, cleaned, and typeset by an automated pipeline. An editor model laid out the pages, chose the highlights, and briefed the cover illustrator — 30 model calls and 272k tokens in total. Set in Jacquard 12, Playfair Display, Source Serif 4, and IBM Plex Mono, all served via Google Fonts under the SIL Open Font License.

The Cover

The cover illustration was commissioned with this prompt:

A dramatic, classical newspaper-illustration scene inside a dim midnight workshop: a lone engineer sits at a wooden desk studying a luminous hand-drawn semiconductor diagram while several small autonomous mechanical assistants tend a tangle of cables, a compact smartphone mounted like a tiny home server, and a humming vintage computer. In the background, a towering wall of softly glowing screens and a distant surveillance camera create an uneasy atmosphere; warm ink-and-watercolor texture, deep navy shadows, copper highlights, intricate editorial illustration, no text, letters, logos, or symbols.

Contemporary forensic photogrammetry render in a calm orthographic view: preserve the lone engineer at the wooden desk studying a luminous hand-drawn semiconductor diagram, small autonomous mechanical assistants tending tangled cables, a compact smartphone mounted as a tiny home server, a humming vintage computer, the towering softly glowing screen wall, and distant surveillance camera; translate every form into pearlescent scanned surfaces with point-cloud edges, raking scan light, and measured dimensional evidence, using a deliberate palette of midnight navy, cold cyan, opalescent white, muted copper, and restrained amber; no text, letters, logos, or symbols.

Absolutely no text, letters, numbers, readable symbols, or logos anywhere in the image.

Production Ledger

StageModelCallsTokens InTokens Out
extractgpt-5.6-luna 27 166,110 76,972
layoutgpt-5.6-terra 1 19,156 3,480
covergpt-5.6-luna 1 352 126
covergpt-image-2 1 256 5,488

The Publisher

Published by Johnny.

Support the Press

If The Daily Front brightens your morning, consider supporting its publisher.

Credits & Contact

All content — articles, posts, comments, and the images within them — belongs to its original authors and is reproduced here to point readers back to the source. Full credit goes to those creators; every item links to its original and its Hacker News discussion.

If you are an author and would like your content removed from an issue, write to hi@johnnys.page and it will be taken down.

Feedback is always welcome at the same address: hi@johnnys.page.

Credit where credit is due.

Every page of this issue began as someone else's work — these are the original sources, linked in full.

  1. How I use LLMs to learn complex topics by laurentiurad — laurentiugabriel.github.io·HN discussion ↗
  2. Message your other Claude Code sessions by mfiguiere — code.claude.com·HN discussion ↗
  3. OpenChamber: An Agentic Development Environment by hexomancer — openchamber.dev·HN discussion ↗
  4. We replaced Redis with MySQL for inventory reservations and it scaled by adletbalzhanov — shopify.engineering·HN discussion ↗
  5. My server is a phone now by seg6 — seg6.space·HN discussion ↗
  6. Everything you do is being recorded by ike_usawa — theatlantic.com·HN discussion ↗
  7. Mea Culpa – Dark Hours by satvikpendem — blog.terrygodier.com·HN discussion ↗
  8. Windows 11's built-in Weather app wastes more than 1 GB of RAM by akyuu — notebookcheck.net·HN discussion ↗
  9. The original URL for this prediction will no longer be available in 11 years (2011) by doubletwoyou — longbets.org·HN discussion ↗
  10. Lost my phone at the office. Claude suggested tracking Bluetooth signal strength by ilamont — twitter.com·HN discussion ↗
  11. Ask HN: What are you working on? (August 2026) by david927 — news.ycombinator.com·HN discussion ↗
  12. Dithered QR Codes by jmusall — andrewt.net·HN discussion ↗
  13. Os8088: A powerful Mac-like OS for the IBM XT, 286, 386 by jggonz — os8088.com·HN discussion ↗
  14. Microsoft Word for Windows 1.1a, Native X64 Port by BruceEel — github.com·HN discussion ↗
  15. Show HN: A Project Oberon System version running on RISC-V instead of RISC-5 by Rochus — github.com·HN discussion ↗
  16. Reviving a four year old reMarkable 2 by oskrim — oskrim.github.io·HN discussion ↗
  17. Improving Heuristics for A* Pathfinding by bobbiechen — redblobgames.com·HN discussion ↗
  18. Making difficulty curves in games by hakkikonu — davetech.co.uk·HN discussion ↗
  19. There Are Magic Hexagons of Every Order by gukoff — gukov.dev·HN discussion ↗
  20. TheoremDB – A public workspace for machine mathematics by frozenseven — theoremdb.org·HN discussion ↗
  21. The Alpha 21264 CPU: NT's Greatest RISC (1998) by Lammy — halfhill.com·HN discussion ↗
  22. John C. Lilly on solid state intelligence and the elimination of man (1978) by Kiboneu — kibotronics.net·HN discussion ↗
  23. Unexpected events and prosocial behavior: the Batman effect (2025) by davidbarker — nature.com·HN discussion ↗
  24. New Zealand lost its music media, and what we're building to replace it by berghoffer — propelmusic.co.nz·HN discussion ↗
  25. Tuxedo No. 2 – Cocktail recipes by smartmic — tuxedono2.com·HN discussion ↗
  26. Should you stop cracking your knuckles? by tchalla — bbc.com·HN discussion ↗
  27. Cool URIs Don't Change (1998) by Klaster_1 — w3.org·HN discussion ↗
  28. I made tinnitus my friend, then it disappeared [video] by gregsadetsky — mynoise.net·HN discussion ↗
  29. The tragedy of the commons, AI edition by simonpure — economist.com·HN discussion ↗
  30. Andrew Wiles on proving Fermat’s Last Theorem (1995) [video] by jackdoe — youtube.com·HN discussion ↗

Browse all issues in the archive →