Roastidio.us User Picks KjQKkQVg

A Critique of GPUI

Mon, 09 Nov 2026 18:08:58 +0000

Recently, there has been a trend of more desktop GUI apps being built using native rust GUI frameworks. And there are now even well known electron apps getting official rewrites: Discord announced their app is being rewritten using GPUI.¹ Meanwhile, a lot of the LLM-clones being published seem to choose egui. In this post, I want to explain why I am not sure those frameworks are a good foundation to build on.

To put it plainly: I believe both GPUI’s and egui’s state models are dead ends for complex desktop applications. Both are impressive projects, and they have their place. Zed genuinely feels fast and nice to use, and I use egui myself for debug interfaces in bevy games. But I don’t think those frameworks should be the default choice for native desktop apps.

I want to make two arguments:

Every UI architecture ends up needing to know what changed and who depends on it, or performance characteristics will not scale. A framework whose state model cannot say so makes the application say it by hand, at the cost of whatever made that framework’s API semantics attractive in the first place.
Once you admit you want that precision, components that run once, with signals and reactive holes, are the simplest API for it.

Disclosure: I ported GPUI’s current Linux renderer to wgpu², I built the benchmark harness used below, and I work on zgui, a signal-based Rust framework that appears in the charts.

The only question that matters

Raph Levien quotes Ron Minsky: “hidden inside of every UI framework is some kind of incrementalization framework.”³ A UI is a function of state, and state changes a little at a time. But if that function becomes expensive, you might want to start looking for ways to derive a faster way to update pixels on the screen from an incremental state change. So every framework has to answer one question: when one value changes, what runs?

Model	What a write runs	Who finds the change
Immediate (egui)	All UI code, next frame	Nobody
Elm (Iced)	All of `view`, then a diff	The diff
Views (GPUI)	Every view without a cache	You, with `notify`
Signals, re-run (Freya, Compose)	Components that read it	The framework
Signals, run once (Floem, Solid, zgui)	Closures that read it	The framework

I understand why people like the first three. No state to synchronize, one place where state lives, a render function that is plain Rust, no macros or separate compiler. I’m gonna make the argument that these approaches don’t scale, and fixing the underlying problem defeats what makes these models simple and easy to reason about.

GPUI: `notify` is zone.js

GPUI calls itself “a hybrid immediate and retained mode” framework.⁴ It retains state in entities. The UI is defined in render functions, changing state must trigger a rerun.

It is ordinary Rust. You can use if, for and local variables, and there aren’t any weird wrappers. State changes require an explicit notification:

notify carries the entity id.⁵ Since Rust doesn’t have a write barrier on &mut, GPUI cannot see which field changed (or whether anything changed at all). The Angular team wrote this about zone.js in 2023: it “is only capable of notifying us when something might have happened”, and “This approach has not scaled well.”⁶ notify is more precise than a zone, since it names an entity, but ultimately it makes the same kind of statement. Below that id, GPUI knows nothing, so it re-renders every view that is not behind a valid .cached() boundary. And in practice, GPUI often rerender every view, because .cached() is rarely used by application authors, and imposes certain restrictions on layout semantics.

GPUI has a reputation of being “fast”. And while constants might be relatively low, asymptotically, it is leaving a lot on the table. So I ran a few benchmarks, that specifically test how much a sparse state change in a large UI actually costs.

At 3,000 live rows with a cached view per row, changing one label takes 8.4 ms. A hover, a keystroke and writing a value equal to the old one all cost about the same, because the cost follows the tree and not the change. It grows by about 3 ms per 1,000 live rows. Write the rows as plain elements, as in the code above, and the same label takes 92 ms. A hand-written equality guard takes the equal write from 7.9 ms to 0.9 µs (demonstrating how much is left for each call site to find).

This doesn’t mean that every GPUI app is slow, but it shows the limit of the state model. Especially with more expensive layout, you do hit this wall in practice. Zed might feel fast, but the truth is that Zed is a relatively simple app, UI wise. The app’s chrome contains a few buttons, in a simple layout, a sidebar and a text editor, and the text editor is implemented as a custom element, completely bypassing GPUI’s layout and view semantics. By their own account, a window “has tens of nodes and a few thousand elements”.⁷

Making GPUI precise defeats GPUI

The obvious fix is to retain more. Zed has experimental branches for this, and Longbridge’s gpui-fast is a fork that keeps every view’s subtree between frames.⁸ ⁹ It works, within a limit: the smallest thing either one can reuse is a view. So to update one label without rebuilding the sidebar, the label has to be a view:

pub struct UnreadBadge { unread: usize, _watch: Subscription }

impl UnreadBadge {
    pub fn new(inbox: Entity<Inbox>, cx: &mut Context<Self>) -> Self {
        let unread = inbox.read(cx).unread();
        let _watch = cx.observe(&inbox, |this, inbox, cx| {
            let unread = inbox.read(cx).unread();
            if unread != this.unread {
                this.unread = unread;
                cx.notify();
            }
        });
        Self { unread, _watch }
    }
}

impl Render for UnreadBadge {
    fn render(
        &mut self,
        _: &mut Window,
        _: &mut Context<Self>,
    ) -> impl IntoElement {
        format!("{} unread", self.unread)
    }
}

Its owner then has to create it and keep the handle:

That is an entity, a Render impl, a subscription, a stored copy of the value, a hand-written guard and an owner, all to express that one label depends on one count. In a signal framework it is this:

The rest of GPUI’s API works against this too. Render takes no props, so parents push values into child entities during their own render. RenderOnce components, which is what buttons and rows are, draw inside their parent’s view and are no boundary at all. List rows are closures, so a row view means managing a keyed map of entities by hand.

And it only helps where state happens to line up with views. I reran gpui-fast’s own 60-panel benchmark, drew each frame once, and then moved the state:

With state owned by each panel, one change saves 83%. With a shared model, retention makes the same frame 11% slower. The window and the edit are identical. In real Zed, the Zed team measured retention “1–3% slower than off on ordinary workloads”, found that “Most of the real-Zed win” came from other work, and warned that “microbenchmark wins didn’t predict real-Zed results”.⁸ gpui-fast is real progress and costs little to adopt: it takes the 3,000-row label from 8.4 to 3.4 ms. But that frame renders three views and lays out one element, and still spends 3.4 ms, because the frame is still a walk over the whole tree.

The web has already walked this road. Redux’s style guide says “Prefer having more UI components subscribed to the Redux store and reading data at a more granular level”.¹⁰ MobX says to “create lots of small observer components”.¹¹ Both tell you to make a boundary per projection, manually, because the framework can’t infer it.

This is the part I find hardest to get past. People choose GPUI because render is a plain function of state. A UI where each projection is a separately owned entity with a subscription and a guard is no longer that. It is a signal graph built by hand from much heavier parts, where a missed edge is silent. Zed’s own design note says “Missing notifications are application bugs”.¹² Keep the pleasant API and you get view-sized updates. Take the precision and you lose the pleasant API. A signals crate on top would not change the trade, because its smallest sink is still a view. Reaching one node with no render running needs writes the framework can see and nodes that outlive a frame, and that means a new state model and a new element contract.

Elm: deceptively simple at small scales

At the size it is usually shown, the Elm architecture is a deceptively simple UI model: one state value, one update, one view, and every change has a name. While large applications do use it successully,¹³ ¹⁴ I do want to make the point that this clarity belongs to the small case, and in a complex application signals and stores are arguably easier to reason about.

Take the same unread count. It has to be right after every message, so either view recomputes it on every update or update maintains it:

match message {
    InboxMessage::MarkRead(i) => {
        if self.threads[i].unread {
            self.threads[i].unread = false;
            self.unread -= 1;
        }
    }
    InboxMessage::Delete(i) => {
        if self.threads.remove(i).unread {
            self.unread -= 1;
        }
    }
    InboxMessage::Arrived(thread) => {
        self.unread += thread.unread as usize;
        self.threads.push(thread);
    }
}

The definition of unread is now nowhere in particular. It is spread across every arm that touches a thread, and each new message has to remember it. The compiler checks that the match is exhaustive, but it does not check the arithmetic. The memo above has one definition, and a new writer cannot forget it.

The same thing happens with location. Where does a hover state or a half-typed draft live? Single source of truth says in the model, with a message type routed down and an outcome routed back up. Elm’s guide: “Actively trying to make components is a recipe for disaster in Elm.”¹⁵. Iced recommends returning an Action to the parent.¹⁶ Iced’s maintainer says components in this architecture always end “with pain”, and also makes the best case for the discipline: avoiding them “forces you to think hard about your data model”.¹⁷ Okay, I guess that’s a fair argument. But cosmic-files has 136 top-level message variants and 73 more for a tab, plus a Tab::update that returns commands for the parent to interpret.¹⁸ Everything in that is explicit, and none of it is simple.

The architecture also has the same issue GPUI has. The update implementation tells you what a message writes, it cannot tell you what read the field. Anything inside the view might. Elm’s architecture doesn’t answer “what changed?”, it answers “what happened?”. Session export might be useful in some scenarios, but it is not useful for scalable performance characteristics.¹⁹

This is what I read in the web’s history. Redux is the best-known relative of this design, and its docs read like a field report. Treat a portion of your store “as if it were a database”.²⁰ Selectors “will be re-run after every dispatched action”.²¹ The core package is “obsolete”, replaced by a toolkit made to remove boilerplate.²² Outside React, the mainstream has moved to tracked reads. Angular, Vue, Svelte and Solid build on signals or something equivalent, Preact offers them, and Svelte’s team put it this way: “we’ve come to the realisation that Knockout was right all along.”²³ Inside React, Jotai and MobX bring tracking in as libraries, and Legend-State even offers a “render once” style.²⁴ Most applications are still on React, and React’s team disagrees, which I come back to below. So the convergence is on the state model, outside one large exception.

Performance follows the same line. Since Iced rebuilds all of view after every batch of messages, one label at 3,000 rows builds 39,023 widgets and takes 7.3 ms. Lazy on every row only gets that to 5.7 ms, because view still has to visit each row to hash its key. The official lazy example keys on a version: u8 that four update arms bump by hand.²⁵ That is a dirty flag with a nicer name. In fairness, cosmic-files and Halloy use no lazy at all, and on a virtualized list Iced is one of the fastest frameworks I measured, at 0.19 ms. A bounded screen rebuilds cheaply. But asymptotic complexity is clear. And similar to GPUI, the API semantics simply can’t express the necessary information.

There is actually precedence for this: Vizia shows what happens when you add precision to this model. It moved from lenses to signals in March 2026 and kept its Model and event dispatch.²⁶ This is its counter, shortened:²⁷

The label reads the signal directly, and the same closure that builds the button created it. The enum, the dispatch and the handler exist to carry one call to update. Vizia was never strict Elm, since its views are built once, and signals were a sensible move: it got per-field writes. But look at what remains of Elm’s reasons. State is a graph of mutable cells, Model is a bag of handles, and event is a &mut self side effect. You now have two systems for saying that something changed. So my objection to adding signals to the Elm architecture really is the same as with GPUI: they work, and they remove what you came for.

A quick note on immediate mode

egui’s pitch is the best in the field: “You don’t have to worry about app state and GUI state being out-of-sync”.²⁸ For a tool, this is hard to beat:

The price is that a frame costs the size of the UI, independent of what changed. At 3,000 rows every small edit takes about 32 ms, or about 19 ms with accessibility off. egui’s author is candid about the trade: immediate mode is “easier to use, but less powerful”.²⁸

As the application grows, the original attraction goes. The layout paradox is “a fundamental shortcoming”.²⁸ Long lists need show_rows, which takes one fixed row height. Rerun, the largest egui application I know of, clamps queries by “inspecting egui state from the previous frame”.²⁹ Anything expensive goes behind a cache keyed on your data. A cache that has to agree with your data is the synchronization problem immediate mode set out to remove, now in application code, one frame late.

One engine, different wiring

The harness can show this directly, because some frameworks can be wired coarsely and finely on the same engine:

I benchmarked some of the engines in two ways, once in the most fine grained way they can be used, and once in a coarser way. The results show how much there is to gain with fine-grained reactivity.

Two things stand out. Iced’s factor is small because the view function still runs. And Floem’s coarse case is worth a look: every cell reads one global revision signal, which is notify in signal clothing. It is the slowest result on the chart. So signals do not rescue coarse state. The React team found the same thing from the other side: on a benchmark with “one giant input”, a signals-style runtime disappointed, and Joe Savona concluded the data model “is just as important, maybe more so” than the algorithm.³⁰ The state has to be shaped like the reads. That is why I call this a state model problem. A good API should make it easy to align the data model with its UI projection.

Why run once

Suppose you accept all of that. You want the framework to track reads, and you want state shaped to match. What is the simplest API?

pub fn sidebar(threads: RwSignal<Vec<Thread>>) -> impl IntoView {
    // Runs once, when the sidebar mounts.
    let unread = Memo::new(move |_| {
        threads.with(|ts| ts.iter().filter(|t| t.unread.get()).count())
    });

    Stack::vertical((
        Label::derived(move || format!("{} unread", unread.get())),
        dyn_stack(move || threads.get(), |t| t.id, thread_row),
    ))
}

That is the whole thing. The body runs once. The closures you hand to the framework run again when something they read changes. A local variable is a local variable. There are no hook rules, no dependency arrays, no stale closures and no PartialEq on props. Nothing reconstructs a row’s identity, because the row is still there.

Compare signals with re-running components, which is Freya’s model. It works well: one keystroke at 3,000 rows costs 1.2 ms. But look at a counter:³¹

use_state exists because that line runs again. You now hold both models: read tracking decides which scope re-runs, and then re-render semantics apply inside it, with hooks, prop equality and a diff. Finer updates need smaller components, which is GPUI’s problem at a much lower price. What the re-running body buys is ordinary control flow, and that is the serious objection.

Dan Abramov makes a compelling argument.³² Run-once puts your rendering logic in closures, so top-level control flow stops working, and you group code around values and not around logic. “The beauty of React is that making things ‘computed’ is an optimization, not a requirement.” He is right about it. This compiles, but the first line never updates:

A reactive if has to become a dyn_container, and a for a dyn_stack. Solid 2.0 had to add dev warnings for top-level reads.³³

But the same comment contains the reason I land the other way. He says Solid’s regrouping is “Similar to how you have to restructure your code around the values when you optimize it with useMemo.” Exactly. If your application never needs that, React’s model may be simpler. If it does, you pay for the regrouping either way, and the only choice is when: from the start, or later under a profiler. Ryan Carniato’s reply is the one I agree with: “In Solid you always write as if the data is derived so you don’t refactor to optimize.”³² Once you know you want this precision, run-once is the API that stops pretending otherwise. The failure modes also favour it. A forgotten hole goes stale on the first update, in the place you wrote it. A forgotten notify depends on what else happened to redraw.

To be perfectly honest, the ecosystem’s wider convergence is on read tracking in general, and not on run-once specifically. Angular considered per-binding updates and chose per-view, in writing, and it lands within about 1 ms of Solid on a partial update.⁶ ³⁴ Apple and Google, who control their languages, kept re-running bodies with @Observable and Compose.³⁵ ³⁶ A hole is itself a re-run scope, so what differs is how big the default scope is. Two things I want to note on this though:

First, those systems pay for their larger scopes with a compiler. Compose has a compiler plugin, Angular compiles templates, and React’s compiler is the serious rival to everything here: it keeps React’s API and removes many needless re-renders, with loads up to 12% better.³⁷ For Rust, I suspect that most people that prefer immediate mode or elm (or whatever GPUI is) would not like the idea of an additional compiler. A proc macro only sees tokens, not types, and render is an arbitrary function, so there is no pass that can split it into scopes. What Rust can express cheaply is a closure.
Second, their own guidance keeps describing the same problem: “Defer reads as long as possible” for Compose, and “Unnecessary view body updates can really add up” for SwiftUI.³⁸ ³⁹ A framework that runs the body once removes that category at component level.

View-level rerun and fine-grained signals can have the same performance ceiling. But signals encourage fine-grained state projections and memoization from the beginning, for view-level rerun its an explicit choice that often leads to more boilerplate.

Signals do not automatically make your app fast

Fine-grained reactivity does not make an app fast on its own.

Floem’s reactivity does exactly what it promises. Changing a label runs 5 effects and spends 0.01 ms in reactive work, then about 14 ms in layout, because Taffy does not know that one leaf moved. (Floem also has a known bug where that edit never repaints, so treat this as a floor.) Vizia runs 4 bindings, then walks all 120,091 entities, for 46 ms. Slint writes an equal value in 4 µs, and takes 172 ms for a label, in a pass that walks about 30,000 items. Freya produces 5 mutations, then visits 57,050 layout nodes to recompute 14. GPUI beats most of them on this edit.

This is the distinction the argument depends on. All of those linear costs are in the engine respectively. Nothing in the application’s code requires them, so they can be fixed behind the same API without changing an application. zgui shows how far that goes: 0.69 ms for the label at 3,000 rows and about 0.26 ms per 1,000 rows, around 12 times flatter than GPUI. It is still not flat, and it is my framework and was tuned on this harness, so take these numbers with a grain of salt. In Iced and egui the linear cost is in the contract: the API says your code runs. No engine work can remove that, and app code has to change. GPUI probably sits somewhere in between, which is why gpui-fast can improve the situation to some extent.

At this point, I wan’t to share a more detailed benchmark matrix. Read the re-running columns down the first five rows and they barely move, because they do not depend on the edit. The signal columns move a lot, because the underlying implementations differ.

The bottom of that grid is also where the cost signals have becomes visible.

Creation. Filtering at 3,000 live rows takes 56 ms in Iced, 67 in egui and 123 in GPUI, against 371 in zgui, 835 in Floem and 982 in Freya. On a virtualized list it is 1.0 ms in Iced and 7.2 in zgui. “Setting up the dependency graph is not free.”⁶
Memory. Resident memory usage for large scenes is generally higher the more a framework retains.
Effects. Facebook moved away from two-way binding because “cascading updates” became hard to predict.⁴⁰ That history is true, and Angular’s docs still say “Effects should be the last API you reach for.”⁴¹ Modern graphs are glitch-free. Careless effects are still difficult to reason about and quickly result in feedback loops or similar stuff.
Rust. Signals rely on arena handles and move closures. Levien thinks such patterns “adapt poorly to Rust”.³ I think they adapt well enough, and GPUI’s entities are arena handles too, but, admittedly, it is not a free lunch.

Conclusion

GPUI makes a full frame realitively cheap, and that makes it probably good enough for many use-cases. It is certainly enough for an editor whose expensive surface is handled by hand. For a large application it leaves a choice: keep the API people like and pay per view, or get precision by writing a signal graph out of entities. Elm and immediate mode have the same problem. Each is clearest in the small, and each loses the thing it was chosen for as precision becomes necessary, and, from my personal experience, that happens faster than people expect.

Tracked reads are where most of the field has ended up, whatever it started from. If that is where we are going, I think we should start there, and make the component a function that runs once.

Method

Numbers are medians of apply and settle from my unpublished harness, on one machine: i9-13900K, RTX 3080 Ti, Vulkan, Linux. Windows, compositor and input are not included. Frameworks’ maintainers have not reviewed the adapters.
GPUI is at ddc9eda925 and gpui-fast at 86a8228229. zgui is at 082337db. These were through September and November 2026, as the best of three passes.
Cells marked † in the grid failed their correctness oracle: Floem’s label and keystroke edits, as noted above, and Slint’s font size. Every other charted cell passed.
The 60-panel results are gpui-fast’s retained_bench with my additions, in test mode, so no GPU work is included. Retention off there is still gpui-fast.
Figures from Zed’s plan are its authors’, from experimental branches.
Rust examples were type-checked against the vendored frameworks. Vizia’s and Freya’s come from their own sources, shortened.

References

Stanislav Vishnevskiy (Discord CTO), post on X, 2026-11-04.

zed#46758, gpui: Remove blade, reimplement linux renderer with wgpu, merged 2026-02-13.

Raph Levien, Xilem: an architecture for UI in Rust, 2022-05-07.

⁴

GPUI README, commit ddc9eda925.

⁵

GPUI source, commit ddc9eda925: crates/gpui/src/app/context.rs:216.

⁶

Angular, Sub-RFC 1: Signals for Angular Reactivity, 2023-04-03.

⁷

zed#63800, gpui: Incremental view rendering with a view tree, draft, closed 2026-09-24.

⁸

crates/gpui/docs/retained_extraction_plan.md, Zed branch gpui-retained-plan, commit 312a04c83, 2026-10-30.

⁹

gpui-fast README, Longbridge, commit 86a8228229.

¹⁰

Redux Style Guide.

¹¹

MobX, Optimizing React component rendering.

¹²

crates/gpui/docs/view_tree.md, Zed branch gpui-retained-node-engine, commit c15d4b8e4b.

¹³

Richard Feldman on The Changelog #319, 2018-10-17.

¹⁴

Michael Murphy (System76), Hacker News comment, 2024-04-25.

¹⁵

An Elm guide, Structure, webapps chapter.

¹⁶

Iced source, commit 8b8e6198: src/lib.rs, Scaling Applications.

¹⁷

Héctor Ramón, iced#995, 2021-09-13.

¹⁸

cosmic-files at 3868a8e: src/app.rs and src/tab.rs. Counts are approximate.

¹⁹

Evan Czaplicki, The Perfect Bug Report, 2016-11-14.

²⁰

Redux, Normalizing State Shape.

²¹

Redux, Deriving Data with Selectors.

²²

Redux, Why Redux Toolkit is How To Use Redux Today.

²³

Svelte team, Introducing runes, 2023-09-20.

²⁴

Legend-State, Fine-grained reactivity.

²⁵

Iced source, commit 8b8e6198: examples/lazy/src/main.rs, lines 12, 127-143, 155.

²⁶

Vizia, Migration Guide: Lens-Based State to Signals, commit 426d2e7b.

²⁷

Vizia, examples/7GUIs/counter.rs, commit 426d2e7b.

²⁸

egui README, commit 7809b4fd9a.

²⁹

rerun#7562, 2024-10-02.

³⁰

Joe Savona, Exploring React Performance, React Conf 2025.

³¹

Freya, crates/freya/src/_docs/state_management.rs, commit bf825f73.

³²

Dan Abramov and Ryan Carniato, comments on React vs Signals: 10 Years Later, 2023-03-01.

³³

Solid 2.0 beta notes, 2026-03-03.

³⁴

js-framework-benchmark, results of 2026-11-02, partial update. Fixture is a flat list.

³⁵

Apple, Discover Observation in SwiftUI, WWDC23.

³⁶

Android Developers, Lifecycle of composables.

³⁷

React Compiler v1.0, 2025-10-07.

³⁸

Android Developers, Compose performance best practices.

³⁹

Apple, Optimize SwiftUI performance with Instruments, WWDC25.

⁴⁰

Facebook, Flux in-depth overview (archived).

⁴¹

Angular, Effects guide.

The Web Is More Than Enough, by Paul Ford (Ftrain)

Sun, 08 Nov 2026 22:54:54 +0000

You can have it all, my empire of alert().

Last week was fun. We launched tinylittleoffice.com—you heard it here first!—and it turned out that lots of folks were in the market for an “office suite that stores data in the URL.”

So many people visited that the server went down (well, I maxxed out the CloudFlare free plan), and ultimately, after I put in my credit card, a couple hundred thousand people came by to check it out. People on Hacker News insisted it was a pointless waste of time, and folks on GitHub started asking for features and fixes, all of which we’re considering, and some of which we’re doing. The Register wrote an article about it, and it also made it, for a little while, to the top ten of Product Hunt.

So all good; we will continue to support and enhance it, bit by bit, while we also do stable software development work for our customers and clients. But I did want to pause for a second and point out something that surprised me about the process. It’s this:

The web browser is very, very, very powerful software for building applications.

I know that is obvious and is the sort of thing I could have said any time in the last 20 years. But now there’s an addendum to the statement:

The web browser is very, very, very powerful software for applications, and the cost of accessing that power is going down seemingly every day.

I put maybe twice as much effort into building a web-based office suite as I might normally put into writing a long newsletter post. I’m not telling you this because I am a very special boy. I’m telling you because if you want to, you can learn to do it, too.

Fast, cheap, good, right? But even after I had to put in my credit card, CloudFlare hosting costs…$0. Partly because I optimize for cheapness, but partly because that’s just how it goes these days. Fast? Dear God, computers are fast, and software development is also fast compared to the past. But as I code web apps, I keep finding new corners of the browser I didn’t know well. Things are just…wild in there.

The Web Crypto API is a first-class security platform in the browser.
The Web Assembly platform lets you run native-speed code in your browser.
WebGL provides for high-quality 3D and 2D graphics in your browser.
The Web Audio API lets you mix sound in your browser.

And on and on. The web is really the greatest distribution platform imaginable right now. It’s inherently multilingual—I released TinyLittleOffice in 21 languages (the most common NYC ones, which is why it has Creole and Yiddish), with lots of infrastructure for accessibility. Plus, of course, JavaScript is a full-featured programming language, and HTML can represent most things a document can do on a computer; if you need something more old-school, PDF.js lets you deal with PDFs in the browser. I think you can even hyphenate text reliably these days, although I refuse to believe it.

I knew these things existed. I’d even programmed with them. But I’d never really looked closely; I just downloaded whatever open-source code would make it easier to build and tried to drag software across the finish line.

My quirky 1990s-vintage office suite might not convince you—it’s weird and small. So take a look at Simon Willison’s new web-based browser 3D game, Battle Drones. He’s hosting it on GitHub. He wrote it himself. He’s not a games builder. It just pops right up in the browser and you play it. It’s multiplayer, and it works offline.

Time to place your Fab Plant.

As he wrote about it:

… but I can now see a path to vibe coded games like this being taken seriously. Battle Drones is fun, it looks good, it has innovative features (the multiplayer-over-audio thing is a first for an RTS as far as I can tell). I’d love to see what someone with better taste than me and a driving passion to produce something truly exceptional could build!

All the various cool browser technologies have been around for years. But they are each extremely vast. If you get good at Web Audio, you probably don’t have time to get good at Web Crypto and Web Assembly and WebGL.

The reason they were so complex is, basically, because they were built for teams like those at Google, not for individuals. In the past, the web was for people to build web pages—and, yes, in the present, you can still do that, but for more than a decade, the web has been designed for giant companies so they can deliver software securely to billions of people who buy things with credit cards. These huge mega-libraries were dropped into the web browser to enable large teams to build big things, and the little guy was a bit of an afterthought. But now you can make a game in 3D with sound, and it can work just fine on a plane.

This is one of the places where “are we in an AI bubble” gets fuzzy for me, because it’s totally clear all these giant AI companies are huffing AGI paint fumes, but at the same time, if we actually unlocked the economic transformation of, say, 100 times as many people making software for each other, that would blow an enormous crater into the current tech economy. Don’t like the way your giant industrial looms make carpet? Hack your own firmware and make each carpet totally personalized! Turn any Instagram post into a huge floor covering! Suddenly all the carpet companies have to hack their own firmware to compete. What’s that going to be like?

This also destabilizes the app store economy. The high tax of building for app stores seems less worth paying when you can just test an idea in the world from a web server for $0 after a couple weeks. Perhaps Mozilla should take another swing at launching a mobile phone! (Forget I mentioned that.) In any case, what used to be a large industrial process is now a personal one, if you so desire. Web browsers enable incredibly rich app development—and that’s radically easier than it used to be.

It’s a mixed blessing. I’ve been a writer for years, and software development feels more and more like writing to me every passing week. The awkward part of the comparison is, in general, people do not want to pay writers any money at all. As a writer, you get used to it. But for software people, being perpetually devalued is pretty novel. Then again, if you need software to do something—like our clients!—say, to fix a process, organize a database, get more value out of a big piece of industrial equipment, it’s a pretty amazing time, because you can do just about anything. I’m pretty confident we’ll all meet in the middle, but it’ll take a while, and it will be different on the other side.

被高估的「行胜于言」 – So!azy

Sun, 08 Nov 2026 18:09:20 +0000

被高估的「行胜于言」

07 Nov, 2026

前两天和一位朋友吃饭，席间她跟我倒了一肚子苦水。

前阵子她手头有个跨部门协作的项目，推进过程中出了点岔子。她属于那种典型的实干派，发现问题后没在群里多废话，自己连着熬了 2 个通宵，把缺口的数据一点点补齐，赶在节点前把方案救了回来。但在那几天里，面对合作方在群里的频频追问，正在气头上的她只冷冰冰地回了一句「在改了，催也没用」。反倒是项目组里另一个平时素来擅长摸鱼的同事，全程没改过一行字，却每天早晚 2 次在群里发长段文字，态度极其诚恳地向合作方同步「我们非常重视」「已经在通宵抢进度」「一定给各位一个满意的交代」。

等项目顺利上线后，合作方的负责人在复盘会上公开致谢，话里话外都在夸那个摸鱼的同事靠谱、有担当、沟通体验极佳；轮到我这位朋友时，对方只是客套地点了点头，会后还私下跟她领导委婉地提了一嘴，说她脾气有点冲、配合度不够高。

听她吐槽完，我拿着筷子愣了一会儿。要是放在 1 年前，我大概会跟着她一起骂合作方眼瞎、分不清大小王。毕竟她才是那个真正把雷排掉的人，而那个同事除了动动嘴皮子，实质性的贡献几乎为 0。

我最早在博客写《渣男理论》那篇文章时，核心观点就是劝大家在人际交往中做成本核算：不要看一个人嘴上说了什么，因为甜言蜜语、陪伴感和口头承诺的边际成本极低；你要看他实际做了什么，看他在需要付出真实的时间、资源和责任时，有没有往后缩。后来在[《渣男理论 II》里我也聊过类似的延伸，就是警惕那些用廉价的「你真厉害」来敷衍你、却不肯花心思理解你真实观点的低成本沟通。

那套逻辑在客观事实上依然成立。但我最近越来越意识到，当时我漏掉了一个更残酷的现实前提：真正能够跳过语言、直接去审视行为成本的人，在现实里少之又少。

又或者说，这根本就不是一个人「能不能认知到」的问题，而是人际关系在运转时，天然就有一套先后顺序。在绝大多数日常交往和协作里，人们真正先看到的、先接收到的，永远是一个人「说了什么」。至于他「做了什么」，往往需要漫长的时间周期、极高的观察成本，甚至要等到某次合作彻底崩盘之后，才会被大家后知后觉地意识到一个人到底做得到什么、做不到什么。

我后来仔细想了想为什么会这样。其实原因没那么复杂，做一件事，它的过程是隐蔽的、滞后的、也是没有声音的。就像我那位朋友在电脑前熬夜补数据，合作方看不见她凌晨 3 点还亮着的屏幕，也看不见她推翻重来的那几版草稿。在最终结果交付之前，「做」在别人的视野里几乎处于隐身状态。对方唯一能感知到的触点，就是微信群里那个冷冰冰的对话框。

但「说」不一样。语言是即时的、高颗粒度的、也是自带情绪温度的。人际交往在最初的 80% 时间里，本质上不是价值的交换，而是确定感的交换。当一个人在事情还没着落的时候，先通过语言把态度端出来、把别人的焦虑安抚好、把预期管理住，他在对方心里就已经率先完成了「靠谱」的建档。哪怕他后面实际只做到了 50 分，别人也会顺着他前面立下的好印象，自动帮他找补剩下的 50 分。

反过来，如果你死守着「行胜于言」的信条，闷头把事情做到 90 分，但在嘴上给人喂了颗钉子，那别人第一时间接收到的信号就是冒犯和失控。在你的工作成果展现出来之前，关系就已经先一步结冰了。等到关系冷掉之后，你后来交出来的那份 90 分答卷，在对方眼里也不过是「本来就该交付的分内事」，甚至连挽回印象的筹码都算不上。

所以人际交往里有一条非常反常识的逻辑：决定一段关系走向的，不是你做了什么，而是你说了什么。

想明白这一点之后，我并没有因此觉得那种「纯靠嘴皮子邀功」的做法值得学习。在需要长期深度绑定的关系里，只说不做的人迟早会露馅，依然是第一个该被筛选掉的对象。但在大量的日常协作与浅层社交中，我不再像以前那样，带着一种近似道德洁癖的优越感去鄙视「把话说好听」这件事了。

以前我总觉得，把精力花在修饰语言、安抚对方情绪上是一种低效的妥协，只要我活儿干得漂亮，别人自然应该理解我的苦心。现在回头看，这种想法其实挺傲慢的。你不能一边在嘴上拒绝释放友好的信号，一边又要求别人像全知全能的上帝一样，越过你生硬的态度去精准识别你的付出。别人和你认识才几天，没有义务花那么高的时间成本来拆解你的「刀子嘴豆腐心」。

如果「先听人说什么，再慢吞吞地看人做什么」就是人类社交出厂自带的运行机制，那跟这个机制死磕就是最吃力不讨好的做法。

那天饭局最后，我给朋友的建议也很简单：下次再遇到这种事，活儿照样按自己的高标准干，但在群里回消息之前，先把那句「催也没用」删掉，换成「问题已经定位到了，正在补数据，明天上午 10 点前发你新版本」。不需要去演什么热泪盈眶的戏码，但至少得让对方通过你说的字，第一时间听出你是个打算解决问题的人。

把事做好，是留给时间去检验的底牌；但把话说对，你才有机会坐到时间揭晓底牌的那一刻。

#daily

The web used to belong somewhere – Manu

Sun, 08 Nov 2026 17:48:10 +0000

The web used to belong somewhere

There are a couple of related ideas I found myself writing about here and there, either on the IRC server or on Quxnet. Ideas and thoughts about what the web used to be, how it used to feel, about how things have changed, and what can be done to bring at least some of the old web back.

We often point fingers at the big social media platforms, with their relentless algorithmic curation as the cause for the awfulness of the modern web. Maybe we blame the SEO folks, or the influencers. There’s a multitude of different characters who each played their role in turning the “old web” into “today’s web”. And I’m not going to pretend they didn’t play a role, because they did.

What I am going to argue for, though, is that there’s something else that has contributed a lot more to the changes that we’ve seen over the past few decades, and that’s the fact that the web used to belong somewhere. And I mean that in the physical sense. I’m not the first one to say this; you can find plenty of other posts out there making this exact point. But it’s a point worth repeating.

There was a time when in order to go online you had to physically go to a specific place: a desk in the house, an internet cafe, a computer lab. The web wasn’t always with you, and you were not always in it and with it. You had to go somewhere, do what you needed to do, and then leave.

BRB? AFK? Acronyms from what feels like a distant past. You are never away from the keyboard today, because there’s a phone following you around everywhere all the time. The internet feels exhausting these days because it’s always there. It’s become what feels like an inescapable presence, for better or for worse.

I’ve been particularly unhappy over the past few weeks, for a variety of reasons. And one thing I noticed is that every time I’m in a down phase of life, I can go look at my phone usage and it’s inevitably higher than it should be. At least for me, there’s a 1:1 correlation between how good I feel and how much of a presence the phone is in my life. And the phone is just a proxy for the web because browsing is 95% of what I do on my phone, since I don’t game and I don’t have social apps.

And that’s quite ironic considering I make websites for a living. I build for the web, and at the same time, spending more time than necessary on it makes me terribly unhappy.

But it feels different when I can leave the web behind, when I can get up from my chair, leave my desk, and the web is no longer with me. That feels healthier. The problem is that most of the world doesn’t work that way anymore. If you leave and come back, you’ll probably have a hard time catching up with everything that has happened while you were away because everybody else is not taking a break. And so even if we managed somehow to get rid of algorithmic curation and infinite scrolls and all those things, the web would still not feel like the “old web”. Because the web used to belong to a place. It sadly doesn’t anymore.

The Military Triumphal Arch

Sat, 07 Nov 2026 10:54:27 +0000

An American Vision
Finally Realized

A Monument To The American Spirit

For 250 years, Americans have triumphed over war, division, and hardship. Against impossible odds, our people have built a land of liberty where the individual citizen can thrive, prosper, and pursue happiness greater than any other place in the world.

The United States Military Triumphal Arch celebrates America's first 250 years and stands as a symbol of its next 250. It serves as a solemn entrance to Arlington National Cemetery, honoring the heroes who gave their lives for our freedom, and as a grand gateway to the capital of the nation that has been, and will forever be, the greatest force for freedom and goodness in the history of the world.

A monumental gateway to the nation’s capital

An American Vision
Finally Realized

A century ago, America envisioned a monument to reconciliation and national unity following the Civil War.

In 1924, the Arlington Memorial Bridge Commission proposed two monumental columns in Memorial Circle, crowned by figures of Victory. One represented the North. The other represented the South. But the columns were never built.

Today, President Donald J. Trump fulfills and expands on this historic civic vision: what began as a celebration of the reconciliation between North and South finds new expression as a celebration of the triumph of the American spirit throughout the full sweep of American history.

The Military Triumphal Arch realizes a century-old ambition for beautiful monumental architecture in Memorial Circle. While such a grand monument was planned and dreamed of by all of America, it was a Dream that never got built because of the onset of the Great Depression of 1929 — But it will get built now.

The Military Triumphal Arch will be an enduring symbol of American Freedom, American Strength, and American Unity. We will fulfill the aspirations of the Great American Patriots who came before us, and whose plans and visions will finally be realized with the start of construction in our 250th year.

A Tribute To Our Heroes

From the Lincoln Memorial, across Arlington Memorial Bridge, to the hallowed grounds of Arlington National Cemetery, an extraordinary ceremonial axis connects the ideals of the American Republic engraved in stone —with the heroes who fought and died to defend them.

The Military Triumphal Arch honors all who have served our country. It will inspire future generations to build an America worthy of their sacrifice.

View on map

“This will be the greatest and most beautiful triumphal arch, anywhere in the world.”

Donald J. Trump
45th & 47th President of the United States

The Future Begins
With a Step

Great nations remember. Great nations also imagine the possibilities of the future.

The Military Triumphal Arch will honor those who founded, built, defended, and transformed this country, while inspiring new generations to carry forward the American promise.

For centuries to come, Americans will walk beneath this monument with our nation’s history behind them and its future before them, remembering the extraordinary nation they inherited and celebrating the freedom they will pass on.

Lippitt-Knoster in Practice (Field Notes for Managing Complex Projects)

Fri, 06 Nov 2026 17:05:58 +0000

"Lippitt-Knoster" is one of those things where if you've worked with me during the last 10 years, you've likely heard me mention it. You might even be reading this because I needed somewhere to point you. In which case, Hi! 👋

The Lippitt-Knoster Model for Managing Complex Change was originally written to describe a way of navigating large organizational shifts, but I’ve found that it’s also useful as a diagnosis tool for any kind of large and long-running project. After all, every project is a "change" in a microcosm. You might not have a complex organizational change to manage every day, but everyone is involved in long-running projects of some size and shape in a company. So that’s what I use it for, and it is useful indeed.

The beauty of the model is that you don’t need an MBA or a special issue of the Harvard Business Review to explain it. It says that any complex project requires six components to succeed, and if one or another is missing, you’ll have some specific and corresponding failure.

It can be summed up in a simple chart but also rewards you with some deeper insights as you apply it:

Vision is the purpose and endpoint of a project. Vision tells you where you’re going and why. If the vision is missing, there will be confusion about what is being done and why work is happening.
Consensus is a team's agreement and alignment around the vision. If a team lacks consensus, people will not want to do the thing and they will sabotage you.
Incentives are the motivation or reasons for why people support the work and prioritize it appropriately. If not everyone is incentivized properly, there will be resistance. Resistance is the passive sibling of sabotage.
The Action Plan is the practical set of steps to get from vision to finish. If you lack an action plan, your team will experience a routine set of false starts and treadmills, which is another way of saying that it will look like work is happening but nothing actually moves forward. You won’t make progress.
Resources are the organizational capacity (people, budget, time) needed to accomplish the work. Lacking resources is a close cousin to lacking skills; it leads to frustration in trying to do something you know you're capable of, but with an unrealistic set of operating constraints.
Skills are the ability to do the work necessary to complete the project. If a team lacks the necessary skills, you'll have a lot of questions around if this work is possible, leading to anxiety.

Vision, consensus, and incentives are all Strategic Concerns. They involve abstract political work: ideas, relationships, people, and an understanding of the business. The action plan, skills, and resources are all Tactical Concerns. They are focused on the practical details of “how” something gets done.¹

One mistake I often see people make is to focus primarily on one concern or the other. For example, a product manager or corporate strategist might spend too much time focused on the strategic side of things without understanding if the team or company is able to execute. Consequently, their ability to build consensus will be negatively impacted by not knowing what is possible or probable. Line managers and software engineers typically make the opposite mistake. They focus too much on the ‘how’ instead of the ‘why’. They’ll prove that something is possible and how it can be done, without realizing that sometimes the team or business doesn't want to do the thing they’re proposing. Neither myopia ends in a successful project.

The order of the model components matters – they flow into each other – but can be managed in either direction. For example: you might start with a vision, build consensus, arrange the right incentives for everyone to act, create a plan, provide adequate resources and timeline to accomplish that plan, and make sure it is staffed with people who have the skills to execute on it. Easy peasy!

You could also navigate the components the other way, working through a series of questions: is something possible? Do skills exist to accomplish the thing? Do those skills (people) have excess capacity that can be allocated to this idea? Can it be done without budget? Can that group of people be small enough that they organically develop their own plans? And if so, are they incentivized to take on this kind of work outside their daily responsibilities? Does it need sign-off from anyone? If you’ve found confirmatory answers along the way, congratulations: you can carve out a secret R&D initiative within your team or your company. (This is also 'effectuation' in practice.)

You can also read the model from the perspectives of both cause and effect. Reading it one way creates a checklist before kicking off any major work: “Here are the six prerequisites for success, are we all set?” (A causal, prescriptive reading – given starting parameters, what will be the end result?) Reading it backwards turns it into a troubleshooting tool. For example, if someone comes to you mid-project complaining that "We keep going in circles and the team is anxious! What can I do?" you might look at the model and respond, "Well of course! You don't have an action plan. Or maybe, it hasn't been adequately distributed and communicated and people feel that they lack the skills to accomplish something so big. Let's break it down into manageable pieces that we do have the skills for." It’s pretty quick to go between looking at the failure states and looking at the necessary components to diagnose what’s going on with a project. (A diagnostic reading, reasoning backwards.)

The model is a fantastic tool for making sense of things. But that leaves the hard work to start after you've made sense of things. How do you drive consensus? How do you align folks around a vision? How do you build up skills, or break down big projects into smaller pieces for which skills exist? How do you win resources, or align incentives?

Some of those answers are obvious, but most are not. Many of the answers are best understood as the manifestation of tacit expertise — a ‘feeling’ for the right move in any particular context, a form of expertise that comes from having been around the block a few times.

And like with most tacit expertise, you’ll find that there are no one-size-fits-all answers to any scenario, but there are plenty of good practices and useful observations.

So here are some of mine:

Strategic Concerns

The most common and important questions that come up after someone lays out a vision are “Why should we do this?” and permutations around the follow-up details. If you see those questions, that’s “confusion”, which is another way of saying you’ve presented a fantasy instead of a vision (or perhaps, the vision is missing entirely). That’s because many people confuse vision for having a colorful and inspiring imagination, making their picture too colorful, unrealistically grand, or too far off.²

My experience is that you make more progress by simply providing adequate context and letting people derive their own vision. The art of context is giving people breadcrumbs to get from where you are today to where you want to be in the future, and giving them some good reasons to follow those breadcrumbs with you. There’s nothing more effective than a self-motivated team that thinks they’re the ones who came up with the idea, that they saw what things could be like. That’s vision.

Similarly, consensus is a straightforward concept, but strangely elusive in most organizations. Any organization beyond a certain age and size will typically have a 'minimally viable consensus' while practically being at odds with itself. Departments often turn into silos with their own internal logic for what should happen. Job security encourages teams to think about what’s best for them instead of for the company. And companies don’t do a great job tying “what’s best for the company” with “what’s best for the individuals within, or the communities around”,³ which makes most employment mercenary: people naturally find a balance between what they’re paid and how much to care about the thing in question. (In that sense, incorporated businesses are kind of like democracy: a bad choice, but among the best of the options available for coordinating large groups of people to accomplish things.)

Recognizing that, one amateur mistake people make is trying to build consensus in a group setting. It just doesn't happen that way. You’re either going to have everyone nodding along and afraid to say their piece in front of everyone else, or you’re going to have one guy (and it’s usually a guy – sorry, my dudes) start pulling some “what about”-ism and dragging the conversation into a black hole of details that you never intended to argue about but find yourself frustratingly debating anyway.

In either scenario, the meeting will end without consensus.

In Japanese business culture there is a concept called “nemawashi”, which translates roughly to “tending to the roots” or “laying the groundwork”. It’s a good analogy because the practice of creating consensus requires a lot of political skill, footwork, trust-building, and private conversation. It means giving people space to tell you everything that’s wrong with your idea, finding ways to address those concerns, and making sure everyone is aligned before the alignment actually happens. The group meeting when everyone signs off in agreement should be the result of careful stage management — you should know and have already addressed everyone’s concerns, including second-order effects of how addressing one person’s issues will impact others.

There should be no surprises; it is theater, not improv.

That said, you might not be able to get to consensus. Perhaps your boss wants the “thing” to happen but there’s another department that’s actively against it. Maybe you're encroaching on their turf, or it will reduce their capacity in some zero-sum resource bucket. Maybe they just have a different perspective on the world and the approaches the business should take. Maybe you've wandered into a long-running feud and this project is just one of many different battles being waged. Who knows, people can be both petty and complicated!

If you can't get their buy-in, they will sabotage it in all sorts of creative ways. Because sabotage and resistance are close cousins and are political (in the sense of not being open conflict), monographs on activism and subterfuge can be read as useful primers. Consider James C. Scott's Weapons of the Weak and the OSS's Simple Sabotage Field Manual for what kinds of foot dragging, malicious compliance, noncompliance, evasion, sowing confusion, slander, useless meetings, arbitrary hurdles, revisiting decisions, and moving goalposts to expect.

My advice for these scenarios is to try one of two things. Your first option is to get to the bottom of why there is no consensus and figure out if you’re in a position to address that root cause. Often, you’re not in a position to address those things; if you pursue resolution, you’re going to use up a lot of your political capital or burn out trying to get the project moving forward. And success can be fleeting – projects can continue to be sabotaged even after launch. I once had a project launch only to have all of its resources immediately pulled, forcing its premature death.

Not even chief executives are immune to this; sometimes the solution to a lack of consensus and active sabotage is to simply fire the people in disagreement. (Obviously, use this technique sparingly — you’re scorching the earth.)

So I recommend most people take the second approach, which is to just drop it. Move on. It’s a lost cause. Don’t be the sailor with a bucket trying to dump water off this Titanic. Quitting things and dropping things is a totally acceptable thing to do; life isn’t a video game where you’re striving for 100% completeness on every side quest. Move on to things where you’re actually making a difference.

But let’s say everyone agrees. Now you need to make sure that things are prioritized appropriately. You’re not going to make any progress if this is low on everyone’s priority list. So you incentivize teams and people.

Positive incentives typically work better than negative incentives, but most people are not in a position to offer meaningful (financial) incentives to push a project forward. Instead, you can rely on horse-trading (“if you help me move this project forward, I’ll help with your thing”), you can help people resolve their problems, and you can paint a compelling-enough end-state that people also want to reach that goal with you.

Otherwise, people are going to be resistant, which is a passive form of sabotage: sabotage without commitment, or general apathy. It might not even be malicious. It’s just… well, you’re just one more project for people to care about and work on. Why should they do it above all else?

And more importantly, resistance can turn into sabotage when incentives are not just missing, but misaligned. Misaligned incentives can break consensus when you're sweating the details.

Tactical Concerns

Now, let’s say you figured out the strategic bits and you’re working through the implementation portion. Some projects are simple enough that you can just describe what needs to be done, and you can count those requirements on a single maimed hand. We’re not talking about those projects.

Any complex-enough project requires coordination of requirements, dependencies, timelines, people, and other details. I’ve written a bit about those issues in “When Everything is Important But Nothing Is Getting Done”, so I don’t want to retread too much ground.

But one thing worth highlighting is how skills and anxiety are coupled, and how to navigate a lack of skills. Any ambitious project is at some point going to run into a lack of skills or prior experience because the work wouldn't be ambitious if you'd done it before. So in many regards, it is an existential question for any project: are you and your team able to do what needs to be done? If not, you’ll get a very stressed team, or you’ll get a simulacrum of what you expected.

There are ways to compensate for a lack of skills. I rely on three techniques:

First is up-skilling people. Education, mentorship, and training are effective ways to turn juniors into seniors, low-skilled employees into high-skilled employees. While there are a variety of documented techniques for this (see: accelerated expertise, tactical decision games), the caveats are that (a) this typically takes longer than the time-span of a single project and (b) you need to find people who are interested in learning.

So the second technique is atomization: break the requirements into smaller pieces that meet the level of skill available rather than trying to get people to rise to the required level. Instead of making everyone work harder, just make the requirements easier. Instead of asking people to “cut database reads by 50%” or “create a capacity forecasting model for the next 12 months” (where they may not even know where to start), give them smaller tasks and directions for what to do to accomplish that. Point folks in the right direction, explain the what and the why, turn big asks into a series of steps, a recipe to accomplish something. This is in itself a form of teaching, and it is more project-sized (see what I did there?).

The third technique is to roll up your sleeves and contribute. I’ve learned from many effective leaders that there is no work below your pay grade. What makes many great leaders "great" is their willingness to spend extra time doing “glue” work, filling in the holes between roles, and making sure all assumptions are bridged back to real expectations. They are never too good to personally write up a project document, to manage a tracker, to make sure that people are talking to each other. They often know as much or more about the details than subject matter experts, but they don't needlessly meddle – they support where needed and use gaps as up-skilling opportunities.

Much of the work of compensating for skills gaps is directly translatable into managing budget, time, and effort tradeoffs to navigate the “resources” component of Lippitt-Knoster. And your ability to solve for skills and resources directly translates back into the specific action plan you need to put together. For example: you may decide not to spend $100,000 on a vendor because you can reverse engineer a single feature you need for a project, but you need to add time to the plan for that.

These considerations become a calculus of risks, rewards, and effort, which in turn underpins the strategic portions that we talked about earlier: sure, you might think you can lead a team to rebuild the hot new vendor in house in two months, but have you earned organizational political capital to place those chips on the table?

So there you have it, Lippitt-Knoster in practice. Lead on!

^{1 - This grouping is not present in most Lippitt-Knoster model descriptions I’ve come across; it is my own humble contribution. The order I'm presenting it in is also my contribution – the order in Mary Lippit's original 1987 model is quite different, for reasons I couldn't discern.}

^{2 - A realistic vision that is too far into the future is its own type of risk – every day presents new opportunities for conditions to change, starting conditions to be led astray. The likelihood of any far-off future has too many compounding variables... too many things have to go right and be true for it to be reliable enough to pin your hopes to.}

^{3 - These things are usually at odds with each other. There's a big literature about how "equity" is a tool to get employees to care about corporate success, but most startup equity goes to zero; for the average employee, a bonus or a pay raise is more useful. Public company equity presents a different issue: it is dependent on public market behavior, and less on your individual ability to impact it – being in a public company, you're likely one of thousands-plus of employees.}

Thanks for reading

Useful? Interesting? Have something to add? Shoot me a note at roman@sharedphysics.com. I love getting email and chatting with readers.

You can also sign up for irregular emails and RSS updates when I post something new.

Who am I?

I'm Roman Kudryashov -- I help healthcare companies solve challenging problems through software development and process design. My longer background is here and I keep track of some of my side projects here.

Stay true,
Roman

"People Don't Want To Work Anymore"... duh? – Absurd Pirate's Internet Blog

Fri, 06 Nov 2026 17:05:58 +0000

"People Don't Want To Work Anymore"... duh?

03 Nov, 2026

"People don't want to work anymore" is a dead horse that's been beaten to the point of glue. Usually uttered by boomer, petite-bourgeoise types who can't wrap their senile brains around why people don't want to work at their shitty Arby's franchise for $7.50/hr in an area where cost of living requires $15/hr.

People who are indignant about people not being employed have got a neoliberal brain worm eating at their frontal lobe. "People don't want to work anymore", yeah no shit dude, you just figured that out? Hell I highly doubt YOU even want to work.

This pride in a P-O-S J-O-B for the sake of having one, is a relatively new and invasive concept. For many human societies in history, work was something to avoid where possible. I came across this video from the channel "The Visual Philosopher" and while most of the video talks about how different cultures talked about a life well-spent, I want to focus on the relationship to labor for the sake of this post.

For all the masturbation shit-lipped conservatives do on the ancient Greeks, they're like the OGs in not wanting to work. Xenophon once said something along the lines of "the manual jobs are scorned and held in low esteem. They ruin the bodies of those who work in them and those who oversee them, forcing them to sit still and remain indoors. Making their bodies soft and their souls weaker". The word 'banausic' meaning mechanical came from the Greek word 'banausos', a derogatory term for laborers. Take an ancient Greek into modern society, and they'd wonder why we turned being wage slaves into a virtue in much of our culture.

There's the four aims in Hinduism, Dharma (duty), Artha (wealth), Kama (pleasure/joy), and Moksha (liberation). The 4 meant to be kept in balance, however Artha has much overtaken our society. "Stone Age Economics" by Marshall Sahlins spoke of hunter-gatherer societies and how they seemingly worked less than we do. And it would make sense, you only had to do so much to meet your basic needs, so the rest of your day can be allocated to whatever you want. It shifted once we had to start working for a wage to afford our basic needs rather than meeting them ourselves alongside our tribe.

Not everyone needs to work, hell I'd argue not everyone should work. Work is something that should be a public service because you want to fill a need in your community. People who can doing for people who can't. You work because of intrinsic motivation. The plumber isn't indignant against the people who can't/doesn't do their own plumbing. So why is the modern worker indignant against the person who doesn't work?

We look at the people who don't work like there's something wrong with them, but in all actuality, I think it's a form of jealousy. Because if you get people to say they quiet part out loud, they'd admit they'd love to not have to do piss all or be "lazy". I'd argue that "laziness" doesn't exist. What we associate with laziness is often a symptom. People aren't lazy, they're burnt out, depressed, disabled, just straight up incapable, or a mix of all of it.

You get stuck in this shitloop where you hate being unemployed because you can't afford shit, but also hate being employed because... well having a job sucks in most cases.

The problem isn't labor, people will absolutely do labor, the problem is work. The difference is labor is a natural order to obtain what one wants or to contribute to their community. People would be much happier volunteering for various humanitarian projects (mutual aid, housing, etc.) rather than working a typical desk job. While the project manager/business analyst/HR rep/or even IT professional (like myself) earn more, they contribute significantly less to society than the teacher, domestic laborer (i.e house wife/husband), or nurse who make significantly less. One educates the youth, the other is the reason the entire economy can even function to begin with, and the latter breaks their back to save lives.

It's an interesting phenomenon that I've observed that there's almost a correlation in the more a position contributes to society the less they're paid. The jobs that pay the most don't contribute much to society or their communities, they contribute to the business that exploits it.

I think of when I was a kid and what people wanted to be when they grew up. Most kids my age wanted to be something like a doctor, a firefighter, something of that nature. How many kids want to be a data analyst when they grew up? Probably none. Hell, I wanted to be a therapist when I grew up, I only stopped because I didn't think it'd make enough money. Well, I got the job that makes enough money, and I fucking hate it. I should have listened to my younger self. Hell the more I learned about social work, the more passionate I am in it as a career/major. So, that’s why I went back to school to earn an MSW.

I personally think wages need to be abolished altogether and things should be done on the basis of doing them. "Oh but then nothing will get done!", my brother in Christ if money was the only motivator, nobody would be a teacher or contribute to FOSS. We already know intrinsic motivation is the greater motivator than extrinsic motivation, and yet we built our entire socio-economic structure on extrinsic motivation. People would still open up overpriced burger restaurants that play 'Stomp, Clap, Hey' music ad nauseum, people would still want to fix plumbing issues in their community, society would still function. It would just operate on a basis of what people really want than what is the most profitable.

That brings the question of progress. What would a society under this model even look like? I'd hypothesize that 'progress' would be slower, but more intentional. I think of the Deadpool joke of "you'll never see a Danish flag on the moon but Goddamnit they're happy" but societally. Progress would happen to explore more and engage with life deeper. We'd build rockets not for a rich asshole dick-measuring contest, but out of genuine curiosity. There'd be less competing amongst organizations, which would mean more heads together. Think about it, if instead of 10 companies all trying to sabotage and poach each other, you had like 3 regional labor unions you'd have far more people working on one project and would probably get more done.

Anyway, I'm unmedicated for my ADHD right now and have already deleted like 6 paragraphs, so I'm gonna call it here before I go on another tangent. I wanna leave you with this question, if you lived in a moneyless society where your basic needs could be met. What would you want to do? Would you still work the job you have? Or would you do something else?

Previous | Next

Reply via email: me@absurdpirate.com

as of writing this...

As mentioned in my last paragraph, I stopped taking Wellbutrin. I cold turkey'd it which probably wasn't my best idea, but I haven't been having anything above a minor side effect, so I figured fuggit. I stopped because while it 'works' I've been dealing with mild anxiety that has been driving me nuts. I'd rather take a raised heart rate from adderall than a raised heart rate from wellbutrin-induced anxiety. So, in the meantime until I get an appointment with my primary care on the 1st, I've just been self-medicating on caffeine like I'm in my late-teens/early-20s again. Mrs. Pirate got a new espresso machine as a birthday gift from my mom and step-dad, and I've been reaping the benefits. I think I had 4 shots of espresso just yesterday alone and it did as much for me as my regular dose of wellbutrin. I kinda just hate taking pills, more just the sensory aspect of it. I hate the feeling of having to swallow a pill every morning, first thing in the morning. I guess it's a good thing meds aren't ingested in the form of a delicious smoothie or something, because no doubt would people just straight up overdose.

#2026 #socialcommentary

The art of bothering – Herbert Lui

Thu, 05 Nov 2026 20:59:54 +0000

At one point or another, we all feel lonely. But this tendency has gotten so bad recently that it’s described as a “loneliness epidemic.”

Imagine this: you want to meet with a friend, but don’t want to be a bother because you know they’ve got a lot of commitments, you might talk yourself out of it. There’s a good chance that they’re worried about not wanting to bother you, and so they won’t ask.

Or, you attend an event where you don’t know anyone, but don’t want to bother people in and interrupt their conversions so you stand by the wall and check your phone.

Or, you want to meet more people, but don’t want to bother them with a cold email.

Bothering is precisely the most useful thing you can do in these situations. The word “bother” likely comes from the Scottish word “pother,” which means “to make a stir or commotion, bustle.” It’s also possible it descends from the English word “pother,” which means “to poke, prod.”

When you take initiative, you also bother. Notice how when you give up on something or shut down a possibility, you say, “Why bother?”

Bothering doesn’t need to be annoying. There’s an art to bothering. You and I are constantly bothered by other people, and we occasionally walk away from it feeling better from the experience. The key to the art is making sure someone else feels glad that you bothered them. Here are some guidelines that might be useful:

It’s useful for your first bother to involve getting someone’s permission. Small talk is a useful way to bother people you don’t know.

Spread your efforts amongst many people, and you won’t be annoying. Focus your efforts on bothering one person, and you may be perceived as extremely annoying.

If you’ve followed up with someone more than three times to silence, let it go. Maybe you can bother them in six months, or a year. But not today. The art of bothering requires restraint. (These days, I follow up once.)

Master the art of pleasant conversation. When I was a university student, I did a very brief field sales gig for a marketing agency. It involved showing students a laptop and their client’s new software, listening to the students’ feedback, and asking them to fill in a survey. It felt incredibly difficult (and against my nature) to interrupt another student and ask for time. Once I got their permission and we started the conversation, though, things went smoothly. I was even once complimented for how pleasant the conversation was. I eventually quit the gig because I found writing came much more naturally to me, but it became a formative experience.

People feel good when they see an opportunity and can offer to help.

Develop a thick skin for being ignored, and know how to stay top of mind in a more passive way. My wife and I recently adopted a dog, who is very food motivated. Whenever we eat, she comes over, puts on her cutest face, and sits down. If we don’t feed her after a few minutes, she lies down a bit further, but constantly keeps an eye on us. I’ve recently learned that dogs can eat bananas and apples in small dosages, because she has bothered me into doing research and feeding her. My dog has mastered this skill in the art of bothering.

Don’t talk yourself out of something just because you’re worried about being annoying. (You might inspire someone!)

If, after you bother them, you get the feeling you’ve been bothersome (or someone visibly shows frustration or gives you verbal feedback), you need to show more restraint in how you communicate. Learn from the experience and make sure to let things cool. Maybe you should let them bother you instead.

I wrote all of this for people who worry they are being too much of a bother, so they can learn to bother in a useful way. This post isn’t an excuse to be annoying.

别让自己变成祥林嫂 – So!azy

Wed, 04 Nov 2026 10:05:19 +0000

别让自己变成祥林嫂

03 Nov, 2026

前两天有个认识挺久的朋友找我聊天，前前后后发了十几条长消息，全是在吐槽最近工作和生活里的一地鸡毛。

老实说，看着屏幕不断弹出的对话框，我脑子里冒出来的第一个念头居然是：我今天到底要在这些信息上消耗多少时间？或许是我这几年真的变得越来越理性，甚至有点冷血了，我已经很难再像年轻时候那样，毫无保留地去充当别人的情绪垃圾桶。

我当然明白对方找我聊这些，首要诉求是让我提供「情绪价值」。如果是平时珍视的关系，给点适当的安慰、站在他那边骂两句，这都没问题。我愿意为值得的人支付这部分心力，但我毕竟不是什么情绪价值大师，不可能无休止地供应这种廉价的安抚。

在我看来，单纯的情绪价值在很多时候其实就是一种止痛剂，甚至是致幻剂。它能让人在倾诉的半个小时里觉得自己被理解了、委屈被看见了，然后呢？第二天醒来，那个让人痛苦的处境依然原封不动地杵在那里。真正让人难受的问题本身是需要被解决的，而不是被反复咀嚼。

所以听完第一轮发泄之后，我本能地想帮他把事情往前推一步，看看能不能拆解一下现状，或者给点实际的建议。但当我顺着他的话往下问的时候，却发现根本无从下手。

他的抱怨太表面了。全都是「我们领导真是个傻逼」「这破事真让人崩溃」「我觉得太累了」这类纯情绪的宣泄。既没有事情的来龙去脉，也没有双方的利益冲突点，更没有他自己目前握有的牌和底线。我顺着对话框往上翻了半天，找不到任何一个可以切入的受力点。

聊到最后，我只能敲出一句：「然后呢，你跟我说这些，最想表达的是什么？或者你想让我帮你做什么？」

这句话发出去，空气往往就会突然安静下来。在很多人眼里，这种反问简直是标准答案级别的「冷血 T 人」发言，极其扫兴。但我后来琢磨了一下，我真正排斥的其实不是朋友向我抱怨，而是那种彻底放弃了主动权、纯粹为了重复痛苦而存在的单向倾倒。

鲁迅笔下的祥林嫂为什么到了最后会让周围的人感到厌烦甚至恐惧？并不是因为她的遭遇不值得同情，恰恰相反，她最初的悲剧是极其沉重的。但当她把「我真傻，真的」变成一套固定的、不需要任何反馈、也绝不打算通过行动去改变现状的脚本时，倾听者就会敏锐地意识到一件事：你在这段对话里无论给出什么回应，都是无效的。她不需要出路，她只需要一个活人站在面前，配合她完成这场名为「受苦」的循环演出。

成年人之间的深度沟通，本质上是一场需要双方共同出力的协作。你带着麻烦来找我，哪怕你现在脑子很乱，不知道怎么解决，这都很正常。但如果你希望这段对话不只是停留在互相叹气，那你在倒苦水的同时，至少得试着给我留一个「抓手」。

什么是抓手？就是除了告诉我「我很难受」之外，顺便告诉我事实的边界在哪里。比如你现在卡在哪个具体的决策上，你试过了哪 2 种办法但没走通，或者你现在有 A 和 B 两个选项，不知道怎么选。哪怕你直接说「我已经决定辞职了，就是来找你骂街解闷的」，这也是一个清晰的界定，那我就痛痛快快陪你骂完这 15 分钟，然后各自散会去忙正事。

怕就怕那种既不愿意交代真实的背景信息，也不打算为自己的处境做任何切割，甚至连「我到底想要什么结果」都没想过的人。他们把所有的精力都用在了描绘痛苦的质感上，一旦你试图去触碰那个制造痛苦的病灶，他们就会迅速缩回去，甩出一句「你根本不懂我的难处」，然后继续开启下一轮一模一样的抱怨。

遇到这种情况，任何解决问题的企图都会像一拳打在棉花上。你投射进去的时间、精力和逻辑思考，瞬间变成了毫无意义的沉没成本。

我现在的精力预算真的很有限，工作里已经有足够多复杂的系统和具体的业务问题等着我去拆解，回到私人生活里，我只想把注意力留给那些真正想要往前走的人。

所以后来我也给自己划了一条线。面对身边的朋友，第一轮的情绪接纳是我作为朋友的本分；但如果到了第二轮、第三轮，对方依然给不出任何事实层面的抓手，只是在原地打转，那我就会主动叫停这段对话。

抱怨本身并不可耻，谁都有扛不住需要透口气的时候。但人不能放任自己沉浸在倾诉的快感里，把抱怨当成逃避具体行动的掩体。当你遇到破事，开口向别人求助或者倾诉之前，不妨先在脑子里问自己一句：我今天说这些，到底是想找个观众看我受苦，还是想找个帮手一起把这页翻过去？

想清楚这个问题，大概是一个人避免自己变成祥林嫂的最低底线。

#daily

We don't want decentralized systems, we want small ones | Andros Fenollosa

Mon, 02 Nov 2026 17:15:55 +0000

We don't want distributed systems, we want small systems. It doesn't matter if they are centralized inside: what matters is that they stay at a manageable size. That makes them cheap, easy to maintain and almost free of moderation. One example is tildes, shared Unix servers where every user has their own account. They run on a trusted admin and donations. When they grow too big, more tildes appear. Another example is Friend Camp, a community of friends. It costs about $30 a month, around $1 per person.

Despite being centralized, they feel like the opposite of big platforms. There are no commercial interests and people know each other. It's like a shoe shop in a small town. The shop can only serve a few customers because there is little space, you know the owner's name (maybe even his wife's) and the shelves don't offer much variety; and yet you know you will be well served and the owner wants you to leave with what is best for you. In a big department store, on the other hand, the staff don't care whether you come back or not. The owner might be a board of shareholders who only want to maximize profit. Space is unlimited, but there are queues and it's hard to get help. You don't even know if the product is what you are looking for, even if it is cheaper. Welcome to economies of scale. Now apply that to centralized systems.

Distributed systems make us feel in control, because resources are shared among all participants. In return, they only ask us to provide the hardware and the time to maintain it. And that is where they clash with what Moxie Marlinspike said: "People do not want to run their own servers" (2022). Maybe we don't have the time, the money or the knowledge to be a node in a distributed network. Maybe we already have enough with our lives without also having to keep an eye on our mail server. So we end up using a centralized provider inside a distributed system: GitHub or GitLab when we want to use Git, Gmail or Outlook when we want to use email, or WordPress.com or Medium when we want to publish a blog. The small system solves the dilemma without giving up what matters: one person provides the server and the time for everyone else, and the rest only need to trust someone they know. Isn't that too much load for one person? Not if the community is small. Darius Kazemi, with about 50 active users on Friend Camp, gets on average one moderation request a month.

Take three Mastodon instances as an example: icosahedron.website (about 133 monthly active users), mastodon.technology (about 23,600 accounts) and mastodon.social (about 3.4 million accounts). All three run the same software and the same protocol; the only thing that changes is size. The second one shut down in 2022 because its only admin burned out. The other two are still alive, but for different reasons: the first because it is small, and the third because it has plenty of resources (in 2024, the organization that runs it brought in about 2.19 million euros, almost all of it from donations).

The biggest risk for a volunteer-run community is almost always the same: that whoever maintains it burns out. That is why size is not a detail: it is what keeps the work within what one person can handle. Limiting size with waiting lists, closed registrations or a cap on active users seems counterintuitive, but it works. To grow without burning out, there are only two paths left: raise a lot of money, like mastodon.social, or become a business, like Reddit, X or YouTube. But profit guarantees neither better quality nor better service. My small Forgejo instance is as centralized as GitHub, but it has 10 active users: it has gone down fewer times, it is faster and it costs me pennies a month to run.

Leopold Kohr wrote it in 1957, long before the internet existed: "Wherever something is wrong, something is too big". Maybe we have spent years asking the wrong question. It doesn't matter so much whether a system is centralized, federated or distributed. What matters is whether it fits in the hands of someone you can write to when something breaks. Paul Ford, when he said goodbye to tilde.club, put it in writing: "you can, at any time, for very little money and relatively little effort, stand up a tiny digital community that basically belongs to itself".

So next time you are looking for a place to publish, to host your code or to talk with your friends, don't ask whether it is decentralized. Ask how many people are inside and whether you know the name of the person who runs it.

Sources

Paul Ford on tilde.club, the creator of the first tilde (2014). In his 2019 note he hands the server over to new admins, along with a waiting list of 10,000 people.
I had a couple drinks and woke up with 1,000 nerds, Paul Ford's account (2014) of how tilde.club was born and the flood of accounts in its first days.
Tildeverse, the association of tildes that followed the tilde.club model.
tilde.club, a shared Unix computer funded by its users' donations.
texto-plano.xyz, a Spanish-speaking tilde: "seamos pocos pero unidos" (let us be few but united).
Run your own social, Darius Kazemi's guide based on Friend Camp: 50 to 100 active users, one moderation request a month and about $30 a month in costs.
My first impressions of web3, Moxie Marlinspike's article, the source of the quote "People do not want to run their own servers".
Icosahedron, a Mastodon instance running since February 2017 with closed registrations.
Dear mastodon.technology community, the shutdown announcement by Ash Furrow, who ran it alone.
Archive Team: Mastodon, a record of closed instances, including mastodon.technology and its 23,600 accounts.
mastodon.social, the largest Mastodon instance, run by the developers of the software themselves.
Mastodon Annual Report 2024, the accounts of Mastodon gGmbH: revenue, costs and moderation of mastodon.social.
The Breakdown of Nations, Leopold Kohr's book (1957), the source of the quote "Wherever something is wrong, something is too big".

Prisoner’s Dilemma is a Scam · YokerHood · Aleksei Matiushkin

Sat, 31 Oct 2026 12:35:03 +0000

The Prisoner’s Dilemma is the most celebrated thought experiment in game theory and, I dare say, one of the most intellectually dishonest constructions in the history of social science. Not because the mathematics is wrong—the mathematics is airtight, as mathematics tends to be when you get to choose the axioms. The fraud is in the premises.

For those mercifully unacquainted: two criminals are arrested. Each can stay silent (cooperate with the partner) or testify against them (defect). If both stay silent, each serves one year. If one defects while the other stays silent, the defector walks free and the loyal fool serves three. If both defect, both serve two. The “dilemma” is that rational self-interest dictates defection, even though mutual cooperation yields a better outcome for both. The Nash equilibrium is mutual betrayal. Two rational agents, acting rationally, produce an irrational result. Checkmate, humanity.

This story has launched two thousand scholarly articles, several dozen popular books, and at least one documentary narrated in the kind of hushed voice normally reserved for tectonic plate collisions. The problem is that the story has roughly the same relationship to actual human decision-making as a spherical cow has to dairy farming.

The Outside World, or: Snitches Get Stitches

The standard formulation contains a clause so brazen that one wonders how it survived peer review. Let me quote: “It is assumed that both prisoners have no loyalty to each other, and will have no opportunity for retribution or reward outside of the game.”

Read that again. Slowly.

“No opportunity for retribution or reward outside of the game.” This is not a simplifying assumption. This is the removal of the entire ecosystem in which the decision operates. It is the equivalent of an aerodynamics paper that begins with “assume no air.” You can certainly derive results under such a premise, but you should have the decency not to call them results about flight.

Criminals—actual criminals, the kind who get arrested in pairs and face prosecutors offering Faustian bargains—exist in social networks denser than a neutron star. The reason is not sentimental; it is economic. Criminal enterprise is, at its core, a repeated cooperation game with extremely high stakes, and the networks that survive are precisely those that have evolved mechanisms to make defection suicidal. The Sicilian Mafia did not invent omerta because Sicilians have a particular fondness for silence. They invented it because organizations whose members rat each other out at the first prosecutorial wink have the life expectancy of a mayfly. Natural selection applies to institutions as ruthlessly as it applies to organisms, and the institution of “snitch freely, suffer no consequences” went extinct before it could leave fossils.

The Japanese yakuza have yubitsume —the ritual severing of a finger joint as atonement for disloyalty. The Russian vory v zakone maintained an entire parallel legal code inside the prison system, one in which cooperation with authorities was punishable by death. These are not colorful cultural footnotes. These are equilibrium-enforcement mechanisms , evolved over centuries by groups whose survival depended on solving exactly the problem the Prisoner’s Dilemma claims is unsolvable. The game theorist’s model is a world in which these mechanisms have been surgically removed, and the conclusion—“look, cooperation collapses!”—is presented as insight rather than tautology.

Even in the absence of organized crime, the argument holds. Neighborhoods have memories. Prisons have hierarchies. The man who walks free today because he testified will walk the same streets tomorrow, and the streets will know. The cellblock has its own information network, and it is more efficient than most corporate intranets. The notion that the “game” ends when the prison doors open is a fantasy that could only be entertained by someone whose closest encounter with the criminal justice system is a parking ticket.

The iterated version of the Prisoner’s Dilemma partially addresses this objection. When repetition is introduced, cooperation emerges: Robert Axelrod’s celebrated tournament showed that tit-for-tat—cooperate first, then mirror the opponent’s previous move—beats strategies built on pure defection. Nash himself observed, watching Flood and Dresher’s original hundred-round experiment, that Alchian and Williams cooperated far more than the one-shot theory predicted. But here is the thing: there is no such thing as a one-shot game in real life. Every human interaction is embedded in a web of relationships, expectations, and consequences that extends far beyond the immediate transaction. The one-shot Prisoner’s Dilemma is not a simplification of reality. It is a different planet.

To strip away reputation, future interaction, social networks, and the threat of retribution, and then to marvel at the collapse of cooperation, is approximately as profound as removing the walls from a building and expressing surprise that the roof falls down. The walls were doing the work. The game theorist removed them and then blamed gravity.

Pride in a Vacuum

Very well. Let us, for the sake of argument, accept the vacuum. One shot. No future. No retribution. No social network. Two strangers in separate rooms, never to meet again, never to meet anyone who has met the other. A decision, crystalline in its isolation, untouched by any consideration outside the four walls and the ticking clock.

Even here— especially here—the Prisoner’s Dilemma is built on a hidden assumption so fundamental that most treatments never bother to state it: the payoff matrix is complete.

It is not.

The matrix shows prison sentences. It assigns numbers to years behind bars. What it does not show—what it cannot show, what it deliberately omits—is the weight of the decision on the person making it. The reflection in the mirror on the morning after. The thing you know about yourself that no parole board will ever ask about and no sentence reduction can erase.

For a certain type of person—the type that game theorists call “rational” and the rest of us might describe less charitably—the matrix is indeed complete. The only thing that matters is the number of years. Freedom is good, imprisonment is bad, the conscience is a rounding error. For this person, defection is the dominant strategy, the Nash equilibrium is mutual betrayal, the mathematicians are right, and the world is a grimmer place than it needs to be.

But humans are not uniform in this regard. Pretending otherwise is the second great fraud.

Some people would rather serve three years with a clean conscience than walk free knowing they sent a man to prison for keeping faith. This is not irrationality. It is not “bounded rationality” or “cognitive bias” or any of the other euphemisms that economists reach for when humans decline to behave like their models. It is a different utility function. The game theorist’s error is not in the algebra; it is in the ontology. They assumed that the payoff matrix—that neat little grid of prison sentences—describes the entire space of consequences. It does not. The matrix is missing a row. The row is labeled self-respect.

Let us call this hidden variable pride. Not pride in the vainglorious sense—not the peacock’s tail, not the Instagram selfie—but pride in the sense of self-regard: the internal cost of knowing that you have done something you consider contemptible. For some people this cost is zero. For others it exceeds any sentence the state can impose. Between these extremes lies the entire spectrum of human character, conveniently erased by the assumption that all players are “rational agents concerned only with minimizing their prison sentences.”

The quantity that interests us is the ratio of pride to rational self-interest—the pride/mind ratio. Let us call it ρ (rho). A person with ρ = 0 is the game theorist’s ideal rational agent: a spreadsheet with legs. A person with infinite ρ is a saint or a fool, depending on your theology. The rest of us live somewhere in between, and the exact location has consequences that the standard Prisoner’s Dilemma refuses to compute.

Let us compute them.

The Balanced Game

The Setup

In the standard formulation, the payoffs for player A (expressed as negative sentence years—higher is better) are:

Defection dominates: regardless of what B does, A is better off testifying. Against a silent B, testimony yields freedom (0) rather than one year (-1). Against a testifying B, testimony yields two years (-2) rather than three (-3). The logic is impeccable. The premises are what is crippled.

Now let us introduce pride. When a player defects, they incur a psychological cost proportional to ρ . But—and this is the crucial nuance—the magnitude of that cost depends on what the opponent did.

Betraying someone who trusted you and stayed silent is, for most humans, a heavier burden than mutual betrayal. If both of you defect, you can at least tell yourself he would have done the same. If you defected while your partner kept faith, there is no such refuge. We capture this asymmetry with a second parameter γ (gamma), ranging from 0 to 1:

Defecting against a cooperator costs the full ρ in shame. You betrayed trust.
Defecting against a defector costs γρ in shame. Discounted by the knowledge that trust was never on the table.

The modified payoff matrix for player A:

When ρ = 0 , this collapses to the standard Prisoner’s Dilemma. When ρ is large, cooperation dominates. Somewhere between these extremes, the game balances.

The Derivation

Suppose B cooperates with probability q . Player A is indifferent between strategies when the expected payoffs are equal:

E[stay silent] = q(-1) + (1 - q)(-3)      = 2q - 3
  E[testify]     = q(-ρ) + (1 - q)(-2 - γρ) = q(2 + γρ - ρ) - 2 - γρ

Setting these equal:

2q - 3 = q(2 + γρ - ρ) - 2 - γρ
   2q - 3 = 2q + q(γ - 1)ρ - 2 - γρ
  -1 + γρ = q(γ - 1)ρ

Solving for q :

q = (γρ - 1) / ((γ - 1)ρ)

For the game to be balanced —each player cooperating with probability exactly 1/2—we set q = 1/2 and solve:

2(γρ - 1) = (γ - 1)ρ
  2γρ - 2 = γρ - ρ
  γρ + ρ = 2
  ρ(1 + γ) = 2

Which yields the boundary:

ρ = 2 / (1 + γ)

What This Means

The formula says: the critical pride/mind ratio depends on how much you discount the shame of mutual betrayal relative to the betrayal of a cooperator.

γ = 0 —“Betraying a betrayor costs me nothing.” The hardened realist. Full shame for ratting out a loyal partner, none for mutual defection. Here ρ = 2 . Translation: if your self-respect is worth less than two years in prison, you defect. If it is worth more, you cooperate. At exactly two years, you flip a coin.

γ = 1/2 —“Mutual betrayal stings, but only half as much.” A plausible default for most humans. Here ρ = 4/3 ≈ 1.33 . Your self-respect needs to be worth roughly sixteen months of freedom to make you indifferent.

γ = 1 —“All betrayal is equally shameful.” The person for whom the act of defection itself, regardless of context, carries the same moral weight. Here ρ = 1 . One year of self-respect against one year of prison. The exchange rate is 1:1.

The full table:

γ       ρ = 2/(1+γ)   Meaning
  ──────────────────────────────────────────────────────
  0.00    2.00          Shame only for betraying trust
  0.25    1.60          Mutual betrayal costs a quarter
  0.50    1.33          Mutual betrayal costs half
  0.75    1.14          Nearly as shameful either way
  1.00    1.00          All betrayal equally shameful

The Three Regimes

The complete picture has three regimes, governed by ρ and γ :

ρ < 1 —Defection dominates. Classical Prisoner’s Dilemma territory. The shame of betrayal, even at full weight, is less than the one-year difference between cooperation and defection. Mind rules. Pride is a footnote. The game theorists are right, for this particular subspecies of human.

ρ > 1/γ —Cooperation dominates. The shame of defection, even mutual defection, outweighs the material benefit. The “dilemma” ceases to exist; staying silent is strictly preferred regardless of what B does. (Note: when γ = 0 , this threshold is infinite—you cannot be shamed into cooperating against a defector if mutual defection costs you nothing.)

1 < ρ < 1/γ —Mixed strategy. Neither strategy dominates. A player cooperates against cooperators (the shame of betrayal exceeds the one-year gain) but defects against defectors (the discounted shame is worth less than the one-year saving). In this regime, the equilibrium is a probabilistic mixture, and the balance point—exactly 50/50—sits at ρ = 2/(1 + γ) .

The Missing Variable

The Prisoner’s Dilemma is not wrong. It is a theorem, and theorems are not wrong; they are either correctly or incorrectly derived from their axioms. The derivation is correct. The axioms are the problem.

The first axiom—no outside world—removes the entire evolutionary apparatus that makes cooperation the default rather than the exception in human affairs. This is the axiom that everybody criticizes, and rightly so. The second axiom—the payoff matrix is complete—assumes that prison sentences are the only relevant consequence, which is tantamount to assuming that human beings have no inner life, no self-respect, and no conscience. This is the axiom that almost nobody questions, because it is not stated as an axiom at all. It is smuggled in as a two-by-two grid and accepted without examination.

The arithmetic above shows that the omission is not merely philosophical. It is quantifiable. For any given shame-asymmetry γ , there exists a precise pride/mind ratio ρ = 2/(1 + γ) at which the dilemma dissolves into perfect indifference. Below this ratio, the game plays as advertised. Above it, cooperation is not altruism—it is self-interest, properly accounted for.

The question the Prisoner’s Dilemma actually asks is not “will rational agents cooperate?” It is something far more personal and far more interesting: how much is your self-respect worth, measured in prison years?

The answer, unlike the dilemma, is not the same for everyone.

That, perhaps, is the real dilemma.

I built a forum with no interface, no passwords, made for the terminal | Andros Fenollosa

Mon, 02 Nov 2026 12:26:38 +0000

I like forums. Debates, questions, answers, opinions, etc. That feeling of an asynchronous community, where answers are thought through and content lasts, is what makes the internet an interesting place. That is why I like reading them and taking part in them. But I had never designed or built one. In my spare time I started sketching one, and I ended up building my humble headless, federated forum, with simple, modern technologies and open standards.

And I learned a lot along the way. A forum looks simple, but it hides the classic problems of any server. Who can do what? How do you tell a moderator from a regular user? What happens when you have to ban someone? How do you stop someone from stealing an account? Roles, permissions, bans and security. I had to solve them one by one, and you don't learn that by reading.

Let me tell you how I made Tyrtulia.

A forum with no interface

The server only offers a solid, documented API. It is REST with hypermedia: the client only knows one route, GET /, and discovers everything else by following links. Underneath there are some very boring standards:

RFC 9110: HTTP semantics, with ETag and If-Match so edits don't overwrite each other.
RFC 9457: errors.
RFC 7396: partial updates with PATCH.
RFC 6570: URL templates.
RFC 4287: Atom feeds.
RFC 9562: UUIDv7 identifiers.
JSON Schema: validation.
Server-Sent Events: real-time events.

There is no web interface, no forms, no advanced authentication systems, no file handling (images, attachments, etc.), and nothing that isn't strictly needed to read and write messages.

That is why it is so light. It uses between 60 and 70 MB of RAM and about 50 MB of disk. It only needs Python and SQLite to run.

An API that discovers itself

How does a client know what it can do? The server tells it with links. Look at the same request, GET /, made by a guest (simplified):

{
    "name": "Forum of example.org",
    "_links": {
        "self": {"href": "/", "method": "GET"},
        "latest": {"href": "/threads", "method": "GET"},
        "search": {"href": "/search{?q,author,in}", "method": "GET", "templated": true},
        "login": {"href": "/sessions", "method": "POST", "schema": "/schemas/session"}
    }
}

And now by alice, logged in:

{
    "name": "Forum of example.org",
    "_links": {
        "self": {"href": "/", "method": "GET"},
        "latest": {"href": "/threads", "method": "GET"},
        "search": {"href": "/search{?q,author,in}", "method": "GET", "templated": true},
        "createThread": {"href": "/threads", "method": "POST", "schema": "/schemas/thread"},
        "notifications": {"href": "/notifications", "method": "GET"},
        "events": {"href": "/events", "method": "GET", "type": "text/event-stream"}
    }
}

If I change a route tomorrow, no client breaks, because none of them knew it in advance. They just follow the links the server gives them.

Why not use one that already exists?

I know there are very complete free software forums:

Discourse: the most popular one today.
Flarum: PHP with MySQL.
NodeBB: Node.js, with MongoDB, Redis or PostgreSQL. It stands out for real time with WebSockets.

Or the good old classic: phpBB.

They are all fantastic, but they are designed to be used from a web browser. They also have an ambitious scope. That is ideal for large communities, but too much for a small, light forum.

That said, Tyrtulia doesn't give up on the browser: it can be indexed by search engines and anyone can read it on the web.

No passwords

No OAuth, no OpenID, no sign-up forms. There are two ways to authenticate:

Your Unix user: the client talks to the forum through a Unix socket. The operating system tells the forum which user is on the other side. No sign-up, no login. Your user is your account.
SSH key: the client connects over HTTP and the forum sends it a challenge. The client signs it with your private SSH key and the forum verifies it with your public key.

There is no registration over HTTP. If you have a Unix user on the server, you already have an account: it is created the first time you connect through the socket. From there you can add your SSH keys to log in from outside. If you don't have a user on the machine, the administrator creates an account for you with your public key from the command line. On a tilde, having a Unix user is already the invitation.

Easy to use, secure, and no passwords to steal.

What changes compared to BBJ

The idea isn't mine. I was inspired by BBJ, a bulletin board for the terminal built for small communities or clubs (tildes, pubnixes, club servers, etc.). I took its spirit and brought it to my own ground. Still, there are important differences.

First, the foundations.

	BBJ	Tyrtulia
API style	RPC: everything is `POST /api/<endpoint>`	REST with hypermedia (HAL): only `GET /` is known
Permissions	The client asks (`is_admin`, `edit_query`)	Links that appear or disappear
Authentication	Unsalted SHA-256 hash of the password on every request	No passwords: Unix socket or SSH-signed challenge
Errors	6 custom numeric codes	RFC 9457 with a catalog of types
Pagination	Everything at once	Cursor based
Concurrency	The last edit wins, silently	`ETag` and `If-Match`
Text format	Custom language (`[bold: ...]`, `[red: ...]`)	Standard Markdown
Validation	A `db_validate` endpoint	JSON Schema linked from each form
Configuration	`config.json`	TOML

Then, the features I missed.

	BBJ	Tyrtulia
Reply to a specific post	`>>N` quotes in the text	Linked replies, with a tree view
Mentions	No	Yes
Notifications	No (pending since 2017)	Inbox with replies, mentions and alerts
Real time	No, you have to poll	Server-Sent Events, with resume
Edit history	No, editing overwrites	Full, with diffs and revert
Deletion	Deletes the row	Tombstone: numbering is preserved
Search	Each client searches what it has downloaded	Server-side full text, accent and case insensitive
Feeds	No	Atom for the forum and each thread
Moderation	Admin or not	Roles, hidden posts, reports and a public log
Rate limiting	No	Per user and per IP

What they share is a small server built on SQLite and several text clients against a documented API.

Clients

A headless forum needs clients, no way around it.

Tyrtulia TUI

Tyrtulia TUI is the terminal client, built with Textual.

tyrtulia.el

If you know me a little, you know this package was a must: tyrtulia.el.

Tyrtulia Web

Tyrtulia Web is more a mirror of the content than a client. Its goal is to let search engines index the forum and let anyone read it from a browser.

It has an unstyled theme and another one that mimics my website.

Federation

You can connect to one forum or set up several. Federation happens in the clients: servers don't talk to each other or copy messages between them. Each forum is independent, with its own users, rules and moderators.

Instead of splitting them into tabs or accounts, the clients mix the threads of all of them into a single list.

Of course, you can only write in the forums where you have an account. In the rest you can only read.

I think it's a pretty cool feature, because it keeps the API code much simpler and lets you explore other forums at zero cost.

Try it

It has been fun to design and build. Of course there are more complete forums, more powerful federation systems, and even decentralized systems that leave Tyrtulia in the dust (Aether, Nostr...). But its niche is very specific: a light, closed-access, federated, indexable, secure forum with text clients. For everything else, there are better things out there.

If you feel like trying it, the installation guide is in the Tyrtulia repository.

I look forward to your feedback.

The upvote dilemma – Herman's blog

Tue, 27 Oct 2026 18:32:45 +0000

The upvote dilemma

27 Oct, 2026

A couple of weeks ago I quietly removed the upvote count from the discovery feed on Bear. The upvote button is still there on every post, and upvotes still decide what ends up on Trending. You just can’t see the numbers next to each post anymore.

I made the change for two reasons.

The first is that visible counts make the popular posts more popular. A post with a lot of upvotes looks like it’s worth reading, so it gets read and upvoted more, and the quiet posts with no audience stay quiet. One of the things I love about Bear, and actively curate, is that someone with no audience can still be discovered. Hiding the count means people judge a post by its title and writing, not by how many people liked it first, especially on the Newest page.

The second is that upvote numbers don't make people feel good. Someone puts sincere effort into a post, publishes it, and then sees a little “1” next to it, sitting right below someone else’s “214”. Writing shouldn’t feel like a popularity contest, and a number next to your name makes it one, whether you like it or not.

More broadly, I think the "like button" is one of the things that made the internet worse (that and infinite scroll). It turned writing and sharing into a scoreboard, and it trained a generation of platforms (and people) to optimise for the number instead of the thing itself. I’ve been critical of this in my post on social media, and it felt a bit hypocritical to have the same mechanic on Bear’s own feed.

Despite my above grievances, upvotes are useful. They’re a good, simple signal to indicate what people have enjoyed, and I haven’t found a better way to rank the feed (yet). This feels like a decent tradeoff. Upvotes still do the useful job of ranking, but they no longer act as a public scoreboard.

I was a little worried making this change (hence the quiet rollout to test it), since part of the appeal of upvoting is seeing number go up. So I compared the two weeks after the change with the month prior, and the number of upvotes per day didn’t change, the number of people upvoting didn’t change, and neither did the number of people clicking through to posts from the feed. People are reading and upvoting as much as before. They’re just not comparing scores while they do it, and upvotes are spread out among more posts than before. Great success!

It’s still early days, and I’ll keep an eye on it over the next month. But for now the numbers are staying hidden.

If you have thoughts on this, send me an email. I’d love to hear how it feels from your side, both as a reader and as a writer.

ask me something – yours, tiramisu

Thu, 29 Oct 2026 17:59:22 +0000

ask me something

29 Oct, 2026

A few weeks ago, while talking to A, she told me something about her that surprised me (I can no longer remember what).

"I didn't know that about you!" I said.

"Well, you never ask me anything," she said, with a forcefulness that caught me off guard.

It stung. It stung because she was right, and it stung because I know how terrible it feels to be in her shoes. I was simultaneously struck by how brave it was of her to say so and how lucky I was that she had bothered to tell me. If she hadn't told me, I never would have known.

Later that week, I told B about this on a call. She just nodded, as if she'd known this about me all this time. Then she told me about this date she went on where the guy talked the whole time and never asked her anything. When the date ended he said to B that he thought the date had gone great. (B is a great listener.) B had a less rosy view of the date. Naturally, there was no second date.

Uh oh, I thought. That must be what it's like to talk to me.

Today, I was on a walk with J around the neighborhood. We had just reached the top of a big hill when the conversation hit a lull.

"Ask me something!" she said.

I obliged. I told her I was glad she had said so because I hadn't noticed, and judging from these recent episodes I clearly have an issue with this. Other people must notice this about and simply not tell me. (I don't blame them — how are you supposed to bring something like this up?)

I've been trying to think about the reasons why I might not ask someone as many questions as they (and I, often) would like.

The least common reason but the one that comes first to mind is that sometimes, I don't ask questions because I don't care about the answers. This happens mostly at work. I'll utter some pleasantries if someone asks about my weekend, and I might even instinctively ask about theirs in return, but I won't ask more questions because I don't really want to know any more and because I dislike when people ask me things without caring about the answers. Obviously, this does not apply to any of my friends, so it is not very helpful in diagnosing the aforementioned scenarios.

Far more often, I want to know things. Of course I worry about how J and B and how all my other friends feel when talking to me. Beyond that, though, I also lose when I don't ask questions. Sometimes, I'll leave long conversations with people and only later think about all these questions I wanted to ask them and didn't get a chance to.

(This is part of the reason I enjoy written communication so much, whether that be emails or letters or texts: it's so much easier to ask questions asynchronously! You don't have to worry about interrupting someone or asking something at the wrong time. If you're unsure whether a question is appropriate, you have time to think about it. Real-life conversations go faster than my brain can keep up.)

The biggest reason is also the most simple: asking questions is hard. With the exception of the easiest questions, like asking someone where they went when they mention coming back from vacation, there are so many things I have to consider before ask a question. Where do I begin? Which of these things do I want to ask about first? Did they already tell me the answer to this somewhere else? Is this a good question? Is now a good time to ask? Am I prying? It takes a significant amount of my brainpower to whittle down an amorphous curiosity about the way a person is and their current state into open, coherent, socially acceptable questions.

In the meantime, because they're my friends, they're probably asking me thought-provoking questions that make me speak at length, during which all my question-planning goes out the window. When the conversation slows, the planning has to start anew. What do I want to know about the most? How do I phrase this? Wait, have I already asked this? Should I know the answer?

To help my slow, porous brain, I used to take notes when calling friends, roughly outlining what they had told me and jotting down questions that bubbled up. It's harder to do this in everyday conversations when you're having dinner or walking around. I don't always have pen and paper handy, and some people find it weird if you take notes in casual conversation. For me it helps offload some of the thinking and remembering that a productive conversation demands, especially when there's a lot to catch up on or when talking to someone new with whom I should mind my Ps and Qs. (B would sometimes wait for me to finish writing stuff down and wait expectantly for a question, of which I usually had a few scribbled somewhere on my legal pad.)

I've also realized recently that I feel some internal resistance to posing the questions people ask me back at them. J said for her it was the most natural thing to do. I always find it difficult for some reason. Maybe I think it feels like a lazy response, or I feel some responsibility to lead the conversation in a different direction? I don't know why, but will keep trying to figure it out.

It's hard — maybe even impossible — to observe something like this objectively myself. A concept I vaguely remember from high school physics — maybe the observer effect? — talked about how we've never been able to observe the natural behavior of an electron because observing it would require us to shine light on it and thus disturb it, causing it to act differently. I can't act as I normally do if I'm consciously thinking about this, but I can't pay attention to it if I'm not thinking about it.

One solution, I found myself proposing to J, is that I need someone to record my conversations so I can listen to them back and match up what I said and how I acted to how I remember feeling in the moment. But I can't know I'm being recorded because that would make me act differently, so one of my friends would have to surreptitiously record me without me noticing. (You have my permission, by the way, provided you send me the recording and promise not to use it for nefarious purposes.)

That sounds like a lot. Instead I suppose I could make a survey for my friends to take and see what they have to say about this. I'd wager some of them (maybe even a lot of them, judging from recent events) have noticed and not told me. I also think, though, that some of my other friends might not feel similarly. In fact, I am sure I ask a few of them far more questions than they ask me.

Which begs the question: what separates the two groups? It's a matter of space: some people let more time pass in between exchanges. They wait longer and let the silence build. In those in-between moments, I have time to regroup my thoughts, formulate questions, and ask them. I don't know if these conversations are better as a result — probably not — but they are more balanced in this regard. (To be clear, I don't want my other friends to get the wrong idea and all of a sudden force me to sit in silence during our conversations. I think I just need to practice getting the balance right.)

On an unrelated note, I love when people talk about the conversation we're having while we're in it, or detail their own thought process! Meta-conversation, if you will. Anything from we're unusually quiet today to oh, you seemed like you didn't want to talk about it and I didn't want to pry. Acknowledging something like silence or tension makes space in the conversation to unpack said phenomenon. I find that the most growth (personal and interpersonal) growth happens in those moments, when you talk directly about whatever you've noticed that hangs in the air like a haze.

Where to go from here? I'm not confident that just being mindful of this shortcoming of mine in conversations is enough to fix it. After all, if it were that easy, would anybody have this problem?

As always, if you have any thoughts or advice, I'd love to hear from you. (You can remain anonymous by filling in a bogus name/email if you wish, though please make it clear so I don't shoot off a reply to some unsuspecting stranger.) If you came here thinking this would be some AMA, I am sorry to disappoint, though you are always welcome to ask me anything.

Topical meme. Translation: Simple makeup ! I accept criticism (but I don’t stay quiet, either)

To end this post, I revisited this old post that feels especially relevant to my situation now, Good conversations have lots of doorknobs.

Givers think that conversations unfold as a series of invitations; takers think conversations unfold as a series of declarations. When giver meets giver or taker meets taker, all is well. When giver meets taker, however, giver gives, taker takes, and giver gets resentful (“Why won’t he ask me a single question?”) while taker has a lovely time (“She must really think I’m interesting!”) or gets annoyed (“My job is so boring, why does she keep asking me about it?”).

It's easy to assume that givers are virtuous and takers are villainous, but that’s giver propaganda. Conversations, like improv scenes, start to sink if they sit still. Takers can paddle for both sides, relieving their partners of the duty to generate the next thing. It’s easy to remember how lonely it feels when a taker refuses to cede the spotlight to you, but easy to forget how lovely it feels when you don’t want the spotlight and a taker lets you recline on the mezzanine while they fill the stage. When you’re tired or shy or anxious or bored, there’s nothing better than hopping on the back of a conversational motorcycle, wrapping your arms around your partner’s waist, and holding on for dear life while they rocket you to somewhere new.

The crux of the post is that good conversations have affordances, or big doorknobs for other people to grab onto. Doorknobs give other people things to ask about or respond to and continue the conversation. Most of the time, I don't feel like my conversations with friends lack doorknobs on either side. What stood out as more relevant to my situation was this:

You might think that the best conversationalists wait patiently for their partners to finish talking before they start concocting a response in their head. It turns out that we like people the best when they respond to us the fastest — so fast (mere milliseconds!) that they must be formulating their reply long before we finish our turn. Abundant affordances allow for this rapid-fire rapport, each utterance offering an obvious opportunity to respond.

I am not so good at this skill that makes people likeable. When I listen to someone, it takes all of my brainpower to process and absorb what they are saying. If you tell me something complex or important, I might even close my eyes to concentrate. I don't say this as an excuse, or a cop-out, because I'd very much like to change; I just want people to know that I'm not uncurious about them, only a little slow and trying my best to keep up. Like many other things, it's a work in progress. ⟡

#english #friendship #wordvomit

Free Software, Per Accidens - gingerBill

Wed, 28 Oct 2026 23:35:47 +0000

Free Software, Per Accidens

2026-10-28

Recently I have been thinking now that LLMs/AI have made it relatively “simple” to decompile just about anything, doesn’t that suggest many of the core “principled/idealistic” arguments for OSS/FOSS were never fundamental to begin with?

I know you don’t get back what was actually written, especially with optimized binaries, but that gap keeps shrinking in terms of usefulness. From a philosophical standpoint, doesn’t it show that many (not all) of the foundations of movements like FOSS (especially GNU) were per accidens⁠¹1 Per accidens means incidental (a product of circumstance), as opposed to per se, meaning essential, true by its very nature. rather than per se?

Origin Stories

All of this makes me wonder how much of the FOSS movement was just post-hoc justification. Part of the origin story is Stallman being annoyed that he couldn’t get the source for a Xerox printer to add a paper jam notification.⁠²2 Sam Williams, Free as in Freedom: Richard Stallman’s Crusade for Free Software (O’Reilly, 2002), chapter 1, “For Want of a Printer”. I completely sympathize with the frustration (I still have printer problems to this day), but the origin alone doesn’t prove anything.

The other part of the origin story is Unix being locked behind expensive licences once AT&T could commercialize it. I’m not disputing any of that context. But being a response to circumstances doesn’t make an argument per accidens; depending on those circumstances does.

Open vs Free(dom)

Most of the framework of the Free Software Movement still assumes source code is hard to get or that binaries are hard to modify. GNU’s Freedom 1 (study) even lists access to source as a precondition.⁠³3 GNU Project, “What is Free Software?” (The Free Software Definition). The same precondition is also listed for Freedom 3. If anyone can recover readable code from a binary, in any language of their choosing, that precondition matters a lot less, and with LLMs/AI it’s already close to being met.

My argument is mostly about the open side of Free Software, which is really just Freedom 1, the freedom to study and change a program. Freedom 0 (run it for any purpose) is a pure permission, as are Freedoms 2 and 3 (share copies and modified versions); GNU even says Freedom 0 has nothing to do with whether a program is “technically capable of functioning in any given environment”.

GNU lists access to source as a precondition for both Freedom 1 and Freedom 3, but my point about decompilation only changes one of them: it gives you the ability to study and modify a program, not the permission to distribute the result. Which means in both cases, source access is per accidens, and the permission is what’s per se. If anything, I think the heart of the Free Software Movement was always the permission to share (Freedoms 2 and 3), and never really the source.

The obvious objection is that the four freedoms are permissions, not capabilities: being able to decompile something doesn’t mean you’re allowed to. I agree, but I’m not arguing about the permission. I’m arguing about the technical premise GNU attached to it: “Access to the source code is a precondition for this”. Freedom 1 is really two claims bundled together: that you need access to the source, and that there shouldn’t be any secrets in the first place. And “cheap” decompilation takes care of the first, because that part was always per accidens. The second is the actual moral claim, and that’s the one I actually disagree with.

To be clear, I’m not claiming decompiled code is as good as the original source. The GPL even defines source as “the preferred form of the work for making modifications to it”,⁠⁴4 GNU General Public License, version 3, section 1, “Source Code”. GPLv2 uses the same wording in section 3.5 Except when you want it in a different language, or the original source wasn’t readable to begin with. Most open source code is hard to read, so even with the original source, you’re still doing your own decompilation, from text to text. and the original is virtually always preferred over a decompilation.⁠⁵ But a preference is not a precondition. A precondition is something you can’t do without, and the lack of source never strictly prevented anything; it just made it expensive. People were decompiling entire programs by hand long before LLMs: Super Mario 64 was decompiled by hand back into C that compiles to a byte-identical ROM, which is what then made the native PC ports possible; what LLMs/AI change is the cost of this process. Even if the original source has extra information (e.g. comments and names), decompiling with tools like Ghidra + LLMs has made the whole process a heck of a lot simpler (for personal use). It’s still harder and messier than having the original source, but it’s possible, which makes source access a convenience rather than a requirement.

And “preferred” is already a matter of degree. Original source, decompiled code, disassembly, and the raw binary are all points on the same gradient. Some things (build scripts, or code behind #ifdefs for other platforms) aren’t in the binary at all, so you’d have to recreate them rather than read them, but that’s a difference in effort. And if decompilation makes auditing possible without the source, then the source itself isn’t doing the essential work.

Source Was Never a Guarantee

Even with the source, you could never really know what was running on a remote server. And even locally, Thompson’s “Reflections on Trusting Trust”⁠⁶6 Ken Thompson, “Reflections on Trusting Trust”, Communications of the ACM 27(8), August 1984, pp. 761–763. Originally his Turing Award lecture. showed you can’t fully trust code you compiled yourself.

The FSF knows both of these: the AGPL exists for the server case⁠⁷7 GNU Affero General Public License, which requires offering the source to users who interact with the software over a network.8 Google’s AGPL Policy: code licensed under the AGPL “MUST NOT be used at Google”. Its reading of the AGPL is disputed as the AGPL treats network use as distribution but it doesn’t make the rest of a service a derivative work. Either way, the ban is the point as companies avoid it regardless.9 David A. Wheeler, “Fully Countering Trusting Trust through Diverse Double-Compiling”, PhD dissertation, George Mason University, 2009. See also Reproducible Builds. (though few projects use it, and many companies refuse to touch AGPL code at all; Google bans it outright⁠⁸), and from what I’ve discussed with others, the answers to Thompson are reproducible builds and diverse double-compiling,⁠⁹ both of which need the source. It does kind of make source necessary for those “solutions”, but they are not sufficient, and very few people actually run them; in practice you’re still trusting someone else’s build. And even in those cases, you still need to trust the bootstrapping stage. There is always a place where you just have to “trust”. And sadly, that means source alone can’t be the guarantee; at best, it’s a mere convenience.

The FSF would say source isn’t about trust at all but about control: without it, the program controls the user. But control is a gradient too, for the same reason trust is. Source, reproducible builds, inspecting the binary, decompiling it: none of these is a guarantee, and each gives you some control over what runs on your machine. The FSF draws a categorical line at one point on that gradient, and my question is why that point?—especially now that the other points keep getting cheaper. Yes, the strongest checks need the source, which makes it the best point on the gradient, but still only a point on it.

Open Source Is Not a Business Model

If the technical case for source access is mostly per accidens, the pragmatic case has to carry the weight, and pragmatically, open source has a funding problem.

Eric S. Raymond, who wrote down much of the original “theory” of open source,⁠¹⁰10 Eric S. Raymond, The Cathedral and the Bazaar (O’Reilly, 1999).11 “The Heartbleed Bug”. It shipped in OpenSSL 1.0.1 in March 2012 and was disclosed in April 2014. in my opinion made an engineering argument rather than a moral one: “given enough eyeballs, all bugs are shallow”. In a way, that’s the main distinction between open source and Free Software. But more eyeballs only make bugs more likely to be found, not certain to be: Heartbleed sat in OpenSSL, one of the most widely used libraries around, for about two years before anyone noticed.⁠¹¹ And not to mention, eyeballs aren’t free. Reliability and reusability do not come from merely having source availability; they come from people being paid to maintain and improve the software—an actual incentive. Unfortunately, that is not the reality of open source.

To be clear, the distinction I’m drawing between Free and open is about motivations and business logic, not licences. The licences mostly overlap, and even GNU says “nearly all open source software is free software”.⁠¹²12 GNU Project, “Why Open Source Misses the Point of Free Software”.

Personally, I think open source is antithetical to “selling software” as a business. Most open source projects can’t really make money from the software itself, so in practice they’re effectively charities. Open source was never “free as in beer” or even “free as in freedom”. It has always been “free as in puppy”: free to get, but the maintenance cost falls on the users as well as the people who made it.⁠¹³13 The origin of the phrase is disputed. From what I can tell, it has been attributed to Sun’s Scott McNealy, and Nadia Eghbal’s Working in Public: The Making and Maintenance of Open Source Software (Stripe Press, 2020) quotes Bootstrap co-creator Jacob Thornton using it. So I have no idea of the actual origin.

For context, I’ve run multiple open source projects for over a decade, the largest being the Odin compiler. However, I’d never license any of them under the GPL or want to run anything under it. If I want something open, I want it permissive, not viral. Both the Odin compiler and its core library are under the zlib licence, which is effectively one step above public domain.⁠¹⁴14 Public domain isn’t legally recognized everywhere, so zlib is about as close as you can get, as well as a few other similar licences.

Odin itself is free precisely because you can’t really sell a compiler anymore: the expected price of a compiler nowadays is zero. Even Intel gave up and made its compilers free. The compilers you can still pay for either have decades of precedent behind them, and thus the inertia (e.g. IAR and Green Hills in embedded, or Matlab and Mathematica in the sciences), or they aren’t really sold as compilers at all but as entire suites (IDE, debugger, profiler, certification, support), which do far more than a mere language and its core library. And I’d sell Odin if I could, because profit is what pays for making it better. Making a living is not a vice.

And if the authors have no funding, what incentive do they have to keep improving it, the way any business would, other than the kindness of their hearts? To be clear, this isn’t a criticism of permissive licences (I am a user of them), rather neither permissive nor copyleft licensing is a business model in itself.

Most of the open source projects I’ve dealt with aren’t actually good in the slightest, because the people developing them have had no incentive to make them better.⁠¹⁵15 Nadia Eghbal, Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure (Ford Foundation, 2016), which covers underfunded projects like OpenSSL and the Heartbleed bug.16 The Blender Development Fund. At the time of writing, around €280,000 a month from roughly 7,600 individuals and 46 corporate members.17 Adam Smith, The Wealth of Nations (1776), on self-interest rather than benevolence.18 F. A. Hayek, “The Use of Knowledge in Society”, American Economic Review, 1945, on prices as signals.19 Thomas Sowell, Knowledge and Decisions (1980), an accessible treatment of prices as information. They’re effectively charities, and even the popular ones are. Blender is one of the most popular open source projects around, and it’s paid for by donations to the Blender Development Fund from thousands of individuals and dozens of companies, such as NVIDIA and Netflix,⁠¹⁶ and at the end of the day, that’s still charity even if it’s just at scale. A profit motive isn’t a bad thing at all;⁠¹⁷ prices are just a signal mechanism, and they’re what allow for rational calculation in the first place;⁠¹⁸^, 19 without those signals, you’re kind of just screwed.

The usual objection is that money corrupts priorities: managers reward adding features, never removing them, and so commercial software bloats. That does happen, but it’s an organisational problem, not a money problem. It’s just Conway’s law: a system’s design ends up copying the communication structure of the organisation that built it.⁠²⁰20 Melvin E. Conway, “How Do Committees Invent?”, Datamation, April 1968.21 Casey Muratori, “The Only Unbreakable Law”, a talk on Conway’s law and why it can’t be avoided.^, 21 And open source isn’t immune to any of this either. A feature is far easier to get merged than a removal. And (unfortunately) most large open source projects are funded by the same huge corporations, with the same performance reviews. At least when customers can leave (assuming an alternative exists), bloat costs you something.

Those same corporations are behind most of the big successful (non-copyleft) open source projects, done in “goodwill” because they can afford to be “kind”. And I’d easily argue that a lot of the time it isn’t kindness at all, but a way to undercut commercial competition and dominate a market, simply because they can afford to give it away.

And the companies that did try to build a business directly on open source show it best. When the “open source companies” of the last decade (MongoDB, Elastic, HashiCorp, and Redis) needed revenue, they all moved to source-available licences, mostly to stop cloud providers selling their own work back to their customers.⁠²²22 MongoDB moved from the AGPL to the SSPL in 2018, Elastic from Apache 2.0 to the SSPL and Elastic License in 2021, HashiCorp from the MPL to the BSL in 2023, and Redis from BSD to the RSAL and SSPL in 2024. Elastic and Redis later added the AGPL back as an option. Open source was the marketing, not the business model, because it can’t sustain one.

The Exceptions That Prove the Rule

Linux is effectively the canonical exception, since much of it is written by developers paid by companies that depend on it. But I’d argue that’s because of the sheer scale of building a kernel/OS, not anything inherent to the GPL. The usual counter I have seen is that the GPL is precisely why those companies cooperate: none of them can take the shared work private, meaning contributing is safe. There’s some truth to that, but permissively licensed projects like LLVM⁠²³23 As people who know me know, I have no love for LLVM whatsoever, and it has been the bane of my existence for over a decade now. get the same kind of corporate cooperation without it, so the GPL isn’t necessary for it.

And even Linux doesn’t follow the FSF’s intent. Linus kept it on GPLv2 because it only asks for “tit-for-tat”, which he called “totally independent of any moral judgement”,⁠²⁴24 Linus Torvalds, “An Ode to GPLv2”, Linux kernel mailing list, September 2006. and he objected to GPLv3’s anti-Tivoization clause, the requirement to let users run modified versions on the device itself. That’s why vendors can still lock down the devices Linux ships in. It’s an engineering argument for sharing code, not the FSF’s moral one.

The same pattern shows up in the other big GPL successes: GCC succeeded through scale too, and WordPress makes its money through other means.⁠²⁵25 WordPress makes its money from everything around the code: Automattic sells hosting (WordPress.com and enterprise hosting) and WooCommerce extensions, and the premium plugin and theme market really sells updates and support. GCC also helped make everyone expect a compiler to cost nothing, which effectively killed an entire software business model for many people. Its main competitors, Clang and MSVC, are backed by Apple and Microsoft, who can afford to give them away.

MySQL, Qt, and wolfSSL are the interesting cases, since they make money through dual licensing: selling a proprietary licence to anyone who doesn’t want the GPL’s terms. These are business models which seem to depend on copyleft, but look at what’s actually being sold: an exemption from the GPL. Nobody pays to escape a zlib licence. The GPL is the “stick” and the non-free licence is the product. And even that didn’t keep MySQL independent: Sun bought it in 2008, and it came to Oracle along with Sun in 2010. Oracle makes its money through other means, not least its own proprietary database. In other words, the GPL’s successes are per accidens as well, not per se.

Copyleft Needs Copyright

Red Hat is one of the rare companies to build a sustainable business on GPL software, mainly because of when they started and because what customers really pay for is the support, certification, and enterprise trust, not the code. And even then, RHEL isn’t really open. It’s closer to source-available on purchase, since they limit the source to paying customers and use their subscription terms to discourage redistribution.⁠²⁶26 Mike McGrath, “Furthering the evolution of CentOS Stream”, Red Hat blog, June 2023. It made CentOS Stream the sole public source for RHEL-related code, with RHEL sources available to customers under their subscription agreements.27 The Register’s coverage of Red Hat’s source change, June 2023.^, 27 I’d argue this is effectively a loophole around the GPL, since the GPL lets anyone who receives the source redistribute it, which normally makes selling it hard to sustain. Whether those terms actually comply with the GPL is disputed. Like MySQL, Red Hat sells something the GPL leaves room for, in their case support, certification, and controlled access to the source; neither generalizes into a business model for software as a whole.

And in many ways, it also shows the movement doesn’t really subvert IP. In GNU’s own words, copyleft “uses copyright law, but flips it over to serve the opposite of its usual purpose”.⁠²⁸28 Richard Stallman, “The GNU Project”, “Copyleft and the GNU GPL”. See also GNU’s “What is Copyleft?”. But RHEL shows how easily that flip is undone. The GPL only works because copyright exists (as do permissive licences, of course), and Red Hat simply layers contracts on top to stop people redistributing source they legally received. So copyleft doesn’t escape IP; it depends on it, and loses to the very same legal tools.

Many (not all) Free Software advocates are anti-IP, and would happily see copyright, and copyleft with it, abolished. But without copyright, Freedoms 2 and 3 are only worth whatever you can get your hands on, because nothing forces anyone to hand over the source. Businesses would fall back on trade secrets, contracts, and DRM, which is exactly what I expect them to do anyway. And that’s not a rare fallback: the vast majority of businesses already work this way. A recipe, a manufacturing process, a customer list, or just knowing how to do something others don’t, is what most businesses are built on, not copyright. Software is no different.

To be clear, I’m not advocating for abolishing IP. Parts of it are flawed (software patents especially), but it exists for a reason: it protects the work and investment that went into making something—so that it’s worth making in the first place. Take it away and that protection doesn’t disappear; it just moves into secrecy, contracts, and DRM.

What I Expect to Happen

If decompilation keeps getting easier, I do expect the industry to respond in a few ways:

Hardware DRM that protects binaries and process memory from even being read.
More use of kernel-level DRM, similar to anti-cheat software.
A legal hellscape where everyone is suing everyone all the time.

Unfortunately, I expect all of them to happen. I am very conflicted about this, because it’s very similar to the idea behind signed binaries and TPMs, which end up becoming “we decide what software will run on your machine”. I know it doesn’t have to be like that at all, but it could be.

Some will say this proves the FSF right all along, since this is exactly the lockdown they’ve warned about.⁠²⁹29 Richard Stallman, “The Right to Read”, Communications of the ACM, February 1997.30 Richard Stallman, “Can You Trust Your Computer?” (2002), on “treacherous computing”.^, 30 But predicting an outcome isn’t the same as being right about its cause. The FSF movement is effectively anti-trade-secret to begin with. In their view, if you distribute software in any form, even compiled and obfuscated, the source should be shared with the world. Their reasoning is about control: without the source, the user doesn’t control the program, the program controls the user. But “trivial” decompilation now gives you most of that control without the source, so what’s left of the demand is simply that a secret must not stay a secret. And a lot of businesses, especially small ones, exist precisely because of their trade secrets, so why the heck should they ever release any of that?

Compiled binaries used to be a cheap form of protection. If decompilation removes that, companies won’t go the FSF route. They’ll reach for the expensive forms instead: hardware, kernel-level DRM, and lawyers, and the FSF’s dream wouldn’t be any better. If in this “future” all software had to be free, most of it would be the charity I described above, with little incentive to improve. Either way, it would be a dark age for software.

But there is another option, and it isn’t a new idea: stay closed, but make the closed version worth paying for. Piracy has always been a problem, and decompilation only makes it easier. Yet Steam and Netflix are both closed source, and they made piracy matter a lot less not by opening up, nor by locking things down harder, but by being more convenient than the pirates. As Gabe Newell put it:

Piracy is almost always a service problem and not a pricing problem.
Gabe Newell, interviewed by The Cambridge Student, November 2011, as reported by MCV.

Neither Steam nor Netflix would ever open up the software their business runs on (the Steam client and store, or Netflix’s apps and recommendations), even though both happily open source the parts that aren’t their business. That software is the business; the service is what makes paying for it easier than pirating it.

And yes, this means the ability to decompile is contingent too: it lasts only as long as hardware and law allow it, but that’s my point. None of the technical conditions, source, or binary, were ever per se. The real question is who draws the line: hardware vendors, the FSF’s demand that all source be shared, or ordinary markets and contracts. Personally I usually prefer to pick the last one. Paid, closed software with clear legal terms protects a company’s work without locking down your machine, and it gives developers a price signal and a reason/incentive to keep improving the software.

The FSF route turns software into a form of forced-charity, and the hardware vendors’ route turns your computer into someone else’s. Paid closed software with clear legal terms is the least bad option, and we should stop treating it as if it was the villain.

Conclusion

LLMs have made decompilation a lot simpler. I’m not saying that makes Free Software necessarily wrong, but it does show which parts of it were per accidens. The technical premise behind GNU’s Freedom 1 (that you need the source to study or change a program) was always about cost and never a principle.

What remains as per se are Freedoms 2 and 3 (the permission to share copies and modified versions) and the moral claim that software shouldn’t have secrets, but neither of these points is technical. The first is a question of copyright, which copyleft depends on as much as anything proprietary does; the second is a claim against trade secrets, which is what most businesses are built on. I don’t think either aspect holds up in the reality of business.

Open source was never a business model in the first place. If decompilation makes binaries a weaker protection, the answer isn’t to give everything away, but to make the closed thing worth paying for, or keep it on a server where it never leaves your hands.

The “essential” arguments for OSS/FOSS/Free-Software might be a lot smaller than even their advocates realized.

Why is it so expensive to send an email?

Mon, 26 Oct 2026 17:39:11 +0000

Why is it so expensive to send an email?

Sending an email is essentially the same as making an HTTPS request. You open a TCP connection to port 25, you do a little SSL handshake, and you send some data through. Most personal computers out there can easily do this thousands of times per second, so how can companies charge $15 to send 1000 emails?! Why do I need some 3rd party company involved at all?! I used to work at Google specifically on GMail, and nothing from my little corner of the product on the “tabbed inbox” team led me to a clear answer...

Unfortunately for me, I was determined to figure it out for myself!

I mostly program with Haskell, and I call C code as necessary for things like OpenSSL and SQLite. I already had a setup for making HTTPS requests from my Haskell code with OpenSSL. I had code for working with HTTP 1.1 messages. How hard could it be to adapt this to email? To my surprise, it turns out that the actual “sending” part is not that hard. The real problem was ultimately out of my hands...

Simple Mail Transfer Protocol

Just like the original plaintext Hypertext Transfer Protocol (HTTP 1.1), there is a correspondingly goofy plaintext protocol for sending emails called Simple Mail Transfer Protocol (SMTP). The original version of the protocol involves sending a bunch of messages back and forth and back and forth between the sender and receiver. It looks kind of like a little conversation. Here is an example where I start my messages with keywords like HELO and MAIL FROM and the receiver starts her messages with status codes like 220 and 250:

(Evan opens the TCP connection)
220 mail.example.com
HELO evancz.dev
250 Hello evancz.dev, I am glad to meet you
MAIL FROM:<devnull@evancz.dev>
250 OK
RCPT TO:<alice@example.com>
250 OK
DATA
354 End data with <CR><LF>.<CR><LF>
From: "Evan from Elm" <devnull@evancz.dev>
To: "Alice from Cryptography" <alice@example.com>
Date: Wed, 21 Oct 1981 8:33:40 +0100
Subject: Big Fan!

Hello Alice from Cryptography,

I loved your collaboration with Rivest, Shamir, and Adleman
in 1977. I have been eagerly awaiting the invention of email,
so that I could express my admiration through this plaintext
transfer protocol!

Best,
Evan from Elm
.
250 OK: queued as 12345
QUIT
221 Bye
(Alice closes the connection)

So to send a single email, you originally had to do SEVEN roundtrips! And TLS did not exist at that time, so you did not even get any encryption after all those roundtrips!

That said, it is not that hard to send and receive a bunch of goofy plaintext, so I set it up and sent an email to myself. It worked! But... it showed up in spam.

Wait, who sent that message?!

The original protocol has a very serious flaw. How does mail.example.com know that I am devnull@evancz.dev and not an imposter? The original protocol lets you just claim whatever sender you want, so anybody in the whole world could easily spoof the domain and sender.

So these days you need to add some TXT records to the DNS for your domain. This way the receiver can go look up some public encryption keys for evancz.dev and confirm that whoever sent the email at least has access to the private key.

At this point I started wondering, wait, how do you prevent someone from spoofing the DNS records? Like what if the NSA and AT&T were collaborating or what if the CIA had a history of creating companies like Crypto AG to backdoor cryptographic systems from the very beginning? It seems like a problem... But hey, I just want to send an email and it looks like all you have to do is set up these DNS records.

So I set up a private key, added some DNS records, ran my emails through some OpenSSL functions, and I started sending emails again!

Now my emails were showing up in my inbox in GMail! Heck yeah! The technical details were not hard, only sort of annoying to figure out. So why does it cost $15 to send 1000 emails?!

When the database backend for Elm went into private alpha, I decided to try sending the transactional emails myself. Just some Haskell and C code making TCP connections! My thinking was that if I ever set up a hosting service to support Elm development, maybe it would be cool to handle emails as well. The whole goal of Elm is to filter out all the irrelevant details and let the programmer focus on the actually meaningful parts, so it seemed like there might be something there!

Okay, but then I noticed that the emails were only showing up in GMail. People who used Microsoft Outlook were not even seeing them in spam...

Old and Goofy Spam Filters

Once someone adds the DNS records to verify their identity, it is still possible for them to just start blasting out spam. I was not sending spam, but I was now interacting with a baroque mosaic of spam detection filters that sometimes work in funny ways.

Each email inbox provider has different algorithms for determining “the reputation” of the sender. Some inboxes are able to mostly assess the reputation of the sender’s domain. “Are the emails from this domain good?” Other inboxes seem to care more about the particular IP address. “If one domain on a given IP address is bad, maybe other domains on that IP address are bad too!” Other inboxes seem to really care about the IP address block. “If someone is sending spam from 100.0.0.0, then maybe the whole 100.0.*.* block is a problem!”

So it is possible that an inbox like Microsoft Outlook really cares about IP address blocks. Maybe they do not have a very fine-grained way of assessing individual IP addresses, or maybe this is just a good for a filter for “big business” users. I have no idea, and I have no special inside knowledge. The point is that this appears to be true for some of the many many inbox services out there. Even if it is not true this month, it may be true next month as the developers at Yahoo Mail, Zoho Mail, Proton Mail, etc. etc. adapt to whatever spammers are getting up to recently.

I host my servers with a smaller cloud provider, so I have access to whichever IP address blocks they offer. I can get a fixed IP address and treat it nicely, but again, some email inboxes seem to really care about the entire IP address block. That means that if anyone is sending spam through my cloud services provider, my whole IP address block may get blacklisted.

So finally we come to the reason why sending emails costs so much.

My Personal Conclusion

Actually setting up the code to send emails is a relatively doable one-time thing. From a technical perspective, it is essentially the same as sending an HTTPS request.

But to deliver to all different email addresses, you need to be trusted by inbox providers with the oldest and goofiest spam filters. Since some inboxes seem to really care about IP address blocks, this means you probably need to get your own IP address block. And from there, you need to send a pretty high volume of emails through it per day.

My emails went through to certain inbox providers just fine, so it must be possible for them to avoid heavily relying on IP address block blacklists. The particular feature I worked on at Google was the “tagged inbox” where emails get sorted into primary, promotions, social, updates, and forums. I never really talked to the spam people down the hall, but maybe things like the human categorization from tagged inbox helps them get a better signal on domain names such that they can rely less on the IP address block blacklists? I honestly have no idea. It was a big office, and the “more exciting” gossip mostly came from the other side of the building where the Google+ people were developing a Facebook killer in the era of “social search”.

In any case, this is where my personal exploration ended. Hopefully it helps readers who have never tried to send emails from scratch, and I will be curious to hear from the collective “spam people down the hall” if there is anything I got wrong! (I am sure there is!)

Drawing Boxes vs. Shading Them In - BiteofanApple

Mon, 26 Oct 2026 17:27:14 +0000

There are two primary kinds of human endeavor: drawing boxes and shading them in. The first defines the boundaries of behavior, culture, and discussion; it draws the boxes. The latter implements those definitions and works within those boundaries. In other words, it shades them in.

I think these two definitions can help us grapple with a lot of the current debate around the role of humans and A.I. going forward. To see how, let's first explore what I mean by shading in via some historical analogues.

Shading In

For simplicity, let's pick a story most people might be familiar with: classical physics. The broad story goes thus:

At first no one really knew why or how things moved. Aristotle had some ideas, they weren't all that useful.
Then Isaac Newton (and Godfried Liebnitz) discovered calculus and Newton coined his so called Laws of Motion. Together those two ideas set modern physics, well, into motion.
The next two centuries spawned innovators who built on Newton, abstracted his math, and applied his principles to a huge range of problems.

In this way people like Euler, Lagrange, and Maxwell built on Newton's ideas, expanding them, formalizing them, and using them to build telegraphs, and rockets, and space probes, and eventually the Internet. This is of course an over-simplification, but let's go with it.

In this formulation, Newton didn't simply take another step along the road. He defined the very foundation of a new discipline. After that countless physicists and engineers filled in the gaps by plugging holes in the theory and applying its principles to the real world. This is where the real advancement happens.

Obviously though, this change didn't happen immediately. This is because shading in takes time. It's limited by the knowledge of people in a given place and their ability to find occasion to use a new piece of tech. Of course, as all software devs learn, the actual process of building takes time too.

✉️ Subscribe to the Newsletter!

In this way, we can see that innovation broadly defined propagates as a wave from some source. The speed of that wave depends on three factors:

knowledge transmission + application discovery + implementation

As another example, think of the digital revolution. Once the World Wide Web became available to the public, it took time to build out the physical infrastructure. Then it took time to discover new techniques for building in this new world and find places where these technologies could or should be used. Finally, it took time (and a lot of money) to actually build those things we'd decided were useful.

An alternate illustration to the one shown here that demonstrates the influence of information shading in a given area of thought or realm of knowledge.
Simulation via tools from Paul Falstad.

Automations of that last step are always good. Assembly lines not only standardized output, they dramatically cut the time it took for cars to go from a drawing to a product in people's driveways. LLMs for coding and math are basically the same thing.

There has always been a huge demand for software, evidenced by its high cost and near constant growth. The world has continued to find new places to use computers and software to solve our problems and improve our lived reality. The wave of innovation created by the emergence of the personal computer and the World Wide Web has shaded in the boxes drawn by the invention of those technologies. What we're seeing now is the dramatic speed up of that innovation which is no longer so limited by the speed of implementation.

Much of mathematics (and of all human knowledge discovery) is too a game of shading in the gaps. This shading in happens gradually because of the nature of causality. Humans learn and pass on information, which takes time to do. The state of knowledge evolves over time and the gaps between knowledge slowly gets filled in. One could argue, and in fact I would, that there is a huge amount of latent knowledge sitting in the literature. So much has technically been discovered already, but no one has put the pieces together yet.

In a world where humans were part of a hive mind this wouldn't happen. The mathematician Kevin Buzzard said it differently:

If one human had an understanding of all of modern pure mathematics simultaneously, how much further would they immediately be able to see?

We do not know the answer to this question, just as we cannot know what the edge of the universe looks like right now because it takes time to get there.

In the past this knowledge has taken human effort to find, but the act of shading in the bounds of knowledge is, in some places, now a thing that can be sped up drastically by machines. Software is similar. So much software is needed to run the modern world, but it's always been limited by the amount of money and human time that could be afforded to a problem. That's still true, but the budget now goes further than it could before. Slowly we will shade in and write all of the software we need to run the modern world just as we will more quickly begin to understand the nuances and the gaps in our mathematics.

Drawing Boxes

The second kind of human endeavor is fundamentally different from the first. We can come to understand it by examining the assumptions that we made above. As I discussed in an earlier post, in order to fill in a space one must assume it is finite in size. In order to shade in an empty box, you need to draw the box!

This is the kind of thing that a machine learning tool based on human input can never do. Inherently backward looking tech can shade, but it cannot draw the boxes in the first place. It's a fundamental design flaw and one that cannot be fixed until the machines experience the world as we do. We should be questioning assumptions, defining new terms, sketching out the boxes which define new disciplines. Then we can let the boxes get filled in by our technology.

The labor of humans then is finally free from shading in. Our ability to do so has been dramatically increased and perhaps may even someday be largely automated. The thing is, this is good. There is much work left to do.

Video Credit: me

As Buzzard said in that same earlier post: mathematics is infinite. Software is too. So is almost every human endeavor. There is always more to do. Yes it's different work, but none of us farm by hand anymore, even those few people who enjoyed it. We've found new and better things to do: we breed new plants, we do landscaping, we make art, and we invented computers and trains and the internet.

Zooming Out

I don't want this to be the typical technology makes new jobs we haven't thought of yet kind of post. I don't intend that. Software as a discipline is changing. Sadly the hero-myths of the solo dev hacking on a mountaintop are truly dead, but so are the stories those were based on: those of the sage-like pagan hermits who ascended the mountaintop to attain some great truth.

From my own experience I have found that knowledge of code is now secondary to knowledge of paradigms, of data flows, of constraints, of testing, of validation, and of system design. I didn't shift, I zoomed out. It's hard to do, especially because I've built my whole career and much of my identity on the old definition of what it meant to be a good software developer, but the times have changed. What's more it's better that we can do more now. It's better we can learn more things. Our understanding of mathematics will only grow. Our ability to make software that's tested and full-featured will only increase. Our job is to sketch out the bounds of what we want the world to do, to draw the boxes we want to see filled in.

In the old world, before the computers we know today there were still computers. They were people. They crunched numbers for experienced engineers so they could focus on the bigger picture. In the end, the precise angle of the nose cone isn't all that important. It's required, sure, but it's far more important to zoom out and get the bigger picture: the orbit, its shape, the balance of fuel and weight.

I'm scared, I'll admit, but I'm also excited to see what happens now that mathematics and software can zoom out another level and focus on new problems.

For years programmers argued about tests: how to write them, what is worthwhile to test and what isn't. These are concerns you have when test writing costs money, when it takes a lot of time—peak shading in. Now it's easy to get to 80-90% coverage and it costs basically nothing. Finally, we're free! No one enjoyed that work. No one wanted to do it. Now, no one has to. We can zoom out and worry about questions we didn't have the bandwidth to think about before.

In a recent 3Blue1Brown video, Grant Sanderson touched on a similar idea. He drew the distinction slightly differently: proving theorems vs. theory building. I think this applies far beyond mathematics and software, but I'd expect software development to focus more on erecting guardrails, writing documentation, and verifying results. In other words: it'll be about theory building (documentation) and verification (proving results). If a discipline can determine how to do those two things, then I'd expect it to quickly become revolutionized. However it's a very open question if that is actually possible. What does it mean to theory-build and verify the working of a manufacturing process?

The Words Belong to Us

I say all this because I think we're in the middle of a shift in the way humans will participate in the advancement of knowledge. It could be that A.I. models like LLMs will simply improve our ability to search the space of existing knowledge: basically better web search. However we've already seen many other emergent use cases, especially in mathematics and sofware, that challenge this idea.

A.I. has the potential to improve every single part of the wave speed formula above, and so dramatically improve our ability to spread novel innovations and discover those latently sitting in our existing whitepaper hoards.

It's important to remember that these algorithms depend on words as we've defined them. This is what I mean by drawing boxes. We have decided which concepts deserve a name and we've defined our terms to describe things we think are important.

We give names to stuff, and if they catch on we put them in dictionaries with the word noun next to them. But are all of these nouns an inventory of the Universe or an inventory of things we made?
– Vsauce

As we continue to accelerate the pace at which we can implement technologies and shade in the boundaries of human knowledge, it's important to remember that, ultimately, we're the ones in control of the system because we define the boundaries of discussion. We make up the words and thereby impose our definitions on the world. That is the irreplaceable value we provide that no model can ever hope to replace.

It might feel like a very abstract role to us now, but so would be modern formal logic to the scholars of early-modern Europe who worried that a calculator would replace them. It didn't. Instead they went on to focus on more important things.

Hello? Where Is Everybody? | Brain Baking

Mon, 26 Oct 2026 17:26:57 +0000

The shopping centre we find ourselves in also has an IKEA nearby. My daughter & I pop in to walk through the isles that house the teddy bears. She picks out a giraffe that now lives by the name Giraffa or just Raffa. For once, we don’t really need anything else in this lovely Swedish store so we head downstairs to find the checkout registers. Instead of encountering a friendly face that helps with the payment process, we’re greeted with closed registers resulting in too long lines. The only open ones are self-scanners. There goes the possibility for some lightweight banter.

Our fridge is empty. We bike to the nearest supermarket for some quick midweek resupplies. No long queues this time, but just as little employees waiting for us at the checkout: only the occasional self-scan verification makes chitchat possible. I see that they closed yet another “human checkout lane”. The System Works.

On one of the campuses where I teach, as part of an experiment, a small physical Amazon store has been opened. This is one of those weird zero personnel stores where everything operates through cameras and image recognition. It feels creepy to even be there. It was also ridiculously expensive and the experiment has been put on hold, but during my trip to the USA I encountered more of these… things? Supply factories? Stores? I don’t know what to call them.

My ISP is giving me a headache by wrongly configuring something in the remote-controlled router. This wasn’t the first time it happened, but this time, I can’t seem to fix it myself. So I dial the free support number, only to be greeted with too many robot-controlled menu options. Press 1 for Dutch. Press 2 for other requests. Press 3 if you really really need to really talk to a human—are you sure? Press 6 to confirm. Press 7 to confirm. Please wait 20 more minutes.

After ten minutes, I disconnect in frustration and turn to the internet. There’s a FAQ page, a support page pointing to the FAQ page, and of course a lovely genAI-controlled chatbot. After “reasoning” (ha!) with the bot for a few minutes, it suggests to call the number I already called 30 minutes ago. I try to look for an email address but can’t find one. My fuck this, I’ll solve it myself attitude ultimately fixed the problem at the cost of a portion of my social self.

I mentor a couple of students working their way through various internships in the IT industry. As the point of contact for the school, I head over there three times: an initial conversation to set the stage, a quick check-in to validate if everything is still going well, and a more formal evaluation meeting to hand out grades together with the employer. I look up where I need to be, bike over there, find the correct building but not the correct floor. I missed the info desk at the entrance—oh wait, it’s just… not there. There’s also no information on the elevator as to which company operates on which floor.

I eventually find the info I need in a hallway and arrive at the reception desk of the company. Again, nobody home. I can see people clutched behind their laptop in adjacent rooms through the windows. I resist the urge to wave and look around. The glass door towards the company’s hallway is locked. There’s an iPad bolted on the reception desk where I have to register myself. The form demands my email address (I provide my work one as they have it anyway) and a telephone number (Yeah right! What about 123456789?). It states my contact will pick me up soon. I wait. I again resist the urge to wave.

After 10 minutes, the person picks me up and walks me towards the meeting room. I mention the awkward impersonal registration process; he assures it works perfectly. As a software professional myself, knowing the many points of failure, I don’t believe him. He admits to being a bit later because the system works with Slack messages but he was monitoring the wrong channel. I wished I did wave.

This depersonalising of receptions to “optimise” employee efficiency leaves a very bad taste in the mouth of the visitors. I biked home confused and still feel a little sad when thinking about it. How hard can it be to put a human there to, you know, greet the visitor with, you know a smile instead of an iPad that demands personal data that’s not relevant to the visit? In the form, I had to select my contact person (that gets notified with a Slack message) which is a simple <select/> that revealed every employee’s first name and last name. Oops?

On top of that, the “the person is notified, sit back and relax!” wasn’t relaxing at all: I know how async backend messages work: the frontend shows “relax dude!” but the backend says 500 and your message never reaches the contact person. Just raise that hand. Wave. If a receptionist calls someone, I can hear them making the call and I know I can relax: the message has been passed. Smile.

Hello? Where is everybody? This evolution depresses me. I want to see real (not generated) faces and talk to someone real (not generated). The rise of these annoying CAN I HELP YOU WITH ANYTHING?? chatbots on corporate websites replacing a simple contact form only adds to the irritation. I can certainly relate to the increased amount of spam received through these forms, but I pay you every month enough to keep the lights on. The least I expect in return is a humane customer service experience.

braindump

「做个人」 – So!azy

Sun, 25 Oct 2026 17:05:38 +0000

「做个人」

25 Oct, 2026

前阵子在路上听了一期「日谈公园」的播客，请的嘉宾是我一直很喜欢的文学教育工作者赵毓龙。那期节目聊的是明清小说里的生日宴，顺着话头讲到了《金瓶梅》第二十九回「吴神仙冰鉴定终身」。

书里的场景是这样的：守备府周大人派人给西门庆送来一位游方道士吴神仙，说是能通风鉴、善究子平。西门庆当时刚满 29 岁，正是鲜花着锦、权势日盛的当口。吴神仙先给他排了八字，一通好话铺垫下来，说他目下有「平地登云之喜，添官进禄之荣」，紧接着又得贵子。西门庆自然受用，追问往后的运限。吴神仙便交了实底，说他八字里阴水太多，往后到了甲子运，「不出六六之年，主有呕血流脓之灾，骨瘦形衰之病」。

六六之年就是 36 岁。换作任何一个正常人，在 29 岁的年纪听见算命先生说自己活不过 36 岁，哪怕心里不信，脸上多少也得挂点霜。但西门庆的反应非常耐人寻味。他没有深究那句要命的判词，反而紧接着问了一句「目下如何」，以及「命中还有败否」。吴神仙顺着他的心思回道，眼下家里那点小吵闹不足为灾，至于家业衰败，「年赶着月，月赶着日，实难矣」。书里紧跟着写了七个字：「西门庆听了，满心欢喜。」

读到这里，我们很容易生出一种优越感，觉得这人怎么蠢得如此彻底。人家明明已经在暗示你纵欲过度、日后要精尽人亡，你却自动过滤掉死期，只把那句「呕血流脓」当成日后难免的一场小灾，只要眼下官运财运不败，就敢「满心欢喜」。

赵毓龙在节目里聊到这一段时，抛出了一个让我印象很深的判断：看书和看人一样，得「做个人」。

什么叫「做个人」？就是别总站在已知结局的岸上，用毫无成本的聪明去嘲笑水里的人。我们作为读者，手里攥着整本书的目录，开了上帝视角，跟西门庆那点家业、官位和声色犬马没有任何利益牵扯，自然能一眼看穿吴神仙的话中意。但如果你把上帝视角收起来，真正钻进西门庆的皮囊里看一眼：一个 29 岁的暴发户，刚刚打通了京城蔡太师的关节，眼看就要加官进爵，家里妻妾成群，银子像流水一样进账。在这个节骨眼上，你让他去相信自己再过几年就要骨瘦形衰而死，这在人性上是根本做不到的。

人永远只能听见自己想听的话，更准确地说，人只能听见和自己当下处境相匹配的话。所谓的「当局者迷」，从来不是因为局里的人智商突然掉线了，而是他被巨大的既得利益、感官刺激和惯性推着走。在那个具体的场域里，承認风险意味着要立刻推翻自己赖以生存的快感来源，这种代价太大了，大到大脑会自动启动防御机制，把致命的警告翻译成无伤大雅的插曲。

我后来琢磨了一下，发现我们在日常工作和生活里，其实每天都在犯这种「不做人」的毛病。

比如在业务复盘或者跨部门协作的时候，我们特别容易扮演那个冷眼旁观的读者。当一个项目彻底烂尾，或者一个明显的隐患最终爆雷，总有人跳出来摊手，说「我早就看出来这条路走不通」，或者「这么低级的坑怎么会踩进去」。站在事后，或者站在不背核心 KPI 的外围，谁都能当那个口吐莲花的吴神仙，把逻辑链条拆得滴水不漏。

但这种聪明是很廉价的。你之所以看得清楚，往往只是因为你不在那个火坑里。你不需要在每天下午 6 点前面对客户的连环追问，不需要在资源极度匮乏的前提下强行拼凑出一个可交付的方案，也没有被某种短期的业绩虚荣冲昏头脑。当你不承担对方的恐惧、贪婪和考核压力时，你给出的那种居高临下的指点，本质上就是一种缺乏边界感的傲慢。

反过来想，赵毓龙说的「做个人」，在我的工作方法论里，其实对应着一种更冷酷也更务实的判断力。

承认人性在具体处境下的局限，不是为了替烂结果找借口，也不是为了搞无原则的共情。正因为我知道一个人在顺风顺水或者极度焦虑时，必然会像西门庆一样选择性失聪，我才彻底放弃了靠「苦口婆心的提醒」去改变他人的幻想。

在职场里，如果你发现一个人正处于某种狂热的惯性中，或者正在用极其拧巴的方式掩盖问题，你去跟他讲长远的风险、讲底层的逻辑，大概率是对牛弹琴。他也会像西门庆问「目下如何」一样，只要眼下能糊弄过去，他就会继续「满心欢喜」地往前冲。

想明白这一点之后，我处理类似局面的方式变得简单了很多。

第一，在评价别人之前，先看一眼他的筹码和处境。如果我不在牌桌上，没押上身家，我就闭嘴，不赚那份事后诸葛亮的口舌便宜。第二，如果我是那个必须为结果兜底的人，我就绝不把希望寄托在当事人的「自我觉醒」上。既然知道局中人注定会过滤掉警告，那就别费劲去做吴神仙，直接用机制、权限和明确的止损线去切掉他的惯性。

看透一个人的局限而不去嘲弄，这是教养；知道局限无法靠说教克服，于是直接动手改规则，这是专业。所谓的「做个人」，大概就是把这两件事分清楚。

#daily

为什么有人不怕把事做砸 – So!azy

Fri, 23 Oct 2026 17:48:17 +0000

为什么有人不怕把事做砸

23 Oct, 2026

昨天写完《睡得着觉的人》，我其实还有个问题没往深处想：面对自己交出去的烂摊子，为什么有些人不仅睡得着，甚至能长期容忍自己处于这么差的状态里？

按常理说，人是有羞耻心的。做出不体面的东西，哪怕别人不骂，自己看着也该觉得刺眼。但在实际共事中，我确实见过不少对「差」完全脱敏的人。我后来琢磨了一下，那些能心安理得跟自己的糟糕产出共处的人，大抵逃不出下面这两类。

第一类，是永远有退路的人。

很多年前，我其实不太相信这个世界上真有一路走来没受过什么苦、也没遇到过真正困境的人。但最近这几年，我在职场和生活里实打实撞见过好几个。他们有着非常顺遂的童年，家境殷实，从小到大被保护得极好。跟他们打交道，你能明显感觉到一种天真的松弛感。在他们的认知里，真实、快乐、美好就像是这个世界理所应当提供的空气，是出厂自带的默认设置。

这种顺遂给他们垫了一层极厚的底。不管眼下在社会里遭遇了什么挫折，或者手头的工作捅了多大的篓子，他们的潜意识里始终有一个声音在兜底：我其实没必要那么拼，大不了就不干了。

因为有随时离场的底气，工作对他们来说更像是一场体验，而不是立身之本。把事情搞砸了，不会触发他们的生存危机，自然也就引不起足够强烈的羞耻感。你跟他们讲职业底线、讲交付标准，在他们听来可能就像是在一个周末下午非要拉着人跑马拉松一样不可理喻。他们不是故意要当坏人，只是单纯没有那个把事情死磕到底的生存必要。

如果说第一类人是因为「不痛」所以不在乎，那第二类人就纯粹是缺少敬畏之心。

这类人我早在 9 月份写《敬畏之心》的时候就提过，今天还是忍不住要再拎出来说。他们在职场里通常表现得极其自信，甚至可以说是盲目乐观。不管接手多复杂的事，第一反应永远是「这有什么难的」。

但我一直觉得，正常的逻辑应该是，一个人的能力和认知积累到了某个水位，看待问题清楚了，手里有活儿了，那种笃定的状态自然就出来了，根本不需要再去刻意建立什么自信。而这些人完全把路径搞反了。他们在既没有专业能力、也没有基本行业认知的时候，先把「自信」给备齐了。甚至我觉得用「自信」这个词来形容他们，都是对这个词的一种抹黑。

因为对事情的复杂程度毫无概念，对专业性没有半点敬畏，他们根本看不见自己做出来的东西和真正的好东西之间隔着多远的距离。一个连「好」都没见过、也不承认有「好」存在的人，你指望他因为自己做得「差」而感到羞愧，本身就是一件不可能的事。他们看着自己满是漏洞的交付物，心里想的可能还真是「我已经做得很完美了」。

想明白这两点之后，我反而少了很多无谓的愤怒。

以前遇到那种把活儿干得稀碎还能谈笑风生的人，我总会下意识想去纠正，想拉着对方复盘，试图唤醒他们身上的那点职业自尊。现在我完全放弃了这种念头。一个人的退路是家庭给的，一个人的盲目是长年累月的认知缺陷喂出来的，这都不是靠一两次绩效面谈或者几句重话就能扭转的东西。

在合作和招人的时候，我现在只看一个很朴素的指标：这个人到底痛不痛。他会不会因为一个低级错误在深夜感到焦躁，会不会对未知的领域保持一点点试探的谨慎。如果没有，不管他看起来多么阳光开朗，或者在面试时表现得多么有冲劲，我都会选择直接绕开。毕竟大家出来工作是为了把事做成，不是为了给有退路的人提供游乐场，更不是为了给盲目的人交学费。

#daily

Please don't mess with links:

Fri, 23 Oct 2026 07:14:53 +0000

Please don't mess with links:

2026-05-31

A link is just a button that takes you somewhere when you click it right?

100% legit link

Except that's a pale, shallow imitation of a link. A real link can be:

Opened in a new tab. (ctrl)
... or a fresh window. (shift)
... or saved as a file (alt).
Copied as a URL (right click)
Used with the keyboard (tab + enter)
Seen by tools like search engines and screen readers.
Hovered over to see the URL.

... none of which work with a button.

Another common offense is to use a real link, but hook the click event to open a popup. However, with a real <a target="_blank"> link, I can:

See the loading progress...
... or/and cancel it.
... see descriptive error pages and retry if needed.
Open multiple at once.
Read the original page while it loads.
Use my browser's tabs or/and window manager to organize them.
Bookmark the page.
Copy the URL and send it to a friend.

... and above all, they are consistent:

I've long lost count of how many times I've accidentally closed the whole site while trying to close a popup that was a little too convincing.

It's also extremely common to click a link with a slow connection, only to be greeted with perpetual spinner. I have no idea if anything is actually happening or how long it will take. Worse, it usually covers up the original page so I can't even read that!

Browsers are good at links and loading pages: It's the whole point.

Don't use javascript buttons as links.
Don't build your own loading animations.
Link previews should open and close on hover, not on click.
Don't open links in javascript popups: Use target="_blank" instead.

Sending a Silly Meme Is an Act of Love

Thu, 22 Oct 2026 16:15:25 +0000

At this moment, an untold number of TikTok videos are being sent without commentary to an untold number of group chats. The videos might remind the senders of their mom, their spouse, their high-school best friends. They might strike the recipients as charming—or as smartphone pollution. The meme-sharing never stops.

People have been sending one another memes nearly as long as the web has been worldwide, gathering amusing bits of internet ephemera and texting, emailing, or sharing it on social media with their loved ones. Before it was TikToks and Instagram Reels, it was I Can Has Cheezburger? links posted to Facebook walls. (Even before the internet existed, people engaged in meme-sharing-like behavior: your grandma clipping articles from the newspaper that she thought you might like, for instance.)

As communication goes, sending a meme is one of the lowest-lift—one might even say laziest—ways to stay in touch. It’s barely a step above not saying anything at all. But a surprisingly large body of research on meme-sharing has found that it can serve an important function in relationships and bring people closer together.

According to Adam Grant, an organizational psychologist at the University of Pennsylvania, sending memes can be a form of “pebbling”—a term that he, appropriately, saw on social media. It refers to a behavior among gentoo penguins, in which they present potential mates with carefully selected, shiny pebbles. Among humans, giving the gift of a carefully selected, shiny meme can be a mating behavior, too, or a platonic one.

[Read: The meme that defined a decade]

“These aren’t trivial gestures—every pebble is a bid for connection,” Grant writes in his new book, Vibe: The Secrets of Strong Connections in a Lonely World. Clicking “Share” on a funny Instagram post is hardly on the level of inviting a friend to dinner, as bids for connection go. But neither is it nothing. At minimum, it’s a way of checking in and reminding someone of your relationship. Nicholas Brody, a communication-studies professor at the University of Puget Sound, told me that in unpublished data from his research, he’s found that the most common reason people said they sent memes was just to convey “I’m thinking of you” to the other person.

But for many, the meaning can be deeper than that. People really tend to curate what they send to whom, experts told me, picking and choosing the pebbles that they think the other person will like. For me, cat videos go to my husband, Lord of the Rings memes to certain friends, nostalgic posts about emo music to different friends, posts about literary drama to my writer friends. This is a way of creating and reinforcing a shared reality, one study on the interpersonal use of memes found, a sense that we are both on the inside of the specific microculture that is our relationship. (Even those who aren’t meme-sharers themselves do this in many other ways, through inside jokes and private language.) Memes work well for this purpose because they “are so nuanced, and have so many different layers of cultural references and relational meanings,” Brody told me, “that they only really have a lot of power when we already feel really close to somebody.” Indeed, his research shows that people mostly send memes to people they know well—to romantic partners and close friends.

The best-case scenario is that a meme opens a door to further sharing. For instance, Grant told me that he recently sent a friend from high school a post of a funny prank he saw—not only because he thought they would appreciate it, but because they themselves were pranksters when they were young. The post launched them into reminiscing about how they used to mash bananas into the door handles of a friend’s car in high school. Rachel Peng, an assistant professor of digital advertising at Louisiana State University, told me that she was inspired to research meme-sending because of her own experience with social anxiety. “Sometimes I send memes,” she said, “to start a conversation. Or sometimes I don’t know what to say but I also want to keep the conversation going.” And even though people tend to use memes most with their nearest and dearest, her research has found that they might be even more beneficial among acquaintances. When you’re just getting to know someone, taking the time to pick out something that reminds you of them is a bigger gesture—even more so if it sparks more back-and-forth.

[Read: Forgive the bad texters]

But what if the meme receiver doesn’t respond with fond reminiscences? Some Instagram DM threads become wildly lopsided: one person sending meme after meme, the other hearting no more than every tenth one. That sort of thing could be annoying. “There is such a thing as spamming people with random junk from the internet,” Grant said. But if the memes are lovingly curated, it could still be a net positive for the relationship, even if the meme receiver just chuckles privately without responding. “If we both get the joke, it’s still a bit like a little moment of connection, right?” Peng said.

“One of the key things in relational maintenance is that we want assurances that this other person values our friendship and our relationship just as much as us,” Brody added. But “it doesn’t always have to be a meme for a meme.” Just remember that if your friend sent you 15 memes in a day, it means they thought of you 15 times that day. So drop them the occasional lol or heart emoji just to show you’re thinking of them too.

Rendering untrusted HTML email, safely | The Making of Close

Tue, 20 Oct 2026 17:06:04 +0000

One of the earliest core features we built in Close was our email sync feature, which allows Close to automatically pull in email communication between your sales team and your sales contacts and display them for your team to see. We present a unified timeline of all communication (emails, calls, SMS, etc.) with a sales lead in one place for your team.

This feature required that we build a way to display email in our web app – safely, without security concerns that typically come with naively rendering untrusted HTML (Stored XSS Attacks).

We launched our ability to display synced HTML email in 2014, however the technical side of it is still very relevant and (I think) interesting since our approach is not one that I've seen widely used.

In the end, we found a way to, exclusively on the client-side (in web browsers), render untrusted HTML email safely inside our single-page application (written originally with Backbone.js, now mostly React). Here we'll discuss a few approaches we had to consider and how we solved this problem.

For example, we can display an IMAP-synced email thread like this:

HTML vs Plaintext?

While many emails do come with a plaintext variant, we had to immediately dismiss the idea of only displaying plaintext email, as convenient as that would have been from a security perspective. Many emails don't have a reasonable plaintext alternative, and users simply expect to be able to view HTML formatted email as they were designed.

Some emails only have a plaintext variant. In those cases we can render the plaintext content pretty simply in our web app: effectively just convert new lines into <br> tags and convert URLs into links.

But most of the interesting engineering/security concerns are around rendering untrusted HTML content (in this case, email content) safely, which is where the remainder of this blog post will focus.

Main goals and concerns

Our main goals were the following:

Display HTML email, not just plaintext
Display "full" HTML email. We care about much more than just a few simple tags like <b> and <i>, but rather want to support displaying sophisticated email styles (including custom style tags) that you often see in well-designed HTML email newsletters, calendar invitations, etc.
We want to render emails within our web application, without any conflicts of our CSS leaking in or the email CSS leaking out.
In addition to CSS styles, we also want to display images, expect links to work, etc.
Most important: Do not let any JavaScript run. Otherwise we run the risk of an attacker taking over our user's Close account by stealing cookies, or a number of other Very Bad™️ things.

Finding a solution…

Saying No to HTML Sanitization

While there may be some rock-solid libraries out there that can take untrusted HTML content and make it completely safe for rendering in HTML, there were a lot of potential downsides to this idea.

First off, in 2014, we didn't immediately trust any of them. HTML sanitization libraries often rely on parsing HTML with regex, which is a notoriously bad idea. We absolutely didn't want to be trying to maintain a library like this ourselves, or have to worry about some unhandled edge case that could lead to a major security vulnerability.

Additionally, unlike other use cases (e.g. rendering a blog comment which may contain just some basic markup for bolding text), we felt like we needed to render complex (heavily styled) HTML emails properly, just like you'd see in Gmail or other modern email clients, so we couldn't default to a tiny whitelist of tags or supported attributes.

Finally, HTML sanitization on its own wouldn't be enough, because we want to render the email within an existing web app, and we don't want its styles affecting the styles of the rest of the web app. There's a well-known solution to this – iframes – that we could have used to help here.

Once we explored iframes, however, we realized they could do everything we needed already on their own…

What can iframes do for us?

Most web developers know that an <iframe> can render a web page in a fairly isolated fashion. Certainly they can solve the issue of our web app styles incorrectly affecting an email's styles (or vice versa).

But we still have that pesky issue of JavaScript.

Uncommon but helpful iframe attributes

There are a number of lesser known iframe attributes that can be very helpful. Let's take a look at a few.

`srcdoc`

Most commonly iframes point to a src webpage URL – either on the same origin or different origin. But since Close is a Single Page Application and our frontend would already be fetching data about the email from our REST API (and could include the email body itself), we discovered that this attribute allowed us to inject HTML content into an iframe (with all the typical iframe benefits) without needing that content to be served by a separate page.

So rather than having to do something like:

<iframe src="/email/body/?email_id=EMAIL_ID_HERE">

... which would have required us to setup an additional endpoint, we could simply display the HTML we already had:

<iframe srcdoc="UNTRUSTED_HTML_HERE">

Neither approach is particularly more or less secure than the other. Both make you still think about "what about script execution" and consider the "same origin" vs. "different origin" options (e.g. we might have needed a separate domain and then have to pass some kind of token for authentication). We chose srcdoc because it worked and was easiest for our setup.

For the value that we inject into the srcdoc, we actually wrap the HTML email in a little HTML, with two main goals:

Give email bodies some sane default styles, and make them fit into the look-and-feel of our web app by default.
Put target="_blank" on all links by default (via a <base> tag), since we never want a user clicking an email link to load a new webpage in the iframe, and this is also a convenient way for us to apply this behavior to all links without having to traverse the email's HTML.
Apply a Content-Security-Policy <meta> tag instructing the iframe document to avoid executing any JavaScript whatsoever. (If we used a hosted page with src instead of srcdoc, this would be done with an HTTP Header instead).

<html>
  <head>
    <meta http-equiv="Content-Security-Policy" content="script-src 'none'" />
    <base target="_blank" />
    <style>
      body {
        margin: 0;
        font:
          13px -apple-system,
          system-ui,
          'Segoe UI',
          Roboto,
          Oxygen-Sans,
          Ubuntu,
          Cantarell,
          'Helvetica Neue',
          sans-serif,
          'Apple Color Emoji',
          'Segoe UI Emoji',
          'Segoe UI Symbol',
          sans-serif;
        overflow-y: hidden;
      }
      html:not(.x),
      body:not(.x) {
        height: auto !important;
      }
      p:first-child {
        margin-top: 0;
      }
      p:last-child {
        margin-bottom: 0;
      }
      a[href] {
        color: #3781b8;
        text-decoration: none;
      }
      a[href]:hover {
        text-decoration: underline;
      }
      blockquote[type='cite'] {
        margin: 0 0 0 0.8ex;
        border-left: 1px #ccc solid;
        padding-left: 1ex;
      }
      img {
        max-width: 100%;
      }
      ul,
      ol {
        padding: 0;
        margin: 0 0 10px 25px;
      }
      ul {
        list-style-type: disc;
      }
    </style>
  </head>
  <body>
    ${bodyHtml}
  </body>
</html>

`sandbox`

This attribute is the heart of our security model. By adding this attribute, it adds a whole bunch of restrictions to the iframe document, including preventing any JavaScript from running! Learn more about what's blocked here and here. The sandbox attribute allows you to opt back in specific behaviors that are blocked by default. We only allow:

allow-popups – We add target="_blank" to all of them.
allow-popups-to-escape-sandbox - So that external webpages opened via a link actually function properly.
allow-same-origin – We need this for our web app to detect the height of iframe's content. This would be dangerous (and defeat the purpose of sandbox) if we also allowed scripts to run by also including allow-scripts, however it's harmless on its own.

`csp`

We add a Content Security Policy to the iframe with a value of script-src 'none' as an additional mechanism to avoid any JavaScript from running in the iframe. This is mostly duplicative with sandbox but provides an extra layer of protection in browsers that support it.

As you can see, we have some overlap in coverage here (e.g. 3 separate features to avoid JavaScript running). We have learned of particular browser bugs where there were temporary limitations in any one of these indvidiual approaches. A reminder that security in layers is often best.

Bringing it together...

Handling unsupported browsers

As soon as we made the decision to rely on <iframe sandbox> as our primary safety mechanism, we also had to consider users with browsers who didn't have this safety mechanism, so that we didn't put their accounts at risk. Feature detection to the rescue:

// Don't show HTML at all if they are using a browser that doesn't support <iframe sandbox>
// since our security model relies on it to prevent XSS.
// (And the basic functionality relies on <iframe srcdoc>)
const iframe = document.createElement('iframe');
const isHtmlEmailSupported = 'sandbox' in iframe && 'srcdoc' in iframe;

Based on this, we can make sure we only display the plaintext email variant (if one exists) or else render a message like "Your browser does not support displaying email content."

Known limitations

One can envision additional enhancements where we would want to parse and modify the email HTML before rendering it. One example would be if we wanted to try to rewrite and proxy all image URLs (similar to Gmail) to protect our users' privacy.

Similarly, we do have a problem where browsers will show a Mixed Content warning (since our site is https://) after you display an email that includes an <img> with an http:// src. Those warnings are still fairly unobtrusive, however, but ultimately we should proxy them to be served over https.

So while we may one day layer in additional HTML parsing measures (either client-side or server-side), and could decide to switch from an <iframe srcdoc> to <iframe src>, the other security features mentioned here would still likely play an important part of safely rendering HTML email.

Lots of other details to get right

There were a lot of other details to get right. Each of them could deserve their own blog post, but here is a summary:

We have to convert "inline" images (images that are embedded within the email itself, not referencing an external URL) to be displayable by the web browser.
We have to deal with understanding quoting parts. We wrote quotequail for this. (Mailgun later open sourced a similar library called talon). You can see in the screenshot at the top of this post a little "..." button where the quoted part of the email is collapsed by default, but expandable.
We want to avoid the "extra scrollbar" issue you typically experience with iframes, so we carefully (this is surprisingly tricky) detect the height of the iframe email contents and then set the iframe to that height, giving it a seamless look on the page.
We need to consider how composing email works too. We needed a WYSIWYG editor for HTML Email that also prevents any XSS. We currently use Froala Editor for this, after having tested many editors for security.

Thoughts?

Can you find any flaws in our email rendering security model? Our product and approach has been audited by third party security firms, however we always appreciate any reports of security vulnerabilities at security@close.com.

Feel free to hit me up at @philfreo with any comments or questions!

– Phil Freo

Do web components have a future if nobody is writing them? | Read the Tea Leaves

Tue, 20 Oct 2026 04:50:11 +0000

With my previous post on “using the platform”, I was surprised that the comments on Hacker News and Lobsters tended to veer toward web components. This surprised me because I didn’t mention web components at all in the post.

I was less surprised when I did some research and found that the entire “use the platform” mantra was first popularized by Polymer, which was Google’s early attempt at a web-components-based JavaScript framework. In 2018 they even called it “our motto”! So this explains why a lot of people seem to have it burned into their brains that “use the platform” means “use web components.”

Now, one of the reasons I didn’t mention web components in the post is that, in my opinion, they’re actually not a great example of “use the platform” (regardless of the motto’s origins). I instead leaned on examples of HTML and CSS features that tend to be more performant, more accessible, and require far fewer lines of code than the equivalent in JavaScript. This is largely thanks to the advances that the browser vendors and standards bodies (e.g. the CSS Working Group and Open UI project) have made in the past few years.

Modern Web Guidance

Web components popped into my head again, though, after a comment on Mastodon pointed me to Google’s Modern Web Guidance. I wasn’t aware of this tool before writing the post, but essentially it’s a set of skills that you can give to an agent to nudge them in the direction of using more modern browser features. Essentially, it’s “use the platform” for agents (or at least the Chrome team’s vision of it).

As I was watching the demo, though, I was struck by how hard it is to see where web components fit into the picture. In the presentation, Phil Walton shows how you can use Modern Web Guidance to create a web app that feels more like a native app in terms of following your finger smoothly as you touch the screen, thanks to features like CSS scroll snap points and scroll-driven animations.

But nowhere in the demo are we really seeing the code – this is pure vibe-coding. And as I watched, I struggled to think of any place where, if I were building Modern Web Guidance myself, I would put instructions to tell the agent, “Hey, you should use custom elements, shadow DOM, or other web component primitives here because it’s going to make the end user experience better.” And that’s because there’s nothing that web components can really do to make the end user experience better. (Arguably you could say that shadow DOM improves CSS performance, but I’ve benchmarked this to death, and you can effectively get the same boost with compile-time CSS scoping, which many frameworks and tools like Svelte, Vue, and Tailwind are already doing.)

So I took a look at the actual code for Modern Web Guidance, and my hunch was confirmed: web components feel like an afterthought. For the first six months of the project’s lifetime, there was almost no mention of web components. This only changed 3 weeks ago when a single commit landed, which mostly provides guidelines for those already using web components, around the topics of accessibility, pre-rendering, styling, etc. But nowhere does the Modern Web Guidance strongly recommend the agent to use web components – in fact, there’s a whole section titled “Decide whether you even need a custom element” which sounds downright discouraging at times. As written, if you throw the Modern Web Guidance at an agent building a brand-new product, it seems unlikely to me that it would choose to use web components.

To be fair, there is one exception: a line for Chrome extension authors recommends using shadow DOM for complex UI injected into a page. This seems perfectly sensible to me, although it’s a fairly narrow use case. Another line suggests using web components for “design systems, embeddable widgets, and self-contained UI,” but this is also fairly narrow, and reads to me as a faint nod within the larger context of “decide whether you even need a custom element.”

Web components at a crossroads

So where do web components fit into this new AI coding world? I’m not going to rehash all my points about web components’ strengths and weaknesses; I’ve already done that at considerable length. Instead I want to talk about what’s new if people are no longer writing the code (or increasingly, even reading it).

This section was painful for me to write, because I spent years working on a web-components-based framework (LWC), participating in the Web Components Community Group and Accessibility Object Model group, and defending web components on my blog, in podcasts, etc. And yet I have to acknowledge that their core value proposition have been severely weakened by agentic coding.

In short, web components were designed for a world where people typed HTML by hand, code was scarce, and thus reuse was an economic necessity. None of those things are true anymore, or at least they’re much less true and becoming less so by the day. So the elevator pitch of “build for a common standard and your components will be easier to pick up and reuse” becomes less compelling as more and more people are vibing UIs from scratch on top of a largely invisible platform substrate.

This doesn’t just devastate the value proposition of web components: it also impacts the JavaScript frameworks that inspired them. Increasingly I read about teams rewriting their entire frontend from one framework to another, based largely on the vibes of “it’s probably better for agents.” Regardless of the merits of these rewrites (which I think ought to be more evidence-based along the lines of “it uses fewer tokens” or “it’s a faster end-user experience”), we’re likely to see more of them in the future. And if people start seeing the framework layer as disposable, it seems unlikely to me that they would assign much value to the layer one step below that.

As I argued in a 2023 post, component libraries were already moving from a “batteries-included” model to a more “DIY” mindset. The apotheosis of this is shadcdn, which might seem like a machine for spitting out reams of boilerplate, but in a sense, that’s the point. Rather than make your touchpoint with a component system an inflexible API that resists your attempts to style or tweak it, you import the individual bits and pieces and then rearrange them at your will. This shift was already underway before AI coding, and now with LLMs “reams of boilerplate” are an advantage rather than a detriment. And none of this plays to the strengths of shadow DOM, reflected attributes, or other web component mainstays.

Salvaging web components

There are two (slightly weak) cases I can try to make for web components in this new world of AI coding.

The first is so-called micro-frontends, or the idea of separating a large UI into multiple sections that can be built by different teams without clobbering each other. Web components were explicitly designed for this scenario: avoiding “friendly fire” (in Brian Kardell’s memorable phrasing). In a world of agents, this kind of sandboxing is actually a well-known technique, because typically you want to isolate agents into strict boundaries to avoid them rampaging on top of each other. In other words, web components could theoretically allow you to have multiple swarms of agents working on separate parts of the UI without their CSS, events, or globals clashing with one another.

The obvious counterpoint is that the web already has a great sandboxing primitive, which is iframes. Iframes offer even firmer boundaries than web components: not only are components isolated from each other, but they also live in separate JavaScript realms with postMessage as the only communication channel. There are several tradeoffs that I don’t want to get into here (synchronous vs asynchronous communication, memory usage, the porousness of closed vs open shadow DOM), but I do think web components have a chance in this fight. (Arguably, the Modern Web Guidance’s “design systems and self-contained UI” are also examples of micro-frontend-like scenarios where web components can shine.)

The second argument is that reuse still matters even when rewrites are just a prompt away. For example, I still believe that my <emoji-picker> element is a good poster child for an effective web component: there is no reason to rebuild this thing in React, Vue, Svelte, and a dozen other frameworks, even though you could trivially do so with an LLM these days. It’s a standalone, client-only component, and most of its complexity lives in managing the emoji data, IndexedDB, etc., with little need for touchpoints with a framework to manage its rendering or lifecycle. So packaging it as a web component and allowing folks to wrap it in their framework layer of choice (or none at all) is still a sensible distribution model.

Arguing against web components as a lingua franca for reuse sounds (to me) like an argument that all code sharing or even open source in general is a waste of time in the agentic era. My colleague André Staltz has shown that this is clearly false: if anything, AI coding is increasing the amount of shared code, not decreasing it. Even if you can rebuild something with agents, that doesn’t mean that it’s worth spending the tokens to do so. (Although I do still wonder about smaller projects.)

The stronger counterargument is that agents already have a perfectly good component reuse layer, which is React. I don’t believe this, though, because I don’t think that React is the last JavaScript framework the world will ever need. Performance benchmarks like the js-framework-benchmark and isomorphic SSR benchmark still stubbornly argue against React adoption: as it turns out, the virtual DOM is still pure overhead. React could certainly reinvent itself for the agentic era, but I imagine this could lead to compatibility problems that would argue more strongly for web component adoption, if for no other reason than to get off the update treadmill.

Still, I think the strongest argument of all is that neither web components nor React nor any other framework really matter, except maybe as a footnote in someone’s AGENTS.md or an aside in an agent’s thinking process. Recently I vibe-coded a small app for my wife, and the agent mentioned that it was wavering between Preact and Svelte before finally settling on Preact. To be honest, I didn’t care at all because the app worked and solved the problem at hand.

Conclusion

I still have a soft spot for web components, and when push comes to shove I’ll happily defend them against any detractors.

There’s even a web component on this very site! The theme picker above is an “HTML web component” (or “light DOM component”), which I find quite nice as an alternative to the old-school “HTML with jQuery sprinkles” approach. Defining setup logic in connectedCallback just feels cleaner to me than awkward querySelector acrobatics. That said, I’ll admit that I had to explicitly tell my agent to use a web component (otherwise I’m certain it would have just shrugged and reached for querySelector).

Despite my sentimentality for web components, though, I think that the web component advocates working on standards, frameworks, or browsers will have to work twice as hard to argue for their relevance in an AI coding future. I no longer have a dog in this fight, but I looked at the status of some longstanding problems with web components and was disappointed to see that server-side rendering, stylesheet sharing, and accessibility still appear to be unsolved. These kinds of flaws – which mind you, directly impact the end-user experience and are thus unchanged with AI coding – will have to be fixed if web components want to have a fighting chance.

If web components don’t survive, or they wither away to forgotten infrastructure on a minority of websites, then what will they have accomplished? Well, I do think that one unambiguous victory for web components has been in “explaining the platform.” This was one of the original goals of web components: taking a native HTML element like <video controls> or <details>/<summary> and explaining how web developers could build it themselves from platform primitives. And in fact if you look at the browser DevTools, you’ll even see “user-agent shadow DOM” hiding inside these elements.

The user agent shadow root for <video controls> in Chromium DevTools.

So from a standards and internal-consistency perspective, web components have been a clear win. They provide a degree of coherence between userland and the platform that, without them, might have felt ad-hoc or inconsistent from browser to browser.

This has also created a symbiotic relationship between standards and userland, where web component concepts have flowed back into standards and influenced the design of new platform features. You can see this most clearly in the Open UI project, where terms like “parts” and “slots” are frequently invoked (both of which come from web components), and which has landed several new features in browsers such as customizable <select>, popovers, and invoker commands, with more likely on the way.

So whatever happens to web components in the future, and regardless of whether web developers ignore them, forget them, celebrate their demise, or write them off entirely, nothing can take this victory away from them. They are woven into the texture of the web platform in a way that can never be undone. For me, this makes me happy even if I never write another web component again.

You can comment on the fediverse or Lobsters.

Cloud computing is a trap, warns GNU founder Richard Stallman | Computing | The Guardian

Sat, 17 Oct 2026 05:30:57 +0000

The concept of using web-based programs like Google's Gmail is "worse than stupidity", according to a leading advocate of free software.

Cloud computing – where IT power is delivered over the internet as you need it, rather than drawn from a desktop computer – has gained currency in recent years. Large internet and technology companies including Google, Microsoft and Amazon are pushing forward their plans to deliver information and software over the net.

But Richard Stallman, founder of the Free Software Foundation and creator of the computer operating system GNU, said that cloud computing was simply a trap aimed at forcing more people to buy into locked, proprietary systems that would cost them more and more over time.

"It's stupidity. It's worse than stupidity: it's a marketing hype campaign," he told The Guardian.

"Somebody is saying this is inevitable – and whenever you hear somebody saying that, it's very likely to be a set of businesses campaigning to make it true."

The 55-year-old New Yorker said that computer users should be keen to keep their information in their own hands, rather than hand it over to a third party.

His comments echo those made last week by Larry Ellison, the founder of Oracle, who criticised the rash of cloud computing announcements as "fashion-driven" and "complete gibberish".

"The interesting thing about cloud computing is that we've redefined cloud computing to include everything that we already do," he said. "The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?"

The growing number of people storing information on internet-accessible servers rather than on their own machines, has become a core part of the rise of Web 2.0 applications. Millions of people now upload personal data such as emails, photographs and, increasingly, their work, to sites owned by companies such as Google.

Computer manufacturer Dell recently even tried to trademark the term "cloud computing", although its application was refused.

But there has been growing concern that mainstream adoption of cloud computing could present a mixture of privacy and ownership issues, with users potentially being locked out of their own files.

Stallman, who is a staunch privacy advocate, advised users to stay local and stick with their own computers.

"One reason you should not use web applications to do your computing is that you lose control," he said. "It's just as bad as using a proprietary program. Do your own computing on your own computer with your copy of a freedom-respecting program. If you use a proprietary program or somebody else's web server, you're defenceless. You're putty in the hands of whoever developed that software."

Roastidio.us User Picks KjQKkQVg

A Critique of GPUI

The only question that matters

GPUI: notify is zone.js

Making GPUI precise defeats GPUI

Elm: deceptively simple at small scales

A quick note on immediate mode

One engine, different wiring

Why run once

Signals do not automatically make your app fast

Conclusion

Method

References

The Web Is More Than Enough, by Paul Ford (Ftrain)

被高估的「行胜于言」 – So!azy

被高估的「行胜于言」

The web used to belong somewhere – Manu

The web used to belong somewhere

The Military Triumphal Arch

An American VisionFinally Realized

A Monument To The American Spirit

An American VisionFinally Realized

A Tribute To Our Heroes

The Future BeginsWith a Step

Lippitt-Knoster in Practice (Field Notes for Managing Complex Projects)

Strategic Concerns

Tactical Concerns

Thanks for reading

Who am I?

"People Don't Want To Work Anymore"... duh? – Absurd Pirate's Internet Blog

"People Don't Want To Work Anymore"... duh?

as of writing this...

The art of bothering – Herbert Lui

别让自己变成祥林嫂 – So!azy

别让自己变成祥林嫂

We don't want decentralized systems, we want small ones | Andros Fenollosa

Sources

Prisoner’s Dilemma is a Scam · YokerHood · Aleksei Matiushkin

The Outside World, or: Snitches Get Stitches

Pride in a Vacuum

The Balanced Game

The Setup

The Derivation

What This Means

The Three Regimes

The Missing Variable

I built a forum with no interface, no passwords, made for the terminal | Andros Fenollosa

A forum with no interface

An API that discovers itself

Why not use one that already exists?

No passwords

What changes compared to BBJ

Clients

Tyrtulia TUI

tyrtulia.el

Tyrtulia Web

Federation

Try it

The upvote dilemma – Herman's blog

The upvote dilemma

ask me something – yours, tiramisu

ask me something

Free Software, Per Accidens - gingerBill

Origin Stories

Open vs Free(dom)

Source Was Never a Guarantee

Open Source Is Not a Business Model

The Exceptions That Prove the Rule

Copyleft Needs Copyright

What I Expect to Happen

Conclusion

Why is it so expensive to send an email?

Why is it so expensive to send an email?

Simple Mail Transfer Protocol

Wait, who sent that message?!

Old and Goofy Spam Filters

My Personal Conclusion

Drawing Boxes vs. Shading Them In - BiteofanApple

Shading In

Drawing Boxes

GPUI: `notify` is zone.js

An American Vision
Finally Realized

An American Vision
Finally Realized

The Future Begins
With a Step

`srcdoc`

`sandbox`

`csp`